Vous préparez une migration BitTitan/Exchange/OneDrive et la MFA bloque l’outil ? Voici une méthode professionnelle pour réussir sans abaisser durablement le niveau de sécurité de votre tenant Azure/Entra.
Sommaire
Peut‑on désactiver la MFA dans Azure/Entra pour mener une migration (BitTitan / Exchange / OneDrive) ?
Vue d’ensemble
Dans de nombreux projets, l’outil de migration échoue à s’authentifier lorsque la MFA est exigée par le tenant. Les tentatives courantes — désactiver les Security Defaults et créer une règle Conditional Access (CA) avec exemption par groupe — donnent parfois des résultats mitigés : l’authentification passe côté messagerie, mais OneDrive/SharePoint continuent d’échouer. Une cause fréquente est la dépréciation de l’authentification de base (Basic Auth) : si le produit/flux s’appuie encore dessus, la simple suppression de l’exigence MFA ne suffit plus. La solution robuste consiste à migrer avec l’authentification moderne, idéalement en app‑only par certificat (service principal).
Ce qui a été constaté
- Désactiver Security Defaults peut suspendre la MFA au niveau locataire, mais c’est non recommandé et cela n’empêche pas toujours les invites d’inscription à la MFA.
- Une règle CA avec exclusion de groupe fonctionne parfois partiellement : messagerie OK, OneDrive/SharePoint KO.
- La fin de Basic Auth rend inopérants les scénarios qui en dépendent ; il faut basculer vers l’OAuth/Modern Auth.
- En l’absence d’outil compatible, la migration manuelle reste un contournement viable, mais plus coûteux en temps et en risque.
Pourquoi désactiver la MFA n’est presque jamais la bonne solution
La MFA protège contre le vol d’identifiants et les attaques à grande échelle. La supprimer, même temporairement, crée une fenêtre d’exposition qui peut être exploitée. De plus :
- Security Defaults n’agit pas finement : vous perdez d’autres protections (verrous d’accès hérités, exigences de mot de passe, etc.).
- Les campagnes d’inscription aux méthodes d’authentification peuvent continuer d’imposer l’enrôlement même si la MFA « semble » désactivée.
- Les règles CA ciblant Toutes les applications cloud, ou des apps spécifiques (Exchange Online, SharePoint Online), peuvent réimposer une MFA, une fréquence de connexion ou un niveau d’authentification incompatible avec l’outil.
Plutôt que de « couper la MFA », l’approche moderne vise à autoriser un agent de migration (application Entra ID) à exécuter des opérations bien délimitées, sur une période courte, avec des droits révoqués dès la fin.
Comprendre les flux d’authentification et leurs impacts
| Critère | Auth. déléguée (compte utilisateur) | Auth. app‑only (service principal + certificat) |
|---|---|---|
| Interaction utilisateur | Oui : prompts MFA possibles | Non : non-interactive, sans MFA |
| Compatibilité outils | Variable ; dépend de la gestion OAuth/MFA de l’éditeur | Excellente si l’outil supporte les permissions applicatives |
| Surcouche CA | Nécessite des exemptions CA finement cadenassées | Moins sensible aux CA ; on contrôle par permissions applicatives |
| Portée des droits | Limitée au compte, dépend des rôles/consentements | Définie par les scopes applicatifs et les politiques SPO/EXO |
| Audit & révocation | Journalisation des connexions, rotation de mots de passe/MFA | Journalisation des app roles et révocation du certificat, suppression SPN |
| Cas OneDrive/SharePoint | Souvent bloqué par CA/MFA ou obsolescence Basic Auth | Préférer Sites.Selected + consentement admin + certificat |
| Cas Exchange Online | IMAP/POP/Basic Auth : obsolètes/inutilisables | EWS OAuth (full_access_as_app) ou Microsoft Graph + application access policy |
Approche recommandée : authentification moderne app‑only (service principal + certificat)
Objectif : donner à l’outil des autorisations applicatives limitées dans le temps et dans la portée, sans impliquer la MFA car il n’y a pas d’utilisateur interactif.
Étapes de mise en œuvre (haute précision)
- Créer l’application Entra ID (registre d’app) : nom explicite (ex.
Migration‑M365‑Q4), noter Application ID. - Générer un certificat dédié :
- RSA 2048 ou 4096, SHA‑256, Key Exportable pour sauvegarde.
- Durée de vie courte (3–12 mois max) alignée sur le projet.
- Stockage sécurisé (HSM ou coffre chiffré) ; ne jamais réutiliser d’un projet à l’autre.
- Associer le certificat à l’app (Certificates & secrets > Certificates), thumbprint journalisé.
- Accorder les permissions applicatives minimales nécessaires, puis consentement admin.
- SharePoint/OneDrive : privilégier
Sites.Selected(Application). Ensuite, accorder l’accès uniquement aux sites/OneDrives concernés. - Exchange Online : selon l’outil :
- Option EWS OAuth :
full_access_as_app(Application) + Application Access Policy pour restreindre les boîtes ciblées. - Option Microsoft Graph :
Mail.ReadWrite(Application) + Application Access Policy (Exchange) pour limiter la portée.
- Option EWS OAuth :
- Microsoft Graph : ajouter
Directory.Read.All(Application) si l’outil doit résoudre les utilisateurs/sites, etUser.Read.Allsi nécessaire.
- SharePoint/OneDrive : privilégier
- Limiter la portée côté workload :
- SharePoint Admin : accorder sélectivement l’accès aux sites/OneDrives via Sites.Selected.
- Exchange Online : créer des application access policies ciblant un groupe de boîtes.
- Tester en non‑prod sur un échantillon représentatif (petites, grosses boîtes, fichiers volumineux, historique de versions).
- Révoquer les accès et supprimer l’application immédiatement après la migration.
Jeu de permissions minimal conseillé (à adapter)
| Workload | Permissions applicatives | Restriction recommandée |
|---|---|---|
| SharePoint/OneDrive | Sites.Selected | Accorder seulement les sites et OneDrives ciblés |
| Exchange Online (Graph) | Mail.ReadWrite, MailboxSettings.Read (selon outil) | Application Access Policy limitant aux boîtes de migration |
| Exchange Online (EWS OAuth) | full_access_as_app | Application Access Policy + groupe cible |
| Graph (résolution annuaire) | Directory.Read.All, User.Read.All | Limiter l’usage au temps du projet |
Exemples PowerShell (création certificat & bonnes pratiques)
Générez un certificat dédié et exportez le public (.cer) pour l’app, le privé (.pfx) pour l’outil.
# Exécuter dans un profil administrateur
$cert = New-SelfSignedCertificate `
-Subject "CN=Migration-M365-Q4" `
-KeyExportPolicy Exportable `
-KeySpec Signature `
-KeyLength 2048 `
-KeyAlgorithm RSA `
-HashAlgorithm SHA256 `
-NotAfter (Get-Date).AddMonths(6) `
-CertStoreLocation "Cert:\CurrentUser\My"
# Export public (à téléverser dans l'app Entra ID)
Export-Certificate -Cert \$cert -FilePath "\$env\:TEMP\Migration-M365-Q4.cer"
# Export privé (protéger par un mot de passe robuste)
\$pwd = Read-Host -AsSecureString "Mot de passe PFX"
Export-PfxCertificate -Cert \$cert -FilePath "\$env\:TEMP\Migration-M365-Q4.pfx" -Password \$pwd Quand un compte utilisateur est imposé : exemptions Conditional Access maîtrisées
Certains éditeurs imposent encore une authentification déléguée. Dans ce cas, mettez en place une exemption CA temporaire et compensez par des contrôles forts.
Procédure CA suggérée
- Créer le groupe
Migration‑Bypass‑MFAet y ajouter uniquement les comptes de migration. - Vérifier que la MFA par utilisateur (héritée) est Disabled pour ces comptes.
- Configurer deux règles CA :
- Règle A « Exiger la MFA » : exclure le groupe
Migration‑Bypass‑MFA. - Règle B « Verrou géographique/IP » : inclure le groupe, autoriser uniquement depuis des Named locations (IP de confiance), bloquer le reste.
- Règle A « Exiger la MFA » : exclure le groupe
- Limiter dans le temps : activer ces règles seulement pendant les fenêtres de migration.
- Avant de lancer, utiliser l’outil What‑If de CA pour valider que aucune autre règle ne réimpose la MFA, une fréquence de connexion ou une force d’authentification spéciale.
- Surveiller les Sign‑in logs et Audit logs pendant l’exécution.
Paramétrage de référence pour la règle B (verrou IP)
- Cibles : Toutes les apps cloud (ou Apps sélectionnées si l’outil le permet).
- Utilisateurs : Inclure le groupe
Migration‑Bypass‑MFA. - Conditions : Emplacements → Inclure : Tous ; Exclure : IP de confiance (Named locations).
- Accès : Bloquer l’accès (ce qui force implicitement la connexion uniquement via les IP exclues du blocage).
Vous êtes encore invité à configurer la MFA alors qu’elle paraît « désactivée » ?
Vérifiez les points suivants, dans l’ordre :
| Vérification | Où regarder | Action |
|---|---|---|
| Security Defaults | Propriétés du tenant | Doit être Disabled pendant la fenêtre de migration (préférer CA fine plutôt que défauts globaux). |
| MFA par utilisateur (héritée) | Portail MFA classique | État Disabled pour les comptes de migration. |
| Inscription aux méthodes d’authentification | Authentication methods > Registration campaign | Exclure temporairement le groupe de migration si l’enrôlement est forcé tenant-wide. |
| Autres règles CA | Conditional Access | Repérer celles qui ciblent SharePoint/Exchange ou Toutes les apps et qui imposent MFA/fréquence/force d’authentification. |
| Sessions en cache | Navigateurs / Tokens | Nettoyer les sessions, invalider les tokens, réessayer en navigation privée. |
Alternatives et outillage compatibles Modern Auth
- Choisir des solutions de migration compatibles Microsoft Graph/Modern Auth pour Exchange Online et SharePoint/OneDrive.
- Pour OneDrive/SharePoint, privilégier des parcours app‑only (service principal + certificat) et Sites.Selected.
- Pour Exchange Online, préférer EWS OAuth ou Graph avec application access policy (éviter tout flux Basic Auth).
Cas particuliers par workload
Exchange Online
- IMAP/POP/SMTP AUTH : à éviter pour la migration ; obsolètes ou restreints.
- EWS avec OAuth : fiable et largement supporté. Nécessite
full_access_as_app+ politique d’accès applicatif pour restreindre la portée. - Microsoft Graph : plus moderne ; utiliser
Mail.ReadWriteen application + application access policy Exchange pour limiter aux boîtes cibles. - Gouvernance : journaliser les accès, prévoir des throttling windows et des retries.
SharePoint Online / OneDrive
- Sites.Selected est la meilleure pratique : l’app reçoit un accès précis aux sites/OneDrives requis, pas plus.
- Surveiller les tenant restrictions (contrôles d’accès) qui peuvent bloquer des appels en provenance de l’outil.
- Valider la gestion des versions, des métadonnées et des partages lors des tests.
Plan de migration sécurisé (checklist opérationnelle)
Avant
- Cartographier les boîtes, sites et OneDrives à migrer ; identifier objets lourds (pièces > 100 Mo, bibliothèques volumineuses, boîtes > 50 Go).
- Choisir l’outil compatible Modern Auth et confirmer son support app‑only.
- Créer l’application Entra ID, certificat dédié, permissions minimales, consentement admin.
- Configurer Sites.Selected (SPO) et application access policy (EXO) pour limiter la portée.
- Préparer, si nécessaire, un compte de migration et une exemption CA (IP de confiance + durée courte).
- Exécuter des tests pilotes et valider performances, mapping des dossiers, versions, droits.
Pendant
- Activer, si utilisé, le bypass CA uniquement sur le créneau prévu.
- Surveiller en temps réel : taux d’erreurs, logs CA, journaux SharePoint/Exchange, consommation de quota.
- Ajuster le throttling selon les messages de limitation ; planifier des fenêtres hors‑pics.
Après
- Révoquer les consentements et supprimer l’app/service principal.
- Supprimer l’exemption CA, réactiver les règles standards, rétablir Security Defaults si c’était votre posture.
- Établir un rapport de clôture (éléments migrés, erreurs résiduelles, comptes traités) et plan de correction.
Dépannage ciblé : erreurs fréquentes et résolutions
- Prompt MFA persistant : vérifiez l’absence d’une autre règle CA (p. ex. Authentication Strength imposant un facteur). Utilisez le What‑If avec l’utilisateur, l’app, l’emplacement et l’appareil simulés.
- OneDrive/SharePoint bloque alors que la messagerie passe : l’outil tente peut‑être un flux legacy. Forcer/appuyer la configuration app‑only avec
Sites.Selected. - Accès Graph refusé : manque de consentement admin ou scopes inadaptés ; vérifier les rôles attribués à l’app et les politiques d’accès.
- Performances dégradées : répartir la charge, augmenter la parallélisation dans les limites des quotas, planifier en heures creuses.
- Erreurs de mapping (caractères spéciaux, chemins trop longs) : préparer des règles de transformation (renommer, aplatir) avant la passe finale.
Sécurité : principes non négociables
- Principe du moindre privilège : permissions minimales, Sites.Selected plutôt que
Sites.ReadWrite.Allglobal. - Temporalité : accès valides uniquement pendant la migration.
- Traçabilité : logs CA, Sign‑ins, Unified Audit Log conservés et examinés.
- Break‑glass : comptes d’urgence réservés aux incidents, jamais pour un projet de migration normal.
- Gestion des secrets : préférer les certificats aux client secrets, stocker hors poste (coffre), renouveler/révoquer.
Exemple de politique d’accès applicatif Exchange
Restreindre l’app aux boîtes d’un groupe spécifique :
# Se connecter à Exchange Online PowerShell
Connect-ExchangeOnline
# Créer un groupe (si non existant) contenant les boîtes à migrer
# New-DistributionGroup -Name "Migration-Scopes" ...
# Créer la politique d'accès applicatif pour l'AppId (remplacer par l'ID de l'application)
New-ApplicationAccessPolicy ` -AppId "00000000-0000-0000-0000-000000000000"`
-PolicyScopeGroupId "[Migration-Scopes@contoso.com](mailto:Migration-Scopes@contoso.com)" ` -AccessRight RestrictAccess`
-Description "Limiter l'app de migration aux boîtes du groupe Migration-Scopes"
# Tester la politique
Test-ApplicationAccessPolicy ` -AppId "00000000-0000-0000-0000-000000000000"`
-Identity "[user.cible@contoso.com](mailto:user.cible@contoso.com)" Gouvernance SharePoint avec Sites.Selected
Attribuez explicitement les droits sur les sites/OneDrives ciblés :
# Exemple conceptuel (cmdlets SPO/Graph)
# 1) L'app dispose de la permission "Sites.Selected" (Application) avec consentement admin.
# 2) Accorder l'accès Read/Write à un site
# Grant-PnPAzureADAppSitePermission -AppId <AppId> -DisplayName "Migration-M365-Q4" -Site <SiteUrl> -Permissions Write
# 3) Vérifier les permissions
# Get-PnPAzureADAppSitePermission -Site \<SiteUrl>
FAQ rapide
Faut‑il désactiver complètement la MFA pour migrer ?
Non. Préférez la Modern Auth app‑only (service principal + certificat). Si un compte utilisateur est indispensable, créez une exemption CA temporaire très cadrée (IP de confiance, durée limitée) et journalisée.
Pourquoi OneDrive/SharePoint échouent alors que la messagerie fonctionne ?
Parce que l’outil utilise parfois des flux legacy ou des appels non compatibles avec les politiques SPO. Basculer vers un parcours app‑only (Sites.Selected) résout généralement le problème.
Que faire si l’outil de migration ne supporte pas Modern Auth ?
Considérer une mise à jour de l’outil, une approche manuelle sur un périmètre réduit, ou un autre produit compatible Modern Auth/Graph.
Comment limiter le risque pendant un bypass CA ?
Restreindre par IP, limiter la fenêtre temporelle, surveiller en temps réel, et supprimer l’exemption immédiatement après.
En bref
- On peut contourner temporairement la MFA via CA, mais l’exposition doit rester courte, encadrée et journalisée.
- La voie la plus robuste est la migration en authentification moderne app‑only par certificat, qui évite de toucher à la MFA tout en assurant la compatibilité Exchange/OneDrive/SharePoint.
- Révoquez systématiquement les accès, supprimez l’app et fermez les exemptions après la migration.
Procédure compacte réutilisable
- Préparer l’app Entra ID + certificat, définir les permissions applicatives minimales.
- Restreindre la portée : Sites.Selected pour SPO/OneDrive ; Application Access Policy pour Exchange.
- Tester un échantillon représentatif en non‑prod.
- Exécuter la migration ; surveiller les logs et la capacité.
- Nettoyer : révoquer, supprimer, rétablir la posture MFA/CA standard.
Avec ces pratiques, vous maximisez la réussite technique de la migration tout en maintenant un haut niveau de sécurité et de conformité.