Condividi tramite

Eseguire la migrazione dalla federazione all'autenticazione basata su certificati (CBA) di Microsoft Entra

  • Articolo

Questo articolo illustra come eseguire la migrazione dall'esecuzione di server federati, ad esempio Active Directory Federation Services (AD FS) in locale all'autenticazione cloud tramite l'autenticazione basata su certificati di Microsoft Entra (CBA).

Implementazione a fasi

Un amministratore tenant potrebbe spostarsi completamente dal dominio federato a Microsoft Entra CBA senza eseguire test pilota abilitando il metodo di autenticazione CBA nell'ID Microsoft Entra e convertendo l'intero dominio in autenticazione gestita. Tuttavia, se il cliente vuole testare l’autenticazione di un piccolo batch di utenti con Microsoft Entra CBA prima di eseguire il cutover completo del dominio da gestire, può usare la funzionalità di implementazione a fasi.

L’implementazione a fasi per l'autenticazione basata su certificati (CBA) consente ai clienti di passare dall'esecuzione di CBA in un IdP federato a Microsoft Entra ID spostando selettivamente un piccolo set di utenti per l'uso di CBA in Microsoft Entra ID (non più reindirizzato all’IdP federato) con gruppi di utenti selezionati prima di convertire la configurazione del dominio in Microsoft Entra ID da federato a gestito. L'implementazione a fasi non è progettata per mantenere il dominio come federato per lunghi periodi di tempo o per quantità elevate di utenti.

Guardare questo breve video che illustra la migrazione dall'autenticazione basata su certificati ADFS a Microsoft Entra CBA

Nota

Quando l'implementazione a fasi è abilitata per un utente, quest’ultimo viene considerato un utente gestito e tutte le autenticazioni verranno eseguite in Microsoft Entra ID. Per un tenant federato, se CBA è abilitato nell'implementazione a fasi, l'autenticazione della password funziona solo se anche PHS è abilitato, altrimenti l'autenticazione della password avrà esito negativo.

Abilitare l'implementazione a fasi per l'autenticazione basata su certificati nel tenant

Suggerimento

La procedura descritta in questo articolo può variare leggermente in base al portale di partenza.

Per configurare l'implementazione a fasi, seguire questa procedura:

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra almeno come Amministratore utenti.
  2. Cercare e selezionare Microsoft Entra Connect.
  3. Nella pagina Microsoft Entra Connect, sotto il link Implementazione a fasi dell'autenticazione cloud, fare clic su Abilita implementazione a fasi per l'accesso utente gestito.
  4. Nella pagina Abilita funzionalità di implementazione a fasi, fare clic su Sì per l'opzione Autenticazione basata su certificati
  5. Fare clic su Gestisci gruppi e aggiungere i gruppi che si desidera includere nell’autenticazione cloud. Per evitare un timeout, assicurarsi che i gruppi di sicurezza non contengano inizialmente più di 200 membri.

Per altre informazioni, vedere Implementazione a fasi.

Usare Microsoft Entra Connect per aggiornare l'attributo certificateUserIds

Un amministratore di AD FS può usarel'Editorregole di sincronizzazione per creare regole per sincronizzare i valori degli attributi da AD FS a oggetti utente di Microsoft Entra. Per altre informazioni, vedere Regole di sincronizzazione per certificateUserIds.

Microsoft Entra Connect richiede un ruolo speciale denominato Amministrazione di identità ibrida, che concede le autorizzazioni necessarie. Questo ruolo è necessario per disporre dell'autorizzazione per scrivere nel nuovo attributo cloud.

Nota

Se un utente usa attributi sincronizzati, ad esempio l'attributo onPremisesUserPrincipalName nell'oggetto utente per il binding di nome utente, tenere presente che qualsiasi utente con accesso amministrativo al server Microsoft Entra Connect può modificare il mapping e il valore dell'attributo sincronizzato. L'utente non ha bisogno di essere un amministratore cloud. L'amministratore di AD FS deve assicurarsi che l'accesso amministrativo al server Microsoft Entra Connect sia limitato e che gli account con privilegi siano account solo cloud.

Domande frequenti sulla migrazione da AD FS a Microsoft Entra ID

È possibile avere account con privilegi con un server AD FS federato?

Sebbene questo sia possibile, Microsoft consiglia che gli account con privilegi siano account solo cloud. Usare account solo cloud per limitare l'esposizione dell'accesso con privilegi in Microsoft Entra ID da un ambiente locale compromesso. Per altre informazioni, vedere Protezione di Microsoft 365 da attacchi in locale.

Se un'organizzazione è un ibrido che esegue sia AD FS che Azure CBA, è comunque vulnerabile alla compromissione di AD FS?

Microsoft consiglia che gli account con privilegi siano account solo cloud. Questa procedura limiterà l'esposizione in Microsoft Entra ID a un ambiente locale compromesso. La gestione degli account con privilegi è fondamentale per questo obiettivo.

Per account sincronizzati:

  • Se si trovano in un dominio gestito (non federato), non esiste alcun rischio per il provider di identità federato.
  • Se si trovano in un dominio federato, ma un subset di account viene spostato in Microsoft Entra CBA by Staged Rollout, sono soggetti a rischi correlati all'IDP federato fino a quando non si è passati completamente da dominio federato ad autenticazione cloud.

Le organizzazioni devono eliminare server federati come AD FS per impedire la funzionalità di pivot da AD FS ad Azure?

Con la federazione, un utente malintenzionato potrebbe spacciarsi per chiunque, ad esempio un CIO, anche se incapace di ottenere un ruolo solo cloud come un account amministratore con privilegi elevati.

Quando un dominio è federato in Microsoft Entra ID, viene inserito un elevato livello di attendibilità nel provider di identità federato. AD FS è soltanto un esempio: questa nozione è vera per qualsiasi IdP federato. Molte organizzazioni distribuiscono un IdP federato come AD FS esclusivamente per eseguire l'autenticazione basata su certificati. In questo case, Microsoft Entra CBA rimuove completamente la dipendenza di AD FS. Con Microsoft Entra CBA, i clienti possono spostare il proprio patrimonio di applicazioni in Microsoft Entra ID per modernizzare l'infrastruttura IAM e ridurre i costi con maggiore sicurezza.

Dal punto di vista della sicurezza, non viene apportata alcuna modifica alle credenziali, tra cui il certificato X.509, le CAC, i PIV etc. o alla PKI usata. I proprietari della PKI mantengono il controllo completo del ciclo di vita e dei criteri di rilascio e revoca dei certificati. Il controllo delle revoche e l'autenticazione si verificano in Microsoft Entra ID invece di IDP federato. Questi controlli abilitano l'autenticazione senza password e resistente al phishing direttamente all'ID Microsoft Entra per tutti gli utenti.

Come funziona l'autenticazione con l'autenticazione cloud Federated AD FS e Microsoft Entra con Windows?

Microsoft Entra CBA richiede all'utente o all'applicazione di fornire l'UPN Microsoft Entra dell'utente che esegue l'accesso.

Nell'esempio del browser, l'utente inserisce più spesso il proprio UPN di Microsoft Entra. L'UPN di Microsoft Entra viene usato per l'autenticazione e l'individuazione degli utenti. Il certificato usato deve quindi corrispondere a questo utente usando una delle associazioni di nome utente configurate nel criterio.

Nell'accesso a Windows, la corrispondenza dipende dal fatto che il dispositivo sia ibrido o aggiunto a Microsoft Entra. Ma in entrambi i casi, se viene fornito un hint per il nome utente, Windows invierà l'hint come UPN di Microsoft Entra. Il certificato usato deve quindi corrispondere a questo utente usando una delle associazioni di nome utente configurate nel criterio.

Passaggi successivi