Pourquoi quitter AD FS devient urgent
Une ferme Active Directory Federation Services (AD FS) représente un point de défaillance unique pour toute votre organisation. Si ce service tombe — panne serveur, certificat expiré, incident réseau — chaque utilisateur perd instantanément l'accès à Microsoft Teams, Exchange Online, SharePoint et l'ensemble des applications cloud. L'authentification fédérée repose sur un flux précis : l'utilisateur saisit son adresse e-mail, Entra ID détecte que le domaine est fédéré, redirige vers AD FS, qui valide le mot de passe contre Active Directory et renvoie un jeton. Ce détour fonctionne, mais il impose de maintenir des serveurs supplémentaires, des certificats et une haute disponibilité permanente — uniquement pour que vos collaborateurs puissent se connecter.
La solution officielle consiste à convertir le domaine de fédéré à géré, ce qui bascule tous les utilisateurs simultanément. Moindre mauvaise configuration, et vous le découvrez en production devant l'ensemble de votre entreprise. C'est précisément pour éviter ce scénario que le Staged Rollout existe.
Prérequis avant toute manipulation
Avant de toucher quoi que ce soit dans le portail, vérifiez les points suivants :
- Licence : aucune licence Entra ID Premium spécifique n'est requise pour le Staged Rollout lui-même, mais votre configuration Azure AD Connect doit être opérationnelle.
- Rôle Entra ID : Administrateur hybride d'identité (Hybrid Identity Administrator) ou Administrateur général (Global Administrator).
- Azure AD Connect : version à jour, synchronisation active, et Password Hash Sync activé dans l'assistant de configuration (même si votre domaine est actuellement fédéré).
- Module PowerShell :
Microsoft.Graphinstallé pour la commande de cutover finale. - Groupe pilote : un groupe de sécurité cloud (pas un groupe de distribution, pas un groupe à extension de messagerie) avec moins de 200 membres pour le premier ajout. Les groupes imbriqués et les groupes dynamiques ne sont pas supportés.
- Synchronisation complète : au moins un cycle de synchronisation complet doit s'être exécuté après l'activation de Password Hash Sync.
Groupes non supportés
Le Staged Rollout ne supporte pas les groupes imbriqués ni les groupes dynamiques. Utilisez exclusivement des groupes de sécurité cloud à adhésion directe, limités à 200 membres lors du premier déploiement.
Comprendre le mécanisme caché du Staged Rollout
La plupart des administrateurs pensent qu'Entra ID vérifie l'appartenance au groupe pilote au moment de la connexion. C'est faux — et cette incompréhension génère beaucoup de confusion.
Voici ce qui se passe réellement :
- Vous ajoutez un utilisateur au groupe pilote dans le portail.
- Une tâche de fond (background job) surveille ce groupe en permanence.
- Lorsqu'elle détecte le nouvel ajout, elle inscrit un attribut masqué directement sur le compte de l'utilisateur dans Entra ID, indiquant que cet utilisateur est désormais "managed".
- Au moment de la connexion, Entra ID lit cet attribut sur le compte — jamais la composition du groupe en temps réel.
Conséquence directe : les changements de groupe peuvent prendre jusqu'à 24 heures pour prendre effet. Si un test ne fonctionne pas immédiatement après l'ajout, patientez avant de conclure à un problème.
Activer Password Hash Sync dans Azure AD Connect
Ouvrez l'assistant Azure AD Connect
Sur votre serveur hébergeant Azure AD Connect, lancez l'application Azure AD Connect depuis le menu Démarrer ou le raccourci du Bureau.
Sélectionnez Configurer dans l'écran d'accueil.
Activez Password Hash Sync
Dans la liste des tâches disponibles, choisissez Modifier la connexion utilisateur, puis cliquez sur Suivant.
Connectez-vous avec vos identifiants d'administrateur général Azure AD lorsque l'assistant le demande.
Sur la page Connexion utilisateur, cochez Synchronisation du hachage de mot de passe en plus de votre méthode de fédération actuelle. AD FS peut rester configuré simultanément — les deux coexistent.
Terminez l'assistant et laissez la synchronisation s'exécuter.
Ce que vous devez voir : dans le journal des événements Windows (Application), des entrées de l'agent de synchronisation indiquant qu'un cycle de synchronisation complet s'est terminé avec succès.
Vérifiez qu'un cycle complet s'est exécuté
Ouvrez PowerShell sur le serveur Azure AD Connect et exécutez :
1Get-ADSyncSchedulerVérifiez que SyncCycleInProgress affiche False et que LastSyncRunTime est récent. Si nécessaire, déclenchez manuellement un cycle :
1Start-ADSyncSyncCycle -PolicyType DeltaConfigurer le Staged Rollout dans le portail Entra
Accédez à la configuration du Staged Rollout
Ouvrez le portail Entra ID et naviguez vers :
Identity > Hybrid management > Azure AD Connect > Connect Sync
Cliquez sur Enable staged rollout for managed user sign-in.
Ce que vous devez voir : un panneau latéral s'ouvre avec les trois méthodes d'authentification disponibles : Password Hash Sync, Pass-through Authentication, et Certificate-based authentication.
Activez Password Hash Sync et ajoutez votre groupe pilote
Faites glisser le bouton Password Hash Sync sur On.
Cliquez sur Manage groups, puis sur Add groups. Recherchez et sélectionnez votre groupe de sécurité pilote. Confirmez la sélection.
Commencez avec un groupe de moins de 200 membres — idéalement 5 à 20 utilisateurs représentatifs de différents profils (postes joints au domaine, appareils mobiles, VPN, etc.).
Ce que vous devez voir : le groupe apparaît dans la liste sous Password Hash Sync avec le statut Active.
Délai de propagation
Après l'ajout d'utilisateurs au groupe pilote, comptez jusqu'à 24 heures pour que l'attribut masqué soit inscrit sur chaque compte. Ne concluez pas à un dysfonctionnement avant d'avoir respecté ce délai.
Limitations connues du Staged Rollout
Le Staged Rollout ne couvre pas tous les scénarios d'authentification. Prenez-les en compte pour composer votre groupe pilote :
- Protocoles d'authentification legacy (IMAP, POP3, SMTP AUTH) : ignorent le groupe pilote et continuent d'utiliser la fédération.
- Applications envoyant un domain hint : contournent le mécanisme et restent fédérées.
- Password writeback : le comportement n'est pas garanti durant le rollout avec Password Hash Sync — testez avec précaution.
- Expiration de mot de passe : non appliquée par défaut pour les utilisateurs en phase pilote.
- VDI non persistant : doit rester fédéré.
- Windows Hello for Business (mode certificat) et cartes à puce : non supportés du tout dans le Staged Rollout.
Le Staged Rollout n'est pas une destination
Microsoft est explicite sur ce point : le Staged Rollout est un mécanisme de test, pas une configuration permanente. Une organisation avec une partie des utilisateurs en fédéré et l'autre en géré de façon indéfinie n'est pas une architecture supportée à long terme. Testez, validez, puis finalisez la migration.
Valider la connexion d'un utilisateur pilote
Une fois le délai de propagation écoulé, testez avec un compte membre du groupe pilote :
Testez la connexion en mode navigation privée
Ouvrez une fenêtre de navigation privée et accédez à https://myapps.microsoft.com.
Saisissez l'adresse e-mail d'un utilisateur appartenant au groupe pilote.
Ce que vous devez voir : la page de connexion Entra ID avec le branding de votre organisation s'affiche directement — sans redirection vers votre serveur AD FS. Le champ de mot de passe est proposé par Entra ID lui-même.
Si vous voyez toujours la page AD FS, la propagation de l'attribut n'est pas encore terminée. Patientez et réessayez.
Contrôlez les journaux de connexion
Dans le portail Entra ID, naviguez vers Identity > Monitoring & health > Sign-in logs.
Filtrez par utilisateur pilote. Vérifiez que la colonne Authentication requirement indique Single-factor authentication (ou MFA si configuré) et que la colonne Client app ne mentionne pas AD FS.
Consultez également les journaux de votre ferme AD FS pour confirmer que les connexions des utilisateurs pilotes n'y apparaissent plus.
Finaliser la migration : convertir le domaine
Lorsque votre groupe pilote a validé le fonctionnement sur une période suffisante, la migration définitive s'effectue avec une seule commande PowerShell. C'est le moment où le domaine bascule de fédéré à géré pour l'ensemble des utilisateurs.
Connectez-vous à Microsoft Graph avec les permissions nécessaires
1Connect-MgGraph -Scopes "Domain.ReadWrite.All"Authentifiez-vous avec un compte Administrateur général ou Administrateur hybride d'identité. Acceptez les permissions demandées.
Convertissez le domaine en managed
Remplacez votredomaine.com par votre domaine réel :
1Update-MgDomain -DomainId "votredomaine.com" -AuthenticationType "Managed"Cette commande est irréversible sans intervention manuelle. Exécutez-la pendant une fenêtre de maintenance, en dehors des heures de pointe. La propagation peut prendre jusqu'à une heure.
Vérifiez la conversion du domaine
1Get-MgDomain -DomainId "votredomaine.com" | Select-Object Id, AuthenticationTypeCe que vous devez voir : AuthenticationType affiche Managed.
Désactivez le Staged Rollout
Retournez dans Entra ID > Identity > Hybrid management > Azure AD Connect > Connect Sync et désactivez le Staged Rollout. Il n'a plus de raison d'être actif une fois le domaine converti.
Fenêtre de maintenance recommandée
Planifiez la commande de cutover un vendredi soir ou un week-end. La propagation d'une heure peut créer des interruptions intermittentes. Prévenez votre helpdesk et gardez un administrateur disponible pour surveiller les journaux.
En cas de problème
Les utilisateurs pilotes voient toujours la page AD FS après 24 heures
Vérifiez que le groupe utilisé est bien un groupe de sécurité cloud à adhésion directe (pas imbriqué, pas dynamique). Confirmez dans les journaux de synchronisation Azure AD Connect qu'un cycle s'est bien exécuté après l'ajout. Si le problème persiste, retirez l'utilisateur du groupe, attendez quelques heures, puis rajoutez-le.
La commande Update-MgDomain retourne une erreur de permissions
Assurez-vous d'avoir lancé Connect-MgGraph avec le scope Domain.ReadWrite.All et que le compte utilisé possède bien le rôle Administrateur général ou Administrateur hybride d'identité. Déconnectez-vous et reconnectez-vous à Graph si la session est ancienne :
1Disconnect-MgGraph2Connect-MgGraph -Scopes "Domain.ReadWrite.All"Les applications legacy ne fonctionnent plus après le cutover
Les protocoles d'authentification basique (SMTP AUTH, IMAP, POP3) ne passent plus par AD FS après la conversion du domaine. Vérifiez que les applications concernées sont configurées pour utiliser l'authentification moderne OAuth 2.0, ou activez l'authentification basique dans Exchange Online pour les services qui l'exigent encore (avec les risques de sécurité associés).
