Résoudre les problèmes d’authentification unique avec Services ADFS (AD FS)

Cet article vous aide à résoudre les problèmes d’authentification unique (SSO) avec Services ADFS (AD FS).

Sélectionnez l’une des sections suivantes en fonction du type de problème que vous rencontrez.

S’applique à : Services ADFS
Numéro de la base de connaissances d’origine : 4034932

Invite d’authentification NTLM ou basée sur des formulaires

Lors de la résolution des problèmes d’authentification unique (SSO) avec Services ADFS (AD FS), si les utilisateurs ont reçu une invite d’authentification NTLM ou par formulaire inattendue, suivez les étapes décrites dans cet article pour résoudre ce problème.

Vérifier les paramètres de l’authentification intégrée Windows

Pour résoudre ce problème, case activée paramètres d’authentification intégrée Windows dans le navigateur client, les paramètres AD FS et les paramètres de demande d’authentification.

Vérifier le navigateur client de l’utilisateur

Vérifiez les paramètres suivants dans Options Internet :

• Sous l’onglet Avancé , vérifiez que le paramètre Activer l’authentification Windows intégrée est activé.
• Après Sécurité>Intranet local>Sites>Avancés, vérifiez que l’URL AD FS figure dans la liste des sites web.
• Après Sécurité > Intranet local > Niveau personnalisé, vérifiez que le paramètre Ouverture de session automatique uniquement dans zone intranet est sélectionné.

Si vous utilisez Firefox, Chrome ou Safari, vérifiez que les paramètres équivalents dans ces navigateurs sont activés.

Vérifier les paramètres AD FS

Vérifier le paramètre WindowsIntegratedFallback

1. Ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Obtenez la stratégie d’authentification globale en exécutant la commande suivante :

   Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
   

3. Examinez la valeur de l’attribut WindowsIntegratedFallbackEnabled .

Si la valeur est True, l’authentification basée sur les formulaires est attendue. Cela signifie que la demande d’authentification provient d’un navigateur qui ne prend pas en charge l’authentification intégrée Windows. Consultez la section suivante sur la prise en charge de votre navigateur.

Si la valeur est False, l’authentification intégrée Windows doit être attendue.

Vérifier le paramètre WIASupportedUsersAgents

1. Obtenez la liste des agents utilisateur pris en charge en exécutant la commande suivante :

   Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

2. Examinez la liste des chaînes d’agent utilisateur retournées par la commande.

Vérifiez si la chaîne de l’agent utilisateur de votre navigateur figure dans la liste. Si ce n’est pas le cas, ajoutez la chaîne de l’agent utilisateur en suivant les étapes ci-dessous :

1. Accédez à http://useragentstring.com/ qui détecte et affiche la chaîne de l’agent utilisateur de votre navigateur.

2. Obtenez la liste des agents utilisateur pris en charge en exécutant la commande suivante :

   $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

3. Ajoutez la chaîne de l’agent utilisateur de votre navigateur en exécutant la commande suivante :

   $wiaStrings = $wiaStrings+"NewUAString"
   

   Exemple :

   $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
   

4. Mettez à jour le paramètre WIASupportedUserAgents en exécutant la commande suivante :

   Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
   

Vérifier les paramètres de demande d’authentification

Vérifiez si la demande d’authentification spécifie l’authentification basée sur les formulaires comme méthode d’authentification

1. Si la demande d’authentification est une demande WS-Federation, case activée si la demande inclut wauth= urn :oasis :names :tc :SAML :1.0 :am :password.
2. Si la demande d’authentification est une requête SAML, case activée si la demande inclut un élément samlp :AuthnContextClassRef avec la valeur urn :oasis :names :tc :SAML :2.0 :ac :classes :Password.

Pour plus d’informations, consultez Vue d’ensemble des gestionnaires d’authentification des pages de connexion AD FS.

Vérifiez si l’application est Microsoft Online Services pour Office 365

Si l’application à laquelle vous souhaitez accéder n’est pas Microsoft Online Services, ce que vous rencontrez est attendu et contrôlé par la demande d’authentification entrante. Collaborez avec le propriétaire de l’application pour modifier le comportement.

Si l’application est Microsoft Online Services, ce que vous rencontrez peut être contrôlé par le paramètre PromptLoginBehavior de l’objet domaine approuvé. Ce paramètre contrôle si Microsoft Entra locataires envoient prompt=login à AD FS. Pour définir le paramètre PromptLoginBehavior , procédez comme suit :

1. Ouvrez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».

2. Obtenez le paramètre de fédération de domaine existant en exécutant la commande suivante :

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

3. Définissez le paramètre PromptLoginBehavior en exécutant la commande suivante :

   Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
   

   Les valeurs du paramètre PromptLoginBehavior sont les suivantes :

   1. TranslateToFreshPasswordAuth : Microsoft Entra ID envoie wauth et wfresh à AD FS au lieu de prompt=login. Cela conduit à une demande d’authentification pour utiliser l’authentification basée sur les formulaires.
   2. NativeSupport : le paramètre prompt=login est envoyé tel qu’il est à AD FS.
   3. Désactivé : rien n’est envoyé à AD FS.

Pour en savoir plus sur la commande Set-MSOLDomainFederationSettings, consultez prise en charge des paramètres Services ADFS prompt=login.

Microsoft Entra scénario

Si la demande d’authentification envoyée à Microsoft Entra ID inclut le paramètre prompt=login, désactivez la fonctionnalité prompt=login en exécutant la commande suivante :

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Après avoir exécuté cette commande, Office 365 applications n’incluent pas le paramètre prompt=login dans chaque demande d’authentification.

Scénario non Microsoft Entra

Les méthodes d’authentification peuvent être spécifiées pour les paramètres de requête tels que WAUTH et RequestedAuthNContext dans les demandes d’authentification. Vérifiez si d’autres paramètres de requête appliquent l’invite d’authentification inattendue. Si c’est le cas, modifiez le paramètre de requête pour utiliser la méthode d’authentification attendue.

Vérifier si l’authentification unique est désactivée

Si l’authentification unique est désactivée, activez-la et testez si le problème est résolu.

Invite d’authentification multifacteur

Pour résoudre ce problème, case activée si les règles de revendication de la partie de confiance sont correctement définies pour l’authentification multifacteur.

L’authentification multifacteur peut être activée sur un serveur AD FS, une partie de confiance ou spécifiée dans un paramètre de demande d’authentification. Vérifiez les configurations pour voir si elles sont correctement définies. Si l’authentification multifacteur est attendue, mais que vous y êtes invité à plusieurs reprises, case activée les règles d’émission de la partie de confiance pour voir si les revendications d’authentification multifacteur sont transmises à l’application.

Pour plus d’informations sur l’authentification multifacteur dans AD FS, consultez les articles suivants :

• Visite guidée sur l’authentification multifacteur dans ADFS – Partie 1 : stratégie
• Visite guidée sur l’authentification multifacteur dans ADFS – Partie 2 : parties de confiance prenant en charge MFA

Vérifier la configuration sur le serveur AD FS et la partie de confiance

Pour case activée la configuration sur le serveur AD FS, validez les règles d’authentification supplémentaires globales. Pour case activée la configuration sur la partie de confiance, validez les règles d’authentification supplémentaires pour l’approbation de la partie de confiance.

1. Pour case activée la configuration sur le serveur AD FS, exécutez la commande suivante dans une fenêtre Windows PowerShell.

   Get-ADFSAdditionalAuthenticationRule
   

   Pour case activée la configuration sur la partie de confiance, exécutez la commande suivante :

   Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
   

   Remarque

   Si les commandes ne retournent rien, les règles d’authentification supplémentaires ne sont pas configurées. Ignorez cette section.

2. Observez l’ensemble de règles de revendication configuré.

Vérifier si l’authentification multifacteur est activée dans l’ensemble de règles de revendication

Un ensemble de règles de revendication est composé des sections suivantes :

• L’instruction de condition : C:[Type=``…,Value=…]
• L’instruction du problème : => issue (Type=``…,Value=…)

Si l’instruction issue contient la revendication suivante, l’authentification multifacteur est spécifiée.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Voici des exemples qui nécessitent l’utilisation de l’authentification multifacteur pour les appareils non joints à l’espace de travail et pour l’accès extranet, respectivement :

• c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", 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/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Vérifier les règles d’émission de la partie de confiance

Si l’utilisateur reçoit à plusieurs reprises des invites d’authentification multifacteur après avoir effectué la première authentification, il est possible que le répondeur ne passe pas les revendications d’authentification multifacteur à l’application. Pour case activée si les revendications d’authentification sont transmises, procédez comme suit :

1. Exécutez la commande suivante dans Windows PowerShell:

   Get-ADFSRelyingPartyTrust -TargetName ClaimApp
   

2. Observez l’ensemble de règles défini dans les attributs IssuanceAuthorizationRules ou IssuanceAuthorizationRulesFile.

L’ensemble de règles doit inclure la règle d’émission suivante pour passer par les revendications d’authentification multifacteur :
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

Vérifier le paramètre de demande d’authentification

Vérifier si la demande d’authentification spécifie l’authentification multifacteur comme méthode d’authentification

• Si la demande d’authentification est une demande WS-Federation, case activée si la demande inclut wauth= http://schemas.microsoft.com/claims/multipleauthn.
• Si la demande d’authentification est une requête SAML, case activée si la requête inclut un élément samlp :AuthnContextClassRef avec la valeur http://schemas.microsoft.com/claims/multipleauthn.

Pour plus d’informations, consultez Vue d’ensemble des gestionnaires d’authentification des pages de connexion AD FS.

Vérifiez si l’application est Microsoft Online Services pour Office 365

Si l’application à laquelle vous souhaitez accéder est Microsoft Online Services pour Office 365, case activée le paramètre de fédération de domaine SupportsMFA.

1. Obtenez le paramètre de fédération de domaine SupportsMFA actuel en exécutant la commande suivante :

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

2. Si le paramètre SupportsMFA a la valeur FALSE, définissez-le sur TRUE en exécutant la commande suivante :

   Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
   

Vérifier si l’authentification unique est désactivée

Si l’authentification unique est désactivée, activez-la et testez si le problème est résolu.

Les utilisateurs ne peuvent pas se connecter au site ou au service cible

Ce problème peut se produire sur la page de connexion AD FS ou côté application.

Si le problème se produit sur la page de connexion AD FS, vous recevez un message d’erreur « Une erreur s’est produite », « Le service HTTP 503 n’est pas disponible » ou un autre message d’erreur. L’URL de la page d’erreur affiche le nom du service AD FS, par fs.contoso.comexemple .

Si le problème se produit côté application, l’URL de la page d’erreur affiche l’adresse IP ou le nom du site du service cible.

Suivez les étapes de la section suivante en fonction de l’endroit où vous rencontrez ce problème.

Ce problème se produit sur la page de connexion AD FS

Pour résoudre ce problème, case activée si tous les utilisateurs sont affectés par le problème et si les utilisateurs peuvent accéder à toutes les parties de confiance.

Tous les utilisateurs sont affectés par le problème et l’utilisateur ne peut accéder à aucune des parties de confiance

Nous allons case activée la fonctionnalité de connexion interne à l’aide de IdpInitiatedSignOn. Pour ce faire, utilisez la page IdpInititatedSignOn pour vérifier si le service AD FS est opérationnel et que la fonctionnalité d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :

1. Activez la page IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. À partir d’un ordinateur qui se trouve à l’intérieur de votre réseau, visitez la page suivante :
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Entrez les informations d’identification correctes d’un utilisateur valide sur la page de connexion.

La connexion est réussie

Si la connexion réussit, case activée si l’état du service AD FS est en cours d’exécution.

1. Sur le serveur AD FS, ouvrez Gestionnaire de serveur.
2. Dans la Gestionnaire de serveur, cliquez sur Outils>Services.
3. Vérifiez si l’état de Services ADFS est en cours d’exécution.

Ensuite, case activée la fonctionnalité de connexion externe à l’aide de IdpInitiatedSignOn. Utilisez la page IdpInititatedSignOn pour vérifier rapidement si le service AD FS est opérationnel et si la fonctionnalité d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :

1. Activez la page IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. À partir d’un ordinateur qui se trouve en dehors de votre réseau, visitez la page suivante :
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. Entrez les informations d’identification correctes d’un utilisateur valide sur la page de connexion.

Si la connexion échoue, consultez Vérifier les composants et services ad FS associés etVérifier la relation d’approbation du proxy.

Si la connexion réussit, poursuivez la résolution des problèmes en suivant les étapes décrites dans Tous les utilisateurs sont affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance.

Échec de la connexion

Si la connexion échoue, case activée les composants et services ad FS associés.

Vérifiez si l’état du service AD FS est en cours d’exécution.

1. Sur le serveur AD FS, ouvrez Gestionnaire de serveur.
2. Dans la Gestionnaire de serveur, cliquez sur Outils>Services.
3. Vérifiez si l’état de Services ADFS est en cours d’exécution.

Vérifiez si les points de terminaison sont activés. AD FS fournit différents points de terminaison pour différentes fonctionnalités et scénarios. Tous les points de terminaison ne sont pas activés par défaut. Pour case activée le status des points de terminaison, procédez comme suit :

1. Sur le serveur AD FS, ouvrez la console de gestion AD FS.

2. DéveloppezPoints de terminaison deservice>.

3. Recherchez les points de terminaison et vérifiez si les états sont activés dans la colonne Activé .

   

Ensuite, case activée si Microsoft Entra Connect est installé. Nous vous recommandons d’utiliser Microsoft Entra Connect, ce qui facilite la gestion des certificats SSL.

Si Microsoft Entra Connect est installé, veillez à l’utiliser pour gérer et mettre à jour les certificats SSL.

Si Microsoft Entra Connect n’est pas installé, case activée si le certificat SSL répond aux exigences AD FS suivantes :

• Le certificat provient d’une autorité de certification racine approuvée.

  AD FS exige que les certificats SSL proviennent d’une autorité de certification racine approuvée. Si AD FS est accessible à partir d’ordinateurs non joints à un domaine, nous vous recommandons d’utiliser un certificat SSL d’une autorité de certification racine tierce de confiance comme DigiCert, VeriSign, etc. Si le certificat SSL ne provient pas d’une autorité de certification racine approuvée, la communication SSL peut s’interrompre.

• Le nom de l’objet du certificat est valide.

  Le nom de l’objet doit correspondre au nom du service de fédération, et non au nom du serveur AD FS ou à un autre nom. Pour obtenir le nom du service de fédération, exécutez la commande suivante sur le serveur AD FS principal :
  Get-AdfsProperties | select hostname

• Le certificat n’est pas révoqué.

  Vérifiez la révocation du certificat. Si le certificat est révoqué, la connexion SSL ne peut pas être approuvée et est bloquée par les clients.

Si le certificat SSL ne répond pas à ces exigences, essayez d’obtenir un certificat qualifié pour la communication SSL. Nous vous recommandons d’utiliser Microsoft Entra Connect, ce qui facilite la gestion des certificats SSL. Consultez Mettre à jour le certificat TLS/SSL pour une batterie de serveurs Services ADFS (AD FS).

Si le certificat SSL répond à ces exigences, case activée les configurations suivantes du certificat SSL.

Vérifier si le certificat SSL est correctement installé

Le certificat SSL doit être installé dans le magasin Personnel de l’ordinateur local sur chaque serveur de fédération de votre batterie de serveurs. Pour installer le certificat, double-cliquez sur . Fichier PFX du certificat et suivez l’Assistant.

Pour vérifier si le certificat est installé à l’emplacement approprié, procédez comme suit :

1. Répertoriez les certificats qui se trouvent dans le magasin personnel de l’ordinateur local en exécutant la commande suivante :
   dir Cert:\LocalMachine\My
2. Vérifiez si le certificat figure dans la liste.

Vérifier si le certificat SSL correct est en cours d’utilisation

Obtenez l’empreinte numérique du certificat utilisé pour la communication SSL et vérifiez si l’empreinte numérique correspond à l’empreinte du certificat attendue.

Pour obtenir l’empreinte numérique du certificat en cours d’utilisation, exécutez la commande suivante dans Windows PowerShell :

Get-AdfsSslCertificate

Si le certificat incorrect est utilisé, définissez le certificat correct en exécutant la commande suivante :

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Vérifier si le certificat SSL est défini comme certificat de communication de service

Le certificat SSL doit être défini comme certificat de communication de service dans votre batterie de serveurs AD FS. Cela ne se produit pas automatiquement. Pour case activée si le certificat correct est défini, procédez comme suit :

1. Dans la console de gestion AD FS, développezCertificatsde service>.
2. Vérifiez si le certificat répertorié sous Communications de service est le certificat attendu.

Si le certificat incorrect est répertorié, définissez le certificat approprié, puis accordez au service AD FS l’autorisation de lecture sur le certificat. Pour cela, procédez comme suit :

1. Définissez le certificat correct :

   1. Cliquez avec le bouton droit sur Certificats, puis cliquez sur Définir le certificat de communication de service.
   2. Sélectionnez le certificat approprié.

2. Vérifiez si le service AD FS dispose de l’autorisation Lecture sur le certificat :

   1. Ajoutez le composant logiciel enfichable Certificats pour le compte d’ordinateur local à la console MMC (Microsoft Management Console).
   2. Développez Certificats (Ordinateur local)>Personnel>Certificats.
   3. Cliquez avec le bouton droit sur le certificat SSL, puis cliquez sur Toutes les tâches>Gérer les clés privées.
   4. Vérifiez si adfssrv est répertorié sous Noms de groupe et d’utilisateur avec l’autorisation Lecture .

3. Si adfssrv n’est pas répertorié, accordez au service AD FS l’autorisation lecture sur le certificat :

   1. Cliquez sur Ajouter, sur Emplacements, sur le serveur, puis sur OK.
   2. Sous Entrez les noms d’objets à sélectionner, entrez nt service\adfssrv, cliquez sur Vérifier les noms, puis cliquez sur OK.
      Si vous utilisez AD FS avec le service d’inscription d’appareil (DRS), entrez nt service\drs à la place.
   3. Accordez l’autorisation Lecture , puis cliquez sur OK.

Vérifier si le service d’inscription d’appareil (DRS) est configuré dans AD FS

Si vous avez configuré AD FS avec DRS, assurez-vous que le certificat SSL est également correctement configuré pour les services Bureau à distance. Par exemple, s’il existe deux suffixes contoso.com UPN et fabrikam.com, le certificat doit avoir enterpriseregistration.contoso.com et enterpriseregistration.fabrikma.com comme autres noms d’objet (SAN).

Pour case activée si le certificat SSL possède les san appropriés, procédez comme suit :

1. Répertoriez tous les suffixes UPN utilisés dans le organization en exécutant la commande suivante :

   Get-AdfsDeviceRegistratrionUpnSuffix
   

2. Vérifiez si les SAN requis sont configurés pour le certificat SSL.

3. Si le certificat SSL n’a pas les noms DRS corrects en tant que SAN, obtenez un nouveau certificat SSL qui a les SAN appropriés pour DRS, puis utilisez-le comme certificat SSL pour AD FS.

Ensuite, case activée la configuration du certificat sur les serveurs WAP et les liaisons de secours :

• Vérifiez si le certificat SSL correct est défini sur tous les serveurs WAP.

  1. Assurez-vous que le certificat SSL est installé dans le magasin Personnel de l’ordinateur local sur chaque serveur WAP.

  2. Obtenez le certificat SSL utilisé par WAP en exécutant la commande suivante :

     Get-WebApplicationProxySslCertificate
     

  3. Si le certificat SSL est incorrect, définissez le certificat SSL correct en exécutant la commande suivante :

     Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
     

• Vérifiez les liaisons de certificat et mettez-les à jour si nécessaire.

  Pour prendre en charge les cas non-SNI, les administrateurs peuvent spécifier des liaisons de secours. Outre la liaison federationservicename :443 standard, recherchez les liaisons de secours sous les ID d’application suivants :

  • {5d89a20c-beab-4389-9447-324788eb944a} : ID d’application pour AD FS.
  • {f955c070-e044-456c-ac00-e9e4275b3f04} : ID d’application pour web Proxy d'application.

  Par exemple, si le certificat SSL est spécifié pour une liaison de secours comme 0.0.0.0 :443, assurez-vous que la liaison est mise à jour en conséquence lorsque le certificat SSL est mis à jour.

Tous les utilisateurs sont affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance

Tout d’abord, nous allons obtenir les informations de la partie de confiance et du client OAuth. Si vous utilisez une partie de confiance conventionnelle, procédez comme suit :

1. Sur le serveur AD FS principal, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Ajoutez le composant AD FS 2.0 à Windows PowerShell en exécutant la commande suivante :

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Obtenez les informations de la partie de confiance en exécutant la commande suivante :

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Obtenez les informations du client OAuth en exécutant la commande suivante :

   $client = Get-AdfsClient ClientName
   

Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, suivez les étapes ci-dessous :

1. Sur le serveur AD FS principal, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Obtenez les informations de la partie de confiance en exécutant la commande suivante :
   $rp = Get-AdfsWebApiApplication ResourceID

3. Si le client OAuth est public, obtenez les informations client en exécutant la commande suivante :

   $client = Get-AdfsNativeClientApplication ClientName
   

   Si le client est confidentiel, obtenez les informations client en exécutant la commande suivante :

   $client = Get-AdfsServerApplication ClientName
   

Passez maintenant aux méthodes de résolution des problèmes suivantes.

Vérifier les paramètres de la partie de confiance et du client

L’identificateur de la partie de confiance, l’ID client et l’URI de redirection doivent être fournis par le propriétaire de l’application et le client. Toutefois, il peut toujours y avoir une incompatibilité entre ce que le propriétaire fournit et ce qui sont configurés dans AD FS. Par exemple, une incompatibilité peut être causée par une faute de frappe. Vérifiez si les paramètres fournis par le propriétaire correspondent à ceux configurés dans AD FS. Les étapes de la page précédente vous permettent d’obtenir les paramètres configurés dans AD FS via PowerShell.

Paramètres fournis par le propriétaire	Paramètres configurés dans AD FS
ID de la partie de confiance	$rp. Identificateur
URI de redirection de la partie de confiance	Correspondance de préfixe ou de caractère générique de $rp. WSFedEndpoint pour une partie de confiance WS-Fed $rp. SamlEndpoints pour une partie de confiance SAML
ID du client	$client. Clientid
URI de redirection du client	Correspondance de préfixe de $client. RedirectUri

Si les éléments de la table correspondent, case activée également si ces paramètres correspondent entre ce qu’ils apparaissent dans la demande d’authentification envoyée à AD FS et ce qui est configuré dans AD FS. Essayez de reproduire le problème pendant lequel vous capturez une trace Fiddler sur la demande d’authentification envoyée par l’application à AD FS. Examinez les paramètres de requête pour effectuer les vérifications suivantes en fonction du type de demande.

Demandes OAuth

Une requête OAuth se présente comme suit :

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Vérifiez si les paramètres de requête correspondent aux paramètres configurés dans AD FS.

Paramètres de la requête	Paramètres configurés dans AD FS
client_id	$client. Clientid
redirect_uri	Correspondance de préfixe de @client_RedirectUri

Le paramètre « resource » doit représenter une partie de confiance valide dans AD FS. Obtenez les informations de la partie de confiance en exécutant l’une des commandes suivantes.

• Si vous utilisez une partie de confiance conventionnelle, exécutez la commande suivante :
  Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
• Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, exécutez la commande suivante :
  Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed demandes

Une demande WS-Fed se présente comme suit :

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Vérifiez si les paramètres de requête correspondent aux paramètres configurés dans AD FS :

Paramètres de la requête	Paramètres configurés dans AD FS
wtrealm	$rp. Identificateur
wreplyeply	Correspondance de préfixe ou correspondance générique de $rp. WSFedEndpoint

Requêtes SAML

Une requête SAML se présente comme suit :

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Décodez la valeur du paramètre SAMLRequest à l’aide de l’option « From DeflatedSAML » dans l’Assistant Texte fiddler. La valeur décodée se présente comme suit :

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Effectuez les vérifications suivantes dans la valeur décodée :

• Vérifiez si le nom d’hôte dans la valeur destination correspond au nom d’hôte AD FS.
• Vérifiez si la valeur de l’émetteur correspond à $rp.Identifier.

Remarques supplémentaires pour SAML :

• $rp. SamlEndpoints : affiche tous les types de points de terminaison SAML. La réponse d’AD FS est envoyée aux URL correspondantes configurées dans les points de terminaison. Un point de terminaison SAML peut utiliser des liaisons de redirection, de publication ou d’artefact pour la transmission de messages. Toutes ces URL peuvent être configurées dans AD FS.
• $rp. SignedSamlRequestsRequired : si la valeur est définie, la requête SAML envoyée par la partie de confiance doit être signée. Les paramètres « SigAlg » et « Signature » doivent être présents dans la requête.
• $rp. RequestSigningCertificate : il s’agit du certificat de signature utilisé pour générer la signature sur la requête SAML. Assurez-vous que le certificat est valide et demandez au propriétaire de l’application de faire correspondre le certificat.

Vérifier le certificat de chiffrement

Si $rp.EncryptClaims retourne Activé, le chiffrement de partie de confiance est activé. AD FS utilise le certificat de chiffrement pour chiffrer les revendications. Effectuez les vérifications suivantes :

• $rp. EncryptionCertificate : utilisez cette commande pour obtenir le certificat et case activée s’il est valide.
• $rp. EncryptionCertificateRevocationCheck : utilisez cette commande pour case activée si le certificat répond aux exigences de révocation case activée.

Les deux méthodes précédentes ne fonctionnent pas

Pour poursuivre la résolution des problèmes, consultez Utiliser l’application Jeton de vidage.

Tous les utilisateurs ne sont pas affectés par le problème, et l’utilisateur ne peut accéder à aucune des parties de confiance

Dans ce scénario, effectuez les vérifications suivantes.

Vérifier si l’utilisateur est désactivé

Vérifiez l’status utilisateur dans Windows PowerShell ou l’interface utilisateur. Si l’utilisateur est désactivé, activez-le.

Vérifier la status utilisateur avec Windows PowerShell

1. Connectez-vous à l’un des contrôleurs de domaine.

2. Ouvrez Windows PowerShell.

3. Vérifiez le status utilisateur en exécutant la commande suivante :

   Get-ADUser -Identity <samaccountname of the user> | Select Enabled
   

   

Vérifier le status utilisateur dans l’interface utilisateur

1. Connectez-vous à l’un des contrôleurs de domaine.

2. Ouvrez le console de gestion Utilisateurs et ordinateurs Active Directory.

3. Cliquez sur le nœud Utilisateurs , cliquez avec le bouton droit sur l’utilisateur dans le volet droit, puis cliquez sur Propriétés.

4. Cliquez sur l’onglet Compte .

5. Sous Options du compte, vérifiez si l’option Compte est désactivé est cochée.

   

6. Si l’option est cochée, décochez-la.

Vérifier si les propriétés de l’utilisateur ont été mises à jour récemment

Si une propriété de l’utilisateur est mise à jour dans Active Directory, cela entraîne une modification des métadonnées de l’objet utilisateur. Vérifiez l’objet de métadonnées utilisateur pour voir quelles propriétés ont été mises à jour récemment. Si des modifications sont trouvées, assurez-vous qu’elles sont récupérées par les services associés. Pour case activée si des modifications de propriété ont été apportées à un utilisateur, procédez comme suit :

1. Connectez-vous à un contrôleur de domaine.

2. Ouvrez Windows PowerShell.

3. Obtenez les métadonnées de l’objet utilisateur en exécutant la commande suivante :
   repadmin /showobjmeta <destination DC> "user DN"

   Voici un exemple de commande :
   repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

4. Dans les métadonnées, examinez la colonne Heure/Date de chaque attribut pour rechercher un indice d’une modification. Dans l’exemple suivant, l’attribut userPrincipleName prend une date plus récente que les autres attributs, ce qui représente une modification des métadonnées de l’objet utilisateur.

   

Vérifier l’approbation de forêt si l’utilisateur appartient à une autre forêt

Dans un environnement AD FS multi-forêts, une approbation de forêt bidirectionnelle est requise entre la forêt où AD FS est déployé et les autres forêts qui utilisent le déploiement AD FS pour l’authentification. Pour vérifier si l’approbation entre les forêts fonctionne comme prévu, procédez comme suit :

1. Connectez-vous à un contrôleur de domaine dans la forêt où AD FS est déployé.

2. Ouvrez le console de gestion Domaines et approbations Active Directory.

3. Dans le console de gestion, cliquez avec le bouton droit sur le domaine qui contient l’approbation que vous souhaitez vérifier, puis cliquez sur Propriétés.

4. Cliquez sur l’onglet Approbations .

5. Sous Domaines approuvés par ce domaine (approbations sortantes) ou Domaines qui approuvent ce domaine (approbations entrantes), cliquez sur l’approbation à vérifier, puis cliquez sur Propriétés.

6. Cliquez sur Valider.
   Dans la boîte de dialogue services de domaine Active Directory, sélectionnez l’une des options.

   • Si vous sélectionnez Non, nous vous recommandons de répéter la même procédure pour le domaine réciproque.

   • Si vous sélectionnez Oui, fournissez des informations d’identification d’utilisateur d’administration pour le domaine réciproque. Il n’est pas nécessaire d’effectuer la même procédure pour le domaine réciproque.

     

Si ces étapes ne vous ont pas aidé à résoudre le problème, poursuivez la résolution des problèmes avec les étapes décrites dans la section Pas tous les utilisateurs sont affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance .

Tous les utilisateurs ne sont pas affectés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance

Dans ce scénario, case activée si ce problème se produit dans un scénario Microsoft Entra. Si c’est le cas, effectuez ces vérifications pour résoudre ce problème. Si ce n’est pas le cas, consultez Utiliser l’application Jeton de vidage pour résoudre ce problème.

Vérifiez si l’utilisateur est synchronisé avec Microsoft Entra ID

Si un utilisateur tente de se connecter à Microsoft Entra ID, il est redirigé vers AD FS pour l’authentification pour un domaine fédéré. L’une des raisons possibles d’un échec de connexion est que l’utilisateur n’est pas encore synchronisé avec Microsoft Entra ID. Vous pouvez voir une boucle de Microsoft Entra ID à Active Directory FS après la première tentative d’authentification sur AD FS. Pour déterminer si l’utilisateur est synchronisé avec Microsoft Entra ID, procédez comme suit :

1. Téléchargez et installez le module Azure AD PowerShell pour Windows PowerShell.
2. Ouvrez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».
3. Lancez une connexion à Microsoft Entra ID en exécutant la commande suivante :
   Connect-MsolService
4. Fournissez les informations d’identification de l’administrateur général pour la connexion.
5. Obtenez la liste des utilisateurs dans le Microsoft Entra ID en exécutant la commande suivante :
   Get-MsolUser
6. Vérifiez si l’utilisateur figure dans la liste.

Si l’utilisateur ne figure pas dans la liste, synchronisez-le avec Microsoft Entra ID.

Vérifier immutableID et UPN dans la règle de revendication d’émission

Microsoft Entra ID nécessite immutableID et l’UPN de l’utilisateur pour authentifier l’utilisateur.

Les administrateurs peuvent utiliser Microsoft Entra Connect pour la gestion automatique de l’approbation AD FS avec Microsoft Entra ID. Si vous ne gérez pas l’approbation via Microsoft Entra Connect, nous vous recommandons de le faire en téléchargeant Microsoft Entra Connect Microsoft Entra Connect active la gestion automatique des règles de revendication en fonction des paramètres de synchronisation.

Pour case activée si les règles de revendication pour immutableID et UPN dans AD FS correspondent à ce que Microsoft Entra ID utilise, procédez comme suit :

1. Obtenez sourceAnchor et UPN dans Microsoft Entra Connect.

   1. Ouvrez Microsoft Entra Connect.

   2. Cliquez sur Afficher la configuration actuelle.

      

   3. Dans la page Vérifier votre solution , notez les valeurs SOURCE ANCHOR et USER PRINCIPAL NAME.

2. Vérifiez les valeurs immutableID (sourceAnchor) et UPN dans la règle de revendication correspondante configurée sur le serveur AD FS.

   1. Sur le serveur AD FS, ouvrez le console de gestion AD FS.

   2. Cliquez sur Approbations de partie de confiance.

   3. Cliquez avec le bouton droit sur l’approbation de partie de confiance avec Microsoft Entra ID, puis cliquez sur Modifier la stratégie d’émission de revendication.

   4. Ouvrez la règle de revendication pour l’ID immuable et l’UPN.

   5. Vérifiez si les variables interrogées pour les valeurs immutableID et UPN sont les mêmes que celles qui apparaissent dans Microsoft Entra Connect.

      

3. S’il existe une différence, utilisez l’une des méthodes ci-dessous :

   • Si AD FS est géré par Microsoft Entra Connect, réinitialisez l’approbation de la partie de confiance à l’aide de Microsoft Entra Connect.
   • Si AD FS n’est pas géré par Microsoft Entra Connect, corrigez les revendications avec les attributs appropriés.

Si ces vérifications ne vous ont pas aidé à résoudre le problème, consultez Utiliser l’application Jeton de vidage pour résoudre ce problème.

Ce problème se produit côté application

Si le certificat de signature de jeton a été renouvelé récemment par AD FS, case activée si le nouveau certificat est récupéré par le partenaire de fédération. Si AD FS utilise un certificat de déchiffrement de jeton qui a également été renouvelé récemment, effectuez également la même case activée. Pour case activée si le certificat de signature de jeton AD FS actuel sur AD FS correspond à celui du partenaire de fédération, procédez comme suit :

1. Obtenez le certificat de signature de jeton actuel sur AD FS en exécutant la commande suivante :

   Get-ADFSCertificate -CertificateType token-signing
   

2. Dans la liste des certificats retournés, recherchez celui avec IsPrimary = TRUE et notez l’empreinte numérique.

3. Obtenez l’empreinte numérique du certificat de signature de jeton actuel sur le partenaire de fédération. Le propriétaire de l’application doit vous le fournir.

4. Comparez les empreintes des deux certificats.

Effectuez la même case activée si AD FS utilise un certificat de déchiffrement de jeton renouvelé, sauf que la commande permettant d’obtenir le certificat de déchiffrement de jeton sur AD FS est la suivante :

Get-ADFSCertificate -CertificateType token-decrypting

Les empreintes numériques des deux certificats correspondent

Si les empreintes correspondent, vérifiez que les partenaires utilisent les nouveaux certificats AD FS.

En cas d’incompatibilité de certificat, vérifiez que les partenaires utilisent les nouveaux certificats. Les certificats sont inclus dans les métadonnées de fédération publiées par le serveur AD FS.

• Les partenaires peuvent accéder aux métadonnées de fédération

  Si les partenaires peuvent accéder aux métadonnées de fédération, demandez-leur d’utiliser les nouveaux certificats.

• Les partenaires ne peuvent pas accéder aux métadonnées de fédération

  Dans ce cas, vous devez envoyer manuellement aux partenaires les clés publiques des nouveaux certificats. Pour cela, procédez comme suit :

  1. Exportez les clés publiques en tant que fichiers .cert ou .p7b pour inclure l’ensemble des chaînes de certificats.
  2. Envoyez les clés publiques aux partenaires.
  3. Demandez aux partenaires d’utiliser les nouveaux certificats.

Les empreintes numériques des deux certificats ne correspondent pas

Ensuite, case activée s’il existe une incompatibilité d’algorithme de signature de jeton. Pour cela, procédez comme suit :

1. Déterminez l’algorithme utilisé par la partie de confiance en exécutant la commande suivante :

   Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
   

   Les valeurs possibles sont SHA1 ou SHA256.

2. Vérifiez auprès du propriétaire de l’application l’algorithme utilisé côté application.

3. Vérifiez si les deux algorithmes correspondent.

Si les deux algorithmes correspondent, case activée si le format d’ID de nom correspond à ce dont l’application a besoin.

1. Sur le serveur AD FS, videz les règles de transformation d’émission en exécutant la commande suivante :

   (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
   

2. Recherchez la règle qui émet la revendication NameIdentifier. Si une telle règle n’existe pas, ignorez cette étape.

   Voici un exemple de règle :

   c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

   Notez le format NameIdentifier dans la syntaxe suivante :

   Properties["Property-type-URI"] = "ValueURI"

   Les formats possibles sont répertoriés ci-dessous. Le premier format est le format par défaut.

   • urn :oasis :names :tc :SAML :1.1 :nameid-format :unspecifie.
   • urn :oasis :names :tc :SAML :1.1 :nameid-format :emailAddress
   • urn :oasis :names :tc :SAML :2.0 :nameid-format :persistent
   • urn :oasis :names :tc :SAML :2.0 :nameid-format :transient

3. Demandez au propriétaire de l’application le format NameIdentifier requis par l’application.

4. Vérifiez si les deux formats NameIdentifier correspondent.

5. Si les formats ne correspondent pas, configurez la revendication NameIdentifier pour utiliser le format requis par l’application. Pour cela, procédez comme suit :

   1. Ouvrez la console de gestion AD FS.
   2. Cliquez sur Approbations de partie de confiance, sélectionnez le partenaire de fédération approprié, puis cliquez sur Modifier la stratégie d’émission de revendications dans le volet Actions .
   3. Ajoutez une nouvelle règle s’il n’existe aucune règle pour émettre la revendication NameIdentifier, ou mettez à jour une règle existante. Sélectionnez ID de nom pour Type de revendication entrante, puis spécifiez le format requis par l’application.

   

Si les deux algorithmes ne correspondent pas, mettez à jour l’algorithme de signature utilisé par l’approbation de partie de confiance.

1. Ouvrez la console de gestion AD FS.

2. Cliquez avec le bouton droit sur l’approbation de la partie de confiance, puis cliquez sur Propriétés.

3. Sous l’onglet Avancé , sélectionnez l’algorithme qui correspond à ce dont l’application a besoin.

   

À propos du renouvellement automatique des certificats

Si le certificat de signature de jeton ou le certificat de déchiffrement de jeton sont auto-signés, AutoCertificateRollover est activé par défaut sur ces certificats et AD FS gère le renouvellement automatique des certificats lorsqu’ils arrivent à expiration.

Pour déterminer si vous utilisez des certificats auto-signés, procédez comme suit :

1. Exécutez la commande suivante :

   Get-ADFSCerticate -CertificateType "token-signing"
   

   

2. Examinez les attributs du certificat.

   Si les attributs Subject et Issuer commencent par « CN=ADFS Signing... », le certificat est auto-signé et géré par AutoCertRollover.

Pour vérifier si les certificats sont renouvelés automatiquement, procédez comme suit :

1. Exécutez la commande suivante :

   Get-ADFSProperties | FL AutoCertificateRollover
   

   

2. Examinez l’attribut AutoCertificateRollover.

   • Si AutoCertificateRollover = TRUE, AD FS génère automatiquement de nouveaux certificats (30 jours avant l’expiration par défaut) et les définit comme certificats principaux (25 jours avant l’expiration).
   • Si AutoCertificateRollover = FALSE, vous devez remplacer manuellement les certificats.

Vérifier les composants et services associés à ADFS

Cet article explique comment case activée les composants et services liés à ADFS. Ces étapes peuvent vous aider lorsque vous résolvez les problèmes d’authentification (SSO) avec Services ADFS (ADFS).

Vérifier dns

L’accès à ADFS doit pointer directement vers l’un des serveurs WAP (Web Proxy d'application) ou l’équilibreur de charge devant les serveurs WAP. Effectuez les vérifications suivantes :

• Effectuez un test ping sur le nom du service de fédération (par exemple fs.contoso.com). Vérifiez si l’adresse IP vers laquelle le ping est résolu est de l’un des serveurs WAP ou de l’équilibreur de charge des serveurs WAP.
• Vérifiez s’il existe un enregistrement A pour le service de fédération sur le serveur DNS. L’enregistrement A doit pointer vers l’un des serveurs WAP ou vers l’équilibreur de charge des serveurs WAP.

Si waP n’est pas implémenté dans votre scénario pour l’accès externe, case activée si l’accès à ADFS pointe directement vers l’un des serveurs ADFS ou l’équilibreur de charge devant les serveurs ADFS :

• Effectuez un test ping sur le nom du service de fédération (par exemple fs.contoso.com). Vérifiez si l’adresse IP que vous obtenez est résolue en l’un des serveurs ADFS ou l’équilibreur de charge des serveurs ADFS.
• Vérifiez s’il existe un enregistrement A pour le service de fédération sur le serveur DNS. L’enregistrement A doit pointer vers l’un des serveurs ADFS ou vers l’équilibreur de charge des serveurs ADFS.

Vérifier l’équilibreur de charge s’il est utilisé

Vérifiez si le pare-feu bloque le trafic entre :

• Le serveur ADFS et l’équilibreur de charge.
• Le serveur WAP (Web Proxy d'application) et l’équilibreur de charge si WAP est utilisé.

Si la sonde est activée sur l’équilibreur de charge, case activée les éléments suivants :

• Si vous exécutez Windows Server 2012 R2, vérifiez que le correctif cumulatif d’août 2014 est installé.
• Vérifiez si le port 80 est activé dans le pare-feu sur les serveurs WAP et les serveurs ADFS.
• Vérifiez que la sonde est définie pour le port 80 et pour le point de terminaison /adfs/probe.

Vérifier les paramètres du pare-feu

Vérifiez si le trafic entrant via le port TCP 443 est activé sur :

• le pare-feu entre le serveur web Proxy d'application et la batterie de serveurs de fédération.
• le pare-feu entre les clients et le serveur web Proxy d'application.

Vérifiez si le trafic entrant via le port TCP 49443 est activé sur le pare-feu entre les clients et le serveur web Proxy d'application lorsque les conditions suivantes sont remplies :

• L’authentification du client TLS à l’aide d’un certificat X.509 est activée.
• Vous utilisez ADFS sur Windows Server 2012 R2.

Vérifier si le point de terminaison est activé sur le proxy

ADFS fournit différents points de terminaison pour différentes fonctionnalités et scénarios. Tous les points de terminaison ne sont pas activés par défaut. Pour case activée si le point de terminaison est activé sur le proxy, procédez comme suit :

1. Sur le serveur ADFS, ouvrez la console de gestion ADFS.

2. DéveloppezPoints de terminaison deservice>.

3. Recherchez le point de terminaison et vérifiez si le status est activé dans la colonne Proxy activé.

   

Vérifier la relation d’approbation de proxy

Si web Proxy d'application (WAP) est déployé, la relation d’approbation de proxy doit être établie entre le serveur WAP et le serveur AD FS. Vérifiez si la relation d’approbation de proxy est établie ou commence à échouer à un moment donné.

Informations contextuelles

La relation d’approbation de proxy est basée sur un certificat client. Lorsque vous exécutez l’Assistant post-installation web Proxy d'application, l’Assistant génère un certificat client auto-signé à l’aide des informations d’identification que vous avez spécifiées dans l’Assistant. Ensuite, l’Assistant insère le certificat dans la base de données de configuration AD FS et l’ajoute au magasin de certificats AdfsTrustedDevices sur le serveur AD FS.

Pour toute communication SSL, http.sys utilise l’ordre de priorité suivant pour que les liaisons de certificat SSL correspondent à un certificat :

Priorité	Nom	Paramètres	Description
1	IP	IP :port	Correspondance exacte entre l’adresse IP et le port
2	SNI	Nom d’hôte :port	Correspondance exacte du nom d’hôte (la connexion doit spécifier SNI)
3	CCS	Port	Appeler le magasin de certificats central
4	Caractère générique IPv6	Port	Correspondance de caractères génériques IPv6 (la connexion doit être IPv6)
5	Caractère générique IP	Port	Correspondance de caractères génériques IP (la connexion peut être IPv4 ou IPv6)

AD FS 2012 R2 et versions ultérieures sont indépendants d’Internet Information Services (IIS) et s’exécutent en tant que service par-dessus http.sys. les liaisons de certificat SSL hostname :port sont utilisées par AD FS. Lors de l’authentification par certificat client, AD FS envoie une liste d’approbation de certificats (CTL) basée sur les certificats dans le magasin AdfsTrustedDevices. Si une liaison de certificat SSL pour votre serveur AD FS utilise IP :port ou si le magasin CTL n’est pas AdfsTrustedDevices, la relation d’approbation de proxy peut ne pas être établie.

Obtenir les liaisons de certificat SSL pour AD FS

Sur le serveur AD FS, exécutez la commande suivante dans Windows PowerShell :
netsh http show sslcert

Dans la liste des liaisons retournées, recherchez celles dont l’ID d’application est 5d89a20c-beab-4389-9447-324788eb944a. Voici un exemple de liaison saine. Notez la ligne « Ctl Store Name ».

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Exécuter le script pour détecter automatiquement les problèmes

Pour détecter automatiquement les problèmes liés à la relation d’approbation de proxy, exécutez le script suivant. En fonction du problème détecté, effectuez l’action en conséquence.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problème 1 : Il existe une liaison spécifique à l’adresse IP

La liaison peut entrer en conflit avec la liaison de certificat AD FS sur le port 443.

La liaison IP :port est prioritaire. Si une liaison IP :port se trouve dans les liaisons de certificat SSL AD FS, http.sys utilise toujours le certificat pour la liaison pour la communication SSL. Pour résoudre ce problème, utilisez les méthodes suivantes.

1. Supprimer la liaison IP :port

   N’oubliez pas que la liaison IP :port peut revenir une fois que vous l’avez supprimée. Par exemple, une application configurée avec cette liaison IP :port peut la recréer automatiquement au prochain démarrage du service.

2. Utiliser une autre adresse IP pour la communication SSL AD FS

   Si la liaison IP :port est requise, résolvez le nom de domaine complet du service ADFS en une autre adresse IP qui n’est utilisée dans aucune liaison. De cette façon, http.sys utilisera la liaison Hostname :port pour la communication SSL.

3. Définir AdfsTrustedDevices en tant que magasin de listes de vie pour la liaison IP :port

   Il s’agit du dernier recours si vous ne pouvez pas utiliser les méthodes ci-dessus. Toutefois, il est préférable de comprendre les conditions suivantes avant de remplacer le magasin CTL par défaut par AdfsTrustedDevices :

   • Pourquoi la liaison IP :port est là.
   • Si la liaison s’appuie sur le magasin CTL par défaut pour l’authentification par certificat client.

Problème 2 : Le nom du magasin CTL n’est pas défini sur AdfsTrustedDevices pour la liaison de certificat AD FS

Si Microsoft Entra Connect est installé, utilisez Microsoft Entra Connect pour définir le nom du magasin CTL sur AdfsTrustedDevices pour les liaisons de certificat SSL sur tous les serveurs AD FS. Si Microsoft Entra Connect n’est pas installé, régénérez les liaisons de certificat AD FS en exécutant la commande suivante sur tous les serveurs AD FS.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problème 3 : Un certificat qui n’est pas auto-signé existe dans le magasin de certificats AdfsTrustedDevices

Si un certificat émis par l’autorité de certification se trouve dans un magasin de certificats où seuls les certificats auto-signés existent normalement, la CTL générée à partir du magasin contient uniquement le certificat émis par l’autorité de certification. Le magasin de certificats AdfsTrustedDevices est un magasin censé avoir uniquement des certificats auto-signés. Ces certificats sont les suivants :

• MS-Organization-Access : certificat auto-signé utilisé pour émettre des certificats de jointure à l’espace de travail.
• Approbation de proxy ADFS : certificats pour chaque serveur web Proxy d'application.

Par conséquent, supprimez tout certificat émis par l’autorité de certification du magasin de certificats AdfsTrustedDevices.

Problème 4 : Installer KB2964735 ou réexécuter le script avec -syncproxytrustcerts

Lorsqu’une relation d’approbation de proxy est établie avec un serveur AD FS, le certificat client est écrit dans la base de données de configuration AD FS et ajouté au magasin de certificats AdfsTrustedDevices sur le serveur AD FS. Pour un déploiement de batterie de serveurs AD FS, le certificat client doit être synchronisé avec les autres serveurs AD FS. Si la synchronisation n’a pas lieu pour une raison quelconque, une relation d’approbation proxy fonctionne uniquement sur le serveur AD FS avec lequel l’approbation a été établie, mais pas sur les autres serveurs AD FS.

Pour résoudre ce problème, utilisez l’une des méthodes suivantes.

Méthode 1

Installez la mise à jour documentée dans kb 2964735 sur tous les serveurs AD FS. Une fois la mise à jour installée, une synchronisation du certificat client est censée se produire automatiquement.

Méthode 2

Exécutez le script avec le commutateur – syncproxytrustcerts pour synchroniser manuellement les certificats clients de la base de données de configuration AD FS avec le magasin de certificats AdfsTrustedDevices. Le script doit être exécuté sur tous les serveurs AD FS de la batterie de serveurs.

Problème 5 : Toutes les vérifications sont réussies. Mais le problème persiste

Vérifiez s’il existe une incompatibilité d’heure ou de fuseau horaire. Si l’heure correspond, mais que le fuseau horaire n’est pas le même, la relation d’approbation de proxy ne peut pas non plus être établie.

Vérifier s’il existe une terminaison SSL entre le serveur AD FS et le serveur WAP

Si l’arrêt SSL se produit sur un périphérique réseau entre les serveurs AD FS et le serveur WAP, la communication entre AD FS et WAP est rompue, car la communication est basée sur le certificat client.

Désactivez l’arrêt SSL sur l’appareil réseau entre les serveurs AD FS et WAP.

Utiliser l’application Jeton de vidage

L’application Jeton de vidage est utile lors du débogage des problèmes liés à votre service de fédération, ainsi que lors de la validation des règles de revendication personnalisées. Il ne s’agit pas d’une solution officielle, mais d’une bonne solution de débogage indépendante qui est recommandée à des fins de résolution des problèmes.

Avant d’utiliser l’application Jeton de vidage

Avant d’utiliser l’application Jeton de vidage, vous devez :

1. Obtenez les informations de la partie de confiance pour l’application à laquelle vous souhaitez accéder. Si l’authentification OAuth est implémentée, obtenez également les informations du client OAuth.
2. Configurez l’application Jeton de vidage.

Obtenir les informations de la partie de confiance et du client OAuth

Si vous utilisez une partie de confiance conventionnelle, procédez comme suit :

1. Sur le serveur AD FS, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Ajoutez le composant AD FS 2.0 à Windows PowerShell en exécutant la commande suivante :

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. Obtenez les informations de la partie de confiance en exécutant la commande suivante :

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. Obtenez les informations du client OAuth en exécutant la commande suivante :

   $client = Get-AdfsClient ClientName
   

Si vous utilisez la fonctionnalité Groupe d’applications dans Windows Server 2016, suivez les étapes ci-dessous :

1. Sur le serveur AD FS, ouvrez Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Obtenez les informations de la partie de confiance en exécutant la commande suivante :

   $rp = Get-AdfsWebApiApplication ResourceID
   

3. Si le client OAuth est public, obtenez les informations client en exécutant la commande suivante :

   $client = Get-AdfsNativeClientApplication ClientName
   

   Si le client OAuth est confidentiel, obtenez les informations client en exécutant la commande suivante :

   $client = Get-AdfsServerApplication ClientName
   

Configurer l’application Jeton de vidage

Pour configurer l’application Jeton de vidage, exécutez les commandes suivantes dans la fenêtre Windows PowerShell :

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Passez maintenant aux méthodes de résolution des problèmes suivantes. À la fin de chaque méthode, vérifiez si le problème est résolu. Si ce n’est pas le cas, utilisez une autre méthode.

Méthodes de résolution des problèmes

Vérifiez la stratégie d’autorisation pour voir si l’utilisateur est impacté

Dans cette méthode, vous commencez par obtenir les détails de la stratégie, puis utilisez l’application Jeton de vidage pour diagnostiquer la stratégie et voir si l’utilisateur est impacté.

Obtenir les détails de la stratégie

$rp. IssuanceAuthorizationRules affiche les règles d’autorisation de la partie de confiance.

Dans Windows Server 2016 et versions ultérieures, vous pouvez utiliser $rp. AccessControlPolicyName pour configurer la stratégie d’authentification et d’autorisation. Si $rp. AccessControlPolicyName a une valeur, une stratégie de contrôle d’accès est en place qui régit la stratégie d’autorisation. Dans ce cas, $rp. IssuanceAuthorizationRules est vide. Utilisez $rp. ResultantPolicy pour obtenir des détails sur la stratégie de contrôle d’accès.

Si $rp. ResultantPolicy n’a pas les détails de la stratégie. Examinez les règles de revendication réelles. Pour obtenir les règles de revendication, procédez comme suit :

1. Définissez la stratégie de contrôle d’accès sur $null en exécutant la commande suivante :
   Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
2. Obtenez les informations de la partie de confiance en exécutant la commande suivante :
   $rp = Get-AdfsRelyingPartyTrust RPName
3. Vérifiez $rp.IssuanceAuthorizationRules et $rp. AdditionalAuthenticationRules.

Utiliser l’application Jeton de vidage pour diagnostiquer la stratégie d’autorisation

1. Définissez la stratégie d’authentification du jeton de vidage pour qu’elle soit identique à la partie de confiance défaillante.

2. Faites en sorte que l’utilisateur ouvre l’un des liens suivants en fonction de la stratégie d’authentification que vous définissez.

   • WS-Fed : https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P : https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Forcer l’authentification multifacteur : https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

3. Connectez-vous sur la page Sign-In.

Vous obtenez l’ensemble des revendications de l’utilisateur. Vérifiez s’il existe quelque chose dans la stratégie d’autorisation qui refuse explicitement ou autorise l’utilisateur en fonction de ces revendications.

Vérifier si une revendication manquante ou inattendue entraîne un refus d’accès à la ressource

1. Configurez les règles de revendication dans l’application Jeton de vidage pour qu’elles soient identiques aux règles de revendication de la partie de confiance défaillante.

2. Configurez la stratégie d’authentification du jeton de vidage pour qu’elle soit identique à la partie de confiance défaillante.

3. Faites en sorte que l’utilisateur ouvre l’un des liens suivants en fonction de la stratégie d’authentification que vous définissez.

   • WS-Fed : https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P : https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • Forcer l’authentification multifacteur : https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

4. Connectez-vous sur la page Sign-In.

Il s’agit de l’ensemble des revendications que la partie de confiance va obtenir pour l’utilisateur. Si des revendications sont manquantes ou inattendues, examinez la stratégie d’émission pour en connaître la raison.

Si toutes les revendications sont présentes, case activée avec le propriétaire de l’application pour voir quelle revendication est manquante ou inattendue.

Vérifier si l’état d’un appareil est requis

Si les règles d’autorisation case activée pour les revendications d’appareil, vérifiez si l’une de ces revendications d’appareil est manquante dans la liste des revendications que vous obtenez à partir de l’application Jeton de vidage. Les revendications manquantes peuvent bloquer l’authentification de l’appareil. Pour obtenir les revendications à partir de l’application Jeton de vidage, suivez les étapes décrites dans la section Utiliser l’application De jeton de vidage pour diagnostiquer la stratégie d’autorisation de la méthode Vérifier la stratégie d’autorisation si l’utilisateur a été affecté .

Voici les revendications de l’appareil. Les règles d’autorisation peuvent utiliser certaines d’entre elles.

• http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
• http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
• http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
• http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
• http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
• http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
• http://schemas.microsoft.com/2014/02/deviceusagetime
• http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
• http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

S’il manque une revendication, suivez les étapes décrites dans Configurer l’accès conditionnel local à l’aide d’appareils inscrits pour vous assurer que l’environnement est configuré pour l’authentification des appareils.

Si toutes les revendications sont présentes, vérifiez si les valeurs des revendications de l’application Jeton de vidage correspondent aux valeurs requises dans la stratégie d’autorisation.