Points à vérifier lorsque l’authentification Kerberos ne fonctionne pas

  • Article

English Version

Lorsque l'authentification Kerberos ne fonctionne pas, il convient de commencer par simplifier la configuration au strict minimum (un client/un serveur/un site web sur le port par défaut). De plus, quelques tests basiques peuvent être effectués comme l'utilisation d' une page permettant de valider l'utilisation (ou non) de Kerberos. En ASP.NET, vous pouvez créer une page similaire à cette page ou utiliser la page de test conçue par notre équipe : ASP.NET Authentication test page. En ASP classique, vous pouvez utiliser la page suivante :

Testkerb.asp
<%
authType=UCase(Request.ServerVariables("AUTH_TYPE"))
authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
response.write " Authentication Method : " & authType & "<BR>"
LenAuthHeader = len(authHeader)
response.write " Protocol : "
if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write "NTLM"
%>

Il est également possible de valider l'utilisation de Kerberos en utilisant Fiddler, STRACE/HTTPREPLAY, Network Monitor…etc Lorsque Kerberos est utilisé, la requête envoyée par le poste client est toujours d'une taille « respectable » (en général plus de 2000 octets) puisque le header HTTP_AUTHORIZATION inclut le ticket Kerberos :

Alors qu'en NTLM, la taille de la requête sera beaucoup plus petite :

A ce stade, si Kerberos ne fonctionne pas, un certain nombre de points doivent être vérifiés :

 

  • Correctif Kerberos pour Windows 2008 R2 

Si votre serveur IIS tourne sur Windows 2008 R2, assurez vous d'avoir installé le correctif https://support.microsoft.com/kb/2545850. Sans ce correctif, vous risquez d'avoir des comportements aléatoires au niveau de l'authentification Kerberos.

  • Le client et le serveur sont-ils dans un domaine ?

L'obtention d'un ticket Kerberos passe nécessairement par l'utilisation d'un KDC dont le rôle est tenu, en environnement Windows, par un contrôleur de domaine.

  • Le serveur IIS est-il configuré pour utiliser l'authentification intégrée ?

  • Le client (Internet Explorer) est-il configuré pour utiliser l'authentification intégrée ?

  • L'URL utilisée est-elle dans une zone de sécurité IE permettant l'utilisation de l'authentification intégrée ?

    Il convient de vérifier qu'IE est configuré pour autoriser l'envoi (silencieux ou non) des informations d'authentification (« credentials ») pour la zone de sécurité correspondant à l'URL accédée.

Remarque : même si cette configuration est peu fréquente, car elle nécessite que le client ait accès à un contrôleur de domaine pour obtenir un ticket, Kerberos peut être utilisé lorsque l'URL accédée est en zone Internet mais ceci produira un prompt d'authentification. Cependant, la délégation Kerberos ne fonctionnera que pour les zones « Intranet » et « Sites de confiance ».

  • Le serveur est-il configuré pour utiliser le header WWW-Authenticate : Negotiate ?

    Dans le cas contraire, il conviendra d'utiliser ADSUTIL pour positionner le header Negotiate (propriété NTAuthenticationProviders de la métabase)comme indiqué dans cet article : https://support.microsoft.com/kb/215383
    Remarque : par défaut, la propriété NTAuthenticationProviders n'est pas définie ce qui provoque l'envoi par IIS des headers (Negotiate et NTLM) :

  • Le client et le serveur sont-ils sur la même machine ?

    Kerberos ne fonctionnera pas dans cette configuration en raison d'un test de bouclage ("loopback check") réalisé par le système d'exploitation. Il faut aussi noter que l'utilisation de NTLM peut poser problème  (voir https://support.microsoft.com/kb/896861 pour plus de détails).

  • Le client arrive-t-il à obtenir un ticket ?

    L'utilitaire KERBLIST (fourni dans le « Windows 2003 Server Resource Kit ».) peut être utilisé pour valider ce point. Dans cet exemple, la commande KERBLIST permet de récupérer avec succès un ticket Kerberos pour le SPN http/MEMMANUBO1 :

    Si l'obtention du ticket échoue, Kerberos ne pourra être utilisé et le client basculera éventuellement en NTLM si ce mode d'authentification est configuré :

    • si l'obtention du ticket échoue car le contrôleur de domaine (DC) ne connait pas le SPN demandé, un basculement (« fallback ») en NTLM sera possible
    • Si le contrôleur de domaine (DC) est injoignable, aucun basculement vers NTLM ne sera possible

  • Ce type de problème peut typiquement se produire si un SPN n'a pas été correctement déclaré. L'article suivant pourra alors être consulté pour déclarer le SPN manquant : https://support.microsoft.com/kb/929650

  • Un autre port que le port 80 est-il utilisé ?

    Par défaut, Internet Explorer n'inclut pas le numéro de port dans le SPN lors de la demande du ticket Kerberos. Ceci pose problème dans le cas où plusieurs sites web sont hébergés sous IIS, chaque site utilisant un numéro de port et une identité spécifique. Dans cette configuration, l'authentification Kerberos fonctionnera uniquement sur certains sites bien que les SPN de tous les sites aient été dument déclarés dans AD. Pour résoudre ce problème, il est nécessaire d'activer la clé FEATURE_INCLUDE_PORT_IN_SPN_KB908209 ( https://support.microsoft.com/kb/908209) afin de forcer Internet Explorer à inclure le numéro de port dans le SPN utilisé pour la demande de ticket Kerberos.

  • Le SPN utilisé par IE pour demander le ticket Kerberos est-il celui attendu ?

    Si un site web est accédé en utilisant un alias de nom de machine (CNAME), il faut savoir qu'Internet Explorer effectuera d'abord une résolution DNS pour obtenir le nom de machine (ANAME). Par défaut, le SPN utilisé par IE pour demander le ticket Kerberos sera basé sur le ANAME et non le CNAME. En conséquence, même si l'URL tapé dans la barre d'adresse IE est https://MONSITEWEB, IE va demander un ticket Kerberos pour le SPN HTTP/MONSERVEUR dans le cas où MONSITEWEB est un alias (CNAME) du nom de machine MONSERVEUR (ANAME).
    Au niveau du poste client, ce comportement peut être changé via la clé de registre FEATURE_USE_CNAME_FOR_SPN_KB911149 détaillée dans cet article : https://support.microsoft.com/kb/911149.
    Une trace Network Monitor pourra être utilisée pour vérifier le SPN associé au ticket :

    Il est aussi possible d'utiliser l'outil KERBSPY (fourni dans KAPIMON) pour visualiser le SPN utilisé par Internet Explorer :

  • L'identité de l'application pool est-elle en adéquation avec le compte associé au SPN ?

    Lorsqu'un ticket Kerberos est envoyé par Internet Explorer à un serveur IIS, le ticket Kerberos est chiffré en utilisant une clé privée basée sur le hash du mot de passe du compte associé au SPN. En conséquence, seul un application pool tournant sous l'identité du compte associé au SPN pourra décoder le ticket.

    Résumons rapidement les étapes  de l'authentification Kerberos :

    • Internet Explorer va se baser sur l'URL entrée dans la barre d'adresse pour calculer un SPN
    • Le SPN est fourni, via l'API SSPI (InitializeSecurityContext), au composant système chargé de la sécurité sous Windows (processus LSASS). A ce stade, il est important de noter qu'Internet Explorer n'implémente aucun code relatif à la construction du ticket Kerberos.
    • A partir du SPN, LSASS demande un ticket Kerberos à un contrôleur de domaine (DC). Si le DC est capable de fournir un ticket pour le SPN demandé, le ticket est renvoyé au client sous une forme chiffrée uniquement décodable par le compte utilisateur associé au SPN (là encore, Internet Explorer n'a aucun moyen de décoder le ticket kerberos qui reste, en ce qui le concerne, une structure « opaque »).
    • Internet Explorer récupère le ticket Kerberos fourni par LSASS et l'encapsule dans le header Authorization : Negotiate pour l'envoyer au serveur
    • La requête http est traitée par IIS puis « routée » vers un application pool
    • L'application pool tente de décoder le ticket (en se basant, comme Internet Explorer, sur SSPI/LSASS) :
      • si le décodage du ticket fonctionne, l'authentification est un succès et tous les services associés au ticket Kerberos sont accessibles (impersonnation, délégation si le ticket le permet…etc)
      • dans le cas contraire, une erreur Kerberos de type KRB_AP_ERR_MODIFIED est retournée (cette erreur générique indique que le ticket a été modifié au cours de son transport ou qu'il n'est pas « décodable »). Cette erreur est également loguée dans l'observateur d'événement

  • Si vous ne déclarez pas explicitement un SPN, l'authentification Kerberos fonctionnera uniquement si l'application pool tourne sous l'identité « Network Service ». Dans ce cas de figure, le ticket Kerberos est bâti en utilisant le SPN par défaut qui est créé dans Active Directory lorsqu'une machine (ici, le serveur IIS) est ajoutée dans le domaine. Ce « SPN par défaut » est associé au compte machine, qui, sous IIS, correspond au compte « Network Service ».

    Si vous souhaitez utiliser une autre identité que « Network Service », il vous faudra déclarer un SPN (à l'aide de l'utilitaire SETSPN) et associer un compte utilisateur à ce SPN. Une erreur courante consiste à créer des SPNs identiques avec des comptes différents. Par exemple, dans le cas où un site IIS utilise 2 applications pools, il serait naturel de déclarer 2 SPNs :

    SETSPN http/monsiteweb CompteAppPool1,
    SETSPN http/monsiteweb CompteAppPool2

    Malheureusement, une telle configuration ne permettra pas un bon fonctionnement de Kerberos en raison de l'ambigüité sur le compte à utiliser pour chiffrer le ticket Kerberos pour le SPN http/monsiteweb. Techniquement, cette configuration produira des erreurs/évènements de type KRB_AP_ERR_MODIFIED . Pour valider que vous n'êtes pas dans ce cas de figure (SPN dupliqués), vous pouvez utiliser les outils documentés dans cet article : https://support.microsoft.com/kb/321044 ou utiliser une version de SPN pour Windows 2003 qui permet de  détecter les SPNs dupliqués en utilisant la commande setspn –X (https://support.microsoft.com/kb/970536).

    Vous pouvez aussi consulter cette excellente série d'article permettant de diagnostiquer les problèmes Kerberos liés à l'absence ou à une mauvaise utilisation d'un SPN :

  • L'authentification Kerberos échoue-t-elle sous IIS7 alors qu'elle fonctionnait en IIS6 ?

    Sous IIS7, l'authentification Kerberos est réalisée par défaut en mode kernel. Ce changement est décrit en détail dans ce blog : https://www.adopenstatic.com/cs/blogs/ken/archive/2008/02/12/16189.aspx. L'authentification Kerberos en mode kernel présente de multiples avantages :

    • les performances sont accrues

    • le décodage du ticket kerberos est réalisé dans le contexte du compte machine (et non celui de l'application pool « cible »)

      Cela permet donc d'utiliser des applications pools tournant sous des identités différentes sans avoir à déclarer un SPN pour chaque application pool comme c'était le cas sous IIS6

  • Si un SPN a été déclaré avec un compte spécifique via SETSPN, l'authentification Kerberos en mode Kernel posera problème. En effet, le ticket ne doit plus être décrypté dans le contexte du compte machine mais dans celui du compte de l'application pool cible. Ce problème se manifeste plus particulièrement lors de l'utilisation d'une web farm puisque, dans ce scenario, la déclaration d'un SPN associé à un compte de service défini sur le domaine est indispensable.

    Une solution brutale à ce problème consiste à désactiver l'authentification Kerberos en mode Kernel. Une meilleure solution consiste à positionner la propriété useAppPoolCredentials (="true") afin de garder le bénéfice de l'authentification Kerberos en mode kernel tout en permettant le décodage du ticket en utilisant le compte de l'application pool « cible ».

  • Que faire si Kerberos fonctionne mais uniquement pour un temps sur un poste client XP SP2 ?

    Il y a un problème connu de renouvellement de ticket kerberos en XP SP2 qui est corrigé par ce correctif (ou par XP SP3) : https://support.microsoft.com/KB/939850

  • Que faire si Kerberos fonctionne mais uniquement pour un temps sur un poste client ?

    Il existe un problème dans Internet Explorer décrit dans l'article suivant : https://support.microsoft.com/kb/899417 (le correctif nécessite de créer une clé de registre FEATURE_ENSURE_FQDN_FOR_NEGOTIATE_KB899417). Ce problème se manifeste par la « perte » de l'authentification Kerberos après un laps de temps. Le correctif décrit dans cet article est activé de base si vous avez le patch cumulatif MS09-054 sorti le 13.10.2009.

  • Que faire si Kerberos fonctionne mais la délégation ne fonctionne pas ?

    Dans ce scenario, il convient d'abord de :

    • vérifier la zone calculée par Internet Explorer pour l'URL demandée. La délégation Kerberos n'est supportée que si la zone de sécurité est « Sites de confiance » ou «  Intranet » (dans ce cas de figure , IE passe le flag ISC_REQ_DELEGATE lors de l'appel à InitializeSecurityContext)
    • vérifier que le compte utilisé pour l'application pool a le flag « Trusted for delegation »

  • Si la délégation ne fonctionne toujours pas après cette vérification, nous vous recommandons d'utiliser l'outil DELEGCONFIG. Cet outil permet de diagnostiquer toute une liste de problème empêchant le bon fonctionnement de Kerberos. Vous pouvez vous reporter à ce lien pour plus de détails : https://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx

  • Les performances sont-elles correctes ?

    Par défaut, l'authentification Kerberos est « request  based » ce qui signifie qu'elle va s'appliquer à chaque requête http (contrairement à l'authentification NTLM qui est « session based »). Ce comportement peut être pénalisant au niveau des performances. Heureusement, il peut être changé en utilisant la propriété authPersistNonNTLM sous IIS7 ou EnableKerbAuthPersist sous IIS6 (pour plus de précisions, consulter cet article : https://support.microsoft.com/kb/954873).

    Une question souvent négligée lors de la mise en œuvre de l'authentification Kerberos concerne son utilisation à bon escient… Il peut en effet être dommage d'utiliser ce type d'authentification pour récupérer des centaines d'images à l'aide de GET conditionnels de plusieurs kilos octets (puisque chaque requête inclura le ticket Kerberos) pour produire au final des réponses de type « 304 not modified ». De plus, il n'est pas certain qu'un tel choix technique apporte un « plus » en matière de sécurité…

Nous espérons que cette « checklist » vous permettra de mieux identifier la nature d'un problème d'authentification Kerberos dans un contexte IE/IIS. Comme vous pouvez le constater, les points à vérifier sont aussi nombreux que les outils existants !

@Bientôt,

Emmanuel Boersma