Migrer vers l’authentification multifacteur Microsoft Entra avec fédération
Déplacer votre solution MFA (authentification multifacteur) vers Microsoft Entra ID est une première étape importante dans votre parcours vers le cloud. Pensez également à passer plus tard à Microsoft Entra ID pour l’authentification utilisateur. Pour plus d’informations, consultez le processus de migration vers l’authentification multifacteur Microsoft Entra avec l’authentification cloud.
Pour migrer vers l’authentification multifacteur Microsoft Entra avec fédération, le fournisseur d’authentification multifacteur Microsoft Entra est installé sur AD FS. L’approbation de la partie de confiance de Microsoft Entra ID et autres approbations de parties de confiance sont configurées pour utiliser l’authentification multifacteur Microsoft Entra pour les utilisateurs qui ont été migrés.
Le diagramme suivant illustre le processus de migration.
Créer des groupes de migration
Pour créer des stratégies d’accès conditionnel, vous devez affecter ces stratégies à des groupes. Vous pouvez utiliser des groupes de sécurité Microsoft Entra ou des groupes Microsoft 365 à cet effet. Vous pouvez également en créer ou en synchroniser de nouveaux.
Vous avez également besoin d’un groupe de sécurité Microsoft Entra pour la migration itérative des utilisateurs vers l’authentification multifacteur Microsoft Entra. Ces groupes sont utilisés dans vos règles de revendication.
Ne réutilisez pas de groupes utilisés pour la sécurité. Si vous utilisez un groupe de sécurité pour sécuriser un groupe d’applications très important avec une stratégie d’accès conditionnel, n’utilisez que le groupe qu’à cette seule fin.
Préparer AD FS
Mettre à niveau la batterie de serveurs AD FS vers FBL 4 2019
Dans AD FS 2019, vous pouvez spécifier des méthodes d’authentification supplémentaires pour une partie de confiance, par exemple une application. Vous utilisez l’appartenance à un groupe pour déterminer le fournisseur d’authentification. En spécifiant une méthode d’authentification supplémentaire, vous pouvez effectuer une transition vers l’authentification multifacteur Microsoft Entra tout en conservant les autres méthodes d’authentification pendant la transition. Pour plus d’informations, consultez Mise à niveau vers AD FS dans Windows Server 2016 à l’aide d’une base de données WID. L’article couvre à la fois la mise à niveau de votre batterie de serveurs vers AD FS 2019 et la mise à niveau de votre FBL vers la version 4.
Configurer des règles de revendication pour appeler l’authentification multifacteur Microsoft Entra
Maintenant que l’authentification multifacteur Microsoft Entra est une méthode d’authentification supplémentaire, vous pouvez affecter des groupes d’utilisateurs qui peuvent l’utiliser. Pour ce faire, vous devez configurer des règles de revendication, également appelées approbations de partie de confiance. À l’aide de groupes, vous pouvez déterminer quel est le fournisseur d’authentification appelé, globalement ou par application. Par exemple, vous pouvez appeler l’authentification multifacteur Microsoft Entra pour les utilisateurs qui se sont inscrits pour accéder aux informations combinées de sécurité, tout en appelant le serveur MFA pour les autres.
Remarque
Les règles de revendication nécessitent un groupe de sécurité local. Avant d’apporter des changements aux règles de revendication, sauvegardez-les.
Sauvegarder des règles
Avant de configurer de nouvelles règles de revendication, sauvegardez vos règles. Vous devez restaurer ces règles dans le cadre des étapes de nettoyage.
Selon votre configuration, vous devrez peut-être également copier la règle et ajouter les nouvelles règles créées pour la migration.
Pour voir les règles globales, exécutez :
Get-AdfsAdditionalAuthenticationRule
Pour voir les approbations de partie de confiance, exécutez la commande suivante en remplaçant RPTrustName par le nom de la règle de revendication d’approbation de partie de confiance :
(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules
Stratégies de contrôle d’accès
Remarque
Vous ne pouvez pas configurer les stratégies de contrôle d’accès pour appeler un fournisseur d’authentification spécifique en fonction de l’appartenance à un groupe.
Pour passer des stratégies de contrôle d’accès à des règles d’authentification supplémentaires, exécutez la commande suivante pour chacune de vos approbations de partie de confiance en utilisant le fournisseur d’authentification basé sur le serveur MFA :
Set-AdfsRelyingPartyTrust -TargetName AppA -AccessControlPolicyName $Null
Cette commande permet de déplacer la logique de votre stratégie de contrôle d’accès actuelle vers des règles d’authentification supplémentaires.
Configurer le groupe et rechercher le SID
Vous devez disposer d’un groupe spécifique dans lequel vous placez les utilisateurs pour lesquels vous souhaitez appeler l’authentification multifacteur Microsoft Entra. Vous aurez besoin du SID (identificateur de sécurité) de ce groupe.
Pour trouver le SID du groupe, utilisez la commande suivante avec le nom de groupe
Get-ADGroup "GroupName"
Définir les règles de revendication pour appeler l’authentification multifacteur Microsoft Entra
Les applets de commande PowerShell suivantes appellent l’authentification multifacteur Microsoft Entra pour les utilisateurs du groupe qui ne font pas partie du réseau d’entreprise. Remplacez « YourGroupSid » par le SID trouvé en exécutant la cmdlet ci-dessus.
Veillez à consulter le Guide pratique pour choisir des fournisseurs d’authentification supplémentaires dans la version 2019.
Important
Sauvegarder vos règles de revendications
Définir la règle de revendication globale
Exécutez l’applet de commande PowerShell suivant :
(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules
La commande retourne vos règles d’authentification supplémentaires actuelles pour l’approbation de partie de confiance. Ajoutez les règles suivantes à vos règles de revendication actuelles :
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'
L’exemple suivant suppose que vos règles de revendication actuelles sont configurées pour demander une authentification MFA quand les utilisateurs se connectent depuis l’extérieur de votre réseau. Cet exemple inclut les règles supplémentaires que vous devez ajouter.
Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type =
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'
Définir une règle de revendication par application
Cet exemple modifie les règles de revendication d’une approbation de partie de confiance spécifique (application), et inclut les informations à ajouter.
Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type ==
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type =
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value =
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'
Configurer l’authentification multifacteur Microsoft Entra en tant que fournisseur d’authentification dans AD FS
Pour configurer l’authentification multifacteur Microsoft Entra pour AD FS, vous devez configurer chacun des serveurs AD FS. Si vous avez plusieurs serveurs AD FS dans votre batterie, vous pouvez les configurer à distance à l’aide d’Azure AD PowerShell.
Pour obtenir des instructions pas à pas sur ce processus, consultez Configurer les serveurs AD FS dans l’article Configurer l’authentification multifacteur Microsoft Entra en tant que fournisseur d’authentification avec AD FS.
Une fois que vous avez configuré les serveurs, vous pouvez ajouter l’authentification multifacteur Microsoft Entra en tant que méthode d’authentification supplémentaire.
Préparer Microsoft Entra ID et implémenter la migration
Cette section décrit les étapes finales avant la migration des paramètres MFA des utilisateurs.
Définir federatedIdpMfaBehavior sur enforceMfaByFederatedIdp
Pour les domaines fédérés, l’authentification multifacteur peut être appliquée par l’accès conditionnel Microsoft Entra ou par le fournisseur de fédération local. Chaque domaine fédéré a un paramètre de sécurité Microsoft Graph PowerShell nommé federatedIdpMfaBehavior. Vous pouvez définir federatedIdpMfaBehavior sur enforceMfaByFederatedIdp
pour que Microsoft Entra ID accepte l’authentification multifacteur effectuée par le fournisseur d’identité fédérée. Si le fournisseur d’identité fédérée n’a pas effectué l’authentification multifacteur, Microsoft Entra ID redirige la requête vers le fournisseur d’identité fédérée pour qu’il l’effectue. Pour plus d’informations, consultez federatedIdpMfaBehavior.
Remarque
Le paramètre federatedIdpMfaBehavior est une nouvelle version de la propriété SupportsMfa de la cmdlet New-MgDomainFederationConfiguration.
Pour les domaines qui définissent la propriété SupportsMfa, ces règles déterminent comment federatedIdpMfaBehavior et SupportsMfa fonctionnent ensemble :
- Le basculement entre federatedIdpMfaBehavior et SupportsMfa n’est pas pris en charge.
- Une fois la propriété federatedIdpMfaBehavior définie, Microsoft Entra ID ignore le paramètre SupportsMfa.
- Si la propriété federatedIdpMfaBehavior n’est jamais définie, Microsoft Entra ID continue d’honorer le paramètre SupportsMfa.
- Si les propriétés federatedIdpMfaBehavior ou SupportsMfa ne sont pas définies, Microsoft Entra ID opte par défaut pour le comportement
acceptIfMfaDoneByFederatedIdp
.
Vous pouvez vérifier l’état de federatedIdpMfaBehavior en utilisant Get-MgDomainFederationConfiguration.
Get-MgDomainFederationConfiguration –DomainID yourdomain.com
Vous pouvez également vérifier l’état de votre indicateur SupportsMfa avec Get-MgDomainFederationConfiguration :
Get-MgDomainFederationConfiguration –DomainName yourdomain.com
L’exemple suivant montre comment définir federatedIdpMfaBehavior sur enforceMfaByFederatedIdp
en utilisant Graph PowerShell.
Requête
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}
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": "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"
}
Configurer les stratégies d’accès conditionnel si nécessaire
Si vous utilisez l’accès conditionnel pour déterminer le moment où l’authentification MFA est proposée aux utilisateurs, vous ne devez pas avoir à changer vos stratégies.
Si SupportsMfa a la valeur false pour vos domaines fédérés, analysez vos règles de revendication sur l’approbation de la partie de confiance Microsoft Entra ID et créez des stratégies d’accès conditionnel qui prennent en charge les mêmes objectifs de sécurité.
Une fois que vous avez créé des stratégies d’accès conditionnel pour appliquer les mêmes contrôles qu’AD FS, vous pouvez sauvegarder et supprimer vos personnalisations de règles de revendication sur la partie de confiance Microsoft Entra ID.
Pour plus d’informations, consultez les ressources suivantes :
Inscrire des utilisateurs pour l’authentification multifacteur Microsoft Entra
Cette section explique comment les utilisateurs peuvent effectuer l’inscription combinée des informations de sécurité (MFA et réinitialisation de mot de passe en libre-service) et comment migrer leurs paramètres MFA. Microsoft Authenticator peut être utilisé en mode sans mot de passe. Elle peut également être utilisée en tant que second facteur pour l’authentification MFA avec l’une ou l’autre des méthodes d’inscription.
Effectuer l’inscription combinée des informations de sécurité (recommandé)
Nous vous recommandons d’inviter les utilisateurs à effectuer l’inscription combinée des informations de sécurité. Ils disposent ainsi d’un seul emplacement où inscrire leurs méthodes et appareils d’authentification pour MFA et SSPR.
Microsoft propose des modèles de communication que vous pouvez fournir aux utilisateurs pour les guider tout au long du processus d’inscription combinée.
Il s’agit notamment de modèles d’e-mails, d’affiches, de fiches cartonnées et de diverses autres ressources. Les utilisateurs inscrivent leurs informations sur https://aka.ms/mysecurityinfo
, ce qui les amène à l’écran d’inscription combinée des informations de sécurité.
Nous vous recommandons de sécuriser le processus d’inscription des informations de sécurité par un accès conditionnel qui oblige l’utilisateur à effectuer l’inscription à partir d’un appareil ou d’un emplacement approuvé. Pour plus d’informations sur le suivi des états d’inscription, consultez Activité des méthodes d’authentification pour Microsoft Entra ID.
Remarque
Les utilisateurs qui doivent effectuer l’inscription combinée de leurs informations de sécurité à partir d’un emplacement ou d’un appareil non approuvé peuvent se voir délivrer un passe d’accès temporaire, ou peuvent éventuellement être exclus temporairement de la stratégie.
Migrer les paramètres MFA à partir du serveur MFA
Vous pouvez recourir à l’utilitaire de migration du serveur MFA afin de synchroniser les paramètres MFA inscrits pour les utilisateurs du serveur MFA vers Microsoft Entra ID. Vous pouvez synchroniser les numéros de téléphone, les jetons matériels et les inscriptions d’appareils, telles que les paramètres de Microsoft Authenticator.
Ajouter des utilisateurs aux groupes appropriés
Si vous avez créé des stratégies d’accès conditionnel, ajoutez les utilisateurs appropriés à ces groupes.
Si vous avez créé des groupes de sécurité locaux pour les règles de revendication, ajoutez les utilisateurs appropriés à ces groupes.
Nous vous déconseillons de réutiliser les groupes utilisés pour la sécurité. Si vous utilisez un groupe de sécurité pour sécuriser un groupe d’applications très important avec une stratégie d’accès conditionnel, n’utilisez que le groupe qu’à cette seule fin.
Surveillance
Vous pouvez superviser l’inscription à l’authentification multifacteur Microsoft Entra en utilisant le rapport d’utilisation et d’insights des méthodes d’authentification. Ce rapport est disponible dans Microsoft Entra ID. Sélectionnez Supervision, puis Utilisation et insights.
Dans Utilisation et insights, sélectionnez Méthodes d’authentification.
Des informations détaillées sur l’inscription à l’authentification multifacteur Microsoft Entra sont disponibles sous l’onglet Inscription. Vous pouvez descendre dans la hiérarchie pour voir la liste des utilisateurs inscrits en sélectionnant le lien hypertexte Utilisateurs compatibles avec l’authentification multifacteur Azure.
Étapes de nettoyage
Une fois que vous avez effectué la migration vers l’authentification multifacteur Microsoft Entra et que vous êtes prêt à désactiver le serveur MFA, effectuez les trois opérations suivantes :
Restaurez les règles de revendication sur AD FS à leur configuration de prémigration, puis supprimez le fournisseur d’authentification basé sur le serveur MFA.
Supprimez le serveur MFA en tant que fournisseur d’authentification dans AD FS. Vous garantissez ainsi que tous les utilisateurs utilisent l’authentification multifacteur Microsoft Entra car il s’agit de la seule méthode d’authentification supplémentaire activée.
Désactivez le serveur MFA.
Restaurer les règles de revendication sur AD FS et supprimer le fournisseur d’authentification basé sur le serveur MFA
Suivez les étapes décrites sous Configurer des règles de revendication pour appeler l’authentification multifacteur Microsoft Entra afin de restaurer les règles de revendication sauvegardées et de supprimer les règles de revendication AzureMFAServerAuthentication.
Par exemple, supprimez les éléments suivants des règles :
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'
Désactiver le serveur MFA en tant que fournisseur d’authentification dans AD FS
Cette modification garantit que seule l’authentification multifacteur Microsoft Entra est utilisée comme fournisseur d’authentification.
Ouvrez la Console de gestion AD FS.
Sous Services, cliquez avec le bouton droit sur Méthodes d’authentification, puis sélectionnez Modifier les méthodes d’authentification multifacteur.
Décochez la case en regard de Azure Multi-Factor Authentication Server (Serveur Azure Multi-Factor Authentication).
Désactiver le serveur MFA
Suivez le processus de désactivation de votre serveur d’entreprise pour supprimer les serveurs MFA de votre environnement.
Considérations éventuelles à prendre en compte au moment de la désactivation des serveurs MFA :
Passez en revue les journaux du serveur MFA pour vérifier qu’aucun utilisateur ou aucune application n’utilise le serveur avant sa suppression.
Désinstallez Serveur Multi-Factor Authentication à partir du Panneau de configuration du serveur
Vous pouvez éventuellement nettoyer les journaux et les répertoires de données restants après les avoir sauvegardés au préalable.
Désinstallez le kit de développement logiciel du serveur Web d’authentification multifacteur, le cas échéant, notamment les fichiers restants situés dans les répertoires etpub\wwwroot\MultiFactorAuthWebServiceSdk et/ou MultiFactorAuth.
Pour les versions du serveur MFA antérieures à la version 8.0, vous devrez peut-être également supprimer l’authentification multifacteur du service web de l’application téléphonique.