Azure Active Directory Conditional Access

Condividi la tua opinione sull'esperienza di download del PDF.
Documentazione sull'accesso
condizionale di Azure AD
Informazioni su come configurare e testare l'accesso condizionale di Azure Active
Directory
Informazioni sull'accesso condizionale
ｅ PANORAMICA
ｐ CONCETTO
Che cosa si intende per condizioni?
Come si definiscono le posizioni?
Che cosa si intende per controlli?
Dipendenze del servizio di accesso condizionale
Distribuire l'accesso condizionale
ｐ CONCETTO
Pianificare una distribuzione dell'accesso condizionale
ｃ GUIDA PRATICA
Bloccare l'autenticazione legacy
Risoluzione dei problemi relativi allo strumento What If
Criteri comuni di accesso condizionale
ｐ CONCETTO

ｃ GUIDA PRATICA
Richiedere l'autenticazione a più fattori per gli amministratori
Richiedere l'autenticazione a più fattori per la gestione di Azure
Accesso condizionale basato sul rischio (richiede Azure AD Premium P2)
Richiedere una località attendibile per la registrazione dell'autenticazione a più fattori
Bloccare l'accesso in base alla località
Richiedere un dispositivo conforme

Articolo • 21/03/2023
Il perimetro di sicurezza moderno si estende ora oltre la rete di un'organizzazione per

includere l'identità di utenti e dispositivi. Le organizzazioni possono usare segnali basati
sull'identità come parte delle decisioni relative al controllo di accesso.
https://www.microsoft.com/it-it/videoplayer/embed/RE4MwZs?
postJsllMsg=true&autoCaptions=it-it
L'accesso condizionale riunisce i segnali per prendere decisioni e imporre i criteri

dell'organizzazione. L'accesso condizionale di Azure AD è al centro del nuovo piano di
controllo basato sulle identità.
I criteri di accesso condizionale nella loro forma più semplice sono istruzioni if-then: se
un utente vuole accedere a una risorsa, deve completare un'azione. Esempio: un
responsabile delle retribuzioni vuole accedere all'applicazione payroll ed è necessario
eseguire l'autenticazione a più fattori per accedervi.
Gli amministratori devono perseguire due obiettivi principali:
Fare in modo che gli utenti siano produttivi sempre e ovunque

Proteggere gli asset dell'organizzazione
Usare i criteri di accesso condizionale per applicare i controlli di accesso corretti quando
necessario per proteggere l'organizzazione.
） Importante
I criteri di accesso condizionale vengono applicati dopo il completamento del

primo fattore di autenticazione. L'accesso condizionale non è destinato a essere
usato come prima misura di difesa di un'organizzazione per attacchi Denial of
Service (DoS), ma può usare i segnali provenienti da questi eventi per determinare
l'accesso.
Segnali comuni
I segnali comuni su cui si basa l'accesso condizionale per stabilire i criteri includono i
seguenti:
Appartenenza di utenti o gruppi

I criteri possono essere destinati a specifici utenti e gruppi offrendo agli
amministratori un controllo granulare dell'accesso.
Informazioni sugli indirizzi IP
Le organizzazioni possono creare intervalli di indirizzi IP attendibili da usare per
prendere decisioni sui criteri.
Gli amministratori possono specificare intervalli IP in interi paesi/aree
geografiche per bloccare o consentire il traffico in ingresso e in uscita.
Dispositivo
Per applicare i criteri di accesso condizionale, è possibile considerare utenti con
dispositivi di specifiche piattaforme o contrassegnati con uno stato specifico.
Usare filtri per i dispositivi per assegnare criteri a dispositivi specifici, ad
esempio workstation con accesso con privilegi.
Applicazione
Gli utenti che provano ad accedere a specifiche applicazioni possono attivare
diversi criteri di accesso condizionale.
Rilevamento del rischio calcolato e in tempo reale
Segnali di integrazione con Azure AD Identity Protection consente ai criteri di
accesso condizionale di identificare il comportamento di accesso rischioso. I
criteri possono quindi forzare gli utenti a modificare la password, eseguire
l'autenticazione a più fattori per ridurre il livello di rischio o bloccare l'accesso
fino a quando un amministratore non esegue un'azione manuale.
Microsoft Defender for Cloud Apps
Consente di monitorare e controllare in tempo reale l'accesso e le sessioni delle
applicazioni utente, aumentando la visibilità e il controllo sull'accesso alle
attività eseguite all'interno dell'ambiente cloud.
Decisioni comuni
Blocca accesso
Decisione più restrittiva
Concedere l'accesso
Decisione meno restrittiva, può comunque richiedere una o più opzioni
seguenti:
Richiedere l'autenticazione a più fattori
Richiedere che i dispositivi siano contrassegnati come conformi
Richiedi dispositivo aggiunto ad Azure AD ibrido
Richiedere app client approvata
Richiedi criteri di protezione delle pp (anteprima)
Criteri comunemente applicati

Molte organizzazioni condividono preoccupazioni che possono essere risolte con i
criteri di accesso condizionale, ad esempio:
Richiesta dell'autenticazione a più fattori per gli utenti con ruoli amministrativi
Richiesta dell'autenticazione a più fattori per le attività di gestione di Azure
Blocco degli accessi per gli utenti che provano a usare protocolli di autenticazione
legacy
Richiesta di percorsi attendibili per la registrazione dell'autenticazione a più fattori
di Azure AD
Blocco o concessione dell'accesso da specifiche posizioni
Blocco dei comportamenti di accesso rischiosi
Obbligo di usare dispositivi gestiti dall'organizzazione per specifiche applicazioni
Requisiti relativi alle licenze
L'uso di questa funzionalità richiede Azure AD Premium P1 licenze. Per trovare la licenza
corretta per le proprie esigenze, vedere il confronto delle funzionalità di Azure AD
disponibili a livello generale .
Anche i clienti con licenze Premium di Microsoft 365 Business possono accedere alle
funzionalità di accesso condizionale.
I criteri basati sui rischi richiedono l'accesso a Identity Protection, una funzionalità di
Azure AD P2.
Per altri prodotti e funzionalità che possono interagire con i criteri di accesso
condizionale sono richieste licenze appropriate.
Quando le licenze necessarie per l'accesso condizionale scadono, i criteri non vengono
disabilitati o eliminati automaticamente, in modo che i clienti possano eseguire la
migrazione da criteri di accesso condizionale senza una modifica improvvisa del
comportamento di sicurezza. I criteri rimanenti possono essere visualizzati ed eliminati,
ma non più aggiornati.
Le impostazioni predefinite per la sicurezza consentono di proteggere da attacchi

correlati all'identità e sono disponibili per tutti i clienti.
Zero Trust
Questa funzionalità consente alle organizzazioni di allineare le proprie identità ai tre
principi guida di un'architettura di Zero Trust:
Verifica esplicita
Usare privilegi minimi
Presunzione di violazione
Per altre informazioni su Zero Trust e altri modi per allineare l'organizzazione ai principi
guida, vedere Zero Trust Guidance Center.
Passaggi successivi
Creazione dettagliata di criteri di accesso condizionale
Pianificare la distribuzione dell'accesso condizionale
Informazioni su Identity Protection
Informazioni su Microsoft Defender for Cloud Apps
Informazioni su Microsoft Intune
Avvio rapido: Richiedere l'accettazione
di condizioni per l'utilizzo prima
dell'accesso alle app cloud
Articolo • 01/06/2023
In questa guida introduttiva si configureranno criteri di accesso condizionale in Azure

Active Directory (Azure AD) per richiedere agli utenti di accettare le condizioni per
l'utilizzo.
Prerequisiti
Per completare lo scenario in questa guida introduttiva, sono necessari gli elementi
seguenti:
Un account Azure con una sottoscrizione attiva. Creare un account

gratuitamente .
Azure AD Premium P1 o P2 : l'accesso condizionale di Azure AD è una funzionalità
di Azure AD Premium. È possibile iscriversi per ottenere una versione di
valutazione nel portale di Azure.
Un account di test con cui eseguire l'accesso: se non si sa come creare un account
di test, vedere Aggiungere utenti basati sul cloud.
Accesso senza condizioni per l'utilizzo

L'obiettivo di questo passaggio è farsi un'idea dell'esperienza di accesso senza un
criterio di accesso condizionale.
1. Accedere al portale di Azure come utente di test.

2. Uscire,
Creare le condizioni per l'utilizzo

Questa sezione illustra i passaggi necessari per creare un esempio di condizioni per
l'utilizzo. Quando si creano condizioni per l'utilizzo, si seleziona un valore per Applica
con i modelli di criteri di accesso condizionale. Se si seleziona Criteri personalizzati,
subito dopo la creazione delle condizioni per l'utilizzo viene visualizzata la finestra di
dialogo per la creazione di un nuovo criterio di accesso condizionale.
1. In Microsoft Word creare un nuovo documento.
2. Digitare My terms of use (Condizioni per l'utilizzo personali) e quindi salvare il

documento con il nome mytou.pdf.
3. Accedere al portale di Azure come amministratore dell'accesso condizionale,

amministratore della sicurezza o amministratore globale.
4. Passare aCondizioni per l'accesso>condizionaleperla sicurezza> di Azure Active

Directory>.
5. Nel menu in alto selezionare Nuovi termini.


6. Nella casella di testo Nome digitare My TOU (Condizioni per l'utilizzo personali).
7. Caricare il file PDF delle condizioni per l'utilizzo.
8. Selezionare la lingua predefinita.
9. Nella casella di testo Nome visualizzato digitare My TOU (Condizioni per l'utilizzo
personali).
10. Per Richiedi agli utenti di espandere le Condizioni d'uso selezionare Attivata.
11. Per Applica con i modelli di criteri di accesso condizionale selezionare Criteri
personalizzati.
12. Selezionare Crea.
Creare criteri di accesso condizionale

Questa sezione illustra come creare i criteri di accesso condizionale necessari.
Lo scenario di questa guida introduttiva usa:
Portale di Azure come segnaposto per un'app cloud che richiede l'accettazione
delle condizioni per l'utilizzo.
Utente di esempio per testare i criteri di accesso condizionale.
Per configurare i criteri di accesso condizionale:

1. Nella casella di testo Nome della pagina Nuovo digitare Richiedi condizioni per
l'utilizzo.
2. In Assegnazioni selezionare Utenti o identità del carico di lavoro.
a. In Includi scegliere Seleziona utenti e gruppi>Utenti e gruppi.
b. Scegliere l'utente di test e scegliere Seleziona.
3. In Assegnazioni selezionare App o azioni cloud.
4. Selezionare Applicazioni cloud o azioni.
a. In Includi scegliere Seleziona app.
b. Selezionare Gestione di Microsoft Azure e quindi selezionare Seleziona.
5. In Controlli di accesso selezionare Concedi.
a. Selezionare Concedi accesso.
b. Selezionare le condizioni per l'utilizzo create in precedenza denominate ToU
personali e scegliere Seleziona.
6. Nella sezione Abilita criterio selezionare Sì.
Testare i criteri di accesso condizionale

Nella sezione precedente è stato creato un criterio di accesso condizionale che richiede
l'accettazione delle condizioni per l'utilizzo.
Per testare i criteri, provare ad accedere al portale di Azure usando l'account di test.
Verrà visualizzata una finestra di dialogo che richiede di accettare le condizioni per
l'utilizzo.
Pulire le risorse
Quando non sono più necessari, eliminare l'utente di test e i criteri di accesso
condizionale:
Se non si conosce la procedura per eliminare un utente di Azure AD, vedere

Eliminare gli utenti da Azure Active Directory.
Per eliminare il criterio, selezionare i puntini di sospensione (...) accanto al nome
dei criteri e quindi selezionare Elimina.
Per eliminare le condizioni per l'utilizzo, selezionarlo e quindi selezionare Elimina

termini.
Passaggi successivi
Richiedere Multi-Factor Authentication per app specifiche
Esercitazione: Proteggere gli eventi di
accesso degli utenti con Azure AD
Multi-Factor Authentication
Articolo • 24/04/2023
L'autenticazione a più fattori (MFA) è un processo in cui un utente richiede ulteriori

forme di identificazione durante un evento di accesso. Ad esempio, la richiesta potrebbe
essere quella di immettere un codice sul cellulare o di fornire un'analisi delle impronte
digitali. Quando è necessaria una seconda forma di identificazione, la sicurezza viene
aumentata perché questo fattore aggiuntivo non è facile per un utente malintenzionato
ottenere o duplicare.
Azure AD Multi-Factor Authentication e i criteri di accesso condizionale offrono la

flessibilità necessaria per richiedere l'autenticazione a più fattori dagli utenti per eventi
di accesso specifici. Per una panoramica dell'autenticazione a più fattori, è consigliabile
guardare questo video: Come configurare e applicare l'autenticazione a più fattori nel
tenant .
） Importante
Questa esercitazione illustra come un amministratore può abilitare Azure AD Multi-

Factor Authentication.
Se il team IT non ha abilitato la possibilità di usare Azure AD Multi-Factor

Authentication o se si verificano problemi durante l'accesso, contattare l'help desk
per assistenza aggiuntiva.
In questa esercitazione si apprenderà come:
＂ Creare criteri di accesso condizionale per abilitare Azure AD Multi-Factor

Authentication per un gruppo di utenti.
＂ Configurare le condizioni dei criteri che richiedono l'autenticazione a più fattori.
＂ Testare la configurazione e l'uso dell'autenticazione a più fattori come utente.
Prerequisiti
Per completare l'esercitazione, sono necessari i privilegi e le risorse seguenti:
Un tenant di Azure AD funzionante con licenze di valutazione o di Azure AD
Premium P1 abilitate.
Se necessario, crearne uno gratuitamente .
Un account con privilegi di amministratore dell'accesso condizionale,

amministratore della sicurezza o amministratore globale . Alcune impostazioni di
autenticazione a più fattori possono essere gestite anche da un amministratore dei
criteri di autenticazione. Per altre informazioni, vedere Authentication Policy
Administrator.For more information, see Authentication Policy Administrator.
Un account non amministratore con una password nota. Per questa esercitazione è
stato creato un account di questo tipo, denominato testuser. In questa
esercitazione viene testata l'esperienza dell'utente finale per la configurazione e
l'uso di Azure AD Multi-Factor Authentication.
Per informazioni sulla creazione di un account utente, vedere Aggiungere o
eliminare utenti con Azure Active Directory.
Un gruppo di cui l'utente non amministratore è membro. Per questa esercitazione

è stato creato un gruppo di questo tipo denominato MFA-Test-Group. In questa
esercitazione si abilita Azure AD Multi-Factor Authentication per questo gruppo.
Per altre informazioni sulla creazione di un gruppo, vedere Creare un gruppo di
base e aggiungere membri con Azure Active Directory.

I criteri di accesso condizionale costituiscono il modo consigliato per abilitare e usare
Azure AD Multi-Factor Authentication. L'accesso condizionale consente di creare e
definire criteri che reagiscono agli eventi di accesso e richiedono azioni aggiuntive
prima che a un utente venga concesso l'accesso a un'applicazione o a un servizio.

I criteri di accesso condizionale possono essere applicati a utenti, gruppi e app specifici.
L'obiettivo è proteggere l'organizzazione fornendo al tempo stesso i livelli di accesso
corretti agli utenti che ne hanno bisogno.
In questa esercitazione viene creato un criterio di accesso condizionale di base per

richiedere l'autenticazione a più fattori quando un utente accede al portale di Azure. In
un'esercitazione successiva di questa serie viene configurato Azure AD Multi-Factor
Authentication usando un criterio di accesso condizionale basato sul rischio.
Prima di tutto, creare un criterio di accesso condizionale e assegnare il gruppo di test

degli utenti come segue:
1. Accedere al portale di Azure usando un account con autorizzazioni di

amministratore globale.
2. Cercare e selezionare Azure Active Directory. Selezionare quindi Sicurezza dal

menu a sinistra.
3. Selezionare Accesso condizionale, quindi + Nuovo criterio e infine Crea un nuovo

criterio.
4. Immettere un nome per il criterio, ad esempio MFA Pilot.
5. In Assegnazioni selezionare il valore corrente in Utenti o identità del carico di

lavoro.
6. In Che cosa si applica questo criterio?, verificare che sia selezionata l'opzione
Utenti e gruppi .
7. In Includi scegliere Seleziona utenti e gruppi e quindi selezionare Utenti e gruppi.

Poiché nessuno è ancora assegnato, l'elenco di utenti e gruppi (mostrato nel
passaggio successivo) viene aperto automaticamente.
8. Cercare e selezionare il gruppo di Azure AD, ad esempio MFA-Test-Group, quindi

scegliere Seleziona.
È stato selezionato il gruppo a cui applicare i criteri. Nella sezione successiva vengono
configurate le condizioni in base alle quali applicare i criteri.
Configurare le condizioni per l'autenticazione a

più fattori
Ora che vengono creati i criteri di accesso condizionale e viene assegnato un gruppo di
test di utenti, definire le app cloud o le azioni che attivano i criteri. Queste app o azioni
cloud sono gli scenari che si decide richiedono un'elaborazione aggiuntiva, ad esempio
la richiesta di autenticazione a più fattori. Ad esempio, è possibile decidere che l'accesso
a un'applicazione finanziaria o l'uso di strumenti di gestione richieda un'ulteriore
richiesta di autenticazione.
Configurare le app che richiedono l'autenticazione a più

fattori
Per questa esercitazione, configurare i criteri di accesso condizionale per richiedere
l'autenticazione a più fattori quando un utente accede al portale di Azure.
1. Selezionare il valore corrente in App o azioni cloud e quindi in Selezionare il

criterio a cui si applica verificare che l'opzione App cloud sia selezionata.
2. In Includi scegliere Seleziona app.
Poiché non sono ancora selezionate app, l'elenco di app (mostrato nel passaggio
successivo) viene aperto automaticamente.
 Suggerimento
È possibile scegliere di applicare il criterio di accesso condizionale per Tutte le

app cloud o Seleziona le app. Per garantire flessibilità, è anche possibile
escludere determinate app dal criterio.
3. Esplorare l'elenco degli eventi di accesso disponibili che è possibile usare. Per
questa esercitazione, selezionare Gestione di Microsoft Azure in modo che il
criterio si applichi agli eventi di accesso al portale di Azure. Quindi scegliere
Seleziona.
Configurare l'autenticazione a più fattori per l'accesso
Configurare quindi i controlli di accesso. I controlli di accesso consentono di definire i
requisiti per concedere l'accesso a un utente. Potrebbe essere necessario usare un'app
client approvata o un dispositivo aggiunto ad Azure AD ibrido.
In questa esercitazione configurare i controlli di accesso per richiedere l'autenticazione a

più fattori durante un evento di accesso al portale di Azure.
1. In Controlli di accesso selezionare il valore corrente in Concedi e quindi

selezionare Concedi accesso.
2. Selezionare Richiedi autenticazione a più fattori e quindi scegliere Seleziona.
Attivare il criterio
I criteri di accesso condizionale possono essere impostati su Solo report se si vuole
vedere in che modo la configurazione influirà sugli utenti o su No se non si vuole usare
il criterio in questo momento. Poiché un gruppo di test di utenti è destinato a questa
esercitazione, è possibile abilitare i criteri e quindi testare Azure AD Multi-Factor
Authentication.
1. In Abilita criterio selezionare Sì.

2. Per applicare il criterio di accesso condizionale, selezionare Crea.
Testare Azure AD Multi-Factor Authentication

A questo punto, si testerà il funzionamento del criterio di accesso condizionale e di
Azure AD Multi-Factor Authentication.
Per prima cosa, accedere a una risorsa che non richiede l'autenticazione a più fattori:
1. Aprire una nuova finestra del browser in modalità InPrivate o in incognito e

passare a https://account.activedirectory.windowsazure.com .
L'uso di una modalità privata per il browser impedisce alle credenziali esistenti di
influire su questo evento di accesso.
2. Accedere con l'utente test non amministratore, ad esempio testuser. Assicurarsi di

includere @ e il nome di dominio per l'account utente.
Se si tratta della prima istanza dell'accesso con questo account, viene richiesto di
modificare la password. Non viene tuttavia richiesto di configurare o usare
l'autenticazione a più fattori.
3. Chiudere la finestra del browser.
I criteri di accesso condizionale sono stati configurati per richiedere l'autenticazione

aggiuntiva per il portale di Azure. A causa di questa configurazione, viene richiesto di
usare Azure AD Multi-Factor Authentication o di configurare un metodo se non è ancora
stato fatto. Testare questo nuovo requisito accedendo al portale di Azure:
1. Aprire una nuova finestra del browser in modalità InPrivate o in incognito e

passare a https://portal.azure.com .
2. Accedere con l'utente test non amministratore, ad esempio testuser. Assicurarsi di

includere @ e il nome di dominio per l'account utente.
È necessario registrarsi e usare Azure AD Multi-Factor Authentication.

3. Selezionare Avanti per avviare il processo.
È possibile scegliere di configurare un telefono di autenticazione, un telefono

ufficio o un'app per dispositivi mobili per l'autenticazione. Il telefono di
autenticazione supporta messaggi di testo e chiamate telefoniche, il telefono office
supporta chiamate a numeri con estensione e app per dispositivi mobili supporta
l'uso di un'app per dispositivi mobili per ricevere notifiche per l'autenticazione o
generare codici di autenticazione.
4. Completare le istruzioni sullo schermo per configurare il metodo di autenticazione
a più fattori selezionato.
5. Chiudere la finestra del browser e accedere di nuovo in https://portal.azure.com

per testare il metodo di autenticazione configurato. Ad esempio, se è stata
configurata un'app per dispositivi mobili per l'autenticazione, verrà visualizzato un
prompt simile al seguente.
6. Chiudere la finestra del browser.
Pulire le risorse
Se non si vuole più usare i criteri di accesso condizionale configurati come parte di
questa esercitazione, eliminare i criteri seguendo questa procedura:
1. Accedere al portale di Azure .
2. Cercare e selezionare Azure Active Directory e quindi selezionare Sicurezza dal

menu a sinistra.
3. Selezionare Accesso condizionale e quindi selezionare i criteri creati, ad esempio

MFA Pilot.
4. selezionare Elimina e quindi confermare che si desidera eliminare il criterio.

Passaggi successivi
In questa esercitazione è stato abilitato Azure AD Multi-Factor Authentication usando i
criteri di accesso condizionale per un gruppo selezionato di utenti. Si è appreso come:
＂ Creare criteri di accesso condizionale per abilitare Azure AD Multi-Factor

Authentication per un gruppo di utenti di Azure AD.
＂ Configurare le condizioni dei criteri che richiedono l'autenticazione a più fattori.
＂ Testare la configurazione e l'uso dell'autenticazione a più fattori come utente.
Abilitare l'opzione di writeback delle password nella reimpostazione della

password self-service
Commenti e suggerimenti
Was this page helpful? ﾂ Sì ﾄ No
Inviare commenti e suggerimenti per il prodotto

| Ottieni assistenza in Microsoft Q&A
Modelli di accesso condizionale
(anteprima)
Articolo • 18/03/2023
I modelli di accesso condizionale offrono un metodo pratico per distribuire nuovi criteri
allineati alle raccomandazioni Microsoft. Questi modelli sono progettati per fornire la
protezione massima allineata ai criteri comunemente usati in vari tipi e posizioni dei
clienti.
Esistono 14 modelli di criteri di accesso condizionale, filtrati in base a cinque scenari

diversi:
Proteggere le basi
Zero Trust
Lavoro remoto
Proteggere gli amministratori
Minacce emergenti
Tutti
Trovare i modelli nel portale di Azure> Ascrittura accessocondizionale>di Sicurezza>di

Azure Active Directory>Nuovo criterio dal modello (anteprima). Selezionare Mostra
altro per visualizzare tutti i modelli di criteri in ogni scenario.

） Importante
I criteri del modello di accesso condizionale escluderanno solo l'utente che crea il
criterio dal modello. Se l'organizzazione deve escludere altri account, sarà possibile
modificare i criteri dopo la creazione. Passare semplicemente a portale di Azure>
Criterio diaccesso> condizionaledi Sicurezza>di Azure Active Directory>,
selezionare i criteri per aprire l'editor e modificare gli utenti e i gruppi esclusi per
selezionare gli account da escludere.
Per impostazione predefinita, ogni criterio viene creato in modalità solo report, si
consiglia alle organizzazioni di testare e monitorare l'utilizzo, per garantire il
risultato previsto, prima di attivare ogni criterio.
Le organizzazioni possono selezionare singoli modelli di criteri e:
Visualizzare un riepilogo delle impostazioni dei criteri.

Modificare per personalizzare in base alle esigenze dell'organizzazione.
Esportare la definizione JSON da usare nei flussi di lavoro a livello di codice.
Queste definizioni JSON possono essere modificate e quindi importate nella
pagina principale dei criteri di accesso condizionale usando l'opzione Importa
file di criteri .
Criteri dei modelli di accesso condizionale

Bloccare l'autenticazione legacy*
Richiedere l'autenticazione a più fattori per gli amministratori*
Richiedere l'autenticazione a più fattori per tutti gli utenti*
Richiedere l'autenticazione a più fattori per la gestione di Azure*
* Questi quattro criteri, se configurati insieme, forniscono funzionalità simili abilitate

dalle impostazioni predefinite di sicurezza.
Bloccare l'accesso per la piattaforma dei dispositivi sconosciuta o non supportata

Nessuna sessione del browser persistente
Richiedi app client approvate o protezione delle app
Richiedere l'autenticazione a più fattori o un dispositivo aggiunto ad Azure AD
conforme o ibrido per tutti gli utenti
Richiedere un dispositivo aggiunto ad Azure AD conforme o ibrido per gli
amministratori
Richiedere l'autenticazione a più fattori per l'accesso a rischioRichiede Azure AD
Premium P2
Richiedere l'autenticazione a più fattori per l'accesso guest
Richiedi la modifica della password per gli utenti ad alto rischioRichiede Azure AD
Premium P2
Protezione della registrazione delle informazioni di sicurezza
Usa le restrizioni imposte dall'applicazione per i dispositivi non gestiti
Altre politiche comuni

Bloccare l'accesso in base alla località
Bloccare l'accesso ad eccezione di app specifiche
Esclusioni di utenti
I criteri di accesso condizionale sono strumenti avanzati, è consigliabile escludere gli
account seguenti dai criteri:
Gli account di accesso di emergenza o critici per impedire il blocco degli account
a livello di tenant. Nello scenario improbabile che tutti gli amministratori siano
bloccati dal tenant, l'account amministrativo per l'accesso di emergenza può essere
usato per accedere al tenant per eseguire le operazioni necessarie per ripristinare
l'accesso.
Altre informazioni sono disponibili nell'articolo Gestire gli account di accesso di
emergenza in Azure AD.
Gli account del servizio e le entità servizio, ad esempio l'account di
sincronizzazione di Azure AD Connect. Gli account del servizio sono account non
interattivi che non sono associati a un determinato utente. Vengono in genere
usati dai servizi back-end che consentono l'accesso a livello di codice alle
applicazioni, ma vengono usati anche per accedere ai sistemi per scopi
amministrativi. Gli account del servizio di questo tipo dovrebbero essere esclusi
poiché l'autenticazione a più fattori non può essere eseguita a livello di codice. Le
chiamate effettuate dalle entità servizio non verranno bloccate dai criteri di
accesso condizionale con ambito agli utenti. Usare l'accesso condizionale per le
identità del carico di lavoro per definire criteri destinati alle entità servizio.
Se l'organizzazione usa questi account negli script o nel codice, è consigliabile
sostituirli con identità gestite. Come soluzione alternativa temporanea, è
possibile escludere questi account specifici dai criteri di base.
Passaggi successivi
Simulare il comportamento di accesso usando lo strumento What If per l'accesso
condizionale.
Usare la modalità solo report per l'accesso condizionale per determinare i risultati
delle nuove decisioni relative ai criteri.
Creazione di un criterio di accesso
condizionale
Articolo • 18/03/2023
Come illustrato nell'articolo Che cos'è l'accesso condizionale, un criterio di accesso

condizionale è un'istruzione if-then, di Assegnazioni e controlli di accesso. Un criterio di
accesso condizionale riunisce i segnali per prendere decisioni e imporre i criteri
dell'organizzazione.
In che modo un'organizzazione crea questi criteri? Che cosa è necessario? Come
vengono applicate?
Più criteri di accesso condizionale possono essere applicati a un singolo utente in

qualsiasi momento. In questo caso, devono essere soddisfatti tutti i criteri applicati. Ad
esempio, se un criterio richiede l'autenticazione a più fattori (MFA) e un altro richiede un
dispositivo conforme, è necessario completare l'autenticazione a più fattori e usare un
dispositivo conforme. Tutte le assegnazioni sono logicamente ANDed. Se sono state
configurate più assegnazioni, tutte le assegnazioni devono essere soddisfatte per
attivare un criterio.
Se viene selezionato un criterio in cui è selezionato "Richiedi uno dei controlli

selezionati", viene richiesto nell'ordine definito, non appena vengono soddisfatti i
requisiti dei criteri, viene concesso l'accesso.
Tutti i criteri vengono applicati in due fasi:
Fase 1: Raccogliere i dettagli della sessione

Raccogliere i dettagli della sessione, ad esempio il percorso di rete e l'identità
del dispositivo che saranno necessari per la valutazione dei criteri.
La fase 1 della valutazione dei criteri viene eseguita per i criteri e i criteri abilitati
in modalità solo report.
Fase 2: Imposizione
Usare i dettagli della sessione raccolti nella fase 1 per identificare eventuali
requisiti che non sono stati soddisfatti.
Se sono presenti criteri configurati per bloccare l'accesso, con il controllo di
concessione del blocco, l'imposizione verrà arrestata qui e l'utente verrà
bloccato.
All'utente verrà richiesto di completare più requisiti di controllo della
concessione che non sono stati soddisfatti durante la fase 1 nell'ordine
seguente, fino a quando i criteri non vengono soddisfatti:
1. Autenticazione a più fattori

2. Dispositivo da contrassegnare come conforme
3. Dispositivo aggiunto all'identità ibrida di Azure AD
4. App client approvata
5. Criterio di protezione dell'app
6. Modifica della password
7. Condizioni d'uso
8. Controlli personalizzati
Dopo aver soddisfatto tutti i controlli di concessione, applicare i controlli

sessione (Applicazione app, Microsoft Defender for Cloud Apps e durata dei
token)
La fase 2 della valutazione dei criteri si verifica per tutti i criteri abilitati.
Assegnazioni
La parte assegnazioni controlla chi, cosa e dove dei criteri di accesso condizionale.
Utenti e gruppi
Gli utenti e i gruppi assegnano chi includerà o escluderà i criteri. Questa assegnazione
può includere tutti gli utenti, gruppi specifici di utenti, ruoli della directory o utenti guest
esterni.
App o azioni cloud

Le app o le azioni cloud possono includere o escludere applicazioni cloud, azioni utente
o contesti di autenticazione soggetti ai criteri.
Condizioni
Un criterio può contenere più condizioni.
Rischio di accesso
Per le organizzazioni con Azure AD Identity Protection, i rilevamenti dei rischi generati
possono influire sui criteri di accesso condizionale.
Piattaforme per dispositivi

Le organizzazioni con più piattaforme del sistema operativo del dispositivo possono
voler applicare criteri specifici su piattaforme diverse.
Le informazioni usate per calcolare la piattaforma del dispositivo provengono da origini

non verificate, ad esempio stringhe dell'agente utente che possono essere modificate.
Percorsi
I dati sulla posizione vengono forniti dai dati di georilevazione IP. Gli amministratori
possono scegliere di definire posizioni e scegliere di contrassegnare alcuni come
attendibili come quelli per i percorsi di rete dell'organizzazione.
App client
Il software che l'utente sta impiegando per accedere all'app cloud. Ad esempio,
"Browser" e "App per dispositivi mobili e client desktop". Per impostazione predefinita,
tutti i criteri di accesso condizionale appena creati verranno applicati a tutti i tipi di app
client anche se la condizione delle app client non è configurata.
Il comportamento della condizione delle app client è stato aggiornato nell'agosto 2020.
Se sono presenti criteri di accesso condizionale, rimarranno invariati. Tuttavia, se si
seleziona un criterio esistente, l'interruttore configura è stato rimosso e vengono
selezionate le app client a cui si applica il criterio.
Filtrare per dispositivi

Questo controllo consente la destinazione di dispositivi specifici in base ai relativi
attributi in un criterio.
Controlli di accesso
La parte relativa ai controlli di accesso dei criteri di accesso condizionale controlla la
modalità di applicazione di un criterio.
Concedi
Grant fornisce agli amministratori un mezzo di imposizione dei criteri in cui possono
bloccare o concedere l'accesso.
Blocca accesso
Blocca l'accesso in questo modo, blocca l'accesso nelle assegnazioni specificate. Il

controllo del blocco è potente e deve essere esposto con la conoscenza appropriata.
Concedere l'accesso
Il controllo grant può attivare l'imposizione di uno o più controlli.

Richiedi che il dispositivo sia contrassegnato come conforme (Intune)
Richiedere criteri di protezione dell'app
Richiedere la modifica della password
Richiedere le condizioni per l'utilizzo
Gli amministratori possono scegliere di richiedere uno dei controlli precedenti o di tutti i
controlli selezionati usando le opzioni seguenti. L'impostazione predefinita per più
controlli consiste nel richiedere tutti.
Richiedi tutti i controlli selezionati (controllo e controllo)

Richiedi uno dei controlli selezionati (controllo o controllo)
sessione
I controlli sessione possono limitare l'esperienza
Usa restrizioni imposte dalle app

Attualmente funziona solo con Exchange Online e SharePoint Online.
Passa le informazioni sul dispositivo per consentire il controllo dell'esperienza
concedendo l'accesso completo o limitato.
Usare il controllo app per l'accesso condizionale
Usa i segnali di Microsoft Defender for Cloud Apps per eseguire operazioni
come:
Bloccare il download, tagliare, copiare e stampare documenti sensibili.
Monitorare il comportamento della sessione rischiosa.
Richiedere l'etichettatura dei file sensibili.
Frequenza di accesso
Possibilità di modificare la frequenza di accesso predefinita per l'autenticazione
moderna.
Sessione del browser persistente
Consente agli utenti di rimanere connessi dopo la chiusura e la riapertura della
finestra del browser.
Personalizzare la valutazione dell'accesso continuo
Disabilitare le impostazioni predefinite per la resilienza
Criteri semplici
Un criterio di accesso condizionale deve contenere almeno quanto segue per essere
applicato:
Nome del criterio.

Assegnazioni
Utenti e/o gruppi a cui applicare i criteri.
App o azioni cloud a cui applicare i criteri.
Controlli di accesso
Concedere o bloccare i controlli
L'articolo Criteri di accesso condizionale comuni include alcuni criteri che riteniamo utili
per la maggior parte delle organizzazioni.
Passaggi successivi

condizionale
Pianificazione di una distribuzione multifactoring di Azure AD basata sul cloud
Gestione della conformità del dispositivo con Intune

Microsoft Defender for Cloud Apps e accesso condizionale
Accesso condizionale: utenti, gruppi e
identità del carico di lavoro
Articolo • 22/03/2023
Un criterio di accesso condizionale deve includere un'assegnazione di identità utente,

gruppo o carico di lavoro come uno dei segnali nel processo decisionale. Questi
possono essere inclusi o esclusi dai criteri di accesso condizionale. Azure Active
Directory valuta tutti i criteri e garantisce che tutti i requisiti vengano soddisfatti prima
di concedere l'accesso.
https://www.youtube-nocookie.com/embed/5DsW1hB3Jqs
Includere gli utenti

Questo elenco di utenti include in genere tutti gli utenti che un'organizzazione ha la
destinazione in un criterio di accesso condizionale.
Le opzioni seguenti sono disponibili per includere durante la creazione di criteri di

accesso condizionale.
Nessuno
Nessun utente selezionato
tutti gli utenti
Tutti gli utenti presenti nella directory, inclusi i guest B2B.
Selezionare Utenti e gruppi
Utenti guest o esterni
Questa selezione offre diverse opzioni che possono essere usate per
indirizzare i criteri di accesso condizionale a tipi di utente guest o esterni
specifici e tenant specifici contenenti tali tipi di utenti. Esistono diversi tipi di
utenti guest o esterni che possono essere selezionati e possono essere
effettuate più selezioni:
Utenti guest di collaborazione B2B
Utenti del membro di collaborazione B2B
Utenti di connessione diretta B2B
Utenti guest locali, ad esempio qualsiasi utente appartenente al tenant
home con l'attributo di tipo utente impostato su guest
Utenti del provider di servizi, ad esempio un provider di soluzioni cloud
(CSP)
Altri utenti esterni o utenti non rappresentati dagli altri tipi di utente
selezionati
È possibile specificare uno o più tenant per i tipi di utente selezionati oppure
specificare tutti i tenant.
Ruoli della directory
Consente agli amministratori di selezionare ruoli di directory predefiniti di
Azure AD specifici usati per determinare l'assegnazione dei criteri. Ad
esempio, le organizzazioni possono creare criteri più restrittivi per gli utenti
assegnati al ruolo Amministratore globale. Altri tipi di ruolo non sono
supportati, inclusi ruoli con ambito unità amministrativa e ruoli personalizzati.
Utenti e gruppi
Consente la destinazione di set specifici di utenti. Ad esempio, le
organizzazioni possono selezionare un gruppo che contiene tutti i membri
del reparto hr quando un'app HR è selezionata come app cloud. Un gruppo
può essere qualsiasi tipo di gruppo di utenti in Azure AD, inclusi i gruppi di
sicurezza e distribuzione dinamici o assegnati. I criteri verranno applicati agli
utenti e ai gruppi annidati.
） Importante
Quando si selezionano gli utenti e i gruppi inclusi in criteri di accesso condizionale,

esiste un limite al numero di singoli utenti che possono essere aggiunti
direttamente a un criterio di accesso condizionale. Se sono necessari un numero
elevato di utenti singoli che devono essere aggiunti direttamente a criteri di
accesso condizionale, è consigliabile inserire gli utenti in un gruppo e assegnare il
gruppo ai criteri di accesso condizionale.
２ Avviso
Se gli utenti o i gruppi sono membri di oltre 2048 gruppi, l'accesso può essere
bloccato. Questo limite si applica sia all'appartenenza diretta sia al gruppo
annidato.
２ Avviso
I criteri di accesso condizionale non supportano gli utenti assegnati a un ruolo di

directory con ambito a un'unità amministrativa o a ruoli di directory con ambito
diretto a un oggetto, ad esempio tramite ruoli personalizzati.
Escludere gli utenti

Quando le organizzazioni includono ed escludono un utente o un gruppo l'utente o il
gruppo vengono esclusi dai criteri, poiché un'azione di esclusione esegue l'override di
un'inclusione nei criteri. Le esclusioni vengono comunemente usate per gli account di
accesso di emergenza o break-glass. Altre informazioni sugli account di accesso di
emergenza e sul motivo per cui sono importanti sono disponibili negli articoli seguenti:
Gestire gli account di accesso di emergenza in Azure AD

Creare una strategia di gestione di controllo di accesso resiliente con Azure Active
Directory
Le opzioni seguenti sono disponibili per escludere quando si creano criteri di accesso
condizionale.
Utenti guest o esterni

Questa selezione offre diverse opzioni che possono essere usate per indirizzare i
criteri di accesso condizionale a tipi di utente guest o esterni specifici e tenant
specifici contenenti tali tipi di utenti. Esistono diversi tipi di utenti guest o
esterni che possono essere selezionati e possono essere effettuate più selezioni:
Utenti guest di collaborazione B2B
Utenti del membro di collaborazione B2B
Utenti di connessione diretta B2B
Utenti guest locali, ad esempio qualsiasi utente appartenente al tenant home
con l'attributo di tipo utente impostato su guest
Utenti del provider di servizi, ad esempio un provider di soluzioni cloud (CSP)
Altri utenti esterni o utenti non rappresentati dagli altri tipi di utente
selezionati
È possibile specificare uno o più tenant per i tipi di utente selezionati oppure
specificare tutti i tenant.
Ruoli della directory
Consente agli amministratori di selezionare ruoli di directory di Azure AD
specifici usati per determinare l'assegnazione. Ad esempio, le organizzazioni
possono creare criteri più restrittivi per gli utenti assegnati al ruolo
Amministratore globale.
Utenti e gruppi
Consente la destinazione di set specifici di utenti. Ad esempio, le organizzazioni
possono selezionare un gruppo che contiene tutti i membri del reparto hr
quando un'app HR è selezionata come app cloud. Un gruppo può essere un
gruppo di qualsiasi tipo in Azure AD, inclusi gruppi di sicurezza e distribuzione
dinamici o assegnati. I criteri verranno applicati agli utenti e ai gruppi annidati.
Prevenzione del blocco dell'amministratore

Per impedire a un amministratore di bloccare se stessi fuori dalla directory quando si
crea un criterio applicato a Tutti gli utenti e a Tutte le app, verrà visualizzato l'avviso
seguente.
Non bloccare te stesso! È consigliabile applicare un criterio a un piccolo set di utenti

prima di verificarne il comportamento come previsto. È anche consigliabile
escludere almeno un amministratore da questo criterio. Ciò garantisce che sia
ancora disponibile l'accesso e possa aggiornare un criterio se è necessaria una
modifica. Esaminare gli utenti e le app interessati.
Per impostazione predefinita, il criterio fornirà un'opzione per escludere l'utente

corrente dal criterio, ma questa impostazione predefinita può essere sostituita
dall'amministratore, come illustrato nell'immagine seguente.
Se si trova bloccato, vedere Cosa fare se si è bloccati dall'portale di Azure?
Accesso per i partner esterni

I criteri di accesso condizionale destinati agli utenti esterni possono interferire con
l'accesso al provider di servizi, ad esempio privilegi di amministratore delegati granulari
Introduzione ai privilegi di amministratore delegati granulari (GDAP). Per i criteri
destinati ai tenant del provider di servizi di destinazione, usare il tipo di utente esterno
del provider di servizi disponibile nelle opzioni di selezione utenti guest o esterni .
Identità del carico di lavoro
Un'identità del carico di lavoro è un'identità che consente a un'applicazione o a
un'entità servizio di accedere alle risorse, talvolta nel contesto di un utente. I criteri di
accesso condizionale possono essere applicati a entità servizio tenant singole registrate
nel tenant. Le app SaaS e multi-tenant di terze parti non rientrano nell'ambito. Le
identità gestite non sono coperte dai criteri.
Le organizzazioni possono essere destinate a identità del carico di lavoro specifiche da

includere o escludere dai criteri.
Per altre informazioni, vedere l'articolo Accesso condizionale per le identità del carico di
lavoro.
Passaggi successivi
Accesso condizionale: App o azioni cloud
Accesso condizionale: app, azioni e
contesto di autenticazione cloud
Articolo • 14/03/2023
Le app, le azioni e il contesto di autenticazione cloud sono segnali chiave in un criterio

di accesso condizionale. I criteri di accesso condizionale consentono agli amministratori
di assegnare controlli a applicazioni, azioni o contesto di autenticazione specifici.
Gli amministratori possono scegliere dall'elenco di applicazioni, che include

applicazioni Microsoft incorporate e tutte le applicazioni integrate di Azure AD, tra
cui quelle incluse o meno in una raccolta e applicazioni pubblicate tramite proxy
dell'applicazione.
Gli amministratori possono scegliere di definire criteri non basati su
un'applicazione cloud, ma su un'azione dell'utente , ad esempio Registrare le
informazioni di sicurezza o registrare o aggiungere i dispositivi, consentendo
l'accesso condizionale per applicare i controlli su tali azioni.
Gli amministratori possono usare il contesto di autenticazione per fornire un livello
di sicurezza aggiuntivo nelle applicazioni.
Applicazioni cloud Microsoft
Molte delle applicazioni cloud Microsoft esistenti sono incluse nell'elenco selezionabile
di applicazioni.
Gli amministratori possono assegnare un criterio di accesso condizionale alle seguenti

applicazioni cloud di Microsoft. Alcune app come Office 365 e Gestione di Microsoft
Azure includono più app o servizi figlio correlati. Aggiungiamo continuamente altre app,
quindi l'elenco seguente non è esaustivo ed è soggetto a modifiche.
Office 365
Azure Analysis Services
Azure DevOps
Esplora dati di Azure
Hub eventi di Azure
Bus di servizio di Azure
Azure SQL Database e Azure Synapse Analytics
Common Data Service
Microsoft Application Insights Analytics
Microsoft Azure Information Protection
Gestione di Microsoft Azure
Gestione delle sottoscrizioni di Microsoft Azure
Portale di controllo di accesso di Microsoft Commerce Tools
Servizio di autenticazione di Microsoft Commerce Tools
Microsoft Forms
Microsoft Intune
Registrazione di Microsoft Intune
Microsoft Planner
Microsoft Power Apps
Microsoft Power Automate
Microsoft Search in Bing
Microsoft StaffHub
Microsoft Stream
Microsoft Teams
Exchange Online
SharePoint
Yammer
Office Delve
Office Sway
Outlook Groups
Servizio Power BI
Project Online
Skype for Business Online
Rete privata virtuale (VPN)
Windows Defender ATP
） Importante
Le applicazioni disponibili per l'accesso condizionale hanno eseguito un processo

di onboarding e convalida. Questo elenco non include tutte le app Microsoft,
poiché molti sono servizi back-end e non devono avere criteri applicati
direttamente a loro. Se si sta cercando un'applicazione mancante, è possibile
contattare il team di applicazioni specifico o effettuare una richiesta in UserVoice .
Office 365
Microsoft 365 offre servizi di produttività e collaborazione basati sul cloud, ad esempio
Exchange, SharePoint e Microsoft Teams. I servizi cloud di Microsoft 365 sono integrati
profondamente per garantire esperienze fluide e collaborative. Questa integrazione può
causare confusione quando si creano criteri perché alcune app, come ad esempio
Microsoft Teams, presentano dipendenze da altre, quali SharePoint o Exchange.
La suite di Office 365 consente di indirizzare tutti questi servizi in una sola volta. È
consigliabile usare la nuova suite di Office 365 anziché indirizzare singole app cloud per
evitare problemi con le dipendenze del servizio.
La destinazione di questo gruppo di applicazioni consente di evitare problemi che

potrebbero verificarsi a causa di criteri e dipendenze incoerenti. Ad esempio: l'app
Exchange Online è associata ai dati tradizionali Exchange Online come posta, calendario
e informazioni di contatto. I metadati correlati possono essere esposti tramite risorse
diverse, ad esempio la ricerca. Per assicurarsi che tutti i metadati siano protetti da come
previsto, gli amministratori devono assegnare criteri all'app Office 365.
Gli amministratori possono escludere l'intera suite di Office 365 o le app cloud
specifiche Office 365 dai criteri di accesso condizionale.
Le applicazioni chiave seguenti sono interessate dall'app cloud Office 365:
Exchange Online
Servizio di ricerca di Microsoft 365
Microsoft Forms
Microsoft Planner (ProjectWorkManagement)
Microsoft Stream
Microsoft Teams
Microsoft To-Do
Microsoft Flow
portale Microsoft Office 365
Applicazione client di Microsoft Office
Microsoft To-Do WebApp
Servizi di lavagna Microsoft
Office Delve
Office Online
OneDrive
Power Apps
Power Automate
Portale di conformità alla sicurezza &
SharePoint Online
API Amministrazione tenant di Skype e Teams
Sway
Yammer
Un elenco completo di tutti i servizi inclusi è disponibile nell'articolo App incluse

nell'accesso condizionale della suite di app di Office 365.
Gestione di Microsoft Azure

Quando i criteri di accesso condizionale sono destinati all'applicazione Gestione di
Microsoft Azure, all'interno della selezione delle app per i criteri di accesso condizionale,
i criteri verranno applicati per i token rilasciati agli ID applicazione di un set di servizi
strettamente associati al portale.
Azure Resource Manager

Portale di Azure, che copre anche l'interfaccia di amministrazione di Microsoft
Entra
Azure Data Lake
API Application Insights
API di Log Analytics
Poiché i criteri vengono applicati al portale di gestione di Azure e all'API, ai servizi o ai

client con una dipendenza del servizio API di Azure, possono essere influenzati
indirettamente. Ad esempio:
API del modello di distribuzione classica

Azure PowerShell
Interfaccia della riga di comando di Azure
Azure DevOps
Portale di Azure Data Factory
Hub eventi di Azure
Bus di servizio di Azure
Database SQL di Azure
Istanza gestita di SQL
Azure Synapse
Portale di amministratore delle sottoscrizioni di Visual Studio
Microsoft IoT Central
７ Nota
L'applicazione Gestione di Microsoft Azure si applica a Azure PowerShell, che

chiama l'API di Azure Resource Manager. Non si applica ad Azure AD PowerShell,
che chiama microsoft API Graph.
Per altre informazioni su come configurare un criterio di esempio per Gestione di

Microsoft Azure, vedere Accesso condizionale: richiedere MFA per Gestione di Azure.
 Suggerimento
Per Azure per enti pubblici, è necessario eseguire la destinazione dell'applicazione

API di Gestione cloud Azure per enti pubblici.
Altre applicazioni
Gli amministratori possono aggiungere qualsiasi applicazione registrata di Azure AD ai
criteri di accesso condizionale. Queste applicazioni possono includere:
Applicazioni pubblicate tramite il proxy di applicazione di Azure AD

Applicazioni aggiunte dalla raccolta
Applicazioni personalizzate non presenti nella raccolta
Applicazioni legacy pubblicate tramite controller e reti per la distribuzione di app
Applicazioni che usano l'accesso Single Sign-On basato su password
７ Nota
Poiché i criteri di accesso condizionale consentono di impostare i requisiti per

l'accesso a un servizio, non è possibile applicarli a un'applicazione client
(pubblica/nativa). In altre parole, il criterio non è impostato direttamente su
un'applicazione client (pubblica/nativa), ma viene applicato quando un client
chiama un servizio. I criteri impostati nel servizio SharePoint, ad esempio, vengono
applicati ai client che chiamano SharePoint. Un criterio impostato in Exchange si
applica al tentativo di accedere alla posta elettronica tramite il client Outlook.
Questo è il motivo per cui le applicazioni client (pubbliche/native) non sono
disponibili nella selezione delle app cloud e l'opzione di accesso condizionale non è
disponibile nelle impostazioni dell'applicazione client (pubblica/nativa) registrata
nel tenant.
Alcune applicazioni non vengono visualizzate nella selezione. L'unico modo per
includere queste applicazioni in un criterio di accesso condizionale consiste
nell'includere tutte le app cloud.
Tutte le app cloud
L'applicazione di criteri di accesso condizionale a Tutte le app cloud comporta
l'applicazione dei criteri per tutti i token rilasciati ai siti e ai servizi Web. Questa opzione
include applicazioni a cui non è possibile applicare individualmente un criterio di
accesso condizionale, ad esempio Azure Active Directory.
In alcuni casi, un criterio Tutte le app cloud potrebbe bloccare inavvertitamente

l'accesso utente. Questi casi sono esclusi dall'imposizione dei criteri e includono:
Servizi necessari per ottenere il comportamento di sicurezza desiderato. Ad

esempio, le chiamate di registrazione dei dispositivi sono escluse dai criteri di
dispositivo conformi destinati a Tutte le app cloud.
Chiamate ad Azure AD Graph e MS Graph per accedere al profilo utente,

all'appartenenza al gruppo e alle informazioni sulle relazioni comunemente usate
dalle applicazioni escluse dai criteri. Di seguito sono elencati gli ambiti esclusi. Il
consenso è ancora necessario per le app per l'uso di queste autorizzazioni.
Per i client nativi:
Azure AD Graph: posta elettronica, offline_access, openid, profilo, User.read
MS Graph: User.read, Persone.read e UserProfile.read
Per client riservati/autenticati:
Azure AD Graph: posta elettronica, offline_access, openid, profilo, User.read,
User.read.all e User.readbasic.all
MS Graph: User.read,User.read.all, User.read.All Persone.read,
Persone.read.all, GroupMember.Read.All, Member.Read.Hidden e
UserProfile.read
Azioni utente
Le azioni dell'utente sono attività che possono essere eseguite da un utente.
Attualmente l'accesso condizionale supporta due azioni utente:
Registrare le informazioni di sicurezza: questa azione utente consente ai criteri di

accesso condizionale di applicare quando gli utenti abilitati per il tentativo di
registrazione combinata di registrare le informazioni di sicurezza. Altre
informazioni sono disponibili nell'articolo Registrazione di informazioni di sicurezza
combinate.
Registrare o aggiungere dispositivi: questa azione utente consente agli

amministratori di applicare criteri di accesso condizionale quando gli utenti
registrano o aggiungono i dispositivi ad Azure AD. Fornisce una granularità nella
configurazione dell'autenticazione a più fattori per la registrazione o l'aggiunta di
dispositivi anziché criteri a livello di tenant attualmente esistenti. Sono disponibili
tre considerazioni chiave con questa azione utente:
Require multifactor authentication è l'unico controllo di accesso disponibile
con questa azione utente e tutti gli altri sono disabilitati. Questa restrizione
impedisce conflitti con i controlli di accesso dipendenti dalla registrazione del
dispositivo Azure AD o non applicabili alla registrazione dei dispositivi di Azure
AD.
Client apps e Filters for devices Device state le condizioni non sono
disponibili con questa azione utente perché dipendono dalla registrazione dei
dispositivi di Azure AD per applicare i criteri di accesso condizionale.
Quando un criterio di accesso condizionale è abilitato con questa azione utente,
è necessario impostareImpostazioni - Devices to be Azure AD joined or Azure
AD registered require Multifactor Authentication dispositivo di Azure Active
Directory>su>No. In caso contrario, i criteri di accesso condizionale con questa
azione utente non vengono applicati correttamente. Altre informazioni su
questa impostazione del dispositivo sono disponibili in Configurare le
impostazioni del dispositivo.
Contesto di autenticazione
Il contesto di autenticazione può essere usato per proteggere ulteriormente i dati e le
azioni nelle applicazioni. Queste applicazioni possono essere applicazioni personalizzate,
applicazioni line-of-business personalizzate, applicazioni come SharePoint o applicazioni
protette da Microsoft Defender for Cloud Apps.
Un'organizzazione, ad esempio, potrebbe conservare nei siti di SharePoint file come il

menu del pranzo o la ricetta segreta della salsa barbecue. Tutti possono avere accesso al
sito del menu per il pranzo, ma è possibile che gli utenti che hanno accesso al sito della
ricetta segreta della salsa barbecue debbano accedere da un dispositivo gestito e
accettare condizioni per l'utilizzo specifiche.
Configurare i contesti di autenticazione

I contesti di autenticazione vengono gestiti nella portale di Azure nelcontesto di
autenticazione>condizionaledi sicurezza> di Azure Active Directory>.
Creare nuove definizioni di contesto di autenticazione selezionando Nuovo contesto di
autenticazione nella portale di Azure. Le organizzazioni sono limitate a un totale di 25
definizioni di contesto di autenticazione. Configurare gli attributi seguenti:
Nome visualizzato è il nome usato per identificare il contesto di autenticazione in

Azure AD e tra applicazioni che usano contesti di autenticazione. È consigliabile
usare nomi che possono essere usati tra le risorse, ad esempio "dispositivi
attendibili", per ridurre il numero di contesti di autenticazione necessari. Avere un
set ridotto limita il numero di reindirizzamenti e offre una migliore esperienza end-
to-user.
Descrizione fornisce altre informazioni sui criteri usati dagli amministratori di
Azure AD e quelli che applicano contesti di autenticazione alle risorse.
La casella di controllo Pubblica nelle app quando selezionata annuncia il contesto
di autenticazione alle app e li rende disponibili per l'assegnazione. Se non è stato
controllato il contesto di autenticazione non sarà disponibile per le risorse
downstream.
L'ID è di sola lettura e viene usato nei token e nelle app per le definizioni di
contesto di autenticazione specifiche della richiesta. È elencato qui per la
risoluzione dei problemi e i casi d'uso di sviluppo.
Aggiungere ai criteri di accesso condizionale

Gli amministratori possono selezionare contesti di autenticazione pubblicati nei criteri di
accesso condizionale in Assegnazioni>app o azioni cloud e selezionare Contesto di
autenticazione dal menu Seleziona cosa si applica a questo criterio.
Eliminare un contesto di autenticazione
Quando si elimina un contesto di autenticazione, assicurarsi che non siano ancora in uso
applicazioni. In caso contrario, l'accesso ai dati dell'app non sarà più protetto. È possibile
confermare questo prerequisito controllando i log di accesso per i casi in cui vengono
applicati i criteri di accesso condizionale del contesto di autenticazione.
Per eliminare un contesto di autenticazione, non deve avere criteri di accesso

condizionale assegnati e non deve essere pubblicato nelle app. Questo requisito
consente di evitare l'eliminazione accidentale di un contesto di autenticazione ancora in
uso.
Contrassegna le risorse con contesti di autenticazione

Per altre informazioni sull'uso del contesto di autenticazione nelle applicazioni, vedere
gli articoli seguenti.
Usare le etichette di riservatezza per proteggere il contenuto in Microsoft Teams,

gruppi di Microsoft 365 e siti di SharePoint
Applicazioni personalizzate
Passaggi successivi
Accesso condizionale: condizioni
Dipendenze dell'applicazione client
Articolo • 17/03/2023
All'interno di un criterio di accesso condizionale, un amministratore può usare segnali

da condizioni come rischio, piattaforma del dispositivo o posizione per migliorare le
decisioni dei criteri.
È possibile combinare più condizioni per creare criteri di accesso condizionale con
granularità fine e specifici.
Ad esempio, quando si accede a un'applicazione sensibile, un amministratore può

fattoriare le informazioni di rischio di accesso da Identity Protection e posizione nella
decisione di accesso oltre ad altri controlli come l'autenticazione a più fattori.
Rischio di accesso
Per i clienti con accesso a Identity Protection, è possibile valutare il rischio di accesso
come parte di un criterio di accesso condizionale. Un rischio di accesso rappresenta la
probabilità che una richiesta di autenticazione specificata non sia stata autorizzata dal
proprietario dell'identità. Altre informazioni sul rischio di accesso sono disponibili negli
articoli , Informazioni su rischio e procedura: Configurare e abilitare i criteri di rischio.
Rischio utente
Per i clienti con accesso a Identity Protection, il rischio utente può essere valutato come
parte di un criterio di accesso condizionale. Il rischio utente rappresenta la probabilità
che un'identità o un account sia compromesso. Altre informazioni sul rischio utente
sono disponibili negli articoli , Cosa è rischio e Procedura: Configurare e abilitare i criteri
di rischio.

La piattaforma del dispositivo è caratterizzata dal sistema operativo in esecuzione in un
dispositivo. Azure AD identifica la piattaforma usando le informazioni fornite dal
dispositivo, ad esempio le stringhe dell'agente utente. Poiché è possibile modificare le
stringhe dell'agente utente, queste informazioni non vengono verificate. La piattaforma
del dispositivo deve essere usata insieme ai criteri di conformità del dispositivo di
Microsoft Intune o come parte di un'istruzione di blocco. L'impostazione predefinita è
l'applicazione a tutte le piattaforme del dispositivo.
L'accesso condizionale di Azure AD supporta le piattaforme seguenti per i dispositivi:
Android
iOS
Windows
macOS
Linux
Se si blocca l'autenticazione legacy usando la condizione Altri client , è anche possibile

impostare la condizione della piattaforma del dispositivo.
Non è supportata la selezione di piattaforme per dispositivi macOS o Linux quando si

seleziona Richiedi app client approvate o Richiedi criteri di protezione delle app come
solo controlli di concessione o quando si sceglie Richiedi tutti i controlli selezionati.
） Importante
Microsoft consiglia di avere criteri di accesso condizionale per le piattaforme di

dispositivi non supportate. Ad esempio, se si vuole bloccare l'accesso alle risorse
aziendali dal sistema operativo Chrome o da qualsiasi altro client non supportato,
è consigliabile configurare un criterio con una condizione piattaforme dispositivo
che include qualsiasi dispositivo ed esclude piattaforme di dispositivi supportate e
concedere il set di controllo Grant su Blocca l'accesso.
Percorsi
Quando si configura la posizione come condizione, le organizzazioni possono scegliere
di includere o escludere alcune località. Queste posizioni denominate possono includere
le informazioni di rete IPv4 o IPv6 pubbliche, il paese o l'area geografica o anche aree
sconosciute che non mappano a paesi o aree specifiche. Solo gli intervalli IP possono
essere contrassegnati come località attendibile.
Quando si specifica Tutte le località, questa opzione include qualsiasi indirizzo IP in

Internet non solo le località denominate configurate. Quando si seleziona Tutte le
località, gli amministratori possono scegliere di escludere tutte le località attendibili o
selezionate.
Ad esempio, alcune organizzazioni possono scegliere di non richiedere l'autenticazione

a più fattori quando gli utenti sono connessi alla rete in una posizione attendibile, ad
esempio la sede centrale fisica. Gli amministratori possono creare criteri che includono
qualsiasi posizione, ma esclude le posizioni selezionate per le reti locali.
Altre informazioni sulle posizioni sono disponibili nell'articolo Informazioni sulla

posizione nell'accesso condizionale di Azure Active Directory.
App client
Per impostazione predefinita, tutti i criteri di accesso condizionale appena creati
verranno applicati a tutti i tipi di app client, anche se la condizione per le app client non
è configurata.
７ Nota
Il comportamento della condizione delle app client è stato aggiornato nel mese di
agosto 2020. Se sono presenti criteri di accesso condizionale esistenti, rimarranno
invariati. Tuttavia, se si fa clic su un criterio esistente, l'interruttore configura è stato
rimosso e le app client a cui si applica il criterio sono selezionate.
） Importante
Gli accessi dai client di autenticazione legacy non supportano l'autenticazione a più
fattori e non passano le informazioni sullo stato del dispositivo ad Azure AD,
pertanto verranno bloccate dai controlli di concessione di accesso condizionale, ad
esempio la richiesta di MFA o dispositivi conformi. Se si dispone di account che
devono usare l'autenticazione legacy, è necessario escludere tali account dai criteri
o configurare il criterio per applicare solo ai client di autenticazione moderni.
Quando l'interruttore Configura è impostato su Sì, si applica agli elementi selezionati.

Quando è impostato su No, si applica a tutte le app client, inclusi i client di
autenticazione moderni e legacy. Questo interruttore non viene visualizzato nei criteri
creati prima di agosto 2020.
Client di autenticazione moderni

Browser
Queste includono applicazioni basate sul Web che usano protocolli come
SAML, WS-Federation, OpenID Connect o servizi registrati come client
riservato OAuth.
App per dispositivi mobili e client desktop
Questa opzione include applicazioni come le applicazioni desktop e telefono
di Office.
Client di autenticazione legacy
Client Exchange ActiveSync
Questa selezione include tutti gli usi del protocollo Exchange ActiveSync
(EAS).
Quando i criteri bloccano l'uso di Exchange ActiveSync l'utente interessato
riceverà un singolo messaggio di posta elettronica di quarantena. Questo
messaggio di posta elettronica con informazioni sul motivo per cui vengono
bloccate e includono istruzioni di correzione se possibile.
Gli amministratori possono applicare criteri solo alle piattaforme
supportate(ad esempio iOS, Android e Windows) tramite l'accesso
condizionale Microsoft API Graph.
Altri client
Questa opzione include client che usano protocolli di autenticazione
basic/legacy che non supportano l'autenticazione moderna.
SMTP: usato dal client POP e IMAP per inviare messaggi di posta
elettronica.
Individuazione automatica: usata dai client Outlook e EAS per trovare le
cassette postali in Exchange Online e connettervisi.
Exchange Online PowerShell: usato per connettersi a Exchange Online con
PowerShell remoto. Se si blocca l'autenticazione di base per Exchange
Online PowerShell, è necessario usare il modulo Exchange Online
PowerShell per connettersi. Per istruzioni, vedere Connettersi a Exchange
Online PowerShell usando l'autenticazione a più fattori.
Servizi Web Exchange: interfaccia di programmazione usata da Outlook,
Outlook per Mac e app di terze parti.
IMAP4: usato dai client di posta elettronica IMAP.
MAPI su HTTP (MAPI/HTTP): usato da Outlook 2010 e versioni successive.
Rubrica offline: copia delle raccolte di elenchi di indirizzi scaricate e usate
da Outlook.
Outlook via Internet (RPC su HTTP): usato da Outlook 2016 e versioni
precedenti.
Servizio Outlook: usato dall'app di posta elettronica e di calendario per
Windows 10.
POP3: usato dai client di posta elettronica POP.
Servizi Web per la creazione di report: funzionalità usata per recuperare i
dati dei report in Exchange Online.
Queste condizioni vengono comunemente usate quando si richiede un dispositivo

gestito, bloccando l'autenticazione legacy e bloccando applicazioni Web, ma
consentendo app per dispositivi mobili o desktop.
Browser supportati
Questa impostazione funziona con tutti i browser. Tuttavia, per soddisfare i criteri di un
dispositivo, ad esempio un requisito di dispositivo conforme, sono supportati i sistemi
operativi e i browser seguenti. I sistemi operativi e i browser che hanno esaurito il
supporto mainstream non sono visualizzati in questo elenco:
Sistemi operativi Browser
Windows 10 + Microsoft Edge, Chrome, Firefox 91+
Windows Server 2022 Microsoft Edge, Chrome
Windows Server 2019 Microsoft Edge, Chrome
iOS Microsoft Edge, Safari (vedere le note)
Android Microsoft Edge, Chrome
macOS Microsoft Edge, Chrome, Safari

Questi browser supportano l'autenticazione del dispositivo, consentendo al dispositivo
di essere identificato e convalidato rispetto a un criterio. Il controllo del dispositivo ha
esito negativo se il browser è in esecuzione in modalità privata o se i cookie sono
disabilitati.
７ Nota
Edge 85+ richiede che l'utente sia connesso al browser per passare correttamente
l'identità del dispositivo. In caso contrario, si comporta come Chrome senza
l'estensione degli account. Questo accesso potrebbe non verificarsi
automaticamente in uno scenario di aggiunta ad Azure AD ibrido.
Safari è supportato per l'accesso condizionale basato su dispositivo in un

dispositivo gestito, ma non può soddisfare l'app client approvata o Richiedi
condizioni di protezione delle app . Un browser gestito come Microsoft Edge
soddisfa i requisiti di criteri di protezione delle app client e app approvati.
In iOS
con la soluzione MDM di terze parti solo il browser Microsoft Edge supporta i
criteri del dispositivo.
Firefox 91+ è supportato per l'accesso condizionale basato su dispositivo, ma è

necessario abilitare "Consenti l'accesso Single Sign-On per Microsoft, lavoro e
istituto di istruzione".
Perché viene visualizzato un prompt dei certificati nel browser

In Windows 7, iOS, Android e macOS Azure AD identifica il dispositivo usando un
certificato client effettuato quando il dispositivo viene registrato con Azure AD. Quando
un utente accede per la prima volta tramite il browser, viene richiesto di selezionare il
certificato. L'utente deve selezionare questo certificato prima di usare il browser.
Supporto di Chrome
Per il supporto di Chrome in Windows 10 Creators Update (versione 1703) o versioni
successive, installare le estensioni di Windows Account o Office . Queste estensioni
sono necessarie quando un criterio di accesso condizionale richiede dettagli specifici del
dispositivo.
Per distribuire automaticamente questa estensione ai browser Chrome, creare la chiave

del Registro di sistema seguente:
Percorso
HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\ExtensionInstallForcelist
Nome 1
Tipo REG_SZ (string)
Data
ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx
Per il supporto di Chrome in Windows 8.1 e 7, creare la chiave del Registro di sistema
seguente:
Percorso
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoSelectCertificateForUrls
Nome 1
Tipo REG_SZ (string)
Dati {"pattern":https://device.login.microsoftonline.com"";"filter":{"ISSUER":
{"CN":"MS-Organization-Access"}}}
Applicazioni per dispositivi mobili e client desktop

supportati
Le organizzazioni possono selezionare App per dispositivi mobili e client desktop come
app client.
Questa impostazione interessa i tentativi di accesso eseguiti dalle app per dispositivi
mobili e client desktop seguenti:
App client Servizio di Piattaforma

destinazione
Dynamics CRM Dynamics Windows 10,

CRM Windows 8.1,
iOS e Android
App Posta/Calendario/Contatti, Outlook 2016, Outlook 2013 Exchange Windows 10

(con autenticazione moderna) Online
MFA e criteri relativi alle applicazioni. I criteri basati su Qualsiasi Android e iOS
dispositivo non sono supportati. servizio app
Mie app
Microsoft Teams Services : questa app client controlla tutti i Microsoft Windows 10,
servizi che supportano Microsoft Teams e tutte le relative app Teams Windows 8.1,
client - Windows Desktop, iOS, Android, WP e client Web Windows 7, iOS,
Android e
macOS
App client Servizio di Piattaforma
destinazione
App di Office 2016, Office 2013 (con autenticazione moderna), SharePoint Windows 8.1,
sincronizzazione OneDrive client Windows 7
App di Office 2016, app di Office universale, Office 2013 (con SharePoint Windows 10
autenticazione moderna), sincronizzazione OneDrive client Online
Office 2016 (solo Word, Excel, PowerPoint e OneNote). SharePoint macOS
Office 2019 SharePoint Windows 10,

macOS
App Office per dispositivi mobili SharePoint Android, iOS
App Office Yammer Yammer Windows 10,

iOS, Android
Outlook 2019 SharePoint Windows 10,

macOS
Outlook 2016 (Office per macOS) Exchange macOS

Online
Outlook 2016, Outlook 2013 (con l'autenticazione moderna), Exchange Windows 8.1,
Skype for Business (con l'autenticazione moderna) Online Windows 7
App Outlook per dispositivi mobili Exchange Android, iOS

Online
App Power BI Servizio Windows 10,

Power BI Windows 8.1,
Windows 7,
Android e iOS
Skype for Business Exchange Android, iOS

Online
App Visual Studio Team Services Visual Studio Windows 10,

Team Windows 8.1,
Services Windows 7, iOS
e Android
Client Exchange ActiveSync

Le organizzazioni possono selezionare solo i client Exchange ActiveSync quando si
assegnano criteri a utenti o gruppi. Selezionando Tutti gli utenti, Tutti gli
utentiguest e esterni o i ruoli directory causeranno che tutti gli utenti siano
soggetti ai criteri.
Quando si crea un criterio assegnato ai client Exchange ActiveSync, Exchange
Online deve essere l'unica applicazione cloud assegnata al criterio.
Le organizzazioni possono limitare l'ambito di questo criterio a piattaforme
specifiche usando la condizione Piattaforme dispositivo .
Se il controllo di accesso assegnato al criterio usa Richiedi app client approvate,

l'utente viene indirizzato all'installazione e all'uso del client outlook mobile. Nel caso in
cui sia necessaria l'autenticazione a più fattori, le condizioni per l'uso o i controlli
personalizzati , gli utenti interessati vengono bloccati, perché l'autenticazione di base
non supporta questi controlli.
Per altre informazioni, vedere gli articoli seguenti:
Bloccare l'autenticazione legacy con l'accesso condizionale

Richiesta di app client approvate con accesso condizionale
Altri client
Selezionando Altri client è possibile specificare una condizione che influisce sulle app
che usano l'autenticazione di base con protocolli di posta elettronica come IMAP, MAPI,
POP, SMTP e le app Office meno recenti che non usano l'autenticazione moderna.
Stato del dispositivo (deprecato)

Questa funzionalità di anteprima è stata deprecata. I clienti devono usare la condizione
Filtro per i dispositivi nei criteri di accesso condizionale per soddisfare gli scenari
ottenuti in precedenza usando la condizione di stato del dispositivo (deprecata).
La condizione dello stato del dispositivo è stata usata per escludere i dispositivi aggiunti
ad Azure AD ibrido e/o i dispositivi contrassegnati come conformi a un criterio di
conformità Microsoft Intune dai criteri di accesso condizionale di un'organizzazione.
Ad esempio, tutti gli utenti che accedono all'app cloud di Gestione di Microsoft Azure ,
incluso Tutti gli stati del dispositivo esclusi device hybrid Azure AD e Device
contrassegnati come conformi e per i controlli Access, Block.
In questo esempio viene creato un criterio che consente solo l'accesso a Microsoft
Azure Management dai dispositivi aggiunti ad Azure AD ibridi o ai dispositivi
contrassegnati come conformi.
Lo scenario precedente può essere configurato usando Tutti gli utenti che accedono
all'app cloud di Gestione di Microsoft Azure con Filtro per i dispositivi in modalità di
esclusione usando la regola seguente device.trustType -eq "ServerAD" -or
device.isCompliant -eq True e per i controlli Access, Block.
In questo esempio viene creato un criterio che blocca l'accesso all'app cloud di
Gestione di Microsoft Azure da dispositivi non gestiti o non conformi.
） Importante
Lo stato del dispositivo e i filtri per i dispositivi non possono essere usati insieme
nei criteri di accesso condizionale. I filtri per i dispositivi offrono una destinazione
più granulare, incluso il supporto per le informazioni sullo stato del dispositivo
tramite la trustType proprietà e isCompliant .

È disponibile una nuova condizione facoltativa nell'accesso condizionale denominato
filtro per i dispositivi. Quando si configura il filtro per i dispositivi come condizione, le
organizzazioni possono scegliere di includere o escludere i dispositivi in base a un filtro
usando un'espressione di regola sulle proprietà del dispositivo. L'espressione di regola
per il filtro per i dispositivi può essere creata usando la sintassi del generatore di regole
o della regola. Questa esperienza è simile a quella usata per le regole di appartenenza
dinamiche per i gruppi. Per altre informazioni, vedere l'articolo Accesso condizionale:
Filtro per i dispositivi.
Passaggi successivi
Accesso condizionale: concessione

Accesso condizionale: Concedere
Articolo • 10/05/2023
In un criterio di accesso condizionale un amministratore può usare i controlli di accesso

per concedere o bloccare l'accesso alle risorse.
Blocca accesso
Il controllo per bloccare l'accesso considera le assegnazioni e impedisce l'accesso in
base alla configurazione dei criteri di accesso condizionale.
Il blocco dell'accesso è un controllo potente che va applicato con le dovute conoscenze.

I criteri con istruzioni di blocco possono avere effetti collaterali imprevisti. I test e la
convalida appropriati sono fondamentali prima di abilitare il controllo su larga scala. Gli
amministratori devono usare strumenti come la modalità solo report di accesso
condizionale e lo strumento What If nell'accesso condizionale quando si apportano
modifiche.
Concedere l'accesso
Gli amministratori possono scegliere di applicare uno o più controlli durante la
concessione dell'accesso. Questi controlli includono le opzioni seguenti:
Richiedere l'autenticazione a più fattori (Autenticazione a più fattori di Azure AD)

Richiedi livello di autenticazione
Richiedi che il dispositivo sia contrassegnato come conforme (Microsoft Intune)
Richiedere un dispositivo aggiunto ad Azure AD ibrido
Richiedi app client approvata
Quando gli amministratori scelgono di combinare queste opzioni, possono usare i

metodi seguenti:
Richiedi tutti i controlli selezionati (controllo e controllo)

Richiedi uno dei controlli selezionati (controllo o controllo)
Per impostazione predefinita, l'accesso condizionale richiede tutti i controlli selezionati.

La selezione di questa casella di controllo richiede agli utenti di eseguire l'autenticazione
a più fattori di Azure Active Directory (Azure AD). Per altre informazioni sulla
distribuzione dell'autenticazione a più fattori di Azure AD, vedere Planning a cloud-
based Azure AD Multifactor Authentication deployment (Pianificazione di una
distribuzione di Azure AD Multifactor Authentication basata sul cloud).
Windows Hello for Business soddisfa il requisito per l'autenticazione a più fattori nei
criteri di accesso condizionale.
Richiedi livello di autenticazione

Gli amministratori possono scegliere di richiedere requisiti di autenticazione specifici nei
criteri di accesso condizionale. Questi punti di forza di autenticazione sono definiti nei
portale di Azure>Azure Active DirectorySecurityAuthentication
methods>Authentication strengths Authentication (Metodi di autenticazione per
lasicurezza> di Azure Active Directory>). Gli amministratori possono scegliere di creare
le proprie versioni o di usare le versioni predefinite.
Richiedere che i dispositivi siano contrassegnati come
conformi
Le organizzazioni che hanno distribuito Intune possono usare le informazioni restituite
dai dispositivi per identificare i dispositivi che soddisfano specifici requisiti di conformità
dei criteri. Intune invia informazioni di conformità ad Azure AD in modo che l'accesso
condizionale possa decidere di concedere o bloccare l'accesso alle risorse. Per altre
informazioni sui criteri di conformità, vedere Impostare regole nei dispositivi per
consentire l'accesso alle risorse dell'organizzazione usando Intune.
Un dispositivo può essere contrassegnato come conforme da Intune per qualsiasi

sistema operativo del dispositivo o da un sistema di gestione di dispositivi mobili di
terze parti per i dispositivi Windows 10. Per un elenco di sistemi di gestione di dispositivi
mobili di terze parti supportati, vedere Supportare partner di conformità dei dispositivi
di terze parti in Intune.
I dispositivi devono essere registrati in Azure AD prima di poter essere contrassegnati

come conformi. Per altre informazioni sulla registrazione dei dispositivi, vedere
Informazioni sulle identità dei dispositivi.
Richiedi che il dispositivo sia contrassegnato come controllo conforme:
Supporta solo i dispositivi Windows 10+, iOS, Android e macOS registrati con
Azure AD e registrati con Intune.
Considera Microsoft Edge in modalità InPrivate un dispositivo non conforme.
７ Nota
In Windows 7, iOS, Android, macOS e alcuni Web browser di terze parti Azure AD
identifica il dispositivo usando un certificato client di cui viene effettuato il
provisioning quando il dispositivo viene registrato con Azure AD. Quando accede
per la prima volta tramite il browser, all'utente viene richiesto di selezionare il
certificato. Per continuare a usare il browser, è necessario che l'utente selezioni il
certificato.
È possibile usare l'app Microsoft Defender per endpoint con i criteri dell'app client
approvati in Intune per impostare i criteri di conformità del dispositivo su Criteri di
accesso condizionale. Non è necessaria alcuna esclusione per l'app Microsoft Defender
per endpoint durante la configurazione dell'accesso condizionale. Anche se Microsoft
Defender per endpoint in Android e iOS (ID app dd47d17a-3194-4d86-bfd5-
c6ae6f5651e3) non è un'app approvata, ha l'autorizzazione per segnalare il
comportamento di sicurezza del dispositivo. Questa autorizzazione consente il flusso
delle informazioni di conformità all'accesso condizionale.
Richiedere un dispositivo aggiunto ad Azure AD ibrido

Le organizzazioni possono scegliere di usare l'identità del dispositivo come parte dei
criteri di accesso condizionale. Le organizzazioni possono richiedere che i dispositivi
siano aggiunti ad Azure AD ibrido usando questa casella di controllo. Per altre
informazioni sulle identità dei dispositivi, vedere Che cos'è un'identità del dispositivo?.
Quando si usa il flusso OAuth del codice dispositivo, il controllo di concessione richiesto
per il dispositivo gestito o una condizione di stato del dispositivo non è supportato. Ciò
è dovuto al fatto che il dispositivo che esegue l'autenticazione non può fornire lo stato
del dispositivo al dispositivo che fornisce un codice. Inoltre, lo stato del dispositivo nel
token è bloccato per il dispositivo che esegue l'autenticazione. Usare invece il controllo
Richiedi autenticazione a più fattori .
Il controllo Richiedi dispositivo aggiunto ad Azure AD ibrido:
Supporta solo i dispositivi Windows correnti (Windows 10+) aggiunti a un dominio

(prima della Windows 10) e windows correnti(Windows 10+).
Non considera Microsoft Edge in modalità InPrivate come dispositivo aggiunto ad
Azure AD ibrido.

Le organizzazioni possono richiedere che un'app client approvata venga usata per
accedere alle app cloud selezionate. Queste app client approvate supportano Intune
criteri di protezione delle app indipendentemente da qualsiasi soluzione di gestione dei
dispositivi mobili.
Per applicare questo controllo di concessione, il dispositivo deve essere registrato in

Azure AD, che richiede l'uso di un'app broker. L'app broker può essere Microsoft
Authenticator per iOS o Microsoft Authenticator o Microsoft Portale aziendale per
dispositivi Android. Se un'app broker non è installata nel dispositivo quando l'utente
tenta di eseguire l'autenticazione, l'utente viene reindirizzato all'App Store appropriato
per installare l'app broker richiesta.
Le app client seguenti supportano questa impostazione, questo elenco non è esaustivo
ed è soggetto a modifiche:
Microsoft Azure Information Protection

Microsoft Cortana
Microsoft Dynamics 365
Microsoft Edge
Microsoft Excel
Microsoft Power Automate
Microsoft Invoicing
Microsoft Kaizala
Microsoft Launcher
Elenchi Microsoft
Microsoft Office
Microsoft OneDrive
Microsoft OneNote
Microsoft Outlook
Microsoft Planner
Microsoft Power Apps
Microsoft Power BI
Microsoft PowerPoint
Microsoft SharePoint
Microsoft Skype for Business
Microsoft Stream
Microsoft Teams
Microsoft To-Do
Microsoft Visio
Microsoft Word
Microsoft Yammer
Microsoft Whiteboard
Amministrazione di Microsoft 365
Osservazioni:
Le app client approvate supportano la funzionalità di gestione di applicazioni

mobili di Intune.
Il requisito Richiedi app client approvata:
Supporta solo iOS e Android come condizione per le piattaforme del
dispositivo.
Richiede un'app broker per registrare il dispositivo. L'app broker può essere
Microsoft Authenticator per iOS o Microsoft Authenticator o Microsoft Portale
aziendale per i dispositivi Android.
L'accesso condizionale non può considerare Microsoft Edge in modalità InPrivate
un'app client approvata.
I criteri di accesso condizionale che richiedono Microsoft Power BI come app client
approvata non supportano l'uso di Azure AD Application Proxy per connettere
l'app Power BI per dispositivi mobili all'Server di report di Power BI locale.
Per esempi di configurazione , vedere Richiedi app client approvate per l'accesso alle
app cloud con accesso condizionale .

Nel criterio di accesso condizionale è possibile richiedere che nell'app client sia presente
un criterio di protezione delle app Intune prima che l'accesso sia disponibile per le app
cloud selezionate.
Per applicare questo controllo di concessione, l'accesso condizionale richiede che il

dispositivo sia registrato in Azure AD, che richiede l'uso di un'app broker. L'app broker
può essere Microsoft Authenticator per iOS o Microsoft Portale aziendale per i
dispositivi Android. Se un'app broker non è installata nel dispositivo quando l'utente
tenta di eseguire l'autenticazione, l'utente viene reindirizzato all'app Store per installare
l'app broker.
Le applicazioni devono avere l'SDK di Intune con la garanzia dei criteri implementata e
devono soddisfare determinati altri requisiti per supportare questa impostazione. Gli
sviluppatori che implementano applicazioni con l'SDK di Intune possono trovare altre
informazioni su questi requisiti nella documentazione di SDK.
Le app client seguenti sono confermate per supportare questa impostazione, questo
elenco non è esaustivo ed è soggetto a modifiche:
App per dispositivi mobili Adobe Acrobat Reader

iAnnotate per Office 365
Microsoft Cortana
Microsoft Edge
Microsoft Excel
Microsoft Flow Mobile
Microsoft Launcher
Elenchi Microsoft
Microsoft Office
Microsoft OneDrive
Microsoft OneNote
Microsoft Outlook
Microsoft Planner
Microsoft Power BI
Microsoft PowerApps
Microsoft PowerPoint
Microsoft SharePoint
Microsoft Stream Mobile Native 2.0
Microsoft Teams
Microsoft To Do
Microsoft Word
Servizi di lavagna Microsoft
Microsoft Field Service (Dynamics 365)
MultiLine per Intune
Nove messaggi - Email e calendario
Notate for Intune
Provectus - Contatti sicuri
Yammer (Android, iOS e iPadOS)
Questo elenco non è tutto incluso, se l'app non è presente in questo elenco, controllare
con il fornitore dell'applicazione per confermare il supporto.
７ Nota
Kaizala, Skype for Business e Visio non supportano la concessione dei criteri
Richiedi protezione app. Se è necessario che queste app funzionino, usare
esclusivamente l'opzione Richiedi app approvate . L'uso della clausola "o" tra le
due concessioni non funzionerà per queste tre applicazioni.
Le app per i criteri di protezione delle app supportano la funzionalità di gestione delle
applicazioni per dispositivi mobili Intune con protezione dei criteri.
Controllo Richiedi criteri di protezione delle app:
Supporta solo iOS e Android per la condizione della piattaforma del dispositivo.
Richiede un'app broker per registrare il dispositivo. In iOS l'app broker è Microsoft
Authenticator. In Android l'app broker è Portale aziendale Intune.
Vedere Richiedi criteri di protezione delle app e un'app client approvata per l'accesso
alle app cloud con accesso condizionale per esempi di configurazione.

Quando viene rilevato il rischio utente, gli amministratori possono usare le condizioni
dei criteri di rischio utente per avere l'utente modificare in modo sicuro una password
usando la reimpostazione della password self-service di Azure AD. Gli utenti possono
eseguire una reimpostazione della password self-service per la correzione automatica.
Questo processo chiuderà l'evento di rischio utente per evitare avvisi non necessari per
gli amministratori.
Quando un utente viene richiesto di modificare una password, sarà prima necessario
completare l'autenticazione a più fattori. Assicurarsi che tutti gli utenti siano registrati
per l'autenticazione a più fattori, quindi vengono preparati nel caso in cui venga rilevato
il rischio per il proprio account.
２ Avviso
Gli utenti devono essere registrati in precedenza per l'autenticazione a più fattori
prima di attivare i criteri di rischio utente.
Le restrizioni seguenti si applicano quando si configura un criterio usando il controllo

delle modifiche della password:
Il criterio deve essere assegnato a "tutte le app cloud". Questo requisito impedisce
a un utente malintenzionato di usare un'app diversa per modificare la password
dell'utente e reimpostare il rischio dell'account accedendo a un'app diversa.
Richiedere la modifica della password non può essere usata con altri controlli, ad
esempio la richiesta di un dispositivo conforme.
Il controllo delle modifiche della password può essere usato solo con la condizione
di assegnazione utente e gruppo, la condizione di assegnazione dell'app cloud
(che deve essere impostata su "tutti") e sulle condizioni di rischio utente.
Condizioni per l'utilizzo

Se l'organizzazione ha creato condizioni per l'uso, altre opzioni potrebbero essere visibili
nei controlli di concessione. Queste opzioni consentono agli amministratori di richiedere
il riconoscimento delle condizioni di utilizzo come condizione di accesso alle risorse
protette dai criteri. Altre informazioni sulle condizioni per l'uso in Azure Active Directory
sono disponibili in termini di utilizzo.
Controlli personalizzati (anteprima)

I controlli personalizzati sono una funzionalità di anteprima di Azure AD. Quando si
usano controlli personalizzati, gli utenti vengono reindirizzati a un servizio compatibile
per soddisfare i requisiti di autenticazione separati da Azure AD. Per altre informazioni,
vedere l'articolo Controlli personalizzati .
Passaggi successivi
Accesso condizionale: controlli sessione
Modalità solo report

Accesso condizionale: sessione
Articolo • 31/03/2023
All'interno di un criterio di accesso condizionale, un amministratore può usare i controlli

sessione per abilitare esperienze limitate all'interno di applicazioni cloud specifiche.
Restrizioni applicate dall'applicazione

Le organizzazioni possono usare questo controllo per richiedere ad Azure AD di passare
le informazioni sul dispositivo alle app cloud selezionate. Le informazioni sul dispositivo
consentono alle app cloud di sapere se una connessione proviene da un dispositivo
conforme o aggiunto al dominio e di aggiornare l'esperienza della sessione. Questo
controllo supporta solo Office 365, SharePoint Online ed Exchange Online come app
cloud selezionate. Quando selezionata, l'app cloud usa le informazioni sul dispositivo
per fornire agli utenti un'esperienza limitata o completa. Limitato quando il dispositivo
non è gestito o conforme e completo quando il dispositivo è gestito e conforme.
Per altre informazioni sull'uso e sulla configurazione delle restrizioni imposte dalle app,
vedere gli articoli seguenti:
Abilitazione dell'accesso limitato con SharePoint Online
Abilitazione dell'accesso limitato con Exchange Online
Controllo dell'applicazione di accesso

condizionale
La funzionalità Controllo app per l'accesso condizionale prevede l'uso di un'architettura
di proxy inverso ed è integrata in modo unico con l'accesso condizionale di Azure AD.
Accesso condizionale di Azure AD consente di applicare i controlli di accesso sulle app
dell'organizzazione in base a determinate condizioni. Le condizioni definiscono l'utente
o il gruppo di utenti, app cloud e posizioni e reti a cui si applica un criterio di accesso
condizionale. Dopo aver determinato le condizioni, è possibile instradare gli utenti a
Microsoft Defender for Cloud Apps dove è possibile proteggere i dati con controllo app
di accesso condizionale applicando controlli di accesso e sessione.
Tramite il controllo delle app con l'accesso condizionale, è possibile monitorare e

controllare l'accesso e le sessioni delle app dell'utente in tempo reale, in base ai criteri di
accesso e di sessione. I criteri di accesso e sessione vengono usati all'interno del portale
di Defender for Cloud Apps per perfezionare i filtri e impostare le azioni da eseguire.
Con i criteri di accesso e di sessione è possibile eseguire le operazioni seguenti:
Impedire l'esfiltrazione di dati: è possibile bloccare le operazioni di download,

taglio, copia e stampa di documenti sensibili, ad esempio nei dispositivi non
gestiti.
Applicare la protezione durante il download: invece di bloccare il download dei
documenti sensibili, è possibile richiedere che i documenti siano etichettati e
protetti con Azure Information Protection. Questa azione garantisce che il
documento sia protetto e che l'accesso utente sia limitato in una sessione
potenzialmente rischiosa.
Impedire il caricamento di file non etichettati: prima che venga caricato, distribuito
e usato un file sensibile, è importante assicurarsi che il file abbia l'etichetta e la
protezione corretti. È possibile fare in modo che i file con contenuto sensibile ma
non provvisti di etichetta vengano bloccati fino a quando l'utente non classifica il
contenuto.
Monitorare le sessioni utente per la conformità (anteprima): gli utenti rischiosi
vengono monitorati quando accedono alle app e le relative azioni vengono
registrate all'interno della sessione. È possibile esaminare e analizzare il
comportamento degli utenti per comprendere dove e in quali condizioni applicare
i criteri di sessione in futuro.
Blocca l'accesso (anteprima): è possibile bloccare in modo granulare l'accesso per
app e utenti specifici a seconda di diversi fattori di rischio. Ad esempio, è possibile
bloccarli se usano certificati client come forma di gestione dei dispositivi.
Bloccare le attività personalizzate: alcune app presentano scenari unici che
comportano rischi, ad esempio l'invio di messaggi con contenuto sensibile in app
come Microsoft Teams o Slack. In questi tipi di scenari è possibile analizzare i
messaggi alla ricerca di contenuto sensibile e bloccarli in tempo reale.
Per altre informazioni, vedere l'articolo Distribuire il controllo app di accesso

condizionale per le app in primo piano.
Frequenza di accesso
La frequenza di accesso definisce il periodo di tempo prima che all'utente venga
richiesto di ripetere l'accesso quando tenta di accedere a una risorsa. Gli amministratori
possono selezionare un periodo di tempo (ore o giorni) o scegliere di richiedere la
riutenticazione ogni volta.
L'impostazione della frequenza di accesso funziona con le app che hanno implementato
i protocolli OAUTH2 o OIDC secondo gli standard. La maggior parte delle app native
Microsoft per Windows, Mac e Mobile, incluse le applicazioni Web seguenti, seguono
l'impostazione.
Word, Excel, PowerPoint Online

OneNote Online
Office.com
Portale di amministrazione di Microsoft 365
Exchange Online
SharePoint e OneDrive
Client Web Teams
Dynamics CRM Online
Portale di Azure
Per altre informazioni, vedere l'articolo Configurare la gestione delle sessioni di

autenticazione con l'accesso condizionale.
Sessione del browser persistente

Una sessione del browser persistente consente agli utenti di rimanere connessi dopo
aver chiuso e riaperto la finestra del browser.
Per altre informazioni, vedere l'articolo Configurare la gestione delle sessioni di
autenticazione con l'accesso condizionale.
Personalizzare la valutazione dell'accesso

continuo
La valutazione dell'accesso continuo è abilitata automaticamente come parte dei criteri
di accesso condizionale di un'organizzazione. Per le organizzazioni che desiderano
disabilitare Valutazione continua dell'accesso, questa configurazione è ora un'opzione
all'interno del controllo della sessione all'interno dell'accesso condizionale. È possibile
impostare come ambito dei criteri di valutazione continua dell'accesso tutti gli utenti o
utenti e gruppi specifici. Gli amministratori possono effettuare la selezione seguente
durante la creazione di nuovi criteri o durante la modifica di criteri di accesso
condizionale esistenti.
Disabilitare solo il funzionamento quando vengono selezionate Tutte le app cloud

, non sono selezionate condizioni e Disabilita è selezionata in>Personalizza
valutazione dell'accesso continuo in criteri di accesso condizionale. È possibile
scegliere di disabilitare tutti gli utenti o utenti e gruppi specifici.

Disabilitare le impostazioni predefinite di

resilienza
Durante un'interruzione, Azure AD estende l'accesso alle sessioni esistenti applicando i
Se le impostazioni predefinite di resilienza sono disabilitate, l'accesso viene negato dopo
la scadenza delle sessioni esistenti. Per altre informazioni, vedere l'articolo Accesso
condizionale: Impostazioni predefinite di resilienza.
Richiedere la protezione dei token per le

sessioni di accesso (anteprima)
La protezione dei token (talvolta definita associazione di token nel settore) tenta di
ridurre gli attacchi usando il furto di token assicurando che un token sia utilizzabile solo
dal dispositivo previsto. Quando un utente malintenzionato è in grado di rubare un
token, eseguendo il hijacking o la riproduzione, può rappresentare la vittima fino alla
scadenza del token o revocarlo. Il furto di token è pensato come un evento
relativamente raro, ma il danno da esso può essere significativo.
L'anteprima funziona solo per scenari specifici. Per altre informazioni, vedere l'articolo
Accesso condizionale: Protezione token (anteprima) .
Passaggi successivi

Che cos'è la modalità solo report per
l'accesso condizionale?
Articolo • 17/03/2023
L'accesso condizionale viene ampiamente usato dai nostri clienti per garantire la
sicurezza applicando i controlli di accesso corretti nelle circostanze giuste. Tuttavia, una
delle sfide legate alla distribuzione di un criterio di accesso condizionale
nell'organizzazione consiste nel determinare l'impatto per gli utenti finali. Può essere
difficile prevedere il numero e i nomi degli utenti interessati da iniziative di distribuzione
comuni, ad esempio bloccare l'autenticazione legacy, richiedere l'autenticazione a più
fattori per una popolazione di utenti o implementare criteri di rischio di accesso.
La modalità solo report è un nuovo stato dei criteri di accesso condizionale che
consente agli amministratori di valutare l'impatto dei criteri di accesso condizionale
prima di abilitarli nell'ambiente in uso. Con il rilascio della modalità solo report:
I criteri di accesso condizionale possono essere abilitati in modalità solo report,

non è applicabile con l'ambito "Azioni utente".
Durante l'accesso, i criteri in modalità solo report vengono valutati ma non
applicati.
I risultati vengono registrati nelle schede Accesso condizionale e Solo report dei
dettagli del log di accesso.
I clienti con una sottoscrizione di Monitoraggio di Azure possono monitorare
l'impatto dei criteri di accesso condizionale tramite la cartella di lavoro delle
informazioni dettagliate Accesso condizionale.
https://www.youtube-nocookie.com/embed/NZbPYfhb5Kc
２ Avviso
I criteri in modalità solo report che richiedono dispositivi conformi possono

richiedere agli utenti in Mac, iOS e Android di selezionare un certificato del
dispositivo durante la valutazione dei criteri, anche se la conformità del dispositivo
non viene applicata. Queste richieste possono essere ripetute fino a quando il
dispositivo non viene reso conforme. Per impedire agli utenti finali di ricevere
richieste durante l'accesso, escludere le piattaforme per dispositivi Mac, iOS e
Android da criteri solo report che eseguono controlli di conformità dei dispositivi.
Si noti che la modalità solo report non è applicabile per i criteri di accesso
condizionale con ambito "Azioni utente".
Risultati dei criteri
Quando un criterio in modalità solo report viene valutato per un determinato accesso,
sono disponibili quattro nuovi valori di risultato possibili:
Risultato Descrizione
Solo Tutte le condizioni dei criteri configurate, i controlli di concessione non interattivi
report: richiesti e i controlli sessione sono stati soddisfatti. Ad esempio, un requisito di
Operazione autenticazione a più fattori viene soddisfatto da un'attestazione MFA già presente
riuscita nel token oppure un criterio del dispositivo conforme viene soddisfatto eseguendo
un controllo del dispositivo in un dispositivo conforme.
Solo Tutte le condizioni dei criteri configurate sono state soddisfatte, ma non tutti i
report: controlli di concessione non interattivi richiesti o i controlli sessione sono stati
errore soddisfatti. Ad esempio, un criterio si applica a un utente in cui è configurato un
controllo di blocco oppure un dispositivo non riesce a rispettare i criteri del
dispositivo.
Solo Tutte le condizioni dei criteri configurate sono state soddisfatte, ma l'azione
report: dell'utente deve soddisfare i controlli di concessione o i controlli sessione necessari.
azione Con la modalità solo report, all'utente non viene richiesto di soddisfare i controlli
dell'utente richiesti. Ad esempio, agli utenti non vengono richiesti problemi di autenticazione a
richiesta più fattori o condizioni per l'utilizzo.
Solo Non tutte le condizioni dei criteri configurate sono state soddisfatte. Ad esempio,
report: non l'utente viene escluso dal criterio o il criterio si applica solo a determinate posizioni
applicato denominate attendibili.
Cartella di lavoro di Insights per l'accesso
condizionale
Gli amministratori hanno la possibilità di creare più criteri in modalità solo report, quindi
è necessario comprendere sia l'impatto individuale di ogni criterio che l'impatto
combinato di più criteri valutati insieme. La nuova cartella di lavoro di Informazioni
dettagliate sull'accesso condizionale consente agli amministratori di visualizzare le query
di accesso condizionale e monitorare l'impatto di un criterio per un determinato
intervallo di tempo, un set di applicazioni e utenti specificati.
Passaggi successivi
Configurare la modalità solo report in un criterio di accesso condizionale
Che cosa sono le dipendenze del
servizio nell'accesso condizionale di
Azure Active Directory?
Articolo • 18/03/2023
Con i criteri di accesso condizionale è possibile specificare i requisiti di accesso ai siti

Web e ai servizi. Ad esempio, i requisiti di accesso possono includere la richiesta di
autenticazione a più fattori (MFA) o dispositivi gestiti.
Quando si accede direttamente a un sito o a un servizio, l'impatto di un criterio

correlato è in genere facile da valutare. Ad esempio, se si dispone di un criterio che
richiede l'autenticazione a più fattori (MFA) per SharePoint Online configurato,
l'autenticazione a più fattori viene applicata per ogni accesso al portale Web di
SharePoint. Tuttavia, non è sempre semplice valutare l'impatto di un criterio perché
esistono app cloud con dipendenze ad altre app cloud. Ad esempio, Microsoft Teams
può fornire l'accesso alle risorse in SharePoint Online. Pertanto, quando si accede a
Microsoft Teams nello scenario corrente, si è soggetti anche ai criteri di MFA di
SharePoint.
 Suggerimento
L'uso dell'app Office 365 avrà come destinazione tutte le app di Office per evitare
problemi con le dipendenze del servizio nello stack di Office.
Imposizione dei criteri

Se si dispone di una dipendenza del servizio configurata, è possibile applicare i criteri
usando l'imposizione anticipata o con associazione tardiva.
L'applicazione dei criteri con associazione anticipata significa che un utente deve
soddisfare i criteri del servizio dipendente prima di accedere all'app chiamante. Ad
esempio, un utente deve soddisfare i criteri di SharePoint prima di accedere a MS
Teams.
L'applicazione dei criteri con associazione tardiva si verifica dopo che l'utente
accede all'app chiamante. L'applicazione viene posticipata a quando si chiamano le
richieste dell'app, un token per il servizio downstream. Ad esempio, MS Teams
accede a Planner e Office.com l'accesso a SharePoint.
Il diagramma seguente illustra le dipendenze del servizio MS Teams. Le frecce a tinta
unita indicano l'imposizione con associazione anticipata la freccia tratteggiata per
Planner indica l'imposizione con associazione tardiva.
Come procedura consigliata, è consigliabile impostare criteri comuni tra app e servizi
correlati, quando possibile. Un comportamento di sicurezza coerente offre un'esperienza
utente ottimale. Ad esempio, l'impostazione di criteri comuni in Exchange Online,
SharePoint Online, Microsoft Teams e Skype for business riduce significativamente le
richieste impreviste che possono derivare da criteri diversi applicati ai servizi
downstream.
Un ottimo modo per eseguire criteri comuni con le applicazioni nello stack di Office
consiste nell'usare l'app Office 365 invece di scegliere come destinazione singole
applicazioni.
Nella tabella seguente sono elencate altre dipendenze del servizio, in cui le app client
devono soddisfare. Questo elenco non è esaustivo.
App client Servizio downstream Imposizione
Azure Data Lake Gestione di Microsoft Azure (portale e API) Associazione anticipata
Microsoft Classroom Exchange Associazione anticipata

App client Servizio downstream Imposizione
SharePoint Associazione anticipata
Microsoft Teams Exchange Associazione anticipata
MS Planner Associazione tardiva
Microsoft Stream Associazione tardiva
Skype for Business Online Associazione anticipata
Microsoft Whiteboard Associazione tardiva
Portale di Office Exchange Associazione tardiva
SharePoint Associazione tardiva
Gruppi di Outlook Exchange Associazione anticipata
Power Apps Gestione di Microsoft Azure (portale e API) Associazione anticipata
Microsoft Azure Active Directory Associazione anticipata
Exchange Associazione anticipata
Power Automate Power Apps Associazione anticipata
Project Dynamics CRM Associazione anticipata
Skype for Business Exchange Associazione anticipata
Visual Studio Gestione di Microsoft Azure (portale e API) Associazione anticipata
Microsoft Forms Exchange Associazione anticipata
Microsoft To-Do Exchange Associazione anticipata
Risoluzione dei problemi relativi alle

dipendenze del servizio
Il log di accesso di Azure Active Directory è una fonte preziosa di informazioni per la
risoluzione dei problemi relativi al motivo e alla modalità di applicazione dei criteri di
accesso condizionale nell'ambiente. Per altre informazioni sulla risoluzione dei problemi
di risultati di accesso imprevisti correlati all'accesso condizionale, vedere l'articolo
Risoluzione dei problemi di accesso con l'accesso condizionale.
Passaggi successivi
Per informazioni su come implementare l'accesso condizionale nell'ambiente in uso,
vedere Pianificare la distribuzione dell'accesso condizionale in Azure Active Directory.
Accesso condizionale: Filtro per le
applicazioni (anteprima)
Articolo • 17/03/2023
Attualmente i criteri di accesso condizionale possono essere applicati a tutte le app o

alle singole app. Le organizzazioni con un numero elevato di app possono trovare
questo processo difficile da gestire tra più criteri di accesso condizionale.
I filtri dell'applicazione sono una nuova funzionalità per l'accesso condizionale che
consente alle organizzazioni di contrassegnare le entità servizio con attributi
personalizzati. Questi attributi personalizzati vengono quindi aggiunti ai criteri di
accesso condizionale. I filtri per le applicazioni vengono valutati al runtime di rilascio dei
token, una domanda comune è se le app vengono assegnate in fase di esecuzione o in
fase di configurazione.
In questo documento viene creato un set di attributi personalizzato, si assegna un

attributo di sicurezza personalizzato all'applicazione e si crea un criterio di accesso
condizionale per proteggere l'applicazione.
） Importante
Il filtro per le applicazioni è attualmente disponibile in anteprima pubblica. Per altre

informazioni sulle anteprime, vedere Condizioni per l'utilizzo supplementari per le
anteprime di Microsoft Azure .
Assegnare ruoli
Gli attributi di sicurezza personalizzati sono sensibili alla sicurezza e possono essere
gestiti solo dagli utenti delegati. Anche gli amministratori globali non dispongono delle
autorizzazioni predefinite per gli attributi di sicurezza personalizzati. Uno o più dei ruoli
seguenti devono essere assegnati agli utenti che gestiscono o segnalano questi attributi.
Nome del ruolo Descrizione
Amministratore Assegnare chiavi e valori di attributo di sicurezza personalizzati

dell'assegnazione degli agli oggetti Azure AD supportati.
attributi
Lettore di assegnazione degli Leggere chiavi e valori degli attributi di sicurezza personalizzati
attributi per gli oggetti Azure AD supportati.
Nome del ruolo Descrizione
Amministratore delle Definire e gestire la definizione degli attributi di sicurezza

definizioni degli attributi personalizzati.
Lettore di definizioni di Leggere la definizione degli attributi di sicurezza personalizzati.

attributi
1. Assegnare il ruolo appropriato agli utenti che gestiranno o segnalano questi

attributi nell'ambito della directory.
Per la procedura dettagliata, vedere Assegnare ruoli di Azure usando il portale di

Azure.
Creare attributi di sicurezza personalizzati

Seguire le istruzioni riportate nell'articolo Aggiungere o disattivare attributi di sicurezza
personalizzati in Azure AD (anteprima) per aggiungere il set di attributi seguente e
Nuovi attributi.
Creare un set di attributi denominato ConditionalAccessTest.

Creare nuovi attributi denominati policyRequirement che consentono
l'assegnazione di più valori e consentono l'assegnazione di valori predefiniti
solo. Vengono aggiunti i valori predefiniti seguenti:
legacyAuthAllowed
blockGuesUsers
requireMFA
requireCompliantDevice
requireHybridJoinedDevice
requireCompliantApp

７ Nota
I filtri di accesso condizionale per i dispositivi funzionano solo con attributi di

sicurezza personalizzati di tipo "string".


1. Accedere alla portale di Azure come amministratore di accesso condizionale,

2. Passare ad Azure Active Directory>Sicurezza>Accesso condizionale.
3. Selezionare Nuovi criteri.
4. Assegnare un nome ai criteri. È consigliabile che le organizzazioni creino uno
standard descrittivo per i nomi dei criteri.
a. In Includi selezionare Tutti gli utenti.
b. In Escludi selezionare Utenti e gruppi e scegliere gli account di accesso di
emergenza o gli account critici dell'organizzazione.
c. Selezionare Operazione completata.
6. In Applicazioni cloud o azioni selezionare le opzioni seguenti:
a. Selezionare i criteri applicati alle app cloud.
b. Includere Le app Seleziona.
c. Selezionare Modifica filtro.
d. Impostare Configura su Sì.
e. Selezionare l'attributo creato in precedenza denominato policyRequirement.
f. Impostare Operatore su Contiene.
g. Impostare Valore per richiedereMFA.
h. Selezionare Fine.
7. In Controlli>di accesso Concedere l'accesso selezionareConcediaccesso, Richiedi
autenticazione a più fattori e selezionare Seleziona.
8. Confermare le impostazioni e impostare Attiva criterio su Solo report.
9. Selezionare Crea per creare e abilitare il criterio.
Dopo aver confermato le impostazioni usando la modalità di solo report, un
amministratore può spostare l'opzione Abilita criterio solo da Report a Attiva.
Configurare attributi personalizzati
Passaggio 1: Configurare un'applicazione di esempio

Se si dispone già di un'applicazione di test che usa un'entità servizio, è possibile
ignorare questo passaggio.
Configurare un'applicazione di esempio che illustra come un processo o un servizio

Windows può essere eseguito con un'identità dell'applicazione, anziché l'identità di un
utente. Seguire le istruzioni riportate nell'articolo Guida introduttiva: Ottenere un token
e chiamare Microsoft API Graph usando l'identità di un'app console per creare questa
applicazione.
Passaggio 2: Assegnare un attributo di sicurezza

personalizzato a un'applicazione
Quando non si dispone di un'entità servizio elencata nel tenant, non può essere
destinata. La suite di Office 365 è un esempio di un'entità servizio di questo tipo.

2. Passare alle applicazioni Azure Active Directory>Enterprise.
3. Selezionare l'entità servizio a cui si vuole applicare un attributo di sicurezza
personalizzato.
4. In Gestisci>attributi di sicurezza personalizzati (anteprima) selezionare Aggiungi
assegnazione.
5. In Set di attributi selezionare CondizionalAccessTest.
6. In Nome attributo selezionare policyRequirement.
7. In Valori assegnati selezionare Aggiungi valori, selezionare richiediMFA
nell'elenco e quindi selezionare Fine.
8. Selezionare Salva.
Passaggio 3: Testare i criteri

Accedere come utente che i criteri si applicano a e testare per verificare che
l'autenticazione a più fattori sia necessaria durante l'accesso all'applicazione.
Altri scenari
Blocco dell'accesso esterno alle applicazioni
Richiesta di criteri di protezione delle app conformi o di Intune
Applicazione dei controlli di frequenza di accesso per applicazioni specifiche
Richiesta di una workstation di accesso con privilegi per applicazioni specifiche
Richiedere controlli sessione per utenti ad alto rischio e applicazioni specifiche
Passaggi successivi
Determinare l'impatto dell'uso della modalità di accesso condizionale solo report

condizionale
Accesso condizionale: Protezione token
(anteprima)
Articolo • 25/03/2023
La protezione dei token (talvolta definita associazione di token nel settore) tenta di
ridurre gli attacchi usando il furto di token assicurando che un token sia utilizzabile solo
dal dispositivo previsto. Quando un utente malintenzionato è in grado di rubare un
token, eseguendo il hijacking o la riproduzione, può rappresentare la vittima fino alla
scadenza del token o revocarlo. Il furto di token è pensato come un evento
relativamente raro, ma il danno da esso può essere significativo.
La protezione dei token crea un legame crittografico sicuro tra il token e il dispositivo
(segreto client) a cui viene rilasciato. Senza il segreto client, il token associato è inutile.
Quando un utente registra un Windows 10 o un dispositivo più recente in Azure AD,
l'identità primaria è associata al dispositivo. Questa connessione significa che qualsiasi
token di accesso rilasciato è associato al dispositivo riducendo significativamente la
probabilità di attacchi di furto e riproduzione.
） Importante
La protezione dei token è attualmente in anteprima pubblica. Per altre informazioni

sulle anteprime, vedere Condizioni per l'utilizzo supplementari per le anteprime
di Microsoft Azure .
Con questa anteprima si offre la possibilità di creare criteri di accesso condizionale per
richiedere la protezione dei token per i token di accesso (token di aggiornamento) per
servizi specifici. Supportiamo la protezione dei token per i token di accesso in Accesso
condizionale per le applicazioni desktop che accedono a Exchange Online e SharePoint
Online nei dispositivi Windows.
７ Nota
È possibile interscambiare i token di accesso e aggiornare i token in questo

contenuto. Questa anteprima non supporta attualmente i token di accesso o i
cookie Web.
Requisiti
Questa anteprima supporta le configurazioni seguenti:
Windows 10 o versioni successive dei dispositivi aggiunti ad Azure AD, aggiunti ad

Azure AD ibrido o registrati in Azure AD.
sincronizzazione OneDrive versione client 22.217 o successiva
Client nativo di Teams versione 1.6.00.1331 o successiva
I client Perpetui di Office non sono supportati
Limitazioni note
Gli utenti esterni (Azure AD B2B) non sono supportati e non devono essere inclusi
nei criteri di accesso condizionale.
Le applicazioni seguenti non supportano l'accesso usando i flussi di token protetti
e gli utenti vengono bloccati quando si accede a Exchange e SharePoint:
Power BI Desktop client
Moduli di PowerShell che accedono agli ambiti exchange, SharePoint o
Microsoft Graph gestiti da Exchange o SharePoint
Estensione PowerQuery per Excel
Estensioni a Visual Studio Code che accedono a Exchange o SharePoint
Visual Studio
I dispositivi client Windows seguenti non sono supportati:
Windows Server
Surface Hub
Distribuzione
Per gli utenti, la distribuzione di criteri di accesso condizionale per applicare la
protezione dei token deve essere invisibile quando si usano piattaforme client
compatibili su dispositivi registrati e applicazioni compatibili.
Per ridurre al minimo la probabilità di interruzioni dell'utente a causa dell'incompatibilità

dell'app o del dispositivo, è consigliabile:
Iniziare con un gruppo pilota di utenti e espandersi nel tempo.

Creare criteri di accesso condizionale in modalità solo report prima di passare
all'applicazione della protezione dei token.
Acquisire log di accesso interattivo e non interattivo.
Analizzare questi log per un periodo sufficiente per coprire l'uso normale
dell'applicazione.
Aggiungere utenti validi noti a un criterio di imposizione.
Questo processo consente di valutare la compatibilità del client e dell'app degli utenti
per l'applicazione della protezione dei token.

Gli utenti che eseguono ruoli specializzati come quelli descritti in Livelli di sicurezza di
accesso con privilegi sono possibili destinazioni per questa funzionalità. È consigliabile
avviare la pilota con un piccolo subset.

I passaggi seguenti consentono di creare criteri di accesso condizionale per richiedere la

protezione dei token per Exchange Online e SharePoint Online nei dispositivi Windows.

a. In Includi selezionare gli utenti o i gruppi che stanno testando questo criterio.
6. In App cloud o azioni>Includiselezionare Seleziona app.
a. In Seleziona selezionare le applicazioni seguenti supportate dall'anteprima:

i. Office 365 Exchange Online
ii. Office 365 SharePoint Online
２ Avviso
I criteri di accesso condizionale devono essere configurati solo per queste
applicazioni. La selezione del gruppo di applicazioni Office 365 può
causare errori imprevisti. Si tratta di un'eccezione alla regola generale che il
gruppo di applicazioni Office 365 deve essere selezionato in un criterio di
b. Scegliere Seleziona.
7. In Condizioni:
a. In Piattaforme dispositivo:
i. Impostare Configura su Sì.
ii. Includono>Selezionare le piattaforme> del dispositivo Windows.
iii. Selezionare Fine.
b. In App client:
i. Impostare Configura su Sì.
ii. In Client di autenticazione moderni selezionare solo App per dispositivi
mobili e client desktop. Lasciare deselezionati altri elementi.
iii. Selezionare Fine.
8. In Controlli di accesso>Sessione selezionare Richiedi protezione token per le
sessioni di accesso e selezionare Seleziona.

Acquisire i log e analizzare

Monitoraggio dell'imposizione dell'accesso condizionale della protezione dei token
prima e dopo l'applicazione.
Log di accesso
Usare l'accesso ad Azure AD per verificare il risultato di un criterio di imposizione della

protezione dei token in modalità solo report o in modalità abilitata.

2. Passare ailog di accesso diAzure Active Directory>.
3. Selezionare una richiesta specifica per determinare se il criterio viene applicato o
meno.
4. Passare al riquadro Accesso condizionale o Solo report a seconda dello stato e
selezionare il nome del criterio che richiede la protezione dei token.
5. In Controlli sessione verificare se i requisiti dei criteri sono stati soddisfatti o meno.
Log Analytics
È anche possibile usare Log Analytics per eseguire query sui log di accesso (interattivi e
non interattivi) per le richieste bloccate a causa di errori di applicazione della protezione
dei token.
Ecco una query di Log Analytics di esempio che cerca i log di accesso non interattivi per
gli ultimi sette giorni, evidenziando Le richieste bloccate rispetto alle richieste
consentite da applicazione.
Kusto
//Per Apps query
// Select the log you want to query (SigninLogs or

AADNonInteractiveUserSignInLogs )
//SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName,

AppDisplayName, ResourceDisplayName
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Office 365 Exchange Online" or

ResourceDisplayName =="Office 365 SharePoint Online"
//Add userPrinicpalName if you want to filter
// | where UserPrincipalName =="<user_principal_Name>"
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains

'["Protection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and

ConditionalAccessPolicies.result !="notApplied"
| extend SessionNotSatisfyResult =
ConditionalAccessPolicies["sessionControlsNotSatisfied"]
| extend Result = case (SessionNotSatisfyResult contains 'Protection',

'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block =

countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers
= dcountif(UserPrincipalName, Result == "Block") by AppDisplayName
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2)
| sort by Requests desc
Il risultato della query precedente dovrebbe essere simile allo screenshot seguente:
Nell'esempio di query seguente viene esaminato il log di accesso non interattivo per gli
ultimi sette giorni, evidenziando Le richieste bloccate rispetto alle richieste
consentitedall'utente.
Kusto
//Per users query
// Select the log you want to query (SigninLogs or

AADNonInteractiveUserSignInLogs )
//SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName,

ResourceDisplayName
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Office 365 Exchange Online" or

ResourceDisplayName =="Office 365 SharePoint Online"
//Add userPrincipalName if you want to filter
// | where UserPrincipalName =="<user_principal_Name>"
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies.enforcedSessionControls contains

'["Protection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and

ConditionalAccessPolicies.result !="notApplied"
| extend SessionNotSatisfyResult =
ConditionalAccessPolicies.sessionControlsNotSatisfied
| extend Result = case (SessionNotSatisfyResult contains 'Protection',

'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName,

ResourceDisplayName,Result
| summarize Requests = count(),Block = countif(Result == "Block"), Allow =

countif(Result == "Allow") by UserPrincipalName,
AppDisplayName,ResourceDisplayName
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2)
| sort by UserPrincipalName asc
Passaggi successivi
Che cos'è un token di aggiornamento primario?
Uso della condizione relativa alla
posizione in un criterio di accesso
condizionale
Articolo • 03/05/2023
I criteri di accesso condizionale sono al massimo un'istruzione if-then che combina i

segnali, per prendere decisioni e applicare i criteri dell'organizzazione. Uno di questi
segnali è la posizione.
） Importante
IPv6 verrà venendo ad Azure Active Directory (Azure AD). Inizieremo a

introdurre il supporto IPv6 nei servizi di Azure AD in un approccio graduale, a
partire dal 3 aprile 2023. Le organizzazioni che usano posizioni denominate in
Accesso condizionale o Identity Protection devono intervenire per evitare possibili
effetti sul servizio.
Le organizzazioni possono usare questo percorso per attività comuni, ad esempio:
Richiedere l'autenticazione a più fattori per gli utenti che accedono a un servizio
quando si trovano fuori dalla rete aziendale.
Bloccare l'accesso per gli utenti che accedono a un servizio da paesi o aree
geografiche specifiche da cui l'organizzazione non funziona mai.
La posizione trovata usando l'indirizzo IP pubblico fornito da un client ad Azure Active

Directory o coordinate GPS fornite dall'app Microsoft Authenticator. I criteri di accesso
condizionale per impostazione predefinita si applicano a tutti gli indirizzi IPv4 e IPv6. Per
altre informazioni sul supporto IPv6, vedere l'articolo Supporto IPv6 in Azure Active
Directory.
 Suggerimento
l'accesso.
Posizioni specifiche
I percorsi sono presenti nella portale di Azure in Percorsidenominatiper l'accesso>
condizionaleper la sicurezza> di Azure Active Directory>. Questi percorsi di rete
specifici possono includere posizioni come intervalli di rete della sede centrale di
un'organizzazione, intervalli di rete VPN o intervalli che da bloccare. Le località
denominate sono definite dagli intervalli di indirizzi IPv4 e IPv6 o da paesi/aree
geografiche.
https://www.youtube-nocookie.com/embed/P80SffTIThY
Intervalli di indirizzi IPv4 e IPv6

Per definire una posizione denominata in base agli intervalli di indirizzi IPv4/IPv6, è
necessario specificare:
Nome della posizione.

Uno o più intervalli IP.
Facoltativamente , contrassegnare come percorso attendibile.
I percorsi denominati definiti dagli intervalli di indirizzi IPv4/IPv6 sono soggetti alle
limitazioni seguenti:
Configurare fino a 195 località denominate.

Configurare fino a 2000 intervalli IP per ogni località denominata.
Sono supportati entrambi gli intervalli IPv4 e IPv6.
Il numero di indirizzi IP contenuti in un intervallo è limitato. Quando si definisce un
intervallo IP, sono consentite solo maschere CIDR maggiori di /8.
Percorsi attendibili
Le posizioni, ad esempio gli intervalli di rete pubblici dell'organizzazione, possono

essere contrassegnate come attendibili. Questo contrassegno viene usato dalle
funzionalità in diversi modi.
I criteri di accesso condizionale possono includere o escludere queste posizioni.

Gli accessi da località denominate attendibili migliorano l'accuratezza del calcolo
dei rischi di Azure AD Identity Protection, riducendo il rischio di accesso di un
utente quando eseguono l'autenticazione da una posizione contrassegnata come
attendibile.
２ Avviso
Anche se si conosce la rete e la si contrassegna come attendibile, non significa che

è consigliabile escluderla dai criteri applicati. Verificare in modo esplicito sia un
principio fondamentale di un'architettura Zero Trust. Per altre informazioni su Zero
Trust e altri modi per allineare l'organizzazione ai principi guida, vedere Zero Trust
Guidance Center.
Paesi
Le organizzazioni possono determinare la posizione del paese in base all'indirizzo IP o
alle coordinate GPS.
Per definire una località denominata per paese/area geografica, è necessario specificare:
Nome della posizione.

Scegliere di determinare la posizione in base all'indirizzo IP o alle coordinate GPS.
Aggiungere uno o più paesi/aree geografiche.
Facoltativamente, scegliere Includi paesi/aree geografiche sconosciuti.
Se si seleziona Determina posizione per indirizzo IP, il sistema raccoglie l'indirizzo IP
del dispositivo a cui l'utente accede. Quando un utente accede, Azure AD risolve
l'indirizzo IPv4 o IPv6 dell'utente (a partire dal 3 aprile 2023) in un paese o area
geografica e il mapping viene aggiornato periodicamente. Le organizzazioni possono
usare località denominate definite da paesi/aree geografiche per bloccare il traffico da
paesi o aree geografiche in cui non eseguono attività aziendali.
Se si seleziona Determina posizione in base alle coordinate GPS, l'utente deve avere
installato l'app Microsoft Authenticator nel dispositivo mobile. Ogni ora, il sistema
contatta l'app Microsoft Authenticator dell'utente per raccogliere la posizione GPS del
dispositivo mobile dell'utente.
La prima volta che l'utente deve condividere la propria posizione dall'app Microsoft
Authenticator, l'utente riceve una notifica nell'app. L'utente deve aprire l'app e
concedere le autorizzazioni per la posizione. Ogni ora l'utente accede alle risorse
coperte dai criteri necessari per approvare una notifica push dall'app.
Ogni volta che l'utente condivide la propria posizione GPS, l'app esegue il rilevamento
di jailbreak (usando la stessa logica del Intune MAM SDK). Se il dispositivo è jailbroken,
la posizione non è considerata valida e all'utente non viene concesso l'accesso.
７ Nota
Un criterio di accesso condizionale con posizioni denominate basate su GPS in

modalità solo report richiede agli utenti di condividere la loro posizione GPS, anche
se non sono bloccati per l'accesso.
La posizione GPS non funziona con metodi di autenticazione senza password.
Più criteri di accesso condizionale possono richiedere agli utenti la propria posizione
GPS prima che vengano applicati tutti. A causa del modo in cui vengono applicati i
criteri di accesso condizionale, è possibile che un utente venga negato l'accesso se
supera il controllo della posizione ma non supera un altro criterio. Per altre informazioni
sull'applicazione dei criteri, vedere l'articolo Creazione di criteri di accesso condizionale.
） Importante
Gli utenti possono ricevere richieste ogni ora per sapere che Azure AD sta
controllando la propria posizione nell'app Authenticator. L'anteprima deve essere
usata solo per proteggere le app molto sensibili in cui questo comportamento è
accettabile o in cui l'accesso deve essere limitato a un paese/area geografica
specifico.
Includi paesi/aree geografiche sconosciute
Alcuni indirizzi IP non eseguono il mapping a un paese o a un'area geografica specifica.

Per acquisire queste posizioni IP, selezionare la casella Includi paesi/aree geografiche
sconosciute durante la definizione di una posizione geografica. Questa opzione
consente di scegliere se questi indirizzi IP devono essere inclusi nella posizione specifica.
Usare questa impostazione quando i criteri che usano la posizione specifica devono
essere applicati a posizioni sconosciute.
Definire le posizioni
1. Accedere al portale di Azure come amministratore dell'accesso condizionale o
amministratore della sicurezza.
2. Passare ad Azure Active Directory>Sicurezza>Accesso condizionale>Posizioni
specifiche.
3. Scegliere Nuova posizione.
4. Assegnare un nome alla posizione.
5. Scegliere Intervalli IP se si conoscono gli specifici intervalli di indirizzi IPv4
accessibili dall'esterno che fanno parte di tale posizione o di tali Paesi/aree
geografiche.
a. Specificare gli intervalli IP o selezionare i paesi/aree geografiche per la località
specificata.
Se si sceglie Paesi/aree geografiche, è possibile scegliere di includere aree
sconosciute.
6. Scegliere Salva
Condizione della posizione nei criteri

Quando si configura la condizione per la posizione, è possibile distinguere tra:
Tutti i percorsi
Tutte le località attendibili
Le località selezionate
Tutti i percorsi
Per impostazione predefinita, se si seleziona Qualsiasi posizione , un criterio viene
applicato a tutti gli indirizzi IP, ovvero a qualsiasi indirizzo su Internet. Questa
impostazione non è limitata agli indirizzi IP configurati come percorso denominato.
Quando si seleziona Tutte le località, è comunque possibile escludere percorsi specifici
dai criteri. Ad esempio, è possibile applicare dei criteri a tutte le posizioni tranne che ai
percorsi attendibili per impostare l'ambito per tutte le posizioni ad eccezione della rete
aziendale.
Tutte le località attendibili

Questa opzione si applica a:
Tutte le posizioni contrassegnate come percorsi attendibili.

Ip attendibili MFA, se configurati.
Indirizzi IP attendibili per l'autenticazione a più fattori
L'uso della sezione indirizzi IP attendibili delle impostazioni del servizio di autenticazione
a più fattori non è più consigliato. Questo controllo accetta solo indirizzi IPv4 e deve
essere usato solo per scenari specifici illustrati nell'articolo Configurare le impostazioni
di autenticazione a più fattori di Azure AD
Se si dispone di questi INDIRIZZI IP attendibili configurati, vengono visualizzati come IP

attendibili MFA nell'elenco delle posizioni per la condizione di posizione.
Le località selezionate
Con questa opzione è possibile selezionare una o più posizioni specifiche. Per applicare
criteri con questa impostazione, un utente deve connettersi da una delle posizioni
selezionate. Quando si seleziona il controllo di selezione di rete denominato che mostra
l'elenco delle reti denominate viene aperto. L'elenco mostra anche se il percorso di rete
è contrassegnato come attendibile.
Traffico IPv6
I criteri di accesso condizionale si applicano a tutto il traffico IPv4 e IPv6 (a partire dal 3
aprile 2023).
Identificazione del traffico IPv6 con i report attività di

accesso di Azure AD
È possibile individuare il traffico IPv6 nel tenant passando i report sulle attività di
accesso di Azure AD. Dopo aver aperto il report attività, aggiungere la colonna "Indirizzo
IP" e aggiungere un punto (:) al campo. Questo filtro consente di distinguere il traffico
IPv6 dal traffico IPv4.
È anche possibile trovare l'INDIRIZZO IP client facendo clic su una riga nel report e
quindi passando alla scheda "Posizione" nei dettagli dell'attività di accesso.

Informazioni utili
Proxy cloud e VPN

Quando si usa un proxy ospitato nel cloud o una soluzione VPN, l'indirizzo IP usato da
Azure AD durante la valutazione dei criteri è l'indirizzo IP del proxy. L'intestazione X-
Forwarded-For (XFF) che contiene l'indirizzo IP pubblico dell'utente non viene usata
perché non è presente alcuna convalida proveniente da un'origine attendibile, quindi
presenterebbe un metodo per la creazione di un indirizzo IP.
Quando è disponibile un proxy cloud, un criterio che richiede un dispositivo aggiunto o

conforme ad Azure AD ibrido può essere più semplice da gestire. Mantenere un elenco
di indirizzi IP usati dal proxy ospitato nel cloud o dalla soluzione VPN aggiornata può
essere quasi impossibile.
Quando viene valutata una posizione?

I criteri di accesso condizionale vengono valutati quando:
Un utente accede inizialmente a un'app Web, un'applicazione per dispositivi mobili

o un'applicazione desktop.
Un'applicazione desktop o per dispositivo mobili che usa l'autenticazione moderna
usa un token di aggiornamento per acquisire un nuovo token di accesso. Per
impostazione predefinita, questo controllo è una volta all'ora.
Questo controllo indica che le applicazioni mobili e desktop che usano l'autenticazione
moderna, viene rilevato un cambiamento nella posizione entro un'ora di modifica del
percorso di rete. Per le applicazioni mobili e desktop che non usano l'autenticazione
moderna, i criteri si applicano a ogni richiesta di token. La frequenza della richiesta può
variare in base all'applicazione. Analogamente, per le applicazioni Web, i criteri si
applicano all'accesso iniziale e sono validi per la durata della sessione nell'applicazione
Web. A causa delle differenze nella durata della sessione tra applicazioni, il tempo tra la
valutazione dei criteri varia. Ogni volta che l'applicazione richiede un nuovo token di
accesso, viene applicato il criterio.
Per impostazione predefinita, Azure AD rilascia un token su base oraria. Dopo che gli
utenti si spostano dalla rete aziendale, entro un'ora il criterio viene applicato per le
applicazioni usando l'autenticazione moderna.
Indirizzo IP utente
L'indirizzo IP usato nella valutazione dei criteri è l'indirizzo IPv4 o IPv6 pubblico
dell'utente. Per i dispositivi in una rete privata, questo indirizzo IP non è l'IP client del
dispositivo dell'utente nella intranet, è l'indirizzo usato dalla rete per connettersi a
Internet pubblico.
Quando è possibile bloccare le posizioni?

Un criterio che usa la condizione di posizione per bloccare l'accesso viene considerato
restrittivo e deve essere eseguito con attenzione dopo un test approfondito. Alcune
istanze dell'uso della condizione di posizione per bloccare l'autenticazione possono
includere:
Blocco di paesi/aree geografiche in cui l'organizzazione non esegue mai attività

aziendali.
Blocco di intervalli IP specifici, ad esempio:
Ip dannosi noti prima che sia possibile modificare i criteri del firewall.
Per azioni altamente sensibili o con privilegi e applicazioni cloud.
In base all'intervallo IP specifico dell'utente, ad esempio l'accesso alle
applicazioni di contabilità o pagamento.
I criteri di accesso condizionale sono potenti strumenti, è consigliabile escludere gli
bloccati dal tenant, è possibile usare l'account amministrativo di accesso di
emergenza per accedere al tenant per eseguire i passaggi per ripristinare l'accesso.
interattivi che non sono associati a alcun utente specifico. In genere vengono usati
dai servizi back-end che consentono l'accesso a livello di codice alle applicazioni,
ma vengono usati anche per accedere ai sistemi per scopi amministrativi. Gli
account del servizio di questo tipo dovrebbero essere esclusi poiché
l'autenticazione a più fattori non può essere eseguita a livello di codice. Le
Caricamento e download in blocco delle posizioni

specifiche
Quando si creano o si aggiornano le posizioni specifiche, per gli aggiornamenti in
blocco è possibile caricare o scaricare un file CSV con gli intervalli di indirizzi IP. Un
caricamento sostituisce gli intervalli IP nell'elenco con tali intervalli dal file. Ogni riga del
file contiene un intervallo di indirizzi IP in formato CIDR.
Supporto dell'API e PowerShell

È disponibile una versione di anteprima del API Graph per le posizioni denominate, per
altre informazioni, vedere l'API namedLocation.
Passaggi successivi
Configurare un esempio di criteri di accesso condizionale usando il percorso,
vedere l'articolo Accesso condizionale: Bloccare l'accesso in base alla posizione.
Accesso condizionale per le identità del
carico di lavoro
Articolo • 17/03/2023
I criteri di accesso condizionale sono stati applicati storicamente solo agli utenti quando
accedono ad app e servizi come SharePoint online o la portale di Azure. Ora si estende il
supporto per i criteri di accesso condizionale da applicare alle entità servizio di proprietà
dell'organizzazione. Questa funzionalità viene chiamata Accesso condizionale per le
identità del carico di lavoro.
Un'identità del carico di lavoro è un'identità che consente a un'applicazione o all'entità

servizio l'accesso alle risorse, talvolta nel contesto di un utente. Queste identità
differiscono dagli account utente tradizionali in quanto:
Non è possibile eseguire l'autenticazione a più fattori.

Spesso non hanno un processo del ciclo di vita formale.
Devono archiviare le credenziali o i segreti da qualche parte.
Queste differenze rendono le identità del carico di lavoro più difficili da gestire e le
mettono a rischio di compromissione.
） Importante
Identità dei carichi di lavoro licenze Premium sono necessarie per creare o
modificare criteri di accesso condizionale con ambito entità servizio.
Nelle directory
senza licenze appropriate, i criteri di accesso condizionale esistenti per le identità
del carico di lavoro continueranno a funzionare, ma non possono essere modificati.
Per altre informazioni, vedere Identità dei carichi di lavoro di Microsoft Entra .
７ Nota
I criteri possono essere applicati a singole entità servizio tenant registrate nel
tenant. Le app SaaS e multi-tenant di terze parti non rientrano nell'ambito. Le
identità gestite non sono coperte dai criteri.
L'accesso condizionale per le identità del carico di lavoro consente di bloccare le entità
servizio dall'esterno degli intervalli IP pubblici attendibili o in base al rischio rilevato da
Azure AD Identity Protection.
Implementazione
Creare criteri di accesso condizionale basati sulla

posizione
Creare un criterio di accesso condizionale basato sulla posizione che si applica alle entità
servizio.

a. In Cosa si applica questo criterio?, selezionare Identità del carico di lavoro.
b. In Includi scegliere Seleziona entità servizio e selezionare le entità servizio
appropriate nell'elenco.
6. In App Cloud o azioni selezionare Tutte le app Cloud. Il criterio si applica solo
quando un'entità servizio richiede un token.
7. InPosizionicondizioni> includere qualsiasi posizione ed escludere posizioni
selezionate in cui si vuole consentire l'accesso.
8. In Concedi, blocca l'accesso è l'unica opzione disponibile. L'accesso viene bloccato
quando viene eseguita una richiesta di token dall'esterno dell'intervallo consentito.
9. I criteri possono essere salvati in modalità solo report, consentendo agli
amministratori di stimare gli effetti o i criteri vengono applicati attivando i criteri.
10. Selezionare Crea per completare il criterio.
Creare criteri di accesso condizionale basati sui rischi

Creare criteri di accesso condizionale basati sul rischio che si applicano alle entità
servizio.


a. In Cosa si applica questo criterio?, selezionare Identità del carico di lavoro.
b. In Includi scegliere Seleziona entità servizio e selezionare le entità servizio
appropriate nell'elenco.
6. In App Cloud o azioni selezionare Tutte le app Cloud. Il criterio si applica solo
quando un'entità servizio richiede un token.
7. In Condizioni>Rischio entità servizio
a. Impostare l'interruttore Configura su Sì.
b. Selezionare i livelli di rischio in cui si vuole attivare questo criterio.
c. Selezionare Fine.
8. In Concedi, blocca l'accesso è l'unica opzione disponibile. L'accesso viene bloccato
quando viene eseguita una richiesta di token dall'esterno dell'intervallo consentito.
9. I criteri possono essere salvati in modalità solo report, consentendo agli
amministratori di stimare gli effetti o i criteri vengono applicati attivando i criteri.
10. Selezionare Crea per completare il criterio.
Eseguire il rollback
Se si desidera eseguire il rollback di questa funzionalità, è possibile eliminare o
disabilitare i criteri creati.
Log di accesso
I log di accesso vengono usati per esaminare la modalità di applicazione dei criteri per le
entità servizio o gli effetti previsti dei criteri quando si usa la modalità di sola report.
1. Passare aLog di accesso di>Azure Active Directory> Accesso all'entitàservizio.

2. Selezionare una voce di log e scegliere la scheda Accesso condizionale per
visualizzare le informazioni di valutazione.
Motivo di errore quando l'entità servizio è bloccata dall'accesso condizionale: "L'accesso

è stato bloccato a causa di criteri di accesso condizionale".
Per visualizzare i risultati di un criterio basato sulla posizione, fare riferimento alla
scheda Report-only degli eventi nel report di accesso o usare la cartella di lavoro
Informazioni dettagliate per l'accesso condizionale e creazione di report .
Per visualizzare i risultati di un criterio basato sui rischi, fare riferimento alla scheda
Report-only degli eventi nel report di accesso.
Riferimento
Ricerca dell'oggettoID
È possibile ottenere l'objectID dell'entità servizio da Applicazioni aziendali di Azure AD.
L'ID oggetto in Azure AD Registrazioni app non può essere usato. Questo identificatore
è l'ID oggetto della registrazione dell'app, non dell'entità servizio.
1. Passare alla portale di Azure>Azure Active Directory>Enterprise Applications,

trovare l'applicazione registrata.
2. Nella scheda Panoramica copiare l'ID oggetto dell'applicazione. Questo
identificatore è l'univoco dell'entità servizio, usato dai criteri di accesso
condizionale per trovare l'app chiamante.
Microsoft Graph
Esempio JSON per la configurazione basata sulla posizione usando l'endpoint beta di
Microsoft Graph.
JSON
"displayName": "Name",
"state": "enabled OR disabled OR enabledForReportingButNotEnforced",
"conditions": {
"applications": {
"includeApplications": [
"All"
},
"clientApplications": {
"includeServicePrincipals": [
"[Service principal Object ID] OR ServicePrincipalsInMyTenant"
],
"excludeServicePrincipals": [
"[Service principal Object ID]"
},
"locations": {
"includeLocations": [
"All"
],
"excludeLocations": [
"[Named location ID] OR AllTrusted"
},
"grantControls": {
"operator": "and",
"builtInControls": [
"block"
Passaggi successivi
Uso della condizione relativa alla posizione in un criterio di accesso condizionale
Accesso condizionale: accesso a livello di codice
Cos'è la modalità solo report dell'accesso condizionale?
Valutazione continua dell'accesso
Articolo • 21/03/2023
La scadenza e l'aggiornamento dei token sono un meccanismo standard del settore. Quando
un'applicazione client come Outlook si connette a un servizio come Exchange Online, le richieste API
vengono autorizzate usando i token di accesso OAuth 2.0. Per impostazione predefinita, i token di
accesso sono validi per un'ora, quando scadono il client viene reindirizzato ad Azure AD per aggiornarli.
Tale periodo di aggiornamento offre la possibilità di rivalutare i criteri per l'accesso degli utenti. Ad
esempio, è possibile scegliere di non aggiornare il token a causa di un criterio di accesso condizionale o
perché l'utente è stato disabilitato nella directory.
I clienti hanno espresso preoccupazioni sul ritardo tra quando le condizioni cambiano per un utente e
quando vengono applicate le modifiche ai criteri. Azure AD ha sperimentato l'approccio "blunt object"
delle durate dei token ridotte, ma ha scoperto che possono ridurre le esperienze utente e l'affidabilità
senza eliminare i rischi.
Una risposta tempestiva alle violazioni dei criteri o ai problemi di sicurezza richiede realmente una
"conversazione" tra l'emittente del token (Azure AD) e la relying party (app abilitate). Questa
conversazione bidirezionale offre due importanti funzionalità. La relying party può vedere quando le
proprietà cambiano, ad esempio il percorso di rete, e comunicarlo all'autorità di certificazione del token.
Inoltre offre all’autorità di certificazione del token un modo per indicare alla relying party di
interrompere il rispetto dei token per un determinato utente a causa di una compromissione o
disabilitazione dell'account o di altri problemi. Il meccanismo per questa conversazione è la valutazione
dell'accesso continuo (continuous access evaluation, CAE). L'obiettivo per la valutazione critica degli
eventi è la risposta quasi in tempo reale, ma la latenza fino a 15 minuti può essere osservata a causa del
tempo di propagazione degli eventi; Tuttavia, l'applicazione dei criteri delle posizioni IP è immediata.
L'implementazione iniziale della valutazione continua dell'accesso è incentrata su Exchange, Teams e

SharePoint Online.
Per preparare le applicazioni per l'uso di CAE, vedere Come usare le API abilitate per la valutazione
dell'accesso continuo nelle applicazioni.
La valutazione dell'accesso continuo è disponibile nei tenant di Azure per enti pubblici (GCC High e
DOD) per Exchange Online.
Vantaggi principali
Cessazione dell’utente o modifica/reimpostazione della password: la revoca della sessione utente
verrà applicata quasi in tempo reale.
Modifica del percorso di rete: i criteri dei percorsi di accesso condizionale verranno applicati quasi
in tempo reale.
L'esportazione di token in un computer esterno a una rete attendibile può essere impedita con i
criteri dei percorsi di accesso condizionale.
Scenari
Esistono due scenari che costituiscono la valutazione continua dell'accesso, la valutazione critica degli
eventi e la valutazione dei criteri di accesso condizionale.
Valutazione degli eventi critici

La valutazione dell'accesso continuo viene implementata abilitando i servizi, ad esempio Exchange
Online, SharePoint Online e Teams, per sottoscrivere eventi critici di Azure AD. Tali eventi possono quindi
essere valutati e applicati quasi in tempo reale. La valutazione degli eventi critici non si basa sui criteri di
accesso condizionale, quindi è disponibile in qualsiasi tenant. Gli eventi seguenti vengono attualmente
valutati:
L'account utente viene eliminato o disabilitato

La password per un utente viene modificata o reimpostata
L'autenticazione a più fattori è abilitata per l'utente
L'amministratore revoca in modo esplicito tutti i token di aggiornamento per un utente
Rischio utente elevato rilevato da Azure AD Identity Protection
Questo processo consente agli utenti di perdere l'accesso ai file di SharePoint Online
dell'organizzazione, alla posta elettronica, al calendario o alle attività e alle app client di Teams da
Microsoft 365 entro pochi minuti da un evento critico.
７ Nota
SharePoint Online non supporta gli eventi di rischio utente.
Valutazione dei criteri di accesso condizionale

Exchange Online, SharePoint Online, Teams e MS Graph possono sincronizzare i criteri di accesso
condizionale chiave per la valutazione all'interno del servizio stesso.
Questo processo abilita lo scenario in cui gli utenti perdono l'accesso ai file dell'organizzazione, alla
posta elettronica, al calendario o alle attività dalle app client di Microsoft 365 o da SharePoint Online
subito dopo la modifica del percorso di rete.
７ Nota
Non tutte le combinazioni di app client e provider di risorse sono supportate. Vedere le tabelle
seguenti. La prima colonna di questa tabella si riferisce alle applicazioni Web avviate tramite Web
browser ,ad esempio PowerPoint avviato nel Web browser, mentre le altre quattro colonne fanno
riferimento alle applicazioni native in esecuzione in ogni piattaforma descritta. Inoltre, i riferimenti a
"Office" includono Word, Excel e PowerPoint.
Outlook Web Outlook Win32 Outlook iOS Outlook Android Outlook Mac
SharePoint Online Supportato Supportato Supportato Supportato Supportato
Exchange Online Supportato Supportato Supportato Supportato Supportato

App Web di App Di Office Office per Office per Office per
Office Win32 iOS Android Mac
SharePoint Non supportato * Supportato Supportato Supportato Supportato

Online
Exchange Online Non supportato Supportato Supportato Supportato Supportato
Web OneDrive OneDrive Win32 OneDrive iOS OneDrive Android OneDrive Mac
SharePoint Online Supportato Non supportato Supportato Supportato Non supportato
Web di Teams Teams Win32 Teams iOS Teams Android Teams Mac
Servizio Parzialmente Parzialmente Parzialmente Parzialmente Parzialmente

Teams supportato supportato supportato supportato supportato
SharePoint Parzialmente Parzialmente Parzialmente Parzialmente Parzialmente

Online supportato supportato supportato supportato supportato
Exchange Parzialmente Parzialmente Parzialmente Parzialmente Parzialmente

Online supportato supportato supportato supportato supportato
* La durata dei token per le app Web di Office viene ridotta a 1 ora quando viene impostato un
criterio di accesso condizionale.
７ Nota
Teams è costituito da più servizi e tra questi i servizi di chiamata e chat non rispettano i criteri di
accesso condizionale basati su IP.
Funzionalità client
Richiesta di attestazione lato client

Prima della valutazione dell'accesso continuo, i client riprodurrebbero il token di accesso dalla cache
purché non fosse scaduto. Con l'autorità di certificazione viene presentato un nuovo caso in cui un
provider di risorse può rifiutare un token quando non è scaduto. Per informare i client di ignorare la
cache anche se i token memorizzati nella cache non sono scaduti, viene presentato un meccanismo
denominato richiesta di richiesta per indicare che il token è stato rifiutato e che è necessario rilasciare
un nuovo token di accesso da Azure AD. L'autorità di certificazione richiede un aggiornamento client per
comprendere la richiesta di attestazione. La versione più recente delle applicazioni seguenti supporta la
richiesta di attestazione:
Web Win32 iOS Android Mac
Outlook Supportato Supportato Supportato Supportato Supportato
Teams Supportato Supportato Supportato Supportato Supportato

Web Win32 iOS Android Mac
Ufficio Non supportato Supportato Supportato Supportato Supportato
OneDrive Supportato Supportato Supportato Supportato Supportato
Durata dei token

Poiché i criteri e i rischi vengono valutati in tempo reale, i client che negoziano sessioni di valutazione
dell'accesso continuo non si basano più sui criteri di durata del token di accesso statico. Questa
modifica significa che i criteri di durata del token configurabili non sono onorati per i client che
negoziano sessioni con riconoscimento CAE.
La durata del token è aumentata fino a 28 ore nelle sessioni CAE. La revoca è basata su eventi critici e
valutazione dei criteri, non solo da un periodo di tempo arbitrario. Questa modifica aumenta la stabilità
delle applicazioni senza influire sul comportamento di sicurezza.
Se non si usano client compatibili con CAE, la durata predefinita del token di accesso rimarrà 1 ora.
L'impostazione predefinita cambia solo se è stata configurata la durata del token di accesso con la
funzionalità di anteprima del token configurabile (CTL).
Diagrammi di flusso di esempio
Flusso di eventi di revoca utente

1. Un client con funzionalità CAE presenta le credenziali o un token di aggiornamento ad Azure AD
che richiede un token di accesso per una risorsa.
2. Un token di accesso viene restituito insieme ad altri artefatti al client.
3. Un amministratore revoca in modo esplicito tutti i token di aggiornamento per l'utente. Un evento
di revoca verrà inviato al provider di risorse da Azure AD.
4. Viene presentato un token di accesso al provider di risorse. Il provider di risorse valuta la validità
del token e verifica se è presente un evento di revoca per l'utente. Il provider di risorse usa queste
informazioni per decidere di concedere o meno l'accesso alla risorsa.
5. In questo caso, il provider di risorse nega l'accesso e invia una richiesta di attestazione 401+ al
client.
6. Il client abilitato per CAE riconosce il test di attestazione 401+. Ignora le cache e torna al passaggio
1, inviando il token di aggiornamento insieme al test di attestazione ad Azure AD. Azure AD
rivaluta quindi tutte le condizioni e chiede all'utente di ripetere l'autenticazione in questo caso.
Flusso di modifica della condizione utente

Nell'esempio seguente un amministratore di accesso condizionale ha configurato un criterio di accesso
condizionale basato sulla posizione per consentire l'accesso solo da intervalli IP specifici:
1. Un client con funzionalità CAE presenta le credenziali o un token di aggiornamento ad Azure AD
che richiede un token di accesso per una risorsa.
2. Azure AD valuta tutti i criteri di accesso condizionale per verificare se l'utente e il client soddisfano
le condizioni.
3. Un token di accesso viene restituito insieme ad altri artefatti al client.
4. L'utente esce da un intervallo IP consentito.
5. Il client presenta un token di accesso al provider di risorse dall'esterno di un intervallo IP
consentito.
6. Il provider di risorse valuta la validità del token e controlla i criteri di posizione sincronizzati da
Azure AD.
7. In questo caso, il provider di risorse nega l'accesso e invia una richiesta di attestazione 401+ al
client. Il client viene contestato perché non proviene da un intervallo IP consentito.
8. Il client abilitato per CAE riconosce il test di attestazione 401+. Ignora le cache e torna al passaggio
1, inviando il token di aggiornamento insieme al test di attestazione ad Azure AD. Azure AD
rivaluta tutte le condizioni e nega l'accesso in questo caso.
Abilitare o disabilitare l'autorità di certificazione

L'impostazione di Valutazione continua dell'accesso è stata spostata nel pannello Accesso condizionale. I
nuovi clienti di Valutazione continua dell'accesso possono accedere e attivare o disattivare Valutazione
continua dell'accesso direttamente durante la creazione dei criteri di accesso condizionale. Tuttavia,
alcuni clienti esistenti dovranno eseguire la migrazione prima di poter accedere alla funzionalità
Valutazione continua dell'accesso tramite l'accesso condizionale.
Migrazione
I clienti che hanno configurato le impostazioni CAE in Sicurezza prima di dover eseguire la migrazione
delle impostazioni a un nuovo criterio di accesso condizionale. Seguire questa procedura per eseguire la
migrazione delle impostazioni CAE a un criterio di accesso condizionale.
1. Accedere alla portale di Azure come amministratore di accesso condizionale, amministratore della
sicurezza o amministratore globale.
2. Passare allavalutazione dell'accesso continuo allasicurezza> di Azure Active Directory>.
3. Verrà quindi visualizzata l'opzione Migrazione dei criteri. Questa azione è l'unica a cui si avrà
accesso a questo punto.
4. Passare all'accesso condizionale e si troverà un nuovo criterio denominato Criteri di accesso
condizionale creati dalle impostazioni CAE con le impostazioni configurate. Gli amministratori
possono scegliere di personalizzare questo criterio o crearne uno per sostituirlo.
La tabella seguente descrive l'esperienza di migrazione di ogni gruppo di clienti in base alle
impostazioni CAE configurate in precedenza.
Impostazione CAE È Abilitazione Esperienza di migrazione prevista

esistente necessaria automatica
la per CAE
migrazione
Nuovi tenant che non No Sì L'impostazione CAE precedente verrà nascosta in quanto
hanno configurato probabilmente questi clienti non hanno visto l'esperienza
nulla nell'esperienza prima della disponibilità generale.
precedente.
Tenant abilitati in No Sì L'impostazione CAE precedente verrà disattivata. Poiché

modo esplicito per questi clienti hanno abilitato in modo esplicito questa
tutti gli utenti con impostazione per tutti gli utenti, non devono eseguire la
l'esperienza migrazione.
precedente.
Tenant che hanno Sì No Le impostazioni CAE precedenti verranno disattivate. Facendo

abilitato in modo clic su Migrate viene avviata la nuova procedura guidata
esplicito alcuni utenti criteri di accesso condizionale, che include Tutti gli utenti,
nei propri tenant con escludendo utenti e gruppi copiati da CAE. Imposta anche il
l'esperienza nuovo controllo Personalizza sessione di valutazione
precedente. dell'accesso continuo su Disabilitato.
Impostazione CAE È Abilitazione Esperienza di migrazione prevista
esistente necessaria automatica
la per CAE
migrazione
Tenant che hanno Sì No Le impostazioni CAE precedenti verranno disattivate. Facendo

disabilitato in modo clic su Migrate viene avviata la nuova procedura guidata
esplicito l'anteprima. criteri di accesso condizionale, che include Tutti gli utenti e
imposta il nuovo controllo Personalizza sessione di
valutazione dell'accesso continuo su Disabilitato.
Altre informazioni sulla valutazione dell'accesso continuo come controllo sessione sono disponibili nella
sezione Personalizzare la valutazione dell'accesso continuo.
Limitazioni
Tempo effettivo per l'appartenenza al gruppo e l'aggiornamento dei

criteri
Le modifiche apportate ai criteri di accesso condizionale e all'appartenenza al gruppo apportate dagli
amministratori potrebbero richiedere fino a un giorno per essere effettive. Il ritardo è dalla replica tra
Azure AD e provider di risorse, ad esempio Exchange Online e SharePoint Online. Alcune ottimizzazioni
sono state eseguite per gli aggiornamenti dei criteri, che riducono il ritardo a due ore. Tuttavia, non
copre ancora tutti gli scenari.
Quando i criteri di accesso condizionale o le modifiche di appartenenza ai gruppi devono essere

applicati immediatamente a determinati utenti, sono disponibili due opzioni.
Eseguire il comando rev-mgusersign PowerShell per revocare tutti i token di aggiornamento di un

utente specificato.
Selezionare "Revoca sessione" nella pagina del profilo utente nel portale di Azure per revocare la
sessione dell'utente per assicurarsi che i criteri aggiornati vengano applicati immediatamente.
Variazione di indirizzi IP e reti con indirizzi IP condivisi o in uscita

sconosciuti
Le reti moderne ottimizzano spesso i percorsi di connettività e di rete per le applicazioni in modo
diverso. Questa ottimizzazione causa spesso variazioni degli indirizzi IP di routing e origine delle
connessioni, come illustrato dal provider di identità e dai provider di risorse. È possibile osservare questa
variazione di percorso di divisione o di indirizzo IP in più topologie di rete, incluse, ma non limitate a:
Proxy locali e basati sul cloud.

Implementazioni della rete privata virtuale (VPN), ad esempio il tunneling diviso.
Distribuzioni della rete wide area (SD-WAN) definite dal software.
Topologie di rete con carico bilanciato o ridondante, ad esempio quelle che usano SNAT .
Distribuzioni di succursali che consentono la connettività Internet diretta per applicazioni
specifiche.
Reti che supportano i client IPv6.
Altre topologie, che gestiscono il traffico delle applicazioni o delle risorse in modo diverso dal
traffico al provider di identità.
Oltre alle variazioni IP, i clienti possono anche usare soluzioni e servizi di rete che:
Usare gli indirizzi IP che possono essere condivisi con altri clienti. Ad esempio, i servizi proxy basati
sul cloud in cui gli indirizzi IP in uscita vengono condivisi tra i clienti.
Usare facilmente indirizzi IP diversi o indefinibili. Ad esempio, le topologie in cui sono presenti set
dinamici di indirizzi IP in uscita di grandi dimensioni usati, ad esempio scenari aziendali di grandi
dimensioni o suddivisione del traffico di rete in uscita e in uscita locale.
Le reti in cui gli indirizzi IP in uscita possono cambiare spesso o sono condivisi possono influire
sull'accesso condizionale di Azure AD e continua la valutazione dell'accesso (CAE). Questa variabilità può
influire sul funzionamento di queste funzionalità e sulle relative configurazioni consigliate. Il tunneling di
divisione può causare blocchi imprevisti anche quando un ambiente è configurato usando procedure
consigliate per il tunneling VPN split. Il routing degli indirizzi IP ottimizzati tramite un indirizzo IP/VPN
attendibile può essere necessario per evitare blocchi correlati a "insufficient_claims" o "Controllo
applicazione IP immediata non riuscita".
La tabella seguente riepiloga i comportamenti e le raccomandazioni relative alle funzionalità di accesso

condizionale e caE per diversi tipi di distribuzioni di rete:
Tipo di rete Esempio Ip Ip Configurazione Applicazione Token di Consigli

visualizzati visualizzati CA applicabile dell'autorità accesso
da Azure da RP (posizione di CAE
AD denominata certificazione
attendibile)
1. Gli indirizzi IP Tutto il 1.1.1.1 2.2.2.2 1.1.1.1

Eventi critici
Lunga Se vengono
in uscita sono traffico di 2.2.2.2 Modifiche alla durata - definiti
dedicati ed rete verso posizione IP fino a 28 percorsi
enumerabili sia Azure AD ore denominati
per il traffico di e gli dalla CA,
Azure AD che per indirizzi assicurarsi
tutti i provider di IP in che
servizi di dominio uscita contengano
tramite tutti gli
1.1.1.1 INDIRIZZI IP
e/o in uscita
2.2.2.2.2 possibili
(visualizzati
da Azure AD
e tutti gli
indirizzi IP)
Tipo di rete Esempio Ip Ip Configurazione Applicazione Token di Consigli
visualizzati visualizzati CA applicabile dell'autorità accesso
da Azure da RP (posizione di CAE
AD denominata certificazione
attendibile)
2. Gli INDIRIZZI Traffico di 1.1.1.1 x.x.x.x 1.1.1.1 Eventi critici Durata del Non
IP in uscita sono rete verso token di aggiungere
dedicati ed Azure AD accesso indirizzi IP
enumerabili per in uscita predefinito non dedicati
Azure AD, ma fino alla - 1 ora o non
non per il traffico versione enumerabili
degli indirizzi IP 1.1.1.1. (x.x.x.x.x) in
Traffico regole di
RP in accesso
uscita condizionale
tramite con nome
x.x.x.x.x attendibile
in quanto
può
indebolire la
sicurezza
3. Gli indirizzi IP Traffico di y.y.y.y x.x.x.x N/A -no criteri Eventi critici Lunga Non
in uscita non rete ad CA IP/Percorsi durata - aggiungere
sono Azure AD attendibili fino a 28 indirizzi IP
dedicati/condivisi in uscita configurati ore non dedicati
o non tramite o non
enumerabili per il y.y.y.y. enumerabili
traffico di Azure Traffico (x.x.x/y.y.y.y)
AD e RPS RP in in regole CA
uscita denominate
attraverso attendibili in
x.x.x.x.x quanto può
indebolire la
sicurezza
Le reti e i servizi di rete usati dai client che si connettono a provider di identità e risorse continuano a
evolversi e cambiare in risposta alle tendenze moderne. Queste modifiche possono influire sulle
configurazioni dell'accesso condizionale e dell'autorità di certificazione che si basano sugli indirizzi IP
sottostanti. Quando si decide su queste configurazioni, fattore nelle modifiche future nella tecnologia e
nel ripristino dell'elenco di indirizzi definito nel piano.
Criteri di posizione supportati

CAE include solo informazioni dettagliate sulle posizioni denominate basate su IP. L'autorità di
certificazione non ha informazioni dettagliate su altre condizioni di posizione, ad esempio indirizzi IP
attendibili MFA o posizioni basate sul paese. Quando un utente proviene da un indirizzo IP attendibile
MFA, una posizione attendibile che include indirizzi IP attendibili MFA o posizione del paese, l'autorità di
certificazione non verrà applicata dopo che l'utente si sposta in una posizione diversa. In questi casi
Azure AD emetterà un token di accesso di un'ora senza controllare l'applicazione immediata dell'ip.
） Importante
Se si desidera che i criteri di posizione vengano applicati in tempo reale dalla valutazione
dell'accesso continuo, usare solo la condizione di posizione dell'accesso condizionale basato su IP
e configurare tutti gli indirizzi IP, inclusi IPv4 e IPv6, che possono essere visualizzati dal provider di
identità e dal provider di risorse. Non usare le condizioni di località paese/area geografica o la
funzionalità ips attendibile disponibile nella pagina delle impostazioni del servizio di Azure AD
Multifactor Authentication.
Limitazioni relative alla posizione denominata

Quando la somma di tutti gli intervalli IP specificati nei criteri di posizione supera i 5.000, il flusso della
posizione di modifica utente non verrà applicato da CAE in tempo reale. In questo caso, Azure AD
emetterà un token CAE di un'ora. CaE continuerà ad applicare tutti gli altri eventi e criteri oltre a eventi
di modifica della posizione client. Con questa modifica, si mantiene comunque un comportamento di
sicurezza più elevato rispetto ai token tradizionali di un'ora, poiché altri eventi verranno valutati quasi in
tempo reale.
Impostazioni di Office e Web Account Manager
Canale di aggiornamento DisableADALatopWAMOverride DisableAADWAM

di Office
Canale Enterprise Se impostato su abilitato o 1, CAE non Se impostato su abilitato o 1, CAE non
semestrale sarà supportato. sarà supportato.
Canale corrente
CaE è supportato indipendentemente CaE è supportato indipendentemente
oppure
dall'impostazione dall'impostazione
Canale Enterprise mensile
Per una spiegazione dei canali di aggiornamento di Office, vedere Panoramica dei canali di
aggiornamento per Microsoft 365 Apps. È consigliabile che le organizzazioni non disabilitino Web
Account Manager (WAM).
Creazione condivisa nelle app di Office

Quando più utenti collaborano contemporaneamente a un documento, l'accesso al documento
potrebbe non essere immediatamente revocato da CAE in base agli eventi di modifica dei criteri. In
questo caso, l'utente perde completamente l'accesso dopo:
Chiusura del documento

Chiusura dell'app office
Dopo 1 ora in cui viene impostato un criterio IP di accesso condizionale
Per ridurre ulteriormente questo tempo, un amministratore di SharePoint può ridurre la durata massima
delle sessioni di creazione condivisa per i documenti archiviati in SharePoint Online e OneDrive for
Business, configurando i criteri dei percorsi di rete in SharePoint Online. Una volta modificata questa
configurazione, la durata massima delle sessioni di creazione condivisa verrà ridotta a 15 minuti e può
essere modificata ulteriormente usando il comando PowerShell di SharePoint Online "Set-SPOTenant –
IPAddressWACTokenLifetime".
Abilitare dopo che un utente è disabilitato
Se si abilita un utente subito dopo la disabilitazione, si verifica una certa latenza prima che l'account
venga riconosciuto come abilitato nei servizi Microsoft downstream.
SharePoint Online e Teams hanno in genere un ritardo di 15 minuti.

Exchange Online in genere ha un ritardo di 35-40 minuti.
Notifiche push
I criteri degli indirizzi IP non vengono valutati prima del rilascio delle notifiche push. Questo scenario
esiste perché le notifiche push sono in uscita e non hanno un indirizzo IP associato per la valutazione. Se
un utente seleziona tale notifica push, ad esempio un messaggio di posta elettronica in Outlook, i criteri
di indirizzo IP caE vengono ancora applicati prima che il messaggio di posta elettronica possa essere
visualizzato. Le notifiche push visualizzano un'anteprima dei messaggi, che non è protetta da un criterio
di indirizzo IP. Tutti gli altri controlli CAE vengono eseguiti prima dell'invio della notifica push. Se un
utente o un dispositivo ha accesso rimosso, l'imposizione viene eseguita entro il periodo documentato.
Utenti guest
Gli account utente guest non sono supportati da CAE. Gli eventi di revoca cae e i criteri di accesso
condizionale basati su IP non vengono applicati immediatamente.
Come funziona CAE con frequenza di accesso?

La frequenza di accesso verrà rispettata con o senza CAE.
Passaggi successivi
Come usare le API abilitate per la valutazione dell'accesso continuo nelle applicazioni
Problematiche delle attestazioni, richieste di attestazioni e funzionalità client
Accesso condizionale: sessione
Monitorare la valutazione continua dell'accesso e risolvere i problemi
Valutazione continua dell'accesso per le
identità del carico di lavoro (anteprima)
Articolo • 01/06/2023
La valutazione dell'accesso continuo (CAE) per le identità del carico di lavoro offre
vantaggi per la sicurezza per l'organizzazione. Consente l'applicazione in tempo reale
dei criteri di posizione e rischio di accesso condizionale, insieme all'applicazione
immediata degli eventi di revoca dei token per le identità dei carichi di lavoro.
La valutazione di accesso continuo non supporta attualmente le identità gestite.
Ambito dell'anteprima
L'ambito di anteprima pubblica delle identità di accesso continuo per le identità del
carico di lavoro include il supporto per Microsoft Graph come provider di risorse.
Le entità servizio di anteprima sono destinate alle applicazioni line of business (LOB).
Sono supportati gli eventi di revoca seguenti:
Disabilita entità servizio

Eliminazione dell'entità servizio
Rischio entità servizio elevato rilevato da Azure AD Identity Protection
La valutazione di accesso continuo per le identità del carico di lavoro supporta i criteri di
accesso condizionale destinati alla posizione e al rischio.
Abilitare l'applicazione
Gli sviluppatori possono acconsentire esplicitamente alla valutazione di accesso
continuo per le identità del carico di lavoro quando le richieste xms_cc API sono
un'attestazione facoltativa. L'attestazione xms_cc con un valore di nel token di cp1
accesso è il modo autorevole per identificare un'applicazione client in grado di gestire
una richiesta di attestazioni. Per altre informazioni su come lavorare nell'applicazione,
vedere l'articolo Attestazioni, richieste di attestazioni e funzionalità client.
Disabilita
Per rifiutare esplicitamente, non inviare l'attestazione xms_cc con un valore di cp1 .
Le organizzazioni che dispongono di Azure AD Premium possono creare criteri di
accesso condizionale per disabilitare la valutazione dell'accesso continuo applicata a
identità del carico di lavoro specifiche come misura immediata di stop-gap.
Risoluzione dei problemi

Quando l'accesso di un client a una risorsa viene bloccato a causa dell'attivazione
dell'autorità di certificazione, la sessione del client verrà revocata e il client dovrà
ripetere l'autenticazione. Questo comportamento può essere verificato nei log di
accesso.
I passaggi seguenti illustrano in dettaglio come un amministratore può verificare

l'attività di accesso nei log di accesso:

2. Passare ad Azure Active Directory>Sign-in logs>Service Principal Sign-ins. È
possibile usare filtri per semplificare il processo di debug.
3. Selezionare una voce per visualizzare i dettagli dell'attività. Il campo Valutazione di
accesso continuo indica se è stato rilasciato un token CAE in un particolare
tentativo di accesso.
Passaggi successivi
Registrare un'applicazione con Azure AD e creare un'entità servizio
Come usare le API abilitate per la valutazione dell'accesso continuo nelle
applicazioni
Applicazione di esempio che usa la valutazione continua dell'accesso
Che cos'è la valutazione dell'accesso continuo?
Accesso condizionale: filtro per i
dispositivi
Articolo • 10/03/2023
Quando si creano criteri di accesso condizionale, gli amministratori hanno chiesto la

possibilità di specificare o escludere dispositivi specifici nel proprio ambiente. L'opzione
Filtra per dispositivi della condizione offre questa possibilità agli amministratori. È ora
possibile specificare come destinazione dispositivi specifici usando operatori e proprietà
supportati per i filtri dei dispositivi e le altre condizioni di assegnazione disponibili nei
Scenari comuni
Esistono più scenari che le organizzazioni possono ora abilitare usando il filtro per le
condizioni dei dispositivi. Gli scenari seguenti forniscono esempi di come usare questa
nuova condizione.
Limitare l'accesso alle risorse con privilegi. Per questo esempio, si supponga di
voler consentire l'accesso a Gestione di Microsoft Azure da un utente a cui è
assegnato un ruolo con privilegi Amministratore globale, abbia soddisfatto
l'autenticazione a più fattori e l'accesso da un dispositivo con privilegi o
workstation amministrative sicure e attestato come conforme. Per questo scenario,
le organizzazioni creerebbero due criteri di accesso condizionale:
Criterio 1: tutti gli utenti con il ruolo di directory amministratore globale,
l'accesso all'app cloud di gestione di Microsoft Azure e per i controlli di accesso,
Concedere l'accesso, ma richiedono l'autenticazione a più fattori e richiedono
che il dispositivo sia contrassegnato come conforme.
Criterio 2: tutti gli utenti con il ruolo di directory amministratore globale,
l'accesso all'app cloud di gestione di Microsoft Azure, escluso un filtro per i
dispositivi che usano l'espressione regola device.extensionAttribute1 è uguale a
SAW e per i controlli di accesso, Blocca. Informazioni su come aggiornare
extensionAttributes in un oggetto dispositivo di Azure AD.
Bloccare l'accesso alle risorse dell'organizzazione dai dispositivi che eseguono
un sistema operativo non supportato. Per questo esempio, si supponga di voler
bloccare l'accesso alle risorse dalla versione del sistema operativo Windows
precedente a Windows 10. Per questo scenario, le organizzazioni creerebbero i
criteri di accesso condizionale seguenti:
Tutti gli utenti, che accedono a tutte le app cloud, escludendo un filtro per i
dispositivi che usano l'espressione regola device.operatingSystem è uguale a
Windows e device.operatingSystemVersion avviaWith "10.0" e per i controlli di
accesso, Blocca.
Non richiedere l'autenticazione a più fattori per account specifici in dispositivi
specifici. Per questo esempio, si supponga di non richiedere l'autenticazione a più
fattori quando si usano account di servizio in dispositivi specifici, ad esempio
telefoni Teams o dispositivi Surface Hub. Per questo scenario, le organizzazioni
creerebbero i due criteri di accesso condizionale seguenti:
Criterio 1: tutti gli utenti esclusi gli account del servizio, l'accesso a tutte le app
cloud e per i controlli di accesso, Concedere l'accesso, ma richiedere
Criterio 2: selezionare utenti e gruppi e includere il gruppo che contiene solo gli
account del servizio, l'accesso a tutte le app cloud, escluso un filtro per i
dispositivi che usano l'espressione regola device.extensionAttribute2 non è
uguale a TeamsPhoneDevice e per i controlli di accesso, Blocca.
７ Nota
Azure AD usa l'autenticazione del dispositivo per valutare le regole di filtro dei
dispositivi. Per un dispositivo che non è registrato con Azure AD, tutte le proprietà
del dispositivo vengono considerate come valori Null e gli attributi del dispositivo
non possono essere determinati perché il dispositivo non esiste nella directory. Il
modo migliore per impostare come destinazione i criteri per i dispositivi non
registrati consiste nell'usare l'operatore negativo perché la regola di filtro
configurata verrebbe applicata. Se si usasse un operatore positivo, la regola di filtro
verrà applicata solo quando un dispositivo esiste nella directory e la regola
configurata corrisponde all'attributo nel dispositivo.

Il filtro per i dispositivi è un'opzione quando si creano criteri di accesso condizionale nel
portale di Azure o si usa microsoft API Graph.
La procedura seguente consentirà di creare due criteri di accesso condizionale per

supportare il primo scenario in Scenari comuni.
Criterio 1: tutti gli utenti con il ruolo di directory amministratore globale, l'accesso
all'app cloud di gestione di Microsoft Azure e per i controlli di accesso, Concedere
l'accesso, ma richiedono l'autenticazione a più fattori e richiedono che il dispositivo sia
contrassegnato come conforme.

a. In Includi selezionare Ruoli directory e scegliere Amministratore globale.
２ Avviso
I criteri di accesso condizionale supportano ruoli predefiniti. I criteri di

accesso condizionale non vengono applicati per altri tipi di ruolo, inclusi i
ruolicon ambito unità amministrativa o personalizzati.


6. In App cloud o azioni>Includiselezionare Seleziona app e selezionare Gestione di
Microsoft Azure.
7. In Controlli> di accessoConcedi selezionare Concedi accesso, Richiedi
autenticazione a più fattori e Richiedi che il dispositivo sia contrassegnato come
conforme e quindi seleziona Seleziona.
8. Confermare le impostazioni e impostare Abilita criterio su Attivato.
9. Selezionare Crea per creare e abilitare i criteri.
Criterio 2: tutti gli utenti con il ruolo di directory amministratore globale, l'accesso
all'app cloud di gestione di Microsoft Azure, escluso un filtro per i dispositivi che usano
l'espressione regola device.extensionAttribute1 è uguale a SAW e per i controlli di
accesso, Blocca.

a. In Includi selezionare Ruoli directory e scegliere Amministratore globale.
２ Avviso



4. In App cloud o azioni>Includiselezionare Seleziona app e selezionare Gestione di
Microsoft Azure.
5. In Condizionifiltrare i dispositivi.
a. Attiva/ disattiva Configura su Sì.
b. Impostare Dispositivi che corrispondono alla regola su Escludi i dispositivi
filtrati dai criteri.
c. Impostare la proprietà su ExtensionAttribute1 , l'operatore su Equals e il valore
su SAW .
d. Selezionare Fine.
6. In Controlli di accesso>Concedi selezionare Blocca accesso, quindi Seleziona.
7. Confermare le impostazioni e impostare Abilita criterio su Attivato.
Impostazione dei valori degli attributi
L'impostazione degli attributi di estensione è resa possibile tramite il API Graph. Per altre
informazioni sull'impostazione degli attributi del dispositivo, vedere l'articolo
Aggiornare il dispositivo.
Filtrare i dispositivi API Graph

Il filtro per l'API dei dispositivi è disponibile nell'endpoint di Microsoft Graph v1.0 ed è
accessibile usando l'endpoint
https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/ . È possibile
configurare un filtro per i dispositivi quando si crea un nuovo criterio di accesso
condizionale oppure è possibile aggiornare un criterio esistente per configurare il filtro
per la condizione dei dispositivi. Per aggiornare un criterio esistente, è possibile eseguire
una chiamata di patch nell'endpoint di Microsoft Graph v1.0 aggiungendo l'ID criterio di
un criterio esistente ed eseguendo il corpo della richiesta seguente. L'esempio seguente
mostra la configurazione di un filtro per le condizioni dei dispositivi esclusi i dispositivi
che non sono contrassegnati come dispositivi SAW. La sintassi della regola può essere
costituita da più di una singola espressione. Per altre informazioni sulla sintassi, vedere
Regole di appartenenza dinamica per i gruppi in Azure Active Directory.
JSON
"conditions": {
"devices": {
"deviceFilter": {
"mode": "exclude",
"rule": "device.extensionAttribute1 -ne \"SAW\""
Operatori supportati e proprietà dei dispositivi

per i filtri
Gli attributi del dispositivo seguenti possono essere usati con il filtro per le condizioni
dei dispositivi nell'accesso condizionale.
７ Nota
Azure AD usa l'autenticazione del dispositivo per valutare le regole di filtro dei
dispositivi. Per un dispositivo che non è registrato con Azure AD, tutte le proprietà
del dispositivo vengono considerate come valori Null e gli attributi del dispositivo
non possono essere determinati perché il dispositivo non esiste nella directory. Il
modo migliore per impostare come destinazione i criteri per i dispositivi non
registrati consiste nell'usare l'operatore negativo perché la regola di filtro
configurata verrebbe applicata. Se si usasse un operatore positivo, la regola di filtro
verrà applicata solo quando un dispositivo esiste nella directory e la regola
configurata corrisponde all'attributo nel dispositivo.
Attributi del Operatori Valori supportati Esempio

dispositivo supportati supportati
deviceId Equals, Id dispositivo valido (device.deviceid -eq

NotEquals, In, che è un GUID "498c4de7-1aee-4ded-8d5d-
NotIn 0000000000000")
displayName Equals, Qualsiasi stringa (device.displayName -contains

NotEquals, "ABC")
StartsWith,
NotStartsWith,
EndsWith,
NotEndsWith,
Contains,
NotContains,
In, NotIn
deviceOwnership Uguale, I valori supportati (device.deviceOwnership -eq

NotEquals sono "Personal" per "Company")
portare i propri
dispositivi e
"Company" per i
dispositivi di
proprietà aziendale
isCompliant Uguale, I valori supportati (device.isCompliant -eq "True")

NotEquals sono "True" per i
dispositivi conformi e
"False" per i
dispositivi non
conformi
manufacturer Equals, Qualsiasi stringa (device.manufacturer -

NotEquals, startsWith "Microsoft")
StartWith,
NotStartsWith,
EndsWith,
NotEndsWith,
Contains,
NotContains,
In, NotIn
mdmAppId Uguale, ID applicazione MDM (device.mdmAppId -in

NotEquals, In, valido ["00000000a-0000-0000-c0000-
NotIn 00000000000"]
model Equals, Qualsiasi stringa (device.model -notContains

NotEquals, "Surface")
StartWith,
NotStartsWith,
EndsWith,
NotEndsWith,
Contains,
NotContains,
In, NotIn
operatingSystem Equals, Un sistema operativo (device.operatingSystem -eq

NotEquals, valido (ad esempio "Windows")
StartWith, Windows, iOS o
NotStartsWith, Android)
EndsWith,
NotEndsWith,
Contains,
NotContains,
In, NotIn
operatingSystemVersion Equals, Versione valida del (device.operatingSystemVersion

NotEquals, sistema operativo (ad -in ["10.0.18363", "10.0.19041",
StartWith, esempio 6.1 per "10.0.19042", "10.0.0.22000"])
NotStartsWith, Windows 7, 6.2 per
EndsWith, Windows 8 o 10.0
NotEndsWith, per Windows 10 e
Contains, Windows 11)
NotContains,
In, NotIn
physicalIds Contiene, non Come esempio tutti i (device.physicalIds -contiene "

contiene dispositivi Windows [ZTDId]:value")
Autopilot archiviano
ZTDId (valore
univoco assegnato a
tutti i dispositivi
Windows Autopilot
importati) nella
proprietà device
physicalIds.
profileType Uguale, Tipo di profilo valido (device.profileType -eq

NotEquals impostato per un "Stampante")
dispositivo. I valori
supportati sono:
RegisteredDevice
(impostazione
predefinita),
SecureVM (usato per
le macchine virtuali
Windows in Azure
abilitate con l'accesso
di Azure AD),
Stampante (usata per
le stampanti),
Condivisa (usata per i
dispositivi condivisi),
IoT (usata per i
dispositivi IoT)
systemLabels Contiene, non Elenco delle etichette (device.systemLabels -contains

contiene applicate al "M365Managed")
dispositivo dal
sistema. Alcuni dei
valori supportati
sono: AzureResource
(usato per le
macchine virtuali
Windows in Azure
abilitate con l'accesso
ad Azure AD),
M365Managed
(usato per i
dispositivi gestiti con
Microsoft Managed
Desktop), MultiUser
(usato per i
dispositivi condivisi)
trustType Uguale, Stato registrato (device.trustType -eq

NotEquals valido per i "ServerAD")
dispositivi. I valori
supportati sono:
AzureAD (usato per i
dispositivi aggiunti
ad Azure AD),
ServerAD (usato per i
dispositivi aggiunti
ad Azure AD ibrido),
Workplace (usato per
i dispositivi registrati
di Azure AD)
extensionAttribute1-15 Equals, extensionAttributes1- (device.extensionAttribute1 -eq

NotEquals, 15 sono attributi che "SAW")
StartWith, i clienti possono
NotStartsWith, usare per gli oggetti
EndsWith, dispositivo. I clienti
NotEndsWith, possono aggiornare
Contains, una delle
NotContains, estensioniAttributes1
In, NotIn a 15 con valori
personalizzati e usarli
nel filtro per i
dispositivi in Accesso
condizionale. È
possibile usare
qualsiasi valore
stringa.
７ Nota
Quando si creano regole complesse o si usano troppi identificatori singoli come

deviceid per le identità del dispositivo, tenere presente che "La lunghezza massima
per la regola di filtro è di 3072 caratteri".
７ Nota
Gli Contains operatori funzionano NotContains in modo diverso a seconda dei tipi
di attributo. Per gli attributi di stringa, operatingSystem ad esempio e model ,
l'operatore Contains indica se si verifica una sottostringa specificata all'interno
dell'attributo. Per gli attributi della raccolta di stringhe, physicalIds ad esempio e
systemLabels , l'operatore Contains indica se una stringa specificata corrisponde a
una delle stringhe intere della raccolta.
Comportamento dei criteri con filtro per i

dispositivi
Il filtro per le condizioni dei dispositivi in Accesso condizionale valuta i criteri in base agli
attributi del dispositivo di un dispositivo registrato in Azure AD e quindi è importante
comprendere in quali circostanze i criteri vengono applicati o meno. Nella tabella
seguente viene illustrato il comportamento quando viene configurato un filtro per le
condizioni dei dispositivi.
Filtrare in base alla condizione dei Stato Filtro dispositivo applicato

dispositivi registrazione
dispositivo
Includere/escludere la modalità con Dispositivo No

operatori positivi (Equals, StartsWith, non
EndsWith, Contains, In) e l'uso di qualsiasi registrato
attributo
Includere/escludere la modalità con Dispositivo Sì, se i criteri vengono soddisfatti

operatori positivi (Equals, StartsWith, registrato
EndsWith, Contains, In) e l'uso di attributi
esclusi extensionAttributes1-15

operatori positivi (Equals, StartsWith, registrato
EndsWith, Contains, In) e l'uso di attributi, gestito da
tra cui extensionAttributes1-15 Intune
Includere/escludere la modalità con Dispositivo Sì, se vengono soddisfatti i criteri.

operatori positivi (Equals, StartsWith, registrato Quando si usa
EndsWith, Contains, In) e l'uso di attributi, non gestito extensionAttributes1-15, i criteri
tra cui extensionAttributes1-15 da Intune verranno applicati se il dispositivo
è conforme o aggiunto ad Azure
AD ibrido
Includere/escludere la modalità con Dispositivo Sì

operatori negativi (NotEquals, non
NotStartsWith, NotEndsWith, NotContains, registrato
NotIn) e l'uso di tutti gli attributi

operatori negativi (NotEquals, registrato
NotStartsWith, NotEndsWith, NotContains,
NotIn) e l'uso di tutti gli attributi esclusi
extensionAttributes1-15

operatori negativi (NotEquals, registrato
NotStartsWith, NotEndsWith, NotContains, gestito da
NotIn) e l'uso di tutti gli attributi inclusi Intune
extensionAttributes1-15
Filtrare in base alla condizione dei Stato Filtro dispositivo applicato
dispositivi registrazione
dispositivo
Includere/escludere la modalità con Dispositivo Sì, se vengono soddisfatti i criteri.

operatori negativi (NotEquals, registrato Quando si usa
NotStartsWith, NotEndsWith, NotContains, non gestito extensionAttributes1-15, i criteri
NotIn) e l'uso di tutti gli attributi inclusi da Intune verranno applicati se il dispositivo
extensionAttributes1-15 è conforme o aggiunto ad Azure
AD ibrido
Passaggi successivi
Tornare all'istituto di istruzione: uso corretto dell'algebra booleana nei filtri
complessi
Aggiornare API Graph dispositivo
Protezione dei dispositivi come parte della storia di accesso con privilegi
Usare lo strumento What If per risolvere
i problemi dei criteri di accesso
condizionale
Articolo • 17/03/2023
Lo strumento criteri What If per l'accesso condizionale consente di comprendere

l'impatto dei criteri di accesso condizionale nell'ambiente. Anziché testare i criteri
eseguendo più accessi in modo manuale, questo strumento consente di valutare un
accesso simulato di un utente. La simulazione valuta l'impatto di questo accesso sui
criteri e genera un report di simulazione.
Lo strumento What If consente di determinare rapidamente i criteri applicabili a un

utente specifico. Queste informazioni possono essere usate, ad esempio, se è necessario
risolvere un problema.
https://www.youtube-nocookie.com/embed/M_iQVM-3C3E
Funzionamento
Nello strumento What If per l'accesso condizionale è prima necessario configurare le
condizioni dello scenario di accesso da simulare. Queste impostazioni possono
includere:
L'utente da testare
Le app cloud a cui l'utente proverà ad accedere
Le condizioni in cui viene eseguito l'accesso alle app cloud configurate
Lo strumento What If non verifica le dipendenze del servizio di accesso condizionale. Ad

esempio, se si usa What If per testare i criteri di accesso condizionale per Microsoft
Teams, il risultato non prende in considerazione i criteri applicabili a Office 365 Exchange
Online, una dipendenza del servizio di accesso condizionale per Microsoft Teams.
Come passaggio successivo, è possibile avviare una simulazione per valutare le

impostazioni. Una valutazione prende in esame solo i criteri abilitati.
Al termine della valutazione, lo strumento genera un report dei criteri interessati. Per
raccogliere altre informazioni sui criteri di accesso condizionale, le informazioni
dettagliate sull'accesso condizionale e la cartella di lavoro per la creazione di report
possono fornire altri dettagli sui criteri in modalità solo report e sui criteri attualmente
abilitati.
Esecuzione dello strumento
È possibile trovare lo strumento What If nel portale di Azure inAccesso> condizionaledi
Sicurezza di>Azure Active Directory>.
Prima di poter eseguire lo strumento What If, è necessario specificare le condizioni da

valutare.
Condizioni
L'unica condizione che è necessario fare è la selezione di un'identità utente o del carico
di lavoro. Tutte le altre condizioni sono facoltative. Per una definizione di queste
condizioni, vedere l'articolo Creazione di criteri di accesso condizionale.

Versione di valutazione
Per avviare una valutazione, fare clic su What If .You start an evaluation by click What If.
Al termine della valutazione, viene generato un report contenente gli elementi seguenti:
Indicatore che indica se nell'ambiente sono presenti criteri classici.
Criteri che verranno applicati all'identità utente o del carico di lavoro.
Criteri che non si applicano all'identità utente o del carico di lavoro.
Se per le app cloud selezionate sono presenti criteri classici, viene visualizzato un
indicatore. Facendo clic sull'indicatore, si viene reindirizzati alla pagina dei criteri classici.
In questa pagina è possibile semplicemente disabilitare un criterio classico o eseguirne
la migrazione. Chiudendo la pagina è possibile tornare ai risultati della valutazione.
Nell'elenco dei criteri applicabili è anche possibile trovare un elenco di controlli di

concessione e controlli sessione che devono essere soddisfatti.
Nell'elenco dei criteri che non si applicano, è possibile trovare i motivi per cui questi
criteri non si applicano. Per ogni criterio elencato, il motivo rappresenta la prima
condizione che non è stata soddisfatta.
Passaggi successivi
Per altre informazioni sull'applicazione dei criteri di accesso condizionale, vedere
l'uso della modalità di solo report dei criteri tramite informazioni dettagliate
sull'accesso condizionale e creazione di report.
Se si è pronti per configurare i criteri di accesso condizionale per l'ambiente,
vedere Criteri comuni di accesso condizionale.
Pianificare una distribuzione
dell'accesso condizionale
Articolo • 07/04/2023
Pianificare la distribuzione dell'accesso condizionale è fondamentale affinché la strategia

di accesso per le applicazioni e le risorse dell'organizzazione sia quella desiderata. I
criteri di accesso condizionale offrono una grande flessibilità di configurazione. Tuttavia,
questa flessibilità significa anche pianificare attentamente per evitare risultati
indesiderati.
Analisi dell'accesso condizionale di Azure Active Directory (Azure AD), ad esempio

l'utente, il dispositivo e la posizione per automatizzare le decisioni e applicare i criteri di
accesso dell'organizzazione per le risorse. I criteri di accesso condizionale consentono di
creare condizioni che gestiscono i controlli di sicurezza che possono bloccare l'accesso,
richiedere l'autenticazione a più fattori o limitare la sessione dell'utente quando
necessario e rimanere fuori dal modo dell'utente quando non.
Con questa valutazione e applicazione, l'accesso condizionale definisce la base della

gestione del comportamento di sicurezza di Microsoft Zero Trust .
Microsoft offre impostazioni predefinite di sicurezza che garantiscono un livello di

sicurezza di base abilitato nei tenant che non hanno Azure AD Premium. Con l'accesso
condizionale è possibile creare criteri che forniscono la stessa protezione delle
impostazioni predefinite per la sicurezza, ma con granularità. Le impostazioni predefinite
per l'accesso condizionale e la sicurezza non devono essere combinate perché la
creazione di criteri di accesso condizionale impedirà di abilitare le impostazioni
predefinite per la sicurezza.
Prerequisiti
Tenant di Azure AD funzionante con Azure AD Premium P1, P2 o licenza di
valutazione abilitata. Se necessario, crearne uno gratuitamente .
Azure AD Premium P2 è necessario includere il rischio Identity Protection nei
Gli amministratori che interagiscono con l'accesso condizionale devono avere una
o più delle assegnazioni di ruolo seguenti a seconda delle attività eseguite. Per
seguire il principio Zero Trust dei privilegi minimi, valutare l'uso di Privileged
Identity Management (PIM) per attivare le assegnazioni di ruolo con privilegi just-
in-time.
Leggere i criteri e le configurazioni di accesso condizionale
Ruolo con autorizzazioni di lettura per la sicurezza
Ruolo con autorizzazioni di lettura globali
Creare o modificare i criteri di accesso condizionale
Amministratore accesso condizionale
Amministratore della sicurezza
Utente di test (non amministratore) che consente di verificare che i criteri
funzionino come previsto prima della distribuzione in utenti reali. Se è necessario
creare un utente, vedere Avvio rapido: Aggiungere nuovi utenti ad Azure Active
Directory.
Un gruppo di cui l'utente non amministratore è membro. Se è necessario creare un
gruppo, vedere Creare un gruppo di base e aggiungere membri in Azure Active
Directory.
Comunicazione del cambiamento

La comunicazione è fondamentale per il successo di qualsiasi nuova funzionalità. È
consigliabile comunicare in modo proattivo con gli utenti come cambierà l'esperienza,
quando cambierà e come ottenere supporto se riscontrano problemi.
Componenti dei criteri di accesso condizionale

I criteri di accesso condizionale rispondono alle domande su chi può accedere alle
risorse, sulle risorse a cui possono accedere e su quali condizioni. I criteri possono
essere progettati in modo da concedere l'accesso, limitare l'accesso con controlli di
sessione o bloccare l'accesso. Si compilano criteri di accesso condizionale definendo le
istruzioni if-then come:
Se viene soddisfatta un'assegnazione Applicare i controlli di accesso

Se viene soddisfatta un'assegnazione Applicare i controlli di accesso
Se si è un utente in Finance che accede Richiedere l'autenticazione a più fattori e un

all'applicazione Payroll dispositivo conforme
Se non si è membri di Finance che Blocca accesso

accedono all'applicazione Payroll
Se il rischio utente è elevato Richiedere un'autenticazione a più fattori e una

modifica sicura della password
Porre le domande giuste

Ecco alcune domande comuni sulle assegnazioni e sui controlli di accesso. Documentare
le risposte alle domande relative a ogni criterio prima della creazione.
Utenti o identità del carico di lavoro

Quali utenti, gruppi, ruoli directory o identità del carico di lavoro verranno inclusi o
esclusi dai criteri?
Quali account o gruppi di accesso di emergenza devono essere esclusi dai criteri?
App o azioni cloud

Questo criterio verrà applicato a qualsiasi applicazione, azione utente o contesto di
autenticazione? Se sì-
Quali applicazioni o servizi si applicano ai criteri?

Quali azioni utente saranno soggette a questo criterio?
Quali contesti di autenticazione verranno applicati a questo criterio?
Condizioni
Quali piattaforme di dispositivo verranno incluse o escluse dal criterio?

Quali sono le posizioni di rete note dell'organizzazione?
Quali percorsi verranno inclusi o esclusi dal criterio?
Quali tipi di app client verranno inclusi o esclusi dai criteri?
È necessario eseguire la destinazione di attributi di dispositivo specifici?
Se si usa Identity Protection, si vuole incorporare il rischio di accesso o utente?
Rischio di accesso e utente
Per le organizzazioni con licenze di Azure AD Premium P2, possono includere rischi per
l'utente e l'accesso nei criteri di accesso condizionale. Queste aggiunte possono
contribuire a ridurre l'attrito delle misure di sicurezza richiedendo l'autenticazione a più
fattori o la modifica sicura della password solo quando un utente o un accesso è
considerato rischioso.
Per altre informazioni sul rischio e sull'uso nei criteri, vedere l'articolo Informazioni sui
rischi.
Bloccare o concedere controlli
Si desidera concedere l'accesso alle risorse richiedendo uno o più degli elementi
seguenti?
Autenticazione a più fattori

Dispositivo contrassegnato come conforme
Uso di un dispositivo aggiunto ad Azure AD ibrido
Uso di un'app client approvata
Protezione di app criteri applicati
Modifica della password
Condizioni per l'uso accettate
Il blocco dell'accesso è un controllo potente che va applicato con le dovute conoscenze.

I criteri con istruzioni di blocco possono avere effetti collaterali imprevisti. I test e la
convalida appropriati sono fondamentali prima di abilitare il controllo su larga scala. Gli
amministratori devono usare strumenti come la modalità di solo report di accesso
condizionale e lo strumento What If nell'accesso condizionale durante l'esecuzione delle
modifiche.
Controlli di sessione
Si desidera applicare uno dei controlli di accesso seguenti nelle applicazioni cloud?
Usa restrizioni imposte dalle app

Usare il controllo app di accesso condizionale
Applicare la frequenza di accesso
Usare la sessione del browser persistente
Personalizzare la valutazione dell'accesso continuo
Combinazione di criteri
Quando si creano e si assegnano criteri, è necessario tenere conto del funzionamento
dei token di accesso. I token di accesso concedono o negano l'accesso in base al fatto
che gli utenti che effettuano una richiesta siano stati autorizzati e autenticati. Se il
richiedente può dimostrare di essere chi dichiara di essere, può accedere alle risorse o
alle funzionalità protette.
I token di accesso vengono rilasciati per impostazione predefinita se una condizione

dei criteri di accesso condizionale non attiva un controllo di accesso.
Questo criterio non impedisce all'app di avere la propria capacità di bloccare l'accesso.
Si consideri ad esempio un esempio di criteri semplificato in cui:
Utenti: FINANCE GROUP
Accesso: PAYROLL APP
Controllo di accesso: autenticazione a più fattori
L'utente A si trova nel GRUPPO FINANCE, è necessario eseguire l'autenticazione a

più fattori per accedere all'APP con pagamento in base al consumo.
L'utente B non è nel GRUPPO FINANCE, viene emesso un token di accesso ed è
autorizzato ad accedere all'APP con pagamento in base al consumo senza
eseguire l'autenticazione a più fattori.
Per garantire che gli utenti esterni al gruppo finanziario non possano accedere all'app
con retribuzione, è possibile creare criteri separati per bloccare tutti gli altri utenti, come
i criteri semplificati seguenti:
Utenti: includere tutti gli utenti/escludere FINANCE GROUP
Accesso: PAYROLL APP
Controllo di accesso: Blocca l'accesso
Ora, quando l'utente B tenta di accedere all'APP con pagamento in base al consumo ,
viene bloccato.
Consigli
Tenendo conto delle nostre informazioni sull'uso dell'accesso condizionale e del
supporto di altri clienti, ecco alcune raccomandazioni basate sulle nostre informazioni.
Applicare criteri di accesso condizionale a ogni app

Assicurarsi che ogni app abbia almeno un criterio di accesso condizionale applicato.
Dal punto di vista della sicurezza, è preferibile creare un criterio che includa tutte le app
cloud e quindi escludere le applicazioni a cui non si vuole applicare il criterio. Questa
procedura garantisce che non sia necessario aggiornare i criteri di accesso condizionale
ogni volta che si esegue l'onboarding di una nuova applicazione.
 Suggerimento
Prestare molta attenzione nell'uso del blocco e di tutte le applicazioni in un singolo

criterio. Ciò potrebbe bloccare gli amministratori dal portale di Azure e le esclusioni
non possono essere configurate per endpoint importanti, ad esempio Microsoft
Graph.
Ridurre al minimo il numero di criteri di accesso

condizionale
La creazione di un criterio per ogni app non è efficiente e comporta un'amministrazione
difficile. L'accesso condizionale ha un limite di 195 criteri per tenant. È consigliabile
analizzare le app e raggrupparle in applicazioni con gli stessi requisiti di risorse per gli
stessi utenti. Ad esempio, se tutte le app di Microsoft 365 o tutte le app HR hanno gli
stessi requisiti per gli stessi utenti, creare un singolo criterio e includere tutte le app a
cui si applica.
Configurare la modalità solo report

Per impostazione predefinita, ogni criterio creato dal modello viene creato in modalità
solo report. È consigliabile che le organizzazioni testano e monitorino l'utilizzo, per
garantire il risultato previsto, prima di attivare ogni criterio.
Abilitare i criteri in modalità solo report. Dopo aver salvato un criterio in modalità solo
report, è possibile visualizzare l'effetto sugli accessi in tempo reale nei log di accesso.
Nei log di accesso selezionare un evento e passare alla scheda Solo report per
visualizzare il risultato di ogni criterio solo report.
È possibile visualizzare l'aggregazione sugli effetti dei criteri di accesso condizionale

nella cartella di lavoro Informazioni dettagliate e creazione di report. Per accedere alla
cartella di lavoro, è necessaria una sottoscrizione di Monitoraggio di Azure ed è
necessario trasmettere i log di accesso a un'area di lavoro Log Analytics.
Pianificare l'interruzione
Se ci si basa su un singolo controllo di accesso, ad esempio l'autenticazione a più fattori
o un percorso di rete per proteggere i sistemi IT, si è soggetti a errori di accesso se tale
singolo controllo di accesso diventa non disponibile o non è configurato correttamente.
Per ridurre il rischio di blocco durante interruzioni impreviste, pianificare strategie di

resilienza per l'organizzazione.
Impostare gli standard di denominazione per i criteri

Uno standard di denominazione consente di trovare i criteri e di comprenderne lo
scopo senza aprirli nel portale di amministrazione di Azure. Si consiglia di denominare
il criterio per visualizzare:
Un numero di sequenza
Le applicazioni cloud a cui si applica
Risposta.
A chi si applica
Quando si applica (se applicabile)
Esempio: un criterio per richiedere l'autenticazione a più fattori per gli utenti di
marketing che accedono all'app Dynamics CRP da reti esterne potrebbe essere:
Un nome descrittivo consente di ottenere una panoramica dell'implementazione

dell'accesso condizionale. Il numero di sequenza è utile se è necessario fare riferimento
a un criterio in una conversazione. Se ad esempio si parla al telefono con un altro
amministratore, è possibile chiedergli di aprire il criterio CA01 per risolvere un problema.
Standard di denominazione per i controlli di accesso di emergenza

Oltre ai criteri attivi, è opportuno implementare anche criteri disabilitati che agiscano
come controlli di accesso resilienti secondari in scenari di emergenza o di interruzione
dei servizi. Lo standard di denominazione per i criteri di emergenza deve includere:
ENABLE IN EMERGENCY all'inizio in modo che il nome si distingua dagli altri criteri.
Il nome dell'interruzione a cui deve essere applicato.
Un numero di sequenza di ordinamento per consentire all'amministratore di
sapere in che ordine devono essere abilitati i criteri.
Esempio: il nome seguente indica che questo criterio è il primo di quattro criteri da
abilitare in caso di interruzione dell'autenticazione a più fattori:
EM01 - ENABLE IN EMERGENCY: Interruzione dell'autenticazione a più fattori [1/4]-

Exchange SharePoint: Richiesta di aggiunta ad Azure AD ibrido per utenti VIP.
Bloccare i paesi da cui non ci si aspetta mai un accesso.

Azure Active Directory consente di creare località denominate. Creare l'elenco dei paesi
consentiti e quindi creare un criterio di blocco di rete con questi "paesi consentiti" come
esclusione. Si tratta di un sovraccarico inferiore per i clienti che si trovano in località
geografiche più piccole. Assicurarsi di esentare gli account di accesso di emergenza da
questo criterio.
Distribuire i criteri di accesso condizionale

Quando si è pronti, distribuire i criteri di accesso condizionale in fasi.
Creare i criteri di accesso condizionale

Per un inizio iniziale, vedere Modelli di criteri di accesso condizionale e Criteri di
sicurezza comuni per le organizzazioni di Microsoft 365 . Questi modelli sono un modo
pratico per distribuire le raccomandazioni Microsoft. Assicurarsi di escludere gli account
di accesso di emergenza.
Valutare l'impatto di un criterio
È consigliabile usare gli strumenti seguenti per valutare l'effetto dei criteri prima e dopo
aver apportato modifiche. Un'esecuzione simulata offre una buona idea dell'effetto di
un criterio di accesso condizionale, non sostituisce un'esecuzione di test effettiva in un
ambiente di sviluppo configurato correttamente.
Modalità solo report e informazioni dettagliate sull'accesso condizionale e cartella

di lavoro Report.
Lo strumento What If
Testare i criteri
Assicurarsi di testare i criteri di esclusione di un criterio. È ad esempio possibile
escludere un utente o gruppo da un criterio che richiede l'autenticazione MFA. Verificare
se agli utenti esclusi viene richiesta l'autenticazione MFA, perché la combinazione di altri
criteri potrebbe richiedere l'autenticazione MFA per questi stessi utenti.
Eseguire tutti i test nel piano di test con gli utenti di test. Il piano di test è importante
per disporre di un confronto tra i risultati previsti e i risultati effettivi. La tabella seguente
illustra alcuni test case di esempio. Modificare gli scenari e i risultati previsti in base al
modo in cui sono configurati i criteri di accesso condizionale.
Policy Scenario Risultato previsto

Policy Scenario Risultato previsto
Accessi a L'utente accede all'app Calcola un punteggio di rischio in base alla probabilità
rischio usando un browser non che l'accesso non sia stato eseguito dall'utente.
approvato Richiede all'utente di correggere automaticamente
l'autenticazione a più fattori
Gestione Un utente autorizzato cerca Accesso concesso

del di accedere da un
dispositivo dispositivo autorizzato
Gestione Un utente autorizzato cerca Accesso bloccato

del di accedere da un
dispositivo dispositivo non autorizzato
Modifica Un utente autorizzato tenta All'utente viene richiesto di cambiare la password o

password di accedere con credenziali l'accesso viene bloccato in base al criterio
per gli compromesse (accesso a
utenti a rischio elevato)
rischio
Distribuire in produzione
Dopo aver confermato l'impatto usando la modalità di solo report, un amministratore
può spostare l'opzione Abilita criterio da Solo report a Attiva.
Eseguire il rollback dei criteri
Nel caso in cui sia necessario eseguire il rollback dei criteri appena implementati, usare
una o più delle opzioni seguenti:
Disabilitare il criterio. La disabilitazione di un criterio assicura che non venga

applicata quando un utente tenta di accedere. È sempre possibile tornare indietro
e abilitare il criterio quando si vorrà utilizzarlo.
Escludere un utente o un gruppo da un criterio. Se un utente non è in grado di

accedere all'applicazione, è possibile scegliere di escluderlo dal criterio.
Ｕ Attenzione
Le esclusioni devono essere usate in modo spaspare, solo in situazioni in cui

l'utente è attendibile. Gli utenti devono essere aggiunti nuovamente al criterio
o al gruppo il prima possibile.
Se un criterio è disabilitato e non è più necessario, eliminarlo.
Risolvere i problemi relativi ai criteri di accesso

condizionale
Se un utente ha un problema con un criterio di accesso condizionale, raccogliere le
informazioni seguenti per facilitare la risoluzione dei problemi.
Nome entità utente

Nome visualizzato dell'utente
Nome del sistema operativo
Timestamp (è sufficiente un'approssimazione)
Applicazione di destinazione
Tipo di applicazione client (browser rispetto a client)
ID correlazione (questo ID è univoco per l'accesso)
Se l'utente ha ricevuto un messaggio con un collegamento a ulteriori dettagli, è

possibile raccogliere la maggior parte di queste informazioni dal collegamento.
Dopo aver raccolto le informazioni, vedere le risorse seguenti:
Problemi di accesso con l'accesso condizionale: comprendere i risultati di accesso

imprevisti correlati all'accesso condizionale usando i messaggi di errore e il log
degli accessi di Azure AD.
Uso dello strumento What-If: comprendere il motivo per cui un criterio è stato o
non è stato applicato a un utente in una circostanza specifica o se un criterio
verrebbe applicato in uno stato noto.
Passaggi successivi
Altre informazioni sull'autenticazione a più fattori
Altre informazioni su Identity Protection
Gestire i criteri di accesso condizionale con Microsoft API Graph

Accesso condizionale: accesso a livello
di codice
Articolo • 18/03/2023
Molte organizzazioni hanno espresso la loro necessità di gestire il maggior numero

possibile di ambienti come il codice possibile. L'uso di Microsoft Graph consente di
trattare i criteri di accesso condizionale come qualsiasi altra parte di codice
nell'ambiente.
Microsoft Graph fornisce un modello di programmabilità unificata che le organizzazioni

possono usare per interagire con i dati in Microsoft 365, Windows 10 e Enterprise
Mobility + Security. Per altre informazioni su Microsoft Graph, vedere l'articolo
Panoramica di Microsoft Graph.
Gli esempi seguenti vengono forniti come non supportano. È possibile usare questi
esempi come base per gli strumenti nell'organizzazione.
Molti degli esempi seguenti usano strumenti come Identità gestite, App per lalogica,
OneDrive , Teams e Azure Key Vault.
Configurare
PowerShell
） Importante
A causa della deprecazione pianificata dei moduli di PowerShell (MSOL & AAD)
dopo dicembre 2022, non sono previsti altri aggiornamenti per questi moduli per
supportare nuove funzionalità di accesso condizionale. Per altre informazioni,
vedere gli annunci recenti: https://aka.ms/AzureADPowerShellDeprecation . Le
nuove funzionalità di accesso condizionale potrebbero non essere disponibili o non
possono essere funzionali all'interno di questi moduli di PowerShell come risultato
di questo annuncio. Prendere in considerazione la migrazione a Microsoft Graph
PowerShell . Altre indicazioni ed esempi verranno rilasciati presto.
Per molti amministratori, PowerShell è già uno strumento di scripting compreso.

Nell'esempio seguente viene illustrato come usare il modulo Di Azure AD PowerShell
per gestire i criteri di accesso condizionale.
Configurare i criteri di accesso condizionale con i comandi di Azure AD

PowerShell
API Microsoft Graph

In questo esempio vengono illustrate le opzioni di base Create, Read, Update ed Delete
(CRUD) disponibili nelle API di accesso condizionale in Microsoft Graph. L'esempio
include anche alcuni modelli JSON che è possibile usare per creare alcuni criteri di
esempio.
Configurare i criteri di accesso condizionale con le chiamate di Microsoft API

Graph
Configurare l'uso dei modelli

Usare le API di accesso condizionale per distribuire i criteri di accesso condizionale
nell'ambiente di pre-produzione usando un modello.
Configurare i criteri di accesso condizionale con i modelli di Microsoft API Graph
Test
In questo esempio vengono modelli di procedure di distribuzione più sicure con flussi di
lavoro di approvazione che possono copiare i criteri di accesso condizionale da un
ambiente, ad esempio pre-produzione, a un altro, come l'ambiente di produzione.
Promuovere i criteri di accesso condizionale dagli ambienti di test

Distribuisci
In questo esempio viene fornito un meccanismo per eseguire i criteri di accesso
condizionale in fasi gradualmente alla popolazione degli utenti, consentendo di gestire
l'impatto e individuare i problemi di supporto in anticipo.
Distribuire i criteri di accesso condizionale agli ambienti di produzione con flussi di

lavoro di approvazione
Monitoraggio
Questo esempio fornisce un meccanismo per monitorare le modifiche dei criteri di
accesso condizionale nel tempo e può attivare avvisi quando vengono modificati i criteri
chiave.
Monitorare i criteri di accesso condizionale distribuiti per le modifiche e gli avvisi di

trigger
Gestione
Backup e ripristino
Automatizzare il backup e il ripristino dei criteri di accesso condizionale con le
approvazioni in Teams usando questo esempio.
Gestire il processo di backup e ripristino dei criteri di accesso condizionale usando

le chiamate di Microsoft API Graph
Account di accesso di emergenza

Più amministratori possono creare criteri di accesso condizionale e possono dimenticare
di aggiungere gli account di accesso di emergenza come esclusione a tali criteri. Questo
esempio garantisce che tutti i criteri vengano aggiornati per includere gli account di
accesso di emergenza designati.
Gestire l'assegnazione degli account di accesso di emergenza ai criteri di accesso

condizionale usando le chiamate di Microsoft API Graph
Piani di emergenza
Le cose non funzionano sempre nel modo desiderato, quando ciò accade è necessario
un modo per tornare a uno stato in cui il lavoro può continuare. L'esempio seguente
offre un modo per ripristinare i criteri in un piano di emergenza noto e disabilitare altri
Gestire l'attivazione dei criteri di emergenza dell'accesso condizionale usando le

chiamate di Microsoft API Graph
Contributo comunitario
Questi esempi sono disponibili nel repository GitHub . Siamo lieti di supportare i
contributi della community tramite i problemi di GitHub e le richieste pull.
Passaggi successivi
Overview of Microsoft Graph (Panoramica di Microsoft Graph)
API di accesso condizionale
API percorso denominata

Criteri comuni di accesso condizionale:
richiedere l'autenticazione a più fattori
per gli amministratori
Articolo • 07/04/2023
Gli account a cui sono assegnati diritti amministrativi sono interessati da utenti
malintenzionati. La richiesta di autenticazione a più fattori (MFA) su tali account è un
modo semplice per ridurre il rischio di compromissione di tali account.
Microsoft consiglia di richiedere l'autenticazione a più fattori nei ruoli seguenti almeno,
in base alle raccomandazioni relative al punteggio di identità:
Amministratore globale
Amministratore di applicazioni
Amministratore dell'autenticazione
Amministratore fatturazione
Amministratore di applicazioni cloud
Amministratore di accesso condizionale
Amministratore di Exchange
Amministratore dell'help desk
Amministratore password
Amministratore autenticazione con privilegi
Amministratore dei ruoli con privilegi
Amministratore di SharePoint
Amministratore utenti
Le organizzazioni possono scegliere di includere o escludere ruoli in base alle esigenze.
l'accesso.
Distribuzione del modello

Le organizzazioni possono scegliere di distribuire questo criterio seguendo la procedura
descritta di seguito o usando i modelli di accesso condizionale (anteprima).

La procedura seguente consente di creare criteri di accesso condizionale per richiedere a
tali ruoli amministrativi assegnati di eseguire l'autenticazione a più fattori.

a. In Includi selezionare Ruoli directory e scegliere ruoli predefiniti come:
２ Avviso


6. In Applicazioni cloud o azioni>Includi selezionare Tutte le app cloud.
7. In Controlli di accesso>Concedi selezionare Concedi accesso, Richiedi
Dopo aver confermato le impostazioni usando la modalità solo report, un

amministratore può spostare l'interruttore Abilita criterio da Solo report a Sì.
Passaggi successivi

condizionale
Criteri di accesso condizionale comuni:
Protezione della registrazione delle
informazioni di sicurezza
Articolo • 17/03/2023
La protezione quando e come gli utenti registrano l'autenticazione a più fattori di Azure
AD e la reimpostazione della password self-service sono possibili con le azioni utente in
un criterio di accesso condizionale. Questa funzionalità è disponibile per le
organizzazioni che hanno abilitato la registrazione combinata. Questa funzionalità
consente alle organizzazioni di trattare il processo di registrazione come qualsiasi
applicazione in un criterio di accesso condizionale e usare la potenza completa
dell'accesso condizionale per proteggere l'esperienza. Gli utenti che accedono all'app
Microsoft Authenticator o abilitano l'accesso telefonico senza password sono soggetti a
questo criterio.
Alcune organizzazioni in passato potrebbero aver usato la posizione di rete attendibile o

la conformità del dispositivo come mezzo per proteggere l'esperienza di registrazione.
Con l'aggiunta di Pass di accesso temporaneo in Azure AD, gli amministratori possono
fornire credenziali limitate al tempo agli utenti che consentono loro di registrare da
qualsiasi dispositivo o posizione. Le credenziali pass di accesso temporaneo soddisfano i
requisiti di accesso condizionale per l'autenticazione a più fattori.

Le organizzazioni possono scegliere di distribuire questo criterio usando i passaggi
descritti di seguito o usando i modelli di accesso condizionale (anteprima).
Creare un criterio per proteggere la

registrazione
Il criterio seguente si applica agli utenti selezionati, che tentano di registrare usando
l'esperienza di registrazione combinata. Il criterio richiede agli utenti di trovarsi in un
percorso di rete attendibile, eseguire l'autenticazione a più fattori o usare credenziali
pass di accesso temporaneo.
1. Nel portale di Azure andare ad Azure Active Directory>Sicurezza>Accesso

condizionale.
3. In Nome immettere un nome per i criteri. Ad esempio, la registrazione combinata
delle informazioni di sicurezza con TAP.
２ Avviso
Gli utenti devono essere abilitati per la registrazione combinata.
b. In Escludi.
i. Selezionare Tutti gli utenti guest ed esterni.
ii. Selezionare Ruoli directory e scegliere Amministratore globale
７ Nota
Il passaggio di accesso temporaneo non funziona per gli utenti guest.
iii. Selezionare Utenti e gruppi e scegliere l'accesso di emergenza o gli account

break-glass dell'organizzazione.
5. In Applicazioni cloud o azioni selezionare Azioni utente e quindi Registra le
informazioni di sicurezza.
6. In Condizioni>Percorsi:
a. Impostare Configura su Sì.
i. Includere Tutte le località.
ii. Escludere Tutte le posizioni attendibili.
7. In Controlli di accesso>Concedi:
a. Selezionare Concedi accesso, Richiedi autenticazione a più fattori.

Gli amministratori dovranno ora rilasciare le credenziali pass di accesso temporaneo ai

nuovi utenti in modo che possano soddisfare i requisiti per l'autenticazione a più fattori
da registrare. I passaggi per eseguire questa attività sono disponibili nella sezione
Creare un passaggio di accesso temporaneo nel portale di Azure AD.
Le organizzazioni possono scegliere di richiedere altri controlli di concessione con o al
posto di Richiedi autenticazione a più fattori al passaggio 7a. Quando si selezionano
più controlli, assicurarsi di selezionare il pulsante di opzione appropriato per attivare
l'opzione necessaria per richiedere tutti o uno dei controlli selezionati durante
l'esecuzione di questa modifica.
Registrazione utente guest

Per gli utenti guest che devono registrarsi per l'autenticazione a più fattori nella
directory, è possibile scegliere di bloccare la registrazione dall'esterno delle posizioni di
rete attendibili usando la guida seguente.
1. Nel portale di Azure andare ad Azure Active Directory>Sicurezza>Accesso

condizionale.
3. In Nome immettere un nome per i criteri. Ad esempio, Registrazione delle
informazioni di sicurezza combinata su reti attendibili.
a. In Includi selezionare Tutti gli utenti guest ed esterni.
5. In Applicazioni cloud o azioni selezionare Azioni utente e quindi Registra le
informazioni di sicurezza.
6. In Condizioni>Percorsi:
a. Configurare Sì.
b. Includere Tutte le località.
c. Escludere Tutte le posizioni attendibili.
a. Selezionare Blocca accesso.
b. Quindi fare clic su Seleziona.

Passaggi successivi

condizionale
Richiedere agli utenti di riconfirmare le informazioni di autenticazione
Articolo • 17/03/2023
A causa dell'aumento dei rischi associati ai protocolli di autenticazione legacy, Microsoft

consiglia alle organizzazioni di bloccare le richieste di autenticazione che usano questi
protocolli e di richiedere l'autenticazione moderna. Per altre informazioni sul motivo per
cui è importante bloccare l'autenticazione legacy, vedere l'articolo Procedura: Bloccare
l'autenticazione legacy in Azure AD con accesso condizionale.


I passaggi seguenti consentono di creare un criterio di accesso condizionale per
bloccare le richieste di autenticazione legacy. Questo criterio viene messo in modalità
solo report per avviare in modo che gli amministratori possano determinare l'impatto
che avranno sugli utenti esistenti. Quando gli amministratori hanno verificato che il
criterio funziona come previsto, lo possono attivare o gestirne la distribuzione
aggiungendo gruppi specifici ed escludendone altri.

b. In Escludiselezionare Utenti e gruppi e scegliere tutti gli account che devono
continuare a poter usare l'autenticazione legacy. Escludere almeno un account
per evitare che l'utente venga bloccato. Se non si esclude alcun account, non
sarà possibile creare questo criterio.
6. In App Cloud o azioni selezionare Tutte le app Cloud.
7. In Condizioni>app client impostare Configura su Sì.
a. Selezionare solo le caselle Exchange ActiveSync client e Altri client.
b. Selezionare Operazione completata.
8. In Controlli di accesso>Concedi selezionare Blocca accesso.
a. Scegliere Seleziona.

７ Nota

l'accesso.
Passaggi successivi

condizionale
Come configurare un dispositivo o un'applicazione multifunzione per l'invio di posta

elettronica tramite Microsoft 365
per l'accesso guest
Articolo • 07/04/2023
Richiedere agli utenti guest di eseguire l'autenticazione a più fattori quando si accede
alle risorse dell'organizzazione.
l'accesso.

a. In Includi selezionare Tutti gli utenti guest ed esterni
a. In Escludi selezionare tutte le applicazioni che non richiedono l'autenticazione a
più fattori.

Passaggi successivi

condizionale
Richiedere L'autenticazione a più fattori
per tutti gli utenti
Articolo • 07/04/2023
Come Alex Weinert, la Directory of Identity Security at Microsoft, cita nel suo post di
blog Il tuo pa$$word non importa :
La password non importa, ma MFA fa! In base ai nostri studi, il tuo account è più del
99,9% meno probabile che venga compromesso se usi MFA.
Le linee guida contenute in questo articolo consentono all'organizzazione di creare

criteri MFA per l'ambiente.
Esclusioni dell'applicazione
Le organizzazioni possono avere molte applicazioni cloud in uso. Non tutte queste
applicazioni possono richiedere la stessa sicurezza. Ad esempio, le applicazioni di
pagamento e partecipazione possono richiedere MFA, ma la caffetteria probabilmente
non è. Gli amministratori possono scegliere di escludere applicazioni specifiche dai
criteri.
Attivazione dell'abbonamento
Le organizzazioni che usano l'attivazione della sottoscrizione per consentire agli utenti
di "eseguire il passaggio" da una versione di Windows a un'altra, potrebbero voler
escludere le API del servizio universal Store e l'applicazione Web, AppID 45a330b1-
b1ec-4cc1-9161-9f0392a49f da tutti gli utenti tutti i criteri MFA delle app cloud.


La procedura seguente consente di creare criteri di accesso condizionale per richiedere a
tutti gli utenti l'autenticazione a più fattori.

a. In Includi selezionare Tutti gli utenti
a. In Escludi selezionare tutte le applicazioni che non richiedono l'autenticazione a
più fattori.
7. In Controlli>di accesso Concedere l'accesso selezionareConcediaccesso, Richiedi

Posizioni specifiche
Le organizzazioni possono scegliere di incorporare percorsi di rete noti noti come
percorsi denominati ai criteri di accesso condizionale. Queste posizioni denominate
possono includere reti IPv4 attendibili come quelle per una posizione principale
dell'ufficio. Per altre informazioni sulla configurazione dei percorsi denominati, vedere
l'articolo Qual è la condizione di posizione in Accesso condizionale di Azure Active
Directory?
Nel criterio di esempio precedente, un'organizzazione può scegliere di non richiedere

l'autenticazione a più fattori se si accede a un'app cloud dalla rete aziendale. In questo
caso, è possibile aggiungere la configurazione seguente al criterio:
1. In Assegnazioni selezionarePosizionicondizioni>.
a. Configurare Sì.
b. Includere Tutte le località.
c. Escludere Tutte le posizioni attendibili.
2. Selezionare Fine.
3. Salvare le modifiche dei criteri.
Passaggi successivi

condizionale
per la gestione di Azure
Articolo • 07/04/2023
Le organizzazioni usano molti servizi di Azure e li gestiscono da strumenti basati su

Azure Resource Manager come:
Portale di Azure
Azure PowerShell
Interfaccia della riga di comando di Azure
Questi strumenti consentono l'accesso con privilegi elevati alle risorse che possono
apportare le modifiche seguenti:
Modificare le configurazioni a livello di sottoscrizione

Impostazioni del servizio
Fatturazione della sottoscrizione
Per proteggere queste risorse con privilegi, Microsoft consiglia di richiedere

l'autenticazione a più fattori per qualsiasi utente che accede a queste risorse. In Azure
AD questi strumenti vengono raggruppati in una suite denominata Gestione di
Microsoft Azure. Per Azure per enti pubblici, questa suite deve essere l'app per le API di
gestione cloud Azure per enti pubblici.
l'accesso.


La procedura seguente consente di creare criteri di accesso condizionale per richiedere
agli utenti che accedono alla suite di gestione di Microsoft Azure di eseguire
Ｕ Attenzione
Assicurarsi di comprendere il funzionamento dell'accesso condizionale prima di

configurare un criterio per gestire l'accesso a Gestione di Microsoft Azure.
Assicurarsi di non creare condizioni che potrebbero bloccare il proprio accesso al
portale.

6. In App cloud o azioni>Includiselezionare Seleziona app, scegliere Gestione di
Microsoft Azure e selezionare Seleziona.

Passaggi successivi

condizionale
Autenticazione a più fattori basata sui
rischi di accesso
Articolo • 18/03/2023
La maggior parte degli utenti ha un comportamento normale monitorabile. In condizioni

che esulano dalla normalità, potrebbe essere rischioso consentire loro semplicemente di
accedere. È possibile bloccare l'utente o forse chiedere loro di eseguire l'autenticazione
a più fattori per dimostrare che sono davvero chi dicono che sono.
Un rischio di accesso rappresenta la probabilità che una richiesta di autenticazione

specificata non sia stata autorizzata dal proprietario dell'identità. Le organizzazioni con
licenze Azure AD Premium P2 possono creare criteri di accesso condizionale che
incorporano i rilevamenti dei rischi di accesso ad Azure AD Identity Protection.
Esistono due posizioni in cui questo criterio può essere configurato, accesso
condizionale e Identity Protection. La configurazione usando un criterio di accesso
condizionale è il metodo preferito che offre più contesto, tra cui dati di diagnostica
avanzati, integrazione in modalità di report, API Graph supporto e la possibilità di usare
altri attributi di accesso condizionale come la frequenza di accesso nei criteri.
I criteri basati sui rischi di accesso proteggono gli utenti dalla registrazione
dell'autenticazione a più fattori nelle sessioni rischiose. Se gli utenti non sono registrati
per MFA, gli accessi rischiosi vengono bloccati e vengono visualizzati un errore
AADSTS53004.

Abilitare con i criteri di accesso condizionale

7. In Condizioni>Rischio di accesso impostare Configura su Sì. In Selezionare il
livello di rischio di accesso questo criterio verrà applicato.
a. Selezionare Alto e Medio.
b. Selezionare Fine.
a. Selezionare Concedi accesso, Richiedi autenticazione a più fattori.
9. In Sessione.
a. Selezionare Frequenza di accesso.
b. Assicurarsi che ogni volta sia selezionata.
c. Scegliere Seleziona.
Dopo che gli amministratori confermano le impostazioni usando la modalità solo report,
è possibile spostare l'opzione Abilita criterio solo da Report a Attiva.
Passaggi successivi
Richiedere la riutenticazione ogni volta
Correggere i rischi e sbloccare gli utenti
Accesso condizionale basato sul rischio per l'utente
condizionale
Che cos'è Azure Active Directory Identity Protection?
modifica della password basata sui
rischi dell'utente
Articolo • 17/03/2023
Microsoft collabora con ricercatori, forze dell'ordine, diversi team di sicurezza di

Microsoft e altre fonti attendibili per trovare coppie di nome utente e password perse.
Le organizzazioni con licenze Azure AD Premium P2 possono creare criteri di accesso
condizionale che incorporare i rilevamenti di rischio utente di Azure AD Identity
Protection.
Esistono due posizioni in cui questo criterio può essere configurato, accesso
condizionale e Identity Protection. La configurazione usando un criterio di accesso
condizionale è il metodo preferito che offre più contesto, tra cui dati di diagnostica
avanzati, integrazione in modalità di report, API Graph supporto e la possibilità di usare
altri attributi di accesso condizionale come la frequenza di accesso nei criteri.

Abilitare con i criteri di accesso condizionale

7. In Condizioni>Rischio utente impostare Configura su Sì.
a. In Consente di configurare i livelli di rischio utente necessari per
l'applicazione dei criteri selezionare Alto.
a. Selezionare Concedi accesso, Richiedi autenticazione a più fattori e Richiedi
modifica password.
9. In Sessione.
b. Assicurarsi che ogni volta sia selezionata.
10. Confermare le impostazioni e impostare Abilita criteri solo report.
Passaggi successivi
Richiedere la riutenticazione ogni volta
Correggere i rischi e sbloccare gli utenti
Accesso condizionale basato sul rischio per l'accesso
condizionale
Che cos'è Azure Active Directory Identity Protection?
richiedere un dispositivo aggiunto ad
Azure AD conforme o ibrido per gli
amministratori
Articolo • 18/03/2023
Gli account a cui sono assegnati diritti amministrativi sono interessati da utenti
malintenzionati. Richiedere agli utenti con questi diritti con privilegi elevati di eseguire
azioni dai dispositivi contrassegnati come conformi o aggiunti ad Azure AD ibrido può
contribuire a limitare la possibile esposizione.
Altre informazioni sui criteri di conformità dei dispositivi sono disponibili nell'articolo
Impostare le regole nei dispositivi per consentire l'accesso alle risorse
dell'organizzazione usando Intune
La richiesta di un dispositivo aggiunto ad Azure AD ibrido dipende dal fatto che i

dispositivi siano già aggiunti ad Azure AD ibrido. Per altre informazioni, vedere l'articolo
Configurare l'aggiunta ad Azure AD ibrido.
Microsoft consiglia di abilitare questo criterio per i ruoli seguenti almeno in base alle
raccomandazioni relative al punteggio di identità:
Amministratore di accesso condizionale
Le organizzazioni possono scegliere di includere o escludere ruoli in base alle esigenze.

l'accesso.


l'autenticazione a più fattori, i dispositivi che accedono alle risorse devono essere
contrassegnati come conformi ai criteri di conformità Intune dell'organizzazione o
aggiunti ad Azure AD ibrido.

a. In Includi selezionare Ruoli directory e scegliere ruoli predefiniti come:
Amministratore dell'applicazione cloud
Amministratore del supporto tecnico
Amministratore della protezione
２ Avviso


a. Selezionare Richiedi che il dispositivo sia contrassegnato come conforme e
b. Per più controlli selezionare Richiedi uno dei controlli selezionati.
７ Nota
È possibile registrare i nuovi dispositivi in Intune anche se si seleziona Richiedi che

il dispositivo sia contrassegnato come conforme per Tutti gli utenti e Tutte le app
cloud seguendo la procedura precedente. Richiedere che il dispositivo sia
contrassegnato come controllo conforme non blocchi Intune registrazione.
Comportamento noto
In Windows 7, iOS, Android, macOS e alcuni Web browser di terze parti, Azure AD
identifica il dispositivo usando un certificato client di cui viene effettuato il provisioning
quando il dispositivo viene registrato in Azure AD. Quando un utente accede per la
prima volta tramite il browser, all'utente viene richiesto di selezionare il certificato. Per
continuare a usare il browser l'utente finale deve selezionare il certificato.
Le organizzazioni che usano la funzionalità attivazione della sottoscrizione per
consentire agli utenti di eseguire il "passaggio" da una versione di Windows a un'altra,
possono voler escludere le API del servizio di Archiviazione universale e l'applicazione
Web, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f dai criteri di conformità dei
dispositivi.
Passaggi successivi

condizionale
Funzionamento dei criteri di conformità del dispositivo con Azure AD

bloccare l'accesso per la piattaforma
dispositivo sconosciuta o non
supportata
Articolo • 11/03/2023
Gli utenti verranno bloccati all'accesso alle risorse aziendali quando il tipo di dispositivo
è sconosciuto o non supportato.


7. In Condizioni selezionare Piattaforme dispositivo
a. Impostare Configura su Sì.
b. In Includi selezionare Qualsiasi dispositivo
c. In Escludi selezionare Android, iOS, Windows e macOS.

Passaggi successivi

condizionale
richiedere app client approvate o criteri
di protezione delle app
Articolo • 31/03/2023
Gli utenti usano spesso i dispositivi mobili sia per le attività personali che per quelle di
lavoro. Assicurandosi che il personale possa essere produttivo, le organizzazioni
vogliono anche impedire la perdita di dati dalle applicazioni nei dispositivi che
potrebbero non gestire completamente.
Con l'accesso condizionale, le organizzazioni possono limitare l'accesso alle app client
approvate (con funzionalità di autenticazione moderna) con criteri di protezione delle
app Intune. Per le app client meno recenti che potrebbero non supportare i criteri di
protezione delle app, gli amministratori possono limitare l'accesso alle app client
approvate.
２ Avviso
Protezione di app criteri sono supportati solo in iOS e Android.
Non tutte le applicazioni supportate come applicazioni approvate o supportano i

criteri di protezione delle applicazioni. Per un elenco di alcune app client comuni,
vedere Protezione di app requisito dei criteri. Se l'applicazione non è elencata,
contattare lo sviluppatore dell'applicazione.
Per richiedere app client approvate per dispositivi iOS e Android, è necessario
registrare prima i dispositivi in Azure AD.
７ Nota
"Richiedi uno dei controlli selezionati" in controlli di concessione è simile a una

clausola OR. Questo viene usato nei criteri per consentire agli utenti di usare app
che supportano i criteri Richiedi protezione app o Richiedi controlli di concessione
dell'app client approvati . Richiedi criteri di protezione delle app vengono
applicati quando l'app supporta il controllo di concessione.
Per altre informazioni sui vantaggi dell'uso dei criteri di protezione delle app, vedere
l'articolo Protezione di app panoramica dei criteri.
I criteri seguenti vengono inseriti in modalità solo report per avviare in modo che gli
amministratori possano determinare l'impatto che avranno sugli utenti esistenti.
Quando gli amministratori sono sicuri che i criteri si applicano in base alle loro
intenzioni, possono passare a Attiva o fase della distribuzione aggiungendo gruppi
specifici ed esclusi altri.
Richiedere app client approvate o criteri di protezione

delle app con dispositivi mobili
La procedura seguente consente di creare criteri di accesso condizionale che richiedono
un'app client approvata o un criterio di protezione delle app quando si usa un
dispositivo iOS/iPadOS o Android. Questo criterio impedirà anche l'uso dei client
Exchange ActiveSync usando l'autenticazione di base nei dispositivi mobili. Questo
criterio funziona in combinazione con un criterio di protezione delle app creato in
Microsoft Intune.


b. In Escludi selezionare Utenti e gruppi ed escludere almeno un account per
impedire il blocco. Se non si escludono account, non è possibile creare i criteri.
7. In Condizioni>piattaforme dispositivo impostare Configura su Sì.
a. In Includiselezionare le piattaforme del dispositivo.
b. Scegliere Android e iOS
8. In Controlli di accesso>Concedi selezionare Concedi accesso.
a. Selezionare Richiedi app client approvata e Richiedi criteri di protezione delle
app
b. Per più controlli selezionare Richiedi uno dei controlli selezionati

Bloccare Exchange ActiveSync in tutti i dispositivi

Questo criterio impedisce a tutti i client di Exchange ActiveSync di connettersi
all'Exchange Online.

impedire il blocco. Se non si escludono account, non è possibile creare i criteri.
6. In App o azioni cloudselezionare Seleziona app.
a. Selezionare Office 365 Exchange Online.
7. In Condizioni>app client impostare Configura su Sì.
a. Deselezionare tutte le opzioni tranne i client Exchange ActiveSync.
a. Selezionare Richiedi criteri di protezione delle app

Passaggi successivi
Panoramica dei criteri di protezione app

Eseguire la migrazione dell'app client approvata ai criteri di protezione delle applicazioni
nell'accesso condizionale
richiedere la riautenticazione e
disabilitare la persistenza del browser
Articolo • 07/04/2023
Proteggere l'accesso utente nei dispositivi non gestiti impedendo alle sessioni del
browser di rimanere connessi dopo la chiusura del browser e impostando una frequenza
di accesso su 1 ora.
l'accesso.


7. In Condizioni>Filtra per i dispositivi impostare Configura su Sì.
a. In Dispositivi corrispondenti alla regola: impostare su Includi dispositivi filtrati
nei criteri.
b. In Sintassi regola selezionare la matita Modifica e incollare la seguente
espressione nella casella, quindi selezionare Applica.
i. device.trustType -ne "ServerAD" -or device.isCompliant -ne True
8. In Sessione controlli di accesso>
a. Selezionare Frequenza di accesso, specificare Riautenticazione periodica e
impostare la durata su 1 e il periodo su Ore.
b. Selezionare Sessione browser persistente e impostare Sessione browser
persistente su Mai persistente.
c. Selezionare, selezionare

Passaggi successivi

condizionale
richiedere un dispositivo conforme, un
dispositivo aggiunto ad Azure AD ibrido
o l'autenticazione a più fattori per tutti
gli utenti
Articolo • 17/03/2023
Le organizzazioni che hanno distribuito Microsoft Intune possono usare le informazioni

restituite dai dispositivi per identificare i dispositivi che soddisfano i requisiti di
conformità, ad esempio:
Richiesta di un PIN per sbloccare

Richiesta di crittografia dei dispositivi
Richiesta di una versione minima o massima del sistema operativo
La richiesta di un dispositivo non è jailbroken o root
Le informazioni di conformità dei criteri vengono inviate ad Azure AD in cui l'accesso

condizionale decide di concedere o bloccare l'accesso alle risorse. Altre informazioni sui
criteri di conformità dei dispositivi sono disponibili nell'articolo Impostare regole sui
dispositivi per consentire l'accesso alle risorse nell'organizzazione usando Intune
La richiesta di un dispositivo aggiunto ad Azure AD ibrido dipende dai dispositivi già

aggiunti ad Azure AD ibrido. Per altre informazioni, vedere l'articolo Configurare
l'aggiunta ad Azure AD ibrida.


l'autenticazione a più fattori, i dispositivi che accedono alle risorse vengono
contrassegnati come conformi ai criteri di conformità Intune dell'organizzazione o che
siano aggiunti ad Azure AD ibrido.

a. Se è necessario escludere applicazioni specifiche dai criteri, è possibile
selezionarle nella scheda Escludi in Seleziona app cloud escluse e scegliere
Seleziona.
a. Selezionare Richiedi l'autenticazione a più fattori, Richiedi che il dispositivo sia
contrassegnato come conforme e Richiedi dispositivo aggiunto ad Azure AD
ibrido
b. Per più controlli selezionare Richiedi uno dei controlli selezionati.

７ Nota
È possibile registrare i nuovi dispositivi in Intune anche se si seleziona Richiedi che

il dispositivo sia contrassegnato come conforme per Tutti gli utenti e Tutte le app
cloud usando i passaggi precedenti. Richiedere che il dispositivo sia
contrassegnato come controllo conforme non blocca la registrazione Intune e
l'accesso all'applicazione Microsoft Intune Web Portale aziendale.
Comportamento noto
In Windows 7, iOS, Android, macOS e alcuni Web browser di terze parti, Azure AD
identifica il dispositivo usando un certificato client di cui viene effettuato il provisioning
quando il dispositivo viene registrato in Azure AD. Quando un utente accede per la
prima volta tramite il browser, viene richiesto di selezionare il certificato. Per continuare
a usare il browser l'utente finale deve selezionare il certificato.
Le organizzazioni che usano la funzionalità Attivazione sottoscrizione per consentire agli
utenti di "eseguire il passaggio" da una versione di Windows a un'altra, potrebbero voler
escludere le API del servizio universal Store e l'applicazione Web, AppID 45a30b1-b1ec-
4cc1-9161-9f03992a49f dai criteri di accesso condizionale.
Passaggi successivi

condizionale
Funzionamento dei criteri di conformità del dispositivo con Azure AD

usare le restrizioni applicate
dall'applicazione per i dispositivi non
gestiti
Articolo • 07/04/2023
Bloccare o limitare l'accesso a SharePoint, OneDrive e Contenuto exchange da dispositivi

non gestiti.


a. In Includi scegliere Seleziona app.
b. Scegliere Office 365, quindi selezionare Seleziona.
7. In Controlli di accesso>Sessione selezionare Usa restrizioni applicate dall'app e
quindi selezionare Seleziona.

Passaggi successivi

condizionale
per le registrazioni di dispositivi Intune
Articolo • 04/04/2023
Si applica a:
Android
iOS/iPadOS
macOS
Windows 8.1
Windows 10
Windows 11
È possibile usare Intune insieme ai criteri di accesso condizionale di Azure Active

Directory (Azure AD) per richiedere l'autenticazione a più fattori durante la registrazione
del dispositivo. Se è necessaria l'autenticazione a più fattori, i dipendenti e gli studenti
che vogliono registrare i dispositivi devono prima eseguire l'autenticazione con un
secondo dispositivo e due forme di credenziali. MFA richiede che eseguano
l'autenticazione usando due o più di questi metodi di verifica:
Un elemento noto, ad esempio una password o un PIN.

Qualcosa che non può essere duplicato, ad esempio un dispositivo o un telefono
attendibile.
Qualcosa che sei, ad esempio un'impronta digitale.
Prerequisiti
Per implementare questo criterio, è necessario assegnare Azure Active Directory
Premium P1 o versioni successive agli utenti.
Configurare Intune per richiedere

l'autenticazione a più fattori durante la
registrazione del dispositivo
Completare questi passaggi per abilitare l'autenticazione a più fattori durante la
registrazione Microsoft Intune.
） Importante
Non configurare le regole di accesso basate su dispositivo per la registrazione
Microsoft Intune.
1. Accedere all'interfaccia di amministrazione Microsoft Intune .
2. Passare a Dispositivi>Accesso condizionale. Questa area è identica all'area di

accesso condizionale disponibile in Azure AD. Per altre informazioni sulle
impostazioni disponibili, vedere App cloud o azioni.
3. Selezionare Nuovo criterio.
4. Assegnare un nome ai criteri.
5. Selezionare la categoria Utenti o identità del carico di lavoro .

a. Nella scheda Includi scegliere Seleziona utenti o gruppi.
b. Vengono visualizzate altre opzioni. Selezionare Utenti e gruppi.
c. Aggiungere gli utenti o i gruppi a cui si assegnano i criteri e quindi scegliere
Seleziona.
d. Per escludere utenti o gruppi dai criteri, selezionare la scheda Escludi e
aggiungere tali utenti o gruppi.
6. Selezionare la categoria successiva, App cloud o azioni.

a. Selezionare la scheda Includi .
b. Scegliere Seleziona app>Selezionare.
c. Scegliere Microsoft Intune Registrazione>Selezionare per aggiungere l'app.
Usare la barra di ricerca nel selettore dell'app per trovare l'app.
Per le registrazioni automatizzate dei dispositivi Apple con Assistente

configurazione con l'autenticazione moderna, è possibile scegliere tra due opzioni.
Nella tabella seguente viene descritta la differenza tra l'opzione Microsoft Intune e
l'opzione registrazione Microsoft Intune.
App cloud Percorso del Note sulla registrazione automatica dei

prompt dispositivi
dell'autenticazione
a più fattori
Microsoft Assistente Con questa opzione, l'autenticazione a più fattori è

Intune configurazione,
necessaria durante la registrazione e ogni volta che
Portale l'utente accede all'app o al sito Web Portale
aziendale'app aziendale. I prompt MFA vengono visualizzati nella
pagina di accesso Portale aziendale.
App cloud Percorso del Note sulla registrazione automatica dei
prompt dispositivi
dell'autenticazione
a più fattori
Registrazione Assistente Con questa opzione, l'autenticazione a più fattori è

Microsoft installazione necessaria durante la registrazione del dispositivo e
Intune viene visualizzata come richiesta di autenticazione a
più fattori una tantum nella pagina di accesso
Portale aziendale.
7. In Condizioni non è necessario configurare alcuna impostazione per MFA.
8. Selezionare la categoria Concedi .

a. Selezionare Richiedi autenticazione a più fattori e Richiedi che il dispositivo
sia contrassegnato come conforme.
b. In Per più controlli selezionare Richiedi tutti i controlli selezionati.
9. Selezionare la categoria Sessione .

a. Selezionare Frequenza di accesso e scegliere Ogni volta.
10. In Abilita criterio selezionare Sì.
11. Selezionare Crea per salvare e creare i criteri.
Dopo aver applicato e distribuito questo criterio, gli utenti visualizzeranno una richiesta
di autenticazione a più fattori una tantum quando registrano il dispositivo.
７ Nota
È necessario un secondo dispositivo per completare la richiesta di autenticazione a

più fattori per questi tipi di dispositivi di proprietà dell'azienda:
Dispositivi Android Enterprise completamente gestiti

Dispositivi Android Enterprise di proprietà dell'azienda con un profilo di
lavoro
Dispositivi iOS/iPadOS registrati tramite registrazione automatica dei
dispositivi Apple
Dispositivi macOS registrati tramite registrazione automatica dei dispositivi
Apple
Il secondo dispositivo è necessario perché il dispositivo primario non può ricevere
chiamate o sms durante il processo di provisioning.
Accesso condizionale: Bloccare l'accesso
in base alla località
Articolo • 17/03/2023
Con la condizione relativa alla posizione nell'accesso condizionale, è possibile

controllare l'accesso alle app cloud in base al percorso di rete dell'utente. La condizione
relativa alla posizione viene comunemente usata per bloccare l'accesso da paesi o aree
geografiche da cui non dovrebbe provenire traffico verso l'organizzazione. Per altre
informazioni sul supporto IPv6, vedere l'articolo Supporto IPv6 in Azure Active Directory.
７ Nota

l'accesso.
Definire le posizioni
specifiche.
3. Scegliere Nuova posizione.
4. Assegnare un nome alla posizione.
5. Scegliere Intervalli IP se si conoscono gli specifici intervalli di indirizzi IPv4
accessibili dall'esterno che fanno parte di tale posizione o di tali Paesi/aree
geografiche.
a. Specificare gli intervalli IP o selezionare i paesi/aree geografiche per la località
specificata.
Se si sceglie Paesi/aree geografiche, è possibile scegliere di includere aree

sconosciute.
6. Scegliere Salva
Altre informazioni sulla condizione relativa alla posizione nell'accesso condizionale sono
disponibili nell'articolo Condizione relativa alla posizione nell'accesso condizionale di
Azure Active Directory

7. In Condizioni>Posizione
a. impostare Configura su Sì
b. In Includi selezionare Località selezionate
c. Selezionare la posizione bloccata creata per l'organizzazione.
d. Fare clic su Seleziona.
8. In Controlli> di accesso selezionare Blocca accesso e fare clic su Seleziona.

Passaggi successivi

condizionale
Accesso condizionale: Blocca l'accesso
Articolo • 11/03/2023
Per le organizzazioni con un approccio di migrazione cloud conservativo, il criterio di

blocco di tutti gli utenti è un'opzione utilizzabile.
Ｕ Attenzione
La configurazione errata di un criterio di blocco può comportare il blocco delle

organizzazioni dal portale di Azure.
I criteri di questo tipo possono avere effetti collaterali imprevisti. L'esecuzione

appropriata di test e della convalida è fondamentale prima dell'abilitazione. Gli
amministratori devono usare strumenti come la modalità di solo report di accesso
condizionale e lo strumento What If nell'accesso condizionale durante l'esecuzione delle
modifiche.

La procedura seguente consente di creare criteri di accesso condizionale per bloccare
l'accesso a tutte le app, ad eccezione di Office 365 se gli utenti non sono in una rete
attendibile. Questi criteri vengono inseriti in modalità solo report per avviare in modo
che gli amministratori possano determinare l'impatto che avranno sugli utenti esistenti.
Quando gli amministratori sono sicuri che i criteri verranno applicati come previsto,
possono attivarli.
Il primo criterio blocca l'accesso a tutte le app, ad eccezione delle applicazioni Microsoft
365, se l'utente non è in una posizione attendibile.

a. In Includi selezionare Tutte le app cloud.
b. In Escludi selezionare Office 365selezionare Seleziona.
7. In Condizioni:
a. In Condizioni>Posizione
i. impostare Configura su Sì
ii. In Includi selezionare Tutte le località.
iii. In Escludi selezionare Tutte le posizioni attendibili.
b. In App client impostare Configura su Sì e selezionare Fine.

Di seguito viene creato un secondo criterio per richiedere l'autenticazione a più fattori o
un dispositivo conforme per gli utenti di Microsoft 365.

4. In App cloud o azioni>Includi selezionare Seleziona app, scegliere Office 365 e
selezionare Seleziona.
a. Selezionare Richiedi autenticazione a più fattori e Richiedi che il dispositivo
sia contrassegnato come conformeselezionare Seleziona.
b. Assicurarsi che l'opzione Richiedi uno dei controlli selezionati sia selezionata.

７ Nota

l'accesso.
Passaggi successivi

condizionale
Accesso condizionale: richiedere un
livello di autenticazione per gli utenti
esterni
Articolo • 10/05/2023
La forza di autenticazione è un controllo di accesso condizionale che consente di

definire una combinazione specifica di metodi di autenticazione a più fattori che un
utente esterno deve completare per accedere alle risorse. Questo controllo è
particolarmente utile per limitare l'accesso esterno alle app sensibili nell'organizzazione.
Ad esempio, è possibile creare criteri di accesso condizionale, richiedere un livello di
autenticazione resistente al phishing nei criteri e assegnarlo agli utenti guest ed esterni.
Azure AD offre tre punti di forza di autenticazione predefiniti :
Forza di autenticazione a più fattori

Forza MFA senza password
Forza MFA resistente al phishing
È possibile usare uno dei punti di forza predefiniti o creare una forza di autenticazione
personalizzata in base ai metodi di autenticazione da richiedere.
Negli scenari utente esterni, i metodi di autenticazione MFA che un tenant di risorse può
accettare variano a seconda che l'utente stia completando l'autenticazione a più fattori
nel tenant principale o nel tenant della risorsa. Per informazioni dettagliate, vedere Forza
di autenticazione di accesso condizionale .
７ Nota
Attualmente è possibile applicare solo i criteri di forza di autenticazione agli utenti

esterni che eseguono l'autenticazione con Azure AD. Per il passcode di posta
elettronica one-time, SAML/WS-Fed e gli utenti della federazione Google, usare il
controllo di concessione MFA per richiedere l'autenticazione a più fattori.
Configurare le impostazioni di accesso tra

tenant per l'autenticazione a più fattori
I criteri di forza di autenticazione interagiscono con le impostazioni di attendibilità MFA
nelle impostazioni di accesso tra tenant per determinare dove e come l'utente esterno
deve eseguire MFA. Un utente di Azure AD esegue prima l'autenticazione con il proprio
account nel tenant di casa. Quando l'utente tenta di accedere alla risorsa, Azure AD
applica i criteri di accesso condizionale di livello di autenticazione e verifica se è stata
abilitata l'attendibilità MFA.
Se l'attendibilità MFA è abilitata, Azure AD controlla la sessione di autenticazione

dell'utente per un'attestazione che indica che l'autenticazione a più fattori è stata
soddisfatta nel tenant principale dell'utente.
Se il trust MFA è disabilitato, il tenant delle risorse presenta all'utente una sfida
per completare l'autenticazione a più fattori nel tenant delle risorse usando un
metodo di autenticazione accettabile.
I metodi di autenticazione che gli utenti esterni possono usare per soddisfare i requisiti
MFA sono diversi a seconda che l'utente stia completando l'autenticazione a più fattori
nel tenant principale o nel tenant della risorsa. Vedere la tabella in Livello di
autenticazione di accesso condizionale .
） Importante
Prima di creare i criteri di accesso condizionale, controllare le impostazioni di

accesso tra tenant per assicurarsi che le impostazioni di attendibilità MFA in
ingresso siano configurate come previsto.
Scegliere un livello di forza di autenticazione

Determinare se uno dei punti di forza di autenticazione predefiniti funzionerà per lo
scenario o se è necessario creare un livello di autenticazione personalizzato.
1. Accedere al portale di Azure come amministratore globale, amministratore della

sicurezza o amministratore dell'accesso condizionale.
2. Passare aimetodi>di autenticazionedella sicurezza> di Azure Active Directory>.
3. Esaminare i punti di forza di autenticazione predefiniti per verificare se uno di essi
soddisfa i requisiti.
4. Se si vuole applicare un set diverso di metodi di autenticazione, creare un livello di
forza di autenticazione personalizzato .

Usare la procedura seguente per creare criteri di accesso condizionale che applicano un
livello di forza di autenticazione agli utenti esterni.
sicurezza o amministratore dell'accesso condizionale.

6. In Includi scegliere Seleziona utenti e gruppi e quindi selezionareGuest o utenti

esterni.
7. Selezionare i tipi di utenti guest o esterni a cui si desidera applicare i criteri.
8. In Escludi selezionare Utenti e gruppi e scegliere gli account di accesso di

9. In App o azioni cloud selezionare tutte le applicazioni che si desidera includere o

escludere dai requisiti di forza di autenticazione.
10. In Controlli> di accessoConcedere:

a. Scegliere Concedi accesso.
b. Selezionare Richiedi forza di autenticazione e quindi selezionare la forza di
autenticazione predefinita o personalizzata dall'elenco.

Passaggi successivi

condizionale
Accesso condizionale: impostazioni
predefinite di resilienza
Articolo • 21/03/2023
Se si è verificato un'interruzione del servizio di autenticazione primaria, il servizio di

autenticazione di backup di Azure Active Directory (Azure AD) può generare
automaticamente token di accesso alle applicazioni per le sessioni esistenti. Questa
funzionalità può aumentare in modo significativo la resilienza di Azure AD, perché le
riutenzioni per le sessioni esistenti rappresentano più del 90% delle autenticazione in
Azure AD. Il servizio di autenticazione di backup non supporta nuove sessioni o
autenticazioni da parte degli utenti guest.
Per le autenticazione protette dall'accesso condizionale, i criteri vengono rivalutati prima

dell'emissione dei token di accesso per determinare:
1. Quali criteri di accesso condizionale si applicano?

2. Per i criteri che si applicano, i controlli necessari sono soddisfatti?
Durante un'interruzione, non tutte le condizioni possono essere valutate in tempo reale
dal servizio di autenticazione di backup per determinare se deve essere applicato un
criterio di accesso condizionale. Le impostazioni predefinite di resilienza dell'accesso
condizionale sono un nuovo controllo sessione che consente agli amministratori di
decidere tra:
Se bloccare le autenticazione durante un'interruzione ogni volta che una

condizione di criterio non può essere valutata in tempo reale.
Consentire la valutazione dei criteri usando i dati raccolti all'inizio della sessione
dell'utente.
） Importante
Le impostazioni predefinite di resilienza sono abilitate automaticamente per tutti i

criteri nuovi e esistenti e Microsoft consiglia di lasciare le impostazioni predefinite
di resilienza abilitate per ridurre l'impatto di un'interruzione. Gli amministratori
possono disabilitare le impostazioni predefinite di resilienza per i singoli criteri di
Come funziona?
Durante un'interruzione, il servizio di autenticazione di backup ripubblicerà
automaticamente i token di accesso per determinate sessioni:
Descrizione sessione Accesso concesso
Nuova sessione No
Sessione esistente: non sono configurati criteri di accesso Sì

condizionale
Sessione esistente: i criteri di accesso condizionale configurati e i Sì

controlli necessari, ad esempio MFA, sono stati soddisfatti in
precedenza
Sessione esistente: i criteri di accesso condizionale configurati e i Determinato dalle

controlli necessari, ad esempio MFA, non sono stati soddisfatti in impostazioni predefinite
precedenza di resilienza
Quando una sessione esistente scade durante un'interruzione di Azure AD, la richiesta di
un nuovo token di accesso viene indirizzata al servizio di autenticazione di backup e tutti
i criteri di accesso condizionale vengono rivalutati. Se non sono presenti criteri di
accesso condizionale o tutti i controlli necessari, ad esempio MFA, sono stati soddisfatti
in precedenza all'inizio della sessione, il servizio di autenticazione di backup rilascia un
nuovo token di accesso per estendere la sessione.
Se i controlli necessari di un criterio non sono stati soddisfatti in precedenza, il criterio

viene rivalutato per determinare se l'accesso deve essere concesso o negato. Tuttavia,
non tutte le condizioni possono essere rivalutate in tempo reale durante un'interruzione.
Alcune di queste condizioni sono indicate di seguito:
Appartenenza al gruppo
Appartenenza al ruolo
Rischio di accesso
Rischio utente
Posizione del paese (risoluzione di nuove coordinate IP o GPS)
Punti di forza di autenticazione
Quando attivo, il servizio di autenticazione di backup non valuta i metodi di

autenticazione richiesti dai punti di forza di autenticazione. Se si usa un metodo di
autenticazione non resistente al phishing prima di un'interruzione, durante
un'interruzione non viene richiesta l'autenticazione a più fattori anche se si accede a una
risorsa protetta da criteri di accesso condizionale con un livello di autenticazione
resistente al phishing.
Impostazioni predefinite di resilienza abilitate
Quando le impostazioni predefinite di resilienza sono abilitate, il servizio di
autenticazione di backup può usare i dati raccolti all'inizio della sessione per valutare se
i criteri devono essere applicati in assenza di dati in tempo reale. Per impostazione
predefinita, tutti i criteri avranno le impostazioni predefinite di resilienza abilitate.
L'impostazione può essere disabilitata per i singoli criteri quando è necessaria la
valutazione dei criteri in tempo reale per l'accesso alle applicazioni sensibili durante
un'interruzione.
Esempio: un criterio con impostazioni predefinite di resilienza abilitato richiede a tutti gli
amministratori globali di accedere alla portale di Azure per eseguire l'autenticazione a
più fattori. Prima di un'interruzione, se un utente che non è un amministratore globale
accede al portale di Azure, il criterio non verrà applicato e l'utente verrà concesso
l'accesso senza essere richiesto per l'autenticazione a più fattori. Durante
un'interruzione, il servizio di autenticazione di backup rivaluta i criteri per determinare se
l'utente deve essere richiesto per l'autenticazione a più fattori. Poiché il servizio di
autenticazione di backup non può valutare l'appartenenza al ruolo in tempo reale,
userebbe i dati raccolti all'inizio della sessione dell'utente per determinare che i criteri
non devono ancora essere applicati. Di conseguenza, l'utente verrà concesso l'accesso
senza essere richiesto per l'autenticazione a più fattori.
Impostazioni predefinite di resilienza

disabilitate
Quando le impostazioni predefinite di resilienza sono disabilitate, il servizio di
autenticazione di backup non userà i dati raccolti all'inizio della sessione per valutare le
condizioni. Durante un'interruzione, se una condizione di criteri non può essere valutata
in tempo reale, l'accesso verrà negato.
Esempio: un criterio con impostazioni predefinite di resilienza disabilitate richiede a tutti

gli amministratori globali di accedere alla portale di Azure per eseguire l'autenticazione
a più fattori. Prima di un'interruzione, se un utente che non è un amministratore globale
accede al portale di Azure, il criterio non verrà applicato e l'utente verrà concesso
l'accesso senza essere richiesto per l'autenticazione a più fattori. Durante
un'interruzione, il servizio di autenticazione di backup rivaluta i criteri per determinare se
l'utente deve essere richiesto per l'autenticazione a più fattori. Poiché il servizio di
autenticazione di backup non può valutare l'appartenenza al ruolo in tempo reale,
l'utente potrebbe accedere al portale di Azure.
２ Avviso
Disabilitando le impostazioni predefinite di resilienza per un criterio che si applica a

un gruppo o a un ruolo ridurrà la resilienza per tutti gli utenti del tenant. Poiché
l'appartenenza a gruppi e ruoli non può essere valutata in tempo reale durante
un'interruzione, anche gli utenti che non appartengono al gruppo o al ruolo
nell'assegnazione dei criteri verranno negati l'accesso all'applicazione nell'ambito
dei criteri. Per evitare di ridurre la resilienza per tutti gli utenti non nell'ambito dei
criteri, è consigliabile applicare i criteri a singoli utenti anziché a gruppi o ruoli.
Test delle impostazioni predefinite di resilienza

Non è possibile eseguire un'esecuzione secca usando il servizio di autenticazione di
backup o simulare il risultato di un criterio con impostazioni predefinite di resilienza
abilitate o disabilitate in questo momento. Azure AD eseguirà esercizi mensili usando il
servizio di autenticazione di backup. I log di accesso visualizzeranno se il servizio di
autenticazione di backup è stato usato per rilasciare il token di accesso. Nel pannellolog
di accesso portale di Azure>Monitoring> è possibile aggiungere il filtro "Tipo di
autorità di certificazione token == Azure AD Backup Auth" per visualizzare i log
elaborati dal servizio Azure AD Backup Authentication.
Configurazione delle impostazioni predefinite

di resilienza
È possibile configurare le impostazioni predefinite di resilienza dell'accesso condizionale
dalle API di portale di Azure, MS Graph o PowerShell.
Portale di Azure
1. Passareall'accesso condizionaleportale di Azure>Security>
2. Creare un nuovo criterio o selezionare un criterio esistente
3. Aprire le impostazioni del controllo Sessione
4. Selezionare Disabilita le impostazioni predefinite di resilienza per disabilitare
l'impostazione per questo criterio. Gli accessi nell'ambito dei criteri verranno
bloccati durante un'interruzione di Azure AD
5. Salvare le modifiche apportate ai criteri
API MS Graph
È anche possibile gestire le impostazioni predefinite di resilienza per i criteri di accesso
condizionale usando il API Graph MS e Microsoft Graph Explorer.
URL richiesta di esempio:
PATCH
https://graph.microsoft.com/beta/identity/conditionalAccess/policies/policyId
Corpo della richiesta di esempio:
JSON
"sessionControls": {
"disableResilienceDefaults": true
PowerShell
Questa operazione di patch può essere distribuita usando Microsoft PowerShell dopo
l'installazione del modulo Microsoft.Graph.Authentication. Per installare questo modulo,
aprire un prompt di PowerShell con privilegi elevati ed eseguire
PowerShell
Install-Module Microsoft.Graph.Authentication
Connettersi a Microsoft Graph, richiedendo gli ambiti necessari:
PowerShell
Connect-MgGraph -Scopes
Policy.Read.All,Policy.ReadWrite.ConditionalAccess,Application.Read.All -
TenantId <TenantID>
Eseguire l'autenticazione quando richiesto.
Creare il corpo JSON per la richiesta PATCH:
PowerShell
$patchBody = '{"sessionControls": {"disableResilienceDefaults": true}}'
Eseguire l'operazione di patch:
PowerShell
Invoke-MgGraphRequest -Method PATCH -Uri

https://graph.microsoft.com/beta/identity/conditionalAccess/policies/<Policy
ID> -Body $patchBody
Consigli
Microsoft consiglia di abilitare le impostazioni predefinite di resilienza. Sebbene non
siano presenti problemi di sicurezza diretti, i clienti devono valutare se vogliono
consentire al servizio di autenticazione di backup di valutare i criteri di accesso
condizionale durante un'interruzione usando i dati raccolti all'inizio della sessione
anziché in tempo reale.
È possibile che l'appartenenza a un utente o a un gruppo venga modificata dall'inizio

della sessione. Con La valutazione dell'accesso continuo (CAE), i token di accesso sono
validi per 24 ore, ma soggetti a eventi di revoca istantanea. Il servizio di autenticazione
di backup sottoscrive la stessa CAE degli eventi di revoca. Se il token di un utente viene
revocato come parte di CAE, l'utente non è in grado di accedere durante
un'interruzione. Quando le impostazioni predefinite di resilienza sono abilitate, le
sessioni esistenti che scadono durante un'interruzione verranno estese. Le sessioni
vengono estese anche se i criteri sono stati configurati con un controllo sessione per
applicare una frequenza di accesso. Ad esempio, un criterio con impostazioni predefinite
di resilienza abilitate può richiedere che gli utenti riutentino ogni ora per accedere a un
sito di SharePoint. Durante un'interruzione, la sessione dell'utente verrà estesa anche se
Azure AD potrebbe non essere disponibile per riutentare l'utente.
Passaggi successivi
Valutazione dell'accesso continuo (CAE)
Informazioni dettagliate e report di
Accesso condizionale
Articolo • 18/03/2023
La cartella di lavoro Informazioni dettagliate e report di Accesso condizionale consente

di conoscere l'impatto dei criteri di accesso condizionale dell'organizzazione nel tempo.
Durante l'accesso, è possibile applicare uno o più criteri di accesso condizionale,
concedendo l'accesso se vengono soddisfatti alcuni controlli di concessione o negando
l'accesso in caso contrario. Dato che durante ogni accesso possono essere valutati più
criteri di accesso condizionale, la cartella di lavoro Informazioni dettagliate e report
consente di esaminare l'impatto dei singoli criteri o di un sottoinsieme di tutti i criteri.
Prerequisiti
Per abilitare la cartella di lavoro Informazioni dettagliate e report, il tenant deve avere
un'area di lavoro Log Analytics per conservare i dati dei log di accesso. Per usare
l'accesso condizionale, gli utenti devono avere licenze di Azure AD Premium P1 o P2.
Gli utenti devono avere almeno il ruolo lettore di sicurezza assegnato e i ruoli
collaboratore dell'area di lavoro Log Analytics assegnati.
Eseguire lo streaming dei log di accesso da Azure AD ai

log di Monitoraggio di Azure
Se i log di Azure AD non sono stati integrati con i log di Monitoraggio di Azure, è
necessario seguire questa procedura prima del caricamento della cartella di lavoro:
1. Creare un'area di lavoro Log Analytics in Monitoraggio di Azure.

2. Integrare i log di Azure AD con i log di Monitoraggio di Azure.
Funzionamento
Per accedere alla cartella di lavoro Informazioni dettagliate e report:
1. Accedere al portale di Azure.

2. Passare ad Azure Active Directory>Sicurezza>Accesso
condizionale>Informazioni dettagliate e report.
Per iniziare: selezionare i parametri

Il dashboard Informazioni dettagliate e report consente di visualizzare l'impatto di uno o
più criteri di accesso condizionale in un periodo di tempo specificato. Per iniziare,
impostare ognuno dei parametri nella parte superiore della cartella di lavoro.
Criteri di accesso condizionale: selezionare uno o più criteri di accesso condizionale per
visualizzarne l'impatto combinato. I criteri sono suddivisi in due gruppi: criteri abilitati e
in modalità solo report. Per impostazione predefinita, sono selezionati tutti i criteri
abilitati, che sono i criteri attualmente applicati nel tenant.
Intervallo di tempo: selezionare un intervallo di tempo da 4 ore a 90 giorni prima. Se si

seleziona un intervallo di tempo più indietro rispetto al momento dell'integrazione dei
log di Azure AD con Monitoraggio di Azure, vengono visualizzati solo gli accessi dopo
l'ora di integrazione.
Utente: per impostazione predefinita, il dashboard mostra l'impatto dei criteri

selezionati per tutti gli utenti. Per filtrare un singolo utente, digitarne il nome nel campo
di testo. Per filtrare tutti gli utenti, digitare "Tutti gli utenti" nel campo di testo o lasciare
vuoto il parametro.
App: per impostazione predefinita, il dashboard mostra l'impatto dei criteri selezionati
per tutte le app. Per filtrare una singola app, digitarne il nome nel campo di testo. Per
filtrare tutte le app, digitare "Tutte le app" nel campo di testo o lasciare vuoto il
parametro.
Data view (Visualizzazione dati): selezionare se si vuole che i risultati vengano
visualizzati nel dashboard in termini di numero di utenti o numero di accessi. In un
determinato intervallo di tempo, un singolo utente può avere centinaia di accessi a
numerose app con molti risultati diversi. Se si seleziona la visualizzazione dati per essere
utenti, un utente potrebbe essere incluso nel conteggio degli errori e dell'esito positivo.
Ad esempio, se ci sono 10 utenti, 8 di essi potrebbero avere avuto un risultato di
successo negli ultimi 30 giorni e 9 di loro potrebbero avere avuto un risultato di errore
negli ultimi 30 giorni.
Riepilogo dell'impatto
Dopo l'impostazione dei parametri, viene caricato il riepilogo dell'impatto. Il riepilogo
mostra il numero di utenti o di accessi per i quali, nell'intervallo di tempo, il risultato con
la valutazione dei criteri selezionati è stato "Operazione riuscita", "Errore", "È richiesto
l'intervento dell'utente" o "Non applicato".
Total: numero di utenti o di accessi durante il periodo di tempo in cui è stato valutato
almeno uno dei criteri selezionati.
Operazione riuscita: numero di utenti o di accessi durante il periodo di tempo in cui il

risultato combinato dei criteri selezionati è stato "Operazione riuscita" o "Solo report:
Operazione riuscita".
Operazione non riuscita: numero di utenti o di accessi durante il periodo di tempo in

cui il risultato di almeno uno dei criteri selezionati è stato "Errore" o "Solo report:
Errore".
È richiesto l'intervento dell'utente: numero di utenti o di accessi durante il periodo di

tempo in cui il risultato combinato dei criteri selezionati è stato "Solo report: Intervento
utente necessario". L'azione utente è necessaria quando è necessario un controllo di
concessione interattivo, ad esempio l'autenticazione a più fattori. Poiché i controlli di
concessione interattiva non vengono applicati dai criteri di solo report, non è possibile
determinare l'esito positivo o negativo.
Non applicato: numero di utenti o di accessi durante il periodo di tempo in cui nessuno
dei criteri selezionati è stato applicato.
Informazioni sull'impatto
Visualizzare il dettaglio degli utenti o degli accessi per ognuna delle condizioni. È
possibile filtrare gli accessi di un determinato risultato (ad esempio, Operazione riuscita
o Errore) selezionando i riquadri di riepilogo nella parte superiore della cartella di lavoro.
È possibile visualizzare il dettaglio degli accessi per ognuna delle condizioni di accesso
condizionale: stato del dispositivo, piattaforma del dispositivo, app client, località,
applicazione e rischio di accesso.
Dettagli di accesso
È anche possibile esaminare gli accessi di un utente specifico cercando gli accessi nella
parte inferiore del dashboard. La query visualizza gli utenti più frequenti. Se si seleziona
un utente, la query viene filtrata.
７ Nota
Quando si scaricano i log di accesso, scegliere il formato JSON per includere i dati
dei risultati solo del report di accesso condizionale.
Configurare criteri di accesso condizionale in
modalità solo report
Per configurare criteri di accesso condizionale in modalità solo report:

3. Selezionare un criterio esistente o creare un nuovo criterio.
4. In Abilita criterio impostare l'interruttore su Modalità solo report .
5. Selezionare Salva
 Suggerimento
La modifica dello stato Abilita criteri di un criterio esistente da On a Report

disabilita l'applicazione dei criteri esistenti.
Risoluzione dei problemi
Perché le query hanno esito negativo a causa di un errore

delle autorizzazioni?
Per accedere alla cartella di lavoro, sono necessarie le autorizzazioni appropriate per
l'area di lavoro di Azure AD e l'area di lavoro Log Analytics. Per verificare se si dispone
delle autorizzazioni appropriate per l'area di lavoro eseguendo una query di log
analytics di esempio:
1. Accedere al portale di Azure.

2. Passare ad Azure Active Directory>Log Analytics.
3. Digitare SigninLogs nella casella di query e selezionare Esegui.
4. Se la query non restituisce risultati, l'area di lavoro potrebbe non essere stata
configurata correttamente.
Per altre informazioni su come trasmettere i log di accesso di Azure AD a un'area di
lavoro Log Analytics, vedere l'articolo Integrare i log di Azure AD con i log di
Monitoraggio di Azure.
Perché le query nella cartella di lavoro hanno esito

negativo?
I clienti hanno notato che le query a volte non riescono se le aree di lavoro sbagliate o
più aree di lavoro sono associate alla cartella di lavoro. Per risolvere questo problema,
selezionare Modifica nella parte superiore della cartella di lavoro e quindi l'ingranaggio
Impostazioni. Selezionare e quindi rimuovere le aree di lavoro che non sono associate
alla cartella di lavoro. Deve essere presente un'unica area di lavoro associata a ogni
cartella di lavoro.
Perché il parametro criteri di accesso condizionale è

vuoto?
L'elenco dei criteri viene generato esaminando i criteri valutati per l'evento di accesso
più recente. Se nel tenant non sono presenti accessi recenti, potrebbe essere necessario
attendere alcuni minuti per caricare l'elenco dei criteri di accesso condizionale. I risultati
vuoti possono verificarsi immediatamente dopo la configurazione di Log Analytics o se
un tenant non ha attività di accesso recenti.
Perché il caricamento della cartella di lavoro richiede

molto tempo?
A seconda dell'intervallo di tempo selezionato e delle dimensioni del tenant, la cartella
di lavoro potrebbe valutare un numero estremamente elevato di eventi di accesso. Per i
tenant di grandi dimensioni, il volume degli accessi potrebbe superare la capacità di
query di Log Analytics. Provare a ridurre l'intervallo di tempo a 4 ore per verificare se la
cartella di lavoro viene caricata.
Perché, dopo un caricamento durato alcuni minuti, la

cartella di lavoro restituisce zero risultati?
Quando il volume di accessi supera la capacità di query di Log Analytics, la cartella di
lavoro restituisce zero risultati. Provare a ridurre l'intervallo di tempo a 4 ore per
verificare se la cartella di lavoro viene caricata.
È possibile salvare le selezioni dei parametri?

È possibile salvare le selezioni dei parametri nella parte superiore della cartella di lavoro,
passando ad Azure Active Directory>Cartelle di lavoro>Conditional Access Insights
and reporting (Informazioni dettagliate e report di Accesso condizionale). Ecco il
modello di cartella di lavoro, in cui è possibile modificare la cartella di lavoro e salvare
una copia nell'area di lavoro, incluse le selezioni dei parametri, in Report personali o
report condivisi.
È possibile modificare e personalizzare la cartella di

lavoro con altre query?
È possibile modificare e personalizzare la cartella di lavoro passando ad Azure Active
Directory>Cartelle di lavoro>Conditional Access Insights and reporting (Informazioni
dettagliate e report di Accesso condizionale). Ecco il modello di cartella di lavoro, in cui
è possibile modificare la cartella di lavoro e salvare una copia nell'area di lavoro, incluse
le selezioni dei parametri, in Report personali o report condivisi. Per iniziare a
modificare le query, selezionare Modifica nella parte superiore della cartella di lavoro.
Passaggi successivi
Modalità solo report dell'accesso condizionale
Per altre informazioni sulle cartelle di lavoro di Azure AD, vedere l'articolo Come
usare cartelle di lavoro di Monitoraggio di Azure per i report di Azure Active
Directory.
Bloccare l'autenticazione legacy con
Azure AD con l'accesso condizionale
Articolo • 11/03/2023
Per consentire agli utenti di accedere facilmente alle app cloud, Azure Active Directory
(Azure AD) supporta una vasta gamma di protocolli di autenticazione, inclusa
l'autenticazione legacy. Tuttavia, l'autenticazione legacy non supporta elementi come
l'autenticazione a più fattori (MFA). L'autenticazione a più fattori è un requisito comune
per migliorare il comportamento di sicurezza nelle organizzazioni.
７ Nota
A partire dal 1° ottobre 2022, inizieremo a disabilitare in modo permanente

l'autenticazione di base per Exchange Online in tutti i tenant di Microsoft 365
indipendentemente dall'utilizzo, ad eccezione dell'autenticazione SMTP. Per altre
informazioni, vedere l'articolo Deprecazione dell'autenticazione di base in
Exchange Online
Alex Weinert, Direttore della sicurezza delle identità di Microsoft, nel post di blog del 12
marzo 2020 Nuovi strumenti per bloccare l'autenticazione legacy nell'organizzazione
sottolineano perché le organizzazioni devono bloccare l'autenticazione legacy e quali
altri strumenti microsoft fornisce per eseguire questa attività:
Affinché l'autenticazione MFA sia efficace, è anche necessario bloccare

l'autenticazione legacy. I protocolli di autenticazione legacy come POP, SMTP, IMAP
e MAPI, infatti, non possono imporre l'autenticazione MFA e costituiscono pertanto i
punti di ingresso preferiti dagli antagonisti che attaccano l'organizzazione...
...I numeri relativi all'autenticazione legacy risultanti da un'analisi del traffico di

Azure Active Directory (Azure AD) sono chiari:
Oltre il 99% degli attacchi password spraying usa protocolli di autenticazione

legacy
Oltre il 97% degli attacchi credential stuffing usa l'autenticazione legacy
Gli account Azure AD delle organizzazioni che hanno disabilitato l'esperienza
di autenticazione legacy sono soggetti al 67% di compromissioni in meno
rispetto a quelli per cui l'autenticazione legacy è abilitata
Se si è pronti per bloccare l'autenticazione legacy per migliorare la protezione del
tenant, è possibile raggiungere questo obiettivo con l'accesso condizionale. Questo
articolo illustra come configurare i criteri di accesso condizionale che bloccano
l'autenticazione legacy per tutti i carichi di lavoro all'interno del tenant.
Durante l'implementazione della protezione di blocco dell'autenticazione legacy, è

consigliabile adottare un approccio graduale anziché disabilitarlo per tutti gli utenti
contemporaneamente. I clienti possono scegliere di iniziare prima a disabilitare
l'autenticazione di base in base al protocollo applicando Exchange Online criteri di
autenticazione, quindi (facoltativamente) bloccando anche l'autenticazione legacy
tramite i criteri di accesso condizionale quando sono pronti.
I clienti senza licenze che includono l'accesso condizionale possono usare le

impostazioni predefinite per la sicurezza per bloccare l'autenticazione legacy.
Prerequisiti
Questo articolo presuppone che si abbia familiarità con i concetti di base dell'accesso
condizionale di Azure AD.
７ Nota

l'accesso.
Descrizione dello scenario

Azure AD supporta i protocolli di autenticazione e autorizzazione più usati, inclusa
l'autenticazione legacy. L'autenticazione legacy non può richiedere agli utenti
l'autenticazione a due fattori o altri requisiti di autenticazione necessari per soddisfare
direttamente i criteri di accesso condizionale. Questo modello di autenticazione include
l'autenticazione di base, un metodo standard di settore ampiamente usato per la
raccolta di informazioni su nome utente e password. Esempi di applicazioni che in
genere o usano solo l'autenticazione legacy sono:
Microsoft Office 2013 o versione precedente.

App che usano protocolli di posta elettronica come POP, IMAP e SMTP AUTH.
Per altre informazioni sul supporto dell'autenticazione moderna in Office, vedere
Funzionamento dell'autenticazione moderna per le app client di Office.
L'autenticazione a fattore singolo (ad esempio, nome utente e password) non è

sufficiente in questi giorni. Le password sono cattive perché sono facili da indovinare e
noi (esseri umani) sono cattivi nella scelta di password valide. Le password sono
vulnerabili anche a vari attacchi, ad esempio phishing e password spray. Una delle
operazioni più semplici che è possibile eseguire per proteggere le minacce alle
password consiste nell'implementare l'autenticazione a più fattori (MFA). Con
l'autenticazione a più fattori, anche se un utente malintenzionato è in possesso della
password di un utente, la password da sola non è sufficiente per autenticare e accedere
correttamente ai dati.
Come si può impedire alle app che usano l'autenticazione legacy di accedere alle risorse
dei tenant? È consigliabile bloccarle con criteri di accesso condizionale. Se necessario, è
possibile autorizzare solo determinati utenti e percorsi di rete specifici per l’uso delle
app basate sull’autenticazione legacy.
Implementazione
Questa sezione illustra come configurare criteri di accesso condizionale per bloccare
l'autenticazione legacy.
Protocolli di messaggistica che supportano

l'autenticazione legacy
I protocolli di messaggistica seguenti supportano l'autenticazione legacy:
SMTP autenticato: consente di inviare messaggi di posta elettronica autenticati.

Individuazione automatica: usata dai client Outlook e EAS per trovare le cassette
postali in Exchange Online e connettervisi.
Exchange ActiveSync (EAS): consente di connettersi alle cassette postali in
Exchange Online.
Exchange Online PowerShell: usato per connettersi a Exchange Online con
PowerShell remoto. Se si blocca l'autenticazione di base per Exchange Online
PowerShell, è necessario usare il modulo Exchange Online PowerShell per
connettersi. Per istruzioni, vedere Connettersi a Exchange Online PowerShell
usando l'autenticazione a più fattori.
Servizi Web Exchange: interfaccia di programmazione usata da Outlook, Outlook
per Mac e app di terze parti.
IMAP4: usato dai client di posta elettronica IMAP.
MAPI su HTTP (MAPI/HTTP): protocollo di accesso alle cassette postali primario
usato da Outlook 2010 SP2 e versioni successive.
Rubrica offline: copia delle raccolte di elenchi di indirizzi scaricate e usate da
Outlook.
Outlook Via Internet (RPC su HTTP): protocollo di accesso alle cassette postali
legacy supportato da tutte le versioni correnti di Outlook.
POP3: usato dai client di posta elettronica POP.
Servizi Web per la creazione di report: funzionalità usata per recuperare i dati dei
report in Exchange Online.
Outlook universale: usato dall'app Posta e Calendario per Windows 10.
Altri client: altri protocolli identificati come protocolli che utilizzano
Per altre informazioni su questi protocolli e servizi di autenticazione, vedere Report sulle
attività di accesso nel portale di Azure.
Identificare l'uso dell'autenticazione legacy

Prima di poter bloccare l'autenticazione legacy nella directory, è necessario
comprendere prima se gli utenti hanno client che usano l'autenticazione legacy. Di
seguito sono disponibili informazioni utili per identificare e valutare dove i client usano
Indicatori di Azure AD
1. Passare ailog di accesso di Portale di Azure>Azure Active Directory>.
2. Aggiungere la colonna App client se non viene visualizzata facendo clic su
Colonne>App client.
3. Selezionare Aggiungi filtri>App> client scegliere tutti i protocolli di autenticazione
legacy e selezionare Applica.
4. Se è stata attivata la nuova anteprima dei report delle attività di accesso, ripetere i
passaggi precedenti anche nella scheda Accessi utente (non interattivo).
Applicando il filtro verranno visualizzati solo i tentativi di accesso eseguiti dai protocolli
di autenticazione legacy. Facendo clic su ogni singolo tentativo di accesso verranno
visualizzati altri dettagli. Nel campo App client nella scheda Info di base sarà indicato il
protocollo di autenticazione legacy che è stato usato.
Questi log indicano dove gli utenti usano i client che dipendono ancora
dall'autenticazione legacy. Per gli utenti che non vengono visualizzati in questi log e
vengono confermati di non usare l'autenticazione legacy, implementare un criterio di
accesso condizionale solo per questi utenti.
Inoltre, per valutare l'autenticazione legacy all'interno del tenant, usare gli accessi
usando la cartella di lavoro di autenticazione legacy.
Indicatori dal client
Per determinare se un client usa l'autenticazione legacy o moderna in base alla finestra
di dialogo presentata all'accesso, vedere l'articolo Deprecation of Basic authentication in
Exchange Online( Deprecation of Basic authentication in Exchange Online).
Considerazioni importanti
Molti client che in precedenza supportano solo l'autenticazione legacy ora supportano
l'autenticazione moderna. I client che supportano l'autenticazione legacy e moderna
possono richiedere l'aggiornamento della configurazione per passare dall'autenticazione
legacy all'autenticazione moderna. Se vengono visualizzati dispositivi mobili, client
desktop o browsermoderni per un client nei log di Azure AD, viene usata
l'autenticazione moderna. Se ha un nome client o protocollo specifico, ad esempio
Exchange ActiveSync, usa l'autenticazione legacy. I tipi di client in Accesso condizionale,
log di accesso di Azure AD e la cartella di lavoro di autenticazione legacy distinguono
tra client di autenticazione moderni e legacy.
I client che supportano l'autenticazione moderna ma non sono configurati per

l'uso dell'autenticazione moderna devono essere aggiornati o riconfigurati per
l'uso dell'autenticazione moderna.
Tutti i client che non supportano l'autenticazione moderna devono essere
sostituiti.
） Importante
Exchange Active Sync con autenticazione basata su certificati
Quando si implementa Exchange Active Sync (EAS) con CBA, configurare i client per
l'uso dell'autenticazione moderna. I client che non usano l'autenticazione moderna
per EAS con CBA non vengono bloccati con deprecazione dell'autenticazione di
base in Exchange Online. Tuttavia, questi client sono bloccati dai criteri di accesso
condizionale configurati per bloccare l'autenticazione legacy.
Per altre informazioni sull'implementazione del supporto per CBA con Azure AD e
l'autenticazione moderna, vedere How to configure Azure AD certificate-based
authentication (Preview) (Come configurare l'autenticazione basata su certificati
di Azure AD (anteprima). Come un'altra opzione, l'autenticazione ABA eseguita in
un server federativo può essere usata con l'autenticazione moderna.
Se si usa Microsoft Intune, potrebbe essere possibile modificare il tipo di autenticazione

usando il profilo di posta elettronica di cui si esegue il push o la distribuzione nei
dispositivi. Se si usano dispositivi iOS (iPhone e iPad), vedere Aggiungere le
impostazioni di posta elettronica per i dispositivi iOS e iPadOS in Microsoft Intune.

Esistono due modi per usare i criteri di accesso condizionale per bloccare
Blocco diretto dell'autenticazione legacy

Blocco indiretto dell'autenticazione legacy
Blocco diretto dell'autenticazione legacy

Il modo più semplice per bloccare l'autenticazione legacy nell'intera organizzazione
consiste nella configurazione di criteri di accesso condizionale che si applicano in modo
specifico ai client di autenticazione legacy e blocca l'accesso. Quando si assegnano
utenti e applicazioni ai criteri, assicurarsi di escludere utenti e account di servizio che
devono comunque accedere usando l'autenticazione legacy. Quando si scelgono le app
cloud in cui applicare questo criterio, selezionare Tutte le app cloud, le app di
destinazione, ad esempio Office 365 (consigliato) o almeno, Office 365 Exchange Online.
Le organizzazioni possono usare i criteri disponibili nei modelli di accesso condizionale
o nell'accesso condizionale dei criteri comuni : Blocca l'autenticazione legacy come
riferimento.
Blocco indiretto dell'autenticazione legacy

Se l'organizzazione non è pronta per bloccare l'autenticazione legacy nell'intera
organizzazione, è necessario assicurarsi che gli accessi con l'autenticazione legacy non
vengano ignorati dai criteri che richiedono controlli di concessione, ad esempio l'uso
dell'autenticazione a più fattori o i dispositivi aggiunti ad Azure AD compatibili o
conformi. Durante l'autenticazione, i client di autenticazione legacy non supportano
l'invio di MFA, conformità del dispositivo o aggiunta di informazioni sullo stato ad Azure
AD. Pertanto, applicare criteri con controlli di concessione a tutte le applicazioni client in
modo che gli accessi basati sull'autenticazione legacy che non possono soddisfare i
controlli di concessione vengono bloccati. Con la disponibilità generale della condizione
delle app client nel mese di agosto 2020, i criteri di accesso condizionale appena creati
si applicano a tutte le app client per impostazione predefinita.
Informazioni utili
I criteri di accesso condizionale possono richiedere fino a 24 ore.
Bloccando l'accesso con Altri client vengono bloccati anche Exchange Online
PowerShell e Dynamics 365 con autenticazione di base.
La configurazione di un criterio per Altri client blocca l'intera organizzazione per

determinati client come SPConnect. Questo blocco si verifica perché l'autenticazione di
client meno recenti avviene in modo imprevisto. Questo problema non si applica alle
principali applicazioni di Office, come i client di Office meno recenti.
È possibile selezionare tutti i controlli di concessione disponibili per la condizione Altri

client, ma l'esperienza dell'utente finale sarà sempre la stessa: l'accesso è bloccato.
Passaggi successivi
Se non si ha familiarità con la configurazione dei criteri di accesso condizionale,
vedere Richiedere MFA per app specifiche con l'accesso condizionale di Azure
Active Directory per un esempio.
Per altre informazioni sul supporto dell'autenticazione moderna, vedere Come
funziona l'autenticazione moderna per le app client di Office
Come configurare un dispositivo o un'applicazione multifunzione per inviare
messaggi di posta elettronica tramite Microsoft 365
Abilitare l'autenticazione moderna in Exchange Online
Abilitare l'autenticazione moderna per Office 2013 nei dispositivi Windows
Come configurare Exchange Server locale per l'uso dell'autenticazione moderna
ibrida
Come usare l'autenticazione moderna con Skype for Business
Condizioni per l'utilizzo di Azure Active
Directory
Articolo • 10/03/2023
I criteri di utilizzo di Azure AD forniscono un metodo semplice che le organizzazioni

possono usare per presentare informazioni agli utenti finali. In questo modo si
garantisce che gli utenti vedano le dichiarazioni rilevanti di non responsabilità che si
riferiscono ai requisiti legali o di conformità. Questo articolo descrive come iniziare a
usare i criteri (ToU).
７ Nota
Questo articolo illustra come eliminare i dati personali dal dispositivo o dal servizio
e può essere usato per supportare gli obblighi previsti dal GDPR. Per informazioni
generali sul GDPR, vedere la sezione GDPR del Centro protezione Microsoft e la
sezione GDPR del portale di trust del servizio .
Panoramica video
Il video seguente offre una rapida panoramica dei criteri ToU.
https://www.youtube-nocookie.com/embed/tj-LK0abNao
Per altri video, vedere:
Come distribuire criteri di utilizzo in Azure Active Directory

Come implementare criteri di utilizzo in Azure Active Directory
Cosa posso fare con le condizioni per l'uso?

Le organizzazioni possono usare le condizioni per l'uso insieme ai criteri di accesso
condizionale per richiedere ai dipendenti o agli ospiti di accettare i criteri di utilizzo
prima di ottenere l'accesso. Queste istruzioni per l'uso possono essere generalizzate o
specifiche per gruppi o utenti e fornite in più lingue. Gli amministratori possono
determinare chi ha o non ha accettato le condizioni per l'uso con i log o le API forniti.
Prerequisiti
Per usare e configurare le condizioni di utilizzo di Azure AD, è necessario disporre di:
Tenant di Azure AD funzionante con Azure AD Premium P1 o licenza di valutazione
abilitata. Se necessario, crearne uno gratuitamente .
Gli amministratori che interagiscono con le condizioni per l'uso devono avere una
o più delle assegnazioni di ruolo seguenti a seconda delle attività eseguite. Per
seguire il principio Zero Trust dei privilegi minimi, valutare l'uso di Privileged
Identity Management (PIM) per attivare le assegnazioni di ruolo con privilegi just-
in-time.
Leggere le condizioni per l'uso della configurazione e dei criteri di accesso
condizionale
Ruolo con autorizzazioni di lettura per la sicurezza
Ruolo con autorizzazioni di lettura globali
Creare o modificare le condizioni per l'uso e i criteri di accesso condizionale
Documento sulle condizioni per l'utilizzo

Il contenuto delle condizioni per l'utilizzo di Azure AD viene presentato in formato PDF.
Il contenuto del file PDF può essere di qualsiasi tipo, ad esempio documenti di contratti
esistenti. Questo consente di acquisire il consenso degli utenti finali durante l'accesso.
Per supportare gli utenti sui dispositivi mobili, le dimensioni del carattere consigliato nel
file PDF sono 24 punti.
Aggiungere le condizioni per l'utilizzo

Dopo aver completato il documento relativo ai criteri di utilizzo, usare la procedura
seguente per aggiungerla.
1. Accedere alla portale di Azure come amministratore di accesso condizionale o

amministratore della sicurezza.
2. Passare aCondizioni diaccesso condizionale per la>sicurezza> di Azure Active

Directory>.
3. Selezionare Nuovi termini.

4. Nella casella Nome immettere un nome per i criteri di utilizzo usati nella portale di
Azure.
5. Per Il documento Condizioni per l'uso, passare ai termini finali dell'uso del pdf dei
criteri e selezionarlo.
6. Selezionare la lingua per il documento relativo all'utilizzo dei criteri. L'opzione

lingua consente di caricare più termini di utilizzo, ognuno con una lingua diversa.
La versione dei criteri di utilizzo visualizzati da un utente finale è basata sulle
preferenze del browser.
7. Nella casella Nome visualizzato immettere un titolo visualizzato dagli utenti

quando eseguono l'accesso.
8. Per richiedere agli utenti finali di visualizzare i criteri di utilizzo prima di accettarli,
impostare Richiedi agli utenti di espandere le condizioni per l'uso su Sì.
9. Per richiedere agli utenti finali di accettare i criteri di utilizzo in ogni dispositivo a
cui accedono, impostare Richiedi agli utenti di consentire il consenso in ogni
dispositivo su Attiva. Se questa opzione è abilitata, è possibile che gli utenti
debbano installare altre applicazioni. Per altre informazioni, vedere Condizioni per
ogni dispositivo per l'uso.
10. Se si desidera scadere le condizioni per l'uso dei criteri in base a una pianificazione,
impostare Scadenza consenso su Attiva. Se impostata su Attiva, vengono
visualizzate due impostazioni di pianificazione.
11. Usare le impostazioni Scadenza a partire da e Frequenza per specificare la

pianificazione per le scadenze dei criteri di utilizzo. La tabella seguente illustra il
risultato di un paio di impostazioni di esempio:
Scadenza Frequenza Risultato

a partire
da
Data Ogni mese A partire da oggi, gli utenti devono accettare i criteri di utilizzo e
odierna quindi riaccettare ogni mese.
Data nel Ogni mese A partire da oggi, gli utenti devono accettare le condizioni di
futuro utilizzo dei criteri. Quando si verifica la data futura, i consenso
scadono e quindi gli utenti devono riaccettare ogni mese.
Ad esempio, se si imposta la scadenza a partire dalla data di inizio del 1 gennaio e

della frequenza su Mensile, questa è la modalità di scadenza per due utenti:
User Prima data di Prima data di Seconda data di Terza data di

accettazione scadenza scadenza scadenza
Alice 1 gen 1 feb 1 mar 1 apr
Bob 15 gen 1 feb 1 mar 1 apr

12. Usare l'impostazione Duration before re-accept obbligatoria (giorni) per
specificare il numero di giorni prima che l'utente debba riaccepire le condizioni di
utilizzo. Questa opzione consente agli utenti di seguire la propria pianificazione.
Ad esempio, se si imposta la durata su 30 giorni, si tratta della modalità di
scadenza per due utenti:
User Prima data di Prima data di Seconda data di Terza data di

accettazione scadenza scadenza scadenza
Alice 1 gen 31 gen 2 mar 1 apr
Bob 15 gen 14 feb 16 mar 15 apr
È possibile usare le impostazioni Di scadenza e Durata prima di accettare

nuovamente le impostazioni necessarie (giorni), ma in genere si usa una o l'altra.
13. In Accesso condizionale usare l'elenco Applica con criteri di accesso condizionale
per selezionare il modello per applicare i criteri relativi alle condizioni per l'utilizzo.
Modello Descrizione
Criteri personalizzati Selezionare gli utenti, i gruppi e le app a cui vengono applicati i
criteri relativi alle condizioni per l'utilizzo.
Creare criteri di accesso Questo criterio per le condizioni per l'utilizzo viene visualizzato
condizionale in un nell'elenco di controllo delle concessioni durante la creazione di
secondo momento un criterio di accesso condizionale.
） Importante
I controlli dei criteri di accesso condizionale (inclusi i criteri per l'utilizzo) non
supportano l'applicazione degli account del servizio. È consigliabile escludere
tutti gli account di servizio dai criteri di accesso condizionale.
I criteri di accesso condizionale personalizzati consentono criteri granulari per

l'utilizzo, fino a un'applicazione cloud o a un gruppo di utenti specifici. Per altre
informazioni, vedere Avvio rapido: Richiedere l'accettazione di condizioni per
l'utilizzo prima dell'accesso alle app cloud.
Se è stato selezionato un modello di accesso condizionale personalizzato, viene

visualizzata una nuova schermata che consente di creare i criteri di accesso
condizionale personalizzati.
Verranno ora visualizzate le nuove condizioni per l'utilizzo.
Visualizzare il report degli utenti che hanno

accettato e rifiutato
Nel pannello delle condizioni per l'utilizzo è visualizzato il numero di utenti che hanno
accettato e rifiutato. Questi conteggi e gli utenti accettati/rifiutati vengono archiviati per
la durata dei criteri relativi alle condizioni per l'utilizzo.
1. Accedere ad Azure e passare a Condizioni per l'utilizzo all'indirizzo
https://aka.ms/catou .
2. Per i criteri per le condizioni per l'utilizzo, selezionare i numeri in Accettato o

Rifiutato per visualizzare lo stato corrente per gli utenti.
3. Per visualizzare la cronologia per un singolo utente, selezionare i puntini di

sospensione (...) e quindi Visualizza cronologia.
Nel riquadro di visualizzazione della cronologia, si visualizza una cronologia di
tutte le accettazioni, i rifiuti e le scadenze.
Visualizzare i log di controllo di Azure AD

Per visualizzare altre attività, i criteri per le condizioni per l'utilizzo di Azure AD
includono i log di controllo. Ogni consenso dell'utente genera un evento nei log di
controllo che viene conservato per 30 giorni. È possibile visualizzare questi log nel
portale o scaricarli come file CSV.
Per iniziare a usare i log di controllo di Azure AD, seguire questa procedura:


Directory>.
3. Selezionare un criterio per le condizioni per l'utilizzo.
4. Selezionare Visualizza log di controllo.
5. Nella schermata dei log di controllo di Azure AD è possibile filtrare le informazioni

usando i menu a discesa per visualizzare informazioni specifiche dei log di
controllo.
È anche possibile selezionare Scarica per scaricare le informazioni in un file di .csv

da usare in locale.
Se si seleziona un log, viene visualizzato un riquadro con altri dettagli dell'attività.
Come vengono visualizzate le condizioni per

l'utilizzo agli utenti
Dopo aver creato e applicato un criterio ToU, gli utenti che si trovano nell'ambito
visualizzano la schermata seguente durante l'accesso.
Gli utenti possono visualizzare i criteri relativi alle condizioni per l'utilizzo e, se
necessario, usare i pulsanti per ingrandire e ridurre.
La schermata seguente mostra l'aspetto dei criteri tou nei dispositivi mobili.
Gli utenti devono accettare i criteri per le condizioni per l'utilizzo una sola volta e non
vedranno di nuovo le condizioni per l'utilizzo nei successivi accessi.
In che modo gli utenti possono esaminare le condizioni

per l'utilizzo
Gli utenti possono esaminare e visualizzare i criteri per l'utilizzo accettati usando la
procedura seguente.
1. Accedere a https://myaccount.microsoft.com/ .
2. Selezionare Impostazioni & Privacy.
3. Selezionare Privacy.
4. In Avviso dell'organizzazione selezionare Visualizza accanto all'istruzione
condizioni per l'utilizzo da esaminare.
Modificare i dettagli delle condizioni per

l'utilizzo
È possibile modificare alcuni dettagli dei criteri relativi alle condizioni per l'utilizzo, ma
non è possibile modificare un documento esistente. La procedura seguente descrive
come modificare i dettagli.


Directory>.
3. Selezionare i criteri per le condizioni per l'utilizzo da modificare.
4. Selezionare Modifica le condizioni.
5. Nel riquadro Modifica condizioni per l'utilizzo è possibile modificare le opzioni

seguenti:
Nome : nome interno dell'unità utente non condivisa con gli utenti finali
Nome visualizzato : il nome che gli utenti finali possono visualizzare durante
la visualizzazione dell'oggetto ToU
Richiedi agli utenti di espandere le condizioni per l'utilizzo : l'impostazione
di questa opzione su Sì impone all'utente finale di espandere il documento
dei criteri per le condizioni per l'utilizzo prima di accettarlo.
(Anteprima) È possibile aggiornare un documento sulle condizioni per
l'utilizzo
È possibile aggiungere una lingua a un oggetto ToU esistente
Se sono presenti altre impostazioni che si desidera modificare, ad esempio il

documento PDF, richiedere agli utenti di fornire il consenso a ogni dispositivo,
scadere il consenso, la durata prima della riaccezione o i criteri di accesso
condizionale, è necessario creare un nuovo criterio tou.
6. Al termine, selezionare Salva per salvare le modifiche.
Aggiornare la versione o il pdf di condizioni per

l'utilizzo esistenti

Directory>.
4. Selezionare Modifica le condizioni.
5. Per la lingua che si vuole aggiornare una nuova versione, selezionare Aggiorna
nella colonna azione
6. Nel riquadro a destra caricare il pdf per la nuova versione
7. È disponibile anche un'opzione attiva/disattiva qui Richiedi reaccept se si vuole

richiedere agli utenti di accettare questa nuova versione al successivo accesso. Se è
necessario che gli utenti riaccettano, la volta successiva che tentano di accedere
alla risorsa definita nei criteri di accesso condizionale, verrà richiesto di accettare
questa nuova versione. Se non è necessario che gli utenti riaccedano, il consenso
precedente rimane aggiornato e solo i nuovi utenti che non hanno acconsentito
prima o il cui consenso scade visualizza la nuova versione. Fino alla scadenza della
sessione, Richiedi riaccept non richiede agli utenti di accettare il nuovo TOU. Se si
vuole assicurarsi di riaccept, eliminare e ricreare o creare un nuovo tou per questo
caso.
8. Dopo aver caricato il nuovo pdf e aver deciso di riaccept, selezionare Aggiungi
nella parte inferiore del riquadro.
9. Nella colonna Documento viene visualizzata la versione più recente.
Visualizzare le versioni precedenti di un

oggetto ToU

Directory>.
3. Selezionare i criteri per le condizioni per l'utilizzo per i quali si desidera visualizzare
una cronologia delle versioni.
4. Selezionare Lingue e cronologia delle versioni
5. Selezionare Visualizza versioni precedenti.
6. È possibile selezionare il nome del documento per scaricare tale versione
Vedere chi ha accettato ogni versione

Directory>.
3. Per visualizzare chi ha attualmente accettato l'oggetto ToU, selezionare il numero
nella colonna Accettata per l'oggetto ToU desiderato .
4. Per impostazione predefinita, la pagina successiva mostrerà lo stato corrente
dell'accettazione di ogni utente nell'elenco delle informazioni
5. Se si desidera visualizzare gli eventi di consenso precedenti, è possibile selezionare
Tutti dall'elenco a discesa Stato corrente . È ora possibile visualizzare gli eventi di
ogni utente in dettagli su ogni versione e cosa è accaduto.
6. In alternativa, è possibile selezionare una versione specifica dall'elenco a discesa
Versione per vedere chi ha accettato tale versione specifica.
Aggiungere una lingua tou

Nella procedura seguente viene descritto come aggiungere un linguaggio tou.


Directory>.
4. Selezionare Modifica termini
5. Selezionare Aggiungi lingua nella parte inferiore della pagina.
6. Nel riquadro Aggiungi le condizioni per l'utilizzo caricare il PDF localizzato e

selezionare la lingua.
7. Selezionare Aggiungi lingua.
8. Selezionare Salva
9. Selezionare Aggiungi per aggiungere la lingua.

Condizioni per l'utilizzo per dispositivo
L'impostazione Richiedi agli utenti di fornire il consenso in ogni dispositivo consente
agli utenti finali di accettare i criteri relativi alle condizioni per l'utilizzo in ogni
dispositivo da cui accede. L'utente finale deve registrare il dispositivo in Azure AD.
Quando il dispositivo viene registrato, l'ID dispositivo viene usato per applicare i criteri
relativi alle condizioni per l'utilizzo in ogni dispositivo.
Piattaforme e software supportati.
iOS Telefoni Windows 10 Altro
App nativa Sì Sì Sì
Microsoft Edge Sì Sì Sì
Internet Sì Sì Sì
Explorer
Chrome (con Sì Sì Sì
estensione)
Le condizioni per l'utilizzo per dispositivo presentano i vincoli seguenti:
Un dispositivo può essere aggiunto a un solo tenant.

Un utente deve disporre delle autorizzazioni per aggiungere il dispositivo.
L'app di registrazione Intune non è supportata. Assicurarsi che sia escluso dai
criteri di accesso condizionale che richiedono i criteri condizioni per l'utilizzo.
Gli utenti di Azure AD B2B non sono supportati.
Se il dispositivo dell'utente non è aggiunto, riceve un messaggio che informa che deve
essere aggiunto al dispositivo. La loro esperienza dipende dalla piattaforma e dal
software.
Aggiungere un dispositivo Windows 10

Se un utente usa Windows 10 e Microsoft Edge, riceve un messaggio simile al seguente
per aggiungere il dispositivo .
Se usano Chrome, viene richiesto di installare l'estensione Windows 10 Accounts .
Registrare un dispositivo iOS

Se un utente usa un dispositivo iOS, viene richiesto di installare l'app Microsoft
Authenticator .
Registrare un dispositivo Android

Se un utente usa un dispositivo Android, viene richiesto di installare l'app Microsoft
Authenticator .
Browser
Se un utente usa un browser non supportato, viene chiesto di usare un browser diverso.
Eliminare le condizioni per l'utilizzo
È possibile eliminare i criteri delle condizioni per l'utilizzo precedenti usando la
procedura seguente.


Directory>.
3. Selezionare i criteri per le condizioni per l'utilizzo da rimuovere.
4. Selezionare Elimina termini.
5. Nel messaggio visualizzato che chiede se si vuole continuare, selezionare Sì.

Non dovrebbero più essere visualizzati i criteri relativi alle condizioni per l'utilizzo.
Eliminazione del record di accettazione utente

I record di accettazione utente vengono eliminati:
Quando l'amministratore elimina in modo esplicito l'oggetto ToU. Quando si

verifica questa modifica, vengono eliminati anche tutti i record di accettazione
associati a tale tou specifico.
Quando il tenant perde la licenza Azure Active Directory Premium.
Quando il tenant viene eliminato.
Modifiche dei criteri

I criteri di accesso condizionale diventano immediatamente effettivi. In questo caso,
l'amministratore inizia a visualizzare "cloud tristi" o "problemi di token di Azure AD".
L'amministratore deve disconnettersi e accedere per soddisfare i nuovi criteri.
） Importante
Gli utenti inclusi nell'ambito devono disconnettersi e accedere per soddisfare un

nuovo criterio se:
Un criterio di accesso condizionale è abilitato in base ai criteri per le

condizioni per l'utilizzo
o viene creato un secondo criterio per l'utilizzo
Guest B2B
La maggior parte delle organizzazioni dispone di un processo che consente ai
dipendenti di fornire il consenso alle condizioni per l'utilizzo e alle informative sulla
privacy dell'organizzazione. Ma come è possibile applicare gli stessi consensi per i guest
di Azure AD business-to-business (B2B) quando vengono aggiunti tramite SharePoint o i
team? Usando l'accesso condizionale e i criteri per l'utilizzo, è possibile applicare un
criterio direttamente agli utenti guest B2B. Durante il flusso di riscatto dell'invito,
l'utente viene presentato con i criteri relativi alle condizioni per l'utilizzo.
I criteri per le condizioni per l'utilizzo verranno visualizzati solo quando l'utente ha un
account guest in Azure AD. SharePoint Online ha attualmente un'esperienza destinatario
di condivisione esterna ad hoc per condividere un documento o una cartella che non
richiede all'utente di avere un account guest. In questo caso, i criteri relativi alle
condizioni per l'utilizzo non vengono visualizzati.
Supporto per le app cloud

I criteri per le condizioni per l'utilizzo possono essere usati per app cloud diverse, ad
esempio Azure Information Protection e Microsoft Intune. Questo supporto è
attualmente disponibile in versione di anteprima.
Azure Information Protection

È possibile configurare un criterio di accesso condizionale per l'app azure Information
Protection e richiedere criteri relativi alle condizioni per l'utilizzo quando un utente
accede a un documento protetto. Questa configurazione attiva un criterio di condizioni
per l'utilizzo prima che un utente acceda a un documento protetto per la prima volta.
Registrazione di Microsoft Intune

È possibile configurare un criterio di accesso condizionale per l'app di registrazione
Microsoft Intune e richiedere criteri per l'utilizzo prima della registrazione di un
dispositivo in Intune. Per altre informazioni, vedere il Leggi il post di blog sulla scelta
della soluzione di Condizioni di utilizzo più adatta per l'organizzazione .
７ Nota
L'app di registrazione Intune non è supportata per le condizioni per l'utilizzo per
dispositivo.
７ Nota
Per la registrazione automatica dei dispositivi iOS/iPadOS, l'aggiunta di un URL

personalizzato ai criteri Condizioni per l'utilizzo di Azure AD non consente agli
utenti di aprire il criterio dall'URL in Assistente configurazione per leggerlo. Il
criterio può essere letto dall'utente dopo il completamento dell'Assistente
configurazione dal sito Web Portale aziendale o nell'app Portale aziendale.
Domande frequenti
D: Non è possibile accedere usando PowerShell quando sono abilitate le condizioni
per l'utilizzo.
R: Le condizioni per l'utilizzo possono essere accettate solo durante l'autenticazione

interattiva.
D: Ricerca per categorie vedere quando/se un utente ha accettato le condizioni per

l'utilizzo?
R: Nel pannello Condizioni per l'utilizzo selezionare il numero in Accettato. È anche

possibile visualizzare o cercare l'attività accettata nei log di controllo di Azure AD. Per
altre informazioni, vedere Visualizzare il report degli utenti che hanno accettato e
rifiutato e Visualizzare i log di controllo di Azure AD.
D: per quanto tempo sono archiviate le informazioni?
R: L'utente conta nei report sulle condizioni per l'utilizzo e chi ha accettato/rifiutato
viene archiviato per la durata delle condizioni per l'utilizzo. I log di controllo di Azure AD
vengono archiviati per 30 giorni.
D: Perché viene visualizzato un numero diverso di consensi nella panoramica dei

dettagli dell'utilizzo rispetto ai log di controllo di Azure AD?
R: I dati di panoramica delle condizioni per l'utilizzo vengono archiviati per la durata dei
criteri relativi alle condizioni per l'utilizzo, mentre i log di controllo di Azure AD vengono
archiviati per 30 giorni.
D: Perché viene visualizzato un numero diverso di consensi nella panoramica dei

dettagli per l'utilizzo rispetto al report CSV esportato?
R: La panoramica dei dettagli sulle condizioni per l'utilizzo riflette le accettazione

aggregate della versione corrente del criterio (aggiornata una volta ogni giorno). Se la
scadenza è abilitata o viene aggiornato un contratto tou (con la riacceptance
obbligatoria), il conteggio sulla panoramica dei dettagli viene reimpostato perché le
accettazione sono scadute, visualizzando quindi il conteggio della versione corrente.
Tutta la cronologia di accettazione viene ancora acquisita nel report CSV.
D: Se i collegamenti ipertestuali sono nel documento PDF dei criteri per l'utilizzo, gli
utenti finali potranno fare clic su di essi?
R: Sì, gli utenti finali possono selezionare collegamenti ipertestuali ad altre pagine, ma i
collegamenti alle sezioni all'interno del documento non sono supportati. Inoltre, i
collegamenti ipertestuali in termini di criteri di utilizzo PDF non funzionano quando si
accede dal portale MyApps/MyAccount di Azure AD.
D: I criteri per le condizioni per l'utilizzo possono supportare più lingue?
R: Sì. Attualmente sono disponibili 108 lingue diverse che un amministratore può
configurare per un singolo criterio per le condizioni per l'utilizzo. Un amministratore può
caricare più documenti PDF e contrassegnare i documenti con una lingua
corrispondente (fino a 108). Quando gli utenti finali accedono, vengono esaminate le
preferenze della lingua del browser e viene visualizzato il documento corrispondente. Se
non esiste alcuna corrispondenza, viene visualizzato il documento predefinito, ovvero il
primo documento caricato.
D: Quando vengono attivate le condizioni per l'utilizzo?
R: I criteri per le condizioni per l'utilizzo vengono attivati durante l'esperienza di accesso.
D: A quali applicazioni è possibile assegnare i criteri per le condizioni per l'utilizzo?
R: È possibile creare criteri di accesso condizionale nelle applicazioni aziendali usando

l'autenticazione moderna. Per altre informazioni, vedere le applicazioni aziendali.
D: È possibile aggiungere più criteri per l'utilizzo a un determinato utente o app?
R: Sì, creando più criteri di accesso condizionale destinati a tali gruppi o applicazioni. Se
un utente rientra nell'ambito di più criteri per l'utilizzo, accetta un criterio per l'utilizzo
alla volta.
D: Cosa accade se un utente rifiuta i criteri per l'utilizzo?
R: ne viene bloccato l'accesso all'applicazione. L'utente dovrà accedere di nuovo e

accettare le condizioni per ottenere l'accesso.
D: È possibile non accettare i criteri per l'utilizzo accettati in precedenza?
R: È possibile esaminare le condizioni per l'utilizzo accettate in precedenza, ma

attualmente non esiste un modo per non accettare.
D: Cosa succede se si usano anche termini e condizioni di Intune?
R: Se sono state configurate entrambe le condizioni per l'utilizzo di Azure AD e le

condizioni Intune, l'utente deve accettare entrambi. Per altre informazioni, vedere il post
di blog sulla scelta della soluzione di Condizioni di utilizzo più adatta per
l'organizzazione .
D: Quali endpoint usano le condizioni per l'utilizzo del servizio per l'autenticazione?
R: Condizioni per l'utilizzo utilizzano gli endpoint seguenti per l'autenticazione:

https://tokenprovider.termsofuse.identitygovernance.azure.com e
https://myaccount.microsoft.com https://account.activedirectory.windowsazure.com .
Se l'organizzazione ha un elenco di URL consentiti per la registrazione, è necessario
aggiungere questi endpoint all'elenco elementi consentiti, insieme agli endpoint di
Azure AD per l'accesso.
Passaggi successivi
Avvio rapido: Richiedere l'accettazione di condizioni per l'utilizzo prima
dell'accesso alle app cloud
Configurare la gestione delle sessioni di
autenticazione con l'accesso
condizionale
Articolo • 23/05/2023
Nelle distribuzioni complesse, le organizzazioni possono avere la necessità di limitare le

sessioni di autenticazione. Alcuni scenari possibili sono:
Accesso alle risorse da un dispositivo non gestito o condiviso

Accesso alle informazioni riservate da una rete esterna
Utenti con impatto elevato
Applicazioni aziendali critiche
I controlli di accesso condizionale consentono di creare criteri mirati a casi d'uso

specifici all'interno dell'organizzazione senza influire su tutti gli utenti.
Prima di approfondire i dettagli su come configurare i criteri, si esaminerà la

configurazione predefinita.
Frequenza di accesso utente

La frequenza di accesso definisce il periodo di tempo prima che all'utente venga
richiesto di ripetere l'accesso quando tenta di accedere a una risorsa.
La configurazione predefinita di Azure Active Directory (Azure AD) per la frequenza di

accesso utente è una finestra in sequenza di 90 giorni. La richiesta di credenziali agli
utenti spesso sembra una cosa ragionevole da fare, ma può essere riattivata: gli utenti
addestrato per immettere le proprie credenziali senza pensare possono fornire
involontariamente a una richiesta di credenziali dannose.
Potrebbe sembrare allarmante non chiedere a un utente di eseguire di nuovo l'accesso,

in realtà qualsiasi violazione dei criteri IT revoca la sessione. Alcuni esempi includono
(ma non sono limitati) una modifica della password, un dispositivo non conforme o una
disabilitazione dell'account. È anche possibile revocare in modo esplicito le sessioni
degli utenti usando PowerShell. La configurazione predefinita di Azure AD è "non
chiedere agli utenti di fornire le proprie credenziali se il comportamento di sicurezza
delle sessioni non è cambiato".
L'impostazione della frequenza di accesso funziona con le app che hanno implementato
protocolli OAuth2 o OIDC in base agli standard. La maggior parte delle app native
Microsoft per Windows, Mac e Mobile, incluse le applicazioni Web seguenti, è conforme
all'impostazione .
Word, Excel, PowerPoint Online

OneNote Online
Office.com
Portale di amministrazione di Microsoft 365
Exchange Online
SharePoint e OneDrive
Client Web Teams
Dynamics CRM Online
Portale di Azure
L'impostazione della frequenza di accesso funziona con le applicazioni e le app SAML di

terze parti che hanno implementato protocolli OAuth2 o OIDC, purché non rilascino i
propri cookie e vengano reindirizzati ad Azure AD per l'autenticazione regolarmente.
Frequenza di accesso utente e autenticazione a più fattori

Frequenza di accesso applicata in precedenza solo all'autenticazione a primo fattore nei
dispositivi aggiunti ad Azure AD, aggiunti ad Azure AD ibrido e registrati in Azure AD.
Non esisteva un modo semplice per i clienti di riapplicare l'autenticazione a più fattori
(MFA) a questi dispositivi. A seguito del feedback dei clienti, la frequenza di accesso
verrà applicata anche per l'autenticazione a più fattori.

Frequenza di accesso utente e identità dei dispositivi

Nei dispositivi aggiunti ad Azure AD e aggiunti ad Azure AD ibrido, lo sblocco del
dispositivo o l'accesso in modo interattivo aggiornerà solo il token di aggiornamento
primario (PRT) ogni 4 ore. Il timestamp dell'ultimo aggiornamento registrato per il token
di aggiornamento primario rispetto al timestamp corrente deve essere entro il tempo
assegnato nei criteri SIF per il token di aggiornamento primario e concedere l'accesso a
un token di aggiornamento primario con un'attestazione MFA esistente. Nei dispositivi
registrati in Azure AD, lo sblocco/accesso non soddisfa i criteri SIF perché l'utente non
accede a un dispositivo registrato in Azure AD tramite un account Azure AD. Tuttavia, il
plug-in WAM di Azure AD può aggiornare un token di aggiornamento primario durante
l'autenticazione dell'applicazione nativa usando WAM.
Nota: il timestamp acquisito dall'accesso utente non corrisponde necessariamente

all'ultimo timestamp registrato dell'aggiornamento prT a causa del ciclo di
aggiornamento di 4 ore. Il caso in cui è uguale è quando un token di aggiornamento
primario è scaduto e un utente lo aggiorna per 4 ore. Negli esempi seguenti si
supponga che i criteri SIF siano impostati su 1 ora e che il token di aggiornamento
primario venga aggiornato alle 00:00.
Esempio 1: quando si continua a lavorare sullo stesso documento in SPO per un'ora
Alle ore 00:00 un utente accede al proprio dispositivo Windows 10 aggiunto ad

Azure AD e inizia a lavorare a un documento archiviato in SharePoint Online.
L'utente continua a lavorare allo stesso documento sul proprio dispositivo per
un'ora.
Alle ore 01:00 all'utente viene richiesto di eseguire di nuovo l'accesso in base ai
requisiti di frequenza di accesso dei criteri di accesso condizionale configurati
dall'amministratore.
Esempio 2: quando si sospenderà il lavoro con un'attività in background in esecuzione nel

browser, quindi interagirà nuovamente dopo il superamento del tempo dei criteri SIF
Alle 00:00, un utente accede al dispositivo aggiunto ad Azure AD Windows 10 e

inizia a caricare un documento in SharePoint Online.
Alle 00:10, l'utente si alza e interrompe il blocco del dispositivo. Il caricamento in
background continua a SharePoint Online.
Alle 02:45, l'utente torna dall'interruzione e sblocca il dispositivo. Il caricamento in
background mostra il completamento.
Alle 02:45, all'utente viene richiesto di accedere quando interagisce di nuovo in
base al requisito di frequenza di accesso nei criteri di accesso condizionale
configurati dall'amministratore dopo l'ultimo accesso alle 00:00.
Se l'app client (in dettagli attività) è un browser, rinviiamo l'applicazione della frequenza
di accesso di eventi/criteri nei servizi in background fino alla successiva interazione
dell'utente.
Esempio 3: con ciclo di aggiornamento di 4 ore del token di aggiornamento primario dallo
sblocco
Scenario 1 : l'utente restituisce entro il ciclo

avvia il lavoro su un documento archiviato in SharePoint Online.
Alle 00:30, l'utente si alza e interrompe il blocco del dispositivo.
Alle ore 00:45 l'utente riprende il lavoro dopo la pausa e sblocca il dispositivo.
Alle 01:00, all'utente viene richiesto di eseguire di nuovo l'accesso in base al
requisito di frequenza di accesso nei criteri di accesso condizionale configurati
dall'amministratore, 1 ora dopo l'accesso iniziale.
Scenario 2 - L'utente restituisce un ciclo esterno

avvia il lavoro su un documento archiviato in SharePoint Online.
Alle 00:30, l'utente si alza e interrompe il blocco del dispositivo.
Alle 04:45, l'utente torna dall'interruzione e sblocca il dispositivo.
Alle 05:45, all'utente viene richiesto di eseguire di nuovo l'accesso in base al
requisito di frequenza di accesso nei criteri di accesso condizionale configurati
dall'amministratore, 1 ora dopo l'aggiornamento del token di aggiornamento
primario alle 04:45 (oltre 4 ore dopo l'accesso iniziale alle 00:00).
Richiedere la riautenticazione ogni volta

Esistono scenari in cui i clienti possono richiedere una nuova autenticazione, ogni volta
che un utente esegue azioni specifiche. La frequenza di accesso ha una nuova opzione
per Ogni volta oltre a ore o giorni.
Scenari supportati:
Richiedere la riautenticazione dell'utente durante Intune registrazione del

dispositivo, indipendentemente dal relativo stato MFA corrente.
Richiedere la riautenticazione dell'utente per gli utenti rischiosi con il controllo di
concessione della modifica della password.
Richiedere la riautenticazione dell'utente per gli accessi a rischio con il controllo di
concessione dell'autenticazione a più fattori.
Quando gli amministratori selezionano Ogni volta, richiederà la riautenticazione

completa quando viene valutata la sessione.
Persistenza delle sessioni di esplorazione

Una sessione del browser persistente consente agli utenti di rimanere connessi dopo
aver chiuso e riaperto la finestra del browser.
L'impostazione predefinita di Azure AD per la persistenza delle sessioni del browser

consente agli utenti di dispositivi personali di scegliere se rendere persistente la
sessione visualizzando il messaggio "Rimanere connessi?" Richiesta dopo una corretta
autenticazione. Se la persistenza del browser è configurata in AD FS usando le linee
guida riportate nell'articolo Impostazioni single sign-on di AD FS, i criteri verranno
conformi e verranno mantenuti anche la sessione di Azure AD. È anche possibile
configurare se gli utenti nel tenant visualizzano l'opzione "Rimanere connessi?"
richiedendo di modificare l'impostazione appropriata nel riquadro di personalizzazione
aziendale.
Nei browser permanenti i cookie rimangono archiviati nel dispositivo dell'utente anche
dopo che un utente chiude il browser. Questi cookie potrebbero avere accesso agli
artefatti di Azure Active Directory e questi elementi sono utilizzabili fino alla scadenza
del token indipendentemente dai criteri di accesso condizionale inseriti nell'ambiente
delle risorse. Pertanto, la memorizzazione nella cache dei token può essere in violazione
diretta dei criteri di sicurezza desiderati per l'autenticazione. Anche se può sembrare
utile archiviare i token oltre la sessione corrente, in questo modo è possibile creare una
vulnerabilità di sicurezza consentendo l'accesso non autorizzato agli artefatti di Azure
Active Directory.
Configurazione dei controlli sessione di

autenticazione
L'accesso condizionale è una funzionalità di Azure AD Premium e richiede una licenza
Premium. Per altre informazioni sull'accesso condizionale, vedere Che cos'è l'accesso
condizionale in Azure Active Directory?
２ Avviso
Se si usa la funzionalità di durata del token configurabile attualmente in anteprima

pubblica, si noti che non è supportata la creazione di due criteri diversi per la stessa
combinazione di utenti o app: una con questa funzionalità e un'altra con la
funzionalità di durata del token configurabile. Microsoft ha ritirato la funzionalità di
durata del token configurabile per la durata dei token di aggiornamento e sessione
il 30 gennaio 2021 e l'ha sostituita con la funzionalità di gestione della sessione di
autenticazione dell'accesso condizionale.
Prima di abilitare frequenza di accesso, assicurarsi che altre impostazioni di

riautenticazione siano disabilitate nel tenant. Se è abilitata l'autenticazione a più
fattori nei dispositivi attendibili, assicurarsi di disabilitarla prima di usare la
frequenza di accesso, perché l'uso di queste due impostazioni insieme può causare
la richiesta imprevista agli utenti. Per altre informazioni sulle richieste di
riautenticazione e sulla durata della sessione, vedere l'articolo Ottimizzare le
richieste di riautenticazione e comprendere la durata della sessione per
l'autenticazione a più fattori di Azure AD.
Distribuzione dei criteri

La procedura consigliata è testare i criteri prima di distribuirli nell'ambiente di
produzione per assicurarsi che funzionino nel modo previsto. L'approccio ideale è usare
un tenant di test per verificare se il nuovo criterio funziona nel modo previsto. Per altre
informazioni, vedere l'articolo Pianificare una distribuzione dell'accesso condizionale.
Criterio 1: Controllo frequenza di accesso


5. Scegliere tutte le condizioni necessarie per l'ambiente del cliente, incluse le app
cloud di destinazione.
７ Nota
È consigliabile impostare la frequenza di richiesta di autenticazione uguale per

le app di Microsoft Office chiave, ad esempio Exchange Online e SharePoint
Online, per un'esperienza utente ottimale.
6. In Controlli di accesso>Sessione.
i. Scegliere Riutenticazione periodica e immettere un valore di ore o giorni o
selezionare Ogni volta.
7. Salvare i criteri.
Criterio 2: Sessione del browser persistente

5. Scegliere tutte le condizioni necessarie.
７ Nota
Si noti che questo controllo richiede di scegliere "Tutte le app cloud" come
condizione. La persistenza della sessione del browser è controllata dal token
di sessione di autenticazione. Tutte le schede in una sessione del browser
condividono un singolo token di sessione e pertanto devono condividere lo
stato di persistenza.
6. In Controlli di accesso>Sessione.
a. Selezionare Sessione del browser persistente.
７ Nota
La configurazione sessione del browser persistente in Accesso condizionale

di Azure AD esegue l'override di "Rimanere connessi?" impostazione nel
riquadro personalizzazione aziendale nel portale di Azure per lo stesso
utente se sono stati configurati entrambi i criteri.
b. Selezionare un valore dall'elenco a discesa.
7. Salvare i criteri.
Criterio 3: Controllo frequenza di accesso ogni utente

rischioso
b. In Escludi selezionare Utenti e gruppi e scegliere l'accesso di emergenza o gli
account break-glass dell'organizzazione.
7. In Condizioni>Rischio utente impostare Configura su Sì. In Configurare i livelli di
rischio utente necessari per applicare i criteri selezionareAlto e quindi selezionare
Fine.
8. In Controlli di accesso>Concedere l'accesso selezionareConcedi accesso, Richiedi
modifica password e selezionare Seleziona.
9. In Frequenza diaccessoai controlli> sessione selezionare Ogni volta.
Convalida
Usare lo strumento What If per simulare un accesso dall'utente all'applicazione di
destinazione e altre condizioni in base alla configurazione dei criteri. I controlli di
gestione delle sessioni di autenticazione vengono visualizzati nei risultati dello
strumento.
Tolleranza di richiesta
Fattoriamo per cinque minuti di deviazione dell'orologio, in modo che non venga
richiesto agli utenti più spesso di una volta ogni cinque minuti. Se l'utente ha eseguito
l'autenticazione a più fattori negli ultimi 5 minuti e ha raggiunto un altro criterio di
accesso condizionale che richiede la riutenticazione, non verrà richiesto all'utente.
L'over-prompt degli utenti per la riutenticazione può influire sulla produttività e
aumentare il rischio di approvazione delle richieste MFA che non hanno avviato. Usare
"Frequenza di accesso: ogni volta" solo per esigenze aziendali specifiche.
Problemi noti
Se si configura la frequenza di accesso per i dispositivi mobili: l'autenticazione
dopo ogni intervallo di frequenza di accesso potrebbe essere lenta, può richiedere
30 secondi in media. Inoltre, potrebbe verificarsi in varie app
contemporaneamente.
Nei dispositivi iOS: se un'app configura i certificati come primo fattore di
autenticazione e l'app ha frequenza di accesso e Intune criteri di gestione delle
applicazioni mobili applicati, gli utenti finali vengono bloccati dall'accesso all'app
quando i criteri attivano.
Passaggi successivi
vedere l'articolo Pianificare una distribuzione di accesso condizionale.
Risoluzione dei problemi relativi alle
modifiche dei criteri di accesso
condizionale
Articolo • 17/03/2023
Il log di controllo di Azure Active Directory (Azure AD) è una fonte preziosa di
informazioni durante la risoluzione dei problemi relativi al motivo e al modo in cui i
criteri di accesso condizionale sono stati modificati nell'ambiente.
I dati del log di controllo vengono mantenuti solo per 30 giorni per impostazione
predefinita, che potrebbero non essere abbastanza lunghi per ogni organizzazione. Le
organizzazioni possono archiviare i dati per periodi più lunghi modificando le
impostazioni di diagnostica in Azure AD in:
Inviare dati a un'area di lavoro Log Analytics

Archiviare i dati in un account di archiviazione
Trasmettere dati in Hub eventi
Inviare dati a una soluzione partner
Trovare queste opzioninell'impostazioneportale di Azure>Azure Active Directory,

Impostazioni di diagnostica> Modifica. Se non si dispone di un'impostazione di
diagnostica, seguire le istruzioni riportate nell'articolo Creare impostazioni di
diagnostica per inviare i log e le metriche della piattaforma a destinazioni diverse per
crearne una.
Usare il log di controllo

2. Passare ailog di controllo di Azure Active Directory>.
3. Selezionare l'intervallo di date che si desidera eseguire una query.
4. Nel filtro Servizio selezionare Accesso condizionale e selezionare il pulsante

Applica .
I log di controllo visualizzano tutte le attività, per impostazione predefinita. Aprire

il filtro Attività per restringere le attività. Per un elenco completo delle attività del
log di controllo per l'accesso condizionale, vedere le attività del log di controllo.
5. Selezionare una riga per visualizzare i dettagli. La scheda Proprietà modificate
elenca i valori JSON modificati per l'attività di controllo selezionata.
Usare Log Analytics

Log Analytics consente alle organizzazioni di eseguire query sui dati usando query
predefinite o query Kusto create personalizzate, per altre informazioni, vedere
Introduzione alle query di log in Monitoraggio di Azure.

Dopo aver abilitato l'accesso a Log Analytics nella portale di Azure>Azure AD>Log
Analytics. La tabella di interesse per gli amministratori di accesso condizionale è
AuditLogs.
Kusto
AuditLogs
| where OperationName == "Update conditional access policy"
Le modifiche sono disponibili in TargetResources>modifiedProperties.
Lettura dei valori

I valori precedenti e nuovi del log di controllo e Log Analytics sono in formato JSON.
Confrontare i due valori per visualizzare le modifiche apportate ai criteri.
Esempio di criterio precedente:
JSON
"conditions": {
"applications": {
"applicationFilter": null,
"excludeApplications": [
],
"797f4846-ba00-4fd7-ba43-dac1f8f63013"
],
"includeAuthenticationContextClassReferences": [
],
"includeUserActions": [
},
"clientAppTypes": [
"browser",
"mobileAppsAndDesktopClients"
],
"servicePrincipalRiskLevels": [
],
"signInRiskLevels": [
],
"userRiskLevels": [
],
"users": {
"excludeGroups": [
"eedad040-3722-4bcb-bde5-bc7c857f4983"
],
"excludeRoles": [
],
"excludeUsers": [
],
"includeGroups": [
],
"includeRoles": [
],
"includeUsers": [
"All"
},
"displayName": "Common Policy - Require MFA for Azure management",
"grantControls": {
"mfa"
],
"customAuthenticationFactors": [
],
"operator": "OR",
"termsOfUse": [
"a0d3eb5b-6cbe-472b-a960-0baacbd02b51"
},
"id": "334e26e9-9622-4e0a-a424-102ed4b185b3",
"modifiedDateTime": "2021-08-09T17:52:40.781994+00:00",
"state": "enabled"
Esempio di criteri aggiornato:
JSON
"conditions": {
"applications": {
"applicationFilter": null,
"excludeApplications": [
],
"797f4846-ba00-4fd7-ba43-dac1f8f63013"
],
"includeAuthenticationContextClassReferences": [
],
"includeUserActions": [
},
"clientAppTypes": [
"browser",
"mobileAppsAndDesktopClients"
],
"servicePrincipalRiskLevels": [
],
"signInRiskLevels": [
],
"userRiskLevels": [
],
"users": {
"excludeGroups": [
"eedad040-3722-4bcb-bde5-bc7c857f4983"
],
"excludeRoles": [
],
"excludeUsers": [
],
"includeGroups": [
],
"includeRoles": [
],
"includeUsers": [
"All"
},
"displayName": "Common Policy - Require MFA for Azure management",
"grantControls": {
"mfa"
],
"customAuthenticationFactors": [
],
"operator": "OR",
"termsOfUse": [
},
"id": "334e26e9-9622-4e0a-a424-102ed4b185b3",
"modifiedDateTime": "2021-08-09T17:52:54.9739405+00:00",
"state": "enabled"
Nell'esempio precedente, i criteri aggiornati non includono le condizioni per l'uso nei
controlli di concessione.
Ripristino dei criteri di accesso condizionale

Per altre informazioni sull'aggiornamento a livello di codice dei criteri di accesso
condizionale usando Microsoft API Graph, vedere l'articolo Accesso condizionale:
Accesso condizionale: Accesso a livello di codice.
Passaggi successivi
Che cos'è il monitoraggio di Azure Active Directory?
Installare e usare le viste di analisi dei log per Azure Active Directory
Accesso condizionale: accesso a livello di codice
Risoluzione dei problemi di accesso con
l'accesso condizionale
Articolo • 11/03/2023
Le informazioni contenute in questo articolo possono essere usate per risolvere i risultati
di accesso imprevisti relativi all'accesso condizionale usando i messaggi di errore e il log
di accesso di Azure AD.
Selezionare le conseguenze "tutte"

Il framework di accesso condizionale offre ottima flessibilità di configurazione. L'elevata
flessibilità, tuttavia, comporta la necessità di esaminare attentamente ogni criterio di
configurazione prima del rilascio per evitare risultati indesiderati. In questo contesto, è
necessario prestare particolare attenzione alle assegnazioni che interessano set
completi, ad esempio tutti gli utenti/i gruppi/le applicazioni cloud.
Le organizzazioni devono evitare le configurazioni seguenti:
Per tutti gli utenti e tutte le applicazioni cloud:
Blocca accesso: questa configurazione consente di bloccare l'intera

organizzazione.
Richiedi che i dispositivi siano contrassegnati come conformi: per gli utenti che
non hanno ancora registrato i propri dispositivi, questo criterio blocca tutti gli
accessi, incluso l'accesso al portale di Intune. Se l'utente è amministratore senza un
dispositivo registrato, questo criterio blocca l'accesso al portale di Azure per la
modifica dei criteri.
Richiedi dispositivo aggiunto ad Azure AD ibrido: questo criterio di blocco
dell'accesso può anche bloccare l'accesso per tutti gli utenti dell'organizzazione se
non questi hanno un dispositivo aggiunto ad Azure AD ibrido.
Richiedi criterio di protezione delle app: questo criterio di blocco dell'accesso può
anche bloccare l'accesso per tutti gli utenti dell'organizzazione se non sono
disponibili criteri di Intune. A un amministratore senza un'applicazione client con
criteri di protezione delle app di Intune questo criterio impedisce di tornare ai
portali, ad esempio quelli di Intune e Azure.
Per tutti gli utenti, tutte le applicazioni cloud e tutte le piattaforme per dispositivi:
Blocca accesso: questa configurazione consente di bloccare l'intera

organizzazione.
Interruzione dell'accesso con accesso
condizionale
La prima cosa da fare è esaminare il messaggio di errore visualizzato. Per i problemi di
accesso quando si usa un Web browser, la pagina di errore stessa contiene informazioni
dettagliate. Queste informazioni da sole possono descrivere il problema e suggerire una
soluzione.
Nell'errore qui sopra il messaggio indica che è possibile accedere all'applicazione solo
da dispositivi o applicazioni client che soddisfano i criteri di gestione dei dispositivi
mobili della società. In questo caso, l'applicazione e il dispositivo non soddisfano tali
criteri.
Eventi di accesso di Azure AD

Il secondo metodo per ottenere informazioni dettagliate sull'interruzione dell'accesso
consiste nell'esaminare gli eventi di accesso di Azure AD per vedere quali criteri di
accesso condizionale sono stati applicati e perché.
Per altre informazioni sul problema, fare clic su Altri dettagli nella pagina iniziale
dell'errore. Facendo clic su Altri dettagli vengono visualizzate informazioni sulla
risoluzione dei problemi utili durante la ricerca degli eventi di accesso di Azure AD per
individuare l'evento di errore specifico visualizzato dall'utente o quando si apre un
evento imprevisto di supporto con Microsoft.
Per individuare i criteri di accesso condizionale applicati e il motivo di tale applicazione,

eseguire le operazioni seguenti.

sicurezza o con il ruolo con autorizzazioni di lettura globali.
2. Passare ad Azure Active Directory>Accessi.
3. Individuare l'evento corrispondente all'accesso da esaminare. Aggiungere o

rimuovere filtri e colonne per escludere le informazioni non necessarie.
a. Aggiungere filtri per limitare l'ambito:
i. ID di correlazione quando si deve cercare la causa di un evento specifico.
ii. Accesso condizionale per verificare l'esito positivo e negativo dei criteri.
Definizione dell'ambito del filtro per visualizzare solo gli errori e limitare i
risultati.
iii. Nome utente per visualizzare le informazioni correlate a utenti specifici.
iv. Data nell'ambito dell'intervallo di tempo in questione.
4. Dopo aver trovato l'evento di accesso corrispondente all'errore di accesso
dell'utente, selezionare la scheda Accesso condizionale . La scheda Accesso
condizionale mostra i criteri o i criteri specifici che hanno causato l'interruzione
dell'accesso.
a. Le informazioni riportate nella scheda Risoluzione dei problemi e supporto
possono indicare chiaramente il motivo dell'errore di accesso, ad esempio il
fatto che il dispositivo non soddisfaceva i requisiti di conformità.
b. Per approfondire l'analisi, eseguire il drill-down nella configurazione dei criteri
facendo clic sul nome dei criteri. Facendo clic su Nome criterio viene
visualizzata l'interfaccia utente di configurazione dei criteri per il criterio
selezionato per la revisione e la modifica.
c. I dettagli relativi all'utente e al dispositivo client usati per la valutazione dei
criteri di accesso condizionale sono disponibili anche nelle schede Informazioni
di base, Posizione, Informazioni sul dispositivo, Dettagli di autenticazione e
Dettagli aggiuntivi dell'evento di accesso.
I criteri non funzionano come previsto

Se si selezionano i puntini di sospensione sul lato destro dei criteri in un evento di
accesso vengono visualizzati i dettagli dei criteri. Questa opzione fornisce agli
amministratori informazioni aggiuntive sui motivi per cui un criterio è stato applicato
correttamente oppure no.

A sinistra si trovano i dettagli raccolti all'accesso e a destra le informazioni dettagliate

sulla conformità di tali dettagli ai requisiti dei criteri di accesso condizionale applicati. I
criteri di accesso condizionale vengono applicati solo quando tutte le condizioni sono
soddisfatte o non configurate.
Se le informazioni nell'evento non sono sufficienti per comprendere i risultati

dell'accesso o modificare i criteri per ottenere i risultati desiderati, è possibile usare lo
strumento di diagnostica di accesso. La diagnostica di accesso è disponibile in
Informazioni di base>Evento di risoluzione dei problemi. Per altre informazioni sulla
diagnostica di accesso, vedere l'articolo Informazioni sulla diagnostica di accesso in
Azure AD. È anche possibile usare lo strumento What If per risolvere i problemi dei
Se è necessario inviare un evento di supporto, specificare l'ID della richiesta, l'ora e la

data dell'evento di accesso nei dettagli di invio dell'evento. Queste informazioni
consentono al supporto Tecnico Microsoft di trovare l'evento specifico di cui si è
interessati.
Codici errore comuni relativi all'accesso condizionale
Codice errore di accesso Stringa di errore
53000 DeviceNotCompliant
Codice errore di accesso Stringa di errore
53001 DeviceNotDomainJoined
53002 ApplicationUsedIsNotAnApprovedApp
53003 BlockedByConditionalAccess
53004 ProofUpBlockedDueToRisk
Altre informazioni sui codici errore sono disponibili nell'articolo Autenticazione di Azure
AD e codici errore relativi all'autorizzazione. I codici errore nell'elenco vengono
visualizzati con un prefisso AADSTS seguito dal codice visualizzato nel browser, ad
esempio AADSTS53002 .
Dipendenze dei servizi

In alcuni scenari specifici, gli utenti vengono bloccati perché sono presenti app cloud
con dipendenze dalle risorse bloccate dai criteri di accesso condizionale.
Per determinare la dipendenza del servizio, controllare il log di accesso per

l'applicazione e la risorsa chiamata dall'accesso. Nello screenshot seguente
l'applicazione chiamata è il Portale di Azure, ma la risorsa chiamata è l'API Gestione dei
servizi di Windows Azure. Per risolvere questo scenario in modo appropriato, tutte le
applicazioni e le risorse devono essere combinate in modo analogo nei criteri di accesso
condizionale.

Quali operazioni è necessario eseguire se non si

riesce ad accedere al portale di Azure?
Se non si riesce ad accedere al portale di Azure a causa di un'impostazione errata in un
criterio di accesso condizionale:
Controllare se siano presenti altri amministratori dell'organizzazione che non sono

ancora stati bloccati. Un amministratore con accesso al portale di Azure può
disabilitare il criterio che impedisce l'accesso.
Se nessun amministratore dell'organizzazione può aggiornare il criterio, inviare una
richiesta di supporto. Il supporto tecnico Microsoft può esaminare e, al momento
della conferma, aggiornare i criteri di accesso condizionale che impediscono
l'accesso.
Passaggi successivi
Usare lo strumento What If per risolvere i problemi dei criteri di accesso
condizionale
Report sulle attività di accesso nel portale di Azure
Risoluzione dei problemi di Accesso condizionale tramite lo strumento What If
Risoluzione dei problemi di Accesso
condizionale tramite lo strumento What
If
Articolo • 17/03/2023
Lo strumento What If in Accesso condizionale è utile per comprendere il motivo per cui
determinati criteri sono o non sono stati applicati a un utente in una circostanza
specifica o se dei criteri verrebbero applicati in uno stato noto.
Lo strumento What If si trova nel portale di Azure>Ascrittura dell'accesso

>condizionaledi Sicurezza>di Azure Active Directory>.
Raccolta di informazioni
Lo strumento What If richiede solo un'identità Utente o Carico di lavoro per iniziare.
Le informazioni aggiuntive seguenti sono facoltative, ma possono essere utili per la

definizione dell'ambito in casi specifici.
App cloud, azioni o contesto di autenticazione
Indirizzo IP
Paese/Area geografica
Piattaforma del dispositivo.
App client
Stato del dispositivo
Rischio di accesso
Livello di rischio utente
Rischio dell'entità servizio (anteprima)
Queste informazioni possono essere raccolte dall'utente, dal dispositivo dell'utente o dal
log degli accessi di Azure AD.
Generazione dei risultati

Immettere i criteri raccolti nella sezione precedente e selezionare What If per generare
un elenco di risultati.
In qualsiasi momento è possibile selezionare Reimposta per cancellare eventuali input

dei criteri e tornare allo stato predefinito.
Valutazione dei risultati
Criteri applicabili
Questo elenco indica i criteri di accesso condizionale che saranno applicabili in base alle
condizioni. L'elenco includerà sia i controlli di concessione che di sessione che si
applicano, inclusi quelli dei criteri in modalità solo report. Alcuni esempi includono la
richiesta di autenticazione a più fattori per accedere a un'applicazione specifica.
Criteri non applicabili

Questo elenco visualizzerà i criteri di Accesso condizionale che non saranno applicabili
se le condizioni sono risultate applicabili. L'elenco includerà tutti i criteri e il motivo per
cui non vengono applicati, inclusi quelli dei criteri in modalità solo report. Gli esempi
includono utenti e gruppi che possono essere esclusi da un criterio.
Caso d'uso
Molte organizzazioni creano criteri in base ai percorsi di rete, autorizzando i percorsi
attendibili e bloccando i percorsi dai quali non è previsto che si esegua l'accesso.
Per verificare che una configurazione sia stata eseguita in modo appropriato, un
amministratore può usare lo strumento What If per simulare l'accesso sia da un percorso
consentito sia da un percorso non consentito.
In questo caso all'utente viene impedito l'accesso a qualsiasi app cloud durante il suo
viaggio in Corea del Nord, perché Contoso ha bloccato l'accesso da tale località.
Questo test potrebbe essere espanso per incorporare altri punti dati al fine di limitare
l'ambito.
Passaggi successivi
Cos'è la modalità solo report dell'accesso condizionale?
Informazioni su Azure Active Directory Identity Protection
Informazioni sulle identità dei dispositivi
Funzionamento: Autenticazione a più fattori di Azure AD
Monitorare la valutazione continua
dell'accesso e risolvere i problemi
Articolo • 06/04/2023
Gli amministratori possono monitorare e risolvere i problemi degli eventi di accesso in

cui viene applicata la valutazione dell'accesso continuo (CAE) in diversi modi.
Creazione di report di accesso con valutazione

continua dell'accesso
Gli amministratori possono monitorare gli accessi utente in cui viene applicata la
valutazione dell'accesso continuo . Queste informazioni sono disponibili nei log di
accesso di Azure AD:

2. Passare ailog di accesso di Azure Active Directory>.
3. Applicare il filtro Is CAE Token (Token CAE ).
Da qui, gli amministratori vengono presentati con informazioni sugli eventi di accesso
dell'utente. Selezionare qualsiasi accesso per visualizzare i dettagli sulla sessione, ad
esempio i criteri di accesso condizionale applicati e se l'autorità di certificazione è
abilitata.
Sono presenti più richieste di accesso per ogni autenticazione. Alcuni si trovano nella
scheda interattiva, mentre altri si trovano nella scheda non interattiva. CaE è
contrassegnato come true solo per una delle richieste, può trovarsi nella scheda
interattiva o nella scheda non interattiva. Gli amministratori devono controllare
entrambe le schede per verificare se l'autenticazione dell'utente è abilitata o meno da
CAE.
Ricerca di tentativi di accesso specifici

I log di accesso contengono informazioni sugli eventi di esito positivo e negativo. Usare
i filtri per restringere la ricerca. Ad esempio, se un utente ha eseguito l'accesso a Teams,
usare il filtro Dell'applicazione e impostarlo su Teams. Gli amministratori potrebbero
dover controllare gli accessi dalle schede interattive e non interattive per individuare
l'accesso specifico. Per restringere ulteriormente la ricerca, gli amministratori possono
applicare più filtri.
Cartelle di lavoro di valutazione continua

dell'accesso
La cartella di lavoro delle informazioni dettagliate sulla valutazione dell'accesso continuo
consente agli amministratori di visualizzare e monitorare le informazioni dettagliate
sull'utilizzo di CAE per i tenant. Nella tabella vengono visualizzati i tentativi di
autenticazione con mancate corrispondenze IP. Questa cartella di lavoro è disponibile
come modello nella categoria Accesso condizionale.
Accesso al modello di cartella di lavoro CAE

L'integrazione di Log Analytics deve essere completata prima della visualizzazione delle
cartelle di lavoro. Per altre informazioni su come trasmettere i log di accesso di Azure
AD a un'area di lavoro Log Analytics, vedere l'articolo Integrare i log di Azure AD con i
log di Monitoraggio di Azure.

2. Passare aCartelle di lavoro diAzure Active Directory>.
3. In Modelli pubblici cercare Informazioni dettagliate sulla valutazione dell'accesso
continuo.
La cartella di lavoro Continuous Access Evaluation Insights contiene la tabella seguente:

Potenziale mancata corrispondenza dell'indirizzo IP tra
Azure AD e provider di risorse
La potenziale mancata corrispondenza dell'indirizzo IP tra la tabella del provider di
risorse di Azure AD & consente agli amministratori di analizzare le sessioni in cui
l'indirizzo IP rilevato da Azure AD non corrisponde all'indirizzo IP rilevato dal provider di
risorse.
Questa tabella della cartella di lavoro illustra questi scenari visualizzando i rispettivi
indirizzi IP e specificando se è stato emesso un token CAE durante la sessione.
Dati analitici di valutazione dell'accesso continuo per

accesso
Le informazioni dettagliate di valutazione dell'accesso continuo per ogni pagina di
accesso nella cartella di lavoro connettono più richieste dai log di accesso e visualizza
una singola richiesta in cui è stato emesso un token CAE.
Questa cartella di lavoro può essere utile, ad esempio quando: un utente apre Outlook
sul desktop e tenta di accedere alle risorse all'interno di Exchange Online. Questa azione
di accesso può essere mappata a più richieste di accesso interattive e non interattive nei
log, rendendo difficile la diagnosi dei problemi.
Configurazione dell'indirizzo IP
Il provider di identità e i provider di risorse potrebbero visualizzare indirizzi IP diversi.
Questa mancata corrispondenza può verificarsi a causa degli esempi seguenti:
La rete implementa il split tunneling.

Il provider di risorse usa un indirizzo IPv6 e Azure AD usa un indirizzo IPv4.
A causa delle configurazioni di rete, Azure AD vede un indirizzo IP dal client e il
provider di risorse vede un indirizzo IP diverso dal client.
Se questo scenario esiste nell'ambiente in uso, per evitare cicli infiniti, Azure AD rilascia
un token CAE di un'ora e non applica la modifica della posizione client durante tale
periodo di un'ora. Anche in questo caso, la sicurezza è migliorata rispetto ai token
tradizionali di un'ora, poiché stiamo ancora valutando gli altri eventi oltre agli eventi di
modifica della posizione client.
Gli amministratori possono visualizzare i record filtrati in base all'intervallo di tempo e

all'applicazione. Gli amministratori possono confrontare il numero di indirizzi IP non
corrispondenti rilevati con il numero totale di accessi durante un periodo di tempo
specificato.
Per sbloccare gli utenti, gli amministratori possono aggiungere indirizzi IP specifici a una
posizione denominata attendibile.

specifiche. Qui è possibile creare o aggiornare percorsi IP attendibili.
７ Nota
Prima di aggiungere un indirizzo IP come percorso denominato attendibile,

verificare che l'indirizzo IP appartenga effettivamente all'organizzazione prevista.
Per altre informazioni sulle località denominate, vedere l'articolo Uso della condizione di
posizione
Passaggi successivi
Integrare i log di Azure AD con i log di Monitoraggio di Azure
Uso della condizione di posizione
Valutazione continua dell'accesso
Eseguire la migrazione dell'app client
approvata ai criteri di protezione delle
applicazioni nell'accesso condizionale
Articolo • 31/03/2023
Questo articolo illustra come eseguire la migrazione dalla concessione dell'accesso

condizionale dell'app client approvata alla concessione dei criteri di protezione delle
applicazioni. Protezione di app criteri offrono la stessa perdita e protezione dei dati dei
criteri delle app client approvati, ma con altri vantaggi. Per altre informazioni sui
vantaggi dell'uso dei criteri di protezione delle app, vedere l'articolo Protezione di app
panoramica dei criteri.
La concessione dell'app client approvata viene ritirata all'inizio di marzo 2026. Le

organizzazioni devono eseguire la transizione di tutti i criteri di accesso condizionale
correnti che usano solo la concessione dell'app client approvata a Richiedi app client
approvata o ai criteri di protezione delle applicazioni entro marzo 2026. Inoltre, per
qualsiasi nuovo criterio di accesso condizionale, applicare solo la concessione dei criteri
Richiedi protezione delle applicazioni.
Dopo marzo 2026, Microsoft smetterà di applicare il controllo dell'app client approvata
e sarà come se questa concessione non sia selezionata. Usare la procedura seguente
prima di marzo 2026 per proteggere i dati dell'organizzazione.
Modificare un criterio di accesso condizionale

esistente
Richiedere app client approvate o criteri di protezione delle app con dispositivi mobili
I passaggi seguenti rendono i criteri di accesso condizionale esistenti richiedono un'app

client approvata o un criterio di protezione delle app quando si usa un dispositivo
iOS/iPadOS o Android. Questo criterio funziona in combinazione con un criterio di
protezione delle app creato in Microsoft Intune.
Le organizzazioni possono scegliere di aggiornare i criteri attenendosi alla procedura

seguente.

3. Selezionare un criterio che usa la concessione dell'app client approvata.
app

Ripetere i passaggi precedenti in tutti i criteri che usano la concessione dell'app client
approvata.
２ Avviso
Non tutte le applicazioni supportate come applicazioni approvate o supportano i

criteri di protezione delle applicazioni. Per un elenco di alcune app client comuni,
vedere Protezione di app requisito dei criteri. Se l'applicazione non è presente
nell'elenco, contattare lo sviluppatore dell'applicazione.

Richiedere i criteri di protezione delle app con i dispositivi mobili
La procedura seguente consente di creare criteri di accesso condizionale che richiedono

un'app client approvata o un criterio di protezione delle app quando si usa un
dispositivo iOS/iPadOS o Android. Questo criterio funziona in combinazione con un
criterio di protezione delle app creato in Microsoft Intune.
Le organizzazioni possono scegliere di distribuire questo criterio seguendo questa

procedura.

impedire il blocco. Se non si escludono account, non è possibile creare il
criterio.
7. In Condizioni Piattaforme>del dispositivo impostare Configura su Sì.
a. In Includiselezionare le piattaforme del dispositivo.
b. Scegliere Android e iOS
app

７ Nota
Se un'app non supporta Richiedi i criteri di protezione delle app, gli utenti finali
che provano ad accedere alle risorse da tale app verranno bloccati.
Passaggi successivi
Per altre informazioni sui criteri di protezione delle applicazioni, vedere:
Panoramica dei criteri di protezione app

Controlli personalizzati (anteprima)
Articolo • 03/06/2023
I controlli personalizzati sono una funzionalità di anteprima di Azure Active Directory.

Quando si usano controlli personalizzati, gli utenti vengono reindirizzati a un servizio
compatibile per soddisfare i requisiti di autenticazione all'esterno di Azure Active
Directory. Per soddisfare questo controllo, il browser di un utente viene reindirizzato al
servizio esterno, esegue qualsiasi autenticazione necessaria e quindi viene reindirizzato
ad Azure Active Directory. Azure Active Directory verifica la risposta e, se l'utente è stato
autenticato o convalidato correttamente, l'utente continua nel flusso di accesso
condizionale.
７ Nota
Per altre informazioni sulle modifiche che stiamo pianificando per la funzionalità
Controllo personalizzato, vedere l'archivio di febbraio 2020 per novità.
Creazione di controlli personalizzati
） Importante
I controlli personalizzati non possono essere usati con l'automazione di Identity

Protection che richiede l'autenticazione a più fattori di Azure AD, la reimpostazione
della password self-service di Azure AD, soddisfa i requisiti di attestazione di
autenticazione a più fattori, per elevare i ruoli in Privileged Identity Manager (PIM),
come parte Intune della registrazione del dispositivo, per i trust tra tenant o
quando si unisce i dispositivi ad Azure AD.
I controlli personalizzati funzionano con un set limitato di provider di autenticazione

approvati. Per creare un controllo personalizzato, è opportuno prima contattare il
provider a cui ci si vuole rivolgere. Ogni provider non Microsoft ha i propri requisiti e
processi per iscriversi, sottoscrivere o altrimenti diventare parte del servizio e indicare
che si vuole integrare con l'accesso condizionale. A questo punto, il provider offre un
blocco di dati in formato JSON. Questi dati consentono al provider e all'accesso
condizionale di collaborare per il tenant, crea il nuovo controllo e definisce il modo in
cui l'accesso condizionale può indicare se gli utenti hanno eseguito correttamente la
verifica con il provider.
Copiare i dati JSON e incollarli nella casella di testo corrispondente. Non apportare
modifiche al codice JSON a meno che non si comprenda in modo esplicito la modifica
apportata. L'introduzione di una modifica potrebbe interrompere la connessione tra il
provider e Microsoft e potenzialmente bloccare gli utenti fuori dai rispettivi account.
L'opzione per creare un controllo personalizzato si trova nella sezione Gestisci della
pagina Accesso condizionale .
Facendo clic su Nuovo controllo personalizzato si apre un pannello con una casella di
testo per i dati JSON relativi al controllo.
Eliminazione di controlli personalizzati
Per eliminare un controllo personalizzato, è prima necessario assicurarsi che non venga
usato in alcun criterio di accesso condizionale. Al termine della procedura:
1. Passare all'elenco di controlli personalizzati

2. Selezionare...
3. Selezionare Elimina.
Modifica di controlli personalizzati

Per modificare un controllo personalizzato, è necessario eliminare il controllo corrente e
creare un nuovo controllo con le informazioni aggiornate.
Limitazioni note
I controlli personalizzati non possono essere usati con l'automazione di Identity
Protection che richiede l'autenticazione a più fattori di Azure AD, la reimpostazione della
password self-service di Azure AD, soddisfa i requisiti di attestazione di autenticazione a
più fattori, per elevare i ruoli in Privileged Identity Manager (PIM), come parte Intune
della registrazione del dispositivo, per i trust tra tenant o quando si unisce i dispositivi
ad Azure AD.
Passaggi successivi
condizionale
Migrazione dei criteri classici di accesso
condizionale
Articolo • 17/03/2023
L'accesso condizionale è lo strumento usato da Azure Active Directory per raggruppare i

segnali, consentendo di prendere decisioni e applicare i criteri dell'organizzazione.
L'accesso condizionale è la base del nuovo piano di controllo basato su identità. Anche
se lo scopo è ancora lo stesso, il rilascio della nuova portale di Azure ha introdotto
miglioramenti significativi al funzionamento dell'accesso condizionale.
Valutare la possibilità di eseguire la migrazione dei criteri non creati nel portale di Azure
perché:
È ora possibile risolvere gli scenari che non è stato possibile gestire in precedenza.
Il consolidamento consente di ridurre il numero di criteri da gestire.
È possibile gestire tutti i criteri di accesso condizionale in un'unica posizione
centrale.
Il portale di Azure classico verrà ritirato.
Questo articolo illustra cosa è necessario sapere per eseguire la migrazione dei criteri di
accesso condizionale esistenti al nuovo framework.
Criteri classici
Nella portale di Azure i criteri di accesso condizionale sono disponibili inAccesso
condizionaleper la sicurezza> di Azure Active Directory>. L'organizzazione potrebbe
anche avere criteri di accesso condizionale meno recenti non creati usando questa
pagina. Questi criteri sono noti come criteri classici. I criteri classici sono criteri di
accesso condizionale, creati in:
Portale di Azure classico

Portale di Intune classico
Portale di Protezione app di Intune
Nella pagina Accesso condizionale è possibile accedere ai criteri classici facendo clic su
Criteri classici nella sezione Gestisci .
La visualizzazione Criteri classici consente di eseguire queste operazioni:
Filtrare i criteri classici.
Disabilitare i criteri classici.
Esaminare le impostazioni di un criterio classico e disabilitarlo.

２ Avviso
Dopo aver disabilitato un criterio classico non può essere riabilitato.
La visualizzazione dei dettagli di un criterio classico consente di documentare le

impostazioni, modificare i gruppi inclusi o esclusi e disabilitare il criterio.
Modificando i gruppi selezionati o escludendo gruppi specifici, è possibile testare
l'effetto di un criterio classico disabilitato per alcuni utenti di test prima di disabilitare i
criteri per tutti gli utenti e i gruppi inclusi.
Considerazioni sulla migrazione

In questo articolo i criteri di accesso condizionale di Azure AD vengono definiti anche
nuovi criteri.
I criteri classici continuano a funzionare in parallelo con quelli nuovi finché
non vengono disabilitati o eliminati.
Nella prospettiva di un consolidamento dei criteri è importante considerare gli aspetti

seguenti:
Diversamente dai criteri classici, che sono legati a un'app cloud specifica, i criteri
nuovi consentono di selezionare tutte le app cloud desiderate.
I controlli applicati da criteri classici e criteri nuovi per un'app cloud devono
risultare tutti soddisfatti (AND).
Nei criteri nuovi è possibile:
Combinare più condizioni, se necessarie per lo specifico scenario.
Selezionare più requisiti di controllo di accesso e combinarli con un OR logico
(per richiedere uno dei controlli selezionati) o con un AND logico (per richiedere
tutti i controlli selezionati).
Exchange Online
Se si vuole eseguire la migrazione dei criteri classici per Exchange Online che includono
Exchange Active Sync come condizione delle app client, potrebbe non essere possibile
consolidarle in un nuovo criterio.
Ciò avviene, ad esempio, quando si vuole includere il supporto per tutti i tipi di app
client. In un criterio nuovo con Exchange Active Sync come condizione per le app client,
non è possibile selezionare altre app client.
Il consolidamento in un criterio nuovo non è possibile nemmeno se i criteri classici

contengono più condizioni. Un nuovo criterio con Exchange Active Sync come
condizione delle app client configurate non supporta altre condizioni:
Se sono configurati nuovi criteri con Exchange Active Sync come condizione per le app
client, è necessario assicurarsi che tutte le altre condizioni non siano configurate.
I criteri classici basati su app per Exchange Online che includono Exchange Active Sync
come condizione delle app client consentono piattaforme di dispositivi supportate e
non supportate. Anche se non si possono configurare singole piattaforme di dispositivo
in un criterio nuovo correlato, è possibile limitare il supporto alle piattaforme di
dispositivo supportate.
È possibile consolidare più criteri classici che includono Exchange Active Sync come
condizione per le app client se questi hanno:
Solo Exchange Active Sync come condizione

Sono configurati diversi requisiti per la concessione dell'accesso
Uno scenario comune consiste nel consolidamento dei criteri seguenti:
Un criterio classico basato su dispositivo configurato nel portale di Azure classico

Un criterio classico basato su app configurato nel portale di Protezione app di
Intune
In questo caso, è possibile consolidare i criteri classici in un unico criterio nuovo con
entrambi i requisiti selezionati.
I criteri classici con controlli basati su app sono preconfigurati con iOS e Android come
condizione per le piattaforme di dispositivo.
In un criterio nuovo è necessario selezionare le piattaforme di dispositivo da supportare

singolarmente.
Passaggi successivi
Usare la modalità solo report per l'accesso condizionale per determinare l'impatto
Per informazioni su come configurare un criterio di accesso condizionale, vedere
Criteri comuni di accesso condizionale.
vedere l'articolo Procedura: Pianificare la distribuzione dell'accesso condizionale in
Azure Active Directory.
Eseguire la migrazione di criteri classici
nel portale di Azure
Articolo • 17/03/2023
Questo articolo illustra come eseguire la migrazione di criteri classici che richiedono
l'autenticazione a più fattori per un'app cloud. Anche se non è un prerequisito, è
consigliabile leggere Eseguire la migrazione dei criteri classici nel portale di Azure prima
di iniziare la migrazione dei criteri classici.
Il processo di migrazione è costituito dai passaggi seguenti:
1. Aprire il criterio classico per ottenere le impostazioni di configurazione.

2. Creare un nuovo criterio di accesso condizionale di Azure Active Directory per
sostituire il criterio classico.
3. Disabilitare il criterio classico.
Aprire un criterio classico

1. Nella portale di Azure passare adAccesso condizionaleper la sicurezza> di
Azure Active Directory>.
2. Selezionare Criteri classici.
3. Nell'elenco dei criteri classici selezionare i criteri di cui si vuole eseguire la

migrazione. Documentare le impostazioni di configurazione in modo che sia
possibile ricreare con un nuovo criterio di accesso condizionale.
Per esempi di criteri comuni e la relativa configurazione nei portale di Azure, vedere
l'articolo Criteri di accesso condizionale comuni.
Disabilitare i criteri classico

Per disabilitare i criteri classici, selezionare Disabilita nella visualizzazione Dettagli .
Passaggi successivi
Per altre informazioni sulla migrazione dei criteri classici, vedere Migrare i criteri
classici nel portale di Azure.
Usare la modalità solo report per l'accesso condizionale per determinare l'impatto
App incluse nella suite di app per
l'accesso condizionale Office 365
Articolo • 17/03/2023
L'elenco seguente viene fornito come riferimento e include un elenco dettagliato di

servizi e applicazioni inclusi nell'app per l'accesso condizionale Office 365.
Ciclo di aumento
Registratore di chiamate
Connettori
servizio Gestione dispositivi
EnrichmentSvc
IC3 Gateway
Servizio di analisi e trasformazione dei supporti
App Richiamo messaggi
Supporto asincrono per la messaggistica
MessagingAsyncMediaProd
Microsoft 365 Reporting Service
Servizio Di individuazione Microsoft
protezione Microsoft Exchange Online
Microsoft Flow
Microsoft Flow GCC
Microsoft Forms
Microsoft Forms Web
Microsoft Forms Web in Azure per enti pubblici
Microsoft Legacy To-Do WebApp
portale di Microsoft Office 365
Applicazione client di Microsoft Office
Servizio schede Contatti Microsoft
Microsoft SharePoint Online - Home page di SharePoint
portale di Microsoft Stream
servizio Microsoft Stream
Microsoft Teams
Microsoft Teams - T4L Web Client
Microsoft Teams - Servizio Teams e canali
Microsoft Teams Chat Aggregator
Servizio Graph di Microsoft Teams
Servizio di vendita al dettaglio di Microsoft Teams
Servizi di Microsoft Teams
Interfaccia utente di Microsoft Teams
Microsoft Teams Web Client
Microsoft To-Do WebApp
Microsoft Whiteboard Services
Esperienza utente di Office 365 Suite
Servizio di archiviazione OCPS
Office 365'app, corrispondente a un siteId migrato.
microservizi di Exchange Office 365
Office 365 Exchange Online
Servizio di ricerca di Office 365
Office 365 SharePoint Online
Office 365 Yammer
Office Delve
Office Hive
Office Hive Azure per enti pubblici
Office Online
Office Services Manager
Office Services Manager in USGov
Servizio Office Shredding
WCSS-Client shell di Office365
WCSS-Client shell di Office365 in Azure per enti pubblici
OfficeClientService
OfficeHome
OneDrive
OneDrive SyncEngine
OneNote
Estensione del browser Outlook
Servizio Outlook per Exchange
Servizio PowerApps
PowerApps Web
PowerApps Web GCC
ProjectWorkManagement
ProjectWorkManagement_USGov
Rispondi alla menzione
Centro sicurezza & conformità
Estendibilità del client Web di SharePoint Online
Isolamento dell'estendibilità del client Web di SharePoint Online
API Amministrazione tenant di Skype e Teams
Skype meeting broadcast
Servizio Di presenza Skype
SmartCompose
Sway
Servizio di messaggistica di destinazione
App DoD GCC per office.com
WCSS-Client DoD della shell di Office365
conditionalAccessPolicy resource type
Article • 01/21/2022
Namespace: microsoft.graph
Represents an Azure Active Directory conditional access policy. Conditional access

policies are custom rules that define an access scenario. For more information, see the
Conditional access documentation.
Methods
Method Return Type Description
List conditionalAccessPolicy Get all of the conditionalAccessPolicies

conditionalAccessPolicies collection objects in the organization.
Create conditionalAccessPolicy Create a new conditionalAccessPolicy

conditionalAccessPolicy object.
Get conditionalAccessPolicy Read properties and relationships of a

conditionalAccessPolicy conditionalAccessPolicy object.
Update conditionalAccessPolicy Update a conditionalAccessPolicy object.

conditionalAccessPolicy
Delete None Delete a conditionalAccessPolicy object.

conditionalAccessPolicy
Properties
Property Type Description
conditions conditionalAccessConditionSet Specifies the rules that must be met for

the policy to apply. Required.
createdDateTime DateTimeOffset The Timestamp type represents date

and time information using ISO 8601
format and is always in UTC time. For
example, midnight UTC on Jan 1, 2014 is
2014-01-01T00:00:00Z . Readonly.
displayName String Specifies a display name for the

conditionalAccessPolicy object.
grantControls conditionalAccessGrantControls Specifies the grant controls that must

be fulfilled to pass the policy.
id String Specifies the identifier of a

conditionalAccessPolicy object. Read-
only.
modifiedDateTime DateTimeOffset The Timestamp type represents date

and time information using ISO 8601
format and is always in UTC time. For
example, midnight UTC on Jan 1, 2014 is
2014-01-01T00:00:00Z . Readonly.
sessionControls conditionalAccessSessionControls Specifies the session controls that are

enforced after sign-in.
state conditionalAccessPolicyState Specifies the state of the

conditionalAccessPolicy object. Possible
values are: enabled , disabled ,
enabledForReportingButNotEnforced .
Required.
Relationships
None.
JSON representation
The following is a JSON representation of the resource.
JSON
"conditions": {"@odata.type":
"microsoft.graph.conditionalAccessConditionSet"},
"createdDateTime": "String (timestamp)",
"displayName": "String",
"grantControls": {"@odata.type":
"microsoft.graph.conditionalAccessGrantControls"},
"id": "String (identifier)",
"modifiedDateTime": "String (timestamp)",
"sessionControls": {"@odata.type":
"microsoft.graph.conditionalAccessSessionControls"},
"state": "string"
namedLocation resource type

Article • 01/21/2022
This is the base class that represents an Azure Active Directory named location. Named
locations are custom rules that define network locations which can then be used in a
Conditional Access policy.
Methods
List namedLocation Get all the namedLocation objects in the

namedLocations collection organization.
Get namedLocation Read the properties and relationships of a

namedLocation namedLocation object.
Delete None Delete a namedLocation object.

namedLocation
Properties
createdDateTime DateTimeOffset The Timestamp type represents creation date and time of
the location using ISO 8601 format and is always in UTC
time. For example, midnight UTC on Jan 1, 2014 is 2014-
01-01T00:00:00Z . Read-only.
displayName String Human-readable name of the location.
id String Identifier of a namedLocation object. Read-only.
modifiedDateTime DateTimeOffset The Timestamp type represents last modified date and
time of the location using ISO 8601 format and is always
in UTC time. For example, midnight UTC on Jan 1, 2014 is
2014-01-01T00:00:00Z . Read-only.
Relationships
None.
JSON representation
JSON
"modifiedDateTime": "String (timestamp)"
See also
What is Conditional Access?
Using the location condition in a Conditional Access policy
countryNamedLocation resource type
Article • 01/21/2022
Represents an Azure Active Directory named location defined by countries and regions.
Named locations are custom rules that define network locations which can then be used
in a Conditional Access policy.
Inherits from namedLocation
Methods
List countryNamedLocation Get all the countryNamedLocation objects

countryNamedLocations collection in the organization.
Create countryNamedLocation Create a new countryNamedLocation

countryNamedLocation object.
Get countryNamedLocation Read the properties and relationships of a

countryNamedLocation countryNamedLocation object.
Update countryNamedLocation Update a countryNamedLocation object.

countryNamedLocation
Delete None Delete a countryNamedLocation object.

countryNamedLocation
Properties
countriesAndRegions String collection List of countries and/or

regions in two-letter
format specified by ISO
3166-2. Required.
countryLookupMethod countryLookupMethodType Determines what method

is used to decide which
country the user is located
in. Possible values are
clientIpAddress (default)
and authenticatorAppGps .
Note:
authenticatorAppGps is
not yet supported in the
Microsoft Cloud for US
Government.
createdDateTime DateTimeOffset The Timestamp type

represents creation date
and time of the location
using ISO 8601 format and
is always in UTC time. For
example, midnight UTC on
Jan 1, 2014 is 2014-01-
01T00:00:00Z . Read-only.
Inherited from
namedLocation.
displayName String Human-readable name of

the location. Required.
Inherited from
namedLocation.
id String Identifier of a
namedLocation object.
Read-only. Inherited from
namedLocation.
includeUnknownCountriesAndRegions Boolean true if IP addresses that

don't map to a country or
region should be included
in the named location.
Optional. Default value is
false .
modifiedDateTime DateTimeOffset The Timestamp type

represents last modified
date and time of the
location using ISO 8601
format and is always in
UTC time. For example,
midnight UTC on Jan 1,
2014 is 2014-01-
01T00:00:00Z . Read-only.
Inherited from
namedLocation.
Relationships
None.
JSON representation
JSON
"countriesAndRegions": ["String"],
"countryLookupMethod": "String",
"includeUnknownCountriesAndRegions": true,
See also
ipNamedLocation resource type
Article • 02/03/2023
Represents an Azure Active Directory named location defined by IP ranges. Named

locations are custom rules that define network locations which can then be used in a
Conditional Access policy.
Inherits from namedLocation
Methods
List ipNamedLocation Get all the ipNamedLocation objects in the

ipNamedLocations collection organization.
Create ipNamedLocation Create a new ipNamedLocation object.

ipNamedLocation
Get ipNamedLocation Read the properties and relationships of an

ipNamedLocation ipNamedLocation object.
Update ipNamedLocation Update an ipNamedLocation object.

ipNamedLocation
Delete None Delete an ipNamedLocation object.

ipNamedLocation
Properties
createdDateTime DateTimeOffset The Timestamp type represents creation date and time of
the location using ISO 8601 format and is always in UTC
time. For example, midnight UTC on Jan 1, 2014 is 2014-
01-01T00:00:00Z . Read-only. Inherited from
namedLocation.
displayName String Human-readable name of the location. Required.
id String Identifier of a namedLocation object. Read-only. Inherited

from namedLocation.
ipRanges ipRange List of IP address ranges in IPv4 CIDR format (e.g.

collection 1.2.3.4/32) or any allowable IPv6 format from IETF
RFC5969. Required.
isTrusted Boolean true if this location is explicitly trusted. Optional. Default

value is false .
modifiedDateTime DateTimeOffset The Timestamp type represents last modified date and
time of the location using ISO 8601 format and is always
in UTC time. For example, midnight UTC on Jan 1, 2014 is
2014-01-01T00:00:00Z . Read-only. Inherited from
namedLocation.
Relationships
None.
JSON representation
JSON
"ipRanges": [{"@odata.type": "microsoft.graph.ipRange"}],
"isTrusted": true,
See also
conditionalAccessTemplate resource
type
Article • 01/26/2023
Represents a Microsoft recommended template of best practice configurations for Azure

Active Directory conditional access policies.
Inherits from entity.
Methods
Method Return type Description
List conditionalAccessTemplate Get a list of the

conditionalAccessTemplates collection conditionalAccessTemplate objects
and their properties.
Get conditionalAccessTemplate Read the properties and relationships

conditionalAccessTemplate of a conditionalAccessTemplate
object.
Properties
description String The user-friendly name of the template.
details conditionalAccessPolicyDetail Complete list of policy details specific to the

template. This property contains the JSON of policy
settings for configuring a Conditional Access policy.
id String Immutable ID of a template. Inherited from entity.
name String The user-friendly name of the template.
scenarios templateScenarios List of conditional access scenarios that the

template is recommended for. The possible values
are: new , secureFoundation , zeroTrust , remoteWork ,
protectAdmins , emergingThreats ,
unknownFutureValue . This is a multi-valued enum.
Supports $filter ( has ).
Relationships
None.
JSON representation
JSON
"@odata.type": "#microsoft.graph.conditionalAccessTemplate",
"description": "String",
"details": {
"@odata.type": "microsoft.graph.conditionalAccessPolicyDetail",
"name": "String",
"scenarios": "String"
Novità di Azure Active Directory

Articolo • 02/06/2023
Ricevere una notifica su quando rivedere questa pagina per gli aggiornamenti
copiando e incollando questo URL: https://learn.microsoft.com/api/search/rss?
search=%22Release+notes+-+Azure+Active+Directory%22&locale=en-us nel di icone
del lettore di feed di feed feed RSS.
Azure AD viene regolarmente migliorato. Per stare al passo con gli sviluppi più recenti,
questo articolo fornisce informazioni sugli argomenti seguenti:
Versioni più recenti

Problemi noti
Correzioni di bug
Funzionalità deprecate
Modifiche pianificate
Questa pagina viene aggiornata ogni mese, quindi rivedila regolarmente. Se si cercano
elementi più vecchi di sei mesi, è possibile trovarli in Archivio per novità in Azure Active
Directory.
Maggio 2023
Disponibilità generale - Livello di autenticazione

dell'accesso condizionale per membri, utenti esterni e
restrizioni FIDO2
Tipo: Nuova funzionalità
Categoria di servizio: Accesso condizionale
Funzionalità del prodotto: Identity Security & Protection
L'attendibilità dell'autenticazione è un controllo di accesso condizionale che consente

agli amministratori di specificare quale combinazione di metodi di autenticazione può
essere usata per accedere a una risorsa. Ad esempio, possono rendere disponibili solo
metodi di autenticazione resistenti al phishing per accedere a una risorsa sensibile. Allo
stesso modo, per accedere a una risorsa senza distinzione, possono consentire
combinazioni di autenticazione a più fattori (MFA) meno sicure, ad esempio password e
SMS.
L'attendibilità dell'autenticazione è ora disponibile a livello generale per i membri e gli
utenti esterni da qualsiasi restrizione cloud Microsoft e FIDO2. Per altre informazioni,
vedere Livello di autenticazione dell'accesso condizionale.
Disponibilità generale - Autenticazione del provider di

identità basata su SAML/Ws-Fed per gli utenti B2B di
Azure Active Directory nei cloud NAT degli Stati Uniti e
sec negli Stati Uniti
Categoria di servizio: B2B
Funzionalità del prodotto: B2B/B2C
I provider di identità basati su SAML/Ws-Fed per l'autenticazione in Azure AD B2B sono

disponibili a livello generale nei cloud US Sec, US Nat e Cina. Per altre informazioni,
vedere Federazione con provider di identità SAML/WS-Fed per gli utenti guest.
Disponibilità generale - Sincronizzazione tra tenant

Categoria di servizio: Provisioning
Funzionalità del prodotto: Gestione del ciclo di vita delle identità
La sincronizzazione tra tenant consente di configurare una soluzione scalabile e

automatizzata per consentire agli utenti di accedere alle applicazioni tra tenant
dell'organizzazione. Si basa sulla funzionalità B2B di Azure Active Directory e
automatizza la creazione, l'aggiornamento e l'eliminazione degli utenti B2B all'interno
dei tenant dell'organizzazione. Per altre informazioni, vedere: Che cos'è la
sincronizzazione tra tenant?.
Anteprima pubblica (aggiornamento) - Estensioni

personalizzate in Gestione entitlement
Categoria di servizio: Gestione entitlement
Funzionalità del prodotto: Identity Governance
L'anno scorso è stata annunciata l'anteprima pubblica delle estensioni personalizzate in

Entitlement Management che consente di automatizzare processi complessi quando
viene richiesto o sta per scadere l'accesso. Di recente è stata espansa l'anteprima
pubblica per consentire la sospensione della richiesta di assegnazione del pacchetto di
accesso durante l'esecuzione del processo esterno. Inoltre, il processo esterno può ora
fornire feedback a Entitlement Management per visualizzare informazioni aggiuntive
agli utenti finali in MyAccess o persino arrestare la richiesta di accesso. In questo modo
si espandono gli scenari di estensione personalizzata dalle notifiche ad altri stakeholder
o dalla generazione di ticket a scenari avanzati, ad esempio governance esterna, rischi e
controlli di conformità. Nel corso di questo aggiornamento sono stati migliorati anche i
log di controllo, la sicurezza dei token e il payload inviato all'app per la logica. Per altre
informazioni sull'aggiornamento in anteprima, vedere:
Attivare App per la logica con estensioni personalizzate nella gestione entitlement
(anteprima)
accessPackageAssignmentRequest: resume
tipo di risorsa accessPackageAssignmentWorkflowExtension
tipo di risorsa accessPackageAssignmentRequestWorkflowExtension
Disponibilità generale - Identità gestita in Microsoft

Authentication Library per .NET
Categoria di servizio: Autenticazioni (accessi)
Funzionalità del prodotto: Autenticazione utente
La versione più recente di MSAL.NET laureati le API di gestione delle identità nella
modalità di disponibilità generale del supporto, il che significa che gli sviluppatori
possono integrarli in modo sicuro nei carichi di lavoro di produzione.
Le identità gestite fanno parte dell'infrastruttura di Azure, semplificando il modo in cui

gli sviluppatori gestiscono le credenziali e i segreti per accedere alle risorse cloud. Con
le identità gestite, gli sviluppatori non devono gestire manualmente il recupero e la
sicurezza delle credenziali. Possono invece basarsi su un set di identità gestito
automaticamente per connettersi alle risorse che supportano l'autenticazione di Azure
Active Directory (AAD). Per altre informazioni, vedere Che cosa sono le identità gestite
per le risorse di Azure?
Con MSAL.NET 4.54.0, le API di gestione delle identità sono ora stabili. Sono state
aggiunte alcune modifiche che semplificano l'uso e l'integrazione che potrebbero
richiedere la modifica del codice se è stata usata l'implementazione sperimentale :
Quando si usano le API di gestione delle identità, gli sviluppatori dovranno

specificare il tipo di identità durante la creazione di managedIdentityApplication.
Quando si acquisiscono token con API di identità gestita e si usa il client HTTP
predefinito, MSAL ritenta la richiesta per determinati codici di eccezione.
È stata aggiunta una nuova classe MsalManagedIdentityException che rappresenta
eventuali eccezioni correlate all'identità gestita. Include informazioni generali sulle
eccezioni, inclusa l'origine di Azure da cui ha origine l'eccezione.
MSAL aggiornerà ora in modo proattivo i token acquisiti con l'identità gestita.
Per iniziare a usare l'identità gestita in MSAL.NET, è possibile usare il pacchetto

Microsoft.Identity.Client insieme alla classe ManagedIdentityApplicationBuilder .
Anteprima pubblica - Nuova esperienza gruppi personali

Tipo: Funzionalità modificata
Categoria di servizio: Gestione gruppi
Funzionalità del prodotto: Esperienze utente finali
Un'esperienza di gruppi personali nuova e migliorata è ora disponibile in

myaccount.microsoft.com/groups . Questa esperienza sostituisce l'esperienza Gruppi
personali esistente in mygroups.microsoft.com a maggio. Per altre informazioni, vedere:
Aggiornare le informazioni sui gruppi nel portale di App personali .
Disponibilità generale: gli amministratori possono

impedire agli utenti di creare tenant
Categoria di servizio: Gestione degli accessi utente
Funzionalità del prodotto: Gestione utenti
La possibilità per gli utenti di creare tenant dalla panoramica di Gestisci tenant è stata
presente in Azure AD sin dall'inizio del portale di Azure. Questa nuova funzionalità nel
riquadro Impostazioni utente consente agli amministratori di impedire agli utenti di
creare nuovi tenant. È disponibile anche un nuovo ruolo Autore tenant per consentire a
utenti specifici di creare tenant. Per altre informazioni, vedere Autorizzazioni utente
predefinite.
Anteprima pubblica : dispositivi Self-Help funzionalità per

dispositivi in sospeso
Categoria di servizio: Gestione dell'accesso ai dispositivi

Nella visualizzazione Tutti i dispositivi nella colonna Registrato è ora possibile
selezionare tutti i dispositivi in sospeso disponibili e aprire un riquadro di contesto per
risolvere i problemi relativi al motivo per cui un dispositivo potrebbe essere in sospeso.
È anche possibile offrire commenti e suggerimenti su se le informazioni riepilogate sono
utili o meno. Per altre informazioni, vedere: Dispositivi in sospeso in Azure Active
Directory.
Disponibilità generale: gli amministratori possono ora

limitare agli utenti l'accesso self-service alle chiavi
BitLocker
Categoria di servizio: Gestione dell'accesso ai dispositivi
Gli amministratori possono ora limitare agli utenti l'accesso self-service alle chiavi
BitLocker tramite la pagina Impostazioni dispositivi. L'attivazione di questa funzionalità
nasconde le chiavi BitLocker di tutti gli utenti non amministratori. Ciò consente di
controllare la gestione degli accessi di BitLocker a livello di amministratore. Per altre
informazioni, vedere Limitare le autorizzazioni predefinite degli utenti membri.
Anteprima pubblica - Nuovi connettori di provisioning

nella raccolta di applicazioni di Azure AD - Maggio 2023
Categoria di servizio: Provisioning di app
Funzionalità del prodotto: Integrazione con app di terze parti
Sono state aggiunte le nuove applicazioni seguenti nella raccolta app con il supporto
per il provisioning. È ora possibile automatizzare la creazione, l'aggiornamento e
l'eliminazione degli account utente per queste nuove app integrate:
Effettuare l'accesso al provisioning host enterprise
Per altre informazioni su come proteggere meglio l'organizzazione usando il

provisioning degli account utente automatizzato, vedere Automatizzare il provisioning
utenti alle applicazioni SaaS con Azure AD.
Disponibilità generale - Gestione delle autorizzazioni di

Microsoft Entra Azure Active Directory Insights
Categoria di servizio: Altro
Funzionalità del prodotto: Gestione autorizzazioni
La scheda Azure Active Directory Insights in Gestione delle autorizzazioni di Microsoft

Entra offre una visualizzazione di tutte le assegnazioni di ruolo permanenti assegnate
agli amministratori globali e un elenco curato di ruoli con privilegi elevati. Gli
amministratori possono quindi usare il report per eseguire ulteriori azioni all'interno
della console di Azure Active Directory. Per altre informazioni, vedere Visualizzare le
assegnazioni di ruolo con privilegi nell'organizzazione (anteprima).
Anteprima pubblica - Guida al portale per configurare

l'autenticazione a più fattori
Categoria di servizio: MFA
Funzionalità del prodotto: Protezione della sicurezza & delle identità
La guida al portale per configurare l'autenticazione a più fattori consente di iniziare a

usare le funzionalità MFA di Azure Active Directory. Questa guida è disponibile nella
scheda Esercitazioni nella panoramica di Azure AD. Per altre informazioni, vedere
Configurare l'autenticazione a più fattori usando la guida al portale.
Disponibilità generale - Authenticator Lite (in Outlook)

Categoria di servizio: Microsoft Authenticator App
Authenticator Lite (in Outlook) è una soluzione di autenticazione per gli utenti che non
hanno ancora scaricato l'app Microsoft Authenticator. Gli utenti vengono richiesti in
Outlook sul dispositivo mobile per registrare per l'autenticazione a più fattori. Dopo aver
immesso la password all'accesso, sarà possibile inviare una notifica push al dispositivo
Android o iOS.
A causa del miglioramento della sicurezza questa funzionalità fornisce agli utenti, il
valore gestito microsoft di questa funzionalità verrà modificato da "disabilitato" a
"abilitato" il 9 giugno. Sono state apportate alcune modifiche alla configurazione della
funzionalità, quindi se è stato effettuato un aggiornamento prima della disponibilità
generale, il 17 maggio, verificare che la funzionalità sia nello stato corretto per il tenant
prima del 9 giugno. Se non si desidera abilitare questa funzionalità il 9 giugno, spostare
lo stato su "disabilitato" o impostare gli utenti per includere ed escludere i gruppi.
Per altre informazioni, vedere: Come abilitare Microsoft Authenticator Lite per Outlook
mobile (anteprima).
Disponibilità generale - Supporto del connettore

PowerShell e Servizi Web tramite l'agente di provisioning
di Azure AD
Funzionalità del prodotto: In uscita alle applicazioni locali
La funzionalità di provisioning delle applicazioni locali di Azure AD supporta ora sia i

connettori di PowerShell che dei servizi Web . è ora possibile effettuare il provisioning
degli utenti in un file flat usando il connettore PowerShell o un'app come SAP ECC
usando il connettore servizi Web. Per altre informazioni, vedere: Effettuare il
provisioning degli utenti nelle applicazioni usando PowerShell.
Disponibilità generale - Rilevamento dell'accesso IP

dell'attore delle minacce verificato
Categoria di servizio: Identity Protection
Identity Protection ha aggiunto un nuovo rilevamento, usando il database di Microsoft

Threat Intelligence, per rilevare l'accesso eseguito dagli indirizzi IP degli attori noti dello
stato nazionale e del crimine informatico e consentire ai clienti di bloccare questi accessi
usando i criteri di accesso condizionale basati sui rischi. Per altre informazioni, vedere:
Rischio di accesso.
Disponibilità generale - Controllo granulare dell'accesso

condizionale per i tipi di utente esterni
Quando si configura un criterio di accesso condizionale, i clienti ora dispongono di un

controllo granulare sui tipi di utenti esterni a cui vogliono applicare i criteri. Gli utenti
esterni vengono classificati in base alla modalità di autenticazione (interna o esterna) e
alla relazione con l'organizzazione (guest o membro). Per altre informazioni, vedere:
Assegnazione di criteri di accesso condizionale ai tipi di utente esterni.
Disponibilità generale - Nuove app federate disponibili

nella raccolta di applicazioni di Azure AD - Maggio 2023
Categoria di servizio: App aziendali
Nel maggio 2023 sono state aggiunte le seguenti 51 nuove applicazioni nella raccolta
app con supporto della federazione
INEXTRACK , Valotalive Digital Signage Microsoft 365 integration , Tailscale ,

MANTL , ServusConnect, Jigx MS Graph Demonstrator , Delivery Solutions, Radiant
IOT Portal, Cosgrid Networks, voya SSO , Redocly, Glaass Pro , TalentLyftOIDC ,
Cisco Expressway, IBM TRIRIGA on Cloud, Avionte Bold SAML Federated SSO,
InspectNTrack , CAREERSHIP , Cisco Unity Connection, HSC-Buddy , teamecho ,
Uni-tel A/S , AskFora , Enterprise Bot,CMD +CTRL Base Camp, Debitia Collections ,
EnergyManager , Visual Workforce , Uplifter , AI2 , TES Cloud,VEDA Cloud , SOC
SST, Alchemer, Cleanmail Swiss, WOX ,DATA Assistente qualità , Softdrive ,
Fluence Portal , Humbol , Document360, Engagement by Local
Measure,Gate Property Management Software , Locus, Banyan Infrastructure ,
Proactis Rego Invoice Capture, SecureTransport, Recnice
È anche possibile trovare la documentazione di tutte le applicazioni da qui

https://aka.ms/AppsTutorial ,
Per elencare l'applicazione nella raccolta di app di Azure AD, leggere i dettagli qui
https://aka.ms/AzureADAppRequest
Disponibilità generale - Le informazioni sulla sicurezza

ora mostrano il tipo Microsoft Authenticator
Sono stati migliorati gli accessi personali e my Security-Info per offrire maggiore
chiarezza sui tipi di altre app Authenticator di Microsoft Authenticator che un utente ha
registrato. Gli utenti vedranno ora le registrazioni di Microsoft Authenticator con
informazioni aggiuntive che mostrano l'app come registrata come MFA basata su push o
accesso al telefono senza password (PSI) e per altre app Authenticator (Software OATH)
che ora indicano che sono registrate come metodo password one-time basato su
tempo. Per altre informazioni, vedere: Configurare l'app Microsoft Authenticator come
metodo di verifica .
Disponibilità generale - Autenticazione del provider di

identità basata su SAML/Ws Fed per gli utenti B2B di
Azure Active Directory in Cloud Nat sec e STATI Uniti
I provider di identità basati su SAML/Ws Fed per l'autenticazione in Azure AD B2B sono
disponibili a livello generale nei cloud US Sec, US Nat e Cina. Per altre informazioni,
vedere Federazione con provider di identità SAML/WS-Fed per gli utenti guest.
Aprile 2023
Anteprima pubblica - Attributi personalizzati per Azure

Active Directory Domain Services
Categoria di servizio: Active Directory Domain Services di Azure
Funzionalità del prodotto: Active Directory Domain Services di Azure
Azure Active Directory Domain Services supporta ora la sincronizzazione degli attributi
personalizzati da Azure AD per gli account locali. Per altre informazioni, vedere: Attributi
personalizzati per Azure Active Directory Domain Services.
Disponibilità generale: abilitazione della registrazione

combinata delle informazioni di sicurezza per MFA e
reimpostazione della password self-service (SSPR)
L'anno scorso abbiamo annunciato l'esperienza utente di registrazione combinata per

MFA e la reimpostazione della password self-service (SSPR) è stata implementata come
esperienza predefinita per tutte le organizzazioni. Siamo lieti di annunciare che
l'esperienza di registrazione delle informazioni di sicurezza combinata è ora
completamente implementata. Questa modifica non influisce sui tenant che si trovano
nell'area cina. Per altre informazioni, vedere: Panoramica della registrazione combinata
delle informazioni di sicurezza per Azure Active Directory.
Disponibilità generale - Metodo MFA preferito dal

sistema
Attualmente, le organizzazioni e gli utenti si basano su un'ampia gamma di metodi di

autenticazione, ognuno dei quali offre diversi gradi di sicurezza. Sebbene
l'autenticazione a più fattori sia fondamentale, alcuni metodi MFA sono più sicuri di altri.
Nonostante l'accesso alle opzioni MFA più sicure, gli utenti scelgono spesso metodi
meno sicuri per vari motivi.
Per risolvere questa sfida, stiamo introducendo un nuovo metodo di autenticazione

preferito dal sistema per MFA. Quando gli utenti accedono, il sistema determina e
visualizza il metodo MFA più sicuro registrato dall'utente. In questo modo gli utenti
devono passare dal metodo predefinito all'opzione più sicura. Anche se gli utenti
possono comunque scegliere un metodo MFA diverso, verrà sempre richiesto di usare il
metodo più sicuro per ogni sessione che richiede MFA. Per altre informazioni, vedere:
Autenticazione a più fattori preferita dal sistema - Criteri dei metodi di autenticazione.
Disponibilità generale - Avviso PIM: avviso sulle

assegnazioni di ruolo attivo-permanente in Azure o
assegnazioni effettuate all'esterno di PIM
Tipo: Correzione
Categoria di servizio: Privileged Identity Management
Funzionalità del prodotto: Privileged Identity Management
Avviso sulle assegnazioni di ruolo della sottoscrizione di Azure effettuate all'esterno di

Privileged Identity Management (PIM) fornisce un avviso in PIM per le assegnazioni di
sottoscrizione di Azure effettuate all'esterno di PIM. Un proprietario o un amministratore
di Accesso utente può eseguire un'azione di correzione rapida per rimuovere tali
assegnazioni.
Anteprima pubblica - Creazione avanzata dell'utente e
invito alle esperienze utente
Categoria di servizio: Gestione utenti
Gli amministratori possono ora definire più proprietà durante la creazione e l'invito di un
utente nel portale di amministrazione di Entra. Questi miglioramenti portano
l'esperienza utente alla parità con le API utente create. Inoltre, gli amministratori
possono ora aggiungere utenti a un gruppo o a un'unità amministrativa e assegnare
ruoli. Per altre informazioni, vedere : Aggiungere o eliminare utenti con Azure Active
Directory.
Anteprima pubblica - Azioni protette per l'accesso

condizionale di Azure AD
Categoria di servizio: RBAC
Funzionalità del prodotto: Controllo di accesso
L'anteprima pubblica delle azioni protette introduce la possibilità di applicare l'accesso

condizionale per selezionare le autorizzazioni. Quando un utente esegue un'azione
protetta, deve soddisfare i requisiti dei criteri di accesso condizionale. Per altre
informazioni, vedere: Quali sono le azioni protette in Azure AD? (anteprima).
Anteprima pubblica - Protezione token per le sessioni di

accesso
Token Protection per le sessioni di accesso è la prima versione in una mappa stradale
per combattere gli attacchi che coinvolgono il furto di token e la riproduzione. Fornisce
l'imposizione dell'accesso condizionale di verifica del token per i client e i servizi
supportati che garantiscono l'accesso alle risorse specificate solo da un dispositivo a cui
l'utente ha eseguito l'accesso. Per altre informazioni, vedere: Accesso condizionale:
Protezione token (anteprima).
Disponibilità generale- Nuovi limiti relativi al numero e
alle dimensioni dei segreti del gruppo a partire da giugno
2023
Tipo: Modifica pianificata
Funzionalità del prodotto: Directory
A partire da giugno 2023, i segreti archiviati in un singolo gruppo non possono superare
48 singoli segreti o avere una dimensione totale maggiore di 10 KB in tutti i segreti in un
singolo gruppo. I gruppi con più di 10 KB di segreti smetteranno immediatamente di
lavorare nel giugno 2023. In giugno, i gruppi che superano 48 segreti non possono
aumentare il numero di segreti che hanno, anche se possono comunque aggiornare o
eliminare tali segreti. È consigliabile ridurre meno di 48 segreti entro gennaio 2024.
I segreti del gruppo vengono in genere creati quando un gruppo viene assegnato le
credenziali a un'app usando l'accesso Single Sign-On basato su password. Per ridurre il
numero di segreti assegnati a un gruppo, è consigliabile creare gruppi aggiuntivi e
suddividere le assegnazioni di gruppo alle applicazioni SSO basate su password in
questi nuovi gruppi. Per altre informazioni, vedere: Aggiungere l'accesso Single Sign-On
basato su password a un'applicazione.
Anteprima pubblica - Authenticator Lite in Outlook

Authenticator Lite è una superficie aggiuntiva per gli utenti di Azure Active Directory per
completare l'autenticazione a più fattori usando notifiche push nel dispositivo Android o
iOS. Con Authenticator Lite, gli utenti possono soddisfare un requisito di autenticazione
a più fattori dalla praticità di un'app familiare. Authenticator Lite è attualmente abilitato
nell'app Outlook per dispositivi mobili. Gli utenti possono ricevere una notifica nell'app
outlook per dispositivi mobili per approvare o negare o usare l'app Outlook per
generare un codice di verifica OATH che può essere immesso durante l'accesso.
L'impostazione 'Microsoft managed' per questa funzionalità verrà impostata su abilitata il
26 maggio 2023. In questo modo è possibile abilitare la funzionalità per tutti gli utenti
nei tenant in cui la funzionalità è impostata su Microsoft gestita. Se si vuole modificare
lo stato di questa funzionalità, eseguire questa operazione prima del 26 maggio 2023.
Per altre informazioni, vedere: Come abilitare Microsoft Authenticator Lite per Outlook
mobile (anteprima).
Disponibilità generale - Aspetto aggiornato per MFA per
utente
Tipo: Modifica pianificata
Come parte dei miglioramenti del servizio in corso, si apportano aggiornamenti

all'esperienza di configurazione dell'amministratore MFA per utente per allinearsi
all'aspetto e all'aspetto di Azure. Questa modifica non include modifiche alla
funzionalità di base e includerà solo miglioramenti visivi. Per altre informazioni, vedere
Abilitare Azure AD Multi-Factor Authentication per utente per proteggere gli eventi di
accesso.
Disponibilità generale: verranno disattivati i log di

controllo aggiuntivi per l'uso
Tipo: Correzione
Categoria di servizio: Condizioni per l'uso
Funzionalità del prodotto: Delega di autenticazione/accesso
A causa di un problema tecnico, è stato recentemente avviato l'emissione di log di

controllo aggiuntivi per le condizioni di utilizzo. I log di controllo aggiuntivi verranno
disattivati dal primo maggio e contrassegnati con il servizio directory principale e la
categoria del contratto. Se si è creata una dipendenza dai log di controllo aggiuntivi, è
necessario passare ai log di controllo regolari contrassegnati con le condizioni per l'uso
del servizio.

nella raccolta applicazioni di Azure AD - Aprile 2023
Ad aprile 2023 sono state aggiunte le seguenti 10 nuove applicazioni nella raccolta app
con supporto federativo:
iTel Alert , goFLUENT, StructureFlow, StructureFlow AU , StructureFlow CA ,

StructureFlow EU , StructureFlow USA , Predict360 SSO, Cegid Cloud , HashiCorp
Cloud Platform (HCP),O'Reilly learning platform, LeftClick Web Services – RoomGuide ,
LeftClick Web Services – Sharepoint , LeftClick Web Services – Presenza, LeftClick
Web Services - Single Sign-On , InterPrice Technologies , WiggleDesk SSO ,
Application Experience with Mist , Connect Plans 360 , Proactis Rego Source-to-
Contract, Danomics , Fountain, Theom, DDC Web, Dozuki.

https://aka.ms/AppsTutorial .

nella raccolta applicazioni di Azure AD - Aprile 2023
Alvao
Stack migliore
BIS
Connettore
Howspace
Kno2fy
Netsparker Enterprise
uniFLOW Online

Anteprima pubblica - Nuovo selettore risorse di Azure

PIM

Con questa nuova esperienza, PIM gestisce automaticamente qualsiasi tipo di risorsa in
un tenant, quindi l'individuazione e l'attivazione non sono più necessarie. Con la nuova
selezione risorse, gli utenti possono scegliere direttamente l'ambito che vogliono gestire
dal gruppo di gestione verso le risorse stesse, rendendo più veloce e più semplice
individuare le risorse che devono amministrare. Per altre informazioni, vedere Assegnare
ruoli delle risorse di Azure in Privileged Identity Management.
Disponibilità generale - Reimpostazione password self-

service (SSPR) supporta ora gli utenti idonei pim e
l'assegnazione di ruoli di gruppo indiretti
Categoria di servizio: Reimpostazione self-service delle password
La reimpostazione della password self-service (SSPR) può ora verificare la presenza di

utenti idonei di PIM e valutare le appartenenze basate su gruppi, insieme alle
appartenenze dirette quando si verifica se un utente si trova in un ruolo di
amministratore specifico. Questa funzionalità offre criteri SSPR più accurati
convalidando se gli utenti sono nell'ambito dei criteri di amministratore SSPR predefiniti
o dei criteri utente della reimpostazione automatica.
Per altre informazioni, vedere:
Differenze dei criteri di reimpostazione dell'amministratore.

Creare un gruppo assegnabile al ruolo in Azure Active Directory
Marzo 2023

nella raccolta applicazioni di Azure AD - Marzo 2023
Acunetix 360
Accesso alle applicazioni Akamai Enterprise
Ardoq
Torii

Disponibilità generale - Federazione delle identità del

carico di lavoro per le identità gestite
Categoria di servizio: Identità gestite per le risorse di Azure
Funzionalità del prodotto: esperienza di sviluppo
La federazione delle identità del carico di lavoro consente agli sviluppatori di usare
identità gestite per i carichi di lavoro software in esecuzione ovunque e accedere alle
risorse di Azure senza bisogno di segreti. Gli scenari principali includono:
Accesso alle risorse di Azure dai pod Kubernetes in esecuzione in qualsiasi cloud o
locale
Flussi di lavoro di GitHub da distribuire in Azure, senza segreti necessari
Accesso alle risorse di Azure da altre piattaforme cloud che supportano OIDC, ad
esempio Google Cloud Platform.
Federazione delle identità del carico di lavoro.

Configurare un'identità gestita assegnata dall'utente per considerare attendibile un
provider di identità esterno (anteprima)
Usare l'identità del carico di lavoro di Azure AD con servizio Azure Kubernetes
(Servizio Azure Kubernetes)
Anteprima pubblica - Nuova esperienza dei gruppi

personali

A questo punto è disponibile un'esperienza nuova e migliorata per i gruppi
personali. https://www.myaccount.microsoft.com/groups I gruppi personali consentono
agli utenti finali di gestire facilmente i gruppi, ad esempio trovare gruppi da aggiungere,
gestire i gruppi proprietari e gestire le appartenenze ai gruppi esistenti. In base al
feedback dei clienti, il nuovo Gruppo personale supporta l'ordinamento e il filtro sugli
elenchi di gruppi e membri del gruppo, un elenco completo dei membri del gruppo in
gruppi di grandi dimensioni e una pagina di panoramica utilizzabile per le richieste di
appartenenza.
Questa esperienza sostituisce l'esperienza dei gruppi personali esistenti in
https://www.mygroups.microsoft.com maggio.
Per altre informazioni, vedere: Aggiornare le informazioni sui gruppi nel portale di App
personali .
Anteprima pubblica- Personalizzare i token con provider

di attestazioni personalizzati
Funzionalità del prodotto: Estensibilità
Un provider di attestazioni personalizzato consente di chiamare un'API e di eseguire il

mapping di attestazioni personalizzate nel token durante il flusso di autenticazione. La
chiamata API viene eseguita dopo che l'utente ha completato tutte le loro sfide di
autenticazione e un token sta per essere rilasciato all'app. Per altre informazioni, vedere:
Estensioni di autenticazione personalizzate (anteprima).
Disponibilità generale - Metodi di autenticazione

convergenti
I criteri dei metodi di autenticazione convergenti consentono di gestire tutti i metodi di

autenticazione usati per MFA e SSPR in un criterio, eseguire la migrazione dei criteri MFA
e SSPR legacy e dei metodi di autenticazione di destinazione ai gruppi di utenti anziché
abilitarli per tutti gli utenti nel tenant. Per altre informazioni, vedere Gestire i metodi di
autenticazione.
Disponibilità generale - Cartella di lavoro di Provisioning
Insights
Funzionalità del prodotto: Report di monitoraggio &
Questa nuova cartella di lavoro semplifica l'analisi e l'analisi dei flussi di lavoro di
provisioning in un determinato tenant. Ciò include il provisioning basato sulle risorse
umane, la sincronizzazione cloud, il provisioning delle app e la sincronizzazione tra
tenant.
Alcune domande chiave che questa cartella di lavoro può aiutare a rispondere sono:
Quanti identità sono state sincronizzate in un determinato intervallo di tempo?

Quante operazioni sono state eseguite, eliminare, aggiornare o altre operazioni?
Quante operazioni sono state riuscite, ignorate o non riuscite?
Quali identità specifiche non sono riuscite? E quale passaggio ha avuto esito
negativo?
Per qualsiasi utente specificato, quali tenant/applicazioni sono stati sottoposti a
provisioning o deprovisioning?
Per altre informazioni, vedere: Provisioning insights cartella di lavoro.
Disponibilità generale - Corrispondenza dei numeri per le

notifiche di Microsoft Authenticator
Digitare: Pianificare la modifica
La funzionalità di corrispondenza dei numeri dell'app Microsoft Authenticator è

disponibile a livello generale dal novembre 2022! Se non hai già usato i controlli di
implementazione (tramite portale di Azure Amministrazione API UX e MSGraph) per
distribuire senza problemi la corrispondenza dei numeri per gli utenti delle notifiche
push di Microsoft Authenticator, ti consigliamo di farlo. In precedenza è stato
annunciato che verranno rimossi i controlli di amministratore e verrà applicata
l'esperienza di corrispondenza numerica a livello di tenant per tutti gli utenti delle
notifiche push di Microsoft Authenticator a partire dal 27 febbraio 2023. Dopo aver
ascoltato i clienti, si estenderà la disponibilità dei controlli di implementazione per
alcune settimane. Le organizzazioni possono continuare a usare i controlli di
implementazione esistenti fino al 8 maggio 2023, per distribuire la corrispondenza dei
numeri nelle proprie organizzazioni. I servizi Microsoft inizieranno a applicare
l'esperienza di corrispondenza dei numeri per tutti gli utenti delle notifiche push di
Microsoft Authenticator dopo il 8 maggio 2023. Verranno inoltre rimossi i controlli di
implementazione per la corrispondenza dei numeri dopo tale data.
Se i clienti non abilitano la corrispondenza numero per tutte le notifiche push di

Microsoft Authenticator prima del 8 maggio 2023, gli utenti di Authenticator potrebbero
riscontrare accessi incoerenti mentre i servizi stanno implementando questa modifica.
Per garantire un comportamento coerente per tutti gli utenti, è consigliabile abilitare la
corrispondenza del numero per le notifiche push di Microsoft Authenticator in anticipo.
Per altre informazioni, vedere: Come usare la corrispondenza dei numeri nelle notifiche
di autenticazione a più fattori - Criteri di autenticazione
Anteprima pubblica - IPv6 in arrivo in Azure AD

Funzionalità del prodotto: Piattaforma
In precedenza, è stato annunciato il piano per portare il supporto IPv6 a Microsoft Azure
Active Directory (Azure AD), consentendo ai clienti di raggiungere i servizi di Azure AD
tramite endpoint IPv4, IPv6 o dual stack. Questo è solo un promemoria che è stato
avviato l'introduzione del supporto IPv6 nei servizi di Azure AD in un approccio in fase
di fine marzo 2023.
Se si usa l'accesso condizionale o Identity Protection e si dispone di IPv6 abilitato in uno

dei dispositivi, è probabile che sia necessario intraprendere azioni per evitare di influire
sugli utenti. Per la maggior parte dei clienti, IPv4 non scompare completamente dal
proprio panorama digitale, quindi non si prevede di richiedere IPv6 o di deprioritizzare
IPv4 in qualsiasi funzionalità o servizi di Azure AD. Continuerà a condividere indicazioni
aggiuntive sull'abilitazione IPv6 in Azure AD in questo collegamento: supporto IPv6 in
Azure Active Directory.
Disponibilità generale - Impostazioni cloud Microsoft per

Azure AD B2B

Le impostazioni cloud Microsoft consentono di collaborare con le organizzazioni da
cloud di Microsoft Azure diversi. Con le impostazioni cloud Microsoft, è possibile
stabilire la collaborazione B2B reciproca tra i cloud seguenti:
Microsoft Azure commerciale e Microsoft Azure per enti pubblici

Microsoft Azure commerciale e Microsoft Azure China 21Vianet
Per altre informazioni sulle impostazioni del cloud Microsoft per la collaborazione B2B,
vedere Impostazioni cloud Microsoft.
Modernizzazione delle esperienze d'uso

Categoria di servizio: Condizioni per l'uso
A partire da luglio 2023, vengono modernezzate le seguenti condizioni per l'uso degli
utenti finali con un visualizzatore PDF aggiornato e lo spostamento delle esperienze da
https://account.activedirectory.windowsazure.com a
https://myaccount.microsoft.com :
Visualizzare le condizioni per l'utilizzo accettate in precedenza.

Accettare o rifiutare le condizioni per l'utilizzo come parte del flusso di accesso.
Nessuna funzionalità verrà rimossa. Il nuovo visualizzatore PDF aggiunge funzionalità e

le modifiche visive limitate nelle esperienze dell'utente finale verranno comunicate in un
aggiornamento futuro. Se l'organizzazione ha consentito solo determinati domini, è
necessario assicurarsi che l'elenco elementi consentiti includa i domini
"myaccount.microsoft.com" e "*.myaccount.microsoft.com" per le Condizioni per
l'utilizzo per continuare a funzionare come previsto.
Febbraio 2023
Disponibilità generale: espansione dell'attivazione dei

ruoli Privileged Identity Management nell'portale di
Azure

l'attivazione del ruolo Privileged Identity Management (PIM) è stata estesa alle
estensioni Fatturazione e ACTIVE Directory nel portale di Azure. I collegamenti sono stati
aggiunti a Sottoscrizioni (fatturazione) e Controllo di accesso (AD) per consentire agli
utenti di attivare i ruoli PIM direttamente da questi pannelli. Nel pannello Sottoscrizioni
selezionare Visualizza sottoscrizioni idonee nel menu dei comandi orizzontale per
controllare le assegnazioni idonee, attive e scadute. Da qui è possibile attivare
un'assegnazione idonea nello stesso riquadro. In Controllo di accesso (IAM) per una
risorsa è ora possibile selezionare Visualizza l'accesso per visualizzare le assegnazioni di
ruolo attualmente attive e idonee e attivarsi direttamente. Grazie all'integrazione di
funzionalità PIM in diversi pannelli di portale di Azure, questa nuova funzionalità
consente agli utenti di ottenere l'accesso temporaneo per visualizzare o modificare più
facilmente sottoscrizioni e risorse.
Per altre informazioni sulle impostazioni del cloud Microsoft, vedere Attivare i ruoli delle
risorse di Azure in Privileged Identity Management.
Disponibilità generale : seguire le procedure consigliate

di Azure AD con le raccomandazioni
Categoria di servizio: Creazione di report
Funzionalità del prodotto: Monitoraggio & dei report
Le raccomandazioni di Azure AD consentono di migliorare il comportamento del tenant

visualizzando le opportunità di implementare le procedure consigliate. Su base
giornaliera, Azure AD analizza la configurazione del tenant. Durante questa analisi, Azure
AD confronta i dati di una raccomandazione con la configurazione effettiva del tenant.
Se una raccomandazione viene contrassegnata come applicabile al tenant, la
raccomandazione viene visualizzata nella sezione Raccomandazioni di Panoramica di
Azure AD.
Questa versione include le prime 3 raccomandazioni:
Eseguire la conversione dall'autenticazione a più fattori per utente

all'autenticazione a più fattori di accesso condizionale
Migrazione di applicazioni da AD FS ad Azure AD
Ridurre al minimo le richieste di autenticazione a più fattori dai dispositivi noti
Che cosa sono le raccomandazioni di Azure Active Directory?

Usare l'API raccomandazioni di Azure AD per implementare le procedure
consigliate di Azure AD per il tenant
Anteprima pubblica - Integrazione di Azure AD PIM +

Accesso condizionale
È ora possibile richiedere agli utenti idonei per un ruolo di soddisfare i requisiti dei
criteri di accesso condizionale per l'attivazione: usare un metodo di autenticazione
specifico applicato tramite i punti di forza dell'autenticazione, attivare da Intune
dispositivo conforme, rispettare le condizioni per l'utilizzo e usare l'autenticazione a più
fattori di terze parti e soddisfare i requisiti di posizione.
Per altre informazioni, vedere Configurare le impostazioni del ruolo di Azure AD in

Privileged Identity Management.
Disponibilità generale: altre informazioni sul motivo per

cui un accesso è stato contrassegnato come "non
familiare"
Il rilevamento dei rischi delle proprietà di accesso non familiari fornisce ora motivi di
rischio per cui le proprietà non sono note per i clienti per analizzare meglio tale rischio.
Identity Protection presenta ora le proprietà non note nel portale di Azure
nell'esperienza utente e nell'API come Informazioni aggiuntive con una descrizione
intuitiva che spiega che le proprietà seguenti non sono note per questo accesso dell'utente
specificato.
Non sono disponibili ulteriori operazioni per abilitare questa funzionalità, le proprietà
sconosciute vengono visualizzate per impostazione predefinita. Per altre informazioni,
vedere: Rischio di accesso.
nella raccolta di applicazioni di Azure AD - Febbraio 2023
A febbraio 2023 sono state aggiunte le 10 nuove applicazioni seguenti nella raccolta di
app con il supporto per la federazione:
PROCAS , Tanium Cloud SSO, LeanDNA, CalendarAnything LWC , courses.work,

Udemy Business SAML, Canva, Kno2fy, IT-Conductor, ナレッジワーク(Knowledge Work),
Valotalive Digital Signage Microsoft 365 integration , Priority Matrix HIPAA , Priority
Matrix Government , Beable, Grain , DojoNavi, Global Validity Access Manager ,
FieldEquip , Peoplevine , Respondent, WebTMA, ClearIP , Pennylane, VsimpleSSO ,
Compliance Genie, Dataminr Corporate , Talon.


nella raccolta di applicazioni di Azure AD - Febbraio 2023
Sono state aggiunte le nuove applicazioni seguenti nella raccolta di app con il supporto
l'eliminazione di account utente per le app appena integrate:
Atmos

provisioning automatico degli account utente, vedere Automatizzare il provisioning
utenti in applicazioni SaaS con Azure AD.
Gennaio 2023
Anteprima pubblica - Sincronizzazione tra tenant
Funzionalità del prodotto: Collaborazione
La sincronizzazione tra tenant consente di configurare una soluzione scalabile e

automatizzata per consentire agli utenti di accedere alle applicazioni tra tenant
dell'organizzazione. Si basa sulla funzionalità B2B di Azure AD e automatizza la
creazione, l'aggiornamento e l'eliminazione di utenti B2B. Per altre informazioni, vedere:
Che cos'è la sincronizzazione tra tenant? (anteprima).
Disponibilità generale - App complementare Apple Watch

rimossa da Authenticator per iOS
Tipo: Deprecato
Nella versione di gennaio 2023 di Authenticator per iOS non è disponibile alcuna app
complementare per watchOS perché non è compatibile con le funzionalità di sicurezza
authenticator, ovvero non è possibile installare o usare Authenticator in Apple Watch.
Questa modifica influisce solo su Apple Watch, quindi puoi comunque usare
Authenticator negli altri dispositivi. Per altre informazioni, vedere: Domande comuni
sull'app Microsoft Authenticator .

nella raccolta di applicazioni di Azure AD - Gennaio 2023
A gennaio 2023 sono state aggiunte le 10 nuove applicazioni seguenti nella raccolta di
app con il supporto della federazione:
MINT TMS, Exterro Legal GRC Software Platform, SIX. ONE Identity Access Manager ,
Lusha, Descartes, Travel Management System , Pinpoint (SAML),my.sdworx.com, itopia
Labs , Better Stack .


nella raccolta di applicazioni di Azure AD - Gennaio 2023
Sono state aggiunte le nuove applicazioni seguenti nella raccolta di app con il supporto
l'eliminazione di account utente per le app appena integrate:
SurveyMonkey Enterprise

provisioning automatico degli account utente, vedere Automatizzare il provisioning
utenti in applicazioni SaaS con Azure AD.
Anteprima pubblica - Nuova esperienza utente per la

sincronizzazione cloud di Azure AD
Categoria di servizio: Sincronizzazione cloud di Azure AD Connect
Funzionalità del prodotto: Identity Governance
Provare la nuova esperienza guidata per la sincronizzazione di oggetti da AD ad Azure

AD usando Azure AD Cloud Sync in portale di Azure. Con questa nuova esperienza, gli
amministratori di identità ibrida possono determinare facilmente quale motore di
sincronizzazione usare per i propri scenari e ottenere altre informazioni sulle varie
opzioni disponibili con le soluzioni di sincronizzazione. Con un'ampia gamma di
esercitazioni e video, i clienti sono in grado di acquisire informazioni sulla
sincronizzazione cloud di Azure AD in un'unica posizione.
Questa esperienza consente agli amministratori di seguire i diversi passaggi coinvolti

nella configurazione di una configurazione di sincronizzazione cloud e di un'esperienza
intuitiva per semplificare la gestione. Gli amministratori possono anche ottenere
informazioni dettagliate sulla configurazione di sincronizzazione usando l'opzione
"Insights", che si integra con Monitoraggio di Azure e cartelle di lavoro.

Creare una nuova configurazione per la sincronizzazione cloud di Azure AD
Connect
Mapping degli attributi nella sincronizzazione cloud di Azure AD Connect
Cartella di lavoro di Azure AD cloud sync insights
Anteprima pubblica - Supporto per le estensioni directory

con sincronizzazione cloud di Azure AD
Funzionalità del prodotto: Sincronizzazione cloud di Azure AD Connect
Gli amministratori IT ibridi ora possono sincronizzare le estensioni di Active Directory e

Azure AD Directory usando Azure AD Cloud Sync. Questa nuova funzionalità aggiunge
la possibilità di individuare dinamicamente lo schema per Active Directory e Azure AD,
consentendo ai clienti di eseguire il mapping degli attributi necessari usando
l'esperienza di mapping degli attributi di Cloud Sync.
Per altre informazioni su come abilitare questa funzionalità, vedere: Estensioni della
directory di Sincronizzazione cloud e mapping degli attributi personalizzati
Dicembre 2022
Anteprima pubblica : Windows 10+ Strumento di

risoluzione dei problemi per i log di diagnostica
Categoria di servizio: Revisione
Funzionalità del prodotto: Report di monitoraggio &
Questa funzionalità analizza i log lato client caricati, noti anche come log di diagnostica,
da un dispositivo Windows 10+ che ha un problema e suggerisce i passaggi di
correzione per risolvere i problemi. Gli amministratori possono usare l'utente finale per
raccogliere i log lato client e quindi caricarli in questo strumento di risoluzione dei
problemi nel portale entra. Per altre informazioni, vedere: Risoluzione dei problemi dei
dispositivi Windows in Azure AD.
Disponibilità generale : più accessi telefonici senza

password per i dispositivi iOS
Gli utenti finali possono ora abilitare l'accesso telefonico senza password per più
account nell'app Authenticator in qualsiasi dispositivo iOS supportato. I consulenti, gli
studenti e gli altri con più account in Azure AD possono aggiungere ogni account a
Microsoft Authenticator e usare l'accesso telefonico senza password per tutti dallo
stesso dispositivo iOS. Gli account Azure AD possono trovarsi nello stesso tenant o in
tenant diversi. Gli account guest non sono supportati per più accessi account da un
dispositivo.
Gli utenti finali non sono necessari per abilitare l'impostazione di telemetria facoltativa
nell'app Authenticator. Per altre informazioni, vedere Abilitare l'accesso senza password
con Microsoft Authenticator.
Anteprima pubblica(aggiornamento) - Aggiornamenti ai

modelli di accesso condizionale
I modelli di accesso condizionale forniscono un metodo pratico per distribuire nuovi

criteri allineati alle raccomandazioni Microsoft. In totale sono presenti 14 modelli di
criteri di accesso condizionale filtrati da cinque scenari diversi; base sicura, zero trust,
lavoro remoto, proteggere gli amministratori e le minacce emergenti.
In questo aggiornamento di anteprima pubblica è stata migliorata l'esperienza utente

con una progettazione aggiornata e sono stati aggiunti quattro nuovi miglioramenti:
Gli amministratori possono creare criteri di accesso condizionale importando un

file JSON.
Gli amministratori possono duplicare i criteri esistenti.
Gli amministratori possono visualizzare informazioni più dettagliate sui criteri.
Gli amministratori possono eseguire query sui modelli a livello di codice tramite
l'API MSGraph.
Per altre informazioni, vedere: Modelli di accesso condizionale (anteprima).
Anteprima pubblica: gli amministratori possono limitare

gli utenti alla creazione di tenant
Categoria di servizio: Gestione degli accessi utente
La possibilità per gli utenti di creare tenant dalla panoramica di Gestisci tenant è stata
presente in Azure AD dall'inizio quasi dell'portale di Azure. Questa nuova funzionalità
nell'opzione Impostazioni utente consente agli amministratori di limitare gli utenti alla
creazione di nuovi tenant. Esiste anche un nuovo ruolo creatore tenant per consentire
agli utenti specifici di creare tenant. Per altre informazioni, vedere Autorizzazioni utente
predefinite.
Disponibilità generale - Impostazioni di avvio delle app

consolidate (App personali) e nuove impostazioni di
anteprima
Categoria di servizio: App personali
Sono state consolidate le impostazioni di avvio delle app pertinenti in una nuova
sezione Launcher app nei portali di Azure e Entra. Il punto di ingresso è disponibile in
Applicazioni aziendali, in cui raccolte usate per essere. È possibile trovare l'opzione
Raccolte selezionando Avvia app. Inoltre, è stata aggiunta una nuova opzione
Impostazioni di avvio app. Questa opzione include alcune impostazioni che potrebbero
essere già familiari con le impostazioni di Microsoft 365. Le nuove opzioni Impostazioni
dispongono anche di controlli per le anteprime. Come amministratore, è possibile
scegliere di provare nuove funzionalità di avvio delle app mentre sono in anteprima.
L'abilitazione di una funzionalità di anteprima significa che la funzionalità viene attivata
per l'organizzazione. Questa funzionalità abilitata riflette nel portale di App personali e
altri avviatori di app per tutti gli utenti. Per altre informazioni sulle impostazioni di
anteprima, vedere: Esperienze utente finali per le applicazioni.
Anteprima pubblica - Criteri di autenticazione

convergenti
I criteri dei metodi di autenticazione convergenti consentono di gestire tutti i metodi di

autenticazione usati per MFA e SSPR in un criterio. È possibile eseguire la migrazione dei
criteri MFA e SSPR legacy e dei metodi di autenticazione di destinazione ai gruppi di
utenti anziché abilitarli per tutti gli utenti nel tenant. Per altre informazioni, vedere
Gestire i metodi di autenticazione per Azure AD.
Disponibilità generale - Supporto dell'unità

amministrativa per i dispositivi
Categoria di servizio: Gestione directory
È ora possibile usare le unità amministrative per delegare la gestione dei dispositivi
specificati nel tenant aggiungendo dispositivi a un'unità amministrativa. È anche
possibile assegnare ruoli predefiniti e personalizzati di gestione dei dispositivi, con
ambito a tale unità amministrativa. Per altre informazioni, vedere Gestione dei
dispositivi.
Anteprima pubblica: i lavoratori front-line che usano

dispositivi condivisi possono ora usare app Microsoft
Edge e Yammer in Android
Categoria di servizio: N/D
Funzionalità del prodotto: SSO
Le aziende spesso forniscono dispositivi mobili ai lavoratori frontline che devono essere
condivisi tra i turni. La modalità dispositivo condivisa di Microsoft consente ai lavoratori
front-line di eseguire facilmente l'autenticazione eseguendo automaticamente l'accesso
e l'accesso automatico di tutte le app che hanno abilitato questa funzionalità. Oltre a
Microsoft Teams e Schermata iniziale gestita disponibile a livello generale, siamo lieti di
annunciare che le app Microsoft Edge e Yammer in Android sono ora disponibili in
Anteprima pubblica.
Per altre informazioni sulla distribuzione di soluzioni frontline, vedere la

documentazione sulla distribuzione front-line .
Per altre informazioni sulla modalità dispositivo condiviso, vedere la documentazione

relativa alla modalità dispositivo condiviso di Azure Active Directory.
Per i passaggi per configurare la modalità dispositivo condivisa con Intune, vedere:
Intune blog di configurazione .
nella Raccolta applicazioni di Azure AD - Dicembre 2022
GHAE

Disponibilità generale - Provisioning di applicazioni locali

Funzionalità del prodotto: In uscita alle applicazioni locali
Azure AD supporta il provisioning degli utenti nelle applicazioni ospitate in locale o in

una macchina virtuale, senza dover aprire alcun firewall. Se l'applicazione supporta SCIM
o è stato creato un gateway SCIM per connettersi all'applicazione legacy, è possibile
usare l'agente di provisioning di Azure AD per connettersi direttamente all'applicazione
e automatizzare il provisioning e il deprovisioning. Se si dispone di applicazioni legacy
che non supportano SCIM e si basano su un archivio utenti LDAP o su un database SQL ,
Azure AD può supportare anche tali applicazioni.

nella raccolta applicazioni di Azure AD - Dicembre 2022
Nel dicembre 2022 sono state aggiunte le seguenti 44 nuove applicazioni nella raccolta
app con supporto federativo:
Bionexo IDM , SMART Meeting Pro , Piano di controllo Venafi – Datacenter, HighQ,
Drawboard PDF , ETU Skillsims, TencentCloud IDaaS, TeamHeadquarters Email Agent
OAuth , Verizon MDM, QRadar SOAR, Tripwire Enterprise, Cisco Unified
Communications Manager, Howspace , Flipsnack SAML, Albert , Altinget.no , Coveo
Hosted Services, Cybozu(cybozu.com), BombBomb , VMware Identity Service,
HexaSync , Trifecta Teams , VerosoftDesign , Mazepay , Wistia, Begin.AI , WebCE,
Dream Broker Studio , PKSHA Chatbot, PGM-BCP , ChartDesk SSO, Elsevier SP,
GreenCommerce IdentityServer , Fullview , Aqua Platform , SpedTrack, Pinpoint ,
Componente aggiuntivo di Darzin Outlook , Componenti aggiuntivi di Outlook per gli
stakeholder, tesma, Parkable, Unite Us

https://aka.ms/AppsTutorial ,
Annuncio di fine supporto adAL

Digitare: N/A
Categoria di servizio: Altro
Funzionalità del prodotto: esperienza di sviluppo
Nell'ambito dell'iniziativa in corso per migliorare l'esperienza per sviluppatori,

l'affidabilità del servizio e la sicurezza delle applicazioni dei clienti, verrà terminato il
supporto per Azure Active Directory Authentication Library (ADAL). La scadenza finale
per la migrazione delle applicazioni a Azure Active Directory Authentication Library
(MSAL) è stata estesa al 30 giugno 2023.
Perché lo facciamo?
Man mano che si consolida e si evolve microsoft Identity Platform, si investe anche in
miglioramenti significativi all'esperienza e al servizio per sviluppatori che consentono di
creare applicazioni sicure, affidabili e resilienti. Per rendere disponibili queste
funzionalità ai clienti, è necessario aggiornare l'architettura dei kit di sviluppo software.
A seguito di questa modifica, è stato deciso che il percorso in avanti richiede il tramonto
di Azure Active Directory Authentication Library. Ciò consente di concentrarsi sugli
investimenti nell'esperienza di sviluppo con Azure Active Directory Authentication
Library.
Che cosa succede?

Si riconosce che la modifica delle librerie non è un'attività semplice e non può essere
eseguita rapidamente. Ci si impegna a aiutare i clienti a pianificare le migrazioni a
Microsoft Authentication Library ed eseguirle con interruzioni minime.
Nel giugno 2020, abbiamo annunciato la fine di 2 anni della sequenza temporale
di supporto per ADAL .
Nel dicembre 2022 è stato deciso di estendere la fine del supporto di Azure Active
Directory Authentication Library a giugno 2023.
Attraverso i sei mesi successivi (gennaio 2023 – giugno 2023) continuiamo a
informare i clienti sulla prossima fine del supporto e fornire indicazioni sulla
migrazione.
Il 2023 di giugno 2023 si creerà ufficialmente azure Active Directory Authentication
Library, rimuovendo la documentazione della libreria e archiviando tutti i
repository GitHub correlati al progetto.
Come scoprire quali applicazioni nel tenant usano Azure

Active Directory Authentication Library?
Per informazioni dettagliate sull'identificazione delle app di Azure Active Directory
Authentication Library, vedere il post di Microsoft Q&A per informazioni dettagliate
sull'identificazione delle app di Azure Active Directory Authentication Library con l'aiuto
di Cartelle di lavoro di Azure.
Se si usa Azure Active Directory Authentication Library,

cosa è possibile aspettarsi dopo la scadenza?
Non saranno presenti nuove versioni (sicurezza o altrimenti) nella libreria dopo
giugno 2023.
Non verranno accettati report imprevisti o richieste di supporto per Azure Active
Directory Authentication Library. La libreria di autenticazione di Azure Active
Directory al supporto della migrazione di Microsoft Authentication Library
continua.
I servizi di base continuano a funzionare e le applicazioni che dipendono dalla
libreria di autenticazione di Azure Active Directory devono continuare a funzionare.
Le applicazioni e le risorse a cui accedono, sono a rischio maggiore di sicurezza e
affidabilità a causa di non avere gli aggiornamenti più recenti, la configurazione
del servizio e i miglioramenti resi disponibili tramite la piattaforma Microsoft
Identity.
Quali funzionalità è possibile accedere solo con Microsoft
Authentication Library?
Il numero di funzionalità e funzionalità aggiunte alle librerie di Microsoft Authentication
Library è in crescita settimanale. Eccone alcuni:
Supporto per gli account Microsoft (MSA)

Supporto per gli account Azure AD B2C
Gestione delle limitazioni
Aggiornamento e revoca dei token proattivi in base a criteri o eventi critici per
Microsoft Graph e altre API che supportano la valutazione dell'accesso continuo
(CAE)
Supporto di Auth Broker con i criteri di accesso condizionale basati su dispositivo
Autenticazione del certificato basata su hardware (CBA) di Azure AD in dispositivi
mobili
Browser di sistema nei dispositivi mobili E altro ancora. Per un elenco aggiornato,
vedere la guida alla migrazione.
Come eseguire la migrazione?

Per semplificare il processo di migrazione, è stata pubblicata una guida completa che
documenta i percorsi di migrazione tra piattaforme e linguaggi di programmazione
diversi.
Oltre all'aggiornamento della libreria di autenticazione di Azure Active Directory

all'aggiornamento di Microsoft Authentication Library, è consigliabile eseguire la
migrazione da Azure AD API Graph a Microsoft Graph. Questa modifica consente di
sfruttare le aggiunte e i miglioramenti più recenti, ad esempio CAE, nell'offerta del
servizio Microsoft tramite un singolo endpoint unificato. Per altre informazioni, vedere la
guida Migrazione delle app da Azure AD Graph a Microsoft Graph . È possibile inviare
domande a Microsoft Q&A o Stack Overflow .

Azure Active Directory Conditional Access

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Azure Active Directory Conditional Access

Caricato da

Copyright:

Formati disponibili

Condividi la tua opinione sull'esperienza di download del PDF.

Informazioni sull'accesso condizionale

Informazioni sull'accesso condizionale

Che cosa si intende per condizioni?

Come si definiscono le posizioni?

Che cosa si intende per controlli?

Dipendenze del servizio di accesso condizionale

Distribuire l'accesso condizionale

Pianificare una distribuzione dell'accesso condizionale

Bloccare l'autenticazione legacy

Risoluzione dei problemi relativi allo strumento What If

Criteri comuni di accesso condizionale

Criteri comuni di accesso condizionale

Richiedere l'autenticazione a più fattori per gli amministratori

Richiedere l'autenticazione a più fattori per la gestione di Azure

Bloccare l'autenticazione legacy

Accesso condizionale basato sul rischio (richiede Azure AD Premium P2)

Richiedere una località attendibile per la registrazione dell'autenticazione a più fattori

Bloccare l'accesso in base alla località

Richiedere un dispositivo conforme

Il perimetro di sicurezza moderno si estende ora oltre la rete di un'organizzazione per

L'accesso condizionale riunisce i segnali per prendere decisioni e imporre i criteri

Gli amministratori devono perseguire due obiettivi principali:

Fare in modo che gli utenti siano produttivi sempre e ovunque

I criteri di accesso condizionale vengono applicati dopo il completamento del

Appartenenza di utenti o gruppi

Criteri comunemente applicati

Le impostazioni predefinite per la sicurezza consentono di proteggere da attacchi

In questa guida introduttiva si configureranno criteri di accesso condizionale in Azure

Un account Azure con una sottoscrizione attiva. Creare un account

Accesso senza condizioni per l'utilizzo

1. Accedere al portale di Azure come utente di test.

Creare le condizioni per l'utilizzo

2. Digitare My terms of use (Condizioni per l'utilizzo personali) e quindi salvare il

3. Accedere al portale di Azure come amministratore dell'accesso condizionale,

4. Passare aCondizioni per l'accesso>condizionaleperla sicurezza> di Azure Active

5. Nel menu in alto selezionare Nuovi termini.

7. Caricare il file PDF delle condizioni per l'utilizzo.

8. Selezionare la lingua predefinita.

12. Selezionare Crea.

Creare criteri di accesso condizionale

Lo scenario di questa guida introduttiva usa:

Per configurare i criteri di accesso condizionale:

Testare i criteri di accesso condizionale

Se non si conosce la procedura per eliminare un utente di Azure AD, vedere

Per eliminare le condizioni per l'utilizzo, selezionarlo e quindi selezionare Elimina

L'autenticazione a più fattori (MFA) è un processo in cui un utente richiede ulteriori

Azure AD Multi-Factor Authentication e i criteri di accesso condizionale offrono la

Questa esercitazione illustra come un amministratore può abilitare Azure AD Multi-

Se il team IT non ha abilitato la possibilità di usare Azure AD Multi-Factor

In questa esercitazione si apprenderà come:

＂ Creare criteri di accesso condizionale per abilitare Azure AD Multi-Factor

Un account con privilegi di amministratore dell'accesso condizionale,

Un gruppo di cui l'utente non amministratore è membro. Per questa esercitazione

Creare criteri di accesso condizionale

In questa esercitazione viene creato un criterio di accesso condizionale di base per

Prima di tutto, creare un criterio di accesso condizionale e assegnare il gruppo di test

1. Accedere al portale di Azure usando un account con autorizzazioni di

2. Cercare e selezionare Azure Active Directory. Selezionare quindi Sicurezza dal

3. Selezionare Accesso condizionale, quindi + Nuovo criterio e infine Crea un nuovo

4. Immettere un nome per il criterio, ad esempio MFA Pilot.

5. In Assegnazioni selezionare il valore corrente in Utenti o identità del carico di

7. In Includi scegliere Seleziona utenti e gruppi e quindi selezionare Utenti e gruppi.

8. Cercare e selezionare il gruppo di Azure AD, ad esempio MFA-Test-Group, quindi