Migration du serveur MFA
Cette rubrique explique comment migrer les paramètres MFA des utilisateurs Microsoft Entra du serveur Azure MFA 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 sur le serveur Azure MFA local directement avec l’authentification multifacteur Microsoft Entra. Une fois les données d’authentification migrées vers Microsoft Entra ID, les utilisateurs peuvent effectuer une MFA cloud de manière fluide sans avoir à se réinscrire ou à confirmer les méthodes d’authentification. Les administrateurs peuvent recourir à l’utilitaire de migration du serveur MFA pour cibler des utilisateurs uniques ou des groupes d’utilisateurs à des fins de test et de déploiement contrôlé sans avoir à apporter de modifications à l’échelle du locataire.
Vidéo : Comment recourir à l’utilitaire de migration de serveur MFA
Regardez 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 du serveur MFA nécessite qu’une nouvelle build de la solution Serveur MFA soit installée sur votre serveur MFA principal. La build met à jour le fichier de données du serveur MFA et inclut le nouvel utilitaire de migration du serveur MFA. Vous n’avez pas besoin de mettre à jour le SDK web ou le portail utilisateur. L’installation de la mise à jour ne démarre pas automatiquement la migration.
Remarque
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 Microsoft Entra ID. 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 par étapes vous permet d’effectuer des tests 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 assurez-vous qu’aucune n’impose que l’authentification multifacteur (MFA) soit effectuée localement dans le cadre du processus d’authentification.
Le déploiement par étapes peut cibler un maximum de 500 000 utilisateurs (10 groupes contenant un maximum de 50 000 utilisateurs chacun).
Guide de migration
Une migration du serveur MFA inclut généralement les étapes décrites dans le processus suivant :
Voici quelques points importants :
La phase 1 doit être répétée quand vous ajoutez des utilisateurs de test.
- L’outil de migration utilise les groupes Microsoft Entra pour déterminer les utilisateurs pour lesquels les données d’authentification doivent être synchronisées entre le serveur MFA et l’authentification multifacteur Microsoft Entra. Après que ses données utilisateur aient été synchronisées, cet utilisateur est prêt à utiliser l’authentification multifacteur Microsoft Entra.
- Le déploiement par étapes vous permet de rediriger les utilisateurs vers l’authentification multifacteur Microsoft Entra, en utilisant également les groupes Microsoft Entra. Même si vous pouvez tout à fait utiliser les mêmes groupes pour les deux outils, nous vous le déconseillons. En effet, les utilisateurs peuvent potentiellement être redirigés vers l’authentification multifacteur Microsoft Entra avant que l’outil n’ait synchronisé leurs données. Nous vous recommandons de configurer des groupes Microsoft Entra pour synchroniser les données d’authentification avec l’utilitaire de migration du serveur MFA, et un autre ensemble de groupes pour le déploiement par étapes pour diriger les utilisateurs ciblés vers l’authentification 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, l’ensemble de votre base d’utilisateurs doit utiliser l’authentification multifacteur Microsoft Entra pour toutes les charges de travail fédérées par rapport à Microsoft Entra ID.
Pendant les phases précédentes, vous pouvez supprimer des utilisateurs des dossiers de déploiement par étapes pour les retirer de l’étendue de l’authentification multifacteur Microsoft Entra et les re-router vers votre serveur Azure MFA local pour toutes les demandes de MFA provenant de Microsoft Entra ID.
La Phase 3 nécessite de déplacer tous les clients qui s’authentifient auprès du serveur MFA local (VPN, gestionnaires de mots de passe, etc.) vers la fédération Microsoft Entra via SAML/OAUTH. Si les standards d’authentification modernes ne sont pas pris 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 seront pas re-synchronisées avec le serveur MFA. Si vous effectuez une restauration vers le serveur MFA local une fois que les utilisateurs ont apporté des modifications à leurs méthodes d’authentification dans Microsoft Entra ID, ces modifications seront perdues. Une fois les migrations d’utilisateurs terminées, changez 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 Azure Multi-Factor Authentication
Nous avons travaillé dur pour nous assurer que l’adoption de notre solution d’authentification multifacteur cloud Microsoft Entra maintienne et même améliore votre posture de sécurité. Il existe trois catégories générales 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, cliquez sur Paramètres de l’entreprise :
| Serveur MFA | Authentification multi-facteur Microsoft Entra |
|---|---|
| Onglet General | |
| Section Paramètres par défaut de l’utilisateur | |
| Appel téléphonique (Standard) | Aucune action n’est nécessaire |
| SMS (OTP)* | Aucune action n’est nécessaire |
| Application mobile (Standard) | Aucune action n’est nécessaire |
| Appel téléphonique (PIN)* | Activer Voice OTP |
| SMS (OTP + PIN)** | Aucune action n’est nécessaire |
| Application mobile (PIN)* | Activer la correspondance de numéro |
| Appel téléphonique/SMS/application mobile/langage de jeton OATH | Les paramètres linguistiques sont automatiquement appliqués à un utilisateur en fonction des paramètres régionaux dans son navigateur |
| Section Règles de PIN par défaut | Non applicable ; voir les méthodes mises à jour 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 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 |
*Quand un code PIN est utilisé pour fournir une fonctionnalité de preuve de présence, l’équivalent fonctionnel est fourni ci-dessus. Les codes PIN 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 de l’utilisateur
Ouvrez le serveur MFA, puis cliquez sur Portail utilisateur :
| Serveur MFA | Authentification multi-facteur Microsoft Entra |
|---|---|
| Onglet Paramètres | |
| URL du portail de l’utilisateur | aka.ms/mfasetup |
| Autoriser l'inscription utilisateur | 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 son navigateur |
| Autoriser les utilisateurs à activer l'application mobile | Consultez Paramètres du service MFA |
| - Limite de l’appareil | Microsoft Entra ID impose une limite de 5 appareils cumulatifs (instances d’application mobile + jeton OATH matériel + jeton OATH logiciel) par utilisateur |
| Utiliser les questions de sécurité de secours | 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 auxquelles répondre | Les questions de sécurité dans Microsoft Entra ID ne peuvent être utilisées que pour la réinitialisation de mot de passe en libre-service. 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 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é dans le serveur MFA ont été utilisées pour accéder au portail utilisateur. L’authentification multifacteur Microsoft Entra prend en charge les questions de sécurité pour la réinitialisation de mot de passe en libre-service uniquement. 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 Microsoft Entra ID et ne nécessitent aucune configuration |
| Adresses IP approuvées | adresses 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 Azure MFA peut fournir des fonctionnalités MFA pour les solutions tierces qui utilisent RADIUS ou LDAP en faisant office de 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 Microsoft Entra ID.
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 changements de mot de passe en ligne pour les utilisateurs finaux. Une fois migrés, les utilisateurs finaux peuvent gérer leurs mots de passe avec 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 toute partie de confiance, à l’exception de l’approbation pour la 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 vers Microsoft Entra ID si elles 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 Azure Multi-Factor Authentication
Effectuez une sauvegarde du fichier de données du serveur MFA situé dans %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 installée au cas où vous devriez effectuer une restauration. Si vous n’avez plus de copie, contactez le support technique.
Selon l’activité de l’utilisateur, le fichier de données peut devenir obsolète rapidement. Aucune modification apportée au serveur MFA ni aucune modification apportée par l’utilisateur final au travers du portail après la sauvegarde n’est capturée. 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. Il est inutile 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 en utilisant le 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. La version x86 et la version x64 du package sont toutes deux installées. Il n’est pas nécessaire d’installer des mises à jour pour le portail utilisateur, le SDK web ou l’adaptateur AD FS.
Notes
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û au fait que des modifications de schéma apportées sur le serveur principal 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 des journaux du serveur MFA ou mettre à niveau vos serveurs secondaires.
Configurer l’utilitaire de migration du 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, cliquez avec le bouton droit, puis cliquez sur Exécuter en tant qu’administrateur. Exécutez le script .\Configure-MultiFactorAuthMigrationUtility.ps1 qui se trouve dans le répertoire d’installation du serveur MFA (C:\Program Files\Multi-Factor Authentication Server par défaut).
Ce script vous demandera de fournir des informations d’identification d’un administrateur d’application dans votre locataire Microsoft Entra. Le script crée ensuite une nouvelle application d’utilitaire de migration du serveur MFA dans Microsoft Entra ID, qui sera utilisée pour écrire les méthodes d’authentification utilisateur dans chaque objet utilisateur Microsoft Entra.
Pour les clients du cloud Government qui souhaitent effectuer des migrations, remplacez les entrées « .com » dans le script par « .us ». Ce script écrit ensuite 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 avez également besoin d’accéder aux URL suivantes :
https://graph.microsoft.com/*(ouhttps://graph.microsoft.us/*pour les clients du cloud Government)https://login.microsoftonline.com/*(ouhttps://login.microsoftonline.us/*pour les clients du cloud Government)
Le script vous demande d’accorder le consentement administrateur à l’application créée. Accédez à l’URL fournie, ou dans le centre d’administration Microsoft Entra, cliquez sur Inscriptions d’application, recherchez et sélectionnez l’application Utilitaire de migration du serveur MFA, cliquez sur Autorisations des 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. Vous devez normalement voir l’écran suivant :
Vous avez correctement installé l’utilitaire de migration.
Notes
Pour ne pas modifier le comportement pendant la migration, si votre serveur d’authentification multifacteur est associé à un fournisseur d’authentification multifacteur sans référence de locataire, vous allez devoir mettre à jour les paramètres d’authentification multifacteur par défaut (comme les messages d’accueil personnalisés) du locataire dont vous effectuez la migration pour qu’ils correspondent aux paramètres de votre fournisseur d’authentification multifacteur. Nous vous recommandons d’effectuer cette opération avant de migrer des utilisateurs.
Exécuter un serveur secondaire d’authentification multifacteur (facultatif)
Si votre implémentation du serveur d’authentification multifacteur compte un grand nombre d’utilisateurs ou un serveur d’authentification multifacteur principal occupé, vous pouvez envisager de déployer un serveur d’authentification multifacteur secondaire dédié pour exécuter l’utilitaire de migration du serveur d’authentification multifacteur et les services de synchronisation de migration. Après la mise à niveau de votre serveur principal d’authentification multifacteur, mettez à niveau un serveur secondaire existant ou déployez-en un nouveau. Le serveur secondaire que vous choisissez ne doit pas gérer le trafic d’authentification multifacteur.
Le script Configure-MultiFactorAuthMigrationUtility.ps1 doit être exécuté sur le serveur secondaire pour inscrire un certificat auprès de l’inscription de l’application utilitaire de migration du serveur d’authentification multifacteur. 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 dans un serveur d’authentification multifacteur secondaire devrait améliorer les performances de migrations manuelles et automatisées de l’utilisateur.
Migrer les 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 change pas l’endroit où un utilisateur effectue l’authentification multifacteur. Ce processus est une copie unidirectionnelle de données depuis le serveur local vers l’objet utilisateur correspondant dans Microsoft Entra ID.
L’utilitaire de migration du serveur MFA cible un groupe Microsoft Entra unique 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 par étape 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 que vous avez terminé, appuyez sur Tab ou cliquez en dehors de la fenêtre pour commencer à rechercher le groupe approprié. Tous les utilisateurs du groupe sont renseignés. Pour un grand groupe, l’opération peut prendre plusieurs minutes.
Pour afficher les données d’attribut d’un utilisateur, mettez celui-ci en surbrillance, puis sélectionnez Afficher :
Cette fenêtre affiche les attributs de l’utilisateur sélectionné dans Microsoft Entra ID 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 migration.
L’option Paramètres vous permet de changer les paramètres du processus de migration :
Migrer : il existe trois options pour migrer la méthode d’authentification par défaut d’un utilisateur :
- Toujours migrer
- Ne migrer que si ce n’est pas déjà défini dans Microsoft Entra ID
- Définir sur la méthode la plus sécurisée disponible si elle n’est pas encore définie dans Microsoft Entra ID
Ces options offrent une flexibilité lors de votre migration de la méthode par défaut. En outre, la stratégie des 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 d’utilisateur : vous permet de spécifier un attribut Active Directory local différent pour faire correspondre l’UPN Microsoft Entra au lieu de la correspondance par défaut avec userPrincipalName :
- L’utilitaire de migration tente une correspondance directe avec UPN avant d’utiliser l’attribut Active Directory local.
- Si aucune correspondance n’est trouvée, une API Windows est appelée pour rechercher l’UPN Microsoft Entra et obtenir le SID, utilisé pour rechercher la liste des utilisateurs du serveur MFA.
- Si l’API Windows ne trouve pas l’utilisateur ou si le SID est introuvable dans le serveur MFA, elle utilise l’attribut Active Directory configuré pour rechercher l’utilisateur dans le Active Directory local, puis utilise le SID pour effectuer une recherche dans la liste des utilisateurs du serveur MFA.
Synchronisation automatique : démarre un service en arrière-plan qui supervise continuellement toutes les modifications de méthode d’authentification des utilisateurs sur le serveur MFA local et les écrit dans Microsoft Entra ID selon l’intervalle de temps 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 de s’exécuter uniquement sur le serveur principal. Pour configurer l’exécution du service Migration Sync 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 du processus manuel sont les suivantes :
Pour commencer le processus de migration pour un utilisateur ou une sélection de plusieurs utilisateurs, appuyez sur la touche Ctrl et maintenez-la enfoncée tout en sélectionnant chacun des utilisateurs que vous souhaitez migrer.
Une fois que vous avez sélectionné les utilisateurs souhaités, cliquez sur Migrer des utilisateurs>Utilisateurs sélectionnés>OK.
Pour migrer tous les utilisateurs du groupe, cliquez sur Migrer des utilisateurs>Tous les utilisateurs du groupe Microsoft Entra>OK.
Vous pouvez migrer des utilisateurs même s’ils sont inchangés. Par défaut, l’utilitaire est défini sur Migrer uniquement les utilisateurs qui ont changé. Cliquez sur Migrer tous les utilisateurs pour migrer à nouveau les utilisateurs précédemment migrés qui sont inchangés. La migration d’utilisateurs inchangés peut être utile lors des tests si un administrateur doit réinitialiser les paramètres Azure MFA d’un utilisateur et souhaite les migrer à nouveau.
Pour le processus automatique, cliquez sur Synchronisation automatique dans Paramètres, puis indiquez si vous souhaitez que tous les utilisateurs soient synchronisés ou uniquement les membres d’un groupe Microsoft Entra donné.
Le tableau suivant liste la logique de synchronisation pour les différentes méthodes.
| Méthode | Logique |
|---|---|
| Téléphone | S’il n’y a pas d’extension, mettre à jour le téléphone MFA. S’il n’y a pas d’extension, mettre à jour le téléphone du bureau. Exception : si la méthode par défaut est SMS, supprimer l’extension et mettre à jour le téléphone MFA. |
| Téléphone de secours | S’il n’y a pas d’extension, mettre à jour le téléphone alternatif. S’il n’y a pas d’extension, mettre à jour le téléphone du 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 dispose également d’un jeton OATH matériel. Si plusieurs appareils portent le même nom, migrer uniquement le plus récent. 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. -- Si aucune correspondance n’est trouvée, créer un 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é, puis la méthode par défaut est définie. Le serveur MFA effectue le suivi du dernier timestamp de la migration et le migre à nouveau l’utilisateur uniquement si les paramètres MFA de l’utilisateur changent ou qu’un administrateur modifie ce qu’il faut migrer dans la boîte de dialogue 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. Quand vous ajoutez des utilisateurs à ce groupe, leurs informations sont automatiquement synchronisées avec Microsoft Entra ID. L’utilitaire de migration du serveur MFA cible un groupe Microsoft Entra, mais ce groupe peut englober les utilisateurs et des groupes d’utilisateurs imbriqués.
Au terme de la procédure, une confirmation vous informe des tâches effectuées :
Comme mentionné dans le message de confirmation, l’affichage des données migrées sur les objets utilisateur dans 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 d’authentification multifacteur Microsoft Entra. 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 des utilisateurs.
Afficher les détails de la migration
Vous pouvez utiliser les journaux d’audit ou Log Analytics pour afficher les détails des migrations d’utilisateurs du serveur MFA vers Azure MFA.
Utiliser des journaux d’audit
Pour accéder aux journaux d’audit dans le centre d’administration Microsoft Entra afin d’afficher les détails des migrations d’utilisateurs du serveur MFA vers Azure MFA, procédez comme suit :
Connectez-vous au centre d’administration Microsoft Entra avec au moins le rôle d’Administrateur d’authentification.
Accédez à Identité>Surveillance et intégrité>Journaux d’audit. Pour filtrer les journaux, cliquez sur Ajouter des filtres.
Sélectionnez Initié par (acteur), puis cliquez sur Appliquer.
Tapez Gestion Azure MFA, puis 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 d’utilisateur, cliquez sur une ligne, puis choisissez l’onglet Propriétés modifiées. Cet onglet affiche les modifications apportées aux méthodes MFA d’authentification et aux numéros de téléphone inscrits.
Le tableau suivant répertorie la méthode d’authentification pour chaque code.
Code Méthode 0 Voix mobile 2 Voix bureau 3 Voix alternative mobile 5 SMS 6 Microsoft Authenticator (notification Push) 7 OTP de jeton matériel ou logiciel Si des appareils utilisateur ont été migrés, une entrée de journal distincte est créée.
Utiliser Log Analytics
Les détails des migrations d’utilisateurs du serveur MFA vers Azure MFA peuvent également être interrogés à l’aide de Log Analytics.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA 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 résumer l’activité de migration des utilisateurs.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
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 Microsoft Entra spécifiques pour le déploiement par étapes pour la MFA. Le déploiement par étapes indique à Microsoft Entra ID d’effectuer une MFA en utilisant l’authentification multifacteur de Microsoft Entra pour les utilisateurs des groupes ciblés, plutôt qu’en les envoyant localement. 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 par étapes
Accédez à l’URL suivante : Activez les fonctionnalités de déploiement par étapes - Microsoft Azure.
Définissez Authentification multifacteur Azure sur Activé, puis cliquez sur Gérer les groupes.
Cliquez sur Ajouter des groupes et ajoutez les groupes contenant les utilisateurs que vous souhaitez activer pour Azure MFA. Les groupes sélectionnés apparaissent dans la liste affichée.
Notes
Tous les groupes que vous ciblez avec la méthode Microsoft Graph ci-dessous apparaissent également dans cette liste.
Activer le déploiement par étapes avec Microsoft Graph
Créer la stratégie featureRolloutPolicy
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é et que le point de terminaison suivant est ciblé :
https://graph.microsoft.com/v1.0/policies/featureRolloutPoliciesLe corps de votre demande doit contenir les éléments suivants (remplacez MFA rollout policy 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 d’ID (masquée dans l’image suivante) :
Cibler les groupes Microsoft Entra qui contiennent les utilisateurs que vous souhaitez tester
Créez une requête POST avec le point de terminaison suivant (remplacez {ID of policy} 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 demande doit contenir les éléments suivants (remplacez {ID of group} par l’ID d’objet du groupe que vous souhaitez cibler pour le déploiement par étapes) :
{ "@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 le déploiement par étapes.
Vous pouvez afficher la stratégie actuelle en place en effectuant un GET sur 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é multifactorAuthentication, 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 points à 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 les méthodes ci-dessus ?
- Les utilisateurs reçoivent-ils correctement les notifications Authenticator ? Sont-ils en mesure d’approuver ces notifications ? L’authentification réussit-elle ?
- Les utilisateurs peuvent-ils s’authentifier avec des jetons OATH matériels ?
Former les utilisateurs
Assurez-vous que les utilisateurs savent à quoi s’attendre quand ils sont déplacés vers Azure MFA, notamment concernant 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. Les modifications éventuellement apportées aux méthodes d’authentification dans Microsoft Entra ID ne se propagent pas en retour à votre environnement local. Si vous devez effectuer une restauration vers le serveur MFA, aucune des modifications apportées par les utilisateurs dans Microsoft Entra ID ne seront disponibles dans le portail utilisateur du serveur MFA.
Si vous utilisez des solutions tierces qui dépendent du serveur Azure MFA pour l’authentification (voir Services d’authentification), il est préférable que les utilisateurs continuent à apporter des modifications à leurs méthodes MFA dans le portail utilisateur. Ces modifications seront automatiquement synchronisées avec Microsoft Entra ID. Une fois que vous avez migré ces solutions tierces, vous pouvez déplacer les utilisateurs vers la page d’inscription combinée Microsoft Entra ID.
Effectuer la migration des utilisateurs
Répétez les étapes de migration indiquées dans les sections Migrer les données utilisateur et Valider et tester jusqu’à ce que toutes les données utilisateur soient migrées.
Migrer les dépendances du serveur MFA
En utilisant les points de données que vous avez collectés dans Services 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ée, 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 d’utilisateurs 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 de MFA à votre serveur de fédération local.
Pour configurer Microsoft Entra ID afin que soient ignorées les demandes de MFA adressées à votre serveur de fédération local, installez le SDK Microsoft Graph PowerShell et définissez federatedIdpMfaBehavior sur rejectMfaByFederatedIdp, 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": "rejectMfaByFederatedIdp"
}
response
Remarque : L’objet de réponse illustré ici peut être abrégé pour une meilleure 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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
"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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
"signingCertificateUpdateStatus": {
"certificateUpdateResult": "Success",
"lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
},
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Les utilisateurs ne seront plus redirigés vers votre serveur de fédération local pour MFA, qu’ils soient ciblés par l’outil de déploiement par étapes ou non. Jusqu’à 24 heures peuvent être nécessaires avant que cela prenne effet.
Notes
La mise à jour du paramètre de fédération de domaine peut prendre jusqu’à 24 heures pour entrer en vigueur.
Facultatif : désactiver le portail utilisateur du serveur MFA
Une fois que vous avez effectué la migration de toutes les données utilisateur, les utilisateurs finaux peuvent commencer à utiliser les pages d’inscription combinée Microsoft Entra ID pour gérer les méthodes de MFA. Il existe deux façons d’empêcher les utilisateurs d’utiliser le portail utilisateur sur 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ésactiver le serveur MFA
Quand vous n’avez plus besoin du serveur Azure MFA, suivez vos pratiques normales de dépréciation de serveur. Aucune action particulière n’est nécessaire dans Microsoft Entra ID pour indiquer la mise hors service du serveur MFA.
Plan de restauration
Si la mise à niveau a rencontré des problèmes, procédez comme suit pour effectuer une restauration :
Désinstallez MFA Server 8.1.
Remplacez PhoneFactor.pfdata par la sauvegarde effectuée avant la mise à niveau.
Notes
Toutes les modifications apportées depuis que la sauvegarde a été effectuée seront perdues, mais doivent être minimales si la sauvegarde a été effectuée juste avant la mise à niveau et que celle-ci a échoué.
Exécutez le programme d’installation pour votre version précédente (par exemple, 8.0.x.x).
Configurez Microsoft Entra ID pour que les demandes de MFA adressées à votre serveur de fédération local soient acceptées. 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 a été raccourci pour améliorer 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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI", "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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI", "signingCertificateUpdateStatus": { "certificateUpdateResult": "Success", "lastRunDateTime": "2021-08-25T07:44:46.2616778Z" }, "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
Définissez Déploiement par étapes pour Azure MFA sur Désactivé. Les utilisateurs seront à nouveau redirigés vers votre serveur de fédération local pour l’authentification multifacteur.