Unique sign-on (SSO) résoudre les problèmes liés aux Services de fédération Active Directory (Active Directory Federation Services)

Poursuivez le dépannage pour vérifier les problèmes potentiels avec la partie de confiance.

Continuer avec des contrôles supplémentaires sur la partie de confiance.

Poursuivez le dépannage pour vérifier le certificat SSL.

Poursuivez le dépannage pour vérifier la relation d’approbation proxy entre un Proxy d’Application Web et AD FS.

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

Le problème rencontré par l’utilisateur avec l’authentification unique ?

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

Si le problème se produit à la page de connexion AD FS, vous recevez un « une erreur s’est produite », « HTTP 503 Service non disponible » ou un autre message d’erreur. L’URL de la page d’erreur affiche le nom du service AD FS par exemple fs.contoso.com.

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

Lorsque vous rencontrez ce problème ?

Ce problème influe sur les tous les utilisateurs ?

L’utilisateur peut accéder à toutes les parties de confiance ?

Ce problème se produit en cas d’Azure AD ?

L’utilisateur peut accéder à toutes les parties de confiance ?

Si le certificat de signature de jeton a été récemment renouvelé par ADFS, vérifiez si le nouveau certificat est capté par le partenaire de la fédération. AD FS utilise un jeton de décrypter le certificat qui a également été renouvelée récemment, le même vérifier également. Pour vérifier si le jeton AD FS en cours sur AD FS le certificat de signature correspond à celle du partenaire de fédération, procédez comme suit :

  1. Obtenir le jeton en cours de signature de certificat sur AD FS en exécutant la commande suivante :
    Get-ADFSCertificate -CertificateType token-signing

  2. Dans la liste des certificats retournée, recherchez celui avec IsPrimary = TRUEet prenez note de l’empreinte numérique.

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

  4. Comparer les empreintes des deux certificats .

Effectuez la même vérification si AD FS utilise un jeton renouvelé décryptage du certificat, sauf que la commande pour obtenir le jeton de certificat sur AD FS de décryptage est la suivante :
Get-ADFSCertificate -CertificateType token-decrypting

Si le jeton jeton ou du certificat de décryptage certificat de signature est 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 autosignés, procédez comme suit :

  1. Exécutez la commande suivante :
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. Examinez les attributs de certificat.
    Si les attributs objet et émetteur commencent par « CN = signature d’ADFS... », le certificat est autosigné et géré par AutoCertRollover.

Pour vérifier si les certificats renouvellent automatiquement, procédez comme suit :

  1. Exécutez la commande suivante :
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. Examinez l’attribut AutoCertificateRollover.

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

    • Si AutoCertificateRollover = FALSE, vous devez manuellement remplacer les certificats.

Les empreintes correspondent ?

Pour vérifier s’il existe une incompatibilité, procédez comme suit :

  1. Déterminer l’algorithme utilisé par la partie utilisatrice en exécutant la commande suivante : Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    Les valeurs possibles sont SHA1 ou SHA256 .

  2. Vérifier avec le propriétaire de l’application de l’algorithme utilisé sur le côté de l’application.

  3. Vérifiez si les deux algorithmes correspondent.

Existe-t-il une différence ?

L’utilisateur peut-il accéder une invite NTLM inattendue ou une invite de commandes de l’authentification basée sur les formulaires ?

L’utilisateur peut-il accéder une invite inattendue pour une authentification multifactorielle ? Ou l’utilisateur à plusieurs reprises obtient-il l’invite ?

Ce problème se produit en cas d’Azure AD ?

La demande d’authentification envoyée à Active Directory Azure inclut le paramètre de connexion = invite?

Paramètres de la demande tels que WAUTH et RequestedAuthNContext dans les demandes d’authentification peuvent avoir des méthodes d’authentification spécifiés. Le paramètre de requête est mise en œuvre l’invite d’authentification ?

Utilisez les méthodes suivantes pour le dépannage.

Vérifiez l’état de l’utilisateur dans Windows PowerShell ou l’interface utilisateur. Si l’utilisateur est désactivé, permettre à l’utilisateur.

Vérifier l’état de l’utilisateur avec Windows PowerShell

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

  2. Ouvrez Windows PowerShell.

  3. Vérifier l’état de l’utilisateur en exécutant la commande suivante :
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Vérifiez l’état de l’utilisateur dans l’interface utilisateur

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

  2. Ouvrez la console de gestion des ordinateurs et utilisateurs Active Directory .

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

  4. Cliquez sur l’onglet compte .

  5. Sous options de compte, vérifiez si le compte est désactivé .
    The "Account is disabled" option under Account options

  6. Si l’option est activée, désactivez-la.

Est-ce que le problème est résolu ?

Si n’importe quelle propriété de l’utilisateur est mis à jour dans Active Directory, il entraîne un changement dans les métadonnées de l’objet utilisateur. Vérifiez l’objet de métadonnées utilisateur pour voir les propriétés qui ont été récemment mis à jour. Si les modifications sont trouvées, assurez-vous qu’ils sont récupérés par des services associés. Pour vérifier si il existait des modifications de propriété à un utilisateur, procédez comme suit :

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

  2. Ouvrez Windows PowerShell.

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

    Un exemple de la commande est :
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. Dans les métadonnées, examinez la colonne Date/heure pour chaque attribut d’aucune indication quant à une modification. Dans l’exemple suivant, l’attribut userPrincipleName accepte une date plus récente que les autres attributs qui représente un changement dans les métadonnées de l’objet utilisateur.
    repadmin show user metadata

Est-ce que le problème est résolu ?

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

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

  2. Console de gestion d’Ouvrir répertoire de domaines et approbations Active .

  3. Dans la console de gestion, cliquez 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 une des options.

    • Si vous sélectionnez non, nous recommandons que vous répétez la même procédure pour le domaine réciproque.

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

Active Directory Domain Services

  • Est-ce que le problème est résolu ?

L’application de vidage du jeton est utile lorsque les règles de revendication du débogage des problèmes avec votre service de fédération, ainsi que la validation personnalisée. Il n’est pas une bonne solution de débogage indépendante qui est recommandée pour les besoins de dépannage, mais une solution officielle.

Avant d’utiliser l’application vider le jeton, vous devez :

  1. Obtenir les informations de la partie de confiance de l’application que vous souhaitez accéder. Si l’authentification OAuth est implémentée, obtenir les informations du client OAuth.

  2. Permet de paramétrer l’application Dump du jeton.

Obtenir la partie de confiance et des informations de client OAuth

Si vous utilisez une partie utilisatrice classique, procédez comme suit :

  1. Sur le serveur ADFS, ouvrir Windows PowerShell avec l’option Exécuter en tant qu’administrateur .

  2. Ajouter l’AD FS 2.0 composant Windows PowerShell en exécutant la commande suivante :
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Obtenir les informations de partie utilisatrice en exécutant la commande suivante :
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Obtenir les informations de client OAuth en exécutant la commande suivante :
    $client = Get-AdfsClient ClientName

Si vous utilisez la fonctionnalité de groupe de l’Application dans Windows Server 2016, suivez les étapes ci-dessous :

  1. Sur le serveur ADFS, ouvrir Windows PowerShell avec l’option Exécuter en tant qu’administrateur .

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

  3. Si le client OAuth est public, le client de lire les informations en exécutant la commande suivante :
    $client = Get-AdfsNativeClientApplication ClientName

    Si le client OAuth est confidentiels, obtenir le client des informations en exécutant la commande suivante :
    $client = Get-AdfsServerApplication ClientName

Configurer l’application Dump du jeton

Pour configurer l’application Dump jeton, 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

Maintenant poursuivre 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.

Dans cette méthode, vous démarrez en obtenant le Détails de la stratégie et puis utiliser l’application Dump jeton à diagnostiquer la stratégie pour voir si l’utilisateur est affecté.

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 les versions ultérieures, vous pouvez utiliser $rp. AccessControlPolicyName pour configurer une stratégie d’authentification et d’autorisation. Si $rp. AccessControlPolicyName a la 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 plus d’informations sur la stratégie de contrôle d’accès.

Si $rp. ResultantPolicy n’ont les plus d’informations sur la stratégie, examiner les règles de déclaration à proprement parler. Pour obtenir les règles de revendication, procédez comme suit :

  1. Définir la stratégie de contrôle d’accès sur $null en exécutant la commande suivante :
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null

  2. Obtenir les informations de partie utilisatrice en exécutant la commande suivante :
    $rp = Get-AdfsRelyingPartyTrust RPName

  3. Check $rp.IssuanceAuthorizationRuleset$rp. AdditionalAuthenticationRules.

Utilisez l’application Dump jeton pour diagnostiquer la stratégie d’autorisation

  1. Définir la stratégie d’authentification Dump jeton soit la même que la partie de confiance défectueux.

  2. Demandez à l’utilisateur d’ouvrir un des liens suivants en fonction de la stratégie d’authentification que vous définissez.

    • WS-Fed :https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • P: SAMLhttps://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Forcer l’authentification à plusieurs facteurs :https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  3. Ouvrez une session la page de connexion.

Ce que vous obtenez est un ensemble de revendications de l’utilisateur. Vérifier si quoi que ce soit dans la stratégie d’autorisation qui refuse explicitement ou qui permet à l’utilisateur basée sur ces revendications.

Est-ce que le problème est résolu ?

  1. Configurez les règles de revendication dans l’application Dump jeton soient les mêmes que les règles de la demande de la partie défaillante.

  2. Configurer la stratégie d’authentification vider le jeton pour être la même que la partie de confiance défectueux.

  3. Demandez à l’utilisateur d’ouvrir un des liens suivants en fonction de la stratégie d’authentification que vous définissez.

    • WS-Fed :https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • P: SAMLhttps://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Forcer l’authentification à plusieurs facteurs :https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Ouvrez une session la page de connexion.

Il s’agit de l’ensemble de revendications à que la partie utilisatrice va passer pour l’utilisateur. Si les demandes sont manquants ou inattendu, examinez la stratégie d’émission pour connaître la raison.

Si toutes les déclarations sont présents, vérifiez auprès du propriétaire de l’application pour voir quelle demande est manquant ou inattendu.

Est-ce que le problème est résolu ?

Si les règles d’autorisation vérifient les revendications de périphérique, vérifiez si un de ces revendications de périphérique manque dans la liste des revendications que vous obtenez à partir de l’application de vidage du jeton. Les revendications manquantes pourraient s’empêcher l’authentification des périphériques. Pour obtenir les revendications à partir de l’application de vidage du jeton, suivez les étapes décrites dans la section utiliser l’application Dump jeton pour diagnostiquer la stratégie d’autorisation dans la méthode de vérification de stratégie d’autorisation si l’utilisateur a été affecté .

Voici les revendications de périphérique. 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 existe une demande manquante, suivez les étapes dans à l’aide de la configuration de l’accès conditionnel sur site enregistré des périphériques pour vous assurer que l’environnement est configuré pour l’authentification du périphérique.

Si toutes les déclarations sont présentes, voir si les valeurs des demandes à partir de l’application Dump jeton correspondent aux valeurs requises dans la stratégie d’autorisation.

Est-ce que le problème est résolu ?

Utilisez les méthodes suivantes pour le dépannage. À 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.

Si un utilisateur essaie de se connecter à Active Directory Azure, ils seront redirigés ADFS pour l’authentification pour un domaine fédéré. Une des raisons possibles pour une connexion ayant échouée est que l’utilisateur n’est pas encore synchronisé à AD Azure. Vous pouvez voir une boucle d’Azure AD pour ADFS après la première authentification tentative AD FS. Pour déterminer si l’utilisateur est synchronisé à AD Azure, procédez comme suit :

  1. Télécharger et installez le module PowerShell de publicité Azure pour Windows PowerShell.

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

  3. Établir une connexion à Active Directory Azure en exécutant la commande suivante :
    Connect-MsolService

  4. Fournir les informations d’identification de l’administrateur global pour la connexion.

  5. Pour obtenir la liste des utilisateurs dans Active Directory Azure en exécutant la commande suivante :
    Get-MsolUser

  6. Vérifiez si l’utilisateur est dans la liste.

Si l’utilisateur n’est pas dans la liste, l’utilisateur d’AD Azure la synchronisation.

Est-ce que le problème est résolu ?

Annonce Azure nécessite immutableID et UPN de l’utilisateur pour authentifier l’utilisateur.

Remarque immutableID est également appelée sourceAnchor dans les outils suivants :

  • Azure AD Sync

  • Azure Active Directory Sync (synchronisation)

Permet aux administrateurs Azure Connect d’Active Directory pour la gestion automatique de confiance AD FS avec AD Azure. Si vous ne gérez pas l’approbation via les connexion AD Azure, nous vous conseillons, de téléchargement Azure Connect de AD. Permet d’azure AD connexion automatique en fonction des paramètres de synchronisation de gestion de règles de revendication.

Pour vérifier si les règles de la revendication de nom UPN et d’immutableID AD FS correspondances qu’AD Azure utilise, procédez comme suit :

  1. Obtenir sourceAnchor et UPN dans Azure Connect d’Active Directory.

    1. Ouvrez AD Azure se connecter.

    2. Cliquez sur Afficher la configuration en cours.
      Azure AD Connect -View current configuration

    3. Sur la page de Révision de votre Solution , prenez note des valeurs de Point d’ancrage de la SOURCE et le Nom d’utilisateur PRINCIPAL.
      Azure AD Connect -Review your solution

  2. Vérification de la règle dans le serveur AD FS de réclamer les valeurs de nom UPN et d’immutableID (sourceAnchor), qui correspond.

    1. Console de gestion sur le serveur AD FS, ouvrez l’AD FS .

    2. Cliquez sur la partie de confiance des approbations.

    3. Cliquez sur l’approbation de tiers de confiance avec AD Azure et puis cliquez sur Modifier la stratégie d’émission de revendication .

    4. Ouvrir la règle de revendication immuable ID et un nom UPN.

    5. Vérifiez si les variables interrogés pour les valeurs d’immutableID et UPN sont les mêmes que ceux apparaissent dans Azure Connect d’AD.
      Issue UPN and ImmutableID

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

      • Si AD FS est géré par Azure AD Connect, réinitialiser l’approbation de tiers de confiance à l’aide d’Azure Connect d’Active Directory.

      • Si AD FS n’est pas géré par Azure AD Connect, corriger les revendications avec les attributs appropriés.
         

Est-ce que le problème est résolu ?

Les informations seront utilisé dans les étapes de dépannage suivantes.

 

Si vous utilisez une partie utilisatrice classique, procédez comme suit :

  1. Sur le serveur primaire de l’ADFS, ouvrir Windows PowerShell avec l’option Exécuter en tant qu’administrateur .

  2. Ajouter l’AD FS 2.0 composant Windows PowerShell en exécutant la commande suivante :
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Obtenir les informations de partie utilisatrice en exécutant la commande suivante :
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Obtenir les informations de client OAuth en exécutant la commande suivante :
    $client = Get-AdfsClient ClientName

Si vous utilisez la fonctionnalité de groupe de l’Application dans Windows Server 2016, suivez les étapes ci-dessous :

  1. Sur le serveur primaire de l’ADFS, ouvrir Windows PowerShell avec l’option Exécuter en tant qu’administrateur .

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

  3. Si le client OAuth est public, obtenir les informations du client en exécutant la commande suivante :
    $client = Get-AdfsNativeClientApplication ClientName

    Si le client est confidentiel, obtenir les informations du client en exécutant la commande suivante :
    $client = Get-AdfsServerApplication ClientName

Maintenant poursuivre avec les méthodes de dépannage suivantes.

L’identificateur de partie utilisatrice, ID de client et de rediriger URI doit être fourni par le propriétaire de l’application et le client. Toutefois, il peut toujours exister une incompatibilité entre ce que fournit le propriétaire et les éléments qui sont configurés dans AD FS. Par exemple, une incompatibilité peut être dû à une faute de frappe. Vérifiez si les paramètres fournis par la correspondance de propriétaire ceux configurés dans AD FS. La procédure décrite dans la page précédente vous obtenez 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 du tiers de confiance

$rp.Identifier

L’URI de redirection partie utilisatrice

Une correspondance de préfixe ou un caractère générique de

  • $rp. WSFedEndpoint pour une partie de confiance WS-Fed

  • $rp. SamlEndpoints pour une partie de confiance SAML

ID de client

$client.ClientId

L’URI de redirection de client

Un préfixe correspondant de $client. RedirectUri

Si les éléments dans le tableau correspond, en outre vérifier si ces paramètres correspondent à entre ce qu’ils apparaissent dans la demande d’authentification envoyée à AD FS et les éléments qui sont configurés dans AD FS. Essayez de reproduire le problème au cours de laquelle vous capturez une trace Fiddler sur la demande d’authentification envoyée par l’application ADFS. Examinez les paramètres de la demande pour effectuer les vérifications suivantes, en fonction du type de demande.

Demandes de OAuth

Une demande de OAuth ressemble à ceci :

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 correspond aux paramètres configurés dans AD FS.

Paramètres de la demande

Paramètres configurés dans AD FS

client_id

$client.ClientId

redirect_uri

Un préfixe correspondant de @client_RedirectUri

Le paramètre « ressource » doit représenter une partie de confiance valide dans AD FS. Obtenir les informations de partie utilisatrice en exécutant une des commandes suivantes.

  • Si vous utilisez une partie utilisatrice conventionnelle, exécutez la commande suivante :
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • Si vous utilisez la fonctionnalité de groupe de l’Application dans Windows Server 2016, exécutez la commande suivante :
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

Demandes WS-Fed

Une demande de 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 demande correspond aux paramètres configurés dans AD FS :

Paramètres de la demande

Paramètres configurés dans AD FS

wtrealm

$rp.Identifier

wreply

Une correspondance de préfixe ou génériques de $rp. WSFedEndpoint

Demandes SAML

Une demande SAML ressemble à ceci :

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

Décoder la valeur du paramètre SAMLRequest à l’aide de l’option « De DeflatedSAML » dans l’Assistant de texte Fiddler. La valeur décodée ressemble à ceci :

<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 au sein de la valeur décodée :

  • Vérifie si le nom d’hôte dans la valeur de Destination correspond au nom d’hôte ADFS.

  • Vérifier si la valeur d’émetteur correspond à$rp.Identifier.

Remarques supplémentaires pour SAML

  • $rp. SamlEndpoints : Affiche tous les types de points de terminaison SAML. La réponse à partir d’AD FS est envoyée à l’URL correspondantes configurées dans les points de terminaison. Un point de terminaison SAML peut utiliser des liaisons de redirection, post ou artefact pour la transmission des messages. Tous ces URL peut être configurés dans AD FS.

  • $rp. SignedSamlRequestsRequired : Si la valeur est définie, la requête SAML envoyée à partir de la partie utilisatrice à signer. Les paramètres « SigAlg » et « Signature » doivent figurer dans la demande.

  • $rp. RequestSigningCertificate : Il s’agit du certificat de signature utilisé pour générer la signature de la demande SAML. Assurez-vous que le certificat est valide et demandez au propriétaire de l’application pour faire correspondre le certificat.

Est-ce que le problème est résolu ?

If$rp.EncryptClaimsRetourne « Enabled », cryptage de tiers de confiance est activée. AD FS utilise le certificat de cryptage pour crypter les revendications. Effectuez 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 est conforme à la révocation Vérifiez la configuration requise.

Est-ce que le problème est résolu ?

S’il existe des différences de certificats, assurez-vous que les partenaires utilisent les nouveaux certificats. Les certificats sont inclus dans les métadonnées de fédération publiée par le serveur AD FS.

Remarque Les partenaires de faire tous vos ressources compte ou organisation organisation partenaires, représentées dans votre AD FS en confiance partie approbations et approbations du 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 les partenaires à 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 les partenaires les clés publiques de nouveaux certificats. Pour ce faire, procédez comme suit :

  1. Exporter les clés publiques en tant que fichiers de .cert ou en tant que fichiers .p7b pour inclure les chaînes de certificats complète.

  2. Envoyer les clés publiques pour les partenaires.

  3. Demandez les partenaires à utiliser les nouveaux certificats.

Est-ce que le problème est résolu ?

  1. Ouvrez la console de gestion AD FS.

  2. Avec le bouton droit à l’approbation de tiers de confiance, puis cliquez sur Propriétés.

  3. Sous l’onglet Avancé , sélectionnez l’algorithme à correspondent à ceux requis par l’application.
    Relying party trust-Hash algorithm

Le problème résolu ?

  1. Sur le serveur ADFS, vider 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 demande NameIdentifier. Si une telle règle n’existe pas, ignorez cette étape.
    Voici un exemple de la 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 la valeur 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 pour 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 ce faire, procédez comme suit :

    1. Ouvrez la console de gestion AD FS.

    2. Cliquez sur Approbations des parties de confiance, sélectionnez le partenaire de fédération approprié, puis cliquez sur Modifier la stratégie d’émission revendications dans le volet Actions .

    3. Ajouter une nouvelle règle si il n’y a pas de règle pour émettre la demande NameIdentifier ou mettre à jour une règle existante. Sélectionnez le Nom d’ID de type de revendication entranteet puis spécifiez le format requis par l’application.
      Configure claim rule

Est-ce que le problème est résolu ?

Remarque: vous pouvez également utiliser Fiddler pour résoudre le problème. Le principe est le même.

L’application de vidage du jeton est utile lorsque les règles de revendication du débogage des problèmes avec votre service de fédération, ainsi que la validation personnalisée. Il n’est pas une bonne solution de débogage indépendante qui est recommandée pour les besoins de dépannage, mais une solution officielle. Pour utiliser l’application Dump jeton, procédez comme suit :

  1. Définir l’application Dump jeton en exécutant les commandes suivantes :
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"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

  2. Répliquer la configuration de tiers de confiance défectueux par copie les règles de délivrance de la partie de confiance vers DumpToken. Pour ce faire, exécutez la commande suivante :
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

  3. Demandez à l’utilisateur d’ouvrir un des liens suivants en fonction de la stratégie d’authentification que vous définissez.

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Forcer l’authentification à plusieurs facteurs :https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Obtenir les revendications par demander à l’utilisateur d’ouvrir une session la page d’authentification.

  5. Dans le Dump sortie du jeton, développez la section de données XML brutes jeton et consulter la déclaration de l’attribut en vérifiant les chaînes suivantes pour voir s’ils correspondent à ce qui est configuré dans la stratégie d’émission de revendication :

    • SAML:NameIdentifier : affiche le format NameIdentifier.

    • SAML:AttributeStatement : affiche chaque paire type/valeur de revendication pour le jeton.

    • SAML:AuthenticationStatement : affiche la méthode d’authentification et les instantanés de l’authentification.

Est-ce que le problème est résolu ?

Utilisez la page de IdpInititatedSignOn pour vérifier si le service AD FS est en cours d’exécution et que la fonctionnalité d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :

  1. Activer la page de IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. À partir d’un ordinateur qui est à l’intérieur de votre réseau, reportez-vous à la page suivante :
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Sur la page de connexion, entrez les informations d’identification correctes d’un utilisateur valide.

Est le signe de réussite ?

Pour résoudre le problème, vérifiez les éléments suivants et les services.

Accès à AD FS doit pointer directement à l’un des serveurs ADFS ou l’équilibreur de charge devant les serveurs ADFS. Effectuez les vérifications suivantes :

  • Ping sur le nom de service de fédération (par exemple, fs.contoso.com). Vérifiez si l’adresse IP que vous obtenez est convertie en un des serveurs ADFS ou l’équilibrage de la charge des serveurs ADFS.

  • Vérifiez s’il existe un enregistrement A pour le service de fédération dans le serveur DNS. L’enregistrement A doit pointer vers l’un des serveurs ADFS ou à l’équilibreur de charge des serveurs ADFS.

Est-ce que le problème est résolu ?

  • Vérifier si le pare-feu bloque le trafic entre :

    • Le serveur AD FS et l’équilibreur de charge.

    • Le WAP (Web Proxy d’Application) serveur et l’équilibrage de la charge si WAP sert.

  • Si la sonde est activée sur l’équilibrage de charge, vérifiez les points suivants :

    • Si vous exécutez Windows Server 2012 R2, assurez-vous que le Correctif cumulatif août 2014 est installé.

    • Vérifiez si le port 80 est activé dans le pare-feu sur les serveurs WAP et AD FS.

    • Assurez-vous que cette sonde est définie pour le port 80 et pour la point de terminaison/adfs/sonde.

Est-ce que le problème est résolu ?

  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.

Est-ce que le problème est résolu ?

AD FS fournit différents points de terminaison pour des scénarios et des fonctionnalités différentes. Pas tous les points de terminaison sont activés par défaut. Pour vérifier l’état des points de terminaison, procédez comme suit :

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

  2. Développez le Service > points de terminaison.

  3. Recherchez les points de terminaison et vérifiez si les statuts sont activés dans la colonne activé .
    ADFS Endpoints status

Est-ce que le problème est résolu ?

Nous vous conseillons d’utiliser Azure Connect AD qui facilite la gestion des certificats SSL.

Azure Connect d’annonce est installée dans votre environnement ?

Si Azure Connect d’Active Directory est installé, assurez-vous que vous utilisez pour gérer et mettre à jour les certificats SSL.

Est-ce que le problème est résolu ?

Le certificat SSL doit remplir les conditions suivantes :

  • Le certificat provient d’une autorité de certification racine de confiance.
    ADFS nécessite que les certificats SSL sont auprès d’une autorité de certification racine de confiance. Si AD FS est accessible à partir d’ordinateurs de joints hors domaine, nous vous recommandons d’utiliser un certificat SSL auprès d’une autorité de certification racine tierce partie de confiance comme DigiCert, VeriSign, etc.. Si le certificat SSL n’est pas auprès d’une autorité de certification racine de confiance, les communications SSL peuvent interrompre.

  • Le nom du sujet du certificat est valide.
    Le nom du sujet doit correspondre le nom de service de fédération, pas sur le nom du serveur AD FS ou un autre nom. Pour obtenir le nom de service de fédération, exécutez la commande suivante sur le serveur ADFS principal :
    Get-AdfsProperties | select hostname

  • Le certificat n’est pas révoqué.
    Vérification de révocation de certificats. Si le certificat est révoqué, connexion SSL ne peut pas être approuvée et sera bloquée par les clients.

Le certificat SSL répond-elle à ces exigences ?

Pour résoudre votre problème, obtenez un certificat qualifié pour la communication SSL.

Le problème résolu une fois que vous utilisez un certificat SSL qualifié ?

Vérifiez les configurations suivantes du certificat SSL.

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

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

  1. Liste les certificats dans le magasin personnel de l’ordinateur local en exécutant la commande suivante :
    dir Cert:\LocalMachine\My

  2. Vérifiez si le certificat est dans la liste.

Est-ce que le problème est résolu ?

Obtenir l’empreinte numérique du certificat qui est utilisé pour la communication SSL et vérifiez si l’empreinte numérique correspond à l’empreinte numérique du certificat prévu.

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

Get-AdfsSslCertificate

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

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Est-ce que le problème est résolu ?

Le certificat SSL doit être défini en tant que le certificat de communication du service dans votre batterie de serveurs ADFS. Ce n’est pas automatique. Pour vérifier si le certificat approprié est défini, procédez comme suit :

  1. Dans la Console de gestion AD FS, développez Service > certificats.

  2. Vérifiez si le certificat répertorié sous les communications Service est le certificat attendu.

Si le bon certificat est répertorié, définir le certificat approprié et puis accorder que l’autorisation de lecture pour le certificat de service de l’ADFS. Pour ce faire, procédez comme suit :

  1. Définir le certificat correct :

    1. Cliquez sur certificats, puis cliquez sur Définir le certificat de Communication du Service.

    2. Sélectionner le certificat approprié.

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

    1. Ajoutez le composant logiciel enfichable certificats pour le compte d’ordinateur local à Microsoft Management Console (MMC).

    2. Développez certificats (ordinateur Local) > Personal > certificats.

    3. Cliquez 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 noms d’utilisateurs et de groupes avec l’autorisation de lecture .

  3. Si adfssrv n’est pas répertorié, accorder que l’autorisation de lecture pour le certificat de service l’AD FS :

    1. Cliquez sur Ajouteret cliquez sur emplacements, cliquez sur le serveur, puis cliquez sur OK.

    2. Dans la zone Entrez les noms des objets à sélectionner, entrez nt service\adfssrvet cliquez sur Vérifier les noms, puis cliquez sur OK.
      Si vous utilisez AD FS avec dispositif d’enregistrement Service (DRS), entrez nt service\drs à la place.

    3. Accordez l’autorisation de lecture , puis cliquez sur OK.

Est-ce que le problème est résolu ?

DRS est configuré dans AD FS ?

Si vous avez configuré ADFS avec DRS, assurez-vous que le certificat SSL est correctement configuré pour RDS. Par exemple, s’il y a deux contoso.com de suffixes UPN et fabrikam.com, le certificat doit avoir enterpriseregistration.contoso.com et enterpriseregistration.fabrikma.com comme les autres noms de l’objet (SAN).

Pour vérifier si le certificat SSL possède les SAN corrects, procédez comme suit :

  1. Liste de tous les suffixes UPN utilisés dans l’organisation en exécutant la commande suivante :
    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Vérifiez si le certificat SSL est requis pour le SAN configuré.

Le certificat SSL a des noms corrects de DRS en SAN ?

Pour résoudre ce problème, obtenir un nouveau certificat SSL qui a les SAN corrects pour DRS et ensuite l’utiliser en tant que le certificat SSL pour AD FS.

Est-ce que le problème est résolu ?

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 les mettre à jour si nécessaire

Pour prendre en charge des cas de non-SNI, les administrateurs peuvent définir des liaisons de secours. Que la liaison de federationservicename:443 standard, recherchez les liaisons de secours sous l’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 secours comme 0.0.0.0 : 443, assurez-vous que la liaison est mise à jour en conséquence lors de la mise à jour le certificat SSL.

Est-ce que le problème est résolu ?

  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.

Est-ce que le problème est résolu ?

La page IdpInititatedSignOn permet de vérifier rapidement si le service AD FS est actif et en cours d’exécution et de la fonctionnalité d’authentification fonctionne correctement. Pour ouvrir la page IdpInitiatedSignOn, procédez comme suit :

  1. Activer la page de IdpInitiatedSignOn en exécutant la commande suivante sur le serveur AD FS :
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. À partir d’un ordinateur qui ne fait pas partie de votre réseau, reportez-vous à la page suivante :
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Sur la page de connexion, entrez les informations d’identification correctes d’un utilisateur valide.

Est le signe de réussite ?

Pour résoudre le problème, vérifiez les éléments suivants et les services.

Accès à AD FS doit pointer directement vers les serveurs WAP (Web Proxy de l’Application) ou de l’équilibreur de charge devant les serveurs WAP. Effectuez les vérifications suivantes :

  • Ping sur le nom de service de fédération (par exemple, fs.contoso.com). Vérifiez si l’adresse IP que résout la commande Ping 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 dans le serveur DNS. L’enregistrement A doit pointer vers l’un des serveurs WAP ou à l’équilibreur de charge des serveurs WAP.

Si le WAP n’est pas implémentée dans votre scénario pour l’accès externe, vérifiez si unccessing AD FS points directement les serveurs ADFS ou l’équilibreur de charge devant les serveurs ADFS :

  • Ping sur le nom de service de fédération (par exemple, fs.contoso.com). Vérifiez si l’adresse IP que vous obtenez est convertie en un des serveurs ADFS ou l’équilibrage de la charge des serveurs ADFS.

  • Vérifiez si un enregistrement A pour le service de fédération dans le serveur DNS. L’enregistrement A doit pointer vers l’un des serveurs ADFS ou à l’équilibreur de charge des serveurs ADFS.

Est-ce que le problème est résolu ?

  • Vérifier si le pare-feu bloque le trafic entre :

    • Le serveur AD FS et l’équilibreur de charge.

    • Le WAP (Web Proxy d’Application) serveur et l’équilibrage de la charge si WAP sert.

  • Si la sonde est activée sur l’équilibrage de charge, vérifiez les éléments suivants :

    • Si vous exécutez Windows Server 2012 R2, assurez-vous que le Correctif cumulatif août 2014 est installé.

    • Vérifiez si le port 80 est activé dans le pare-feu sur le serveur WAP et serveurs AD FS.

    • Assurez-vous que cette sonde est définie pour le port 80 et le /adfs/probe de point de terminaison.

Est-ce que le problème est résolu ?

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

    • til pare-feu entre le serveur Proxy de l’Application Web et de la batterie de serveurs de fédération.

    • le pare-feu entre les clients et le serveur Proxy de l’Application Web.

  2. Vérifiez si le trafic entrant via le port TCP 49443 est activé sur le pare-feu entre les clients et le serveur Proxy de l’Application Web, lorsque les conditions suivantes sont remplies :

    • L’authentification du client TLS à l’aide du certificat X.509 est activée.

    • Vous utilisez AD FS dans Windows Server 2012 R2.

      Remarque La configuration n’est pas requis sur le pare-feu entre le serveur Proxy de l’Application Web et les serveurs de fédération.

Est-ce que le problème est résolu ?

 

Est-ce que le problème est résolu ?

AD FS fournit différents points de terminaison pour des scénarios et des fonctionnalités différentes. Pas tous les points de terminaison sont activés par défaut. Pour vérifier si le point de terminaison est activée sur le serveur proxy, procédez comme suit :

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

  2. Développez le Service > points de terminaison.

  3. Recherchez le point de terminaison et vérifier si l’état est activé sur la colonne Proxy activé .
    ADFS endpoints proxy status

 

Est-ce que le problème est résolu ?

Remarque : Informations sur cette page s’appliquent à AD FS 2012 R2 et versions ultérieures.

Si le Proxy d’Application Web (WAP) est déployé, la relation d’approbation proxy doit être établie entre le serveur WAP et le serveur AD FS. Vérifiez si la relation d’approbation proxy est établie ou échoue à un moment donné dans le temps.

Informations générales

La relation d’approbation de proxy est un certificat client en fonction. Lorsque vous exécutez l’Assistant après l’installation de Proxy d’Application Web, l’Assistant génère un certificat auto-signé client en utilisant les informations d’identification que vous avez spécifié dans l’Assistant. L’Assistant insère le certificat dans la base de données de configuration AD FS, puis l’ajoute au magasin de certificats AdfsTrustedDevices sur le serveur AD FS.

Pour toutes les communications SSL, http.sys utilise l’ordre de priorité suivant pour les liaisons de certificat SSL pour faire correspondre un certificat :

Priorité

Nom

Paramètres

Description

1

IP

IP:port

Correspondance exacte IP et le Port

2

SNI

Hostname:port

Correspondance exacte (connexion doit spécifier la SNI)

3

CCS

Port

Appeler le magasin Central de certificat

4

Générique de IPv6

Port

Correspondance de caractères génériques IPv6 (la connexion doit être IPv6)

5

IP génériques

Port

Correspondance de caractères génériques IP (connexion peut être IPv4 ou IPv6)

AD FS 2012 R2 et ultérieurement sont indépendantes de Internet Information Services (IIS) et s’exécute en tant que service sur http.sys. liaisons de certificat SSL nom_hôte : port utilisés par ADFS. Lors de l’authentification de certificat client, ADFS envoie une liste de certificats (CTL) basée sur les certificats dans le magasin de AdfsTrustedDevices. Si une liaison de certificat SSL pour votre serveur ADFS utilise IP : port ou le magasin de confiance n’est pas AdfsTrustedDevices, relation d’approbation proxy ne peut pas être établie.

Obtenir les liaisons de certificat SSL pour AD FS

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

Dans la liste des liaisons a renvoyé, recherchez ceux dont l’ID d’Application de 5d89a20c-beab-4389-9447-324788eb944a. Voici un exemple d’une liaison en bon état. Remarque Les éléments en gras.

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

Résolution des problèmes

Pour détecter automatiquement les problèmes liés à la relation d’approbation de serveur proxy, exécutez le script suivant. Selon le problème détecté, effectuer l’action en conséquence à la fin de la page.

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.")

Quel est le problème détecté ?

La liaison IP : port prend la priorité la plus élevée. Si une liaison IP : port est dans les liaisons de certificat AD FS SSL, http.sys utilise toujours le certificat pour la liaison pour la communication SSL. Pour résoudre ce problème, appliquez les méthodes suivantes.

Méthode 1 : Supprimer la liaison IP : port

Notez que la liaison IP : port peut-être provenir de retour une fois que vous l’avez supprimé. Par exemple, une application configurée avec cette liaison IP : port peut recréer d’automatiquement sur le démarrage du service suivant.

Méthode 2 : Utiliser une autre adresse IP pour la communication AD FS SSL

Si la liaison IP : port est obligatoire, de résoudre le nom de domaine complet du service ADFS vers une autre adresse IP qui n’est pas utilisée dans les liaisons. De cette façon, http.sys utilise la liaison nom_hôte : port pour les communications SSL.

Méthode 3 : Les AdfsTrustedDevices de jeu comme magasin de confiance pour la liaison IP : port

, C’est le dernier recours si vous ne pouvez pas utiliser les méthodes ci-dessus. Mais il est préférable de comprendre les les conditions suivantes avant de modifier la valeur par défaut, stocker des CTL pour AdfsTrustedDevices :

  • Pourquoi IP : port la liaison existe-t-il.

  • Si la liaison dépend de la valeur par défaut, stocker des CTL pour l’authentification de certificat client.

Est-ce que le problème est résolu ?

Si Azure Connect d’Active Directory est installé, utilisez DAS se connecter pour définir le nom de magasin de confiance à AdfsTrustedDevices pour les liaisons de certificat SSL sur tous les serveurs ADFS. Si Azure AD Connect n’est pas installé, régénérer les liaisons de certificat ADFS en exécutant la commande suivante sur tous les serveurs ADFS.
Set-AdfsSslCertificate -Thumbprint Thumbprint

Est-ce que le problème est résolu ?

Si une autorité de certification délivrée le certificat se trouve dans un magasin de certificats dans lequel seuls les certificats auto-signés existerait normalement, la liste de certificats générée depuis le magasin ne contiendrait que délivrée de certificat de l’autorité de certification. Le magasin de certificats AdfsTrustedDevices est une banque de ce type qui est censé pour accueillir uniquement des certificats auto-signés. Ces certificats sont les suivants :

  • MS--accès organisation : Le certificat auto-signé utilisé pour la délivrance des certificats de jointure poste de travail.

  • ADFS Proxy d’approbation : Certificats pour chaque serveur Proxy de l’Application Web.

AdfsTrustedDevices certificates

Par conséquent, supprimer un certificat d’autorité de certification délivré dans le magasin de certificats AdfsTrustedDevices.

Est-ce que le problème est résolu ?

Lorsqu’une relation d’approbation proxy est établie avec un serveur ADFS, 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 ADFS, le certificat client doit être synchronisée sur les autres serveurs ADFS. Si la synchronisation ne se produit pas pour une raison quelconque, une relation d’approbation proxy ne fonctionne que sur le serveur ADFS avec que l’approbation a été établie, mais pas par rapport aux autres serveurs ADFS.

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

Méthode 1

Sur tous les serveurs ADFS, installez la mise à jour décrite dans KB 2964735 . Après avoir installé la mise à jour, une synchronisation du certificat client est supposée se produire automatiquement.

Méthode 2

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

Notez que cela n’est pas une solution permanente, car les certificats du client seront renouvelés à intervalles réguliers.

Est-ce que le problème est résolu ?

Vérifiez s’il existe une incompatibilité de temps ou le fuseau horaire. Si heure correspond à mais le temps de zone ne, relation d’approbation proxy échoue également être établie.

Est-ce que le problème est résolu ?

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

Désactiver l’arrêt de SSL sur le périphérique de réseau entre les serveurs ADFS et WAP.

Est-ce que le problème est résolu ?

Vérifiez les paramètres de l’authentification intégrée de Windows dans le navigateur client, les paramètres d’ADFS et les paramètres de la demande d’authentification.

Vérifier le navigateur client de l’utilisateur

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

  • Sous l’onglet Avancé , assurez-vous que le paramètre Activer l’authentification intégrée de Windows est activé.

  • à la suite de sécurité > intranet Local > Sites > Avancé, vérifiez que l’URL de la FS AD est dans la liste des sites Web.

  • Suivant sécurité > intranet Local > Personnaliser le niveau, assurez-vous que le paramètre ouverture de session automatique uniquement dans la Zone Intranet est activé.

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

Vérifiez les paramètres AD FS

Vérifiez le paramètre de WindowsIntegratedFallback

  1. Ouvrez Windows PowerShell à l’exécuter en tant qu’option d’administrateur.

  2. Obtenir 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 l’authentification intégrée de Windows. Consultez la section suivante sur la façon d’obtenir votre navigateur pris en charge.

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

Vérifiez le paramètre de WIASupportedUsersAgents

  1. Obtenir 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 renvoyée par la commande.

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

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

  2. Obtenir 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 du navigateur en exécutant la commande suivante :
    $wiaStrings = $wiaStrings+"NewUAString"
    Exemple :$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

  4. Mettre à jour le paramètre WIASupportedUserAgents en exécutant la commande suivante :
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Vérifiez les paramètres de la demande d’authentification

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

  1. Si la demande d’authentification est un demande de WS-Federation, vérifiez si la demande inclut wauth = urn : oasis : noms : tc : SAML:1.0:am:password.

  2. Si la demande d’authentification est une demande SAML, vérifiez si la demande inclut une samlp:AuthnContextClassRef élément avec la valeur urn : oasis : noms : tc : SAML:2.0:ac:classes:Password.

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

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

Si l’application que vous souhaitez accéder n’est pas de Microsoft Online Services, vous pouvez constater est prévu et contrôlé par la demande d’authentification entrante . Travailler avec le propriétaire de l’application pour modifier le comportement.

Si l’application est de Microsoft Online Services, vous rencontrez peut être contrôlé par la PromptLoginBehavior paramètre de de l’objet de domaine approuvé. Ce paramètre contrôle si les locataires AD Azure envoyer invite = connexion à AD FS. Pour définir le PromptLoginBehavior paramètreSuivez ces étapes :

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

  2. Obtenir 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 pour le paramètre PromptLoginBehavior sont :

    1. TranslateToFreshPasswordAuth: AD Azure envoie AD FS, au lieu de l’invite de commandes wauth et wfresh = connexion. Cela conduit à une demande d’authentification à utiliser l’authentification basée sur les formulaires.

    2. NativeSupport: le paramètre de connexion = invite est envoyé tel quel à AD FS.

    3. Désactivé: rien n’est envoyé à AD FS.

Pour en savoir plus sur la commande Set-MSOLDomainFederationSettings, reportez-vous à la section demander des Services de fédération Active Directory = prise en charge du paramètre de connexion.

Est-ce que le problème est résolu ?

Plusieurs facteurs d’authentification peut être activé sur un serveur AD FS, à une partie de confiance, ou spécifié dans un paramètre de demande d’authentification. Vérifiez la configuration pour voir si elles sont correctement définies. Si une authentification multifactorielle est attendue mais vous're invité à plusieurs reprises pour lui, vérifier les règles de délivrance de partie utilisatrice pour voir si les demandes d’authentification à plusieurs facteurs sont passés à l’application.

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

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

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

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

    Pour vérifier la configuration sur la partie de confiance, exécutez la commande suivante :
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    Remarque Si les commandes renvoient la valeur nothing, les règles d’authentification supplémentaires ne sont pas configurés. Ignorer cette section.

  2. Observez la règle de revendication configuré.

Vérifiez si une authentification multifactorielle 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 de problème :=> issue (Type=…,Value=…)

Si l’instruction de problème contient la déclaration suivante, plusieurs facteurs d’authentification est spécifié.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Voici des exemples qui requièrent une authentification multifacteur à utiliser respectivement pour les périphériques de joints non-lieu de travail et pour l’accès extranet :

  • 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 de délivrance partie utilisatrice

Si l’utilisateur reçoit les invites d’authentification à plusieurs facteurs à plusieurs reprises une fois qu’ils effectuent la première authentification, il est possible que la partie de réponse ne traverse pas les demandes d’authentification à plusieurs facteurs pour l’application. Pour vérifier si les demandes d’authentification sont transmises par l’intermédiaire, procédez comme suit :

  1. Dans Windows PowerShell, exécutez la commande suivante :
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp

  2. Observez les règles définies dans les attributs IssuanceAuthorizationRules ou IssuanceAuthorizationRulesFile.

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

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

Vérifiez si la demande d’authentification spécifie une authentification à plusieurs facteurs comme la méthode d’authentification

  • Si la demande d’authentification est un demande de 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 une samlp:AuthnContextClassRef élément avec la valeur http://schemas.microsoft.com/claims/multipleauthn.

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

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

Si l’application que vous souhaitez accéder est de Microsoft Online Services pour Office 365, vérifiez le paramètre de fédération de domaine SupportsMFA.

  1. Obtenir le paramètre de fédération de domaine SupportsMFA en cours en exécutant la commande suivante :
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  2. Si le paramètre SupportsMFA a la valeur FALSE, affectez-lui la valeur True en exécutant la commande suivante :
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

Est-ce que le problème est résolu ?

Désactiver la fonctionnalité de connexion = invite de commande en exécutant la commande suivante :
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Après avoir exécuté cette commande, les applications Office 365 n’incluront pas le paramètre de connexion = invite dans chaque demande d’authentification.

Est-ce que le problème est résolu ?

Modifier le paramètre de requête pour utiliser la méthode d’authentification attendu.

Est-ce que le problème est résolu ?

Si l’authentification est désactivée, activez-la.

Est-ce que le problème est résolu ?

Félicitations ! Le problème de l’authentification unique a été résolu.

Nous sommes navrés d’apprendre que le problème persiste. Nous vous prions si vous complétez l’enquête avec les détails de votre problème.

Que fait ce guide ?

Résout de session unique (SSO) problèmes avec Active Directory Federation Services (ADFS).

Est la personne concernée ?

Administrateurs qui aident à diagnostiquer les problèmes de l’authentification unique pour leurs utilisateurs.

Comment cela fonctionne-t-il ?

Nous allons commencer en vous demandant le problème face à vos utilisateurs. Puis nous allons vous à travers une série d’étapes qui sont spécifiques à votre situation de dépannage.

Temps d’exécution estimé :

30 à 45 minutes.

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×