Résoudre les problèmes DSO avec les services AD FS (Active Directory Federation Services)

Cet article vous aide à résoudre les problèmes d' signature unique (SSO) avec les services AD FS (Active Directory Federation Services).

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

S’applique à :   Numéro de la base de ko d’origine des services de fédération Active Directory   : 4034932

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

Lors de la résolution des problèmes d’authentification unique (SSO) avec les services AD FS (Active Directory Federation Services), si les utilisateurs ont reçu une invite d’authentification NTLM ou basée sur les formulaires inattendue, suivez les étapes de cet article pour résoudre ce problème.

Vérifier les Windows’authentification intégrée

Pour résoudre ce problème, vérifiez les paramètres Windows’authentification intégrée 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é, assurez-vous que le paramètre Activer l’authentification Windows intégrée est activé.
  • Après Security > Local intranet Sites Advanced , assurez-vous que > > l’URL AD FS figure dans la liste des sites web.
  • Après security > Local intranet > custom level, make sure that the Automatic logon only in Intranet Zone setting is selected.

Si vous utilisez Firefox, Chrome ou Safari, assurez-vous 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
    
  3. Examinez la valeur de l’attribut WindowsIntegratedFallbackEnbaled.

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 Windows’authentification intégrée. Consultez la section suivante sur la prise en charge de votre navigateur.

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

Vérifier le paramètre WIASupportedUsersAgents
  1. Obtenez la liste des agents utilisateurs pris en charge en exécutant la commande suivante :

    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  2. Examinez la liste des chaînes d’agent utilisateur que la commande renvoie.

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

  1. Go to http://useragentstring.com/ that detects and shows you the user agent string of your browser.

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

    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  3. Ajoutez la chaîne d’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érifier 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, vérifiez si la demande inclut wauth= urn:oasis:names:tc:SAML:1.0:am:password.
  2. Si la demande d’authentification est une demande SAML, vérifiez 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, voir Vue d’ensemble des handlersd’authentification des pages de signature AD FS.

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

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

Si l’application est Microsoft Online Services, ce que vous découvrez peut être contrôlé par le paramètre PromptLoginBehavior à partir de l’objet de domaine approuvé. Ce paramètre contrôle si les Azure AD envoient prompt=login à AD FS. Pour définir le paramètre PromptLoginBehavior, suivez les étapes suivantes :

  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 suivants :

    1. TranslateToFreshPasswordAuth: Azure AD envoie wauth et wfresh à AD FS au lieu de prompt=login. Cela entraîne une demande d’authentification pour utiliser l’authentification basée sur les formulaires.
    2. NativeSupport: le paramètre prompt=login est envoyé tel quelle aux AD FS.
    3. Désactivé : rien n’est envoyé aux AD FS.

Pour en savoir plus sur la commande Set-MSOLDomainFederationSettings, consultez la prise en charge des paramètres prompt=login des services de fédération Active Directory.

Azure Active Directory (Azure AD)

Si la demande d’authentification envoyée Azure AD inclure 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’incluront pas le paramètre prompt=login dans chaque demande d’authentification.

Scénario non Azure AD

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

Vérifier si l’activation de l’activation de l’activation de l’activation est désactivée

Si l’activation de l' utilisateur 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, vérifiez 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, vérifiez 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 :

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

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

  1. Pour vérifier la configuration sur le serveur AD FS, exécutez la commande suivante dans Windows PowerShell fenêtre.

    Get-ADFSAdditionalAuthenticationRule
    

    Pour vérifier la configuration sur la partie de confiance, exécutez la commande suivante :

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    Notes

    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 se compose des sections suivantes :

  • L’instruction de condition : C:[Type=``…,Value=…]
  • L’instruction issue : => 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 à un 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 la partie répondante ne passe pas par les revendications d’authentification multifacteur à l’application. Pour vérifier si les revendications d’authentification sont transmises, suivez les étapes suivantes :

  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 WS-Federation, vérifiez si la demande inclut wauth= http://schemas.microsoft.com/claims/multipleauthn .
  • Si la demande d’authentification est une demande SAML, vérifiez si la demande inclut un élément samlp:AuthnContextClassRef avec valeur http://schemas.microsoft.com/claims/multipleauthn .

Pour plus d’informations, voir Vue d’ensemble des handlersd’authentification des pages de signature AD FS.

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

Si l’application à accéder est Microsoft Online Services pour Office 365, vérifiez 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 est FALSE, définissez-le sur TRUE en exécutant la commande suivante :

    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
    

Vérifier si l’activation de l’activation de l’activation de l’activation est désactivée

Si l’activation de l' utilisateur 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

This issue can occur at the AD FS sign-in page or at the application side.

Si le problème se produit sur la page de signature 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 tel que fs.contoso.com .

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.

This issue occurs at the AD FS sign-in page

Pour résoudre ce problème, vérifiez si tous les utilisateurs sont touchés par le problème et s’ils peuvent accéder à toutes les parties de confiance.

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

Nous allons vérifier la fonctionnalité de la signature interne à l’aide de IdpInitiatedSignOn. Pour ce faire, utilisez la page IdpInititatedSignOn pour vérifier si le service AD FS est opérationnel et si la fonctionnalité d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, suivez les étapes suivantes :

  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 connectez-vous est réussie

Si la signature réussit, vérifiez si l’état du service AD FS est en cours d’exécution.

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

Ensuite, vérifiez la fonctionnalité de connectez-vous 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, suivez les étapes suivantes :

  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 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, voir Vérifier les services et composants associés à AD FS et vérifier la relation d’confiance du proxy.

Si la signature réussit, poursuivez la résolution des problèmes en accédant aux étapes de Tous les utilisateurs qui sont touchés par le problème, et l’utilisateur peut accéder à certaines des parties de confiance.

La connectez-vous échoue

Si la connectez-vous échoue, vérifiez les services et composants associés aux services AD FS.

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

  1. Sur le serveur AD FS, ouvrez le Gestionnaire de serveur.
  2. Dans le Gestionnaire de serveur, cliquez sur > Outils Services.
  3. Vérifiez si l’état des services de fédération Active Directory 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érents scénarios et fonctionnalités. Tous les points de terminaison ne sont pas activés par défaut. Pour vérifier l’état des points de terminaison, consultez les étapes suivantes :

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

  2. Développez les > points de terminaison de service.

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

    Vérifiez l’état de tous les points de terminaison A D F S activés.

Ensuite, vérifiez si Azure AD Connecter est installé. Nous vous recommandons d’utiliser Azure AD Connecter ce qui facilite la gestion des certificats SSL.

Si Azure AD Connecter est installé, veillez à l’utiliser pour gérer et mettre à jour les certificats SSL.

Si Azure AD Connecter n’est pas installé, vérifiez si le certificat SSL répond aux exigences AD FS suivantes :

  • Le certificat est issu d’une autorité de certification racine de confiance.

    AD FS exige que les certificats SSL soient issus d’une autorité de certification racine de confiance. Si les services AD FS sont accessibles à partir d’ordinateurs non joints à un domaine, nous vous recommandons d’utiliser un certificat SSL à partir d’une autorité de certification racine tierce de confiance comme DigiCert, VeriSign, etc. Si le certificat SSL ne fait pas partie d’une autorité de certification racine de confiance, la communication SSL peut se rompre.

  • Nom du sujet du certificat 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 des certificats. Si le certificat est révoqué, la connexion SSL ne peut pas être sécurisée et sera 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 Azure AD Connecter ce qui facilite la gestion des certificats SSL. Voir Mettre à jour le certificat TLS/SSL pour une batterie de serveurs AD FS (Active Directory Federation Services).

Si le certificat SSL répond à ces exigences, vérifiez 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 pour 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’endroit correct, suivez les étapes suivantes :

  1. List the certificates that are in the Personal store for the local computer by running the following command:
    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 de 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 utilisé est erroné, définissez le certificat correct en exécutant la commande suivante :

Set-AdfsSslCertificate –Thumbprint CorrectThumprint
Vérifier si le certificat SSL est le certificat de communication de service

Le certificat SSL doit être définie en tant que certificat de communication de service dans votre batterie de serveurs AD FS. Cela ne se produit pas automatiquement. Pour vérifier si le certificat correct est bien installé, suivez les étapes suivantes :

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

Si le certificat n’est pas répertorié, définissez le certificat correct, puis accordez au service AD FS l’autorisation 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 correct.
  2. Vérifiez si le service AD FS dispose de l’autorisation lecture sur le certificat :

    1. Ajoutez le logiciel en ligne 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, cliquez sur Toutes les tâches Gérer les clés > privées.
    4. Vérifiez si adfssrv est répertorié sous Les noms de groupes et d’utilisateurs 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 des 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 des appareils (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 RDS. Par exemple, s’il existe deux suffixes UPN et , le certificat doit avoir et comme autres noms du contoso.com fabrikam.com sujet enterpriseregistration.contoso.com enterpriseregistration.fabrikma.com (SAN).

Pour vérifier si le certificat SSL dispose des SNS corrects, suivez les étapes suivantes :

  1. List all the UPN suffixes being used in the organization by running the following command:

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. Vérifiez si les SNS requis sont configurés pour le certificat SSL.

  3. Si le certificat SSL ne possède pas les noms DRS corrects en tant que nom d’enregistrement sans, obtenez un nouveau certificat SSL qui dispose des noms de service d’aide à la décision corrects pour DRS, puis utilisez-le comme certificat SSL pour AD FS.

Ensuite, vérifiez la configuration du certificat sur les serveurs WAP et les liaisons de base :

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

    1. Assurez-vous que le certificat SSL est installé dans le magasin personnel pour 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 faux, 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 retour. Autre que la liaison federationservicename:443 standard, recherchez les liaisons de retour sous les ID d’application suivants :

    • {5d89a20c-beab-4389-9447-324788eb944a : il s’agit de l’ID d’application pour } AD FS.
    • {f955c070-e044-456c-ac00-e9e4275b3f04 : il s’agit de l’ID d’application pour le } proxy d’application web.

    Par exemple, si le certificat SSL est spécifié pour une liaison de retour 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 touché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, suivez les étapes suivantes :

  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
    

À présent, poursuivez avec les méthodes de dépannage suivantes.

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

L’identificateur de 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 différence entre ce que le propriétaire fournit et ce qui est configuré dans AD FS. Par exemple, une insérialisation 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 obtiennent les paramètres configurés dans AD FS via PowerShell.

Paramètres fournies par le propriétaire Paramètres configuré dans AD FS
ID de partie de confiance $rp. Identificateur
URI de redirection de partie de confiance Un préfixe ou une correspondance générique de
  • $rp. WSFedEndpoint pour une WS-Fed de confiance
  • $rp. SamlEndpoints pour une partie de confiance SAML
ID du client $client. ClientId
URI de redirection du client Correspondance de préfixe $client. RedirectUri

Si les éléments du tableau correspondent, vérifiez également si ces paramètres correspondent à ce qu’ils apparaissent dans la demande d’authentification envoyée aux services AD FS et à ce qui est configuré dans AD FS. Essayez de reproduire le problème au cours duquel vous capturez un suivi Fiddler sur la demande d’authentification envoyée par l’application aux AD FS. Examinez les paramètres de demande pour faire les vérifications suivantes en fonction du type de requête.

Requêtes OAuth

Une requête OAuth ressemble à ce qui 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 demande correspondent aux paramètres configurés dans AD FS.

Paramètres de la requête Paramètres configuré dans AD FS
client_id $client. ClientId
redirect_uri Une 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 ressemble à ce qui 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 demande correspondent aux paramètres configurés dans AD FS :

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

Une requête SAML ressemble à ce qui 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 « DeflatedSAML » dans l’Assistant Texte fiddler. La valeur décodée ressemble à ce qui 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>

Faites 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 $rp.Identifier correspond.

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 des messages. Toutes ces URL peuvent être configurées dans AD FS.
  • $rp. SignedSamlRequestsRequired : si la valeur est définie, la demande SAML envoyée par la partie de confiance doit être signée. Les paramètres « SigAlg » et « Signature » doivent être présents dans la demande.
  • $rp. RequestSigningCertificate : il s’agit du certificat de signature utilisé pour générer la signature sur la demande SAML. Assurez-vous que le certificat est valide et demandez au propriétaire de l’application de le faire correspondre.
Vérifier le certificat de chiffrement

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

  • $rp. EncryptionCertificate : utilisez cette commande pour obtenir le certificat et vérifier s’il est valide.
  • $rp. EncryptionCertificateRevocationCheck : utilisez cette commande pour vérifier si le certificat répond aux exigences de vérification de révocation.
Les deux méthodes précédentes ne fonctionnent pas

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

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

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

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

Vérifiez l’état de l’Windows PowerShell l’interface utilisateur. Si l’utilisateur est désactivé, activez-le.

Vérifiez l’état de l’utilisateur avec Windows PowerShell
  1. Connectez-vous à l’un des contrôleurs de domaine.

  2. Ouvrez Windows PowerShell.

  3. Vérifiez l’état de l’utilisateur en exécutant la commande suivante :

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

    Utilisez la Get-ADUser pour vérifier l’état activé de l’utilisateur.

Vérifier l’état de l’utilisateur dans l’interface utilisateur
  1. Connectez-vous à l’un des contrôleurs de domaine.

  2. Ouvrez la 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 le compte est désactivé.

    Vérifiez si l’option Compte est désactivée.

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

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

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 reprises par les services associés. Pour vérifier si des modifications de propriété ont été apportées à un utilisateur, consultez les étapes suivantes :

  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"

    Un exemple de commande est :
    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 tout indice de modification. Dans l’exemple suivant, l’attribut userPrincipleName prend une date plus nouvelle que les autres attributs qui représente une modification des métadonnées de l’objet utilisateur.

    Sortie de la commande repadmin showobjmeta.

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

Dans un environnement AD FS à forêts multiples, une confiance de forêt double 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’relation d’confiance entre les forêts fonctionne comme prévu, suivez les étapes suivantes :

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

  2. Ouvrez la console de gestion Des domaines et des trusts Active Directory.

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

  4. Cliquez sur l’onglet Trusts.

  5. Sous Domaines fiables par ce domaine (trusts sortantes) ou Domaines qui font confiance à ce domaine (trusts entrantes), cliquez sur l’trust à 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.

      Validez l’confiance entrante dans la boîte de dialogue Services de domaine Active Directory.

Si ces étapes ne vous ont pas permis de résoudre le problème, poursuivez la résolution des problèmes avec les étapes de la section Not all users are impacted by the issue, et l’utilisateur peut accéder à certaines des parties de confiance.

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

Dans ce scénario, vérifiez si ce problème se produit dans un Azure AD scénario. Si tel est le cas, faites ces vérifications pour résoudre ce problème. Si ce n’est pas le cas, voir Utiliser l’application jeton de vidage pour résoudre ce problème.

Vérifiez si l’utilisateur est synchronisé avec Azure AD

Si un utilisateur tente de se connecter à Azure AD, 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 Azure AD. Vous pouvez voir une boucle de Azure AD vers AD FS après la première tentative d’authentification auprès d’AD FS. Pour déterminer si l’utilisateur est synchronisé avec Azure AD, suivez les étapes suivantes :

  1. Téléchargez et installez Azure AD module PowerShell pour Windows PowerShell.
  2. Ouvrez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».
  3. Lancez une connexion à Azure AD 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 Azure AD 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 Azure AD.

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

Azure AD nécessite immuableID et l’UPN de l’utilisateur pour authentifier l’utilisateur.

Notes

ImmutableID est également appelé sourceAnchor dans les outils suivants :

  • Azure AD Sync
  • Azure Active Directory Sync (DirSync)

Les administrateurs peuvent utiliser Azure AD Connecter gestion automatique de l’confiance AD FS avec Azure AD. Si vous ne gérez pas l’confiance via Azure AD Connecter, nous vous recommandons de le faire en téléchargeant Azure AD Connecter Azure AD Connecter permet la gestion automatique des règles de revendication en fonction des paramètres de synchronisation.

Pour vérifier si les règles de revendication pour immutableID et UPN dans AD FS correspond à ce que Azure AD utilise, suivez les étapes suivantes :

  1. Obtenez sourceAnchor et UPN dans Azure AD Connecter.

    1. Ouvrez Azure AD Connecter.

    2. Cliquez sur Afficher la configuration actuelle.

      Sélectionnez l’affichage de la configuration actuelle dans Azure A D Connecter page de tâches supplémentaires.

    3. Dans la page Examiner votre solution, notez les valeurs d’ANCRAGE SOURCE et DE NOM D’UTILISATEUR PRINCIPAL.

      Obtenez les valeurs d’ANCRE SOURCE et DE NOM D’UTILISATEUR PRINCIPAL dans la page Azure A D Connecter.

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

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

    2. Cliquez sur Trusts de partie de confiance.

    3. Cliquez avec le bouton droit sur l’Azure AD de confiance, puis cliquez sur Modifier la stratégie d’émission de revendications.

    4. Ouvrez la règle de revendication pour un ID et un UPN non permutables.

    5. Vérifiez si les variables interrogés pour les valeurs immutableID et UPN sont identiques à celles qui apparaissent dans Azure AD Connecter.

      Vérifiez les valeurs d’ID immuable et d’UPN dans la règle de revendication correspondante configurée sur le serveur A D F S.

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

    • Si AD FS est géré par un Azure AD Connecter, réinitialisez l’confiance de la partie de confiance à l’aide Azure AD Connecter.
    • Si AD FS n’est pas géré Azure AD Connecter, corrigez les revendications avec les attributs corrects.

Si ces vérifications ne vous ont pas permis de résoudre le problème, consultez 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 jetons a été renouvelé récemment par AD FS, vérifiez si le nouveau certificat a été choisi par le partenaire de fédération. Dans le cas où AD FS utilise un certificat de déchiffrement de jeton qui a également été renouvelé récemment, faites également la même vérification. Pour vérifier si le certificat de signature de jetons AD FS actuel sur AD FS correspond à celui du partenaire de fédération, suivez les étapes suivantes :

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

    Get-ADFSCertificate -CertificateType token-signing
    
  2. Dans la liste des certificats renvoyés, recherchez celui avec IsPrimary = TRUE et notez l’empreinte numérique.

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

  4. Comparez les empreintes numériques des deux certificats.

Faites la même vérification si AD FS utilise un certificat de déchiffrement de jeton renouvelé, sauf que la commande pour obtenir le certificat de déchiffrement du jeton sur AD FS est la suivante :

Get-ADFSCertificate -CertificateType token-decrypting

Les empreintes des deux certificats correspondent

Si les empreintes numériques correspondent, assurez-vous que les partenaires utilisent les nouveaux certificats AD FS.

S’il existe des non-règles de certificat, assurez-vous 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.

Notes

Les partenaires font référence à tous vos partenaires d’organisation de ressources ou d’organisation de comptes, représentés dans vos services AD FS par des trusts de partie de confiance et des demandes d’accès au fournisseur de revendications.

  • 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 aux partenaires 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 en tant que fichiers .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, vérifiez s’il existe une insérialisation de l’algorithme de signature de jetons. 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, vérifiez si le format de l’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 émettra 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 qu’elle utilise le format nécessaire à l’application. Pour cela, procédez comme suit :

    1. Ouvrez la console de gestion AD FS.
    2. Cliquez sur Trusts 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 mettre à jour une règle existante. Sélectionnez l’ID de nom pour le type de revendication entrante, puis spécifiez le format nécessaire à l’application.

    Ajoutez une règle de revendication de transformation s’il n’existe aucune règle pour émettre la revendication NameIdentifier ou mettre à jour une règle existante.

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

  1. Ouvrez la console de gestion AD FS.

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

  3. Sous l’onglet Avancé, sélectionnez l’algorithme pour qu’il corresponde à ce dont l’application a besoin.

    Sélectionnez l’algorithme pour qu’il corresponde à ce dont l’application a besoin sous l’onglet Avancé dans la boîte de dialogue Paramètres des propriétés.

À propos du renouvellement automatique du certificat

Si le certificat de signature de jetons ou le certificat de déchiffrement du 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 sont proches de leur expiration.

Pour déterminer si vous utilisez des certificats auto-signés, suivez les étapes suivantes :

  1. Exécutez la commande suivante :

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Exécutez la cmdlet Get-ADFSCerticate, signature de jetons de type certificat.

  2. Examinez les attributs du certificat.

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

Pour vérifier si les certificats sont renouvelés automatiquement, suivez les étapes suivantes :

  1. Exécutez la commande suivante :

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Exécutez lGet-ADFSProperties cmdlet pour vérifier si les certificats sont renouvelés automatiquement.

  2. Examinez l’attribut AutoCertificateRollover.

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

Cet article explique comment vérifier les composants et services liés aux services ADFS. Ces étapes peuvent vous aider lorsque vous dépannagez des problèmes d' sign-on (SSO) avec les services ADFS (Active Directory Federation Services).

Vérifier le DNS

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

  • Ping sur le nom du service de fédération (par exemple, fs.contoso.com ). Confirmez si l’adresse IP sur la résolution ping est de l’un des serveurs WAP ou du programme d’équilibrage 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 le point d’accès sans fil n’est pas implémenté dans votre scénario pour l’accès externe, vérifiez si l’accès à ADFS pointe directement vers l’un des serveurs ADFS ou l’équilibreur de charge devant les serveurs ADFS :

  • Ping sur le nom du service de fédération (par exemple, fs.contoso.com ). Confirmez si l’adresse IP que vous obtenez est résolue vers 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’équilibrage 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 Application Proxy) et l’équilibrage de charge si ce dernier est utilisé.

Si la sonde est activée sur l’équilibrage de charge, vérifiez ce qui suit :

  • Si vous exécutez Windows Server 2012 R2, assurez-vous que le déploiement de mise à jour 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.
  • Assurez-vous que la sonde est définie pour le port 80 et pour le point de terminaison /adfs/sonde.

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 proxy d’application web et la batterie de serveurs de fédération;
  • le pare-feu entre les clients et le serveur proxy d’application web;

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

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

Notes

La configuration n’est pas requise sur le pare-feu entre le serveur proxy d’application web et les serveurs de fédération.

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

ADFS fournit différents points de terminaison pour différents scénarios et fonctionnalités. Tous les points de terminaison ne sont pas activés par défaut. Pour vérifier si le point de terminaison est activé sur le proxy, consultez les étapes suivantes :

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

  2. Développez les > points de terminaison de service.

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

    Vérifiez l’état des points de terminaison A D F S affichés dans la colonne Proxy activé.

Vérifier la relation d’confiance de proxy

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

Notes

Les informations de cette page s’appliquent à AD FS 2012 R2 et aux ultérieures.

Informations contextuelles

La relation d’confiance de proxy est basée sur un certificat client. Lorsque vous exécutez l’Assistant post-installation du proxy d’application web, celui-ci génère un certificat client auto-signé à l’aide des informations d’identification que vous avez spécifiées dans l’Assistant. L’Assistant insère ensuite 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 Hostname:port Correspondance exacte du nom d’hôte (la connexion doit spécifier SNI)
3 CCS Port Appeler le magasin central de certificats
4 Caractère générique IPv6 Port Correspondance générique 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 les ultérieures sont indépendants de Internet Information Services (IIS) et s’exécutent en tant que service sur http.sys. Les liaisons de certificats SSL hostname:port sont utilisées par AD FS. Pendant l’authentification de certificat client, AD FS envoie une liste de certificats de confiance (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, il se peut que la relation d’confiance du proxy ne soit pas é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 renvoyé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 un script pour détecter automatiquement les problèmes

Pour détecter automatiquement les problèmes liés à la relation d’confiance de proxy, exécutez le script suivant. En fonction du problème détecté, prenez 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 IP spécifique

La liaison peut être 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 certificatS 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’ignorez pas que la liaison IP:port peut revenir après sa suppression. Par exemple, une application configurée avec cette liaison IP:port peut la recréer automatiquement lors de la prochaine 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 FQDN du service ADFS en une autre adresse IP qui n’est utilisée dans aucune liaison. Ainsi, http.sys utilisera la liaison Hostname:port pour la communication SSL.

  3. Définir AdfsTrustedDevices comme magasin CTL pour la liaison IP:port

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

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

Problème 2 : la liaison de certificat AD FS n’a pas le nom de magasin CTL a la valeur AdfsTrustedDevices

Si Azure AD Connecter est installé, utilisez AAD Connecter pour définir le nom du magasin CTL sur AdfsTrustedDevices pour les liaisons de certificat SSL sur tous les serveurs AD FS. Si Azure AD Connecter n’est pas installé, régénérez les liaisons de certificatS 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 une ca 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’ac. Le magasin de certificats AdfsTrustedDevices est un tel magasin supposé n’avoir que des certificats auto-signés. Ces certificats sont :

  • MS-Organization-Access : certificat auto-signé utilisé pour émettre des certificats de jointeurs de lieu de travail.
  • Confiance de proxy ADFS : certificats pour chaque serveur proxy d’application web.

Certificats pour chaque serveur proxy d’application web.

Par conséquent, supprimez tout certificat émis par une ca du magasin de certificats AdfsTrustedDevices.

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

Lorsqu’une relation d’confiance 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 est censé être synchronisé avec les autres serveurs AD FS. Si la synchronisation ne se produit pas pour une raison quelconque, une relation d’confiance de proxy ne fonctionne que sur le serveur AD FS avec qui l’trust 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 la 2964735 KB sur tous les serveurs AD FS. Une fois la mise à jour installée, une synchronisation du certificat client est prévue pour 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 vers le magasin de certificats AdfsTrustedDevices. Le script doit être exécuté sur tous les serveurs AD FS de la batterie de serveurs.

Notes

Il ne s’agit pas d’une solution permanente, car les certificats clients seront renouvelés régulièrement.

Problème 5 : toutes les vérifications sont passées. Mais le problème persiste

Vérifiez s’il existe une insérialisation de fuseau horaire ou de fuseau horaire. Si l’heure correspond, mais pas le fuseau horaire, la relation d’confiance du proxy ne pourra pas être établie.

Vérifier s’il existe un arrêt SSL entre le serveur AD FS et le serveur WAP

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

Désactivez l’arrêt de 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 de problèmes avec votre service de fédération et 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 recommandée à des fins de dépannage.

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 à accéder. Si l’authentification OAuth est implémentée, obtenez également les informations du client OAuth.
  2. Configurer l’application jeton de vidage.

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

Si vous utilisez une partie de confiance conventionnelle, suivez les étapes suivantes :

  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 Windows PowerShell suivante :

$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

À présent, poursuivez avec les méthodes de dépannage suivantes. À la fin de chaque méthode, voir si le problème est résolu. Si ce n’est pas le cas, utilisez une autre méthode.

Méthodes de dépannage

Vérifier la stratégie d’autorisation pour voir si l’utilisateur est touché

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 afin de voir si l’utilisateur est touché.

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 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 en savoir plus sur la stratégie de contrôle d’accès.

Si $rp. ResultantPolicy n’a pas les détails de la stratégie, recherchez les règles de revendication réelles. Pour obtenir les règles de revendication, suivez les étapes suivantes :

  1. Définissez la stratégie de contrôle d'$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érifier $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 sur la même que la partie de confiance défaillante.

  2. L’utilisateur doit ouvrir l’un des liens suivants en fonction de la stratégie d’authentification que vous avez définie.

    • WS-Fed : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P : https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forcer l’authentification multifacteur : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Connectez-vous sur la Sign-In page.

Vous obtenez l’ensemble des revendications de l’utilisateur. Voir si la stratégie d’autorisation refuse ou autorise explicitement 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 de manière à ce qu’elle soit identique à la partie de confiance défaillante.

  3. L’utilisateur doit ouvrir l’un des liens suivants en fonction de la stratégie d’authentification que vous avez définie.

    • WS-Fed : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P : https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forcer l’authentification multifacteur : https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Connectez-vous sur la Sign-In page.

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, recherchez la stratégie d’émission pour en connaître la raison.

Si toutes les revendications sont présentes, vérifiez auprès du propriétaire de l’application quelle revendication est manquante ou inattendue.

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

Si les règles d’autorisation vérifient 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 de l’application Utiliser le jeton de vidage pour diagnostiquer la section stratégie d’autorisation dans la stratégie de vérification de l’autorisation si l’utilisateur a été touché.

Voici les revendications d’appareil. Les règles d’autorisation peuvent en utiliser certaines.

  • 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 de la procédure de configuration de l’accès conditionnel local à l’aide d’appareils enregistrés pour vous assurer que l’environnement est configuré pour l’authentification des appareils.

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