L'articolo illustra come implementare l'autenticazione a più fattori per i client desktop di Outlook che accedono a Microsoft Exchange. Esistono quattro architetture che corrispondono a quattro diverse possibilità per Microsoft Exchange con la cassetta postale dell'utente:
Nota
Nei diagrammi le linee tratteggiate nere mostrano le interazioni di base tra i componenti locali di Active Directory, Microsoft Entra Connect, Microsoft Entra ID, AD FS e Web Application Proxy. È possibile ottenere informazioni su queste interazioni in Porte e protocolli necessari per l'identità ibrida.
Architettura (Exchange Online)
Scaricare un file di Visio di tutti i diagrammi in questo articolo.
In questo scenario, gli utenti devono usare la versione del client outlook che supporta l'autenticazione moderna. Per altre informazioni, vedere Funzionamento dell'autenticazione moderna per le app client di Office 2013, Office 2016 e Office 2019. Questa architettura riguarda sia Outlook per Windows che Outlook per Mac.
Flusso di lavoro (Exchange Online)
- L'utente tenta di accedere a Exchange Online tramite Outlook.
- Exchange Online fornisce l'URL di un endpoint Microsoft Entra per recuperare il token di accesso per ottenere l'accesso alla cassetta postale.
- Outlook si connette all'ID Microsoft Entra utilizzando tale URL.
- Non appena il dominio è federato, Microsoft Entra ID reindirizza la richiesta ad AD FS locale.
- L'utente immette le credenziali in una pagina di accesso ad AD FS.
- AD FS reindirizza la sessione a Microsoft Entra ID.
- Microsoft Entra ID applica criteri di accesso condizionale di Azure con un requisito di autenticazione a più fattori per le app per dispositivi mobili e i client desktop. Per informazioni sulla configurazione di tale criterio, vedere la sezione relativa alla distribuzione di questo articolo.
- I criteri di accesso condizionale chiamano l'autenticazione a più fattori Di Microsoft Entra. L'utente ottiene una richiesta per completare l'autenticazione a più fattori.
- L'utente completa l'autenticazione a più fattori.
- Microsoft Entra ID rilascia i token di accesso e di aggiornamento e li restituisce al client.
- Utilizzando il token di accesso, il client si connette a Exchange Online e recupera il contenuto.
Configurazione (Exchange Online)
Per bloccare i tentativi di accesso a Exchange Online tramite l'autenticazione legacy (la linea rossa tratteggiata nel diagramma), è necessario creare un criterio di autenticazione che disabilita l'autenticazione legacy per i protocolli usati dal servizio Outlook. Questi sono i protocolli specifici che è necessario disabilitare: individuazione automatica, MAPI, Rubriche offline e EWS. Ecco la configurazione corrispondente:
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook: False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
Il protocollo RPC (Remote Procedure Call) non è più supportato per Office 365, quindi l'ultimo parametro non influisce sui client.
Ecco un esempio di comando per la creazione di questo criterio di autenticazione:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Nota
Per impostazione predefinita, dopo aver creato i criteri, anche l'autenticazione legacy per tutti gli altri protocolli (ad esempio IMAP, POP e ActiveSync) è disabilitata. Per modificare questo comportamento, è possibile abilitare i protocolli usando un comando di PowerShell simile al seguente:
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
Dopo aver creato i criteri di autenticazione, è prima possibile assegnarlo a un gruppo pilota di utenti usando il Set-User user01 -AuthenticationPolicy <name_of_policy> comando . Dopo il test, è possibile espandere i criteri da includere a tutti gli utenti. Per applicare i criteri a livello di organizzazione, usare il Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> comando . Per questa configurazione è necessario usare PowerShell per Exchange Online.
Architettura (Exchange Online, AD FS)
Scaricare un file di Visio di tutti i diagrammi in questo articolo.
Questo scenario è uguale a quello precedente, ad eccezione del fatto che usa un trigger diverso per l'autenticazione a più fattori. Nello scenario precedente è stato usato AD FS locale per l'autenticazione. Sono quindi stati reindirizzati le informazioni sull'autenticazione riuscita a Microsoft Entra ID, in cui un criterio di accesso condizionale ha applicato l'autenticazione a più fattori. In questo scenario, invece di usare l'accesso condizionale per applicare l'autenticazione a più fattori, viene creato un criterio di controllo di accesso a livello di AD FS e viene applicata l'autenticazione a più fattori. Il resto dell'architettura è uguale a quello precedente.
Nota
È consigliabile questo scenario solo se non è possibile usare quello precedente.
In questo scenario, gli utenti devono usare la versione del client outlook che supporta l'autenticazione moderna. Per altre informazioni, vedere Funzionamento dell'autenticazione moderna per le app client di Office 2013, Office 2016 e Office 2019. Questa architettura riguarda sia Outlook per Windows che Outlook per Mac.
Flusso di lavoro (Exchange Online, AD FS)
L'utente tenta di accedere a Exchange Online tramite Outlook.
Exchange Online fornisce l'URL di un endpoint Microsoft Entra per recuperare il token di accesso per ottenere l'accesso alla cassetta postale.
Outlook si connette all'ID Microsoft Entra utilizzando tale URL.
Se il dominio è federato, Microsoft Entra ID reindirizza la richiesta ad AD FS locale.
L'utente immette le credenziali in una pagina di accesso ad AD FS.
Rispondere a un criterio di controllo di accesso di Active Directory Domain Services, AD FS chiama l'autenticazione a più fattori Di Microsoft Entra per completare l'autenticazione. Di seguito è riportato un esempio di questo tipo di criteri di controllo di accesso ad AD FS:
L'utente ottiene una richiesta per completare l'autenticazione a più fattori.
L'utente completa l'autenticazione a più fattori.
AD FS reindirizza la sessione a Microsoft Entra ID.
Microsoft Entra ID rilascia i token di accesso e di aggiornamento e li restituisce al client.
Utilizzando il token di accesso, il client si connette a Exchange Online e recupera il contenuto.
Configurazione (Exchange Online, AD FS)
Nota
I criteri di controllo di accesso implementati nel passaggio 6 vengono applicati al livello di attendibilità della relying party, quindi influisce su tutte le richieste di autenticazione per tutti i servizi di Office 365 che passano attraverso AD FS. È possibile usare le regole di autenticazione di AD FS per applicare filtri aggiuntivi. Tuttavia, è consigliabile usare criteri di accesso condizionale (descritti nell'architettura precedente) anziché usare un criterio di controllo di accesso AD FS per i servizi Microsoft 365. Lo scenario precedente è più comune e, usandolo, è possibile ottenere una maggiore flessibilità.
Per bloccare i tentativi di accesso a Exchange Online tramite l'autenticazione legacy (la linea rossa tratteggiata nel diagramma), è necessario creare un criterio di autenticazione che disabilita l'autenticazione legacy per i protocolli usati dal servizio Outlook. Questi sono i protocolli specifici che è necessario disabilitare: individuazione automatica, MAPI, Rubriche offline e EWS. Ecco la configurazione corrispondente:
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook: False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
Il protocollo RPC non è più supportato per Office 365, quindi l'ultimo parametro non influisce sui client.
Ecco un esempio di comando per la creazione di questo criterio di autenticazione:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Architettura (Exchange locale)
Scaricare un file di Visio di tutti i diagrammi in questo articolo.
Questa architettura riguarda sia Outlook per Windows che Outlook per Mac.
Flusso di lavoro (Exchange locale)
- Un utente con una cassetta postale in Exchange Server avvia il client Outlook. Il client Outlook si connette a Exchange Server e specifica che dispone di funzionalità di autenticazione moderne.
- Exchange Server invia una risposta al client che richiede di ottenere un token dall'ID Microsoft Entra.
- Il client Outlook si connette a un URL di Microsoft Entra fornito da Exchange Server.
- Azure identifica che il dominio dell'utente è federato, quindi invia richieste ad AD FS (tramite proxy applicazione Web).
- L'utente immette le credenziali in una pagina di accesso ad AD FS.
- AD FS reindirizza la sessione a Microsoft Entra ID.
- Microsoft Entra ID applica criteri di accesso condizionale di Azure con un requisito di autenticazione a più fattori per le app per dispositivi mobili e i client desktop. Per informazioni sulla configurazione di tale criterio, vedere la sezione relativa alla distribuzione di questo articolo.
- I criteri di accesso condizionale chiamano l'autenticazione a più fattori Di Microsoft Entra. L'utente ottiene una richiesta per completare l'autenticazione a più fattori.
- L'utente completa l'autenticazione a più fattori.
- Microsoft Entra ID rilascia i token di accesso e di aggiornamento e li restituisce al client.
- L'utente presenta il token di accesso a Exchange Server e Exchange autorizza l'accesso alla cassetta postale.
Configurazione (Exchange locale)
Per bloccare i tentativi di accesso a Exchange locale tramite l'autenticazione legacy (la linea rossa tratteggiata nel diagramma), è necessario creare un criterio di autenticazione che disabilita l'autenticazione legacy per i protocolli usati dal servizio Outlook. Questi sono i protocolli specifici che è necessario disabilitare: individuazione automatica, MAPI, Rubriche offline, EWS e RPC. Ecco la configurazione corrispondente:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook: True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Il protocollo RPC non supporta l'autenticazione moderna, quindi non supporta l'autenticazione a più fattori di Microsoft Entra. Microsoft consiglia il protocollo MAPI per i client Outlook per Windows.
Ecco un esempio di comando per la creazione di questo criterio di autenticazione:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
Dopo aver creato i criteri di autenticazione, è prima possibile assegnarlo a un gruppo pilota di utenti usando il Set-User user01 -AuthenticationPolicy <name_of_policy> comando . Dopo il test, è possibile espandere i criteri per includere tutti gli utenti. Per applicare i criteri a livello di organizzazione, usare il Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> comando . Per questa configurazione è necessario usare PowerShell locale di Exchange.
Architettura (Exchange locale, AD FS)
Scaricare un file di Visio di tutti i diagrammi in questo articolo.
Questo scenario è simile a quello precedente. In questo scenario, tuttavia, l'autenticazione a più fattori viene attivata da AD FS. Questa architettura riguarda sia Outlook per Windows che Outlook per Mac.
Nota
È consigliabile questo scenario solo se non è possibile usare quello precedente.
Flusso di lavoro (Exchange locale, AD FS)
L'utente avvia il client outlook. Il client si connette a Exchange Server e specifica che dispone di funzionalità di autenticazione moderne.
Exchange Server invia una risposta al client che richiede di ottenere un token dall'ID Microsoft Entra. Exchange Server fornisce al client un URL per Microsoft Entra ID.
Il client usa l'URL per accedere all'ID Microsoft Entra.
In questo scenario, il dominio è federato. Microsoft Entra ID reindirizza il client ad AD FS tramite proxy applicazione Web.
L'utente immette le credenziali in una pagina di accesso ad AD FS.
AD FS attiva l'autenticazione a più fattori. Di seguito è riportato un esempio di questo tipo di criteri di controllo di accesso ad AD FS:
L'utente ottiene una richiesta per completare l'autenticazione a più fattori.
L'utente completa l'autenticazione a più fattori.
AD FS reindirizza la sessione a Microsoft Entra ID.
Microsoft Entra ID rilascia i token di accesso e aggiornamento all'utente.
Il client presenta il token di accesso al server locale di Exchange. Exchange autorizza l'accesso alla cassetta postale dell'utente.
Configurazione (Exchange locale, AD FS)
Nota
I criteri di controllo di accesso implementati nel passaggio 6 vengono applicati al livello di attendibilità della relying party, in modo che influisca su tutte le richieste di autenticazione per tutti i servizi di Office 365 che passano attraverso AD FS. È possibile usare le regole di autenticazione di AD FS per applicare filtri aggiuntivi. Tuttavia, è consigliabile usare criteri di accesso condizionale (descritti nell'architettura precedente) anziché usare un criterio di controllo di accesso AD FS per i servizi Microsoft 365. Lo scenario precedente è più comune e, usandolo, è possibile ottenere una maggiore flessibilità.
Per bloccare i tentativi di accesso a Exchange locale tramite l'autenticazione legacy (la linea rossa tratteggiata nel diagramma), è necessario creare un criterio di autenticazione che disabilita l'autenticazione legacy per i protocolli usati dal servizio Outlook. Questi sono i protocolli specifici che è necessario disabilitare: individuazione automatica, MAPI, Rubriche offline, EWS e RPC. Ecco la configurazione corrispondente:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook: True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Il protocollo RPC non supporta l'autenticazione moderna, quindi non supporta l'autenticazione a più fattori di Microsoft Entra. Microsoft consiglia il protocollo MAPI per i client Outlook per Windows.
Ecco un esempio di comando per la creazione di questo criterio di autenticazione:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
Dopo aver creato i criteri di autenticazione, è prima possibile assegnarlo a un gruppo pilota di utenti usando il Set-User user01 -AuthenticationPolicy <name_of_policy> comando . Dopo il test, è possibile espandere i criteri per includere tutti gli utenti. Per applicare i criteri a livello di organizzazione, usare il Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> comando . Per questa configurazione è necessario usare PowerShell locale di Exchange.
Componenti
- Microsoft Entra ID. Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato sul cloud Microsoft. Fornisce l'autenticazione moderna essenzialmente basata su EvoSTS (un servizio token di sicurezza usato da Microsoft Entra ID). Viene usato come server di autenticazione per Exchange Server locale.
- Autenticazione a più fattori Microsoft Entra. L'autenticazione a più fattori è un processo in cui gli utenti vengono richiesti durante il processo di accesso per un'altra forma di identificazione, ad esempio un codice sul cellulare o un'analisi delle impronte digitali.
- Accesso condizionale Microsoft Entra. L'accesso condizionale è la funzionalità usata da Microsoft Entra ID per applicare criteri aziendali come l'autenticazione a più fattori.
- AD FS. AD FS consente la gestione federata delle identità e degli accessi condividendo diritti di identità digitali e diritti attraverso i limiti di sicurezza e organizzazione con una maggiore sicurezza. In queste architetture viene usato per facilitare l'accesso per gli utenti con identità federata.
- Proxy applicazione Web. Proxy applicazione Web preautentica l'accesso alle applicazioni Web tramite AD FS. Funziona anche come proxy AD FS.
- Microsoft Intune. Intune è la gestione unificata degli endpoint basata sul cloud, la gestione degli endpoint nei sistemi operativi Windows, Android, Mac, iOS e Linux.
- Exchange Server. Exchange Server ospita le cassette postali degli utenti in locale. In queste architetture usa i token rilasciati all'utente da Microsoft Entra ID per autorizzare l'accesso alle cassette postali.
- Servizi Active Directory. Servizi Active Directory archivia informazioni sui membri di un dominio, inclusi i dispositivi e gli utenti. In queste architetture gli account utente appartengono ai servizi di Active Directory e vengono sincronizzati con Microsoft Entra ID.
- Outlook per le aziende. Outlook è un'applicazione client che supporta l'autenticazione moderna.
Dettagli dello scenario
L'infrastruttura di messaggistica aziendale (EMI) è un servizio chiave per le organizzazioni. Il passaggio da metodi meno recenti e meno sicuri di autenticazione e autorizzazione all'autenticazione moderna è una sfida fondamentale in un mondo in cui il lavoro remoto è comune. L'implementazione dei requisiti di autenticazione a più fattori per l'accesso al servizio di messaggistica è uno dei modi più efficaci per soddisfare tale sfida.
Questo articolo descrive quattro architetture per migliorare la sicurezza in uno scenario di accesso client desktop di Outlook tramite l'autenticazione a più fattori Di Microsoft Entra.
Queste sono quattro architetture in base a quattro diverse possibilità per Microsoft Exchange:
Tutte e quattro le architetture coprono sia Outlook per Windows che Outlook per Mac.
Per informazioni sull'applicazione dell'autenticazione a più fattori in altri scenari di messaggistica ibrida, vedere gli articoli seguenti:
- Infrastruttura di messaggistica ibrida per la sicurezza avanzata in uno scenario di accesso Web
- Infrastruttura di messaggistica ibrida per la sicurezza avanzata in uno scenario di accesso per dispositivi mobili
Questo articolo non illustra altri protocolli, ad esempio IMAP o POP. In genere, questi scenari non usano questi protocolli.
Note generali
- Queste architetture usano il modello di identità Microsoft Entra federato . Per la sincronizzazione dell'hash delle password e i modelli di autenticazione pass-through, la logica e il flusso sono gli stessi. L'unica differenza è correlata al fatto che Microsoft Entra ID non reindirizza la richiesta di autenticazione a Active Directory locale Federation Services (AD FS).
- In exchange locale si intende Exchange 2019 con gli aggiornamenti più recenti e un ruolo Cassetta postale.
- In un ambiente reale, non si avrà un solo server. Si avrà una matrice con carico bilanciato di server Exchange per la disponibilità elevata. Gli scenari descritti di seguito sono adatti a tale configurazione.
Potenziali casi d'uso
Questa architettura è rilevante per gli scenari seguenti:
- Migliorare la sicurezza EMI.
- Adottare una strategia di sicurezza Zero Trust .
- Applicare il livello elevato di protezione standard per il servizio di messaggistica locale durante la transizione o la coesistenza con Exchange Online.
- Applicare rigorosi requisiti di sicurezza o conformità nelle organizzazioni chiuse o altamente protette, ad esempio quelle del settore finanziario.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Disponibilità
La disponibilità complessiva dipende dalla disponibilità dei componenti coinvolti. Per informazioni sulla disponibilità, vedere queste risorse:
- Miglioramento della disponibilità di Microsoft Entra
- Servizi cloud attendibili: disponibilità di Office 365
- Che cos'è l'architettura di Microsoft Entra?
La disponibilità dei componenti della soluzione locale dipende dalla progettazione implementata, dalla disponibilità hardware e dalle operazioni interne e dalle routine di manutenzione. Per informazioni sulla disponibilità su alcuni di questi componenti, vedere le risorse seguenti:
- Configurazione di una distribuzione di AD FS con gruppi di disponibilità AlwaysOn
- Distribuzione della disponibilità elevata e della resilienza del sito in Exchange Server
- Proxy applicazione Web in Windows Server
Per usare l'autenticazione moderna ibrida, è necessario assicurarsi che tutti i client della rete possano accedere all'ID Microsoft Entra. È anche necessario mantenere costantemente le porte del firewall di Office 365 e le aperture dell'intervallo IP.
Per i requisiti di protocollo e porte per Exchange Server, vedere "Requisiti del protocollo e del client di Exchange" in Panoramica dell'autenticazione moderna ibrida per l'uso con i server Skype for Business ed Exchange locali.
Per gli intervalli e le porte IP di Office 365, vedere URL e intervalli di indirizzi IP di Office 365.
Per informazioni sull'autenticazione moderna ibrida e sui dispositivi mobili, vedere Endpoint autoDetect in Altri endpoint non inclusi nel servizio Web url e indirizzo IP di Office 365.
Resilienza
Per informazioni sulla resilienza dei componenti in questa architettura, vedere le risorse seguenti.
- Per Microsoft Entra ID: avanzamento della disponibilità di Microsoft Entra
- Per scenari che usano AD FS: distribuzione ad AD FS multi-geografico a disponibilità elevata in Azure con Gestione traffico di Azure
- Per la soluzione locale di Exchange: Disponibilità elevata di Exchange
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Per informazioni sulla sicurezza e sull'autenticazione moderna ibrida, vedere Deep Dive: How Hybrid Authentication Really Works(Approfondimento: Funzionamento dell'autenticazione ibrida).
Per le organizzazioni chiuse con protezione perimetrale avanzata tradizionale, esistono problemi di sicurezza correlati alle configurazioni classiche di Exchange ibride. La configurazione di Exchange Hybrid Modern non supporta l'autenticazione moderna ibrida.
Per informazioni sull'ID Microsoft Entra, vedere La guida alle operazioni di sicurezza di Microsoft Entra.
Per informazioni sugli scenari che usano la sicurezza di AD FS, vedere gli articoli seguenti:
- Procedure consigliate per la protezione di AD FS e proxy applicazione Web
- Configurare il blocco intelligente Extranet di AD FS
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Il costo dell'implementazione dipende dai costi di licenza di Microsoft Entra ID e Microsoft 365. Il costo totale include anche i costi per il software e l'hardware per i componenti locali, le operazioni IT, la formazione e l'istruzione e l'implementazione del progetto.
Queste soluzioni richiedono almeno Microsoft Entra ID P1. Per informazioni dettagliate sui prezzi, vedere Prezzi di Microsoft Entra.
Per informazioni su AD FS e Proxy applicazione Web, vedere Prezzi e licenze per Windows Server 2022.
Per altre informazioni sui prezzi, vedere queste risorse:
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi in modo efficiente per soddisfare le esigenze che gli utenti lo pongono. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.
Le prestazioni del carico di lavoro dipendono dalle prestazioni dei componenti coinvolti e dalle prestazioni di rete. Per altre informazioni, vedere Ottimizzazione delle prestazioni di Office 365 usando le linee di base e la cronologia delle prestazioni.
Per informazioni sui fattori locali che influiscono sulle prestazioni per scenari che includono servizi AD FS, vedere queste risorse:
- Configurare il monitoraggio delle prestazioni
- Ottimizzazione di SQL e risoluzione dei problemi di latenza con AD FS
Per informazioni sulla scalabilità di AD FS, vedere Pianificazione della capacità del server AD FS.
Per informazioni sulla scalabilità locale di Exchange Server, vedere Architettura preferita di Exchange 2019.
Distribuire lo scenario
Ecco i passaggi principali:
- Proteggere l'accesso desktop di Outlook configurando la configurazione ibrida di Exchange e abilitando l'autenticazione moderna ibrida.
- Blocca tutti i tentativi di autenticazione legacy a livello di ID Microsoft Entra. Bloccare i tentativi di autenticazione legacy a livello di servizi di messaggistica usando i criteri di autenticazione.
Configurare un criterio di accesso condizionale
Per configurare criteri di accesso condizionale di Microsoft Entra che applicano l'autenticazione a più fattori, come descritto in alcune delle architetture di questo articolo:
Nella finestra App client selezionare App per dispositivi mobili e client desktop:
Applicare il requisito di autenticazione a più fattori nella finestra Concedi :
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Koh Kondrashov | Cloud Solution Architect
- Ella Parkum | Principal Customer Solution Architect-Engineering
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Annuncio dell'autenticazione moderna ibrida per Exchange locale
- Panoramica dell'autenticazione moderna ibrida e prerequisiti per l'uso con server Exchange locali
- Usare l'autenticazione basata sulle attestazioni di AD FS con Outlook sul web
- Come configurare Exchange Server locale per utilizzare l'Autenticazione moderna ibrida
- Architettura preferita di Exchange 2019
- Distribuzione di AD FS a disponibilità elevata tra aree geografiche in Azure con Gestione traffico di Azure
- Uso dell'autenticazione moderna ibrida con Outlook per iOS e Android
- Configurazione dell'account con autenticazione moderna in Exchange Online