Quitter AD FS : migrer vers l'authentification cloud sans rupture de service
Beaucoup d'organisations conservent AD FS par habitude, alors que la raison de son déploiement a disparu depuis longtemps. Cette infrastructure exposée sur Internet, et dont la compromission ouvre la porte à la falsification de jetons, mérite un projet de sortie. Bien préparée, la migration est largement transparente pour les utilisateurs.
Pourquoi sortir d'AD FS
Une ferme AD FS, c'est des serveurs à maintenir, des proxys d'application web publiés sur Internet, des certificats à renouveler et une dépendance forte au datacenter pour chaque connexion à Microsoft 365. C'est surtout un composant Tier 0 : quiconque obtient le certificat de signature de jetons peut forger des jetons pour n'importe quel utilisateur. L'authentification cloud, par synchronisation du hachage de mot de passe ou par authentification directe, supprime cette dépendance et permet de s'appuyer pleinement sur l'accès conditionnel et Entra ID Protection.
Inventorier avant de toucher à quoi que ce soit
La difficulté d'une migration AD FS tient rarement à Microsoft 365 lui-même, mais à tout ce qui s'est greffé sur la ferme au fil des années :
- Approbations de partie de confiance : chaque application fédérée doit être identifiée, avec son propriétaire et son usage réel. Le rapport d'activité des applications AD FS dans Entra ID, alimenté par Entra Connect Health, aide à évaluer leur migrabilité.
- Règles de revendications : certaines transformations complexes, parfois non documentées, conditionnent le bon fonctionnement d'une application.
- MFA : un adaptateur MFA tiers ou des règles d'autorisation personnalisées doivent trouver leur équivalent dans l'accès conditionnel.
- Jonction hybride : vérifiez que l'inscription des appareils ne dépend pas d'AD FS.
Tester avec le déploiement échelonné
Le déploiement échelonné permet de faire passer des groupes d'utilisateurs à l'authentification cloud alors que le domaine reste fédéré. On active d'abord PHS (ou PTA) pour tous, puis on ajoute des groupes pilotes. Les utilisateurs concernés s'authentifient directement auprès d'Entra ID ; les autres continuent de passer par AD FS. Certains scénarios ne sont pas pris en charge par ce mode : consultez la documentation Microsoft à jour avant d'élaborer le plan de test.
Migrer les applications
Les applications SAML et WS-Fédération publiées par AD FS peuvent, dans la plupart des cas, devenir des applications d'entreprise Entra ID. Il faut reproduire les revendications attendues avec les fonctions de mappage et de transformation d'Entra ID, remplacer les règles d'autorisation par l'affectation d'utilisateurs et des stratégies d'accès conditionnel, puis tester avec l'éditeur ou l'équipe applicative. Une migration application par application, avec retour arrière possible, limite les risques.
Basculer les domaines puis démanteler
- Convertir chaque domaine de fédéré à géré, pendant une fenêtre planifiée, avec un plan de retour arrière documenté.
- Surveiller les journaux de connexion et le support pendant quelques jours.
- Supprimer l'approbation de partie de confiance de Microsoft 365 dans AD FS.
- Décommissionner les serveurs AD FS et les proxys, puis nettoyer les enregistrements DNS, les règles de pare-feu et les comptes de service.
- Détruire les certificats de signature et de déchiffrement de jetons, et nettoyer le conteneur de clés AD FS dans Active Directory.
Golden SAML et persistance. Après la bascule, vérifiez qu'aucun domaine du locataire n'est resté fédéré et qu'aucune configuration de fédération inconnue n'a été ajoutée. Ajouter un domaine fédéré pointant vers un fournisseur d'identité contrôlé par l'attaquant est une technique de persistance documentée.
Ce qu'un audit vérifie
- La liste des domaines encore fédérés et la justification de chacun.
- L'inventaire des approbations de partie de confiance et leur utilisation réelle.
- La protection du certificat de signature de jetons tant qu'AD FS est en service.
- La présence de configurations de fédération non documentées dans le locataire.
- Le démantèlement effectif des serveurs, certificats et comptes de service après la migration.