Problèmes liés à l’authentification Kerberos lorsqu’un utilisateur appartient à de nombreux groupes

Cet article vous aide à résoudre les problèmes liés à l’échec de l’authentification Kerberos lorsqu’un utilisateur appartient à de nombreux groupes.

Produits concernés : Windows 10 (toutes les éditions), Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 327825

Symptômes

Un utilisateur qui appartient à un grand nombre de groupes de sécurité rencontre des problèmes d’authentification. Lors de l’authentification, l’utilisateur peut voir un message tel que HTTP 400 - Requête incorrecte (en-tête de requête trop long). L’utilisateur rencontre également des problèmes d’accès aux ressources, et les paramètres de stratégie de groupe de l’utilisateur peuvent ne pas être mis à jour correctement.

Pour plus d’informations sur le contexte de l’erreur, consultez Http 400 Mauvaise requête (en-tête de requête trop long) réponses aux requêtes HTTP.

Ce comportement se produit dans l’une des versions de Windows actuellement prises en charge. Pour plus d’informations sur les versions de Windows actuellement prises en charge, consultez la fiche d’informations sur le cycle de vie Windows.

Cause

L’utilisateur ne peut pas s’authentifier, car le ticket généré par Kerberos pour représenter l’utilisateur n’est pas assez grand pour contenir toutes les appartenances aux groupes de l’utilisateur.

Dans le cadre de l’exchange du service d’authentification, Windows génère un jeton pour représenter l’utilisateur à des fins d’autorisation. Ce jeton (également appelé contexte d’autorisation) inclut les identificateurs de sécurité (SID) de l’utilisateur et les SID de tous les groupes auxquels l’utilisateur appartient. Il inclut également tous les SID stockés dans l’attribut du sIDHistory compte d’utilisateur. Kerberos stocke ce jeton dans la structure de données PAC (Privilege Attribute Certificate) dans le ticket de Ticket-Getting Kerberos (TGT). À compter de Windows Server 2012, Kerberos stocke également le jeton dans la structure de données Informations sur les revendications Active Directory (Access Control dynamique) du ticket Kerberos. Si l’utilisateur est membre d’un grand nombre de groupes et s’il existe de nombreuses revendications pour l’utilisateur ou l’appareil utilisé, ces champs peuvent occuper beaucoup d’espaces dans le ticket.

Le jeton a une taille maximale fixe (MaxTokenSize). Les protocoles de transport tels que l’appel de procédure distante (RPC) et HTTP reposent sur la MaxTokenSize valeur lorsqu’ils allouent des mémoires tampons pour les opérations d’authentification. MaxTokenSize a la valeur par défaut suivante, en fonction de la version de Windows qui génère le jeton :

• Windows Server 2008 R2 et versions antérieures, windows 7 et versions antérieures : 12 000 octets
• Windows Server 2012 et versions ultérieures, et Windows 8 et versions ultérieures : 48 000 octets

En règle générale, si l’utilisateur appartient à plus de 120 groupes universels, la valeur par défaut MaxTokenSize ne crée pas une mémoire tampon suffisamment grande pour contenir les informations. L’utilisateur ne peut pas s’authentifier et peut recevoir un message mémoire insuffisante . En outre, Windows peut ne pas être en mesure d’appliquer stratégie de groupe paramètres pour l’utilisateur.

Résolution

Pour résoudre ce problème, mettez à jour le Registre sur chaque ordinateur qui participe au processus d’authentification Kerberos, y compris les ordinateurs clients. Nous vous recommandons de mettre à jour tous vos systèmes Windows, en particulier si vos utilisateurs doivent se connecter sur plusieurs domaines ou forêts.

Sur chacun de ces ordinateurs, définissez l’entrée de MaxTokenSize Registre sur une valeur plus élevée. Vous trouverez cette entrée dans la HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters sous-clé. Les ordinateurs doivent redémarrer après avoir apporté cette modification.

Pour plus d’informations sur la détermination d’une nouvelle valeur pour MaxTokenSize, consultez la section Calcul de la taille de jeton maximale de cet article.

Par exemple, prenons l’exemple d’un utilisateur qui utilise une application web qui s’appuie sur un client SQL Server. Dans le cadre du processus d’authentification, le client SQL Server transmet le jeton de l’utilisateur à une base de données SQL Server principale. Dans ce cas, vous devez configurer l’entrée de MaxTokenSize Registre sur chacun des ordinateurs suivants :

• L’ordinateur client qui exécute Internet Explorer
• Serveur web exécutant IIS
• Ordinateur client SQL Server
• Ordinateur de base de données SQL Server

Dans Windows Server 2012 (et les versions ultérieures), Windows peut enregistrer un événement (ID d’événement 31) si la taille du jeton dépasse un certain seuil. Pour activer ce comportement, vous devez configurer le paramètre stratégie de groupe Configuration ordinateur\Modèles d’administration\Système\KDC\Avertissement pour les tickets Kerberos volumineux.

Calcul de la taille maximale du jeton

Utilisez la formule suivante pour calculer la taille du jeton généré par Windows pour un utilisateur particulier. Ce calcul vous aide à déterminer si vous devez modifier MaxTokenSize.

TokenSize = 1200 + 40d + 8s

Pour Windows Server 2012 (et les versions ultérieures), cette formule définit ses composants comme suit :

• 1200. Valeur de surcharge estimée pour un ticket Kerberos. Cette valeur peut varier en fonction de facteurs tels que la longueur du nom de domaine DNS et la longueur du nom du client.
• d. Somme des valeurs suivantes :
  • Nombre d’appartenances dans des groupes universels qui se trouvent en dehors du domaine du compte de l’utilisateur.
  • Nombre de SID stockés dans l’attribut du sIDHistory compte. Cette valeur compte les appartenances aux groupes et les SID utilisateur.
• s. Somme des valeurs suivantes :
  • Nombre d’appartenances dans des groupes universels qui se trouvent à l’intérieur du domaine du compte de l’utilisateur.
  • Nombre d’appartenances dans des groupes locaux de domaine.
  • Nombre d’appartenances dans des groupes globaux.

Windows Server 2008 R2 et les versions antérieures utilisent la même formule. Toutefois, ces versions considèrent que le nombre d’appartenances au groupe local de domaine fait partie de la valeur d au lieu de la valeur s .

Si vous avez une MaxTokenSize valeur de 0x0000FFFF (64 Ko), vous pouvez mettre en mémoire tampon environ 1 600 SID de classe d ou environ 8 000 SID de classe s. Toutefois, un certain nombre d’autres facteurs influencent la valeur que vous pouvez utiliser en toute sécurité pour MaxTokenSize, notamment les éléments suivants :

• Si vous utilisez approuvé pour les comptes de délégation, chaque SID nécessite deux fois plus d’espace.

• Si vous avez plusieurs approbations, configurez les approbations pour filtrer les SID. Cette configuration réduit l’impact de la taille du ticket Kerberos.

• Si vous utilisez Windows Server 2012 ou une version ultérieure, les facteurs suivants affectent également les exigences en matière d’espace SID :

  • Il existe un nouveau schéma pour compresser les SID dans le PAC. Pour plus d’informations, consultez Compression du SID de ressource KDC. Cette fonctionnalité réduit la taille nécessaire pour les SID dans le ticket.
  • Dynamique Access Control ajoute des revendications Active Directory au ticket, ce qui augmente les exigences de taille. Toutefois, après avoir déployé des revendications avec Windows Server 2012 serveurs de fichiers, vous pouvez vous attendre à sortir progressivement un nombre important de groupes qui contrôlent l’accès aux fichiers. Cette réduction peut à son tour réduire la taille nécessaire dans le ticket. Pour plus d’informations, consultez Dynamic Access Control : Vue d’ensemble du scénario.

• Si vous avez configuré Kerberos pour utiliser la délégation sans contrainte, vous devez doubler la TokenSize valeur de la formule afin d’obtenir une estimation valide de MaxTokenSize.

  Importante

  En 2019, Microsoft a envoyé des mises à jour à Windows qui ont modifié la configuration par défaut de la délégation sans contrainte pour Kerberos pour la désactiver. Pour plus d’informations, consultez Mises à jour à la délégation TGT sur les approbations entrantes dans Windows Server.

  Étant donné que la compression SID de ressource est largement utilisée et que la délégation sans contrainte est déconseillée, MaxTokenSize une valeur de 48 000 ou plus devrait devenir suffisante pour tous les scénarios.

Problèmes connus qui affectent MaxTokenSize

Une MaxTokenSize valeur de 48 000 octets doit être suffisante pour la plupart des implémentations. Il s’agit de la valeur par défaut dans Windows Server 2012 et versions ultérieures. Toutefois, si vous décidez d’utiliser une valeur plus élevée, passez en revue les problèmes connus dans cette section.

• Limite de taille de 1 010 SID de groupe pour le jeton d’accès LSA

  Ce problème est similaire dans le fait qu’un utilisateur qui a trop d’appartenances à un groupe ne peut pas s’authentifier, mais les calculs et les conditions qui régissent le problème sont différents. Par exemple, l’utilisateur peut rencontrer ce problème lors de l’utilisation de l’authentification Kerberos ou de l’authentification Windows NTLM. Pour plus d’informations, consultez La journalisation sur un compte d’utilisateur membre de plus de 1 010 groupes peut échouer sur un ordinateur Windows Server.

• Problème connu lors de l’utilisation de valeurs de MaxTokenSize supérieures à 48 000

  Pour atténuer un vecteur d’attaque par déni de service, Internet Information Server (IIS) utilise une taille de mémoire tampon de requête HTTP limitée de 64 Ko. Un ticket Kerberos qui fait partie d’une requête HTTP est encodé en Base64 (6 bits étendus à 8 bits). Par conséquent, le ticket Kerberos utilise 133 % de sa taille d’origine. Par conséquent, lorsque la taille maximale de la mémoire tampon est de 64 Ko dans IIS, le ticket Kerberos peut utiliser 48 000 octets.

  Si vous définissez l’entrée MaxTokenSize de Registre sur une valeur supérieure à 48 000 octets et que l’espace de mémoire tampon est utilisé pour les SID, une erreur IIS peut se produire. Toutefois, si vous définissez l’entrée de MaxTokenSize Registre sur 48 000 octets et que vous utilisez l’espace pour les SID et les revendications, une erreur Kerberos se produit.

  Pour plus d’informations sur les tailles de mémoire tampon IIS, consultez Comment limiter la taille d’en-tête de la transmission HTTP acceptée par IIS à partir d’un client dans Windows 2000.

• Problèmes connus lors de l’utilisation de valeurs de MaxTokenSize supérieures à 65 535

  Les versions précédentes de cet article ont abordé des valeurs allant jusqu’à 100 000 octets pour MaxTokenSize. Toutefois, nous avons constaté que les versions de l’administrateur SMS rencontrent des problèmes lorsque le MaxTokenSize est supérieur ou égal à 100 000 octets.

  Nous avons également identifié que le protocole IKE IPSEC n’autorise pas un objet BLOB de sécurité à dépasser 66 536 octets, et qu’il échoue également quand MaxTokenSize est défini sur une valeur plus élevée.