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

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 Microsoft Entra (CBA).

Implementazione a fasi

Un amministratore tenant potrebbe tagliare completamente il dominio federato a Entra ID CBA senza test pilota abilitando il metodo di autenticazione CBA in Entra ID e convertendo l'intero dominio in autenticazione gestita. Tuttavia, se il cliente vuole testare un piccolo batch di utenti autenticarsi con L'autorità di certificazione Entra ID prima del 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 a un IdP federato all'ID Microsoft Entra spostando selettivamente un piccolo set di utenti per l'uso di CBA in Entra ID (non più reindirizzato al provider di identità federato) con gruppi di utenti selezionati prima di convertire la configurazione del dominio in Entra ID da federato a gestito. L'implementazione a fasi non è progettata per mantenere federato il dominio per lunghi periodi di tempo o per grandi quantità 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, l'utente 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 phS è abilitato troppo altrimenti l'autenticazione della password avrà esito negativo.

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

Suggerimento

I passaggi descritti in questo articolo possono variare leggermente in base al portale da cui si inizia.

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

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un utente Amministrazione istrator.
  2. Cercare e selezionare Microsoft Entra Connessione.
  3. Nella pagina Microsoft Entra Connessione, nell'implementazione a fasi dell'autenticazione cloud, fare clic su Abilita implementazione temporanea per l'accesso utente gestito.
  4. Nella pagina Abilita funzionalità di implementazione a fasi fare clic su per l'opzione Autenticazione basata su certificati
  5. Fare clic su Gestisci gruppi e aggiungere gruppi che si desidera far parte dell'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 Connessione per aggiornare l'attributo certificateUserIds

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

Microsoft Entra Connessione richiede un ruolo speciale denominato Hybrid Identity Amministrazione istrator, che concede le autorizzazioni necessarie. Questo ruolo è necessario per l'autorizzazione per scrivere nel nuovo attributo cloud.

Nota

Se un utente usa attributi sincronizzati, ad esempio l'attributo onPremisesUserPrincipalName nell'oggetto utente per l'associazione del nome utente, tenere presente che qualsiasi utente con accesso amministrativo al server Microsoft Entra Connessione può modificare il mapping degli attributi sincronizzati e modificare il valore dell'attributo sincronizzato. L'utente non deve essere un amministratore cloud. L'amministratore di AD FS deve assicurarsi che l'accesso amministrativo al server Microsoft Entra Connessione 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?

Anche se è possibile, Microsoft consiglia gli account con privilegi come account solo cloud. L'uso di 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 dagli attacchi locali.

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

Microsoft consiglia agli account con privilegi di essere account solo cloud. Questa procedura limiterà l'esposizione in Microsoft Entra ID da un ambiente locale compromesso. La gestione degli account con privilegi è fondamentale per questo obiettivo.

Per gli 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 il dominio federato non viene completamente passato all'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 rappresentare chiunque, ad esempio un CIO, anche se non riesce a ottenere un ruolo solo cloud come l'account globale Amministrazione istrator.

Quando un dominio è federato in Microsoft Entra ID, viene inserito un elevato livello di attendibilità nel provider di identità federato. AD FS è un esempio, ma la nozione è vera per qualsiasi IdP federato. Molte organizzazioni distribuiscono un IdP federato, ad esempio AD FS esclusivamente per eseguire l'autenticazione basata su certificati. Microsoft Entra CBA rimuove completamente la dipendenza di AD FS in questo caso. 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 e così via o l'infrastruttura a chiave pubblica usata. I proprietari dell'infrastruttura a chiave pubblica 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 Di Microsoft Entra dell'utente che esegue l'accesso.

Nell'esempio del browser, l'utente digita più spesso nell'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 nei criteri.

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 l'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 nei criteri.

Passaggi successivi