Résoudre les échecs Kerberos dans Internet Explorer

Cet article vous aide à isoler et à résoudre 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 en cas d’échec de Kerberos

Vous essayez d’accéder à un site web où Windows Integrated Authenticated a été configuré et 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 :

Capture d’écran de l’invite d’informations d’identification.

Bien que vous entrez un nom d’utilisateur et un mot de passe valides, vous êtes à nouveau invité (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 HTTP 401 status qui ressemble à l’erreur suivante :

Non autorisé
Erreur HTTP 401. La ressource demandée nécessite une authentification utilisateur.

Capture d’écran de l’erreur 401.

Sur le serveur Microsoft Internet Information Services (IIS), les journaux du site web contiennent des demandes qui se terminent par un code status 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 bien, l’écran affiche un code status 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 un échec 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
  • Les 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 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.

Capture d’écran des demandes de plus de 4 000 octets.

Si l’établissement de 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).

Capture d’écran des demandes inférieures à 1 400 octets.

Une fois que vous avez déterminé que l’authentification Kerberos échoue, case activée chacun des éléments suivants dans l’ordre donné.

Éléments à case activée en cas d’échec de l’authentification Kerberos

Les sections suivantes décrivent les éléments que vous pouvez utiliser pour case activée en cas d’échec de l’authentification Kerberos.

Le client et le serveur se trouvent-ils 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). Des scénarios avancés sont également possibles dans les cas suivants :

  • Le client et le serveur ne sont 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 décrits dans la section Pourquoi la délégation Kerberos échoue-t-elle entre mes deux forêts, même si elle était utilisée pour fonctionner de cet article.

Iis est-il configuré pour utiliser l’authentification intégrée ?

Capture d’écran du paramètre Authentification Windows.

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

Sélectionnez l’option Activer l’authentification Windows intégrée dans la page Options Internet.

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 case activée pour les sites suivants :

  • Sites correspondant à la zone Intranet local du navigateur.
  • Sites dans la zone Sites de confiance.

Vous pouvez case activée dans quelle zone 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 vers lequel vous naviguez.

Vérifiez la zone dans propriétés d’Internet Explorer.

Vous pouvez case activée 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érifier que l’option 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 de confiance).

Vérifiez si l’option Ouverture de session automatique est sélectionnée.

Remarque

Même si cette configuration n’est pas courante (car elle nécessite que le client ait accès à un contrôleur de domaine), Kerberos peut être utilisé pour une URL dans la zone Internet. Dans ce cas, sauf si les paramètres par défaut sont modifiés, le navigateur invite toujours l’utilisateur à fournir des informations d’identification. La délégation Kerberos ne fonctionne pas dans la zone Internet. En effet, Internet Explorer autorise la délégation Kerberos uniquement pour une URL dans les zones Intranet et Sites de confiance.

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

Vérifiez si le serveur IIS a 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 de 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.

Paramètres des fournisseurs dans l’authentification.

Remarque

Par défaut, la propriété NTAuthenticationProviders n’est pas définie. Cela entraîne l’envoi d’en-têtes Negotiate et Windows NT LAN Manager (NTLM).

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 kb 926642.

Le client peut-il obtenir un ticket Kerberos

Vous pouvez utiliser l’outil Liste Kerberos (KLIST) 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.

Remarque

KLIST est un outil Windows natif depuis Windows Server 2008 pour les systèmes d’exploitation côté serveur et Windows 7 Service Pack 1 pour les systèmes d’exploitation côté client.

Utilisez l’outil KLIST pour vérifier que l’ordinateur client peut obtenir un ticket Kerberos pour un nom de principal de service donné.

Lorsque la demande de ticket Kerberos échoue, l’authentification Kerberos n’est pas utilisée. Le 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 secours 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 celui 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. Cela peut être 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. (Pour plus d’informations sur la déclaration de la clé, consultez la section Clés de fonctionnalité Internet Explorer.) Ce paramètre force les Explorer Internet à 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 de l’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. (Pour plus d’informations sur la façon de déclarer la clé, consultez Clés de fonctionnalité Internet Explorer.)

Une trace du moniteur réseau est une bonne méthode pour case activée 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é à partir 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. Ainsi, 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 responsable de la sécurité Windows (processus LSASS (Local Security Authority Subsystem Service). À ce stade, vous pouvez voir que le code Explorer Internet n’implémente aucun code pour construire le ticket Kerberos. Internet Explorer appelle uniquement les API SSPI.

  3. LSASS utilise le SPN transmis 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é qui est 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 les Explorer Internet, le ticket est un objet blob opaque.

  4. Internet Explorer encapsule le ticket Kerberos fourni par LSASS dans l’en-têteAuthorization: Negotiate, puis 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 d’hôte spécifié.

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

    • 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 le permet, etc.) 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 manière ou d’une autre 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 de 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

Toutefois, ces identités ne sont pas recommandées, car elles constituent un risque pour la 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é à 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 noms de principal de service en double incorrects, utilisez les outils décrits 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 en double à 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 :

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

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

  • Les performances sont accrues, car les transitions en mode noyau vers mode 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.

Avertissement

Si un SPN a été déclaré pour un compte d’utilisateur spécifique (également utilisé comme identité de pool d’applications), l’authentification en mode noyau ne peut pas déchiffrer le ticket Kerberos, car elle utilise le compte d’ordinateur. Ce problème est typique dans les scénarios de batterie de serveurs web. Ce scénario déclare généralement un SPN pour le nom d’hôte NLB (virtuel). Pour éviter ce problème, utilisez l’une des méthodes suivantes :

  • Désactivez l’authentification en mode noyau. (Non recommandé du point de vue des performances.)
  • Définissez useAppPoolCredentials sur true. Cela permet de conserver l’avantage en termes de performances de l’authentification en mode noyau, tout en permettant au ticket Kerberos d’être décodé sous l’identité du pool d’applications. Pour plus d’informations, consultez Authentification <>de sécurité.

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

Dans ce scénario, case activée les éléments suivants :

  • Zone Explorer Internet utilisée pour l’URL. La délégation Kerberos est autorisée uniquement pour les zones Intranet et Sites de confiance. (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 de confiance.)

  • L’indicateur De délégation approuvé pour le compte d’utilisateur du pool d’applications IIS hébergeant votre site doit être défini dans Active Directory.

Si la délégation échoue toujours, envisagez d’utiliser le Configuration Manager Kerberos 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 les performances sont-elles médiocres lorsque j’utilise l’authentification Kerberos ?

Kerberos est un protocole d’authentification basé sur les requêtes 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 assez volumineux) avec chaque requête effectuée sur le serveur. C’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 requête 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 requêtes suivantes n’ont pas besoin d’inclure de 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é a la valeur true, Kerberos devient basé sur une session. Dans le cas contraire, il sera basé sur les requêtes. Il aura des performances moins bonnes, car nous devons inclure une plus grande quantité de données à envoyer au serveur à chaque fois. Pour plus d’informations, consultez Authentification Kerberos basée sur la requête et l’authentification Basée sur la session (ou le paramètre AuthPersistNonNTLM).

Remarque

Il n’est peut-être pas judicieux d’utiliser aveuglément l’authentification Kerberos sur tous les objets. L’utilisation de l’authentification Kerberos pour extraire des centaines d’images à l’aide de requêtes GET conditionnelles qui génèrent probablement des réponses 304 non modifiées revient à essayer de tuer une mouche à l’aide d’un marteau. Une telle méthode n’offre pas non plus de gains de sécurité évidents.

Pourquoi la délégation Kerberos échoue-t-elle entre mes deux forêts alors qu’elle fonctionnait auparavant

Prenons l’exemple du scénario 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 fonctionnait précédemment et que vous n’avez apporté aucune modification aux forêts ou aux 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 sans contrainte (la possibilité de déléguer un jeton Kerberos d’une application à un service principal) au-delà des limites de forêt pour toutes les approbations nouvelles et existantes. Pour plus d’informations, consultez Mises à jour à 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 – si défini au niveau de l’utilisateur
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - si défini au niveau de l’ordinateur

Les clés de fonctionnalité doivent être créées dans 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. À l’intérieur de 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 être complet, voici un exemple d’exportation du Registre en activant la clé de fonctionnalité pour inclure les 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 d’authentification intégrée Windows