Gonflement du jeton Kerberos : MaxTokenSize et groupes

Qu'est-ce que le gonflement du jeton Kerberos ?

Le diagnostic du gonflement du jeton Kerberos et de MaxTokenSize commence par une distinction : le nombre de personnes dans un groupe diffère du nombre de SID de groupes portés pour une personne. La prolifération des groupes peut devenir un problème de disponibilité de l'authentification, mais un constat de groupe volumineux ne suffit pas à le diagnostiquer. Une investigation utile relie l'identité concernée, le service en échec, le contexte d'autorisation et les limites sur le chemin d'authentification de ce service.

Un nettoyage d'urgence introduit un second problème. Supprimer des appartenances jusqu'à ce qu'une application fonctionne de nouveau modifie les accès sans établir quelles permissions ou restrictions ont été retirées. Certaines suppressions réduisent des privilèges inutiles ; d'autres interrompent un travail nécessaire. Une suppression peut aussi affaiblir un contrôle si l'appartenance apportait une restriction. Le résultat de sécurité dépend du rôle réel du groupe, pas du raccourcissement de la liste des appartenances.

Ce guide traite les imbrications circulaires et les groupes intégrés modifiés comme des signaux à examiner dans cette investigation. Il ne présente ni panne observée ni incident de sécurité mesuré. L'objectif est une réparation qui rétablit le processus concerné tout en préservant les accès et les refus approuvés.

Fonctionnement : PAC, MaxTokenSize et limites distinctes

Le TGT Kerberos transporte des données d'autorisation dans son Privilege Attribute Certificate (PAC) : SID de l'utilisateur, des groupes et de sIDHistory. Les revendications et la compression des SID influencent aussi l'espace requis. Ce sont les octets résultants qui comptent ; le nombre de membres directs est une autre mesure. Microsoft KB327825 explique ce mécanisme.

KB837361 documente le paramètre de registre MaxTokenSize :

La section des problèmes connus de KB327825 identifie séparément une limite du jeton d'accès LSA de 1 010 SID de groupes, qui concerne Kerberos ou NTLM. Augmenter MaxTokenSize ne supprime pas cette limite distincte. KB327825, problèmes connus.

KB938118 indique 65 535 octets comme valeur maximale autorisée, mais déconseille les valeurs supérieures à 48 000, car l'encodage HTTP Base64 augmente le volume des données d'authentification. Traitez le maximum autorisé et un réglage opérationnel approprié comme deux décisions distinctes. Augmenter une valeur de registre ne supprime pas toutes les contraintes en aval.

L'imbrication circulaire est un problème de graphe

Supposons que le groupe A contienne le groupe B et que le groupe B contienne le groupe A. Un parcours personnalisé qui revisite les nœuds sans en garder la trace peut boucler ou compter plusieurs fois les mêmes visites. C'est une conséquence algorithmique, pas une affirmation sur un comportement observé du KDC ou de PowerShell. Revenir au même groupe ne crée pas un nouveau SID unique à chaque visite.

Conservez les relations directes entre groupes lors de l'investigation d'un cycle. Une composante fortement connexe (SCC) identifie un ensemble de groupes qui peuvent s'atteindre mutuellement ; cette topologie aide le responsable de la revue à choisir la relation à supprimer. Un constat de cycle n'établit pas que le PAC d'un utilisateur dépasse MaxTokenSize. Le cycle et un nombre excessif d'appartenances effectives peuvent coexister, mais ils nécessitent des preuves distinctes.

L'imbrication dangereuse de groupes dans Active Directory explique comment un héritage caché crée un chemin vers le Tier 0 et pourquoi la remédiation doit identifier la relation de groupe qui accorde ce privilège. Appliquez cette revue des chemins lors de la simplification des appartenances, afin que la réparation de la disponibilité préserve aussi la frontière de privilèges prévue.

Symptômes par service et scénario de modification d'urgence

Microsoft documente des réponses HTTP 400 dues à un en-tête de requête trop volumineux, des échecs d'accès aux ressources et des problèmes de mise à jour de la stratégie de groupe utilisateur. Son exemple client/IIS/SQL montre l'importance des machines participantes pour le diagnostic. KB327825, symptômes et résolution.

Utilisez le tableau suivant comme plan d'investigation. Il s'agit de questions à tester, pas de signatures d'erreur supplémentaires ni de preuves que Kerberos échoue aléatoirement.

Si le même utilisateur réussit sur un service et échoue sur un autre, conservez les deux cas. Comparez leurs chemins réels avant de modifier les groupes. Le cas réussi est une preuve diagnostique utile, mais il n'identifie pas la limite applicable au cas en échec. Évitez de remplacer cette comparaison par une affirmation générique de gonflement intermittent du jeton.

Comment supprimer un groupe peut supprimer une restriction

Considérez un exemple conditionnel sur un poste Windows 10/11 couvert par la documentation Microsoft sur le refus d'accès à cet ordinateur depuis le réseau. Un groupe de sécurité dédié porte SeDenyNetworkLogonRight. Le paramètre se trouve sous Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft documente que ce refus Deny prime sur l'autorisation Allow correspondante d'accès réseau et que les modifications d'attribution s'appliquent à la prochaine ouverture de session.

Supposons maintenant qu'un opérateur retire l'utilisateur de ce groupe dans le seul but de réduire ses appartenances. Si c'était le seul chemin de l'utilisateur vers Deny et qu'un Allow subsiste, le prochain contexte d'autorisation perd cette restriction. C'est une déduction conditionnelle issue du comportement documenté de la stratégie, pas un compte rendu d'incident. Elle ne prouve pas que chaque partage ou fichier est désormais accessible : les autres ACL et refus doivent encore être vérifiés. Vérifiez l'applicabilité avant d'étendre cet exemple de poste de travail à d'autres systèmes.

La documentation Microsoft sur les groupes de sécurité explique que les groupes peuvent porter des droits utilisateur aussi bien que des permissions sur les ressources. Avant de supprimer une relation ou un membre, consignez ces deux rôles. Le nom d'un groupe ne suffit pas à décider si la suppression réduit les privilèges, casse un accès nécessaire ou retire une restriction.

La dérive des accès privilégiés dans Active Directory explique comment des exceptions temporaires sans responsables, échéances et revalidation peuvent recréer des droits via les groupes et les ACL. Appliquez la même discipline de référence aux réparations urgentes, surtout lorsqu'un processus en échec conduit à accorder un accès compensatoire.

Détection : recueillir les appartenances, les chemins et le contexte des avertissements

Étape 1 : constituer un dossier pour chaque service concerné

Consignez l'utilisateur, les versions client et serveur, le service/SPN, le MaxTokenSize effectif de chaque participant, la population de groupes/SID, sIDHistory, les revendications ou le contexte de délégation, l'échec exact et tout avertissement pertinent. Préservez les preuves avant toute modification. Distinguez un échec observé d'une estimation, d'un constat de posture de l'annuaire et d'un nouveau test réussi.

L'Event ID 31 peut signaler le franchissement d'un seuil configuré pour les tickets volumineux sur Windows Server 2012 et versions ultérieures. Activez-le via Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets. Ce n'est pas une preuve de dépassement de MaxTokenSize ; corrélez-le au service en échec. KB327825, résolution.

Consignez le seuil d'avertissement réel et l'activation éventuelle de cette stratégie. Le passage source ne fournit pas de seuil numérique universel. L'absence d'avertissement ne constitue pas un résultat de validation du compte.

Étape 2 : inventorier les groupes du principal

La commande suivante est l'exemple 2 de Get-ADPrincipalGroupMembership, cité comme commande documentée. Ces commandes n'ont pas été exécutées dans un environnement AD pour cet article ; remplacez l'identité d'exemple par un compte résolu dans votre périmètre.

Get-ADPrincipalGroupMembership -Identity Administrator

La cmdlet nécessite un catalogue global. Microsoft documente ResourceContextServer pour rechercher des groupes locaux dans un autre domaine. Vérifiez le contexte de la ressource plutôt que de supposer que le domaine du compte décrit à lui seul tout le parcours du service. Les objets groupes retournés servent à l'inventaire ; ils ne mesurent pas les octets du ticket.

Étape 3 : préserver les relations directes avant d'aplatir les résultats

Cette requête d'appartenance directe utilise les paramètres documentés de Get-ADGroupMember :

Get-ADGroupMember -Identity "Enterprise Admins"

À titre de comparaison, l'exemple 4 de Microsoft inclut les membres atteints via les groupes enfants :

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive

Microsoft décrit la sortie récursive comme les membres terminaux de la hiérarchie. Préservez séparément les relations directes pour expliquer un chemin ou un cycle. Une sortie aplatie ne peut pas expliquer à elle seule quelle relation fournit un droit. La documentation signale également une limite pour les membres d'une autre forêt dépourvue d'Active Directory Web Service.

Pour une vue transitive ciblée des SID, Microsoft documente l'attribut calculé tokenGroups (attribut Token-Groups), récupéré par une requête LDAP de portée BASE sur le principal, avec un catalogue global disponible. Cette opération est coûteuse pour les contrôleurs de domaine. Commencez par les comptes concernés plutôt que par des requêtes répétées à grande échelle. Sa population de SID constitue une preuve utile, mais elle ne compte toujours pas les octets du PAC.

Remédiation : simplifier les groupes sans perdre les contrôles approuvés (Remediation)

Étape 1 : établir la référence et le retour arrière

Sauvegardez les appartenances directes, les relations entre groupes et la population transitive des comptes concernés. Consignez les responsables des groupes, les usages des ressources, les droits utilisateur, les restrictions approuvées, les réglages des tampons et les applications touchées. Documentez la modification prévue et un retour arrière avant de supprimer des appartenances. Les commandes précédentes en lecture seule servent à cet inventaire ; elles n'autorisent aucune suppression.

Examinez les groupes intégrés au regard d'une référence organisationnelle tenue à jour. Microsoft documente des fonctions légitimes pour des groupes tels que Event Log Readers, même lorsque leur appartenance par défaut est vide. Un nouveau membre peut être intentionnel. Sans référence tenue à jour, examinez la justification du responsable plutôt que de considérer l'ajout lui-même comme malveillant.

Étape 2 : supprimer les dépendances inutiles et rompre les cycles erronés

Identifiez la relation précise qui crée un cycle ou une dépendance obsolète. Confirmez ses usages avec le responsable, supprimez uniquement la relation approuvée et préservez les permissions et refus nécessaires. Aplatir signifie simplifier l'architecture des groupes ; cela ne signifie pas attribuer chaque utilisateur directement dans l'ACL de chaque ressource.

Séparez les rôles métier des groupes de ressources et attribuez aux deux des responsables et des dates de revue. Vérifiez si la nouvelle conception réduit réellement les appartenances effectives inutiles. Réorganiser les noms de groupes ou leur imbrication sans réduire la population de SID pertinente n'établit pas que le contexte d'authentification a diminué.

Étape 3 : utiliser MaxTokenSize comme mesure provisoire ciblée

Si l'investigation démontre une limite de tampon, envisagez une modification contrôlée de la configuration parallèlement au nettoyage structurel. KB938118 documente la stratégie sous Computer Configuration\Policies\Administrative Templates\System\Kerberos, nommée Set maximum Kerberos SSPI context token buffer size. Elle indique d'activer la stratégie et de saisir 48000. Pour sa procédure de préférence de registre, choisissez REG_DWORD et une saisie décimale.

Comparez d'abord cette valeur à la configuration effective. Définir 48 000 sur une machine utilisant déjà 48 000 n'augmente pas la capacité. Respectez les exigences documentées de redémarrage après application, préservez un retour arrière et examinez les contraintes HTTP. Ne traitez pas 65 535 comme la recommandation par défaut et ne supposez pas qu'une modification du seul contrôleur de domaine résout un chemin à plusieurs participants.

Étape 4 : tester les accès et refus nécessaires

Reconnectez les comptes pilotes et retestez chaque service concerné. Vérifiez les actions métier approuvées, les restrictions qui doivent subsister et les accès compensatoires accordés pendant la panne. Comparez les appartenances et les relations directes avant et après. Observez de nouveau l'échec réel et le contexte des avertissements.

La disparition d'un constat de taille ou de cycle est une preuve utile de posture, mais ce n'est pas un test complet d'acceptation du service. Clôturez la réparation lorsque le processus concerné et le modèle d'accès correspondent tous deux à la cible documentée. Conservez les exceptions avec des responsables et des dates de revue pour confronter les modifications ultérieures à la même référence.

Comment EtcSec détecte ce problème

L'etc-collector d'EtcSec fournit six contrôles pertinents de posture de l'annuaire. Leurs prédicats exacts figurent ci-dessous. Les quatre contrôles de taille comptent les membres directs, pas la taille du jeton. Aucun des six contrôles ne compte les SID de groupes transitifs d'un utilisateur, ne mesure les octets du PAC, ne lit MaxTokenSize ou ne prouve un échec d'authentification.

Le suffixe CRITICAL correspond à une sévérité réelle High, et HIGH à une sévérité réelle Medium. Ces seuils de membres directs sont des règles du collecteur, pas des limites d'authentification Microsoft. Les prédicats de taille ne filtrent pas explicitement les groupes de sécurité par rapport aux groupes de distribution.

Leurs populations se chevauchent : GROUP_EXCESSIVE_MEMBERS couvre à la fois les populations de 101–500 et >500 membres ; OVERSIZED_GROUP_HIGH est un sous-ensemble de OVERSIZED_GROUP. N'additionnez pas leurs nombres comme s'il s'agissait de groupes distincts et ne décrivez pas quatre risques de gonflement du jeton prouvés indépendamment. L'affichage des seuls cinq plus grands groupes dans les détails des membres excessifs ne limite pas le nombre total de constats.

Le contrôle circulaire compte les groupes impliqués, pas les cycles ni les utilisateurs en échec. Son graphe ne conserve que les groupes collectés connus et normalise les noms distinctifs. Un cycle passant par un domaine non collecté peut être manqué. Le résultat situe des relations à examiner, pas la cause d'un échec Kerberos.

Ce que signifie réellement la référence des groupes intégrés

BUILTIN_MODIFIED utilise des recherches exactes sur les noms anglais sAMAccountName. Ses listes non vides acceptent Administrator, Domain Admins et Enterprise Admins pour Administrators ; Domain Users, Authenticated Users et INTERACTIVE pour Users ; Guest et Domain Guests pour Guests.

Ses neuf listes vides couvrent Remote Desktop Users, Network Configuration Operators, Performance Monitor Users, Performance Log Users, Distributed COM Users, IIS_IUSRS, Cryptographic Operators, Event Log Readers et Certificate Service DCOM Access. Un CN extrait dans l'un de ces groupes peut déclencher le contrôle même lorsque l'ajout répond à un travail légitime.

La comparaison accepte une égalité insensible à la casse ou une correspondance de sous-chaîne avec un nom attendu. Elle ignore les DN de membres sans CN extrait et ne vérifie ni le SID ni le conteneur du groupe. Les noms localisés, les renommages, les groupes homonymes et les CN contenant un nom attendu limitent l'interprétation. Elle ne détecte pas les membres attendus manquants, n'inspecte pas les modifications d'ACL et ne compare pas l'historique des changements d'une organisation.

Utilisez ce constat pour demander un responsable, une justification et une comparaison avec la référence locale. La réponse correcte est une décision d'appartenance examinée, pas une purge automatique. Combinez les six constats avec les preuves de service recueillies plus haut pour décider quoi modifier et comment le valider.