Résolution des problèmes AD FS - Authentification Windows intégrée

L’authentification Windows intégrée permet aux utilisateurs de se connecter avec leurs informations d’identification Windows et de faire l’expérience de l’authentification unique (SSO) à l’aide de Kerberos ou de NTLM.

Raison de l’échec de l’authentification Windows intégrée

Trois raisons principales expliquent l’échec de l’authentification Windows intégrée. Il s’agit des éléments suivants : - Configuration incorrecte du nom du principal du service (SPN) - Jeton de liaison de canal - Configuration d’Internet Explorer

Configuration incorrecte du SPN

Un nom de principal de service (SPN) est un identificateur unique d’une instance de service. Les SPN sont utilisés par l’authentification Kerberos pour associer une instance de service à un compte d’ouverture de session de service. Cela permet à une application cliente de demander à ce que le service authentifie un compte même si le client n’a pas le nom du compte.

Voici un exemple d’utilisation d’un SPN avec AD FS :

1. Un navigateur web interroge Active Directory pour déterminer le compte de service exécutant sts.contoso.com
2. Active Directory indique au navigateur qu’il s’agit du compte de service AD FS.
3. Le navigateur obtient un ticket Kerberos pour le compte de service AD FS.

Si le compte de service AD FS a un SPN mal configuré ou incorrect, cela peut entraîner des problèmes. En examinant les traces réseau, vous pouvez voir des erreurs comme KRB Error : KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

À l’aide des traces réseau (comme Wireshark), vous pouvez déterminer le SPN que le navigateur tente de résoudre, puis à l’aide de l’outil en ligne de commande setspn - Q <spn>, vous pouvez effectuer une recherche sur ce SPN. Il est possible qu’il ne soit pas trouvé ou qu’il soit affecté à un autre compte que le compte de service AD FS.

Vous pouvez vérifier le SPN en examinant les propriétés du compte de service AD FS.

Jeton de liaison de canal

Actuellement, lorsqu’une application cliente s’authentifie elle-même au serveur à l’aide de Kerberos, de Digest ou de NTLM via le protocole HTTPS, un canal TLS (Transport Level Security) est d’abord établi, puis l’authentification a lieu à l’aide de ce canal.

Le jeton de liaison de canal est une propriété du canal externe sécurisé TLS et permet d’établir la liaison entre le canal externe et une conversation via le canal interne authentifié par le client.

Si une attaque d’« intercepteur » se produit et que l’attaquant déchiffre et rechiffre le trafic SSL, la clé ne correspond pas. AD FS détermine qu’il y a quelque chose entre le navigateur web et lui-même. Cela entraîne l’échec de l’authentification Kerberos, et l’utilisateur est invité à utiliser une boîte de dialogue 401 au lieu d’une expérience d’authentification unique.

Cela peut être provoqué par :

• Tout ce qui se trouve entre le navigateur et AD FS
• Fiddler
• Proxys inverses effectuant un pontage SSL

Par défaut, AD FS a cette valeur définie sur « Autoriser ». Vous pouvez modifier ce paramètre à l’aide de l’applet de commande PowerShell Set-ADFSProperties -ExtendedProtectionTokenCheck None

Pour plus d’informations à ce sujet, consultez Meilleures pratiques pour la planification et le déploiement sécurisés d’AD FS.

Configuration d’Internet Explorer

Notes

Si vous utilisez Chrome, ajoutez-le à la liste des agents utilisateur pris en charge par WIA.

Par défaut, Internet Explorer se comporte comme suit :

1. Internet Explorer reçoit une réponse 401 d’AD FS avec le mot NEGOTIATE dans l’en-tête.
2. Cela indique au navigateur web d’obtenir un ticket Kerberos ou NTLM à renvoyer à AD FS.
3. Par défaut, Internet Explorer tente de le faire (SPNEGO) sans intervention de l’utilisateur si le mot NEGOTIATE se trouve dans l’en-tête. Cela fonctionne uniquement pour les sites intranet.

Il y a deux choses principales qui peuvent empêcher cela de se produire.

• Activer l’authentification Windows intégrée n’est pas coché dans les propriétés d’Internet Explorer. Vous trouverez cela sous Options Internet -> Avancé -> Sécurité.

  

• Les zones de sécurité ne sont pas configurées correctement

  • Les noms de domaine complets ne sont pas dans la zone intranet

  • L’URL AD FS ne se trouve pas dans la zone intranet.

    

Étapes suivantes

• Résolution des problèmes AD FS