Migrazione del server MFA
Questo argomento illustra come eseguire la migrazione delle impostazioni MFA per gli utenti di Microsoft Entra dal server Azure MFA locale all'autenticazione a più fattori Di Microsoft Entra.
Panoramica della soluzione
L'Utilità migrazione server MFA consente di sincronizzare i dati di autenticazione a più fattori archiviati nel server Azure MFA locale direttamente con l'autenticazione a più fattori Di Microsoft Entra. Dopo la migrazione dei dati di autenticazione a Microsoft Entra ID, gli utenti possono eseguire senza problemi mfa basati sul cloud senza dover eseguire di nuovo la registrazione o confermare i metodi di autenticazione. Amministrazione possono usare l'Utilità migrazione server MFA per definire come destinazione singoli utenti o gruppi di utenti per testare e controllare l'implementazione senza dover apportare modifiche a livello di tenant.
Video: Come usare l'utilità di migrazione server MFA
Guardare il video per una panoramica di MFA Server Migration Utility e del relativo funzionamento.
Limitazioni e requisiti
L'Utilità migrazione server MFA richiede l'installazione di una nuova build della soluzione server MFA nel server MFA primario. La compilazione apporta aggiornamenti al file di dati del server MFA e include la nuova Utilità migrazione server MFA. Non è necessario aggiornare WebSDK o il portale utenti. L'installazione dell'aggiornamento non avvia automaticamente la migrazione.
Nota
L'Utilità migrazione server MFA può essere eseguita in un server MFA secondario. Per altre informazioni, vedere Eseguire un server MFA secondario (facoltativo).
L'Utilità migrazione server MFA copia i dati dal file di database negli oggetti utente in Microsoft Entra ID. Durante la migrazione, gli utenti possono essere destinati all'autenticazione a più fattori Di Microsoft Entra a scopo di test tramite l'implementazione a fasi. La migrazione a fasi consente di eseguire test senza apportare modifiche alle impostazioni di federazione del dominio. Al termine delle migrazioni, è necessario finalizzare la migrazione apportando modifiche alle impostazioni di federazione del dominio.
AD FS che esegue Windows Server 2016 o versione successiva è necessario per fornire l'autenticazione MFA su qualsiasi relying party di AD FS, non incluso Microsoft Entra ID e Office 365.
Esaminare i criteri di controllo di accesso di AD FS e assicurarsi che nessuno richieda l'autenticazione a più fattori sia eseguita in locale come parte del processo di autenticazione.
L'implementazione a fasi può essere destinato a un massimo di 500.000 utenti (10 gruppi contenenti un massimo di 50.000 utenti ciascuno).
Guida alla migrazione
Una migrazione del server MFA include in genere i passaggi del processo seguente:
Tenere presente le seguenti considerazioni importanti:
La fase 1 deve essere ripetuta quando si aggiungono utenti di test.
- Lo strumento di migrazione usa i gruppi di Microsoft Entra per determinare gli utenti per i quali i dati di autenticazione devono essere sincronizzati tra il server MFA e l'autenticazione a più fattori Di Microsoft Entra. Dopo la sincronizzazione dei dati utente, l'utente è pronto per l'uso dell'autenticazione a più fattori Di Microsoft Entra.
- L'implementazione a fasi consente di reindirizzare gli utenti all'autenticazione a più fattori Di Microsoft Entra, usando anche i gruppi di Microsoft Entra. Sebbene sia possibile usare gli stessi gruppi per entrambi gli strumenti, è consigliabile usarli perché gli utenti potrebbero potenzialmente essere reindirizzati all'autenticazione a più fattori Di Microsoft Entra prima che lo strumento abbia sincronizzato i dati. È consigliabile configurare i gruppi di Microsoft Entra per la sincronizzazione dei dati di autenticazione da parte dell'Utilità migrazione server MFA e un altro set di gruppi per l'implementazione a fasi per indirizzare gli utenti di destinazione all'autenticazione a più fattori Di Microsoft Entra anziché in locale.
La fase 2 deve essere ripetuta durante la migrazione della base utente. Alla fine della fase 2, l'intera base utente deve usare l'autenticazione a più fattori Di Microsoft Entra per tutti i carichi di lavoro federati con Microsoft Entra ID.
Durante le fasi precedenti, è possibile rimuovere gli utenti dalle cartelle di implementazione a fasi per rimuoverli dall'ambito dell'autenticazione a più fattori Di Microsoft Entra e indirizzarli al server Azure MFA locale per tutte le richieste MFA provenienti da Microsoft Entra ID.
La fase 3 richiede lo spostamento di tutti i client che eseguono l'autenticazione nel server MFA locale (VPN, gestione password e così via) nella federazione di Microsoft Entra tramite SAML/OAUTH. Se gli standard di autenticazione moderni non sono supportati, è necessario configurare i server NPS con l'estensione di autenticazione a più fattori Microsoft Entra installata. Dopo la migrazione delle dipendenze, gli utenti non devono più usare il portale utenti nel server MFA, ma devono gestire i metodi di autenticazione in Microsoft Entra ID (aka.ms/mfasetup). Quando gli utenti iniziano a gestire i dati di autenticazione in Microsoft Entra ID, questi metodi non verranno sincronizzati con il server MFA. Se si esegue il rollback al server MFA locale dopo che gli utenti hanno apportato modifiche ai metodi di autenticazione in Microsoft Entra ID, tali modifiche andranno perse. Al termine delle migrazioni utente, modificare l'impostazione federatedIdpMfaBehavior domain federation. La modifica indica a Microsoft Entra ID di non eseguire più MFA in locale e di eseguire tutte le richieste MFA con l'autenticazione a più fattori Di Microsoft Entra, indipendentemente dall'appartenenza al gruppo.
Le sezioni seguenti illustrano i passaggi di migrazione in modo più dettagliato.
Identificare le dipendenze del server Azure Multi-Factor Authentication
Abbiamo lavorato duramente per garantire che il passaggio alla soluzione di autenticazione a più fattori Microsoft Entra basata sul cloud manterrà e migliora anche il comportamento di sicurezza. Esistono tre categorie generali da usare per raggruppare le dipendenze:
Per facilitare la migrazione, sono stati confrontate le funzionalità del server MFA ampiamente usate con l'equivalente funzionale nell'autenticazione a più fattori Di Microsoft Entra per ogni categoria.
Metodi MFA
Aprire il server MFA, fare clic su Impostazioni aziendale:
Server MFA | Autenticazione a più fattori Microsoft Entra |
---|---|
Scheda Generale | |
Sezione Impostazioni predefinite utente | |
Telefono chiamata (Standard) | Non è richiesta alcuna azione |
Sms (OTP)* | Non è richiesta alcuna azione |
App per dispositivi mobili (Standard) | Non è richiesta alcuna azione |
Telefono Chiamata (PIN)* | Abilitare OTP vocale |
SMS (OTP + PIN)** | Non è richiesta alcuna azione |
App per dispositivi mobili (PIN)* | Abilitare la corrispondenza dei numeri |
Telefono lingua del token call/sms/app per dispositivi mobili/OATH | Le impostazioni della lingua verranno applicate automaticamente a un utente in base alle impostazioni locali nel browser |
Sezione Regole PIN predefinite | Non applicabile; vedere i metodi aggiornati nello screenshot precedente |
Scheda Risoluzione nome utente | Non applicabile; La risoluzione del nome utente non è necessaria per l'autenticazione a più fattori Di Microsoft Entra |
Scheda Sms | Non applicabile; L'autenticazione a più fattori Microsoft Entra usa un messaggio predefinito per i messaggi di testo |
Scheda Token OATH | Non applicabile; L'autenticazione a più fattori Microsoft Entra usa un messaggio predefinito per i token OATH |
Report | Report sulle attività dei metodi di autenticazione di Microsoft Entra |
*Quando viene usato un PIN per fornire funzionalità di verifica della presenza, l'equivalente funzionale viene fornito in precedenza. I PIN che non sono collegati a livello crittografico a un dispositivo non proteggono sufficientemente da scenari in cui un dispositivo è stato compromesso. Per proteggersi da questi scenari, inclusi gli attacchi di scambio SIM, spostare gli utenti in metodi più sicuri in base alle procedure consigliate per i metodi di autenticazione Microsoft.
**L'esperienza MFA text predefinita nell'autenticazione a più fattori Microsoft Entra invia agli utenti un codice, che è necessario immettere nella finestra di accesso come parte dell'autenticazione. Il requisito di eseguire il round trip del codice fornisce funzionalità di verifica della presenza.
Portale utenti
Aprire il server MFA, fare clic su Portale utenti:
Server MFA | Autenticazione a più fattori Microsoft Entra |
---|---|
scheda Impostazioni | |
URL del portale utenti | aka.ms/mfasetup |
Consenti registrazione utente | Vedere Registrazione combinata delle informazioni di sicurezza |
- Richiedi telefono di backup | Vedere Impostazioni del servizio MFA |
- Richiedi token OATH di terze parti | Vedere Impostazioni del servizio MFA |
Consentire agli utenti di avviare un bypass monouso | Vedere La funzionalità Tap di Microsoft Entra ID |
Consenti agli utenti di selezionare il metodo | Vedere Impostazioni del servizio MFA |
- Telefono chiamata | Vedere la documentazione di Telefono chiamata |
- Sms | Vedere Impostazioni del servizio MFA |
- App per dispositivi mobili | Vedere Impostazioni del servizio MFA |
- Token OATH | Vedere la documentazione del token OATH |
Consenti agli utenti di selezionare la lingua | Le impostazioni della lingua verranno applicate automaticamente a un utente in base alle impostazioni locali nel browser |
Consenti agli utenti di attivare l'app mobile | Vedere Impostazioni del servizio MFA |
- Limite di dispositivi | Microsoft Entra ID limita gli utenti a cinque dispositivi cumulativi (istanze di app per dispositivi mobili + token OATH hardware + token OATH software) per utente |
Usa domande di sicurezza per il fallback | Microsoft Entra ID consente agli utenti di scegliere un metodo di fallback in fase di autenticazione in caso di esito negativo del metodo di autenticazione scelto |
- Domande a cui rispondere | Le domande di sicurezza in Microsoft Entra ID possono essere usate solo per la reimpostazione della password self-service. Per altre informazioni, vedere Domande sulla sicurezza personalizzata di Microsoft Entra |
Consenti agli utenti di associare token OATH di terze parti | Vedere la documentazione del token OATH |
Usa token OATH per fallback | Vedere la documentazione del token OATH |
Timeout sessione | |
Scheda Domande di sicurezza | Le domande di sicurezza nel server MFA sono state usate per ottenere l'accesso al portale utenti. L'autenticazione a più fattori Microsoft Entra supporta solo domande di sicurezza per la reimpostazione della password self-service. Vedere la documentazione relativa alle domande di sicurezza. |
Scheda Sessioni passate | Tutti i flussi di registrazione del metodo di autenticazione vengono gestiti da Microsoft Entra ID e non richiedono la configurazione |
Indirizzi IP attendibili | Indirizzi IP attendibili di Microsoft Entra ID |
Tutti i metodi MFA disponibili nel server MFA devono essere abilitati nell'autenticazione a più fattori di Microsoft Entra usando le impostazioni del servizio MFA. Gli utenti non possono provare i metodi MFA appena migrati a meno che non siano abilitati.
Servizi di autenticazione
Il server Azure MFA può fornire funzionalità di autenticazione a più fattori per soluzioni di terze parti che usano RADIUS o LDAP fungendo da proxy di autenticazione. Per individuare le dipendenze RADIUS o LDAP, fare clic su Autenticazione RADIUS e opzioni di autenticazione LDAP nel server MFA. Per ognuna di queste dipendenze, determinare se queste terze parti supportano l'autenticazione moderna. In tal caso, prendere in considerazione la federazione direttamente con Microsoft Entra ID.
Per le distribuzioni RADIUS che non possono essere aggiornate, è necessario distribuire un server dei criteri di rete e installare l'estensione Server dei criteri di rete microsoft Entra per l'autenticazione a più fattori.
Per le distribuzioni LDAP che non possono essere aggiornate o spostate in RADIUS, determinare se è possibile usare Microsoft Entra Domain Services. Nella maggior parte dei casi, LDAP è stato distribuito per supportare le modifiche delle password in linea per gli utenti finali. Dopo la migrazione, gli utenti finali possono gestire le password usando la reimpostazione della password self-service in Microsoft Entra ID.
Se è stato abilitato il provider di autenticazione server MFA in AD FS 2.0 in qualsiasi trust della relying party, ad eccezione del trust della relying party di Office 365, sarà necessario eseguire l'aggiornamento ad AD FS 3.0 o federate tali relying party direttamente all'ID Microsoft Entra se supportano metodi di autenticazione moderni. Determinare il piano di azione migliore per ognuna delle dipendenze.
Eseguire il backup del file di dati del server Azure Multi-Factor Authentication
Eseguire un backup del file di dati del server MFA che si trova in %programfiles%\Multi-Factor Authentication Server\Data\Telefono Factor.pfdata (percorso predefinito) nel server MFA primario. Assicurarsi di avere una copia del programma di installazione per la versione attualmente installata nel caso in cui sia necessario eseguire il rollback. Se non si ha più una copia, contattare il servizio supporto tecnico clienti.
A seconda dell'attività dell'utente, il file di dati può diventare obsoleto rapidamente. Eventuali modifiche apportate al server MFA o a qualsiasi modifica apportata dall'utente finale tramite il portale dopo l'acquisizione del backup. Se si esegue il rollback, eventuali modifiche apportate dopo questo punto non verranno ripristinate.
Installare l'aggiornamento del server MFA
Eseguire il nuovo programma di installazione nel server MFA primario. Prima di aggiornare un server, rimuoverlo dal bilanciamento del carico o dalla condivisione del traffico con altri server MFA. Non è necessario disinstallare il server MFA corrente prima di eseguire il programma di installazione. Il programma di installazione esegue un aggiornamento sul posto usando il percorso di installazione corrente, ad esempio C:\Programmi\Server Multi-Factor Authentication. Se viene chiesto di installare un pacchetto di aggiornamento di Microsoft Visual C++ 2015 Redistributable, accettare la richiesta. Entrambe le versioni, x86 e x64, del pacchetto vengono installate. Non è necessario installare gli aggiornamenti per il portale utenti, l'SDK Web o l'adapter AD FS.
Nota
Dopo aver eseguito il programma di installazione nel server primario, i server secondari possono iniziare a registrare voci sb non gestite . Ciò è dovuto alle modifiche apportate allo schema nel server primario che non verranno riconosciute dai server secondari. Questi errori sono previsti. Negli ambienti con 10.000 utenti o più, la quantità di voci di log può aumentare significativamente. Per attenuare questo problema, è possibile aumentare le dimensioni del file dei log del server MFA o aggiornare i server secondari.
Configurare l'utilità di migrazione del server MFA
Dopo aver installato l'aggiornamento del server MFA, aprire un prompt dei comandi di PowerShell con privilegi elevati: passare il puntatore del mouse sull'icona di PowerShell, fare clic con il pulsante destro del mouse e scegliere Esegui come Amministrazione istrator. Eseguire lo script .\Configure-MultiFactorAuthMigrationUtility.ps1 disponibile nella directory di installazione del server MFA (C:\Programmi\Server Multi-Factor Authentication per impostazione predefinita).
Questo script richiederà di fornire le credenziali per un application Amministrazione istrator nel tenant di Microsoft Entra. Lo script creerà quindi una nuova applicazione MFA Server Migration Utility all'interno di Microsoft Entra ID, che verrà usata per scrivere metodi di autenticazione utente in ogni oggetto utente Microsoft Entra.
Per i clienti cloud per enti pubblici che desiderano eseguire le migrazioni, sostituire le voci ".com" nello script con ".us". Questo script scriverà quindi le voci del Registro di sistema HKLM:\SOFTWARE\WOW6432Node\Positive Networks\Telefono Factor\ StsUrl e GraphUrl e indicare a Utilità di migrazione di usare gli endpoint GRAPH appropriati.
Sarà anche necessario accedere agli URL seguenti:
https://graph.microsoft.com/*
(ohttps://graph.microsoft.us/*
per i clienti cloud per enti pubblici)https://login.microsoftonline.com/*
(ohttps://login.microsoftonline.us/*
per i clienti cloud per enti pubblici)
Lo script indicherà di concedere il consenso amministratore all'applicazione appena creata. Passare all'URL fornito o all'interno dell'interfaccia di amministrazione di Microsoft Entra, fare clic su Registrazioni applicazione, trovare e selezionare l'app Utilità migrazione server MFA, fare clic su Autorizzazioni API e quindi concedere le autorizzazioni appropriate.
Al termine, passare alla cartella Server Multi-Factor Authentication e aprire l'applicazione MultiFactorAuthMigrationUtilityUI . Verrà visualizzata la schermata seguente:
L'utilità di migrazione è stata installata correttamente.
Nota
Per assicurarsi che non vengano apportate modifiche al comportamento durante la migrazione, se il server MFA è associato a un provider MFA senza riferimenti al tenant, è necessario aggiornare le impostazioni di autenticazione a più fattori predefinite (ad esempio messaggi di saluto personalizzati) per il tenant di cui si sta eseguendo la migrazione in modo che corrisponda alle impostazioni nel provider MFA. È consigliabile eseguire questa operazione prima di eseguire la migrazione di tutti gli utenti.
Eseguire un server MFA secondario (facoltativo)
Se l'implementazione del server MFA ha un numero elevato di utenti o un server MFA primario occupato, è consigliabile valutare la possibilità di distribuire un server MFA secondario dedicato per l'esecuzione di MFA Server Migration Utility e dei servizi di sincronizzazione migrazione. Dopo l'aggiornamento del server MFA primario, aggiornare un server secondario esistente o distribuire un nuovo server secondario. Il server secondario scelto non deve gestire altro traffico MFA.
Lo script Configure-MultiFactorAuthMigrationUtility.ps1 deve essere eseguito nel server secondario per registrare un certificato con la registrazione dell'app Utilità migrazione server MFA. Il certificato viene usato per eseguire l'autenticazione a Microsoft Graph. L'esecuzione dei servizi utilità di migrazione e sincronizzazione in un server MFA secondario deve migliorare le prestazioni delle migrazioni utente manuali e automatizzate.
Eseguire la migrazione dei dati utente
La migrazione dei dati utente non rimuove o modifica i dati nel database del server Multi-Factor Authentication. Analogamente, questo processo non cambierà la posizione in cui un utente esegue l'autenticazione a più fattori. Questo processo è una copia unidirezionale dei dati dal server locale all'oggetto utente corrispondente in Microsoft Entra ID.
L'utilità Migrazione server MFA è destinata a un singolo gruppo Microsoft Entra per tutte le attività di migrazione. È possibile aggiungere utenti direttamente a questo gruppo o aggiungere altri gruppi. È anche possibile aggiungerli in fasi durante la migrazione.
Per avviare il processo di migrazione, immettere il nome o il GUID del gruppo Microsoft Entra di cui si vuole eseguire la migrazione. Al termine, premere TAB o fare clic all'esterno della finestra per iniziare a cercare il gruppo appropriato. Tutti gli utenti del gruppo vengono popolati. Il completamento di un gruppo di grandi dimensioni può richiedere alcuni minuti.
Per visualizzare i dati degli attributi per un utente, evidenziare l'utente e selezionare Visualizza:
In questa finestra vengono visualizzati gli attributi per l'utente selezionato sia in Microsoft Entra ID che nel server MFA locale. È possibile usare questa finestra per visualizzare il modo in cui i dati sono stati scritti in un utente dopo la migrazione.
L'opzione Impostazioni consente di modificare le impostazioni per il processo di migrazione:
Eseguire la migrazione: sono disponibili tre opzioni per la migrazione del metodo di autenticazione predefinito dell'utente:
- Eseguire sempre la migrazione
- Eseguire la migrazione solo se non è già impostato in Microsoft Entra ID
- Impostare sul metodo più sicuro disponibile se non è già impostato in Microsoft Entra ID
Queste opzioni offrono flessibilità quando si esegue la migrazione del metodo predefinito. Inoltre, i criteri dei metodi di autenticazione vengono controllati durante la migrazione. Se il metodo predefinito di cui viene eseguita la migrazione non è consentito dai criteri, viene impostato sul metodo più sicuro disponibile.
Corrispondenza utente: consente di specificare un attributo di Active Directory locale diverso per la corrispondenza di Microsoft Entra UPN anziché la corrispondenza predefinita con userPrincipalName:
- L'utilità di migrazione tenta di eseguire la corrispondenza diretta con l'UPN prima di usare l'attributo Active Directory locale.
- Se non viene trovata alcuna corrispondenza, chiama un'API Windows per trovare l'UPN di Microsoft Entra e ottenere il SID, che usa per cercare l'elenco utenti del server MFA.
- Se l'API Windows non trova l'utente o il SID non viene trovato nel server MFA, userà l'attributo di Active Directory configurato per trovare l'utente nella Active Directory locale e quindi usare il SID per cercare l'elenco utenti del server MFA.
Sincronizzazione automatica: avvia un servizio in background che monitora continuamente le modifiche apportate ai metodi di autenticazione agli utenti nel server MFA locale e li scrive in Microsoft Entra ID in corrispondenza dell'intervallo di tempo specificato.
Server di sincronizzazione: consente l'esecuzione del servizio Di sincronizzazione migrazione server MFA in un server MFA secondario anziché solo su quello primario. Per configurare il servizio di sincronizzazione migrazione per l'esecuzione in un server secondario, è necessario eseguire lo
Configure-MultiFactorAuthMigrationUtility.ps1
script nel server per registrare un certificato con la registrazione dell'app MFA Server Migration Utility. Il certificato viene usato per eseguire l'autenticazione a Microsoft Graph.
Il processo di migrazione può essere automatico o manuale.
I passaggi del processo manuale sono:
Per avviare il processo di migrazione per un utente o una selezione di più utenti, premere e tenere premuto CTRL durante la selezione di ognuno degli utenti di cui si vuole eseguire la migrazione.
Dopo aver selezionato gli utenti desiderati, fare clic su Esegui migrazione utenti>>selezionati OK.
Per eseguire la migrazione di tutti gli utenti nel gruppo, fare clic su Migrate Users All users>in Microsoft Entra group OK(Esegui migrazione di tutti gli utenti nel gruppo>Microsoft Entra).
È possibile eseguire la migrazione degli utenti anche se non sono modificati. Per impostazione predefinita, l'utilità è impostata su Solo gli utenti che sono stati modificati. Fare clic su Migrate all users to re-migrated users that are unchanged (Esegui migrazione di tutti gli utenti per eseguire nuovamente la migrazione degli utenti migrati in precedenza non modificati). La migrazione di utenti non modificati può essere utile durante i test se un amministratore deve reimpostare le impostazioni di Azure MFA di un utente e vuole eseguirne nuovamente la migrazione.
Per il processo automatico, fare clic su Sincronizzazione automatica in Impostazioni, quindi selezionare se si desidera che tutti gli utenti vengano sincronizzati o solo i membri di un determinato gruppo Microsoft Entra.
La tabella seguente elenca la logica di sincronizzazione per i vari metodi.
metodo | Logica |
---|---|
Telefono | Se non è presente alcuna estensione, aggiornare il telefono MFA. Se è presente un'estensione, aggiornare il telefono di Office. Eccezione: se il metodo predefinito è Sms, eliminare l'estensione e aggiornare il telefono MFA. |
Telefono di backup | Se non è presente alcuna estensione, aggiornare il telefono alternativo. Se è presente un'estensione, aggiornare il telefono di Office. Eccezione: se sia Telefono che backup Telefono hanno un'estensione, ignorare Telefono di backup. |
App per dispositivi mobili | La migrazione massima di cinque dispositivi verrà eseguita o solo quattro se l'utente dispone anche di un token OATH hardware. Se sono presenti più dispositivi con lo stesso nome, eseguire solo la migrazione di quella più recente. I dispositivi verranno ordinati dal più recente al meno recente. Se i dispositivi esistono già in Microsoft Entra ID, trovare la corrispondenza con la chiave privata del token OATH e aggiornare. - Se non esiste alcuna corrispondenza nella chiave privata del token OATH, trova la corrispondenza nel token del dispositivo -- Se trovato, creare un token OATH software per il dispositivo server MFA per consentire il funzionamento del metodo token OATH. Le notifiche continueranno a funzionare usando il dispositivo di autenticazione a più fattori Microsoft Entra esistente. - Se non viene trovato, creare un nuovo dispositivo. Se l'aggiunta di un nuovo dispositivo supererà il limite di cinque dispositivi, il dispositivo verrà ignorato. |
OATH Token | Se i dispositivi esistono già in Microsoft Entra ID, trovare la corrispondenza con la chiave privata del token OATH e aggiornare. - Se non viene trovato, aggiungere un nuovo dispositivo token OATH hardware. Se l'aggiunta di un nuovo dispositivo supererà il limite di cinque dispositivi, il token OATH verrà ignorato. |
I metodi MFA verranno aggiornati in base a ciò che è stato migrato e il metodo predefinito verrà impostato. Il server MFA tiene traccia del timestamp dell'ultima migrazione ed eseguirà di nuovo la migrazione dell'utente solo se le impostazioni MFA dell'utente cambiano o un amministratore modifica gli elementi di cui eseguire la migrazione nella finestra di dialogo Impostazioni.
Durante i test, è consigliabile eseguire prima una migrazione manuale e testare per assicurarsi che un determinato numero di utenti si comporti come previsto. Al termine del test, attivare la sincronizzazione automatica per il gruppo Microsoft Entra di cui si vuole eseguire la migrazione. Quando si aggiungono utenti a questo gruppo, le informazioni verranno sincronizzate automaticamente con Microsoft Entra ID. Utilità migrazione server MFA è destinata a un gruppo Microsoft Entra, ma tale gruppo può includere sia utenti che gruppi annidati di utenti.
Al termine, una conferma informerà le attività completate:
Come indicato nel messaggio di conferma, la visualizzazione dei dati migrati negli oggetti utente all'interno di Microsoft Entra ID può richiedere alcuni minuti. Gli utenti possono visualizzare i metodi migrati passando a aka.ms/mfasetup.
Suggerimento
È possibile ridurre il tempo necessario per visualizzare i gruppi se non è necessario visualizzare i metodi MFA di Microsoft Entra. Fare clic su Visualizza>metodi di Azure AD MFA per attivare o disattivare la visualizzazione delle colonne per AAD Default, AAD Telefono, AAD Alternate, AAD Office, AAD Devices e AAD OATH Token. Quando le colonne sono nascoste, alcune chiamate API Microsoft Graph vengono ignorate, migliorando notevolmente il tempo di caricamento dell'utente.
Visualizzare i dettagli della migrazione
È possibile usare i log di controllo o Log Analytics per visualizzare i dettagli delle migrazioni utente da MFA Server ad Azure MFA.
Usare i log di controllo
Per accedere ai log di controllo nell'interfaccia di amministrazione di Microsoft Entra per visualizzare i dettagli delle migrazioni utente da MFA Server ad Azure MFA, seguire questa procedura:
Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un Amministrazione istrator di autenticazione.
Passare a Identity Monitoring & health Audit logs (Log di controllo dell'integrità>e monitoraggio delle identità).> Per filtrare i log, fare clic su Aggiungi filtri.
Selezionare Avviato da (attore) e fare clic su Applica.
Digitare Gestione MFA di Azure e fare clic su Applica.
Questo filtro visualizza solo i log di Utilità migrazione server MFA. Per visualizzare i dettagli per una migrazione utente, fare clic su una riga e quindi scegliere la scheda Proprietà modificate. Questa scheda mostra le modifiche apportate ai metodi di autenticazione a più fattori registrati e ai numeri di telefono.
La tabella seguente elenca il metodo di autenticazione per ogni codice.
Codice metodo 0 Dispositivi mobili vocali 2 Segreteria telefonica 3 Dispositivi mobili alternativi vocali 5 SMS 6 Notifica push di Microsoft Authenticator 7 OTP per token hardware o software Se è stata eseguita la migrazione di dispositivi utente, è presente una voce di log separata.
Usare Log Analytics
È anche possibile eseguire query sui dettagli delle migrazioni utente da server MFA ad Azure MFA usando Log Analytics.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc
Questo screenshot mostra le modifiche per la migrazione degli utenti:
Questo screenshot mostra le modifiche per la migrazione dei dispositivi:
Log Analytics può essere usato anche per riepilogare l'attività di migrazione degli utenti.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
Convalidare e testare
Dopo aver eseguito la migrazione dei dati utente, è possibile convalidare l'esperienza dell'utente finale usando l'implementazione a fasi prima di apportare la modifica del tenant globale. Il processo seguente consentirà di specificare come destinazione gruppi Microsoft Entra per l'implementazione a fasi per MFA. L'implementazione a fasi indica a Microsoft Entra ID di eseguire l'autenticazione a più fattori di Microsoft Entra per gli utenti nei gruppi di destinazione, anziché inviarli in locale per eseguire l'autenticazione a più fattori. È possibile convalidare e testare: è consigliabile usare l'interfaccia di amministrazione di Microsoft Entra, ma se si preferisce, è anche possibile usare Microsoft Graph.
Abilitare l'implementazione a fasi
Passare all'URL seguente: Abilitare le funzionalità di implementazione a fasi - Microsoft Azure.
Modificare l'autenticazione a più fattori di Azure su Sì e quindi fare clic su Gestisci gruppi.
Fare clic su Aggiungi gruppi e aggiungere i gruppi contenenti gli utenti da abilitare per Azure MFA. I gruppi selezionati vengono visualizzati nell'elenco visualizzato.
Nota
Tutti i gruppi di destinazione che usano il metodo Microsoft Graph riportato di seguito verranno visualizzati anche in questo elenco.
Abilitare l'implementazione a fasi con Microsoft Graph
Creare la funzionalitàRolloutPolicy
Passare a aka.ms/ge e accedere a Graph Explorer usando un account di identità ibrida Amministrazione istrator nel tenant che si vuole configurare per l'implementazione a fasi.
Assicurarsi che POST sia selezionato come destinazione per l'endpoint seguente:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies
Il corpo della richiesta deve contenere i seguenti (modificare i criteri di implementazione MFA in un nome e una descrizione per l'organizzazione):
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
Eseguire un'istruzione GET con lo stesso endpoint e prendere nota del valore ID (incrociato nell'immagine seguente):
Scegliere come destinazione i gruppi di Microsoft Entra che contengono gli utenti che si desidera testare
Creare una richiesta POST con l'endpoint seguente (sostituire {ID dei criteri} con il valore ID copiato nel passaggio 1d):
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref
Il corpo della richiesta deve contenere quanto segue (sostituire {ID di gruppo} con l'ID oggetto del gruppo di destinazione per l'implementazione a fasi):
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }
Ripetere i passaggi a e b per qualsiasi altro gruppo di destinazione con implementazione a fasi.
È possibile visualizzare i criteri correnti in uso eseguendo un'operazione GET rispetto all'URL seguente:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo
Il processo precedente usa la risorsa featureRolloutPolicy. La documentazione pubblica non è ancora stata aggiornata con la nuova funzionalità multifactorAuthentication, ma contiene informazioni dettagliate su come interagire con l'API.
Verificare che l'esperienza MFA dell'utente finale. Ecco alcuni aspetti da controllare:
- Gli utenti visualizzano i metodi in aka.ms/mfasetup?
- Gli utenti ricevono telefonate/SMS?
- Sono in grado di eseguire correttamente l'autenticazione usando i metodi precedenti?
- Gli utenti ricevono correttamente le notifiche di Authenticator? Sono in grado di approvare queste notifiche? L'autenticazione ha esito positivo?
- Gli utenti possono eseguire correttamente l'autenticazione usando i token OATH hardware?
Informare gli utenti
Assicurarsi che gli utenti sappiano cosa aspettarsi quando vengono spostati in Azure MFA, inclusi i nuovi flussi di autenticazione. È anche possibile indicare agli utenti di usare il portale di registrazione combinato di Microsoft Entra ID (aka.ms/mfasetup) per gestire i metodi di autenticazione anziché il portale utenti al termine delle migrazioni. Le modifiche apportate ai metodi di autenticazione in Microsoft Entra ID non verranno propagate nuovamente all'ambiente locale. In una situazione in cui è stato necessario eseguire il rollback al server MFA, eventuali modifiche apportate dagli utenti in Microsoft Entra ID non saranno disponibili nel portale utenti del server MFA.
Se si usano soluzioni di terze parti che dipendono dal server Azure MFA per l'autenticazione (vedere Servizi di autenticazione), si vuole che gli utenti continuino a apportare modifiche ai relativi metodi di autenticazione a più fattori nel portale utenti. Queste modifiche verranno sincronizzate automaticamente con Microsoft Entra ID. Dopo aver eseguito la migrazione di queste soluzioni di terze parti, è possibile spostare gli utenti nella pagina di registrazione combinata di Microsoft Entra ID.
Completare la migrazione degli utenti
Ripetere i passaggi di migrazione disponibili nelle sezioni Eseguire la migrazione dei dati utente e Convalidare e testare fino a quando non viene eseguita la migrazione di tutti i dati utente.
Eseguire la migrazione delle dipendenze del server MFA
Usando i punti dati raccolti nei servizi di autenticazione, iniziare a eseguire le varie migrazioni necessarie. Al termine, prendere in considerazione la possibilità di gestire i metodi di autenticazione nel portale di registrazione combinato, anziché nel portale utenti nel server MFA.
Aggiornare le impostazioni di federazione del dominio
Dopo aver completato le migrazioni degli utenti e aver spostato tutti i servizi di autenticazione dal server MFA, è il momento di aggiornare le impostazioni di federazione del dominio. Dopo l'aggiornamento, Microsoft Entra non invia più la richiesta MFA al server federativo locale.
Per configurare Microsoft Entra ID per ignorare le richieste MFA al server federativo locale, installare Microsoft Graph PowerShell SDK e impostare federatedIdpMfaBehavior su rejectMfaByFederatedIdp
, come illustrato nell'esempio seguente.
Richiedi
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Risposta
Nota: l'oggetto risposta illustrato qui potrebbe essere abbreviato per la leggibilità.
HTTP/1.1 200 OK
Content-Type: application/json
{
"@odata.type": "#microsoft.graph.internalDomainFederation",
"id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
"issuerUri": "http://contoso.com/adfs/services/trust",
"metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
"signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"passiveSignInUri": "https://sts.contoso.com/adfs/ls",
"preferredAuthenticationProtocol": "wsFed",
"activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
"signOutUri": "https://sts.contoso.com/adfs/ls",
"promptLoginBehavior": "nativeSupport",
"isSignedAuthenticationRequestRequired": true,
"nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"signingCertificateUpdateStatus": {
"certificateUpdateResult": "Success",
"lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
},
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Gli utenti non verranno più reindirizzati al server federativo locale per MFA, indipendentemente dal fatto che siano destinati allo strumento Implementazione a fasi o meno. Si noti che l'applicazione può richiedere fino a 24 ore.
Nota
L'aggiornamento dell'impostazione della federazione del dominio può richiedere fino a 24 ore.
Facoltativo: disabilitare il portale utenti del server MFA
Dopo aver completato la migrazione di tutti i dati utente, gli utenti finali possono iniziare a usare le pagine di registrazione combinate di Microsoft Entra ID per gestire i metodi MFA. Esistono due modi per impedire agli utenti di usare il portale utenti nel server MFA:
- Reindirizzare l'URL del portale utenti del server MFA a aka.ms/mfasetup
- Deselezionare la casella di controllo Consenti agli utenti di accedere nella scheda Impostazioni nella sezione Portale utenti del server MFA per impedire agli utenti di accedere completamente al portale.
Rimuovere le autorizzazioni del server MFA
Quando non è più necessario il server Azure MFA, seguire le normali procedure di deprecazione del server. Non è necessaria alcuna azione speciale in Microsoft Entra ID per indicare il ritiro del server MFA.
Piano di rollback
Se l'aggiornamento presenta problemi, seguire questa procedura per eseguire il rollback:
Disinstallare MFA Server 8.1.
Sostituire Telefono Factor.pfdata con il backup eseguito prima dell'aggiornamento.
Nota
Tutte le modifiche apportate dal backup andranno perse, ma devono essere minime se il backup è stato eseguito subito prima dell'aggiornamento e dell'aggiornamento non è riuscito.
Eseguire il programma di installazione per la versione precedente, ad esempio 8.0.x.x.
Configurare Microsoft Entra ID per accettare richieste MFA al server federativo locale. Usare Graph PowerShell per impostare federatedIdpMfaBehavior su
enforceMfaByFederatedIdp
, come illustrato nell'esempio seguente.Richiedi
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
L'oggetto risposta seguente viene abbreviato per la leggibilità.
Response
HTTP/1.1 200 OK Content-Type: application/json { "@odata.type": "#microsoft.graph.internalDomainFederation", "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc", "issuerUri": "http://contoso.com/adfs/services/trust", "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex", "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "passiveSignInUri": "https://sts.contoso.com/adfs/ls", "preferredAuthenticationProtocol": "wsFed", "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed", "signOutUri": "https://sts.contoso.com/adfs/ls", "promptLoginBehavior": "nativeSupport", "isSignedAuthenticationRequestRequired": true, "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "signingCertificateUpdateStatus": { "certificateUpdateResult": "Success", "lastRunDateTime": "2021-08-25T07:44:46.2616778Z" }, "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
Impostare l'implementazione a fasi per Azure MFA su Off. Gli utenti verranno nuovamente reindirizzati al server federativo locale per MFA.