Dépannage de problèmes AD FS – Microsoft Entra ID
Avec la croissance du cloud, de nombreuses entreprises ont décidé d'utiliser Microsoft Entra ID pour leurs différents services et applications. La fédération avec Microsoft Entra ID est devenue une pratique standard pour de nombreuses organisations. Ce document couvre certains aspects de la résolution des problèmes qui surviennent avec cette fédération. Plusieurs des rubriques du document de dépannage des problèmes généraux concernent toujours la fédération avec Azure. Ce document se concentrera donc uniquement sur les spécificités de l'interaction Microsoft Entra ID et AD FS.
Redirection vers AD FS
La redirection se produit lorsque vous vous connectez à une application telle que Office 365 et que vous êtes « redirigé » vers les serveurs AD FS de votre organisation pour vous connecter.
Premiers points à vérifier
Si la redirection ne se produit pas, vous souhaitez vérifier quelques points
Assurez-vous que votre client Microsoft Entra est activé pour la fédération en vous connectant au Portail Azure et en vérifiant sous Microsoft Entra Connect.
Assurez-vous que votre domaine personnalisé est vérifié en cliquant sur le domaine en regard de Fédération dans le Portail Azure.
Enfin, il convient de vérifier DNS et de vérifier que vos serveurs AD FS ou WAP sont résolus à partir d’Internet. Vérifiez que ceci est résolu et que vous êtes en mesure d’y accéder.
Vous pouvez également utiliser l’applet de commande PowerShell
Get-MgDomain
pour obtenir ces informations.
Vous recevez une erreur de méthode d’authentification inconnue
Vous pouvez rencontrer une erreur « Méthode d’authentification inconnue » indiquant qu’AuthnContext n’est pas pris en charge au niveau AD FS ou STS lorsque vous êtes redirigé à partir d’Azure.
Cela est le plus courant quand Microsoft Entra ID redirige vers AD FS ou STS à l'aide d'un paramètre qui applique une méthode d'authentification.
Pour appliquer une méthode d’authentification, utilisez l’une des méthodes suivantes :
Pour WS-Federation, utilisez une chaîne de requête WAUTH pour forcer une méthode d’authentification préférée.
Pour SAML2.0, utilisez les éléments suivants :
<saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext>
Lorsque la méthode d’authentification appliquée est envoyée avec une valeur incorrecte, ou si cette méthode d’authentification n’est pas prise en charge sur AD FS ou STS, vous recevez un message d’erreur avant d’être authentifié.
Méthode d’authentification souhaitée | URI wauth |
---|---|
Authentification par nom d’utilisateur et mot de passe | urn:oasis:names:tc:SAML:1.0:am:password |
Authentification du client SSL | urn:ietf:rfc:2246 |
Authentification intégrée de Windows | urn:federation:authentication:windows |
Classes de contexte d’authentification SAML prises en charge
Méthode d'authentification | URI de la classe de contexte d’authentification |
---|---|
Nom d'utilisateur et mot de passe | urn:oasis:names:tc:SAML:2.0:ac:classes:Password |
Transport protégé par mot de passe | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport |
Client TLS (Transport Layer Security) | urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient |
Certificat X.509 | urn:oasis:names:tc:SAML:2.0:ac:classes:X509 |
Authentification Windows intégrée | urn:federation:authentication:windows |
Kerberos | urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos |
Pour vous assurer que la méthode d’authentification est prise en charge au niveau AD FS, vérifiez les points suivants.
AD FS 2.0
Sous /adfs/ls/web.config, vérifiez que l’entrée pour le type d’authentification est présente.
<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>
AD FS 2012 R2
Sous Gestion AD FS, cliquez sur Stratégies d’authentification dans le composant logiciel enfichable AD FS.
Dans la section Authentification principale, cliquez sur Modifier en regard de Paramètres globaux. Vous pouvez également cliquer avec le bouton droit sur Stratégies d’authentification, puis sélectionner Modifier l’authentification principale globale. Dans le volet Actions, sélectionnez Modifier l’authentification principale globale.
Dans la fenêtre Modifier la stratégie d’authentification globale, sous l’onglet Principal, vous pouvez configurer les paramètres suivants dans le cadre de la stratégie d’authentification globale. Par exemple, pour l’authentification principale, vous pouvez sélectionner les méthodes d’authentification disponibles sous Extranet et Intranet.
**Vérifiez que la case à cocher méthode d’authentification requise est cochée.
AD FS 2016
Sous Gestion AD FS, cliquez sur Méthodes de service et d’authentification dans le composant logiciel enfichable AD FS.
Dans la section Authentification principale, cliquez sur Modifier.
Dans la fenêtre Modifier les méthode d'authentification, sous l’onglet Principal, vous pouvez configurer les paramètres suivants dans le cadre de la stratégie d’authentification.
Jetons émis par AD FS
Microsoft Entra ID renvoie un message d'erreur après l'édition de jeton
Après l'édition d'un jeton par AD FS, Microsoft Entra ID peut générer un message d'erreur. Dans ce cas, recherchez les problèmes suivants :
- Les revendications faites par AD FS dans le jeton doivent correspondre aux attributs respectifs de l'utilisateur dans Microsoft Entra ID.
- Le jeton pour Microsoft Entra ID doit contenir les revendications requises suivantes :
- WSFED :
- UPN : la valeur de cette revendication doit correspondre à l'UPN des utilisateurs dans Microsoft Entra ID.
- ImmutableID : la valeur de cette revendication doit correspondre à sourceAnchor ou ImmutableID de l'utilisateur dans Microsoft Entra ID.
- WSFED :
Pour obtenir la valeur d'attribut User dans Microsoft Entra ID, exécutez la ligne de commande suivante : Get-AzureADUser –UserPrincipalName <UPN>
- SAML 2.0 :
- IDPEmail : la valeur de cette revendication doit correspondre au nom d'utilisateur principal des utilisateurs dans Microsoft Entra ID.
- NAMEID : la valeur de cette revendication doit correspondre au sourceAnchor ou ImmutableID de l'utilisateur dans Microsoft Entra ID.
Pour plus d’informations, consultez Utiliser un fournisseur d’identité SAML 2.0 pour implémenter l’authentification unique.
Incompatibilité de certificat de signature de jetons entre AD FS et Microsoft Entra ID
AD FS utilise le certificat de signature de jeton pour signer le jeton envoyé à l’utilisateur ou à l’application. L'approbation entre AD FS et Microsoft Entra ID est une approbation fédérée basée sur ce certificat de signature de jeton.
Toutefois, si le certificat de signature de jeton côté AD FS est modifié en raison de la substitution de certificat automatique ou d'une intervention, les détails du nouveau certificat doivent être mis à jour côté Microsoft Entra ID pour le domaine fédéré. Lorsque le certificat de signature de jetons principal sur AD FS est différent de celui de Microsoft Entra ID, le jeton émis par AD FS n’est pas approuvé par Microsoft Entra ID. Par conséquent, l’utilisateur fédéré n’est pas autorisé à se connecter.
Pour résoudre ce problème, vous pouvez utiliser les étapes décrites dans Renouveler des certificats de fédération pour Office 365 et Microsoft Entra ID.
Autres points courants à vérifier
Voici une brève liste d'éléments à vérifier si vous rencontrez des problèmes avec l'interaction AD FS et Microsoft Entra.
- Identifiants obsolètes ou mis en cache dans le Gestionnaire d’identifiants Windows
- L’algorithme de hachage sécurisé configuré sur l’approbation de partie de confiance pour Office 365 est défini sur SHA1