La journalisation sur un compte d’utilisateur membre de plus de 1 010 groupes peut échouer sur un ordinateur Windows Server

Cet article résout un problème où la journalisation sur un compte d’utilisateur membre de plus de 1 010 groupes échoue.

S’applique à : Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Numéro de base de connaissances d’origine : 328889

Symptômes

Lorsqu’un utilisateur tente de se connecter à un ordinateur à l’aide d’un compte d’ordinateur local ou d’un compte d’utilisateur de domaine, la demande d’ouverture de session peut échouer. Vous recevez le message d’erreur suivant :

Message d’ouverture de session : le système ne peut pas vous connecter en raison de l’erreur suivante : lors d’une tentative d’ouverture de session, le contexte de sécurité de l’utilisateur a accumulé trop d’ID de sécurité. Veuillez réessayer ou consulter votre administrateur système.

Le problème se produit lorsque l’utilisateur de connexion est un membre explicite ou transitif d’environ 1 010 groupes de sécurité ou plus.

Les applications et l’ID du journal des événements de sécurité 4625 peuvent afficher ce code d’erreur :

0xc000015a

L’erreur est STATUS_TOO_MANY_CONTEXT_IDS.

Cause

Lorsqu’un utilisateur se connecte à un ordinateur, l’autorité de sécurité locale (LSA, une partie du sous-système de l’autorité de sécurité locale) génère un jeton d’accès. Le jeton représente le contexte de sécurité de l’utilisateur. Le jeton d’accès se compose d’identificateurs de sécurité uniques (SID) pour chaque groupe dont l’utilisateur est membre. Ces SID incluent des groupes transitifs et des valeurs SID à partir de SIDHistory de l’utilisateur et des comptes de groupe.

Le tableau qui contient les SID des appartenances de groupe de l’utilisateur dans le jeton d’accès ne peut contenir pas plus de 1 024 SID. LSA ne peut pas supprimer un SID du jeton. Par conséquent, s’il existe davantage de SID, l’ASA ne parvient pas à créer le jeton d’accès et l’utilisateur ne peut pas se connecter.

Lorsque la liste des SID est générée, le LSA insère également plusieurs SID génériques connus en plus des SID pour les appartenances de groupe de l’utilisateur (évalués transitivement). Par conséquent, si un utilisateur est membre de plus de 1 010 groupes de sécurité personnalisés, le nombre total de SID peut dépasser la limite de 1 024 SID.

La liste des SID personnalisés inclut les éléments suivants :

• Les SID principaux de l’utilisateur/ordinateur et les groupes de sécurité dont le compte est membre.
• LES SID dans l’attribut SIDHistory des groupes dans l’étendue de l’ouverture de session.

Étant donné que l’attribut SIDHistory peut contenir plusieurs valeurs, la limite de 1 024 SID peut être atteinte rapidement si les comptes sont migrés plusieurs fois. Le nombre de SID dans le jeton d’accès est inférieur au nombre total de groupes dont l’utilisateur est membre dans la situation suivante :

• L’utilisateur provient d’un domaine approuvé où SIDHistory et SID sont filtrés.
• L’utilisateur provient d’un domaine approuvé dans une approbation où les SID sont mis en quarantaine. Ensuite, seuls les SID du même domaine que ceux de l’utilisateur sont inclus.
• Seuls les SID de groupe local de domaine du domaine du domaine de la ressource sont inclus.
• Seuls les SID de groupe local du serveur à partir du serveur de ressources sont inclus.

En raison de ces différences, il est possible que l’utilisateur puisse se connecter à un ordinateur dans un domaine, mais pas à un ordinateur d’un autre domaine. L’utilisateur peut également être en mesure de se connecter à un serveur dans un domaine, mais pas à un autre serveur dans le même domaine.

Vous pouvez découvrir les appartenances aux groupes de domaines d’un utilisateur affecté avec NTDSUTIL. Il dispose d’un outil d’évaluation de l’appartenance au groupe qui fonctionne également entre les limites des forêts. L’outil fonctionne également pour les utilisateurs suivants :

• utilisateurs qui sont bien au-dessus de la limite de 1 024 SID
• utilisateurs qui se trouvent dans tant de groupes que Kerberos échoue à la récupération des tickets même avec 65 535 octets de la mémoire tampon

Effectuez les étapes suivantes :

1. Ouvrez une invite de commandes sur un ordinateur disposant d’AD Management Tools (contrôleur de domaine ou ordinateur disposant de RSAT).

2. Basculez vers l’outil gro mem eva , puis obtenez les commandes disponibles comme capture d’écran suivante :

   

3. Connectez-vous aux contrôleurs de domaine nécessaires à l’évaluation :

   • Définir le contrôleur de domaine du compte %s - CONTRÔLEUR de domaine de l’utilisateur
   • Définir le catalogue global %s - GC de la forêt de l’utilisateur
   • Définir le contrôleur de domaine de ressources %s - CONTRÔLEUR de domaine de ressources
   • Définissez les informations d’identification en fonction des besoins ou les journaux détaillés lorsque les résultats semblent incorrects ou que la collection échoue.

4. Exécutez l’évaluation comme suit (par exemple, pour Admin in contoso.com) :

   Run contoso.com Admin

5. L’exécution collecte les détails de l’utilisateur dans les étapes 1 à 2, les détails du groupe de domaines de ressources à l’étape 3, puis compilent le rapport aux étapes 4 et 5.

6. Les résultats seront stockés dans un fichier TSV dans le répertoire actif comme capture d’écran suivante :

   

Consultez le guide suivant pour lire un fichier TSV :

• Type SID : indique s’il s’agit du SID principal du groupe/utilisateur ou du SIDHistory.
• Nombre d’historiques SID : combien de SID de SIDHistory ce compte introduit-t-il ?
• Nombre de membres de niveau : combien de SID cette entrée ajoute-t-elle à la collection à un seul niveau (membre des entrées) ?
• Total MemberOf Count : Combien de SID cette entrée ajoute-t-elle à la collection au total ?
• Propriétaire du groupe : pour les environnements disposant d’une gestion de groupe déléguée, vous pouvez obtenir des conseils sur l’utilisation d’un trop grand nombre de groupes pour attaquer l’ouverture de session utilisateur.
• Type de groupe : Type de sid. WellKnown, l’ID utilisateur, les groupes de sécurité globaux et universels se trouveraient dans tous les jetons créés pour cet utilisateur. Le groupe de sécurité local de domaine se trouverait uniquement dans ce domaine de ressources. Il peut être important lorsqu’un utilisateur a des problèmes d’ouverture de session uniquement dans un domaine de ressources donné.
• Membre WhenChanged (UTC) : dernière modification apportée à l’appartenance au groupe. Il peut aider à mettre en corrélation l’heure à laquelle le ou les utilisateurs ont signalé les problèmes d’ouverture de session pour la première fois.

Conseils pour rechercher des groupes à cibler pour une modification :

• Les groupes qui ont SIDHistory ont un bon levier permettant de réduire le nombre de SID.

• Les groupes qui introduisent de nombreux autres groupes par le biais de l’imbrication ont un excellent avantage pour réduire le nombre de SID.

• Recherchez des indices dans le nom du groupe pour déterminer si le groupe peut ne plus être utilisé. Par exemple, nous avons eu un client qui a un groupe par application dans sa solution de déploiement de logiciels. Et nous avons trouvé des groupes qui contenaient office2000 ou access2000.

• Transmettez le rapport de la liste de groupes à vos administrateurs de service et d’application. Identifiez les groupes qui ne sont plus nécessaires, peut-être uniquement pour cet utilisateur dans cette unité commerciale ou ce service.

Limites :

• L’outil n’inclut pas certains types de SID spéciaux/WellKnown répertoriés ci-dessous dans cet article. Par conséquent, n’oubliez pas qu’un utilisateur doit effacer plusieurs SID de 1 024 dans le rapport avant de pouvoir se connecter correctement.

• L’outil ne couvre pas non plus les groupes locaux serveur. Si vous rencontrez des problèmes uniquement sur certains serveurs d’un domaine de ressources, l’utilisateur ou certains de ses groupes sont membres de groupes locaux serveur.

Pour obtenir la liste des groupes locaux serveur et de ses membres :

Net localgroup | findstr * > %computername%-grouplist.txt

Pour obtenir la liste des membres d’un domaine :

Md server-groups

For /f "delims=*" %d in (%computername%-grouplist.txt) do Net localgroup %d | findstr \ > server-groups\%d-domain-memberlist.txt**

Mélanger et faire correspondre les groupes signalés ici avec le rapport utilisateur à partir de NTDSUTIL.

Résolution

Pour résoudre ce problème, utilisez l’une des méthodes suivantes, en fonction de votre situation.

Méthode 1

Cette résolution s’applique à la situation suivante :

• L’utilisateur qui rencontre l’erreur d’ouverture de session n’est pas administrateur.
• Les administrateurs peuvent se connecter correctement à l’ordinateur ou au domaine.

Cette résolution doit être effectuée par un administrateur disposant des autorisations nécessaires pour modifier les appartenances aux groupes de l’utilisateur. L’administrateur doit modifier les appartenances de groupe de l’utilisateur pour s’assurer que l’utilisateur n’est plus membre de plus de 1 010 groupes de sécurité. Considérez les appartenances de groupe transitives et les appartenances aux groupes locaux.

Les options permettant de réduire le nombre de SID dans le jeton utilisateur sont les suivantes. La collecte de données à partir de NTDSUTIL doit vous aider à voir quels groupes se trouvent dans l’étendue de la modification ou de la suppression :

• Supprimez l’utilisateur d’un nombre suffisant de groupes de sécurité.

• Convertissez les groupes de sécurité inutilisés en groupes de distribution. Les groupes de distribution ne comptent pas par rapport à la limite des jetons d’accès. Les groupes de distribution peuvent être convertis en groupes de sécurité lorsqu’un groupe converti est requis.

• Déterminez si les principaux de sécurité s’appuient sur l’historique SID pour l’accès aux ressources. Si ce n’est pas le cas, supprimez l’attribut SIDHistory de ces comptes. Vous pouvez récupérer la valeur d’attribut par le biais d’une restauration faisant autorité.

Méthode 2

La résolution s’applique à la situation dans laquelle le compte d’administrateur ne peut pas se connecter à l’ordinateur.

Lorsque l’utilisateur dont l’ouverture de session échoue en raison d’un trop grand nombre d’appartenances au groupe Administrateurs est membre du groupe Administrateurs, un administrateur disposant des informations d’identification du compte Administrateur (autrement dit, un compte disposant d’un identificateur relatif connu [RID] de 500) doit redémarrer un contrôleur de domaine en sélectionnant l’option de démarrage en mode sans échec (ou en sélectionnant l’option Mode sans échec avec l’option de démarrage réseau). En mode sans échec, l’administrateur doit ensuite se connecter au contrôleur de domaine à l’aide des informations d’identification du compte Administrateur.

Voir Redémarrer le contrôleur de domaine en mode de restauration des services d’annuaire localement

Microsoft a modifié l’algorithme de génération de jetons. LSA peut créer un jeton d’accès pour le compte Administrateur afin que l’administrateur puisse se connecter, quel que soit le nombre de groupes transitifs ou de groupes intransitifs dont le compte Administrateur est membre. Lorsque l’une de ces options de démarrage en mode sans échec est utilisée, le jeton d’accès créé pour le compte Administrateur inclut les SID de tous les groupes intégrés et tous les groupes globaux de domaine dont le compte Administrateur est membre.

Ces groupes incluent généralement :

• Tout le monde (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administrators (S-1-5-32-544)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\Utilisateurs authentifiés (S-1-5-11)
• LOCAL (S-1-2-0)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyy-zzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyy-zzz-512)
• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) si tout le monde est membre de ce groupe
• NT AUTHORITY\This Organization (S-1-5-15) si le contrôleur de domaine exécute Windows Server 2003

Une fois qu’un administrateur s’est connecté en sélectionnant l’une des options de démarrage en mode sans échec et en utilisant les informations d’identification du compte Administrateur, l’administrateur doit ensuite identifier et modifier l’appartenance des groupes de sécurité qui ont provoqué le déni de service d’ouverture de session.

Une fois cette modification effectuée, les utilisateurs doivent pouvoir se connecter correctement après une période égale à la latence de réplication du domaine.

Méthode 3

Cette option a le plus grand intérêt si vous avez de nombreux groupes créés pour accorder l’accès aux ressources utilisées sur un ensemble spécifique de serveurs, et qu’ils ne sont pas pertinents pour de nombreux autres serveurs. Le jeton d’accès des utilisateurs contient toujours les SID de l’utilisateur, des groupes globaux et universels. Toutefois, il contient uniquement les SID des groupes domain-local du domaine où se trouvent les serveurs de ressources. Par conséquent, à partir de 600 groupes dont un utilisateur est membre, 400 aident à donner accès aux ressources du serveur de fichiers sur deux groupes de serveurs, puis les idées suivantes peuvent être réalisables :

• Fractionnez vos serveurs en plusieurs groupes en fonction du nombre de groupes locaux de domaine.
• Au lieu d’un domaine de ressource qui a tous les groupes et serveurs, avez plusieurs domaines où seuls les groupes définis qui contiennent les serveurs dont vous avez besoin.
• Avoir un domaine distinct pour les serveurs avec un peu besoin de groupes locaux de domaine. Il peut s’agir de serveurs Exchange, car Exchange a une préférence forte pour les groupes universels.

Plus d’informations

Les SID génériques d’un compte sont souvent les suivants :

• Tout le monde (S-1-1-0)
• BUILTIN\Users (S-1-5-32-545)
• BUILTIN\Administrators (S-1-5-32-544)
• NT AUTHORITY\Utilisateurs authentifiés (S-1-5-11)
• Sid de session de connexion (S-1-5-5-X-Y)
• BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554) si l’utilisateur est membre de ce groupe (imbriqué)

Exemples de SID en fonction du type de session d’ouverture de session :

• LOCAL (S-1-2-0)
• OUVERTURE DE SESSION CONSOLE (S-1-2-1)
• NT AUTHORITY\NETWORK (S-1-5-2)
• NT AUTHORITY\SERVICE (S-1-5-6)
• NT AUTHORITY\INTERACTIVE (S-1-5-4)
• NT AUTHORITY\TERMINAL SERVER USER (S-1-5-13)
• NT AUTHORITY\BATCH (S-1-5-3)

SID pour les groupes principaux fréquemment utilisés :

• Domain\Domain Computers (S-1-5-21-xxxxxxxx-yyy-zzzz-515)
• Domain\Domain Users (S-1-5-21-xxxxxxxx-yyy-zzzz-513)
• Domain\Domain Admins (S-1-5-21-xxxxxxxx-yyyy-zzz-512)

SID qui documentent la façon dont la session d’ouverture de session a été vérifiée, l’une des valeurs suivantes :

• Identité déclarée par l’autorité d’authentification (S-1-18-1)
• Identité déclarée du service (S-1-18-2)

SID qui fournissent des détails sur le contexte du jeton et les détails de revendication, plusieurs sont possibles :

• Revendications d’appareil utilisées (S-1-5-21-0-0-0-496)
• Revendications utilisateur utilisées (S-1-5-21-0-0-0-497)
• Ce certificat d’organisation (S-1-5-65-1)
• Le jeton a été créé avec l’aide d’une identité vérifiée PKI (S-1-18-4)
• Le jeton a été créé à l’aide de l’approche MFA (S-1-18-5)
• Credential Guard a été utilisé (S-1-18-6)

SID qui décrivent le niveau de cohérence du jeton, les exemples les plus courants :

• Niveau obligatoire moyen (S-1-16-8192)
• Niveau obligatoire élevé (S-1-16-12288)

Le jeton d’accès inclut un SID relatif à l’origine utilisateur/ordinateur, l’une des valeurs suivantes :

• NT AUTHORITY\OTHER_ORGANIZATION (S-1-5-1000)
• NT AUTHORITY\This Organization (S-1-5-15) si le compte provient de la même forêt que l’ordinateur.

L’exemple suivant illustre les groupes de sécurité locaux de domaine qui s’affichent dans le jeton de l’utilisateur lorsque l’utilisateur se connecte à un ordinateur dans un domaine.

Dans cet exemple, supposons que Joe appartient au domaine A et est membre d’un domaine local Domain A\Chicago Users. Joe est également membre d’un domaine de groupe local Domaine B\Chicago Users. Lorsque Joe se connecte à un ordinateur qui appartient au domaine A (par exemple, Domaine A\Station de travail1), un jeton est généré pour Joe sur l’ordinateur, et le jeton contient, en plus de toutes les appartenances aux groupes universels et globaux, le SID pour les utilisateurs du domaine A\Chicago. Il ne contiendra pas le SID pour le domaine B\Chicago Users, car l’ordinateur sur lequel Joe s’est connecté (Domaine A\Workstation1) appartient au domaine A.

De même, lorsque Joe se connecte à un ordinateur qui appartient au domaine B (par exemple, Domaine B\Station de travail1), un jeton est généré pour Joe sur l’ordinateur, et le jeton contient, en plus de toutes les appartenances aux groupes universels et globaux, le SID pour domaine B\Chicago Users ; il ne contiendra pas le SID pour domaine A\Chicago Users, car l’ordinateur sur lequel Joe s’est connecté (Domaine B\Workstation1) appartient au domaine B.

Toutefois, lorsque Joe se connecte à un ordinateur qui appartient au domaine C (par exemple, Domaine C\Workstation1), un jeton est généré pour Joe sur l’ordinateur de connexion qui contient toutes les appartenances de groupe universelles et globales pour le compte d’utilisateur de Joe. Ni le SID pour le domaine A\Chicago Users ni le SID pour domaine B\Chicago Users n’apparaît dans le jeton, car les groupes locaux de domaine dont Joe est membre se trouvent dans un domaine différent de l’ordinateur sur lequel Joe s’est connecté (Domaine C\Workstation1). À l’inverse, si Joe était membre d’un groupe local de domaine qui appartient au domaine C (par exemple, Domaine C\Chicago Users), le jeton généré pour Joe sur l’ordinateur contiendrait, en plus de toutes les appartenances aux groupes universels et globaux, le SID pour les utilisateurs du domaine C\Chicago.

References

• SID connus

• Structures SID connues

• évaluation de l’appartenance aux groupes