Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Microsoft Entra ID offre une expérience de connexion basée sur le cloud simple à toutes vos ressources et applications avec une authentification forte et des stratégies d’accès adaptatif basées sur les risques pour accorder l’accès aux ressources afin de réduire les coûts opérationnels de gestion et de maintenance d’un environnement AD FS et d’accroître l’efficacité informatique.
Pour plus d’informations sur la raison pour laquelle vous devez effectuer une mise à niveau d’AD FS vers l’ID Microsoft Entra, visitez le passage d’AD FS à Microsoft Entra ID. Consultez migrer de la fédération vers l’authentification cloud pour comprendre comment effectuer une mise à niveau à partir d’AD FS.
Ce document vous fournira les étapes recommandées pour la désaffectation de vos serveurs AD FS.
Conditions préalables à la désaffectation des serveurs AD FS
Avant de commencer à désaffecter vos serveurs AD FS, vérifiez que les éléments suivants sont terminés. Pour plus d’informations, consultez la migration de la fédération vers l’authentification cloud.
Installez Microsoft Entra Connect Health pour fournir une surveillance robuste de votre infrastructure d’identité locale.
Effectuez le pré-travail pour l’authentification unique (SSO).
Migrez l’authentification de votre utilisateur vers l’ID Microsoft Entra. Une fois l’authentification cloud activée, l’ID Microsoft Entra est capable de gérer le processus de connexion des utilisateurs en toute sécurité. Microsoft Entra ID vous offre trois options pour sécuriser l’authentification cloud des utilisateurs :
- Synchronisation de hachage de mot de passe Microsoft Entra (PHS) : permet à vos utilisateurs de se connecter à des applications locales et cloud à l’aide des mêmes mots de passe. Microsoft Entra Connect synchronise un hachage d’un hachage du mot de passe d’un utilisateur entre une instance Active Directory locale et une instance Microsoft Entra basée sur le cloud. Les deux couches de hachage garantissent que vos mots de passe ne sont jamais exposés ou transmis aux systèmes cloud.
- Microsoft Entra Certificate Based Authentication (CBA) : vous permet d’adopter une méthode d’authentification résistante à l’hameçonnage et d’authentifier les utilisateurs avec un certificat X.509 sur votre infrastructure à clé publique (PKI).
- Authentification directe Microsoft Entra (PTA) : permet à vos utilisateurs de se connecter à des applications locales et cloud à l’aide des mêmes mots de passe. Il installe un agent sur votre annuaire Active Directory local et valide les mots de passe des utilisateurs directement sur votre annuaire Active Directory local.
Vous pouvez essayer l’authentification cloud pour vos utilisateurs à l’aide du déploiement intermédiaire. Il vous permet de tester de manière sélective des groupes d’utilisateurs avec les fonctionnalités d’authentification cloud mentionnées ci-dessus.
Remarque
- PHS &CBA sont les options recommandées pour l’authentification managée dans le cloud. Le PTA doit être utilisé uniquement dans les cas où il existe des exigences réglementaires pour ne pas synchroniser les informations de mot de passe sur le cloud.
- L’authentification des utilisateurs et la migration des applications peuvent être effectuées dans n’importe quel ordre. Toutefois, il est recommandé d’effectuer d’abord la migration de l’authentification utilisateur.
- Veillez à évaluer les scénarios pris en charge et non pris en charge pour le déploiement intermédiaire.
Migrez toutes vos applications qui utilisent actuellement AD FS pour l’authentification auprès de Microsoft Entra ID, car elle vous donne un plan de contrôle unique pour la gestion des identités et des accès à Microsoft Entra ID. Veillez également à migrer vos applications Office 365 et appareils joints à Microsoft Entra ID.
- L’Assistant Migration peut être utilisé pour migrer des applications d’AD FS vers Microsoft Entra ID.
- Si vous ne trouvez pas l’application SaaS appropriée dans la galerie d’applications, elles peuvent être demandées à partir de https://aka.ms/AzureADAppRequest.
Veillez à exécuter Microsoft Entra Connect Health pendant au moins une semaine pour observer l’utilisation des applications dans l’ID Microsoft Entra. Vous devriez également pouvoir afficher les journaux de connexion utilisateur dans Microsoft Entra ID.
Étapes de désactivation de vos serveurs AD FS
Cette section vous fournit le processus pas à pas pour désactiver vos serveurs AD FS.
Avant cette étape, vous devez vérifier qu’aucune partie de confiance (approbations de partie de confiance) avec le trafic n’est encore présente dans les serveurs AD FS.
Avant de commencer, vérifiez les journaux des événements AD FS et/ou Microsoft Entra Connect Health pour toute défaillance ou réussite de connexion, car cela signifie que ces serveurs sont toujours utilisés pour quelque chose. Si vous voyez des échecs ou des réussites de connexion, vérifiez comment migrer vos applications à partir d’AD FS ou transférer votre authentification vers Microsoft Entra ID.
Une fois la vérification ci-dessus vérifiée, vous pouvez effectuer les étapes suivantes (en supposant que les serveurs AD FS ne sont pas utilisés pour autre chose maintenant) :
Remarque
Après avoir déplacé votre authentification vers l’ID Microsoft Entra, testez votre environnement pendant au moins une semaine pour vérifier que l’authentification cloud s’exécute sans problème.
- Envisagez de prendre une sauvegarde finale facultative avant de désaffecter les serveurs AD FS.
- Supprimez toutes les entrées AD FS de l’un des équilibreurs de charge (internes et externes) que vous avez peut-être configurés dans votre environnement.
- Supprimez toutes les entrées DNS correspondantes des noms de batterie de serveurs respectifs pour les serveurs AD FS dans votre environnement.
- Sur le serveur AD FS principal, exécutez
Get-ADFSPropertieset recherchez CertificateSharingContainer. Notez ce nom de domaine, car vous devrez le supprimer près de la fin de l’installation (après quelques redémarrages et quand il n’est plus disponible) - Si votre base de données de configuration AD FS utilise une instance de base de données SQL Server comme magasin, veillez à supprimer la base de données avant de désinstaller les serveurs AD FS.
- Désinstallez les serveurs WAP (Proxy).
- Connectez-vous à chaque serveur WAP, ouvrez la console de gestion de l’accès à distance et recherchez les applications web publiées.
- Supprimez les serveurs AD FS associés qui ne sont plus utilisés.
- Lorsque toutes les applications web publiées sont supprimées, désinstallez WAP avec la commande suivante Uninstall-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess.
- Désinstallez les serveurs AD FS.
- En commençant par les nœuds secondaires, désinstallez AD FS avec la commande Uninstall-WindowsFeature ADFS-Federation,Windows-Internal-Database. Après cette exécution del C :\Windows\WID\data\adfs* commande pour supprimer les fichiers de base de données
- Supprimez les certificats SSL (Ad FS Secure Socket Layer) de chaque stockage serveur.
- Reformatez les serveurs AD FS avec un formatage complet du disque.
- Vous pouvez désormais supprimer votre compte AD FS en toute sécurité.
- Supprimez le contenu du DN CertificateSharingContainer à l’aide d’ADSI Edit après la désinstallation.