Partage via

Effectuer une migration vers l’authentification multifacteur Microsoft Entra et l’authentification utilisateur Microsoft Entra

  • Article

L’authentification MFA (authentification multifacteur) permet de sécuriser votre infrastructure et vos ressources contre les acteurs malveillants. Le Serveur Multi-Factor Authentication (Serveur MFA) de Microsoft n’est plus proposé pour les nouveaux déploiements. Les clients qui utilisent le Serveur MFA doivent passer à l’authentification multifacteur Microsoft Entra.

Plusieurs options sont disponibles pour migrer du Serveur MFA vers Microsoft Entra ID :

  • Bien : déplacement uniquement de votre service MFA vers Microsoft Entra ID.
  • Mieux : Déplacement de votre service MFA et de l’authentification utilisateur vers Microsoft Entra ID (traité dans cet article).
  • Meilleure : Déplacement de toutes vos applications, de votre service MFA et de l’authentification utilisateur vers Microsoft Entra ID. Consultez la section de cet article qui porte sur le déplacement des applications vers Microsoft Entra ID, si vous comptez déplacer des applications (traité dans cet article).

Pour sélectionner l’option de migration MFA appropriée dans le cadre de votre organisation, consultez les considérations relatives à la migration du serveur MFA vers l’authentification multifacteur Microsoft Entra.

Le diagramme suivant montre le processus qui permet de migrer vers l’authentification multifacteur Microsoft Entra et l’authentification cloud tout en conservant certaines applications sur AD FS. Ce processus permet la migration itérative des utilisateurs du serveur MFA vers l’authentification multifacteur Microsoft Entra en fonction de l’appartenance au groupe.

Chaque étape est expliquée dans les sections suivantes de cet article.

Remarque

Si vous prévoyez de déplacer des applications vers Microsoft Entra ID dans le cadre de cette migration, vous devez le faire avant la migration MFA. Si vous déplacez toutes vos applications, vous pouvez ignorer certaines sections du processus de migration MFA. Consultez la section relative au déplacement d’applications à la fin de cet article.

Processus de migration vers l’authentification multifacteur et Microsoft Entra ID

Processus de migration vers l’authentification multifacteur et Microsoft Entra ID.

Préparer les groupes et l’accès conditionnel

Les groupes sont utilisés à trois niveaux pour la migration MFA.

  • Pour déplacer de manière itérative les utilisateurs vers l’authentification multifacteur Microsoft Entra avec le déploiement par étapes.

    Utilisez un groupe créé dans Microsoft Entra ID, également appelé groupe cloud uniquement. Vous pouvez utiliser les groupes de sécurité Microsoft Entra ou les groupes Microsoft 365 pour le déplacement des utilisateurs vers l’authentification MFA ainsi que pour les stratégies d’accès conditionnel.

    Important

    Les groupes d’appartenance dynamique et imbriqués ne sont pas pris en charge pour le déploiement par étapes. N’utilisez pas ces types de groupe.

  • Stratégies d’accès conditionnel. Vous pouvez utiliser l’ID Microsoft Entra ou des groupes locaux pour l’accès conditionnel.

  • Pour appeler l’authentification multifacteur Microsoft Entra pour les applications AD FS avec des règles de revendications. Cette étape s’applique uniquement si vous utilisez des applications avec AD FS.

    Vous devez utiliser un groupe de sécurité Active Directory local. Une fois que l’authentification multifacteur Microsoft Entra est définie en tant que méthode d’authentification supplémentaire, vous pouvez désigner des groupes d’utilisateurs qui vont l’utiliser sur chaque approbation de partie de confiance. Par exemple, vous pouvez appeler l’authentification multifacteur Microsoft Entra pour les utilisateurs que vous avez déjà fait migrer, et le serveur MFA pour les utilisateurs qui n’ont pas encore été migrés. Cette stratégie est utile à la fois pour les tests et la migration.

Remarque

Nous vous déconseillons de réutiliser les groupes utilisés pour la sécurité. Utilisez uniquement le groupe de sécurité pour sécuriser un groupe d’applications très important avec une stratégie d’accès conditionnel.

Configurer des stratégies d’accès conditionnel

Si vous utilisez déjà l’accès conditionnel pour déterminer le moment où l’authentification MFA est proposée aux utilisateurs, vous n’avez pas à changer vos stratégies. Au fur et à mesure que les utilisateurs migrent vers l’authentification cloud, ils commencent à utiliser l’authentification multifacteur Microsoft Entra tel qu’elle est définie par vos stratégies d’accès conditionnel. Ils ne sont plus redirigés vers AD FS et le serveur MFA.

Si vos domaines fédérés ont l’indicateur federatedIdpMfaBehavior défini sur enforceMfaByFederatedIdp ou l’indicateur SupportsMfa défini sur $True (federatedIdpMfaBehaviorremplaceSupportsMfa lorsque les deux sont définis), vous appliquez probablement l’authentification multifacteur sur AD FS en utilisant des règles de revendications. Dans ce cas, vous devez analyser vos règles de revendication sur l’approbation de partie de confiance Microsoft Entra ID et créer des stratégies d’accès conditionnel qui prennent en charge les mêmes objectifs de sécurité.

Si nécessaire, configurez les stratégies d’accès conditionnel avant d’activer le déploiement par étapes. Pour plus d’informations, consultez les ressources suivantes :

Préparer AD FS

Si vous n’avez pas d’applications dans AD FS qui nécessitent une authentification MFA, vous pouvez ignorer cette section et accéder à la section Préparer le déploiement par étapes.

Mettre à niveau la batterie de serveurs AD FS vers FBL 4 2019

Dans AD FS 2019, Microsoft a publié une nouvelle fonctionnalité qui aide à spécifier des méthodes d’authentification supplémentaires pour une partie de confiance, par exemple une application. Vous pouvez spécifier une méthode d’authentification supplémentaire en utilisant l’appartenance au groupe pour déterminer le fournisseur d’authentification. En spécifiant une méthode d’authentification supplémentaire, vous pouvez effectuer une transition vers l’authentification multifacteur Microsoft Entra tout en conservant les autres méthodes d’authentification pendant la transition.

Pour plus d’informations, consultez Mise à niveau vers AD FS dans Windows Server 2016 à l’aide d’une base de données WID. L’article couvre à la fois la mise à niveau de votre batterie de serveurs vers AD FS 2019 et la mise à niveau de votre FBL vers la version 4.

Configurer des règles de revendication pour appeler l’authentification multifacteur Microsoft Entra

Maintenant que l’authentification multifacteur Microsoft Entra est une méthode d’authentification supplémentaire, vous pouvez affecter des groupes d’utilisateurs pour utiliser l’authentification multifacteur Microsoft Entra en configurant des règles de revendications, également appelées approbations de parties de confiance. À l’aide de groupes, vous pouvez déterminer quel est le fournisseur d’authentification appelé, globalement ou par application. Par exemple, vous pouvez appeler l’authentification multifacteur Microsoft Entra pour les utilisateurs ayant accès à l’inscription combinée des informations de sécurité, ou dont les numéros de téléphone ont été migrés, et vous pouvez appeler le serveur MFA pour les utilisateurs dont les numéros de téléphone n’ont pas été migrés.

Remarque

Les règles de revendication nécessitent un groupe de sécurité local.

Sauvegarder des règles

Avant de configurer de nouvelles règles de revendication, sauvegardez vos règles. Vous devez restaurer les règles de revendication dans le cadre des étapes de nettoyage.

Selon votre configuration, vous devrez peut-être également copier la règle existante et ajouter les nouvelles règles créées pour la migration.

Pour voir les règles globales, exécutez :

Get-AdfsAdditionalAuthenticationRule

Pour voir les approbations de partie de confiance, exécutez la commande suivante en remplaçant RPTrustName par le nom de la règle de revendication d’approbation de partie de confiance :

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

Stratégies de contrôle d’accès

Remarque

Vous ne pouvez pas configurer les stratégies de contrôle d’accès pour appeler un fournisseur d’authentification spécifique en fonction de l’appartenance à un groupe.

Pour passer de vos stratégies de contrôle d’accès à des règles d’authentification supplémentaires, exécutez la commande suivante pour chacune de vos approbations de partie de confiance en utilisant le fournisseur d’authentification basé sur le serveur MFA :

Set-AdfsRelyingPartyTrust -**TargetName AppA -AccessControlPolicyName $Null**

Cette commande permet de déplacer la logique de votre stratégie de contrôle d’accès actuelle vers des règles d’authentification supplémentaires.

Configurer le groupe et rechercher le SID

Vous devez disposer d’un groupe spécifique dans lequel vous placez les utilisateurs pour lesquels vous souhaitez appeler l’authentification multifacteur Microsoft Entra. Vous aurez besoin de trouver le SID (identificateur de sécurité) de ce groupe. Pour trouver le SID du groupe, exécutez la commande suivante en remplaçant GroupName par le nom de groupe :

Get-ADGroup GroupName

Commande PowerShell Microsoft Graph pour obtenir le SID du groupe.

Définir les règles de revendication pour appeler l’authentification multifacteur Microsoft Entra

Les applets de commande Microsoft Graph suivantes appellent l’authentification multifacteur Microsoft Entra pour les utilisateurs du groupe qui ne font pas partie du réseau d’entreprise. Vous devez remplacer "YourGroupSid" par le SID retourné par l’applet de commande précédent.

Veillez à consulter le Guide pratique pour choisir des fournisseurs d’authentification supplémentaires dans la version 2019.

Important

Sauvegardez vos règles de revendications avant de continuer.

Définir la règle de revendication globale

Exécutez la commande suivante en remplaçant RPTrustName par le nom de la règle de revendication d’approbation de partie de confiance :

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

La commande retourne vos règles d’authentification supplémentaires actuelles pour l’approbation de partie de confiance.
Vous devez ajouter les règles suivantes à vos règles de revendication actuelles :

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

L’exemple suivant suppose que vos règles de revendication actuelles sont configurées pour demander une authentification MFA quand les utilisateurs se connectent depuis l’extérieur de votre réseau. Cet exemple inclut les règles supplémentaires que vous devez ajouter.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == 
"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"https://schemas.microsoft.com/claims/multipleauthn" );
 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'
Définir une règle de revendication par application

Cet exemple modifie les règles de revendication d’une approbation de partie de confiance spécifique (application). Il comprend les règles supplémentaires que vous devez ajouter.

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == 
"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"https://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Configurer l’authentification multifacteur Microsoft Entra en tant que fournisseur d’authentification dans AD FS

Pour configurer l’authentification multifacteur Microsoft Entra pour AD FS, vous devez configurer chacun des serveurs AD FS. Si plusieurs serveurs AD FS se trouvent dans votre batterie, vous pouvez les configurer à distance avec Microsoft Graph PowerShell.

Pour obtenir des instructions pas à pas sur ce processus, consultez Configurer les serveurs AD FS.

Une fois que vous avez configuré les serveurs, vous pouvez ajouter l’authentification multifacteur Microsoft Entra en tant que méthode d’authentification supplémentaire.

Capture d’écran montrant comment ajouter l’authentification multifacteur Microsoft Entra en tant que méthode d’authentification supplémentaire.

Préparer le déploiement par étapes

Vous êtes maintenant prêt à activer le déploiement par étapes. Le déploiement par étapes vous aide à déplacer de manière itérative vos utilisateurs vers l’authentification PHS ou l’authentification PTA tout en migrant leurs paramètres MFA locaux.

Inscrire des utilisateurs pour l’authentification multifacteur Microsoft Entra

Cette section explique comment les utilisateurs peuvent effectuer l’inscription combinée des informations de sécurité (MFA et réinitialisation de mot de passe en libre-service) et comment migrer leurs paramètres MFA. Microsoft Authenticator peut être utilisé en mode sans mot de passe. Elle peut également être utilisée en tant que second facteur pour l’authentification MFA avec l’une ou l’autre des méthodes d’inscription.

Nous vous recommandons d’inviter les utilisateurs à effectuer l’inscription combinée des informations de sécurité. Ils disposent ainsi d’un seul emplacement où inscrire leurs méthodes et appareils d’authentification pour MFA et SSPR.

Microsoft propose des modèles de communication que vous pouvez fournir aux utilisateurs pour les guider tout au long du processus d’inscription combinée. Il s’agit notamment de modèles d’e-mails, d’affiches, de fiches cartonnées et de diverses autres ressources. Les utilisateurs inscrivent leurs informations sur https://aka.ms/mysecurityinfo, ce qui les amène à l’écran d’inscription combinée des informations de sécurité.

Nous vous recommandons de sécuriser le processus d’inscription des informations de sécurité par un accès conditionnel qui oblige l’utilisateur à effectuer l’inscription à partir d’un appareil ou d’un emplacement approuvé. Pour plus d’informations sur le suivi des états d’inscription, consultez Activité des méthodes d’authentification pour Microsoft Entra ID.

Remarque

Les utilisateurs qui DOIVENT effectuer l’inscription combinée de leurs informations de sécurité à partir d’un emplacement ou d’un appareil non approuvé peuvent se voir délivrer un passe d’accès temporaire, ou peuvent éventuellement être exclus temporairement de la stratégie.

Migrer les paramètres MFA à partir du serveur MFA

Vous pouvez recourir à l’utilitaire de migration du serveur MFA afin de synchroniser les paramètres MFA inscrits pour les utilisateurs du serveur MFA vers Microsoft Entra ID. Vous pouvez synchroniser les numéros de téléphone, les jetons matériels et les inscriptions d’appareils, telles que les paramètres de l’application Microsoft Authenticator.

Ajouter des utilisateurs aux groupes appropriés

  • Si vous avez créé des stratégies d’accès conditionnel, ajoutez les utilisateurs appropriés à ces groupes.
  • Si vous avez créé des groupes de sécurité locaux pour les règles de revendication, ajoutez les utilisateurs appropriés à ces groupes.
  • Une fois que vous avez ajouté les utilisateurs aux règles d’accès conditionnel appropriées, ajoutez-les au groupe que vous avez créé pour le déploiement par étapes. Une fois l’opération effectuée, les utilisateurs se voient appliquer la méthode d’authentification Azure que vous avez sélectionnée (PHS ou PTA) et l’authentification multifacteur Microsoft Entra quand ils doivent effectuer l’authentification multifacteur.

Important

Les groupes d’appartenance dynamique et imbriqués ne sont pas pris en charge pour le déploiement par étapes. N’utilisez pas ces types de groupe.

Nous vous déconseillons de réutiliser les groupes utilisés pour la sécurité. Si vous utilisez un groupe de sécurité pour sécuriser un groupe d’applications très important avec une stratégie d’accès conditionnel, n’utilisez que le groupe qu’à cette seule fin.

Surveillance

De nombreux classeurs Azure Monitor et rapports d’utilisation et d’insights sont disponibles pour vous permettre de superviser le déploiement. Vous trouverez ces rapports dans Microsoft Entra ID, dans le volet de navigation sous Supervision.

Supervision du déploiement par étapes

Dans la section classeurs, sélectionnez Modèles publics. Sous la section Authentification hybride, sélectionnez le classeur Groupes, utilisateurs et connexions dans le déploiement par étapes.

Vous pouvez utiliser ce classeur pour superviser les activités suivantes :

  • Utilisateurs et groupes ajoutés au déploiement par étapes.
  • Utilisateurs et groupes supprimés du déploiement par étapes.
  • Échecs de connexion des utilisateurs dans le déploiement par étapes, et raisons de ces échecs.

Superviser l’inscription à l’authentification multifacteur Microsoft Entra

Vous pouvez superviser l’inscription à l’authentification multifacteur Microsoft Entra en utilisant le rapport d’utilisation et d’insights des méthodes d’authentification. Ce rapport est disponible dans Microsoft Entra ID. Sélectionnez Supervision, puis Utilisation et insights.

Capture d’écran montrant comment trouver le rapport d’utilisation et d’insights.

Dans Utilisation et insights, sélectionnez Méthodes d’authentification.

Des informations détaillées sur l’inscription à l’authentification multifacteur Microsoft Entra sont disponibles sous l’onglet Inscription. Vous pouvez descendre dans la hiérarchie pour voir la liste des utilisateurs inscrits en sélectionnant le lien hypertexte Utilisateurs compatibles avec l’authentification multifacteur Azure.

Capture d’écran de l’onglet Inscription.

Supervision de l’intégrité des connexions aux applications

Supervisez les applications que vous avez déplacées vers Microsoft Entra ID avec le classeur d’intégrité des connexions aux applications ou le rapport d’utilisation relatif à l’activité des applications.

  • Classeur d’intégrité des connexions aux applications. Pour obtenir des conseils d’aide sur l’utilisation de ce classeur, consultez Supervision de l’intégrité de connexion de l’application pour la résilience.
  • Rapport d’utilisation relatif à l’activité des applications Microsoft Entra. Ce rapport permet d’afficher les connexions réussies et non réussies pour des applications individuelles. Il permet également d’explorer et d’afficher l’activité relative aux connexions pour une application spécifique.

Tâches de nettoyage

Après avoir déplacé tous les utilisateurs vers l’authentification cloud et l’authentification multifacteur Microsoft Entra, vous êtes prêt à désactiver votre serveur MFA. Nous vous recommandons de passer en revue les journaux du serveur MFA pour vérifier qu’aucun utilisateur ou aucune application n’utilise le serveur avant sa suppression.

Convertir vos domaines en authentification managée

Vous devez à présent convertir vos domaines fédérés dans Microsoft Entra ID en domaines managés et supprimer la configuration de déploiement par étapes. Cette conversion garantit l’authentification cloud des nouveaux utilisateurs sans qu’ils soient ajoutés aux groupes de migration.

Restaurer les règles de revendication sur AD FS et supprimer le fournisseur d’authentification basé sur le serveur MFA

Suivez les étapes décrites sous Configurer des règles de revendication pour appeler l’authentification multifacteur Microsoft Entra afin de restaurer les règles de revendication sauvegardées et de supprimer les règles de revendication AzureMFAServerAuthentication.

Par exemple, supprimez la section suivante des règles :

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'

Désactiver le serveur MFA en tant que fournisseur d’authentification dans AD FS

Cette modification garantit que seule l’authentification multifacteur Microsoft Entra est utilisée comme fournisseur d’authentification.

  1. Ouvrez la Console de gestion AD FS.
  2. Sous Services, cliquez avec le bouton droit sur Méthodes d’authentification, puis sélectionnez Modifier les méthodes d’authentification multifacteur.
  3. Désactivez la case à cocher Serveur Azure Multi-Factor Authentication.

Désactiver le serveur MFA

Suivez le processus de désactivation de votre serveur d’entreprise pour supprimer les serveurs MFA de votre environnement.

Considérations éventuelles à prendre en compte au moment de la désactivation du serveur MFA :

  • Nous vous recommandons de passer en revue les journaux du serveur MFA pour vérifier qu’aucun utilisateur ou aucune application n’utilise le serveur avant sa suppression.
  • Désinstallez Serveur Multi-Factor Authentication à partir du Panneau de configuration du serveur.
  • Vous pouvez éventuellement nettoyer les journaux et les répertoires de données restants après les avoir sauvegardés au préalable.
  • Désinstallez le kit de développement logiciel du serveur Web d’authentification multifacteur, le cas échéant, notamment les fichiers restants situés dans les répertoires etpub\wwwroot\MultiFactorAuthWebServiceSdk et/ou MultiFactorAuth.
  • Pour les versions antérieures à la version 8.0.x du serveur MFA, vous devrez peut-être également supprimer le service web d’authentification multifacteur de l’application téléphonique.

Déplacer l'authentification des applications vers Microsoft Entra ID

Si vous migrez l’authentification des applications en totalité ainsi que l’authentification MFA et l’authentification utilisateur, vous pourrez supprimer des parties importantes de votre infrastructure locale, ce qui entraînera une réduction des coûts et des risques. Si vous migrez l’authentification des applications en totalité, vous pouvez ignorer la phase Préparer AD FS et simplifier la migration MFA.

Le processus de déplacement de l’authentification des applications dans sa totalité est illustré dans le diagramme suivant.

Effectuer la migration des applications vers l’authentification multifacteur Microsoft Entra.

Si vous ne pouvez pas déplacer toutes vos applications avant la migration, déplacez-en autant que possible avant de commencer. Pour plus d’informations sur la migration d’applications vers Azure, consultez Ressources pour la migration d’applications vers Microsoft Entra ID.

Étapes suivantes