Résoudre les problèmes liés aux échecs Kerberos dans Internet Explorer

Cet article vous aide à isoler et à corriger les causes de diverses erreurs lorsque vous accédez à des sites web configurés pour utiliser l’authentification Kerberos dans Internet Explorer. Le nombre de problèmes potentiels est presque aussi important que le nombre d’outils disponibles pour les résoudre.

Symptôme courant lors de l’échec de Kerberos

Vous essayez d’accéder à un site web sur lequel Windows Intégré authentifié a été configuré et que vous prévoyez d’utiliser le protocole d’authentification Kerberos. Dans ce cas, votre navigateur vous invite immédiatement à entrer des informations d’identification, comme suit :

Bien que vous entrez un nom d’utilisateur et un mot de passe valides, vous êtes invité à nouveau (trois invites au total). Ensuite, vous voyez un écran qui indique que vous n’êtes pas autorisé à accéder à la ressource souhaitée. L’écran affiche un code d’état HTTP 401 qui ressemble à l’erreur suivante :

Non autorisé
Erreur HTTP 401. La ressource demandée nécessite l'authentification des utilisateurs.

Sur le serveur Microsoft Internet Information Services (IIS), les journaux du site web contiennent des demandes qui se terminent par un code d’état 401.2, tel que le journal suivant :

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Ou, l’écran affiche un code d’état 401.1, tel que le journal suivant :

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Déterminer si Kerberos est utilisé

Lorsque vous résolvez les problèmes d’authentification Kerberos, nous vous recommandons de simplifier la configuration au minimum. Autrement dit, un client, un serveur et un site IIS qui s’exécute sur le port par défaut. En outre, vous pouvez suivre certaines étapes de dépannage de base. Par exemple, utilisez une page de test pour vérifier la méthode d’authentification utilisée. Si vous utilisez ASP.NET, vous pouvez créer cette page de test d’authentification ASP.NET.

Si vous utilisez ASP classique, vous pouvez utiliser la page Testkerb.asp suivante :

<%
    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"
%>

Vous pouvez également utiliser les outils suivants pour déterminer si Kerberos est utilisé :

• Fiddler
• HttpWatch
• Moniteur réseau
• Outils de développement dans votre navigateur

Pour plus d’informations sur la façon dont ces traces peuvent être générées, consultez le suivi côté client.

Lorsque Kerberos est utilisé, la requête envoyée par le client est volumineuse (plus de 2 000 octets), car l’en-tête HTTP_AUTHORIZATION inclut le ticket Kerberos. La demande suivante concerne une page qui utilise l’authentification Windows basée sur Kerberos pour authentifier les utilisateurs entrants. La taille de la requête GET est supérieure à 4 000 octets.

Si l’établissement d’une liaison NTLM est utilisé, la requête sera beaucoup plus petite. La capture côté client suivante montre une demande d’authentification NTLM. La requête GET est beaucoup plus petite (moins de 1 400 octets).

Après avoir déterminé que l’authentification Kerberos échoue, vérifiez chacun des éléments suivants dans l’ordre donné.

Éléments à vérifier si l’authentification Kerberos échoue

Les sections suivantes décrivent les éléments que vous pouvez utiliser pour vérifier si l’authentification Kerberos échoue.

Le client et le serveur se trouvent dans le même domaine

L’utilisation de Kerberos nécessite un domaine, car un ticket Kerberos est remis par le contrôleur de domaine (DC). Les scénarios avancés sont également possibles dans les cas suivants :

• Le client et le serveur ne se trouvent pas dans le même domaine, mais dans deux domaines de la même forêt.
• Le client et le serveur se trouvent dans deux forêts différentes.

Ces scénarios possibles sont abordés dans la section Pourquoi la délégation Kerberos échoue-t-elle entre mes deux forêts, bien qu’elle soit utilisée pour la section de travail de cet article.

IIS configuré pour utiliser l’authentification intégrée

L’authentification intégrée est activée dans Internet Explorer

L’URL utilisée est-elle résolue en zone de sécurité pour laquelle les informations d’identification peuvent être envoyées

Exécutez toujours cette vérification pour les sites suivants :

• Sites correspondant à la zone Intranet local du navigateur.
• Sites dans la zone Sites approuvés.

Vous pouvez vérifier la zone dans laquelle votre navigateur décide d’inclure le site. Pour ce faire, ouvrez le menu Fichier d’Internet Explorer, puis sélectionnez Propriétés. La fenêtre Propriétés affiche la zone dans laquelle le navigateur a décidé d’inclure le site auquel vous accédez.

Vous pouvez vérifier si la zone dans laquelle le site est inclus autorise l’ouverture de session automatique. Pour ce faire, ouvrez le menu Options Internet d’Internet Explorer, puis sélectionnez l’onglet Sécurité . Après avoir sélectionné la zone souhaitée, sélectionnez le bouton Niveau personnalisé pour afficher les paramètres et vérifiez que l’ouverture de session automatique est sélectionnée. (En règle générale, cette fonctionnalité est activée par défaut pour les zones Intranet et Sites approuvés).

Le serveur IIS est-il configuré pour envoyer l’en-tête WWW-Authenticate : Negotiate

Si IIS n’envoie pas cet en-tête, utilisez la console du Gestionnaire IIS pour définir l’en-tête Negotiate via la propriété de configuration NTAuthenticationProviders . Pour plus d’informations, consultez fournisseurs <>d’authentification Windows. Vous pouvez accéder à la console via le paramètre Fournisseurs des détails de l’authentification Windows dans le gestionnaire IIS.

Le client et le serveur sont-ils installés sur le même ordinateur

Par défaut, Kerberos n’est pas activé dans cette configuration. Pour modifier ce comportement, vous devez définir la clé de DisableLoopBackCheck Registre. Pour plus d’informations, consultez la base de connaissances 926642.

Le client peut-il obtenir un ticket Kerberos

Vous pouvez utiliser l’outil KLIST (Kerberos List) pour vérifier que l’ordinateur client peut obtenir un ticket Kerberos pour un nom de principal de service donné. Dans cet exemple, le nom du principal de service (SPN) est http/web-server.

Lorsque la demande de ticket Kerberos échoue, l’authentification Kerberos n’est pas utilisée. La secours NTLM peut se produire, car le SPN demandé est inconnu du contrôleur de domaine. Si le contrôleur de domaine est inaccessible, aucun NTLM ne se produit.

Pour déclarer un SPN, consultez l’article suivant :

Comment utiliser des SPN lorsque vous configurez des applications web hébergées sur Internet Information Services.

Le serveur web utilise-t-il un port autre que la valeur par défaut (80)

Par défaut, Internet Explorer n’inclut pas les informations de numéro de port dans le SPN utilisé pour demander un ticket Kerberos. Il peut s’agir d’un problème si vous utilisez IIS pour héberger plusieurs sites sous différents ports et identités. Dans cette configuration, l’authentification Kerberos peut fonctionner uniquement pour des sites spécifiques, même si tous les SPN ont été correctement déclarés dans Active Directory. Pour résoudre ce problème, vous devez définir la valeur de FEATURE_INCLUDE_PORT_IN_SPN_KB908209 Registre. (Voir le Section clés de fonctionnalité Internet Explorer pour plus d’informations sur la déclaration de la clé.) Ce paramètre force Internet Explorer à inclure le numéro de port dans le SPN utilisé pour demander le ticket Kerberos.

Internet Explorer utilise-t-il le SPN attendu

Si un site web est accessible à l’aide d’un nom d’alias (CNAME), Internet Explorer utilise d’abord la résolution DNS pour résoudre le nom d’alias en nom d’ordinateur (ANAME). Le nom de l’ordinateur est ensuite utilisé pour générer le SPN et demander un ticket Kerberos. Même si l’URL entrée dans la barre d’adresses Internet Explorer est http://MYWEBSITE, Internet Explorer demande un SPN pour HTTP/MYSERVER si MYWEBSITE est un alias (CNAME) de MYSERVER (ANAME). Vous pouvez modifier ce comportement à l’aide de la clé de FEATURE_USE_CNAME_FOR_SPN_KB911149 Registre. (Voir le Clés de fonctionnalité Internet Explorer pour plus d’informations sur la déclaration de la clé.)

Une trace network Monitor est une bonne méthode pour vérifier le SPN associé au ticket Kerberos, comme dans l’exemple suivant :

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

L’identité du pool d’applications correspond-elle au compte associé au SPN

Lorsqu’un ticket Kerberos est envoyé d’Internet Explorer à un serveur IIS, le ticket est chiffré à l’aide d’une clé privée. La clé privée est un hachage du mot de passe utilisé pour le compte d’utilisateur associé au spN. Par conséquent, seule une application qui s’exécute sous ce compte peut décoder le ticket.

La procédure suivante est un résumé de l’algorithme d’authentification Kerberos :

1. Internet Explorer détermine un SPN à l’aide de l’URL entrée dans la barre d’adresses.

2. Le SPN est transmis via une API SSPI (Security Support Provider Interface) (InitializeSecurityContext) au composant système chargé de la sécurité Windows (le processus LSASS (Local Security Authority Subsystem Service). À ce stade, vous pouvez voir que le code Internet Explorer n’implémente aucun code pour construire le ticket Kerberos. Internet Explorer appelle uniquement les API SSPI.

3. LSASS utilise le SPN passé pour demander un ticket Kerberos à un contrôleur de domaine. Si le contrôleur de domaine peut traiter la requête (SPN connu), il crée un ticket Kerberos. Ensuite, il chiffre le ticket à l’aide d’une clé construite à partir du hachage du mot de passe du compte d’utilisateur pour le compte associé au spN. LSASS envoie ensuite le ticket au client. En ce qui concerne Internet Explorer, le ticket est un objet blob opaque.

4. Internet Explorer encapsule le ticket Kerberos fourni par LSASS dans l’en-tête Authorization: Negotiate , puis il envoie le ticket au serveur IIS.

5. IIS gère la requête et l’achemine vers le pool d’applications approprié à l’aide de l’en-tête de l’hôte spécifié.

6. Le pool d’applications tente de déchiffrer le ticket à l’aide des API SSPI/LSASS et en suivant les conditions suivantes :

   • Si le ticket peut être déchiffré, l’authentification Kerberos réussit. Tous les services associés au ticket (emprunt d’identité, délégation si le ticket l’autorise, et ainsi de suite) sont disponibles.

   • Si le ticket ne peut pas être déchiffré, une erreur Kerberos (KRB_AP_ERR_MODIFIED) est retournée. Cette erreur est une erreur générique qui indique que le ticket a été modifié d’une certaine manière pendant son transport. Le ticket ne peut donc pas être déchiffré. Cette erreur est également consignée dans les journaux des événements Windows.

Si vous ne déclarez pas explicitement un SPN, l’authentification Kerberos fonctionne uniquement sous l’une des identités de pool d’applications suivantes :

• Service réseau
• ApplicationPoolIdentity
• Un autre compte système, tel que LOCALSYSTEM ou LOCALSERVICE

Mais ces identités ne sont pas recommandées, car elles sont un risque de sécurité. Dans ce cas, le ticket Kerberos est généré à l’aide d’un SPN par défaut créé dans Active Directory lorsqu’un ordinateur (dans ce cas, le serveur sur lequel IIS s’exécute) est ajouté au domaine. Ce SPN par défaut est associé au compte d’ordinateur. Sous IIS, le compte d’ordinateur est mappé au service réseau ou ApplicationPoolIdentity.

Si votre pool d’applications doit utiliser une identité autre que les identités répertoriées, déclarez un SPN (à l’aide de SETSPN). Ensuite, associez-le au compte utilisé pour l’identité de votre pool d’applications. Une erreur courante consiste à créer des SPN similaires qui ont des comptes différents. Par exemple :

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite UserAppPool2

Cette configuration ne fonctionnera pas, car il n’existe aucun moyen déterministe de savoir si le ticket Kerberos pour le SPN http/mywebsite sera chiffré à l’aide du mot de passe UserAppPool1 ou UserAppPool2. Cette configuration génère généralement des erreurs KRB_AP_ERR_MODIFIED. Pour déterminer si vous êtes dans ce scénario de SPN en double incorrect, utilisez les outils documentés dans l’article suivant :

Pourquoi vous pouvez toujours avoir des spN en double dans AD 2012 R2 et AD 2016

À partir de Windows Server 2008, vous pouvez également utiliser une version mise à jour de SETSPN pour Windows qui permet la détection des SPN dupliqués à l’aide de la setspn –X commande lorsque vous déclarez un nouveau SPN pour votre compte cible. Pour plus d’informations, consultez Setspn.

Nous vous recommandons également de consulter les articles suivants :

• Problèmes d’authentification Kerberos – Problèmes de nom de principal de service (SPN) - Partie 1

• Problèmes d’authentification Kerberos – Problèmes de nom de principal de service (SPN) - Partie 2

• Problèmes d’authentification Kerberos – Problèmes de nom de principal de service (SPN) - Partie 3

L’authentification Kerberos échoue-t-elle dans IIS 7 et versions ultérieures, même si elle fonctionne dans IIS 6

L’authentification en mode noyau est une fonctionnalité introduite dans IIS 7. Elle offre les avantages suivants :

• Les performances sont augmentées, car les transitions en mode noyau vers utilisateur ne sont plus effectuées.
• Le décodage de ticket Kerberos est effectué à l’aide du compte d’ordinateur et non de l’identité du pool d’applications. Cette modification vous permet d’avoir plusieurs pools d’applications s’exécutant sous différentes identités sans avoir à déclarer de SPN.

Pourquoi la délégation échoue-t-elle bien que l’authentification Kerberos fonctionne

Dans ce scénario, consultez les éléments suivants :

• Zone Internet Explorer utilisée pour l’URL. La délégation Kerberos est autorisée uniquement pour les zones Intranet et Sites approuvés. (En d’autres termes, Internet Explorer définit l’indicateur ISC_REQ_DELEGATE lorsqu’il appelle InitializeSecurityContext uniquement si la zone déterminée est intranet ou sites approuvés.)

• Le compte d’utilisateur du pool d’applications IIS hébergeant votre site doit avoir l’indicateur approuvé pour la délégation défini dans Active Directory.

Si la délégation échoue toujours, envisagez d’utiliser Kerberos Configuration Manager pour IIS. Cet outil vous permet de diagnostiquer et de corriger les configurations IIS pour l’authentification Kerberos et pour les SPN associés sur les comptes cibles. Pour plus d’informations, consultez la README.md. Vous pouvez télécharger l’outil ici.

Pourquoi obtenir des performances incorrectes quand j’utilise l’authentification Kerberos

Kerberos est un protocole d’authentification basé sur les demandes dans les versions antérieures de Windows Server, telles que Windows Server 2008 SP2 et Windows Server 2008 R2. Cela signifie que le client doit envoyer le ticket Kerberos (qui peut être un objet blob volumineux) avec chaque requête effectuée au serveur. Il est contraire aux méthodes d’authentification qui s’appuient sur NTLM. Par défaut, NTLM est basé sur une session. Cela signifie que le navigateur n’authentifie qu’une seule requête lorsqu’il ouvre la connexion TCP au serveur. Chaque demande suivante sur la même connexion TCP ne nécessite plus d’authentification pour que la demande soit acceptée. Dans les versions plus récentes d’IIS, à partir de Windows 2012 R2, Kerberos est également basé sur une session. Seule la première requête sur une nouvelle connexion TCP doit être authentifiée par le serveur. Les demandes suivantes n’ont pas besoin d’inclure un ticket Kerberos.

Vous pouvez modifier ce comportement à l’aide de la propriété authPersistNonNTLM si vous exécutez sous IIS 7 et versions ultérieures. Si la propriété est définie sur true, Kerberos devient basé sur une session. Sinon, elle sera basée sur la demande. Il aura des performances pires, car nous devons inclure une plus grande quantité de données à envoyer au serveur à chaque fois. Pour plus d’informations, consultez l’authentification Kerberos basée sur la requête et la session (ou le paramètre AuthPersistNonNTLM).

Pourquoi la délégation Kerberos échoue-t-elle entre mes deux forêts bien qu’elle fonctionne

Examinez le cas suivant :

• Les utilisateurs de votre application se trouvent dans un domaine à l’intérieur de la forêt A.
• Votre application se trouve dans un domaine à l’intérieur de la forêt B.
• Vous avez une relation d’approbation entre les forêts.

Dans ce scénario, la délégation Kerberos peut cesser de fonctionner, même si elle était utilisée pour fonctionner précédemment et que vous n’avez apporté aucune modification aux forêts ou domaines. L’authentification Kerberos fonctionne toujours dans ce scénario. Seule la délégation échoue.

Ce problème peut se produire en raison des mises à jour de sécurité de Windows Server publiées par Microsoft en mars 2019 et juillet 2019. Ces mises à jour ont désactivé la délégation Kerberos non contrainte (la possibilité de déléguer un jeton Kerberos d’une application à un service back-end) entre les limites de forêt pour toutes les approbations nouvelles et existantes. Pour plus d’informations, consultez Mises à jour de la délégation TGT sur les approbations entrantes dans Windows Server.

Clés de fonctionnalité Internet Explorer

Ces clés sont des clés de Registre qui activent ou désactivent certaines fonctionnalités du navigateur. Les clés se trouvent dans les emplacements de Registre suivants :

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – s’il est défini au niveau de l’utilisateur
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - s’il est défini au niveau de l’ordinateur

Les clés de fonctionnalité doivent être créées à l’un de ces emplacements, selon que vous souhaitez activer ou désactiver la fonctionnalité :

• pour tous les utilisateurs sur l’ordinateur
• pour un compte spécifique uniquement

Ces clés doivent être créées sous le chemin d’accès respectif. Dans la clé, une valeur DWORD nommée iexplorer.exe doit être déclarée. La valeur par défaut de chaque clé doit être true ou false, selon le paramètre souhaité de la fonctionnalité. Par défaut, la valeur des deux clés de fonctionnalité et FEATURE_USE_CNAME_FOR_SPN_KB911149, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 est false. Pour obtenir une précision, voici un exemple d’exportation du Registre en activant la clé de fonctionnalité pour inclure des numéros de port dans le ticket Kerberos sur true :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Plus d’informations

Pages de diagnostic pour la résolution des problèmes liés à l’authentification intégrée Windows