Eseguire la migrazione all'autenticazione cloud con implementazione a fasi

L'implementazione a fasi consente di testare in modo selettivo gruppi di utenti con funzionalità di autenticazione cloud come Azure AD Multi-Factor Authentication (MFA), Accesso condizionale, Identity Protection per le credenziali perse, Identity Governance e altri ancora, prima di eliminare i domini. Questo articolo illustra come eseguire il passaggio. Prima di iniziare l'implementazione a fasi, è tuttavia necessario considerare i possibili effetti in presenza di uno o più delle condizioni seguenti:

  • È attualmente in uso un server Multi-Factor Authentication locale.
  • Si usano smart card per l'autenticazione.
  • Il server corrente offre alcune funzionalità solo per la federazione.

Prima di provare questa funzionalità, è consigliabile rivedere la guida relativa alla scelta del metodo di autenticazione appropriato. Per altre informazioni, vedere la tabella "Confronto dei metodi" in Scegliere il metodo di autenticazione appropriato per la soluzione ibrida di gestione delle identità di Azure Active Directory.

Per una panoramica della funzionalità, vedere il video seguente sull'implementazione a fasi in Azure Active Directory.

Prerequisiti

  • Si ha un tenant Azure Active Directory (Azure AD) con domini federati.

  • Si è deciso di passare a una delle due opzioni seguenti:

    Per entrambe le opzioni, è consigliabile abilitare l'accesso Single Sign-On (SSO) per ottenere un'esperienza di accesso invisibile all'utente. Per Windows 7 o 8.1 aggiunti a un dominio, è consigliabile usare l'accesso Single Sign-On facile. Per altre informazioni, vedere Informazioni sull'accesso Single Sign-On facile. Per Windows 10, Windows Server 2016 e versioni successive, è consigliabile usare SSO tramite token di aggiornamento primario (PRT) con dispositivi aggiunti Azure AD,dispositivi aggiunti Azure AD ibridi o dispositivi registrati personali tramite Aggiungi account aziendale o dell'istituto di istruzione.

  • Sono stati configurati tutti i criteri appropriati di personalizzazione del tenant e di accesso condizionale necessari per gli utenti di cui viene eseguita la migrazione all'autenticazione cloud.

  • Se si prevede di usare Azure AD Multi-Factor Authentication, è consigliabile usare la registrazione combinata per la reimpostazione della password self-service (SSPR) e Multi-Factor Authentication per fare in modo che gli utenti registrino i metodi di autenticazione una sola volta. Nota: quando si usa SSPR per reimpostare la password o modificare la password usando la pagina MyProfile durante l'implementazione a fasi, Azure AD Connessione deve sincronizzare il nuovo hash della password che può richiedere fino a 2 minuti dopo la reimpostazione.

  • Per usare la funzionalità di implementazione a fasi, è necessario essere un amministratore globale nel tenant.

  • Per abilitare l'accesso Single Sign-On facile in una foresta di Active Directory specifica, è necessario essere un amministratore di dominio.

  • Se si distribuisce hybrid Azure AD o Azure AD join, è necessario eseguire l'aggiornamento Windows 10 1903.

Scenari supportati

Per l'implementazione a fasi sono supportati gli scenari riportati di seguito. La funzionalità può essere usata solo nei casi seguenti:

  • Utenti di cui è stato effettuato il provisioning per Azure AD tramite Azure AD Connect. Non si applica a utenti solo cloud.

  • Traffico di accesso utente in browser e client con autenticazione moderna. Le applicazioni o i servizi cloud che usano l'autenticazione legacy eseguiranno il fallback ai flussi di autenticazione federati, ad esempio Exchange Online con l'autenticazione moderna disattivata oppure Outlook 2010, che non supporta l'autenticazione moderna.

  • Le dimensioni del gruppo sono attualmente limitate a 50.000 utenti. Se i gruppi hanno più di 50.000 utenti, è consigliabile suddividerli in più gruppi per poter usare l'implementazione a fasi.

  • Windows 10 aggiunta ibrida o Azure AD L'acquisizione del token di aggiornamento primario senza alcuna visualizzazione al server federativo per Windows 10 versione 1903 e successiva, quando l'UPN dell'utente è instradabile e il suffisso del dominio viene verificato in Azure AD.

  • La registrazione di Autopilot è supportata nell'implementazione a fasi Windows 10 versione 1909 o successiva.

Scenari non supportati

Per l'implementazione a fasi non sono supportati gli scenari riportati di seguito:

  • L'autenticazione legacy, ad esempio POP3 e SMTP, non è supportata.

  • Alcune applicazioni inviano il parametro di query "domain_hint" ad Azure AD durante l'autenticazione. Questi flussi saranno ancora possibili e gli utenti abilitati per l'implementazione a fasi continueranno a usare la federazione per l'autenticazione.

  • Gli amministratori possono implementare l'autenticazione cloud usando i gruppi di sicurezza. Per evitare latenza di sincronizzazione durante l'uso dei gruppi di sicurezza Active Directory locali, è consigliabile usare gruppi di sicurezza cloud. Si applicano le condizioni seguenti:

    • È possibile usare un massimo di 10 gruppi per ogni funzionalità, vale a dire 10 gruppi per sincronizzazione dell'hash delle password, 10 per autenticazione pass-through e 10 per accesso Single Sign-On facile.
    • I gruppi annidati non sono supportati.
    • I gruppi dinamici non sono supportati per l'implementazione a fasi.
    • Gli oggetti Contact all'interno del gruppo impediscono l'aggiunta del gruppo.
  • Quando un gruppo di sicurezza viene aggiunto per l'implementazione a fasi per la prima volta, il limite di utenti è 200 per evitare che si verifichi un timeout nell'esperienza utente. Dopo aver aggiunto il gruppo, è possibile aggiungervi altri utenti direttamente, se necessario.

  • Mentre gli utenti sono in fase di implementazione a fasi, i criteri di scadenza delle password sono impostati su 90 giorni senza alcuna opzione per personalizzarlo.

  • Windows 10 l'aggiunta ibrida o Azure AD l'acquisizione del token di aggiornamento primario per Windows 10 versione precedente alla 1903. Questo scenario esegue il fall back all'endpoint WS-Trust del server federativo, anche se l'utente che esegue l'accesso rientra nell'ambito dell'implementazione a fasi.

  • Windows 10'aggiunta ibrida o Azure AD'acquisizione del token di aggiornamento primario per tutte le versioni, quando l'UPN locale dell'utente non è instradabile. Questo scenario esegue il fall back all'endpoint WS-Trust in modalità di implementazione a fasi, ma smette di funzionare al termine della migrazione a fasi e l'accesso utente non si basa più sul server federativo.

  • Se si dispone di una configurazione VDI non persistente con Windows 10 versione 1903 o successiva, è necessario rimanere in un dominio federato. Lo spostamento in un dominio gestito non è supportato in VDI non persistente. Per altre informazioni, vedere Identità del dispositivo e virtualizzazione desktop.

  • Se si dispone di un trust di certificati ibridi di Windows Hello for Business con certificati rilasciati tramite il server federativo che funge da autorità di registrazione o utenti smart card, lo scenario non è supportato in un'implementazione a fasi.

    Nota

    È comunque necessario eseguire il passaggio finale dall'autenticazione federata all'autenticazione cloud usando Azure AD Connect o PowerShell. L'implementazione a fasi non cambia i domini da federati a gestiti. Per altre informazioni sul cutover del dominio, vedere Eseguire la migrazione dalla federazione alla sincronizzazione dell'hash delle password e Eseguire la migrazione dalla federazione all'autenticazione pass-through.

Introduzione all'implementazione a fasi

Per testare l'accesso tramite sincronizzazione dell'hash delle password usando l'implementazione a fasi, seguire le istruzioni preliminari illustrate nella sezione successiva.

Per informazioni sui cmdlet PowerShell da usare, vedere Anteprima di Azure AD 2.0.

Istruzioni preliminari per la sincronizzazione dell'hash delle password

  1. Abilitare la sincronizzazione dell'hash delle password dalla pagina Funzionalità facoltative in Azure AD Connessione.

    Screenshot della pagina "Funzionalità facoltative" in Azure Active Directory Connect

  2. Verificare che sia stato eseguito un ciclo completo di sincronizzazione dell'hash delle password in modo che tutti gli hash delle password degli utenti siano stati sincronizzati con Azure AD. Per controllare lo stato di sincronizzazione dell'hash delle password, è possibile usare la diagnostica di PowerShell descritta in Risolvere i problemi di sincronizzazione degli hash delle password con la sincronizzazione Azure AD Connect.

    Screenshot del log di risoluzione dei problemi di Azure AD Connect

Se si vuole testare l'accesso tramite autenticazione pass-through usando l'implementazione a fasi, abilitare la funzionalità seguendo le istruzioni preliminari illustrate nella sezione successiva.

Istruzioni preliminari per l'autenticazione pass-through

  1. Identificare un server che esegue Windows Server 2012 R2 o versione successiva in cui si vuole eseguire l'autenticazione l'agente di autenticazione pass-through.

    Non scegliere il server di Azure AD Connect.  Verificare che il server sia aggiunto a un dominio, possa autenticare gli utenti selezionati con Active Directory e possa comunicare con Azure AD sulle porte e sugli URL in uscita. Per altre informazioni, vedere la sezione Passaggio 1: Verificare i prerequisiti in Avvio rapido: Accesso Single Sign-On facile di Azure AD.

  2. Scaricare l'agente di autenticazione di Azure AD Connect e installarlo nel server.

  3. Per abilitare la disponibilità elevata,installare agenti di autenticazione aggiuntivi in altri server.

  4. Assicurarsi di aver configurato le impostazione di blocco intelligente in modo appropriato. In questo modo è possibile assicurarsi che gli account Active Directory locali degli utenti non vengano bloccati da utenti malintenzionati.

È consigliabile abilitare l'accesso Single Sign-On facile indipendentemente dal metodo di accesso (sincronizzazione dell'hash delle password o autenticazione pass-through) selezionato per l'implementazione a fasi. Per abilitare l'accesso Single Sign-On facile, seguire le istruzioni preliminari illustrate nella sezione successiva.

Istruzioni preliminari per l'accesso Single Sign-On facile

Abilitare l'accesso Single Sign-On facile nelle foreste Active Directory usando PowerShell. Se si dispone di più di una foresta Active Directory, abilitarla singolarmente per ogni foresta. L'accesso Single Sign-On facile viene attivato solo per gli utenti selezionati per l'implementazione a fasi. Non condiziona la configurazione della federazione esistente.

Abilitare l'accesso Single Sign-On facile eseguendo le operazioni seguenti:

  1. Accedere al server di Azure AD Connect.

  2. Passare alla cartella %programfiles% \ Microsoft Azure Active Directory Connessione.

  3. Importare il modulo PowerShell dell'accesso Single Sign-On facile eseguendo il comando seguente:

    Import-Module .\AzureADSSO.psd1

  4. Eseguire PowerShell come amministratore. In PowerShell eseguire la chiamata a New-AzureADSSOAuthenticationContext. Il comando apre un riquadro in cui è possibile immettere le credenziali dell'amministratore globale del tenant.

  5. Chiamare Get-AzureADSSOStatus | ConvertFrom-Json. Questo comando visualizza un elenco di foreste di Active Directory (vedere l'elenco "Domini") in cui è stata abilitata questa funzionalità. Il valore predefinito a livello di tenant è false.

    Esempio di output di Windows PowerShell

  6. Chiamare $creds = Get-Credential. Al prompt dei comandi, immettere le credenziali dell'amministratore di dominio per la foresta di Active Directory da usare.

  7. Chiamare Enable-AzureADSSOForest -OnPremCredentials $creds. Questo comando crea l'account computer AZUREADSSOACC dal controller di dominio locale per la foresta di Active Directory necessaria per l'accesso Single Sign-On facile.

  8. Per l'accesso Single Sign-On facile è necessario che gli URL siano nell'area Intranet. Per distribuire tali URL usando i criteri di gruppo, vedere Avvio rapido: Accesso Single Sign-On facile di Azure AD.

  9. Per una procedura dettagliata completa, è anche possibile scaricare i piani di distribuzione per l'accesso Single Sign-On facile.

Abilitare l'implementazione a fasi

Per implementare una funzionalità specifica (autenticazione pass-through, sincronizzazione dell'hash delle password o accesso Single Sign-On facile) per una serie di utenti in un gruppo, seguire le istruzioni illustrate nelle sezioni successive.

Abilitare un'implementazione a fasi di una funzionalità specifica nel tenant

È possibile implementare una delle opzioni seguenti:

  • Opzione A - sincronizzazione dell'hash delle password + accesso Single Sign-On facile
  • Opzione B - autenticazione pass-through + accesso Single Sign-On facile (SSO)
  • Non supportato - sincronizzazione dell'hash delle password + autenticazione pass-through + accesso Single Sign-On facile

Eseguire le operazioni seguenti:

  1. Per accedere all'esperienza utente, accedere al portale Azure AD .

  2. Selezionare il collegamento Abilita implementazione a fasi per l'accesso utente gestito.

    Ad esempio, se si vuole abilitare l'opzione A, scorrere i controlli Sincronizzazione hash password e Accesso Single Sign-On facile su On, come illustrato nelle immagini seguenti.

  3. Aggiungere i gruppi alla funzionalità per abilitare l'autenticazione pass-through e l'accesso Single Sign-On facile. Per evitare un timeout dell'esperienza utente, assicurarsi che i gruppi di sicurezza non contengano inizialmente più di 200 membri.

    Nota

    I membri di un gruppo vengono automaticamente abilitati per l'implementazione a fasi. I gruppi annidati e dinamici non sono supportati per l'implementazione a fasi. Quando si aggiunge un nuovo gruppo, gli utenti del gruppo (fino a 200 utenti per un nuovo gruppo) verranno aggiornati per usare immediatamente l'autenticazione gestita. La modifica di un gruppo (aggiunta o rimozione di utenti) può richiedere fino a 24 ore per l'applicazione delle modifiche. L'accesso Single Sign-On facile verrà applicato solo se gli utenti sono nel gruppo Seamless SSO e anche in un gruppo PTA o PHS.

Controllo

Sono stati abilitati gli eventi di controllo per le varie azioni eseguite per l'implementazione a fasi:

  • Evento di controllo durante l'abilitazione dell'implementazione a fasi per sincronizzazione dell'hash delle password, autenticazione pass-through o accesso Single Sign-On facile.

    Nota

    Un evento di controllo viene registrato quando si attiva l'accesso Single Sign-On facile tramite l'implementazione a fasi.

    Riquadro "Create rollout policy for feature" (Crea criteri di implementazione per la funzionalità) nella scheda Attività

    Riquadro "Create rollout policy for feature" (Crea criteri di implementazione per la funzionalità) nella scheda Proprietà modificate

  • Evento di controllo durante l'aggiunta di un gruppo alla sincronizzazione dell'hash delle password, all'autenticazione pass-through o all'accesso Single Sign-On facile.

    Nota

    Un evento di controllo viene registrato quando un gruppo viene aggiunto alla sincronizzazione dell'hash delle password per l'implementazione a fasi.

    Riquadro "Add a group to feature rollout" (Aggiungi un gruppo all'implementazione della funzionalità) nella scheda Attività

    Riquadro "Add a group to feature rollout" (Aggiungi un gruppo all'implementazione della funzionalità) nella scheda Proprietà modificate

  • Evento di controllo durante l'abilitazione a fasi per un utente che è stato aggiunto a un gruppo.

    Riquadro "Add user to feature rollout" (Aggiungi utente all'implementazione della funzionalità) nella scheda Attività

    Riquadro "Add user to feature rollout" (Aggiungi utente all'implementazione della funzionalità) nella scheda Destinazione/i

Convalida

Per testare l'accesso tramite sincronizzazione dell'hash delle password o autenticazione pass-through (accesso tramite nome utente e password), seguire questa procedura:

  1. Nella Extranet andare alla pagina App in una sessione privata del browser, quindi immettere il valore UserPrincipalName (UPN) dell'account utente selezionato per l'implementazione a fasi.

    Gli utenti selezionati per l'implementazione a fasi non vengono reindirizzati alla pagina di accesso federato. A loro viene invece chiesto di accedere alla pagina di accesso di personalizzazione del tenant di Azure AD.

  2. Verificare che l'accesso venga visualizzato nel report delle attività di accesso di Azure AD, usando UserPrincipalName come filtro.

Per verificare l'accesso tramite accesso Single Sign-On facile:

  1. Nella Intranet andare alla pagina App in una sessione privata del browser, quindi immettere il valore UserPrincipalName (UPN) dell'account utente selezionato per l'implementazione a fasi.

    Gli utenti selezionati per l'implementazione a fase dell'accesso Single Sign-on facile visualizzano il messaggio "Tentativo di accesso per conto dell'utente" prima di accedere automaticamente.

  2. Verificare che l'accesso venga visualizzato nel report delle attività di accesso di Azure AD, usando UserPrincipalName come filtro.

    Per tenere traccia degli accessi utente eseguiti ancora in Active Directory Federation Services (AD FS) per gli utenti selezionati per l'implementazione a fasi, seguire le istruzioni riportate in Risoluzione dei problemi di AD FS: eventi e registrazione. Vedere la documentazione del fornitore per informazioni su come eseguire il controllo in provider di federazione di terze parti.

Monitoraggio

È possibile monitorare gli utenti e i gruppi aggiunti o rimossi dall'implementazione a fasi e dagli accesso degli utenti durante l'implementazione a fasi, usando le nuove cartelle di lavoro di autenticazione ibrida nel portale di Azure.

Cartelle di lavoro di Autenticazione ibrida

Rimuovere un utente dall'implementazione a fasi

La rimozione di un utente dal gruppo disabilita l'implementazione a fasi per tale utente. Per disabilitare la funzionalità di implementazione a fasi, riportare il controllo su Off.

Domande frequenti

D: È possibile usare questa funzionalità in un tenant di produzione?

A: Sì, è possibile usare questa funzionalità nel tenant di produzione, ma è consigliabile provare prima di tutto nel tenant di test.

D: È possibile usare questa funzionalità per gestire una "coesistenza permanente", in cui alcuni utenti usano l'autenticazione federata e altri usano l'autenticazione cloud?

A: No, questa funzionalità è progettata per testare l'autenticazione cloud. Dopo aver eseguito correttamente il test di alcuni gruppi di utenti, è consigliabile eseguire il cut over all'autenticazione cloud. Non è consigliabile usare uno stato misto permanente, poiché questo approccio potrebbe generare flussi di autenticazione imprevisti.

D: È possibile usare PowerShell per eseguire l'implementazione a fasi?

A: Sì. Per informazioni su come usare PowerShell per eseguire l'implementazione a fasi, vedere Anteprima di Azure AD.

Passaggi successivi