Migration du serveur MFA vers l’authentification multifacteur Microsoft Entra

Article
10/14/2024

L’authentification multifacteur (MFA) est importante pour sécuriser votre infrastructure et vos actifs contre les acteurs malveillants. Le serveur Multi-Factor Authentication (serveur MFA) n’est pas disponible pour les nouveaux déploiements et sera bientôt déconseillé. Les clients qui utilisent MFA Server doivent passer à l’utilisation de l’authentification multifacteur basée sur le cloud Microsoft Entra.

Dans cet article, nous supposons que vous disposez d’un environnement hybride dans lequel :

Vous utilisez le serveur MFA pour l’authentification multifacteur.
Vous utilisez la fédération sur Microsoft Entra ID avec les services de fédération Active Directory (AD FS) ou un autre produit de fédération de fournisseur d’identité.
- Bien que cet article se limite à AD FS, des étapes similaires s’appliquent à d’autres fournisseurs d’identité.
Votre instance du serveur MFA est intégrée à AD FS.
Vous pouvez avoir des applications qui utilisent AD FS pour l’authentification.

Il existe plusieurs états finaux possibles pour votre migration, en fonction de votre objectif.

	Objectif : désactiver Serveur MFA UNIQUEMENT	Objectif : désactiver le serveur MFA et passer à l’authentification Microsoft Entra	Objectif : désactiver Serveur MFA et AD FS
Fournisseur MFA	Remplacez le fournisseur MFA du serveur MFA par Microsoft Entra l’authentification multifacteur.	Remplacez le fournisseur MFA du serveur MFA par Microsoft Entra l’authentification multifacteur.	Remplacez le fournisseur MFA du serveur MFA par Microsoft Entra l’authentification multifacteur.
Authentification utilisateur	Continuez à utiliser la fédération pour l’authentification Microsoft Entra.	Passer à Microsoft Entra ID avec synchronisation de hachage du mot de passe (de préférence) ou authentification de type Passthrough et authentification unique transparente (SSO).	Passez à Microsoft Entra ID avec la synchronisation de hachage du mot de passe (de préférence) ou l’authentification directe et l’authentification unique (SSO).
Authentification de l’application	Continuez à utiliser l’authentification AD FS pour vos applications.	Continuez à utiliser l’authentification AD FS pour vos applications.	Déplacez les applications vers Microsoft Entra ID avant de migrer vers Microsoft Entra authentification multifacteur.

Si vous le pouvez, déplacez votre authentification multifacteur et votre authentification utilisateur vers Azure. Pour avoir des instructions détaillées, consultez Passer à Microsoft Entra l’authentification multifacteur et l’authentification utilisateur Microsoft Entra.

Si vous ne pouvez pas déplacer l’authentification de vos utilisateurs, consultez les instructions détaillées pour passer à l’authentification multifacteur de Microsoft Entra avec fédération.

Prérequis

Environnement AD FS (nécessaire si vous ne migrez pas toutes vos applications vers Microsoft Entra avant de migrer le serveur MFA)
- Effectuez une mise à niveau vers AD FS pour Windows Server 2019, niveau de comportement de la ferme (FBL) 4. Cette mise à niveau vous permet de sélectionner le fournisseur d’authentification en fonction de l’appartenance à un groupe pour une transition utilisateur plus fluide. Même s’il est possible d’effectuer une migration vers AD FS pour Windows Server 2016 FBL 3, cela ne sera pas aussi fluide pour les utilisateurs. Pendant la migration, les utilisateurs sont invités à sélectionner un fournisseur d’authentification (serveur MFA ou authentification multifacteur Microsoft Entra) jusqu’à ce que la migration soit terminée.
Autorisations
- Rôle d’administrateur d’entreprise dans Active Directory pour configurer la ferme AD FS pour l’authentification multifacteur Microsoft Entra
- Un Administrateur général est nécessaire pour gérer cette fonctionnalité.

Considérations pour tous les chemins de migration

La migration du serveur MFA vers l’authentification multifacteur Microsoft Entra ne se limite pas à déplacer les numéros de téléphone MFA enregistrés. Le serveur MFA de Microsoft peut être intégré à de nombreux systèmes, et vous devez évaluer la façon dont ces systèmes utilisent le serveur MFA pour comprendre les meilleures façons d’intégrer l’authentification multifacteur Microsoft Entra.

Migration des informations utilisateur MFA

Lorsque l’on réfléchit au déplacement d’utilisateurs par lots, il est courant d’envisager leur déplacement par région, par département ou par rôle, comme les administrateurs. Vous devez déplacer les comptes d’utilisateurs de manière itérative, en commençant par les groupes de test et de pilotes, et vous assurer que vous disposez d’un plan de restauration.

Vous pouvez utiliser l’utilitaire de migration du serveur MFA pour synchroniser les données MFA stockées dans le serveur Azure MFA sur site avec l’authentification multifacteur Microsoft Entra et utiliser le déploiement par étapes pour réacheminer les utilisateurs vers Azure MFA. Le déploiement par étapes vous aide à effectuer des tests sans apporter de modifications à vos paramètres de fédération de domaine.

Pour que les utilisateurs puissent différencier le compte récemment ajouté et l’ancien compte associé à Serveur MFA, assurez-vous que le nom de compte pour l’application mobile sur Serveur MFA permet de distinguer les deux comptes. Par exemple, le nom de compte qui apparaît sous Application mobile sur Serveur MFA a été renommé Serveur MFA local. Le nom de compte sur Microsoft Authenticator est modifié avec la prochaine notification Push à l’utilisateur.

La migration des numéros de téléphone peut également entraîner la migration de numéros périmés et inciter les utilisateurs à conserver une authentification MFA par téléphone au lieu de configurer des méthodes plus sécurisées comme Microsoft Authenticator en mode sans mot de passe. Nous vous recommandons donc d’inviter tous les utilisateurs à effectuer l’inscription combinée des informations de sécurité, quel que soit le chemin de migration que vous choisissez.

Migration des clés de sécurité matérielles

Microsoft Entra ID prend en charge les jetons matériels OATH. Vous pouvez recourir à l’utilitaire de migration de serveur MFA pour synchroniser les paramètres MFA entre le serveur MFA et authentification multifacteur Microsoft Entra et utiliser le déploiement par étapes pour tester les migrations utilisateur sans changer les paramètres de fédération de domaine.

Si vous souhaitez uniquement migrer des jetons matériels OATH, vous devez charger des jetons sur Microsoft Entra ID en utilisant un fichier CSV, communément appelé « fichier d’origine ». Le fichier d’origine contient les clés secrètes et les numéros de série des jetons, ainsi que d’autres informations nécessaires pour charger les jetons dans Microsoft Entra ID.

Si vous ne disposez plus du fichier d’origine avec les clés secrètes, vous ne pourrez pas exporter les clés secrètes à partir de Serveur MFA. Si vous n’avez plus accès aux clés secrètes, contactez le fournisseur de votre matériel pour obtenir de l’aide.

Le kit de développement logiciel (SDK) du service web de Serveur MFA peut être utilisé pour exporter le numéro de série des jetons OATH attribués à un utilisateur donné. Vous pouvez utiliser ces informations et le fichier d’origine pour importer les jetons dans Microsoft Entra ID et attribuer le jeton OATH à l’utilisateur spécifié en fonction du numéro de série. L’utilisateur devra également être contacté au moment de l’importation pour fournir les informations de mot de passe à usage unique de l’appareil afin de finaliser l’inscription. Reportez-vous à la rubrique de fichier d’aide GetUserInfo>userSettings>OathTokenSerialNumber du serveur Multi-Factor Authentication sur votre serveur MFA.

Migrations supplémentaires

La décision de passer du serveur MFA à l’authentification multifacteur Microsoft Entra ouvre la voie à d’autres migrations. L’exécution d’autres migrations dépend de nombreux facteurs, notamment :

votre volonté d’utiliser l’authentification Microsoft Entra pour les utilisateurs
votre volonté de déplacer vos applications vers Microsoft Entra ID

Étant donné que le serveur MFA fait partie intégrante de l’authentification des utilisateurs et des applications, envisagez de déplacer ces deux fonctions vers Azure dans le cadre de votre migration MFA, puis de désactiver AD FS.

Nos recommandations :

Utiliser Microsoft Entra ID pour l’authentification afin de renforcer la sécurité et la gouvernance
Déplacer des applications vers Microsoft Entra ID si possible

Pour sélectionner la meilleure méthode d’authentification des utilisateurs pour votre organisation, voir Choisir la bonne méthode d’authentification pour votre solution d’identité hybride Microsoft Entra . Nous vous recommandons d’utiliser la synchronisation de hachage du mot de passe (PHS).

Authentification sans mot de passe

Dans le cadre de l’inscription des utilisateurs pour utiliser Microsoft Authenticator comme deuxième facteur, nous vous recommandons d’activer la connexion par téléphone sans mot de passe. Pour plus d’informations, y compris sur les autres méthodes sans mot de passe comme les clés de sécurité FIDO2 et Windows Hello Entreprise, visitez Planifier un déploiement d’authentification sans mot de passe avec Microsoft Entra ID.

Réinitialisation de mot de passe en libre-service Microsoft Identity Manager

La réinitialisation de mot de passe en libre-service (SSPR) Microsoft Identity Manager (MIM) peut utiliser Serveur MFA pour invoquer des codes à usage unique par SMS dans le cadre du flux de réinitialisation du mot de passe. MIM ne peut pas être configuré pour utiliser Microsoft Entra authentification multifacteur. Nous vous recommandons d’évaluer la migration de votre service SSPR vers Microsoft Entra SSPR. Vous pouvez profiter de l’inscription des utilisateurs à Microsoft Entra d’authentification multifacteur pour utiliser l’expérience d’inscription combinée afin qu’ils s’inscrivent à Microsoft Entra SSPR.

Si vous ne pouvez pas déplacer votre service SSPR ou si profitez du serveur d’authentification multifacteur pour appeler des requêtes d’authentification multifacteur pour des scénarii de Gestion des accès privilégiés (PAM), nous vous recommandons d’effectuer une mise à jour vers une option tierce d’authentification multifacteur.

Clients RADIUS et authentification multifacteur Microsoft Entra

Serveur MFA prend en charge RADIUS en vue d’invoquer l’authentification multifacteur pour les applications et les appareils réseau qui prennent en charge le protocole. Si vous utilisez RADIUS avec Serveur MFA, nous vous recommandons de déplacer les applications clientes vers des protocoles modernes tels que SAML, OpenID Connect, OAuth sur Microsoft Entra ID. Si l’application ne peut pas être mise à jour, vous pouvez déployer le serveur NPS (Network Policy Server) avec l’extension d’authentification multifacteur Microsoft Entra. L’extension du serveur NPS (Network Policy Server) agit comme un adaptateur entre les applications basées sur RADIUS et l’authentification multifacteur Microsoft Entra pour fournir un deuxième facteur d’authentification. Cet « adaptateur » vous permet de déplacer vos clients RADIUS vers Microsoft Entra authentification multifacteur et de désactiver votre Serveur MFA.

Considérations importantes

Il existe des limitations lors de l’utilisation de NPS pour les clients RADIUS et nous vous recommandons d’évaluer les clients RADIUS pour déterminer si vous pouvez les mettre à niveau vers des protocoles d’authentification modernes. Vérifiez avec le fournisseur de services les versions de produit prises en charge et leurs fonctionnalités.

L’extension NPS n’utilise pas les stratégies d’accès conditionnel Microsoft Entra. Si vous conservez RADIUS et utilisez l’extension NPS, toutes les requêtes d’authentification dirigées vers NPS obligeront l’utilisateur à effectuer une authentification multifacteur.
Les utilisateurs doivent s’inscrire à Microsoft Entra d’authentification multifacteur avant d’utiliser l’extension NPS. Sinon, l’extension ne parvient pas à authentifier l’utilisateur, ce qui peut générer des appels au support technique.
Lorsque l’extension NPS invoque l’authentification multifacteur, la requête MFA est envoyée à la méthode MFA par défaut de l’utilisateur.
- Étant donné que la connexion a lieu sur des applications non-Microsoft, il est fréquent que l’utilisateur ne puisse pas voir de notification indiquant que l’authentification multifacteur est nécessaire et qu’une requête a été envoyée sur son appareil.
- Tant que l’authentification multifacteur est exigée, les utilisateurs doivent avoir accès à leur méthode d’authentification par défaut pour finaliser l’authentification multifacteur. Ils ne peuvent pas choisir une autre méthode. Leur méthode d’authentification par défaut sera utilisée même si elle a été désactivée dans les méthodes d’authentification du locataire et les stratégies d’authentification multifacteur.
- Les utilisateurs peuvent modifier leur méthode d’authentification multifacteur par défaut dans la page Informations de sécurité (aka.ms/mysecurityinfo).
Les méthodes MFA disponibles pour les clients RADIUS sont contrôlées par les systèmes clients qui envoient les requêtes d’accès RADIUS.
- Les méthodes MFA qui nécessitent une entrée utilisateur après la saisie d’un mot de passe ne peuvent être utilisées qu’avec les systèmes qui prennent en charge les réponses aux demandes d’accès avec RADIUS. Les méthodes d’entrée peuvent inclure les mots de passe à usage unique, les jetons OATH matériels ou Microsoft Authenticator.
- Certains systèmes peuvent limiter les méthodes d’authentification multifacteur disponibles aux appels téléphoniques et notifications Push de Microsoft Authenticator.

Remarque :

Les méthodes d’authentification disponibles dépendent de l’algorithme de chiffrement de mot de passe utilisé entre le client RADIUS et le système NPS, ainsi que des méthodes d’entrée que le client peut utiliser. Pour plus d’informations, consultez Déterminer les méthodes d’authentification que vos utilisateurs peuvent employer.

Les intégrations courantes de clients RADIUS incluent des applications telles que les passerelles des services Bureau à distance et les serveurs VPN. D’autres peuvent inclure :

Passerelle Citrix
- Citrix Gateway prend en charge l’intégration des extensions RADIUS et NPS ainsi que l’intégration de SAML.
VPN de Cisco
- Cisco VPN prend en charge à la fois l’authentification RADIUS et l’authentification SAML pour SSO.
- En passant de l’authentification RADIUS à SAML, vous pouvez intégrer Cisco VPN sans déployer l’extension NPS.
Tous les VPN
- Nous vous recommandons, si possible, de fédérer votre VPN en tant qu’application SAML. Cette fédération vous permettra d’utiliser l’accès conditionnel. Pour plus d’informations, consultez une liste des fournisseurs de VPN intégrés dans la galerie Microsoft Entra ID App.

Partager via