Esaminare le opzioni di autenticazione per il modello di identità ibrido
- 9 minuti
Il modello di identità ibrido consente alle organizzazioni di sincronizzare gli oggetti e gli attributi Active Directory locale con i Microsoft Entra ID basati sul cloud. Le organizzazioni che usano un modello ibrido usano la sincronizzazione della directory per gestire le identità nel Active Directory Domain Services (Ad DS). La sincronizzazione della directory sincronizza anche tutti gli aggiornamenti a account utente, gruppi e contatti al tenant Microsoft Entra delle sottoscrizioni di Microsoft 365.
Nota
Quando la sincronizzazione della directory sincronizza gli account utente di Active Directory Domain Services per la prima volta, non assegna automaticamente una licenza di Microsoft 365 e non può accedere ai servizi di Microsoft 365, ad esempio la posta elettronica. Le organizzazioni devono prima assegnare loro una posizione di utilizzo. Devono quindi assegnare una licenza a questi account utente, singolarmente o dinamicamente tramite l'appartenenza a gruppi.
Quando si usa il modello di identità ibrido, le organizzazioni possono scegliere tra i tipi di autenticazione seguenti:
- Autenticazione gestita. Microsoft Entra ID gestisce il processo di autenticazione. Usa una versione con hash archiviata localmente della password oppure invia le credenziali a un agente software locale che le autentica usando Active Directory Domain Services locale.
- Autenticazione federata. Microsoft Entra ID reindirizza il computer client che richiede l'autenticazione a un altro provider di identità.
Le sezioni seguenti esaminano questi due tipi di autenticazione in modo più dettagliato.
Autenticazione gestita
Sono disponibili due tipi di autenticazione gestita:
- Sincronizzazione dell'hash delle password (PHS). Con PHS, Microsoft Entra ID esegue l'autenticazione stessa. PHS consente agli utenti di usare lo stesso nome utente e la stessa password usati in locale.
- Autenticazione pass-through (PTA). Con PTA, Microsoft Entra ID dispone di Active Directory Domain Services per eseguire l'autenticazione. Questa opzione è simile alla sincronizzazione dell'hash delle password, ma offre una semplice convalida delle password usando agenti software locali per le organizzazioni con criteri di sicurezza e conformità sicuri.
Letture aggiuntive. Per altre informazioni, vedere Scelta del metodo di autenticazione corretto.
Sincronizzazione dell'hash delle password (PHS)
Con PHS, le organizzazioni sincronizzano gli account utente di Active Directory Domain Services con Microsoft 365 e gestiscono gli utenti in locale. Le organizzazioni non devono distribuire alcuna infrastruttura aggiuntiva oltre a Microsoft Entra Connect Sync o Microsoft Entra Cloud Sync.
PHS usa un processo di sincronizzazione hash unidirezionale sicuro per proteggere la password dell'utente. L'hash della password viene crittografato durante la trasmissione e archiviato in modo sicuro in Microsoft Entra ID, che usa l'hash a scopo di autenticazione.
Importante
PHS non invia o archivia mai la password effettiva in Microsoft Entra ID, che consente di proteggere dagli attacchi correlati alle password.
PHS offre diversi vantaggi, tra cui:
- Possibilità di usare password locali per i servizi basati sul cloud.
- Riduzione del numero di password che gli utenti devono ricordare.
- Possibilità di applicare criteri password locali nel cloud.
Quando gli utenti modificano o reimpostano le password in locale, PHS sincronizza i nuovi hash delle password con Microsoft Entra ID. In questo modo, gli utenti possono sempre usare la stessa password per le risorse cloud e locali. PHS non invia mai password utente a Microsoft Entra ID, né le archivia in Microsoft Entra ID in testo non crittografate. Alcune funzionalità Premium di Microsoft Entra ID, ad esempio Identity Protection, richiedono PHS indipendentemente dal metodo di autenticazione usato da un'organizzazione.
Autenticazione pass-through (PTA)
PTA offre una semplice convalida della password per i servizi di autenticazione Microsoft Entra. Autentica gli utenti convalidando le credenziali di Active Directory locale in base a un agente software leggero in esecuzione in uno o più server locali. Questo processo convalida gli utenti direttamente con Active Directory Domain Services. Con PTA si sincronizzano gli account utente di Active Directory Domain Services con Microsoft 365 e si gestiscono gli utenti in locale.
Quando un'organizzazione abilita PTA, reindirizza gli utenti all'agente PTA per autenticare le proprie credenziali. L'agente convalida le credenziali dell'utente in base al Active Directory locale e restituisce i risultati dell'autenticazione a Microsoft 365.
Importante
PTA non invia o archivia mai le password in Microsoft 365, che consente di proteggere dagli attacchi correlati alle password.
PTA supporta una gamma di scenari di autenticazione, tra cui:
- Autenticazione basata su password
- Autenticazione con smart card
- Altre forme di autenticazione a più fattori
PTA offre anche molte funzionalità avanzate, tra cui la possibilità di:
- Escludere utenti o gruppi specifici dall'autenticazione.
- Specificare una porta personalizzata per l'agente PTA.
- Configurare il failover in altri metodi di autenticazione se si verifica un errore.
PTA offre diversi vantaggi, tra cui:
- Possibilità di usare password locali per i servizi basati sul cloud.
- Riduzione del numero di password che gli utenti devono ricordare.
- Possibilità di applicare criteri password locali nel cloud.
Attenzione
L'agente leggero che PTA richiede alle organizzazioni di installare e gestire in locale potrebbe non essere adatto a tutte le organizzazioni o scenari di autenticazione.
PTA consente agli utenti di un'organizzazione di accedere alle risorse e alle applicazioni locali e di Microsoft 365 usando l'account e la password locali. Questa configurazione convalida le password degli utenti direttamente rispetto ad Active Directory Domain Services locale dell'organizzazione senza archiviare gli hash delle password in Microsoft Entra ID.
Microsoft ha progettato PTA per le organizzazioni con un requisito di sicurezza per applicare immediatamente gli stati dell'account utente locale, i criteri password e le ore di accesso.
Autenticazione federata
Quando si sceglie questo metodo di autenticazione, Microsoft Entra ID passa il processo di autenticazione a un sistema di autenticazione attendibile separato per convalidare l'accesso dell'utente. L'autenticazione federata è destinata principalmente alle organizzazioni aziendali di grandi dimensioni con requisiti di autenticazione più complessi. Sincronizza le identità di Active Directory Domain Services con Microsoft 365. È inoltre necessario che le organizzazioni gestino i propri account utente in locale. Con l'autenticazione federata, un utente ha la stessa password in locale e nel cloud. Di conseguenza, non è necessario eseguire di nuovo l'accesso per usare Microsoft 365.
L'autenticazione federativa in Microsoft 365 può usare Active Directory Federation Services (AD FS) o un sistema federativo di terze parti per convalidare l'accesso dell'utente. AD FS è un servizio Microsoft che offre funzionalità di single sign-on (SSO) e federazione delle identità. AD FS consente agli utenti di eseguire l'autenticazione usando le credenziali Active Directory locale e accedere alle risorse in ambienti cloud o partner senza la necessità di identità o credenziali separate.
AD FS usa il linguaggio SAML (Security Assertion Markup Language) e altri protocolli per scambiare in modo sicuro i dati di autenticazione e autorizzazione tra organizzazioni diverse. Può abilitare l'accesso SSO con un'ampia gamma di applicazioni e servizi che supportano SAML o altri standard federativi.
L'uso di AD FS per l'autenticazione federativa con Microsoft 365 offre diversi vantaggi, tra cui:
- Possibilità di usare Active Directory locale per autenticare gli utenti.
- Accesso Single Sign-On (SSO) a più applicazioni cloud.
- Supporto per l'autenticazione a più fattori (MFA) e i criteri di accesso condizionale.
Processo di autenticazione federata originale
Microsoft originariamente progettava l'autenticazione federativa in modo che quando un utente tentava di accedere a una risorsa di Microsoft 365, la richiesta passasse prima a un server proxy federativo. Il server proxy federativo ha quindi reindirizzato l'utente al provider di identità appropriato per l'autenticazione. Il provider di identità era un server AD FS locale o un provider di identità di terze parti che supportava SAML (Security Assertion Markup Language) o OpenID Connect (OIDC).
Dopo che il provider di identità ha autenticato l'utente, ha inviato un token di sicurezza al server proxy federativo, che a sua volta lo ha inviato a Microsoft 365. Microsoft 365 ha quindi usato il token di sicurezza per autorizzare l'utente e concedere l'accesso alla risorsa richiesta.
Il server proxy federativo ha agito come intermediario tra l'utente, il provider di identità e Microsoft 365. Ha contribuito a garantire che il processo di autenticazione fosse sicuro e che la trasmissione non compromettono le credenziali utente. Inoltre, il server proxy federativo potrebbe fornire funzionalità di bilanciamento del carico e failover per la disponibilità elevata e la scalabilità del processo di autenticazione.
Sostituzione del server proxy federativo con un proxy dell'applicazione Web
Un nuovo servizio ruolo di Accesso remoto denominato Web Application Proxy (WAP) ha assunto il ruolo del proxy del server federativo a partire da Windows Server 2012 R2. Nelle versioni legacy di AD FS (ad esempio AD FS 2.0 e AD FS in Windows Server 2012), il proxy del server federativo ha abilitato AD FS per l'accessibilità dall'esterno della rete aziendale. Per fornire la stessa funzionalità in Windows Server 2012 R2 e versioni successive, le organizzazioni possono distribuire uno o più proxy di applicazioni Web.
Nel contesto di AD FS, Web Application Proxy funziona come proxy del server federativo AD FS. WAP offre anche funzionalità proxy inverso per le applicazioni Web all'interno della rete aziendale di un'organizzazione. Questa progettazione consente agli utenti di qualsiasi dispositivo di accedervi dall'esterno della rete aziendale.
Nel complesso, il server Application Proxy Web offre una soluzione più flessibile e scalabile per l'accesso remoto sicuro alle applicazioni Web rispetto al server proxy federativo precedente. Offre anche le nuove funzionalità e i miglioramenti seguenti:
- Supporto migliore per i protocolli di autenticazione moderni. WAP supporta protocolli di autenticazione più recenti, ad esempio OAuth e OpenID Connect, oltre ai tradizionali protocolli basati su SAML. Questa funzionalità consente alle organizzazioni di fornire l'accesso alle moderne applicazioni Web che richiedono questi protocolli per l'autenticazione.
- Miglioramento delle funzionalità di pubblicazione delle applicazioni. WAP offre opzioni più flessibili per la pubblicazione di applicazioni in Internet, tra cui la preautenticazione e l'autenticazione pass-through. Questa funzionalità consente alle organizzazioni di proteggere l'accesso alle applicazioni e di controllare meglio l'accesso in base all'identità dell'utente.
- Supporto per protocolli aggiuntivi. WAP supporta altri protocolli, ad esempio HTTP e HTTPS, oltre ai tradizionali protocolli SAML e WS-Federation. Questa funzionalità semplifica l'accesso remoto sicuro a una gamma più ampia di applicazioni.
- Integrazione con Microsoft Entra ID. Le organizzazioni possono integrare WAP con Microsoft Entra ID per fornire una soluzione di autenticazione e autorizzazione basata sul cloud. Questa funzionalità semplifica l'accesso sicuro alle applicazioni e alle risorse basate sul cloud.
- Scalabilità e prestazioni migliorate. WAP offre scalabilità e prestazioni migliorate rispetto al server proxy federato precedente. Può gestire un numero maggiore di richieste e offrire tempi di risposta migliori, rendendolo più adatto per le organizzazioni più grandi con requisiti di traffico più elevati.
Provider di identità e autenticazione di terze parti
Oltre ad AD FS, Microsoft 365 supporta la federazione con altri provider di identità, ad esempio Microsoft Entra ID, PingFederate, Okta e altri provider di identità di terze parti che supportano i protocolli SAML o WS-Federation. Di conseguenza, le organizzazioni possono usare l'infrastruttura AD FS locale o un provider di identità di terze parti per autenticare gli utenti per i servizi di Microsoft 365.
I provider di identità e autenticazione di terze parti possono sincronizzare gli oggetti directory locali con Microsoft 365 e con l'accesso alle risorse cloud gestito principalmente da un provider di identità di terze parti. Se un'organizzazione usa una soluzione federativa di terze parti, può configurare l'accesso con tale soluzione per Microsoft 365 a condizione che la soluzione federativa di terze parti sia compatibile con Microsoft Entra ID.
Letture aggiuntive. Per altre informazioni, vedere l'elenco di compatibilità della federazione Microsoft Entra ID.
Amministrazione
Poiché un'organizzazione archivia account utente originali e autorevoli in Active Directory Domain Services locale, deve gestire le proprie identità con gli stessi strumenti usati per gestire Active Directory Domain Services.
Le organizzazioni non possono gestire gli account utente sincronizzati in Microsoft Entra ID usando il interfaccia di amministrazione di Microsoft 365 o PowerShell.
Verifica delle conoscenze
Scegliere la risposta migliore per ognuna delle domande seguenti.