Problèmes d'authentification Kerberos lorsqu'un utilisateur appartient à de nombreux groupes

S’applique à : Windows Server 2019, all versionsWindows Server 2016Windows 10 Enterprise

Symptômes


Un utilisateur qui appartient à un grand nombre de groupes de sécurité a 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 a également des problèmes d’accès aux ressources, et les paramètres de stratégie de groupe de l’utilisateur ne peuvent pas mettre à jour correctement.

Pour plus d’informations sur le contexte de l’erreur, consultez le KB2020943, HTTP 400 - Bad Request (demande en-tête trop long) « erreur dans Internet Information Services (IIS).

Ce problème se produit dans une des versions Windows actuellement pris en charge. Pour plus d’informations sur les versions actuellement prises en charge de Windows, consultez la fiche du cycle de vie de Windows.

Cause


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

Dans le cadre du processus d’authentification Kerberos, Windows génère un jeton pour représenter l’utilisateur à des fins d’autorisation. Ce jeton (également appelé un 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 identificateurs SID qui sont stockées dans l’attribut sIDHistory du compte utilisateur. Kerberos stocke ce jeton dans la structure de données du certificat d’attribut de privilège (PAC) dans le Ticket Kerberos obtenir de Ticket (TGT). À partir de Windows Server 2012, Kerberos stocke également le jeton dans la structure de données d’informations (contrôle d’accès dynamique) Active Directory revendications du ticket Kerberos. Si l’utilisateur est membre d’un grand nombre de groupes, et s’il y a de nombreuses demandes pour l’utilisateur ou le périphérique qui est utilisé, ces champs peuvent occuper beaucoup d’espace dans le ticket.

Le jeton a une taille maximale fixe (MaxTokenSize). Transport des protocoles tels que l’appel de procédure distante (RPC) et HTTP utilisent la valeur MaxTokenSize lors de leur allouer les 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 les versions ultérieures, Windows 8 et versions ultérieures : octets 48000

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

Résolution


Pour résoudre ce problème, mettez à jour le Registre sur chaque ordinateur qui fait partie du processus d’authentification Kerberos, y compris les ordinateurs clients. Nous vous recommandons de vous mettre à jour tous vos systèmes Windows, surtout si vos utilisateurs doivent ouvrir une session sur plusieurs domaines ou forêts.

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

Pour plus d’informations sur la définition d’une nouvelle valeur pour MaxTokenSize, voir calcul de la taille de jeton maximale.

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

  • L’ordinateur client qui exécute Internet Explorer
  • Le serveur web qui exécute IIS
  • L’ordinateur client de SQL Server
  • L’ordinateur de base de données SQL Server

Dans Windows Server 2012 (et versions ultérieures), Windows peut consigner un événement (31 d’ID d’événement) si la taille de jeton dépasse un certain seuil. Pour activer ce comportement, vous devez configurer la stratégie de groupe configuration Ordinateur Configuration ordinateur\Modèles de Templates\System\KDC\avertissement pour les tickets Kerberos grands.

Informations supplémentaires


Calcul de la taille de jeton maximale

Utilisez la formule suivante pour calculer la taille du jeton qui génère de Windows pour un utilisateur particulier. Ce calcul permet de déterminer si vous devez changer MaxTokenSize.

TokenSize = 1200 + 40d + 8s

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

  • 1200. La valeur estimée généraux pour obtenir un ticket Kerberos. Cette valeur peut varier en fonction de facteurs tels que la longueur du nom de domaine DNS et de la longueur du nom du client.
  • d. La somme des valeurs suivantes :
    • Le nombre d’appartenances universel à des groupes qui sont en dehors du domaine de l’utilisateur compte.
    • Le nombre de SID stockés dans l’attribut sIDHistory du compte. Cette valeur détermine les identificateurs SID des utilisateurs et appartenances aux groupes.
  • s. La somme des valeurs suivantes :
    • Le nombre d’appartenances universel à des groupes qui se trouvent dans le domaine du compte de l’utilisateur.
    • Le nombre d’appartenances à des groupes de domaine local.
    • Le nombre de membres dans des groupes globaux.

Windows Server 2008 R2 et les versions antérieures utilisent la même formule. Toutefois, ces versions de prendre en compte le nombre d’appartenances aux groupes locaux de domaine faisant partie de ladvaleur à la place de lasvaleur.

Si vous avez une valeur MaxTokenSize 0x0000FFFF (64 K), vous ne pourrez pas la mémoire tampon d’environ 1600d-classe SID ou environ 8000s-classe SID. Toutefois, un certain nombre d’autres facteurs influent sur la valeur que vous pouvez utiliser en toute sécurité pour MaxTokenSize, y compris les éléments suivants :

  • Si vous utilisez des comptes « approuvé pour la délégation », chaque SID nécessite deux fois plus d’espace.
  • Si vous avez plusieurs approbations, configurer les approbations pour filtrer les identificateurs 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 besoins en espace de SID :
    • Il existe un nouveau schéma pour compresser les identificateurs SID dans le PAC. Pour plus d’informations, consultez Compression de KDC ressource SID. Cette fonctionnalité réduit la taille nécessaire pour les identificateurs SID dans le ticket.
    • Contrôle d’accès dynamique ajoute des revendications de Active Directory pour le ticket, l’augmentation de la taille requise. Toutefois, après avoir déployé des revendications avec des serveurs de fichiers Windows Server 2012, vous devriez progressivement un nombre important de groupes qui contrôlent l’accès aux fichiers. Cette réduction peut réduire à son tour de 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 double laTokenSizevaleur de la formule pour obtenir une estimation valide de MaxTokenSize.

Problèmes connus qui affectent MaxTokenSize

La valeur MaxTokenSize 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 les versions ultérieures. Toutefois, si vous décidez d’utiliser une valeur supérieure, passez en revue les problèmes connus dans cette section.

Limite de taille de 1,010 groupe SID du jeton d’accès LSA

Ce problème est similaire dans la mesure où un utilisateur ayant trop d’appartenances ne peut pas s’authentifier, mais les calculs et les conditions qui régissent le problème sont différentes. Par exemple, l’utilisateur peut rencontrer ce problème lors de l’utilisation de l’authentification Kerberos ou l’authentification Windows NTLM. Pour plus d’informations, reportez-vous à la section 328889 de la base de connaissances, ouverture de session d’un compte d’utilisateur qui est 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érieure à 48,000

Pour atténuer un refus de l’attaque par service, Internet Information Server (IIS) utilise une taille de mémoire tampon de demande HTTP limitée de 64 Ko. Un ticket Kerberos qui fait partie d’une requête HTTP est codé en Base64 (six bits de développé à huit bits). Par conséquent, le ticket Kerberos utilise % de 133 de sa taille d’origine. Par conséquent, lorsque la taille maximale du tampon est de 64 Ko dans IIS, le ticket Kerberos permet de 48 000 octets.

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

Pour plus d’informations sur les tailles de mémoire tampon IIS, consultez KB310156, Comment faire pour limiter la taille de l’en-tête de la transmission HTTP qui accepte de IIS à partir d’un client dans Windows 2000

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

Des versions précédentes de cet article décrit les valeurs de 100000 octets pour MaxTokenSize. Toutefois, nous avons constaté que les versions de l’administrateur SMS ont des problèmes lorsque le MaxTokenSize est de 100000 octets ou plus.

Nous avons également identifié que le protocole IPSEC IKE ne permet pas une BLOB plus volumineux que les 66536 octets de sécurité, et il serait également échouer lorsque MaxTokenSize est définie sur une valeur supérieure.