Résolution des problèmes AD FS : Microsoft Entra ID

Avec la croissance de l'informatique en nuage, de nombreuses entreprises ont adopté l'ID Microsoft Entra pour leurs différentes applications et services. La fédération avec Microsoft Entra ID est désormais une pratique standard avec de nombreuses organisations. Cet article traite de certains aspects de la résolution des problèmes qui surviennent avec cette fédération. Plusieurs des rubriques de l’article de dépannage général concernent toujours la fédération avec Azure. Cet article décrit donc des spécificités avec l’interaction microsoft Entra ID et Active Directory Federation Services (AD FS).

Redirection vers AD FS

La redirection se produit lorsque vous vous connectez à une application telle qu’Office 365 et que vous êtes redirigé vers les serveurs AD FS de votre organisation pour vous connecter.

Première chose à vérifier

Si la redirection ne se produit pas, il existe quelques éléments à vérifier.

1. Vérifiez que votre locataire Microsoft Entra est activé pour la fédération. Connectez-vous au portail Azure et vérifiez sous Microsoft Entra Connect.

   

2. Vérifiez que votre domaine personnalisé est vérifié. Sélectionnez le domaine en regard de fédération dans le portail Azure.

   

3. Vérifiez le système DNS et assurez-vous que vos serveurs AD FS ou serveurs proxy d’application Web sont accessibles via l'Internet. Vérifiez qu’ils sont résolus et que vous pouvez y accéder.

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

   

Vous recevez une erreur « Méthode d’authentification inconnue »

Vous pouvez rencontrer une erreur « Méthode d’authentification inconnue » indiquant que AuthnContext n’est pas pris en charge au niveau du service d’émission de jeton de sécurité (STS) ou AD FS lorsque vous êtes redirigé depuis Azure.

Ce scénario est le plus courant lorsque 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 SAML 2.0, utilisez le code suivant :

  <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 (Secure Sockets Layer)	urn:ietf:rfc:2246
Authentification intégrée Windows	urn:federation:authentication:windows

Le tableau suivant répertorie les 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 de sécurité de la couche de transport (TLS)	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 éléments suivants.

AD FS 2.0

Sous /adfs/ls/web.config, vérifiez que l’entrée du 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

1. Sous Gestion AD FS, sélectionnez Stratégies d’authentification dans le composant logiciel enfichable AD FS.

2. Dans la section Authentification principale , en regard des paramètres globaux, sélectionnez Modifier. Vous pouvez également cliquer avec le bouton droit sur Stratégies d’authentification, puis sélectionner Modifier l’authentification principale globale. Ou dans le volet Actions , sélectionnez Modifier l’authentification principale globale.

3. Dans le volet Modifier la stratégie d’authentification globale , sous l’onglet Principal , vous pouvez configurer les paramètres dans le cadre de la stratégie d’authentification globale. Par exemple, pour l’authentification principale, sélectionnez les méthodes d’authentification disponibles sous Extranet et Intranet.

   Vérifiez que la case à cocher de la méthode d’authentification requise est cochée.

AD FS 2016

1. Sous Gestion AD FS, sélectionnezMéthodes d’authentification de > dans le composant logiciel enfichable AD FS.

2. Dans la section Authentification principale , sélectionnez Modifier.

3. Dans le volet Modifier les méthodes d’authentification , sous l’onglet Principal , vous pouvez configurer les paramètres dans le cadre de la stratégie d’authentification.

   

Jetons émis par AD FS

Cette section décrit les jetons émis par AD FS.

Microsoft Entra ID provoque une erreur après l’émission de jeton

Une fois qu’AD FS émet un jeton, l’ID Microsoft Entra peut générer une erreur. Dans ce cas, recherchez les problèmes suivants :

• Les revendications émises par AD FS dans le jeton doivent correspondre aux attributs respectifs de l’utilisateur dans Microsoft Entra ID.

• Le jeton de l’ID Microsoft Entra doit contenir les revendications requises suivantes :

  • WSFED :

    • UPN : La valeur de cette revendication doit correspondre au nom d’utilisateur principal (UPN) des utilisateurs dans l’ID Microsoft Entra.
    • ImmuableID : la valeur de cette revendication doit correspondre aux sourceAnchor ou ImmutableID attributs de l’utilisateur dans Microsoft Entra ID.

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

    

  • SAML 2.0 :

    • IDPEmail : La valeur de cette revendication doit correspondre à l’UPN des utilisateurs dans l’ID Microsoft Entra.
    • NAMEID : La valeur de cette revendication doit correspondre aux attributs 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. La relation de confiance entre AD FS et Microsoft Entra ID est une relation fédérée fondée sur ce certificat de signature de jeton.

Si le certificat de signature de jetons du côté AD FS est modifié en raison d'un changement automatique de certificat ou par une intervention, les détails du nouveau certificat doivent être mis à jour sur le côté Microsoft Entra ID pour le domaine fédéré. Lorsque le certificat de signature de jeton principal sur ad FS est différent de l’ID Microsoft Entra, l’ID Microsoft Entra n’approuve pas le jeton émis par AD FS. Pour cette raison, l’utilisateur fédéré n’est pas autorisé à se connecter.

Pour résoudre ce problème, suivez les étapes décrites dans Renouveler les certificats de fédération pour Office 365 et l’ID Microsoft Entra.

Autres éléments courants à vérifier

Si vous rencontrez des problèmes avec l’interaction AD FS et Microsoft Entra, vérifiez les éléments suivants :

• Informations d’identification obsolètes ou mises en cache dans le Gestionnaire d’informations d’identification Windows.
• L’algorithme de hachage sécurisé (SHA) configuré pour la configuration de confiance avec Office 365 est réglé sur SHA1.

Contenu connexe

• Dépannage AD FS