Partager via


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.

Redirection screen to AD FS

Premiers points à vérifier

Si la redirection ne se produit pas, vous souhaitez vérifier quelques points

  1. 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.

    User sign-in screen in Microsoft Entra Connect

  2. Assurez-vous que votre domaine personnalisé est vérifié en cliquant sur le domaine en regard de Fédération dans le Portail Azure.

    Domain shown next to federation in the portal

  3. 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.

  4. Vous pouvez également utiliser l’applet de commande PowerShell Get-MgDomain pour obtenir ces informations.

    Screenshot of the PowerShell window showing the results of the Get-MgDomain command.

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.

Edit Authentication Methods window

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.

Pour obtenir la valeur d'attribut User dans Microsoft Entra ID, exécutez la ligne de commande suivante : Get-AzureADUser –UserPrincipalName <UPN>

Screenshot of the PowerShell window showing the results of the Get-AzureADUser command.

  • 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

Étapes suivantes