Notes
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.
Dans cet article, vous allez apprendre à déployer l’authentification utilisateur cloud avec la synchronisation de hachage de mot de passe Microsoft Entra (PHS) ou l’authentification directe (PTA). Bien que nous présentions le cas d’usage pour passer des services de fédération Active Directory (AD FS) à des méthodes d’authentification cloud, les conseils s’appliquent également à d’autres systèmes locaux.
Avant de continuer, nous vous suggérons de consulter notre guide sur le choix de la méthode d’authentification appropriée et de comparer les méthodes les plus adaptées à votre organisation.
Nous vous recommandons d’utiliser PHS pour l’authentification cloud.
Déploiement par étapes
Le déploiement par étapes est un excellent moyen de tester des groupes d’utilisateurs de manière sélective avec des fonctionnalités d’authentification cloud comme l’authentification multifacteur Microsoft Entra, l’accès conditionnel, Microsoft Entra ID Protection pour les informations d’identification divulguées ou Identity Governance avant le basculement de vos domaines.
Reportez-vous au plan d’implémentation de déploiement intermédiaire pour comprendre les scénarios pris en charge et non pris en charge. Nous vous recommandons d’utiliser le déploiement par étapes pour effectuer des tests avant de découper les domaines.
Flux du processus de migration
Prerequisites
Avant de commencer votre migration, assurez-vous que vous respectez ces conditions préalables.
Rôles obligatoires
Pour un déploiement par étapes, vous devez être administrateur d’identité hybride de votre locataire.
Passer à la version supérieur du serveur Microsoft Entra Connect
Installez Microsoft Entra Connect (Microsoft Entra Connect) ou effectuez une mise à niveau vers la dernière version. Lorsque vous passez un serveur Microsoft Entra Connect à une édition supérieure, vous réduisez le temps nécessaire à la migration d’AD FS vers les méthodes d’authentification cloud de plusieurs heures à quelques minutes.
Documenter les paramètres de fédération actuels
Pour rechercher vos paramètres de fédération actuels, exécutez Get-MgDomainFederationConfiguration.
Get-MgDomainFederationConfiguration -DomainID yourdomain.com
Vérifiez les paramètres qui peuvent avoir été personnalisés pour la conception de votre fédération et la documentation du déploiement. Plus précisément, recherchez des personnalisations dans PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa (si federatedIdpMfaBehavior n’est pas défini) et PromptLoginBehavior.
Sauvegarder les paramètres de fédération
Bien que ce déploiement ne modifie aucune autre partie de confiance dans votre batterie AD FS, vous pouvez sauvegarder vos paramètres :
Utilisez l’outil de restauration rapide AD FS de Microsoft pour restaurer une batterie existante ou en créer une nouvelle.
Exportez l’approbation de la partie de confiance de la plateforme d’identité Microsoft 365 et les règles de revendication personnalisées associées que vous avez ajoutées à l’aide de l’exemple PowerShell suivant :
(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"
Planifier le projet
Les échecs de projets informatiques, lorsqu’ils se produisent, proviennent généralement d’une disparité entre les attentes et l’impact, les responsabilités et les résultats. Pour éviter ces pièges, assurez-vous que vous engagez les bonnes parties prenantes et que les rôles des parties prenantes dans le projet sont bien compris.
Planifier les communications
Après la migration vers l’authentification cloud, l’expérience de connexion de l’utilisateur pour accéder à Microsoft 365 et à d’autres ressources qui sont authentifiées par Microsoft Entra ID change. Les utilisateurs qui sont en dehors du réseau voient seulement la page de connexion Microsoft Entra.
Communiquez de manière proactive avec vos utilisateurs sur ce qui va changer dans leur expérience, à quel moment les changements seront appliqués et comment ils peuvent obtenir de l’aide en cas de problème.
Planifier la fenêtre de maintenance
Les clients d’authentification moderne (Office 2016 et Office 2013, applications iOS et Android) utilisent un jeton d’actualisation valide pour obtenir de nouveaux jetons d’accès permettant de continuer à accéder aux ressources au lieu de retourner à AD FS. Ces clients sont protégés des demandes de mot de passe résultant du processus de conversion de domaine. Les clients continuent de fonctionner sans configuration supplémentaire.
Note
Lorsque vous migrez de l’authentification fédérée vers l’authentification cloud, le processus de conversion du domaine fédéré en domaine managé peut prendre jusqu’à 60 minutes. Pendant ce processus, les utilisateurs peuvent ne pas être invités à entrer des informations d’identification pour les nouvelles connexions au Centre d’administration Microsoft Entra ou à d’autres applications basées sur un navigateur protégées avec l’ID Microsoft Entra. Nous vous recommandons d’inclure ce délai dans votre fenêtre de maintenance.
Planifiez le retour en arrière.
Conseil
Envisagez de planifier le basculement des domaines pendant les heures creuses en cas d’exigences de restauration.
Pour planifier la réversibilité, utilisez les paramètres actuels de fédération documentés et consultez la documentation de conception et de déploiement de la fédération.
Le processus de restauration doit inclure la conversion de domaines managés en domaines fédérés à l’aide de l’applet de commande New-MgDomainFederationConfiguration . Si nécessaire, configurez des règles de revendications supplémentaires.
Considérations relatives à la migration
Voici les principaux éléments à prendre en compte lors de la migration.
Planifier les paramètres de personnalisation
Le fichier onload.js ne peut pas être dupliqué dans Microsoft Entra ID. Si votre instance AD FS est fortement personnalisée et s’appuie sur des paramètres de personnalisation spécifiques dans le fichier onload.js, vérifiez si Microsoft Entra ID peut répondre à vos besoins actuels en matière de personnalisation et planifiez en conséquence. Communiquez ces modifications à venir à vos utilisateurs.
Expérience de connexion
Vous ne pouvez pas personnaliser l’expérience de connexion Microsoft Entra. Quelle que soit la façon dont vos utilisateurs se sont connectés précédemment, vous avez besoin d’un nom de domaine complet, comme un nom d’utilisateur principal (UPN) ou un e-mail pour vous connecter à Microsoft Entra ID.
Personnalisation de l’organisation
Vous pouvez personnaliser la page de connexion Microsoft Entra. Certaines modifications visuelles sur les pages de connexion d’AD FS doivent être attendues après la conversion.
Note
La personnalisation de l’organisation n’est pas disponible dans les licences Microsoft Entra ID gratuites, sauf si vous disposez d’une licence Microsoft 365.
Planifier les stratégies d’accès conditionnel
Évaluez si vous utilisez actuellement l’accès conditionnel pour l’authentification, ou si vous utilisez des stratégies de contrôle d’accès dans AD FS.
Envisagez de remplacer les stratégies de contrôle d’accès AD FS par les stratégies d’accès conditionnel Microsoft Entra équivalentes et les règles d’accès client Exchange Online. Vous pouvez utiliser Microsoft Entra ID ou des groupes locaux pour l’accès conditionnel.
Désactiver l’authentification héritée : en raison du risque accru associé aux protocoles d’authentification hérités, créez une stratégie d’accès conditionnel pour bloquer l’authentification héritée.
Planifier la prise en charge de l’authentification multifacteur
Pour les domaines fédérés, l’authentification MFA peut être appliquée par l’accès conditionnel Microsoft Entra ou par le fournisseur de fédération local. Vous pouvez activer la protection pour empêcher le contournement de l’authentification multifacteur Microsoft Entra en configurant le paramètre de sécurité federatedIdpMfaBehavior. Activez la protection d’un domaine fédéré dans votre locataire Microsoft Entra. Assurez-vous que l’authentification multifacteur Microsoft Entra soit toujours effectuée quand un utilisateur fédéré accède à une application régie par une stratégie d’accès conditionnel nécessitant une MFA. Cela inclut l’exécution de l’authentification multifacteur Microsoft Entra, même lorsque le fournisseur d’identité fédérée a émis des revendications de jeton fédéré que l’authentification multifacteur locale a été effectuée. L’application de l’authentification multifacteur Microsoft Entra à chaque fois garantit qu’aucun intervenant malveillant ne peut la contourner en imitant le fournisseur d’identité qui a déjà effectué la MFA. Cette pratique est fortement recommandée, sauf si vous effectuez une MFA pour vos utilisateurs fédérés à l’aide d’un fournisseur MFA tiers.
Le tableau suivant explique le comportement de chaque option. Pour plus d’informations, consultez federatedIdpMfaBehavior.
| Valeur | Descriptif |
|---|---|
| acceptIfMfaDoneByFederatedIdp | Microsoft Entra ID accepte l’authentification multifacteur effectuée par le fournisseur d’identité fédérée. Si le fournisseur d’identité fédérée n’a pas effectué l’authentification multifacteur, Microsoft Entra ID s’en charge. |
| enforceMfaByFederatedIdp | Microsoft Entra ID accepte l’authentification multifacteur effectuée par le fournisseur d’identité fédérée. Si le fournisseur d’identité fédérée n’a pas effectué l’authentification multifacteur, il redirige la demande vers le fournisseur d’identité fédérée pour qu’il s’en charge. |
| rejectMfaByFederatedIdp | Microsoft Entra ID effectue toujours une authentification multifacteur et rejette celle que le fournisseur d’identité fédérée effectue. |
Le paramètre federatedIdpMfaBehavior est une version évoluée de la propriété SupportsMfa de l’applet de commande PowerShell MSOnline v1Set-MsolDomainFederationSettings.
Pour les domaines qui ont déjà défini la propriété SupportsMfa , ces règles déterminent comment federatedIdpMfaBehavior et SupportsMfa fonctionnent ensemble :
- Le basculement entre federatedIdpMfaBehavior et SupportsMfa n’est pas pris en charge.
- Une fois la propriété federatedIdpMfaBehavior définie, l’ID Microsoft Entra ignore le paramètre SupportsMfa .
- Si la propriété federatedIdpMfaBehavior n’est jamais définie, l’ID Microsoft Entra continue d’honorer le paramètre SupportsMfa .
- Si ni federatedIdpMfaBehavior ni SupportsMfa ne sont définis, le comportement par défaut de Microsoft Entra ID est
acceptIfMfaDoneByFederatedIdp.
Vous pouvez vérifier l’état de la protection en exécutant Get-MgDomainFederationConfiguration :
Get-MgDomainFederationConfiguration -DomainId yourdomain.com
Planifier l’implémentation
Cette section inclut le travail préalable à effectuer avant de basculer votre méthode de connexion et de convertir les domaines.
Créer les groupes nécessaires pour le déploiement par étapes
Si vous n’utilisez pas de déploiement intermédiaire, ignorez cette étape.
Créez des groupes pour un déploiement par étapes, mais aussi pour les stratégies d’accès conditionnel si vous décidez d’en ajouter.
Nous vous recommandons d’utiliser un groupe maître dans Microsoft Entra ID, également appelé groupe cloud uniquement. Vous pouvez utiliser des groupes de sécurité Microsoft Entra ou des groupes Microsoft 365 pour déplacer les utilisateurs vers l’authentification multifacteur et pour les stratégies d’accès conditionnel. Pour plus d’informations, consultez la création d’un groupe de sécurité Microsoft Entra et cette vue d’ensemble des groupes Microsoft 365 pour les administrateurs.
Les membres d’un groupe sont automatiquement activés pour le déploiement par étapes. Les groupes d’appartenances dynamiques et imbriqués ne sont pas pris en charge dans le déploiement par étapes.
Travail préalable d’authentification unique
La version d’authentification unique que vous utilisez dépend du système d’exploitation de votre appareil et de l’état de jointure.
Pour Windows 10, Windows Server 2016 et versions ultérieures, nous vous recommandons d’utiliser l’authentification unique via le jeton d’actualisation principal (PRT) avec des appareils joints à Microsoft Entra, des appareils joints à Microsoft Entra hybrides et des appareils inscrits à Microsoft Entra.
Pour les appareils macOS et iOS, nous vous recommandons d’utiliser l’authentification unique via le plug-in Microsoft Enterprise SSO pour les appareils Apple. Cette fonctionnalité nécessite que vos appareils Apple soient gérés par une GPM. Si vous utilisez Intune comme GPM, suivez le guide de déploiement Microsoft Enterprise SSO pour Apple Intune. Si vous utilisez un autre MDM, suivez le guide de déploiement Jamf Pro / MDM générique.
Pour les appareils Windows 7 et 8.1, nous vous recommandons d’utiliser le SSO sans interruption avec une connexion au domaine afin d'inscrire l'ordinateur dans Microsoft Entra ID. Vous n’avez pas à synchroniser ces comptes comme pour les appareils Windows 10. Toutefois, vous devez effectuer ce travail préparatoire pour l’authentification unique sans heurts à l’aide de PowerShell.
Travail préalable pour PHS et PTA
Selon le choix de la méthode de connexion, effectuez le travail préalable pour PHS ou pour PTA.
Implémenter votre solution
Enfin, vous devez basculer la méthode de connexion sur PHS ou PTA, comme prévu, et convertir les domaines de la fédération en authentification cloud.
Utilisation du déploiement par étapes
Si vous utilisez le déploiement par étapes, suivez les étapes indiquées dans les liens ci-dessous :
Activez le déploiement intermédiaire d’une fonctionnalité spécifique sur votre locataire.
Une fois le test terminé, convertissez les domaines de fédérés à gérés.
Sans déploiement par étapes
Vous avez deux options pour permettre ce changement :
Option A : basculer à l’aide de Microsoft Entra Connect.
Disponible si vous avez initialement configuré votre environnement AD FS/ping fédéré à l’aide de Microsoft Entra Connect.
Option B : Basculer à l’aide de Microsoft Entra Connect et de PowerShell
Disponible si vous n’avez pas initialement configuré vos domaines fédérés à l’aide de Microsoft Entra Connect ou si vous utilisez des services de fédération tiers.
Pour choisir l’une de ces options, vous devez connaître vos paramètres actuels.
Vérifier les paramètres Microsoft Entra Connect actuels
Connectez-vous au Centre d’administration Microsoft Entra en tant qu’administrateur d’identité hybride au moins.
Accédez à Entra ID>Entra Connect>Cloud Sync.
- Vérifiez les paramètres SIGN_IN USER , comme indiqué dans ce diagramme :
Pour vérifier comment la fédération a été configurée :
Sur votre serveur Microsoft Entra Connect, ouvrez Microsoft Entra Connect , puis sélectionnez Configurer.
Sous Tâches supplémentaires > gérer la fédération, sélectionnez Afficher la configuration de fédération.
Si la configuration d’AD FS apparaît dans cette section, vous pouvez considérer qu’AD FS a été initialement configuré à l’aide de Microsoft Entra Connect. Consultez l’image ci-dessous comme exemple :
Si AD FS n’est pas listé dans les paramètres actuels, vous devez convertir manuellement vos domaines de l’identité fédérée à l’identité managée avec PowerShell.
Option A
Passer de la fédération à la nouvelle méthode de connexion à l’aide de Microsoft Entra Connect
Sur votre serveur Microsoft Entra Connect, ouvrez Microsoft Entra Connect , puis sélectionnez Configurer.
Dans la page Tâches supplémentaires , sélectionnez Modifier la connexion de l’utilisateur, puis sélectionnez Suivant.
Dans la page Se connecter à Microsoft Entra ID , entrez les informations d’identification de votre compte Administrateur général.
Dans la page de connexion de l’utilisateur :
Si vous sélectionnez le bouton d’option d’authentification directe, et si l’authentification unique est nécessaire pour les appareils Windows 7 et 8.1, cochez Activerl’authentification unique, puis sélectionnez Suivant.
Si vous activez le bouton d’option de synchronisation de hachage de mot de passe , veillez à activer la case à cocher Ne pas convertir les comptes d’utilisateur . L’option est dépréciée. Si l’authentification unique est nécessaire pour les appareils Windows 7 et 8.1, activez l’authentification unique, puis sélectionnez Suivant.
En savoir plus : Activer l’authentification unique transparente à l’aide de PowerShell.
Dans la page Activer l’authentification unique , entrez les informations d’identification d’un compte Administrateur de domaine, puis sélectionnez Suivant.
Les informations d’identification du compte d’administrateur de domaine sont nécessaires pour activer l’authentification unique fluide. Le processus effectue les actions suivantes, qui nécessitent ces autorisations élevées :
- Un compte d’ordinateur nommé AZUREADSSO (qui représente Microsoft Entra ID) est créé dans votre instance Active Directory locale.
- La clé de déchiffrement Kerberos du compte d’ordinateur est partagée de façon sécurisée avec Microsoft Entra ID.
- Deux noms de principal du service Kerberos sont créés pour représenter les deux URL utilisées lors de la connexion à Microsoft Entra.
Les informations d’identification d’administrateur de domaine ne sont pas stockées dans Microsoft Entra Connect ou Microsoft Entra ID et sont supprimées une fois le processus terminé. Elles sont utilisées pour activer cette fonctionnalité.
En savoir plus : Présentation approfondie technique transparente de l’authentification unique.
Dans la page Prêt à configurer , vérifiez que la case à cocher Démarrer le processus de synchronisation lorsque la configuration se termine est cochée. Ensuite, sélectionnez Configurer.
Importante
À ce stade, tous vos domaines fédérés passent à l’authentification managée. Votre méthode de connexion utilisateur sélectionnée est la nouvelle méthode d’authentification.
Dans le Centre d’administration Microsoft Entra, sélectionnez l’ID Microsoft Entra, puis Microsoft Entra Connect.
Vérifiez ces paramètres :
- Fédération est défini sur Désactivé.
- L’authentification unique transparente est activée.
- La synchronisation de hachage de mot de passe est activée.
Si vous passez à PTA, effectuez les étapes suivantes.
Déployer davantage d’agents d’authentification pour PTA
Note
Pour bénéficier de l’authentification directe, vous devez déployer des agents légers sur le serveur Microsoft Entra Connect et sur vos serveurs locaux qui exécutent Windows Server. Pour réduire la latence, installez les agents aussi près que possible de vos contrôleurs de domaine Active Directory.
Pour la plupart des clients, deux ou trois agents d’authentification suffisent à offrir la haute disponibilité et la capacité nécessaire. Un locataire peut avoir un maximum de 12 agents inscrits. Le premier agent est toujours installé sur le serveur Microsoft Entra Connect lui-même. Pour en savoir plus sur les limitations de l’agent et les options de déploiement d’agent, consultez l’authentification directe Microsoft Entra : Limitations actuelles.
Sélectionnez l’authentification directe.
Dans la page d’authentification directe , sélectionnez le bouton Télécharger .
Sur la page Télécharger l’agent, sélectionnez Accepter les termes et télécharger.f
Le téléchargement des agents d’authentification supplémentaires démarre. Installez l’agent d’authentification secondaire sur un serveur joint à un domaine.
Exécutez l’installation de l’agent d’authentification. Lors de l’installation, vous devez fournir les informations d’identification d’un compte d’administrateur général.
Lorsque l’agent d’authentification est installé, vous pouvez revenir à la page d’intégrité de PTA pour vérifier l’état des autres agents.
Option B
Passer de la fédération à la nouvelle méthode de connexion à l’aide de Microsoft Entra Connect et de PowerShell
Disponible si vous n’avez pas initialement configuré vos domaines fédérés à l’aide de Microsoft Entra Connect ou si vous utilisez des services de fédération tiers.
Sur votre serveur Microsoft Entra Connect, suivez les étapes 1 à 5 dans l’option A. Notez que dans la page de connexion utilisateur, l’option Ne pas configurer est préélectionnée.
Dans le Centre d’administration Microsoft Entra, sélectionnez l’ID Microsoft Entra, puis Microsoft Entra Connect.
Vérifiez ces paramètres :
Fédération est défini sur Activé.
L’authentification unique transparente est définie sur Désactivé.
La synchronisation de hachage de mot de passe est activée.
En cas de PTA uniquement, procédez comme suit pour installer d’autres serveurs d’agents PTA.
Dans le Centre d’administration Microsoft Entra, sélectionnez l’ID Microsoft Entra, puis Microsoft Entra Connect.
Sélectionnez l’authentification directe. Vérifiez que l’état est Actif.
Si l’agent d’authentification n’est pas actif, effectuez ces étapes de résolution des problèmes avant de poursuivre le processus de conversion de domaine à l’étape suivante. Vous risquez d’entraîner une panne d’authentification si vous convertissez vos domaines avant de vérifier que vos agents PTA sont correctement installés et que leur état est Actif dans le Centre d’administration Microsoft Entra.
Convertir les domaines fédérés en domaines managés
À ce stade, l’authentification fédérée est toujours active et opérationnelle pour vos domaines. Pour poursuivre le déploiement, vous devez convertir chaque domaine de l’identité fédérée en identité managée.
Importante
Vous n’êtes pas obligé de convertir tous les domaines en même temps. Vous pouvez choisir de démarrer avec un domaine de test sur votre locataire de production ou de démarrer avec votre domaine qui a le plus petit nombre d’utilisateurs.
Terminez la conversion à l’aide du Kit de développement logiciel (SDK) Microsoft Graph PowerShell :
Dans PowerShell, connectez-vous à Microsoft Entra ID à l’aide d’un compte Administrateur général.
Connect-MGGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"Pour convertir le premier domaine, exécutez la commande suivante :
Update-MgDomain -DomainId <domain name> -AuthenticationType "Managed"Dans le Centre d’administration Microsoft Entra, sélectionnez Microsoft Entra ID > Microsoft Entra Connect.
Vérifiez que le domaine a été converti en domaine managé en exécutant la commande ci-dessous. Le type d’authentification doit être défini sur géré.
Get-MgDomain -DomainId yourdomain.com
Pour vous assurer que Microsoft Entra Connect reconnaît l’authentification directe comme activée après la conversion de votre domaine en authentification gérée, mettez à jour les paramètres de méthode de connexion dans Microsoft Entra Connect pour refléter les modifications. Pour plus d’informations, reportez-vous à la documentation d’authentification directe de Microsoft Entra .
Terminer votre migration
Effectuez les tâches suivantes pour vérifier la méthode d’inscription et terminer le processus de conversion.
Tester la nouvelle méthode de connexion
Quand votre locataire utilisait l’identité fédérée, les utilisateurs étaient redirigés de la page de connexion de Microsoft Entra vers votre environnement AD FS. Maintenant que le locataire est configuré pour utiliser la nouvelle méthode de connexion au lieu de l’authentification fédérée, les utilisateurs ne sont pas redirigés vers AD FS.
Au lieu de cela, les utilisateurs se connectent directement sur la page de connexion Microsoft Entra.
Suivez les étapes décrites dans ce lien : valider la connexion avec PHS/PTA et l’authentification unique transparente (si nécessaire)
Supprimer un utilisateur du déploiement par étapes
Si vous avez utilisé le déploiement par étapes, n’oubliez pas de désactiver ses fonctionnalités une fois que vous avez terminé le basculement.
Pour désactiver la fonctionnalité de déploiement intermédiaire, faites glisser le contrôle vers Désactivé.
Synchroniser les mises à jour de userPrincipalName
Historiquement, les mises à jour apportées à l’attribut UserPrincipalName , qui utilise le service de synchronisation à partir de l’environnement local, sont bloquées, sauf si ces deux conditions sont remplies :
- L’utilisateur est dans un domaine d’identité (non fédérée) managée.
- Aucune licence n’a été affectée à l’utilisateur.
Pour savoir comment vérifier ou activer cette fonctionnalité, consultez Synchroniser les mises à jour userPrincipalName.
Gérer l’implémentation
Substituer la clé de déchiffrement Kerberos pour l’authentification unique fluide
Nous vous recommandons de changer la clé de déchiffrement Kerberos au moins tous les 30 jours, pour vous aligner sur la façon dont les membres du domaine Active Directory soumettent des changements de mot de passe. Comme aucun appareil n’est associé à l’objet de compte d’ordinateur AZUREADSSO, vous devez effectuer ce changement de clé manuellement.
Voir la FAQ : Comment puis-je substituer la clé de déchiffrement Kerberos du compte d’ordinateur AZUREADSSO ?.
Surveillance et journalisation
Surveillez les serveurs qui exécutent les agents d’authentification pour conserver la disponibilité de la solution. En plus des compteurs de performance généraux du serveur, les agents d’authentification exposent des objets de performance qui peuvent être utilisés pour comprendre les erreurs et les statistiques associées à l’authentification.
Les agents d’authentification consignent les opérations dans les journaux des événements Windows sous Application and Service Logs. Vous pouvez également activer la journalisation pour le dépannage.
Pour confirmer les différentes actions effectuées lors du déploiement par étapes, vous pouvez Vérifier les événements pour PHS, PTA ou authentification unique fluide.
Dépanner
Votre équipe de support doit comprendre comment résoudre les problèmes d’authentification qui surviennent pendant ou après le passage de l’authentification fédérée à l’authentification managée. Utilisez la documentation de dépannage suivante pour aider votre équipe de support à se familiariser avec les procédures de dépannage courantes, et les mesures à prendre pour isoler et résoudre le problème.
Désactiver l’infrastructure AD FS
Migrer l’authentification d’application d’AD FS vers Microsoft Entra ID
La migration exige l’évaluation de la configuration locale de l’application, puis le mappage de cette configuration dans Microsoft Entra ID.
Si vous envisagez de continuer à utiliser AD FS avec des applications SaaS locales à l’aide de protocoles SAML / WS-FED ou OAuth, vous utiliserez à la fois AD FS et Microsoft Entra ID après avoir converti les domaines pour l’authentification utilisateur. Dans ce cas, vous pouvez protéger vos applications et ressources locales avec l’accès hybride sécurisé (SHA) via le proxy d’application Microsoft Entra ou l’une des intégrations de partenaires Microsoft Entra ID. À l’aide du Proxy d’application ou d’un de nos partenaires, vous pouvez fournir un accès à distance sécurisé à vos applications locales. Les utilisateurs bénéficient de la connexion facile à leurs applications à partir de n’importe quel appareil après une authentification unique. Pour plus d’informations, consultez Activer l’authentification unique pour une application d’entreprise avec un service de jeton de sécurité de tiers de confiance.
Vous pouvez déplacer les applications SaaS actuellement fédérées avec ADFS vers Microsoft Entra ID. Reconfigurez pour vous authentifier auprès de l’ID Microsoft Entra via un connecteur intégré à partir de la galerie d’applications Azure ou en inscrivant l’application dans l’ID Microsoft Entra.
Pour plus d’informations, consultez Déplacement de l’authentification d’application des services de fédération Active Directory vers l’ID Microsoft Entra.
Supprimer une approbation de partie de confiance
Si vous avez Microsoft Entra Connect Health, vous pouvez surveiller l’utilisation à partir du Centre d’administration Microsoft Entra. Si l’utilisation ne montre aucune nouvelle requête d’authentification et après avoir vérifié le bon fonctionnement de l’authentification de tous les utilisateurs et clients via Microsoft Entra ID, vous pouvez supprimer sans danger l’approbation de partie de confiance de Microsoft 365.
Si vous n’utilisez pas AD FS à d’autres fins (c’est-à-dire pour d’autres approbations de partie de confiance), vous pouvez mettre AD FS hors service sans problème.
Supprimer AD FS
Pour obtenir la liste complète des étapes à suivre pour supprimer complètement AD FS de l’environnement, suivez le guide de désactivation des services de fédération Active Directory (AD FS).