Migration du serveur MFA
Cette rubrique explique comment migrer les paramètres MFA pour les utilisateurs Microsoft Entra à partir du serveur d’authentification multifacteur Microsoft Entra local vers l’authentification multifacteur Microsoft Entra.
Vue d’ensemble de la solution
L’utilitaire de migration de serveur MFA permet de synchroniser les données d’authentification multifacteur stockées dans le serveur d’authentification multifacteur Microsoft Entra local directement vers l’authentification multifacteur Microsoft Entra. Une fois les données d’authentification migrées vers l’ID Microsoft Entra, les utilisateurs peuvent effectuer une authentification multifacteur basée sur le cloud en toute transparence sans avoir à s’inscrire à nouveau ou à confirmer les méthodes d’authentification. Les administrateurs peuvent utiliser l’utilitaire de migration de serveur MFA pour cibler des utilisateurs uniques ou des groupes d’utilisateurs pour tester et contrôler le déploiement sans avoir à apporter de modifications à l’échelle du locataire.
Vidéo : Utilisation de l’utilitaire de migration de serveur MFA
Consultez notre vidéo pour obtenir une vue d’ensemble de l’utilitaire de migration de serveur MFA et de son fonctionnement.
Limitations et exigences
L’utilitaire de migration de serveur MFA nécessite l’installation d’une nouvelle build de la solution de serveur MFA sur votre serveur MFA principal. La build met à jour le fichier de données du serveur MFA et inclut le nouvel utilitaire de migration de serveur MFA. Vous n’avez pas besoin de mettre à jour le WebSDK ou le portail utilisateur. L’installation de la mise à jour ne démarre pas automatiquement la migration.
Note
L’utilitaire de migration de serveur MFA peut être exécuté sur un serveur MFA secondaire. Pour plus d’informations, consultez Exécuter un serveur MFA secondaire (facultatif).
L’utilitaire de migration de serveur MFA copie les données du fichier de base de données sur les objets utilisateur dans l’ID Microsoft Entra. Pendant la migration, les utilisateurs peuvent être ciblés pour l’authentification multifacteur Microsoft Entra à des fins de test avec un déploiement par étapes. La migration intermédiaire vous permet de tester sans apporter de modifications à vos paramètres de fédération de domaine. Une fois les migrations terminées, vous devez finaliser votre migration en apportant des modifications à vos paramètres de fédération de domaine.
AD FS exécutant Windows Server 2016 ou une version ultérieure est nécessaire pour fournir l’authentification MFA sur toute partie de confiance AD FS, à l’exclusion de Microsoft Entra ID et d’Office 365.
Passez en revue vos stratégies de contrôle d’accès AD FS et vérifiez qu’aucune authentification multifacteur n’est nécessaire pour être effectuée localement dans le cadre du processus d’authentification.
Le déploiement intermédiaire peut cibler un maximum de 500 000 utilisateurs (10 groupes contenant un maximum de 50 000 utilisateurs chacun).
Guide de migration
Une migration de serveur MFA inclut généralement les étapes du processus suivant :
Quelques points importants :
La phase 1 doit être répétée quand vous ajoutez des utilisateurs de test.
- L’outil de migration utilise des groupes Microsoft Entra pour déterminer les utilisateurs pour lesquels les données d’authentification doivent être synchronisées entre MFA Server et l’authentification multifacteur Microsoft Entra. Une fois les données utilisateur synchronisées, cet utilisateur est alors prêt à utiliser l’authentification multifacteur Microsoft Entra.
- Le déploiement intermédiaire vous permet de rediriger les utilisateurs vers l’authentification multifacteur Microsoft Entra, également à l’aide de groupes Microsoft Entra. Bien que vous puissiez certainement utiliser les mêmes groupes pour les deux outils, nous vous recommandons de ne pas le faire, car les utilisateurs peuvent potentiellement être redirigés vers l’authentification multifacteur Microsoft Entra avant que l’outil ait synchronisé leurs données. Nous vous recommandons de configurer des groupes Microsoft Entra pour synchroniser les données d’authentification par l’utilitaire de migration de serveur MFA, et un autre ensemble de groupes pour le déploiement intermédiaire pour diriger les utilisateurs ciblés vers l’authentification multifacteur Microsoft Entra plutôt que localement.
La phase 2 doit être répétée quand vous migrez votre base d’utilisateurs. À la fin de la phase 2, votre base d’utilisateurs entière doit utiliser l’authentification multifacteur Microsoft Entra pour toutes les charges de travail fédérées par rapport à l’ID Microsoft Entra.
Pendant les phases précédentes, vous pouvez supprimer les utilisateurs des "Staged Rollout folders" pour les retirer de l'étendue de l'authentification multifacteur de Microsoft Entra et les réorienter vers votre serveur d'authentification multifacteur Microsoft Entra sur site pour toutes les demandes MFA provenant de l'ID Microsoft Entra.
phase 3 nécessite de déplacer tous les clients qui s’authentifient vers le serveur MFA local (VPN, gestionnaires de mots de passe, et ainsi de suite) vers la fédération Microsoft Entra via SAML/OAUTH. Si les normes d’authentification modernes ne sont pas prises en charge, vous devez mettre en place des serveurs NPS avec l’extension d’authentification multifacteur Microsoft Entra installée. Une fois les dépendances migrées, les utilisateurs ne doivent plus utiliser le portail utilisateur sur le serveur MFA, mais plutôt gérer leurs méthodes d’authentification dans Microsoft Entra ID (aka.ms/mfasetup). Une fois que les utilisateurs commencent à gérer leurs données d’authentification dans Microsoft Entra ID, ces méthodes ne sont pas synchronisées avec le serveur MFA. Si vous revenez au serveur MFA local une fois que les utilisateurs ont apporté des modifications à leurs méthodes d’authentification dans Microsoft Entra ID, ces modifications sont perdues. Une fois les migrations utilisateur terminées, modifiez le paramètre de fédération de domaine federatedIdpMfaBehavior. La modification indique à Microsoft Entra ID de ne plus effectuer de MFA localement et d’effectuer toutes les demandes de MFA avec l’authentification multifacteur Microsoft Entra, quel que soit le groupe d’appartenance.
Les sections suivantes expliquent plus en détail les étapes de migration.
Identifier les dépendances du serveur d’authentification multifacteur Microsoft Entra
Nous avons travaillé dur pour nous assurer que le passage à notre solution d’authentification multifacteur Microsoft Entra basée sur le cloud gère et améliore votre posture de sécurité. Il existe trois grandes catégories qui doivent être utilisées pour regrouper les dépendances :
Pour faciliter votre migration, nous avons mis en correspondance les fonctionnalités de serveur MFA largement utilisées avec l’équivalent fonctionnel dans l’authentification multifacteur Microsoft Entra pour chaque catégorie.
Méthodes MFA
Ouvrez le serveur MFA, sélectionnez Paramètres de l’entreprise :
| Serveur MFA | Authentification multifacteur Microsoft Entra |
|---|---|
| onglet Général | |
| Section Paramètres par défaut de l’utilisateur | |
| Appel téléphonique (standard) | Aucune action n’est nécessaire |
| Message texte (OTP)* | Aucune action n’est nécessaire |
| Application mobile (Standard) | Aucune action n’est nécessaire |
| Appel téléphonique (PIN)* | Activer le protocole OTP vocal |
| Message texte (OTP + CODE CONFIDENTIEL)** | Aucune action n’est nécessaire |
| Application mobile (PIN)* | Activer la correspondance de numéro |
| Appel téléphonique/sms/application mobile/langue du jeton OATH | Les paramètres linguistiques sont automatiquement appliqués à un utilisateur en fonction des paramètres régionaux dans leur navigateur |
| Section des règles par défaut pour le code PIN | Non applicable; voir les méthodes actualisées dans la capture d’écran précédente |
| Onglet Résolution du nom d’utilisateur | Non applicable ; la résolution de nom d’utilisateur n’est pas requise pour l’authentification multifacteur Microsoft Entra |
| Onglet de message texte | Non applicable ; l’authentification multifacteur Microsoft Entra utilise un message par défaut pour les SMS |
| Onglet Jeton OATH | Non applicable ; l’authentification multifacteur Microsoft Entra utilise un message par défaut pour les jetons OATH |
| Rapports | Rapports d’activité des méthodes d’authentification Microsoft Entra |
*Lorsqu’un code confidentiel est utilisé pour fournir des fonctionnalités de preuve de présence, l’équivalent fonctionnel est fourni ci-dessus. Les codes CONFIDENTIELs qui ne sont pas liés par chiffrement à un appareil ne protègent pas suffisamment contre les scénarios où un appareil a été compromis. Pour vous protéger contre ces scénarios, notamment les attaques d’échange de SIM, déplacez les utilisateurs vers des méthodes plus sécurisées en fonction des bonnes pratiques sur les méthodes d’authentification Microsoft.
**L’expérience MFA SMS par défaut dans l’authentification multifacteur Microsoft Entra envoie aux utilisateurs un code qu’ils doivent entrer dans la fenêtre de connexion dans le cadre de l’authentification. L’exigence consistant à soumettre le code à un aller-retour fournit une fonctionnalité de preuve de présence.
Portail utilisateur
Ouvrez le serveur MFA, sélectionnez portail utilisateur:
| Serveur MFA | Authentification multifacteur Microsoft Entra |
|---|---|
| Onglet Paramètres | |
| URL du portail utilisateur | aka.ms/mfasetup |
| Autoriser l’inscription des utilisateurs | Consultez Inscription d’informations de sécurité combinée |
| - Invite pour le téléphone de secours | Consultez Paramètres du service MFA |
| - Inviter à entrer un jeton OATH tiers | Consultez Paramètres du service MFA |
| Autoriser les utilisateurs à lancer un contournement à usage unique | Consultez Fonctionnalité TAP de Microsoft Entra ID |
| Autoriser les utilisateurs à sélectionner la méthode | Consultez Paramètres du service MFA |
| - Appel téléphonique | Consultez la documentation sur les appels téléphoniques |
| -SMS | Consultez Paramètres du service MFA |
| - Application mobile | Consultez Paramètres du service MFA |
| - Jeton OATH | Consultez la documentation sur les jetons OATH |
| Autoriser les utilisateurs à sélectionner la langue | Les paramètres linguistiques sont automatiquement appliqués à un utilisateur en fonction des paramètres régionaux dans leur navigateur |
| Autoriser les utilisateurs à activer l’application mobile | Consultez Paramètres du service MFA |
| - Limite de l’appareil | Microsoft Entra ID limite les utilisateurs à cinq appareils cumulatifs (instances d’application mobile + jeton OATH matériel + jeton OATH logiciel) par utilisateur |
| Utiliser les questions de sécurité comme recours | Microsoft Entra ID permet aux utilisateurs de choisir une méthode de secours au moment de l’authentification si la méthode d’authentification choisie échoue |
| - Questions à répondre | Les questions de sécurité dans l’ID Microsoft Entra ne peuvent être utilisées que pour SSPR. Découvrez-en plus sur les questions de sécurité personnalisées Microsoft Entra |
| Autoriser les utilisateurs à associer un jeton OATH tiers | Consultez la documentation sur les jetons OATH |
| Utiliser le jeton OATH comme solution de secours | Consultez la documentation sur les jetons OATH |
| Délai d’expiration de session | |
| onglet Questions de sécurité | Les questions de sécurité sur le serveur MFA ont été utilisées pour accéder au portail utilisateur. L’authentification multifacteur Microsoft Entra prend uniquement en charge les questions de sécurité relatives à la réinitialisation de mot de passe en libre-service. Consultez la documentation sur les questions de sécurité. |
| Onglet Sessions précédentes | Tous les flux d’inscription de méthode d’authentification sont gérés par l’ID Microsoft Entra et ne nécessitent pas de configuration |
| adresses IP approuvées | IP de confiance Microsoft Entra ID |
Toutes les méthodes MFA disponibles dans le serveur MFA doivent être activées dans l’authentification multifacteur Microsoft Entra en utilisant les paramètres du service MFA. Les utilisateurs ne peuvent pas essayer leurs méthodes MFA nouvellement migrées, sauf si elles sont activées.
Services d’authentification
Le serveur d’authentification multifacteur Microsoft Entra peut fournir des fonctionnalités MFA pour les solutions tierces qui utilisent RADIUS ou LDAP en agissant en tant que proxy d’authentification. Pour découvrir les dépendances RADIUS ou LDAP, cliquez sur les options Authentification RADIUS et Authentification LDAP dans le serveur MFA. Pour chacune de ces dépendances, déterminez si ces tiers prennent en charge l’authentification moderne. Si c’est le cas, envisagez la fédération directement avec l’ID Microsoft Entra.
Pour les déploiements RADIUS qui ne peuvent pas être mis à niveau, vous devez déployer un serveur NPS et installer l’extension NPS de l’authentification multifacteur Microsoft Entra.
Pour les déploiements LDAP qui ne peuvent pas être mis à niveau ou déplacés vers RADIUS, déterminez si Microsoft Entra Domain Services peut être utilisé. Dans la plupart des cas, LDAP a été déployé pour prendre en charge les modifications de mot de passe en ligne pour les utilisateurs finaux. Une fois migrés, les utilisateurs finaux peuvent gérer leurs mots de passe à l’aide de la réinitialisation de mot de passe en libre-service dans Microsoft Entra ID.
Si vous avez activé le fournisseur d’authentification du serveur MFA dans AD FS 2.0 sur les approbations de partie de confiance à l’exception de l’approbation de partie de confiance Office 365, vous devez effectuer une mise à niveau vers AD FS 3.0 ou fédérer ces parties de confiance directement à Microsoft Entra ID s’ils prennent en charge les méthodes d’authentification modernes. Déterminez le meilleur plan d’action pour chacune des dépendances.
Sauvegarder le fichier de données du serveur d’authentification multifacteur Microsoft Entra
Effectuez une sauvegarde du fichier de données du serveur MFA situé à %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (emplacement par défaut) sur votre serveur MFA principal. Vérifiez que vous disposez d’une copie du programme d’installation de votre version actuellement installée si vous devez restaurer. Si vous n’avez plus de copie, contactez les services de support technique.
Selon l’activité de l’utilisateur, le fichier de données peut devenir obsolète rapidement. Toutes les modifications apportées au serveur MFA ou les modifications apportées par l’utilisateur final via le portail après la capture de la sauvegarde ne seront pas capturées. Si vous effectuez une restauration, les modifications apportées après ce point ne seront pas restaurées.
Installer la mise à jour du serveur MFA
Exécutez le nouveau programme d’installation sur le serveur MFA principal. Avant de mettre à niveau un serveur, supprimez-le de l’équilibrage de charge ou du partage de trafic avec d’autres serveurs MFA. Vous n’avez pas besoin de désinstaller votre serveur MFA actuel avant d’exécuter le programme d’installation. Le programme d’installation effectue une mise à niveau sur place à l’aide du chemin d’installation actuel (par exemple, C :\Program Files\Multi-Factor Authentication Server). Si vous êtes invité à installer un package de mise à jour redistribuable Microsoft Visual C++ 2015, acceptez l’invite. Les versions x86 et x64 du package sont installées. Il n’est pas nécessaire d’installer les mises à jour pour le portail utilisateur, le Kit de développement logiciel (SDK) web ou l’adaptateur AD FS.
Note
Après avoir exécuté le programme d’installation sur votre serveur principal, les serveurs secondaires peuvent commencer à journaliser les entrées SB non gérées. Cela est dû aux modifications de schéma apportées sur le serveur principal qui ne sont pas reconnues par les serveurs secondaires. Ces erreurs sont attendues. Dans les environnements avec 10 000 utilisateurs ou plus, la quantité d’entrées de journal peut augmenter considérablement. Pour atténuer ce problème, vous pouvez augmenter la taille de fichier de vos journaux de serveur MFA ou mettre à niveau vos serveurs secondaires.
Configurer l’utilitaire de migration de serveur MFA
Après avoir installé la mise à jour du serveur MFA, ouvrez une invite de commandes PowerShell avec élévation de privilèges : pointez sur l’icône PowerShell, sélectionnez avec le bouton droit et sélectionnez Exécuter en tant qu’administrateur. Exécutez le fichier .\Configure-MultiFactorAuthMigrationUtility.ps1 script trouvé dans votre répertoire d’installation du serveur MFA (C :\Program Files\Serveur Multi-Factor Authentication par défaut).
Ce script vous demande de fournir des informations d’identification d’un administrateur d’application dans votre locataire Microsoft Entra. Il crée une application utilitaire de migration du serveur MFA au sein de Microsoft Entra ID, utilisée pour consigner les méthodes d'authentification des utilisateurs dans chaque objet utilisateur Microsoft Entra.
Pour les clients cloud gouvernementaux qui souhaitent effectuer des migrations, remplacez les entrées « .com » dans le script par . us ». Ce script écrit les entrées de Registre HKLM :\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl et GraphUrl et indique à l’utilitaire de migration d’utiliser les points de terminaison GRAPH appropriés.
Vous aurez également besoin d’accéder aux URL suivantes :
https://graph.microsoft.com/*(ouhttps://graph.microsoft.us/*pour les clients cloud gouvernementaux)https://login.microsoftonline.com/*(ouhttps://login.microsoftonline.us/*pour les clients cloud gouvernementaux)
Le script vous demande d’accorder le consentement de l’administrateur à l’application nouvellement créée. Accédez à l’URL fournie, ou dans le Centre d'administration Microsoft Entra, sélectionnez Inscription d’applications, recherchez et sélectionnez l’application Utilitaire de Migration de Serveur MFA, sélectionnez Autorisations d’API, puis accordez les autorisations appropriées.
Quand vous avez terminé, accédez au dossier du serveur Multi-Factor Authentication, puis ouvrez l’application MultiFactorAuthMigrationUtilityUI. L’écran suivant doit s’afficher :
Vous avez correctement installé l’utilitaire de migration.
Note
Pour garantir aucune modification du comportement lors de la migration, si votre serveur MFA est associé à un fournisseur MFA sans référence de locataire, vous devez mettre à jour les paramètres MFA par défaut (par exemple, les salutations personnalisées) du locataire que vous migrez pour correspondre aux paramètres de votre fournisseur MFA. Nous vous recommandons d’effectuer cette opération avant de migrer des utilisateurs.
Exécuter un serveur MFA secondaire (facultatif)
Si votre implémentation de serveur MFA a un grand nombre d’utilisateurs ou un serveur MFA principal occupé, vous pouvez envisager de déployer un serveur MFA secondaire dédié pour exécuter l’utilitaire de migration de serveur MFA et les services de synchronisation de migration. Après la mise à niveau de votre serveur MFA principal, mettez à niveau un serveur secondaire existant ou déployez un nouveau serveur secondaire. Le serveur secondaire que vous choisissez ne doit pas gérer d’autres trafics MFA.
Le script Configure-MultiFactorAuthMigrationUtility.ps1 doit être exécuté sur le serveur secondaire pour enregistrer un certificat avec l'application d'enregistrement de l'utilitaire de migration du serveur MFA. Le certificat est utilisé pour s’authentifier auprès de Microsoft Graph. L’exécution de l’utilitaire de migration et des services de synchronisation sur un serveur MFA secondaire doit améliorer les performances des migrations utilisateur manuelles et automatisées.
Migrer des données utilisateur
La migration des données utilisateur ne supprime ni ne modifie aucune donnée dans la base de données du serveur Multi-Factor Authentication. De même, ce processus ne changera pas lorsqu’un utilisateur effectue l’authentification multifacteur. Ce processus est une copie unidirectionnel des données du serveur local vers l’objet utilisateur correspondant dans l’ID Microsoft Entra.
L’utilitaire de migration de serveur MFA cible un seul groupe Microsoft Entra pour toutes les activités de migration. Vous pouvez ajouter des utilisateurs directement à ce groupe ou ajouter d’autres groupes. Vous pouvez également les ajouter en phases pendant la migration.
Pour commencer le processus de migration, entrez le nom ou le GUID du groupe Microsoft Entra que vous souhaitez migrer. Une fois terminé, appuyez sur Tab ou sélectionnez en dehors de la fenêtre pour commencer à rechercher le groupe approprié. Tous les utilisateurs du groupe sont renseignés. Un grand groupe peut prendre plusieurs minutes pour terminer.
Pour afficher les données d’attribut d’un utilisateur, mettez l’utilisateur en surbrillance, puis sélectionnez Afficher:
Cette fenêtre affiche les attributs de l’utilisateur sélectionné dans l’ID Microsoft Entra et le serveur MFA local. Vous pouvez utiliser cette fenêtre pour voir comment les données ont été écrites sur un utilisateur après la migration.
L’option paramètres vous permet de modifier les paramètres du processus de migration :
Migrer : il existe trois options pour migrer la méthode d’authentification par défaut de l’utilisateur :
- Toujours migrer
- Migrer uniquement s’il n’est pas déjà défini dans Microsoft Entra Identity
- Défini sur la méthode la plus sécurisée disponible s’il n’est pas déjà défini dans l’ID Microsoft Entra
Ces options offrent une flexibilité lorsque vous migrez la méthode par défaut. En outre, la stratégie de méthodes d’authentification est vérifiée pendant la migration. Si la méthode par défaut en cours de migration n’est pas autorisée par la stratégie, elle est définie sur la méthode la plus sécurisée disponible à la place.
Correspondance utilisateur : vous permet de spécifier un attribut Active Directory local différent pour la mise en correspondance de Microsoft Entra UPN au lieu de la correspondance par défaut avec userPrincipalName :
- L’utilitaire de migration tente de correspondre directement à UPN avant d’utiliser l’attribut Active Directory local.
- Si aucune correspondance n’est trouvée, il appelle une API Windows pour rechercher l’UPN Microsoft Entra et obtenir le SID, qu’il utilise pour rechercher la liste des utilisateurs du serveur MFA.
- Si l’API Windows ne trouve pas l’utilisateur ou si le SID n’est pas trouvé dans le serveur MFA, il utilise l’attribut Active Directory configuré pour rechercher l’utilisateur dans Active Directory local, puis utilisez le SID pour rechercher la liste des utilisateurs du serveur MFA.
Synchronisation automatique : démarre un service en arrière-plan qui surveille en permanence les modifications de méthode d’authentification apportées aux utilisateurs du serveur MFA local et les écrit dans l’ID Microsoft Entra à l’intervalle de temps spécifié défini.
Serveur de synchronisation : permet au service de synchronisation de migration du serveur MFA de s’exécuter sur un serveur MFA secondaire plutôt que d’exécuter uniquement sur le serveur principal. Pour configurer le service Migration Sync pour qu’il s’exécute sur un serveur secondaire, le script
Configure-MultiFactorAuthMigrationUtility.ps1doit être exécuté sur le serveur pour inscrire un certificat auprès de l’inscription de l’application MFA Server Migration Utility. Le certificat est utilisé pour s’authentifier auprès de Microsoft Graph.
Le processus de migration peut être automatique ou manuel.
Les étapes de processus manuelles sont les suivantes :
Pour commencer le processus de migration d’un utilisateur ou d’une sélection de plusieurs utilisateurs, appuyez longuement sur la touche Ctrl tout en sélectionnant chacun des utilisateurs que vous souhaitez migrer.
Après avoir sélectionné les utilisateurs souhaités, sélectionnez Migrer des utilisateurs>Utilisateurs sélectionnés>OK.
Pour migrer tous les utilisateurs du groupe, sélectionnez Migrer des utilisateurs>Tous les utilisateurs du groupe Microsoft Entra>OK.
Vous pouvez migrer des utilisateurs même s’ils ne sont pas modifiés. Par défaut, l’utilitaire est défini sur Migrer uniquement les utilisateurs qui ont changé. Sélectionnez Migrer tous les utilisateurs pour migrer à nouveau les utilisateurs précédemment migrés qui ne sont pas modifiés. La migration d’utilisateurs inchangés peut être utile lors du test si un administrateur doit réinitialiser les paramètres d’authentification multifacteur Microsoft Entra d’un utilisateur et souhaite les migrer à nouveau.
Pour le processus automatique, sélectionnez synchronisation automatique dans Paramètres, puis indiquez si tous les utilisateurs doivent être synchronisés ou uniquement des membres d’un groupe Microsoft Entra donné.
Le tableau suivant répertorie la logique de synchronisation pour les différentes méthodes.
| Méthode | Logique |
|---|---|
| Téléphone | En l’absence d’extension, mettez à jour le téléphone MFA. S'il y a une extension, mettez à jour le téléphone de bureau. Exception : si la méthode par défaut est Sms Message, supprimez l’extension et mettez à jour le téléphone MFA. |
| Téléphone de sauvegarde | En l'absence d'extension, mettez à jour le téléphone alternatif. S'il y a une prolongation, mettez à jour le téléphone de bureau. Exception : si Téléphone et Téléphone de secours ont une extension, ignorer Téléphone de secours. |
| Application mobile | Au maximum cinq appareils sont migrés ou seulement quatre si l’utilisateur a également un jeton OATH matériel. S’il existe plusieurs appareils portant le même nom, migrez uniquement la version la plus récente. Les appareils sont classés du plus récent au plus ancien. Si des appareils existent déjà dans Microsoft Entra ID, effectuer une correspondance sur la clé secrète de jeton OATH, puis une mise à jour. - S’il n’y a pas de correspondance sur la clé secrète de jeton OATH, effectuer une correspondance sur le jeton d’appareil -- Si une correspondance est trouvée, créer un jeton OATH logiciel pour l’appareil associé au serveur MFA afin de permettre le fonctionnement de la méthode de jeton OATH. Les notifications fonctionnent toujours à l’aide de l’appareil d’authentification multifacteur Microsoft Entra existant. -- S’il est introuvable, créez un nouvel appareil. Si l’ajout d’un nouvel appareil dépasse la limite de cinq appareils, l’appareil est ignoré. |
| Jeton OATH | Si des appareils existent déjà dans Microsoft Entra ID, effectuer une correspondance sur la clé secrète de jeton OATH, puis une mise à jour. - S’il n’y en a pas, ajouter un nouvel appareil de jeton OATH matériel. Si l’ajout d’un nouvel appareil dépasse la limite de cinq appareils, le jeton OATH est ignoré. |
Les méthodes MFA sont mises à jour en fonction de ce qui a été migré et la méthode par défaut est définie. Le serveur MFA suit l'horodatage de la dernière migration et ne migre à nouveau l'utilisateur que si les paramètres MFA changent ou si un administrateur modifie ce qu'il faut migrer dans la boîte de dialogue des paramètres .
Lors du test, nous vous recommandons d’effectuer une migration manuelle en premier et de vérifier qu’un nombre donné d’utilisateurs se comportent comme prévu. Une fois le test réussi, activez la synchronisation automatique pour le groupe Microsoft Entra que vous souhaitez migrer. Lorsque vous ajoutez des utilisateurs à ce groupe, leurs informations sont automatiquement synchronisées avec l’ID Microsoft Entra. L’utilitaire de migration de serveur MFA cible un groupe Microsoft Entra, mais ce groupe peut englober à la fois les utilisateurs et les groupes imbriqués d’utilisateurs.
Une fois terminée, une confirmation vous informe des tâches terminées :
Comme mentionné dans le message de confirmation, l’affichage des données migrées sur les objets utilisateur dans l’ID Microsoft Entra peut prendre plusieurs minutes. Les utilisateurs peuvent afficher leurs méthodes migrées en accédant à aka.ms/mfasetup.
Conseil
Vous pouvez réduire le temps nécessaire à l’affichage des groupes si vous n’avez pas besoin d’afficher les méthodes Microsoft Entra MFA. Cliquez sur Afficher>Méthodes Azure AD MFA pour activer/désactiver l’affichage des colonnes AAD par défaut, Numéro de téléphone AAD, Alternative AAD, Office AAD, Appareils AAD et Jeton AAD OATH. Lorsque des colonnes sont masquées, certains appels d’API Microsoft Graph sont ignorés, ce qui améliore considérablement le temps de chargement de l’utilisateur.
Afficher les détails de la migration
Utilisez les journaux d’audit ou Log Analytics pour afficher les détails des migrations d’utilisateurs depuis le serveur MFA vers Microsoft Entra Authentification Multifacteur.
Utiliser les journaux d’audit
Pour accéder aux journaux d’audit dans le Centre d’administration Microsoft Entra pour afficher les détails du serveur MFA vers les migrations utilisateur d’authentification multifacteur Microsoft Entra, procédez comme suit :
Connectez-vous au centre d’administration Microsoft Entra au moins en tant qu’administrateur d’authentification .
Accédez à Identité>Monitoring et intégrité>Journaux d’audit. Pour filtrer les journaux, cliquez sur Ajouter des filtres.
Sélectionnez initié par (acteur), puis sélectionnez Appliquer.
Tapez Gestion de l’authentification multifacteur Microsoft Entra et cliquez sur Appliquer.
Ce filtre affiche uniquement les journaux de l’utilitaire de migration de serveur MFA. Pour afficher les détails d’une migration utilisateur, sélectionnez une ligne, puis choisissez l’onglet Propriétés modifiées. Cet onglet affiche les modifications apportées aux méthodes MFA inscrites et aux numéros de téléphone.
Le tableau suivant répertorie la méthode d’authentification pour chaque code.
Code Méthode 0 Voix mobile 2 Bureau vocal 3 Voix alternative mobile 5 SMS 6 Notification push pour Microsoft Authenticator 7 OTP de jeton matériel ou logiciel Si des appareils utilisateur ont été migrés, il existe une entrée de journal distincte.
Utiliser Log Analytics
Les détails des migrations d'utilisateurs du serveur MFA vers l'authentification multifacteur Microsoft Entra peuvent également être interrogés à l'aide de Log Analytics.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Microsoft Entra multifactor authentication Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc
Cette capture d’écran montre les modifications apportées à la migration des utilisateurs :
Cette capture d’écran montre les modifications apportées à la migration des appareils :
Log Analytics peut également être utilisé pour synthétiser l’activité de migration des utilisateurs.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Microsoft Entra multifactor authentication Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
capture d’écran 
Valider et tester
Une fois que vous avez correctement migré les données utilisateur, vous pouvez valider l’expérience utilisateur final en utilisant le déploiement par étapes avant de changer le locataire dans sa globalité. Le processus suivant vous permet de cibler des groupes spécifiques de Microsoft Entra pour un déploiement progressif de l’authentification multifacteur. Le déploiement intermédiaire ordonne à Microsoft Entra ID d’effectuer l’authentification multifacteur pour les utilisateurs des groupes ciblés à l’aide de la solution Microsoft Entra, plutôt que de les envoyer sur site pour effectuer cette authentification. Vous pouvez valider et tester : nous vous recommandons d’utiliser le Centre d’administration Microsoft Entra, mais si vous préférez, vous pouvez également utiliser Microsoft Graph.
Activer le déploiement progressif
Accédez à l’URL suivante : Activer les fonctionnalités de déploiement intermédiaire - Microsoft Azure.
Définissez Authentification multifacteur Azure sur Activé, puis cliquez sur Gérer les groupes.
Sélectionnez Ajouter des groupes et ajoutez le ou les groupes contenant les utilisateurs que vous souhaitez activer pour l’authentification multifacteur Microsoft Entra. Les groupes sélectionnés apparaissent dans la liste affichée.
Note
Tous les groupes que vous ciblez à l’aide de la méthode Microsoft Graph suivante apparaissent également dans cette liste.
Activer le déploiement intermédiaire à l’aide de Microsoft Graph
Créer la politique de déploiement des fonctionnalités
Accédez à aka.ms/ge et connectez-vous à l’Afficheur Graph avec un compte Administrateur d’identité hybride dans le locataire que vous souhaitez configurer pour le déploiement par étapes.
Vérifiez que POST est sélectionné pour cibler le point de terminaison suivant :
https://graph.microsoft.com/v1.0/policies/featureRolloutPoliciesLe corps de votre demande doit contenir les éléments suivants (remplacez la stratégie de lancement MFA par le nom et la description de votre organisation) :
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
Effectuez un GET avec le même point de terminaison et notez la valeur ID (masquée dans l’image suivante) :
Cibler le ou les groupes Microsoft Entra qui contiennent les utilisateurs que vous souhaitez tester
Créez une requête POST avec l'endpoint suivant (remplacez {ID de stratégie} par la valeur d'ID que vous avez copiée à l'étape 1d) :
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$refLe corps de la requête doit contenir les éléments suivants (remplacez {ID de groupe} par l’ID d’objet du groupe que vous souhaitez cibler pour le déploiement intermédiaire) :
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }Répétez les étapes a et b pour tous les autres groupes que vous souhaitez cibler avec un déploiement intermédiaire.
Vous pouvez afficher la stratégie actuelle en place en effectuant une opération GET par rapport à l’URL suivante :
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesToLe processus précédent utilise la ressource featureRolloutPolicy. La documentation publique n’a pas encore été mise à jour avec la nouvelle fonctionnalité multifacteurAuthentication, mais elle contient des informations détaillées sur l’interaction avec l’API.
Vérifier l’expérience MFA de l’utilisateur final. Voici quelques éléments à vérifier :
- Les utilisateurs voient-ils leurs méthodes dans aka.ms/mfasetup ?
- Les utilisateurs reçoivent-ils des appels téléphoniques/sms ?
- Sont-ils en mesure de s’authentifier avec succès à l’aide des méthodes ci-dessus ?
- Les utilisateurs reçoivent-ils correctement des notifications Authenticator ? Sont-ils en mesure d’approuver ces notifications ? L’authentification réussit-elle ?
- Les utilisateurs peuvent-ils s’authentifier correctement à l’aide de jetons OATH matériels ?
Éduquer les utilisateurs
Assurez-vous que les utilisateurs savent à quoi s’attendre lorsqu’ils sont déplacés vers l’authentification multifacteur Microsoft Entra, y compris les nouveaux flux d’authentification. Vous pouvez également demander aux utilisateurs d’utiliser le portail d’inscription combinée microsoft Entra ID (aka.ms/mfasetup) pour gérer leurs méthodes d’authentification plutôt que le portail utilisateur une fois les migrations terminées. Toute modification apportée aux méthodes d’authentification dans l’ID Microsoft Entra ne se propage pas à votre environnement local. Dans un cas où vous deviez restaurer le serveur MFA, les modifications apportées par les utilisateurs dans Microsoft Entra ID ne seront pas disponibles dans le portail utilisateur du serveur MFA.
Si vous utilisez des solutions tierces qui dépendent du serveur d’authentification multifacteur Microsoft Entra pour l’authentification (consultez services d’authentification), vous souhaitez que les utilisateurs continuent à apporter des modifications à leurs méthodes MFA dans le portail utilisateur. Ces modifications sont synchronisées automatiquement avec l’ID Microsoft Entra. Une fois que vous avez migré ces solutions tierces, vous pouvez déplacer les utilisateurs vers la page d’inscription combinée de Microsoft Entra ID.
Effectuer la migration des utilisateurs
Répétez les étapes de migration trouvées dans Migrer des données utilisateur et valider et tester les sections jusqu’à ce que toutes les données utilisateur ne sont pas migrées.
Migrer les dépendances du serveur MFA
En utilisant les points de données que vous avez collectés dans le service d’authentification , commencez à effectuer les différentes migrations nécessaires. Une fois cette opération terminée, envisagez que les utilisateurs gèrent leurs méthodes d’authentification dans le portail d’inscription combiné, plutôt que dans le portail utilisateur sur le serveur MFA.
Mettre à jour les paramètres de fédération de domaine
Une fois que vous avez terminé les migrations utilisateur et déplacé tous vos services d’authentification hors du serveur MFA, il est temps de mettre à jour vos paramètres de fédération de domaine. Après la mise à jour, Microsoft Entra n’envoie plus de demande MFA à votre serveur de fédération local.
Pour configurer l’ID Microsoft Entra pour ignorer les demandes MFA adressées à votre serveur de fédération local, installez le kit de développement logiciel (SDK) Microsoft Graph PowerShell et définissez federatedIdpMfaBehavior sur rejectMfaByFederatedIdp, comme illustré dans l’exemple suivant.
Demande
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Réponse
Note
L’objet de réponse présenté ici peut être raccourci pour la lisibilité.
HTTP/1.1 200 OK
Content-Type: application/json
{
"@odata.type": "#microsoft.graph.internalDomainFederation",
"id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
"issuerUri": "http://contoso.com/adfs/services/trust",
"metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
"signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"passiveSignInUri": "https://sts.contoso.com/adfs/ls",
"preferredAuthenticationProtocol": "wsFed",
"activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
"signOutUri": "https://sts.contoso.com/adfs/ls",
"promptLoginBehavior": "nativeSupport",
"isSignedAuthenticationRequestRequired": true,
"nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"signingCertificateUpdateStatus": {
"certificateUpdateResult": "Success",
"lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
},
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Les utilisateurs ne sont plus redirigés vers votre serveur de fédération local pour l’authentification multifacteur, qu’ils soient ciblés par l’outil de déploiement intermédiaire ou non. Notez que cela peut prendre jusqu’à 24 heures.
Note
La mise à jour du paramètre de fédération de domaine peut prendre jusqu’à 24 heures.
Facultatif : Désactiver le portail utilisateur du serveur MFA
Une fois que vous avez terminé la migration de toutes les données utilisateur, les utilisateurs finaux peuvent commencer à utiliser les pages d’inscription combinées microsoft Entra ID pour gérer les méthodes MFA. Il existe deux façons d’empêcher les utilisateurs d’utiliser le portail utilisateur dans le serveur MFA :
- Redirigez votre URL du portail utilisateur du serveur MFA vers aka.ms/mfasetup
- Décochez la case Autoriser les utilisateurs à se connecter sous l’onglet Paramètres de la section Portail utilisateur du serveur MFA pour empêcher les utilisateurs de se connecter complètement au portail.
Désaffecter le serveur MFA
Lorsque vous n’avez plus besoin du serveur d’authentification multifacteur Microsoft Entra, suivez vos pratiques normales de dépréciation de serveur. Aucune action spéciale n’est requise dans l’ID Microsoft Entra pour indiquer la mise hors service du serveur MFA.
Plan de retour arrière
Si la mise à niveau a rencontré des problèmes, procédez comme suit pour restaurer :
Désinstallez MFA Server 8.1.
Remplacez PhoneFactor.pfdata par la sauvegarde effectuée avant la mise à niveau.
Remarque
Toutes les modifications apportées depuis la sauvegarde sont perdues, mais elles doivent être minimes si la sauvegarde a été effectuée juste avant la mise à niveau et la mise à niveau a échoué.
Exécutez le programme d’installation de votre version précédente (par exemple, 8.0.x.x).
Configurez l’ID Microsoft Entra pour accepter les demandes MFA sur votre serveur de fédération local. Utilisez Graph PowerShell pour définir federatedIdpMfaBehavior sur
enforceMfaByFederatedIdp, comme illustré dans l’exemple suivant.Requête
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }L’objet de réponse suivant est raccourci pour la lisibilité.
Réponse
HTTP/1.1 200 OK Content-Type: application/json { "@odata.type": "#microsoft.graph.internalDomainFederation", "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc", "issuerUri": "http://contoso.com/adfs/services/trust", "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex", "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "passiveSignInUri": "https://sts.contoso.com/adfs/ls", "preferredAuthenticationProtocol": "wsFed", "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed", "signOutUri": "https://sts.contoso.com/adfs/ls", "promptLoginBehavior": "nativeSupport", "isSignedAuthenticationRequestRequired": true, "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "signingCertificateUpdateStatus": { "certificateUpdateResult": "Success", "lastRunDateTime": "2021-08-25T07:44:46.2616778Z" }, "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
Définissez le déploiement intermédiaire pour l’authentification multifacteur Microsoft Entra sur Désactivé. Les utilisateurs sont à nouveau redirigés vers votre serveur de fédération local pour l’authentification multifacteur.