MFA e migrazioni Microsoft 365: dopo la dismissione della Basic Auth, molti MSP si trovano con progetti bloccati. Questa guida spiega come creare un’esclusione di Conditional Access realmente efficace, come usare BitTitan con OAuth 2.0 (Q3 2024+) e quali sono le alternative sicure.
Contesto e obiettivo
Dal mese di ottobre 2022 Microsoft ha disattivato in modo definitivo l’autenticazione di base (Basic Authentication) per Exchange Online. Da quel momento, qualsiasi strumento di migrazione che faceva affidamento su Basic Auth deve usare la Modern Authentication (OAuth 2.0) e rispettare le policy di Microsoft Entra ID (ex Azure AD), inclusi Security defaults e Conditional Access (CA). In parallelo, e fino a metà 2024, BitTitan MigrationWiz non ha offerto supporto completo a OAuth per alcune workload (in particolare OneDrive/SharePoint), con conseguenti prompt MFA o blocchi di autenticazione.
Questa guida pratica mostra come:
- capire perché “spegnere” MFA non basta più (e spesso è pericoloso);
- configurare un’esclusione CA valida per gli account di migrazione;
- abilitare BitTitan con registrazione applicativa e permessi application (OAuth 2.0);
- scegliere alternative quando la versione di BitTitan non è adeguata;
- applicare buone pratiche per limitare i rischi e chiudere le eccezioni a fine progetto.
Problema tipico riscontrato dagli MSP
L’MSP deve migrare posta elettronica e OneDrive per più utenti. Dopo l’abolizione della Basic Auth, gli strumenti che non supportano completamente Modern Auth incontrano l’MFA, generando errori di accesso o richieste impossibili da automatizzare. Le versioni di MigrationWiz precedenti a metà 2024 non gestivano correttamente l’autenticazione per OneDrive/SharePoint, rendendo di fatto impraticabile il flusso.
Tentativi fatti e limiti osservati
| Tentativo | Risultato |
|---|---|
| Disabilitare “Security defaults” (Entra → Identity > Overview > Properties > Manage security defaults) | L’MFA restava comunque attiva per l’account admin: la disattivazione globale non basta se sono presenti altre policy (es. Conditional Access o per-user MFA legacy). |
| Conditional Access: creare un gruppo “Migrazione”, aggiungere gli utenti, escluderli dalla CA che richiede MFA | Per Exchange/posta ha funzionato; per OneDrive/SharePoint continuava il prompt MFA, perché alcune chiamate di BitTitan ricadevano su criteri diversi o sul legacy per-user MFA. |
| Supporto Microsoft: ticket e suggerimento di usare account di servizio dedicati | Non ha risolto il blocco tecnico: senza pieno supporto OAuth nel motore di migrazione, il problema persisteva. |
Perché “spegnere MFA” non funziona (e non è consigliabile)
In Entra ID la protezione MFA può essere imposta da più strati:
- Security defaults: un set di impostazioni predefinite per abilitare MFA di base per tutti. Spegnerle non rimuove altre enforcement.
- Conditional Access: una o più policy che possono richiedere MFA per specifiche app, condizioni, utenti o gruppi. Se una policy applicabile richiede MFA, un’altra policy “permissiva” non la annulla: vince sempre la condizione più restrittiva.
- Per-user MFA (legacy): l’attivazione storica a livello utente dal vecchio portale MFA. Se è Enabled/Enforced, scatta comunque, a prescindere da CA.
Principio chiave: in caso di conflitto, prevale la policy più restrittiva. Per questo motivo creare una “policy che non richiede MFA” non disattiva le altre che lo richiedono; bisogna escludere il gruppo di migrazione da ciascuna policy rilevante o spostare l’autenticazione su un flusso application (dove MFA non si applica).
Soluzione praticabile e sostenibile
Esclusione CA realmente efficace
Il primo pilastro è assicurarsi che gli account di servizio o gli utenti addetti alla migrazione siano effettivamente esclusi da tutte le policy che impongono MFA, per l’insieme di applicazioni cloud coinvolte (Exchange Online, SharePoint Online/OneDrive, Teams quando serve). Procedi così:
- Crea il gruppo (es.
GRP-Migrazione) e aggiungi gli account di servizio e/o gli operatori di progetto. - Individua in Conditional Access → Policies tutte le policy che:
- hanno in Assignments → Users “All users” (o includono gli operatori),
- e in Grant richiedono Require multi-factor authentication o un Authentication strength che implica MFA,
- e in Cloud apps includono “All cloud apps” o specificamente Exchange/SharePoint.
- Apri ogni policy identificata e aggiungi
GRP-Migrazionein Users → Exclude. Non creare una policy “che non richiede MFA”: non ha precedenza su quelle che lo impongono. - In Conditions → Client apps, verifica che le policy MFA si applichino anche ai client “Browser” e “Mobile/desktop”. Alcuni strumenti usano flussi differenti: assicurati che l’esclusione copra i percorsi realmente usati.
Controllo del per‑user MFA (legacy)
Accedi alla pagina “Multi‑Factor Authentication” (portale legacy) e verifica che lo stato degli utenti in GRP-Migrazione sia Disabled. In caso contrario, imposta su Disabled. Questo evita che il vecchio enforcement superi le policy CA.
Se BitTitan è Q3 2024+ con supporto OAuth 2.0 completo
Con le build recenti, la strada consigliata è usare un flusso application (client credentials) per eliminare l’MFA dallo scenario tecnico, mantenendolo per gli utenti interattivi:
- Registra l’app in Entra ID (App registrations):
- Nome: BitTitan MigrationWiz (o simile);
- Tipo di account: solo tenant corrente;
- Genera un client secret o carica un certificato (preferibile in produzione).
- Concedi le API permission necessarie:
- Office 365 Exchange Online → Exchange.ManageAsApp (Application);
- Microsoft Graph → Sites.FullControl.All (Application) per SharePoint/OneDrive.
Nota: se il prodotto lo consente, valuta Sites.Selected per minimizzare il perimetro e delegare l’accesso solo ai siti/drive coinvolti.
- Admin consent alle autorizzazioni: l’applicazione ottiene il consenso una volta a livello di tenant. Da questo momento l’app autentica con client id + secret/cert senza MFA.
- Configura MigrationWiz sul progetto usando l’app registrata (tenant, client id, secret/cert). L’MFA riguarda solo gli utenti umani che accedono alla console, non il flusso machine‑to‑machine.
Se BitTitan è precedente o non aggiornabile
Hai tre opzioni:
- Migrazione manuale (download/upload di OneDrive e import PST per la posta): adatta a micro‑ambienti o per emergenze, con checklist di coerenza e re‑mapping permessi.
- Strumento alternativo tra quelli che supportano appieno Modern Auth (vedi più avanti).
- Sessioni intermedie con account di servizio esentati da MFA, strettamente limitate nel tempo e solo per workload compatibili. È comunque una soluzione transitoria.
Strumenti alternativi con Modern Auth
| Strumento | Note principali |
|---|---|
| Microsoft 365 Migration Center | Incluso nell’ecosistema Microsoft, integra l’eredità di Mover.io per OneDrive/SharePoint; supporto nativo a OAuth 2.0 e gestione semplificata dei mapping. |
| ShareGate Desktop / ShareGate Apricot | Specializzato su SharePoint/OneDrive; GUI completa, ottimo per ristrutturazioni d’informazione e reportistica; licenze perpetue o annuali. |
| Quest On Demand Migration | Piattaforma SaaS multi‑tenant che copre posta, Teams, OneDrive e SharePoint; pronto per MFA e scenari complessi cross‑tenant. |
| Cloudiway | Supporto consolidato per G Suite, Exchange, Box e Dropbox, con Modern Auth operativa dal 2023; utile in progetti eterogenei. |
Verifiche fondamentali prima di avviare la migrazione
- What‑If di Conditional Access: in Entra → Security → Conditional Access → What If, simula l’accesso con:
- Utente: account di servizio/operatori;
- App: Exchange Online e/o SharePoint Online (o All cloud apps);
- Client app: Browser e Mobile/desktop;
- Località/Named locations: come in produzione.
- Sign‑in logs: apri un accesso di prova e controlla nel dettaglio:
- Client app = Browser o Modern auth (non legacy),
- Conditional Access → policy applicate = nessuna richiede MFA,
- Authentication requirements = Single‑factor per l’applicazione.
- Per‑user MFA: assicurati sia Disabled sugli account di servizio.
- App registration: se usi il flusso application, verifica client id, scadenza del secret, e admin consent granted.
Best practice per disattivare o bypassare MFA in sicurezza
Usare account di servizio dedicati
- Creali solo per la migrazione, senza licenza (se non necessaria) o con licenza minima.
- Mettili nel gruppo
GRP-Migrazioneescluso dalle policy MFA. - Non usare account break‑glass generici; evita ruoli eccessivi (Least privilege).
- Al termine, disabilita o elimina gli account.
Limitare al massimo la finestra temporale
- Imposta una scadenza sulla membership del gruppo (Access Reviews o scadenze dinamiche);
- Disattiva le esclusioni appena i batch sono completati;
- Documenta nel piano di migrazione: chi, cosa, quando e perché.
Non spegnere i Security defaults “per sport”
Spegnere i Security defaults riduce sensibilmente la postura di sicurezza; fallo solo se hai già una baseline CA matura e verificata. In alternativa, mantienili accesi e gestisci le eccezioni con esclusioni mirate.
Log e tracciabilità
- Abilita il logging avanzato (Sign‑in logs, Audit logs);
- Conserva gli export dei log durante la finestra di migrazione;
- Valuta alert su accessi anomali provenienti dagli account di servizio.
Procedura rapida consigliata (ricap)
- Aggiorna BitTitan a una build ≥ luglio 2024 con supporto OAuth 2.0 pieno.
- Registra l’app in Entra ID e concedi:
Exchange.ManageAsApp(Application) per Exchange;Sites.FullControl.All(Application) per SharePoint/OneDrive.
- Crea il gruppo
GRP-Migrazionee escludilo da tutte le CA che richiedono MFA (All users / All cloud apps incluse). - Aggiungi gli account di servizio/utenti al gruppo.
- Conferma nei log che le sessioni usano Browser o Modern auth e che nessuna policy sta richiedendo MFA.
- Esegui la migrazione.
- Rimuovi le eccezioni: revoca membership del gruppo, disattiva o elimina gli account di servizio, rimuovi eventuali secret inutilizzati.
Checklist operative
Prima della migrazione
- Inventario workload (Exchange, OneDrive, SharePoint, Teams) e volumi;
- Verifica versione dello strumento (BitTitan o alternative) e capacità OAuth;
- Definisci account di servizio, gruppo dedicato ed esclusioni CA;
- Conferma stato per‑user MFA: Disabled sugli account di progetto;
- App registration completata, admin consent accordato; secret/cert in cassaforte;
- What‑If CA e test di autenticazione end‑to‑end con un utente pilota;
- Piano di rollback e finestra di cut‑over con comunicazione agli utenti.
Dopo la migrazione
- Verifica integrità contenuti (mailbox random, drive campione, permessi);
- Ripristina policy standard: rimuovi esclusioni e break‑glass temporanei;
- Revoca secret/cert inutili; valuta rotazione periodica;
- Conserva i log, chiudi la documentazione di progetto.
Troubleshooting: errori comuni e soluzioni
| Segnale/Sintomo | Possibile causa | Risoluzione |
|---|---|---|
| Prompt MFA persiste su OneDrive anche dopo esclusione gruppo | Esiste un’altra CA che richiede MFA su “All cloud apps” o un Authentication strength mirato; oppure per‑user MFA Enabled/Enforced | Riesamina tutte le CA “Require MFA” e aggiungi l’esclusione. Disabilita il per‑user MFA sugli account di progetto. |
| Sign‑in logs: “Legacy per‑user MFA enforced” | Vecchia configurazione MFA attiva a livello utente | Imposta lo stato su Disabled nel portale legacy MFA |
| Impossibile concedere admin consent all’app | Utente senza ruolo idoneo (Global Admin/Privileged Role Admin) o permesso non disponibile nel servizio | Esegui come ruolo adeguato; conferma che le API selezionate siano Application e non Delegated |
| BitTitan autentica Exchange ma fallisce su SharePoint/OneDrive | Permesso Graph insufficiente (es. “Sites.Selected” senza assegnazione ai siti) o edizione strumento senza supporto OAuth per OneDrive | Usa “Sites.FullControl.All” per test; se funziona, riduci poi al perimetro minimo. In alternativa, aggiorna lo strumento o valuta opzioni alternative |
| Accesso rifiutato con client credentials | Certificato/secret errati o scaduti; Tenant ID o Resource mal configurati | Rigenera secret/cert, aggiorna la configurazione nel tool; verifica scadenze e audience |
| Policy CA “Block legacy authentication” interferisce | Lo strumento effettua ancora chiamate legacy per alcune funzioni | Migra alla versione dello strumento che usa Modern Auth al 100%; evitare eccezioni su legacy auth, se non per test brevi e controllati |
Esempio di configurazione (guida operativa sintetica)
- Account di servizio: crea
svc_migwiz, senza licenza (o con la minima necessaria), e aggiungilo aGRP-Migrazione. - Conditional Access:
- Apri ogni policy che impone MFA (Grant → Require MFA) e inserisci
GRP-Migrazionein Users → Exclude. - Controlla le policy con Authentication strength (Passwordless/Phishing‑resistant): escludi il gruppo se si applicano a Exchange/SharePoint.
- Evita di creare una policy “No MFA”: non disattiva le altre.
- Apri ogni policy che impone MFA (Grant → Require MFA) e inserisci
- Registrazione applicativa (se supportata):
- App registrations → New registration → Nome “BitTitan MigrationWiz”.
- Certificates & secrets → crea un secret (nota scadenza) o carica certificato.
- API permissions:
- Office 365 Exchange Online →
Exchange.ManageAsApp(Application) - Microsoft Graph →
Sites.FullControl.All(Application)
- Office 365 Exchange Online →
- Concedi Admin consent.
- Verifica:
- Esegui What‑If su Exchange e SharePoint per
svc_migwiz. - Sign‑in logs: nessuna policy applicata che richieda MFA; Client app “Browser/Modern auth”.
- Esegui What‑If su Exchange e SharePoint per
- Esecuzione: avvia i batch di migrazione; monitora log ed errori; regola le soglie di throughput.
- Chiusura: rimuovi membri da
GRP-Migrazione, disattiva/eliminasvc_migwiz, revoca secret/cert non più necessari.
Domande frequenti
Posso semplicemente disattivare i Security defaults?
È sconsigliato, e spesso inutile. Se sono attive policy CA che impongono MFA o l’utente ha per‑user MFA abilitato, continuerai a vedere prompt. Lavora con esclusioni mirate e, quando possibile, usa l’autenticazione application per gli strumenti.
La mia esclusione CA non ha effetto su OneDrive/SharePoint. Perché?
Perché la chiamata applicativa compie percorsi che ricadono in policy diverse (es. “All cloud apps”) o su enforcement legacy. Verifica What‑If, controlla Authentication strength, e assicurati di avere escluso il gruppo da tutte le policy pertinenti.
Qual è la combinazione di permessi minima per MigrationWiz?
Tipicamente Exchange.ManageAsApp per Exchange e Sites.FullControl.All per SharePoint/OneDrive in modalità Application. Se lo strumento lo permette, usa Sites.Selected più assegnazioni mirate per ridurre la superficie.
È sicuro escludere MFA per un gruppo?
Sì, se l’eccezione è temporanea, limitata agli account di servizio, rispettosa del least privilege e accompagnata da logging e scadenze automatiche. Evita esclusioni permanenti per utenti finali.
Riepilogo finale
- Disabilitare completamente l’MFA non è più consigliato né sempre efficace: agisci su Conditional Access e sul vecchio per‑user MFA dove ancora presente.
- Per BitTitan, usa una versione con supporto OAuth 2.0; le release precedenti non funzionano correttamente dopo la dismissione della Basic Auth.
- Se non puoi aggiornare, valuta Microsoft 365 Migration Center, ShareGate, Quest On Demand Migration o Cloudiway, oppure una migrazione manuale per ambienti piccoli.
- Applica sempre controlli temporizzati, log e rimuovi le eccezioni subito dopo la chiusura dei batch.
Appendice: suggerimenti architetturali
- Ruoli amministrativi: assegna ruoli solo agli account che eseguono la migrazione (es. Exchange Admin/SharePoint Admin), non a tutti i membri del gruppo.
- Segreti vs certificati: per produzione preferisci certificati (minore esposizione, rotazione più sicura). Pianifica le scadenze nel runbook.
- Rate limits: distribuisci i job su più account di servizio se lo strumento lo supporta, rispettando i limiti delle API.
- Permessi OneDrive: se usi
Sites.Selected, ricorda che devi assegnare esplicitamente l’accesso alle raccolte/siti coinvolti prima di avviare i job. - Tenant hardening post‑migrazione: ripristina le CA baseline (MFA obbligatoria, ban legacy, device compliance se previsto).
Questa guida è destinata ad amministratori e MSP con autorizzazioni formali sul tenant. Le eccezioni MFA devono essere temporanee, strettamente controllate e documentate.