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

2025-01-15

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

Numéro de 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 - Demande incorrecte (en-tête de requête trop long) . L’utilisateur a é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 les réponses de requête incorrecte HTTP 400 (en-tête de requête trop longue) aux requêtes HTTP.

Note

Dans des conditions similaires, l’authentification Windows NTLM fonctionne comme prévu. Vous ne voyez peut-être pas le problème d’authentification Kerberos, sauf si vous analysez le comportement de Windows. Toutefois, dans de tels scénarios, Windows peut ne pas être en mesure de mettre à jour les paramètres de stratégie de groupe.

Ce comportement se produit dans l’une des versions de Windows actuellement prises en charge. Pour plus d’informations sur les versions actuellement prises en charge de Windows, consultez la feuille de fait du 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 suffisamment grand pour contenir toutes les appartenances de groupe 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 appartient l’utilisateur. 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 TGT (Ticket-Getting Ticket) Kerberos. À compter de Windows Server 2012, Kerberos stocke également le jeton dans la structure de données Des revendications Active Directory (contrôle d’accès dynamique) dans le 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 s’appuient 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, selon 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, 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 de mémoire tampon suffisamment importante pour contenir les informations. L’utilisateur ne peut pas s’authentifier et peut recevoir un message hors mémoire . De plus, Windows peut ne pas être en mesure d’appliquer les paramètres de stratégie de groupe pour l’utilisateur.

Note

D’autres facteurs affectent également le nombre maximal de groupes. Par exemple, les SID pour les groupes globaux et locaux de domaine ont des besoins en espace plus petits. Windows Server 2012 et versions ultérieures ajoutent des informations de revendication au ticket Kerberos et compressent également les SID de ressources. Les deux fonctionnalités modifient les besoins en espace.

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.

Important

De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre pour la restauration, au cas où des problèmes se produisent.

Sur chacun de ces ordinateurs, définissez l’entrée de MaxTokenSize Registre sur une valeur supérieure. 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, MaxTokenSizeconsultez la section Calcul de la taille maximale des jetons de cet article.

Par exemple, considérez 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 MaxTokenSize de Registre sur chacun des ordinateurs suivants :

Ordinateur client exécutant Internet Explorer
Serveur web en cours d’exécution qui exécute IIS
Ordinateur client SQL Server
Ordinateur de base de données SQL Server

Dans Windows Server 2012 (et versions ultérieures), Windows peut consigner un événement (ID d’événement 31) si la taille du jeton passe un certain seuil. Pour activer ce comportement, vous devez configurer le paramètre de stratégie de groupe Configuration ordinateur\Modèles d’administration\System\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 versions ultérieures), cette formule définit ses composants comme suit :

1200. Valeur estimée de la surcharge 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 dans le 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 versions antérieures utilisent la même formule. Toutefois, ces versions considèrent le nombre d’appartenances à un groupe local de domaine à faire partie de la valeur d au lieu de la valeur s .

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

Si vous utilisez un niveau de confiance 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 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.
- Le contrôle d’accès dynamique ajoute des revendications Active Directory au ticket, ce qui augmente les exigences de taille. Toutefois, après avoir déployé des revendications avec des serveurs de fichiers Windows Server 2012, 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 Contrôle d’accès dynamique : Vue d’ensemble du scénario.
Si vous avez configuré Kerberos pour utiliser la délégation non contrainte, vous devez doubler la TokenSize valeur de la formule pour obtenir une estimation MaxTokenSizevalide .

Important

En 2019, Microsoft a fourni des mises à jour à Windows qui ont modifié la configuration par défaut de la délégation non contrainte pour que Kerberos soit désactivée. Pour plus d’informations, consultez Mises à jour de 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 non contrainte est déconseillée, MaxTokenSize de 48 000 ou plus doit être suffisante pour tous les scénarios.

Problèmes connus qui affectent MaxTokenSize

La 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 grande, 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 à celui d’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 de MaxTokenSize Registre sur une valeur supérieure à 48 000 octets et que l’espace 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é les valeurs allant jusqu’à 100 000 octets pour MaxTokenSize. Toutefois, nous avons constaté que les versions de l’administrateur SMS rencontrent des problèmes lorsque la taille MaxTokenSize est de 100 000 octets ou plus.

Nous avons également identifié que le protocole IPSEC IKE n’autorise pas un objet BLOB de sécurité à devenir supérieur à 66 536 octets et qu’il échouerait également lorsqu’il MaxTokenSize est défini sur une valeur plus grande.