La connexion 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 lié à l’échec de la journalisation sur un compte d’utilisateur membre de plus de 1 010 groupes.

S’applique à : Windows Server 2008 R2 Service Pack 1
Numéro de la 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. Et 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é. Réessayez ou consultez 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 ouvre une session sur un ordinateur, l’autorité de sécurité locale (LSA, qui fait 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 provenant de SIDHistory de l’utilisateur et des comptes de groupe.

Le tableau qui contient les SID des appartenances au groupe de l’utilisateur dans le jeton d’accès ne peut pas contenir plus de 1 024 SID. La LSA ne peut supprimer aucun SID du jeton. Par conséquent, s’il y a plus de SID, le LSA ne parvient pas à créer le jeton d’accès et l’utilisateur ne pourra 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 aux groupes de l’utilisateur (évaluées 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 SID principaux de l’utilisateur/de l’ordinateur et des groupes de sécurité dont le compte est membre.
• 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 celui de l’utilisateur sont inclus.
• Seuls les SID de groupe local de domaine du domaine de la ressource sont inclus.
• Seuls les SID de groupe local de serveurs du serveur 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 du même domaine.

Vous pouvez en savoir plus sur les appartenances au groupe de domaine d’un utilisateur affecté avec NTDSUTIL. Il dispose d’un outil d’évaluation de l’appartenance aux groupes qui fonctionne également au-delà des limites des forêts. L’outil fonctionne également pour les utilisateurs suivants :

• utilisateurs bien au-dessus de la limite de 1 024 SID
• utilisateurs qui se trouvent dans tant de groupes que Kerberos ne parvient pas à récupérer le ticket, même avec 65 535 octets de la mémoire tampon

Procédez comme suit :

1. Ouvrez une invite de commandes sur un ordinateur disposant des outils d’administration AD (contrôleur de domaine ou ordinateur disposant d’un service 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 %s du compte - contrôleur de domaine du 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 ressource %s - CONTRÔLEUR de domaine du domaine de ressource
   • Définissez des informations d’identification en fonction des besoins ou des 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 Administration dans contoso.com) :

   Run contoso.com Admin

5. L’exécution collecte les détails de l’utilisateur aux étapes 1 à 2, les détails du groupe de domaine de ressources à l’étape 3, puis compile 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 de SID : Indique s’il s’agit du SID principal du groupe/de l’utilisateur ou du SIDHistory.
• Nombre d’historiques DE SID : combien de SID de SIDHistory ce compte introduit-t-il ?
• Nombre de membres à un niveau : combien de SID cette entrée ajoute-t-elle à la collection sur un seul niveau (le membre des entrées) ?
• Nombre total de membres : combien de SID cette entrée ajoute-t-elle à la collection au total ?
• Propriétaire du groupe : pour les environnements qui ont 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. Les groupes de sécurité WellKnown, SID utilisateur, globaux et universels se trouveraient dans tous les jetons créés pour cet utilisateur. Le groupe de sécurité local de domaine se trouve uniquement dans ce domaine de ressource. Cela peut être important lorsqu’un utilisateur rencontre des problèmes d’ouverture de session uniquement dans un domaine de ressources spécifique.
• Member WhenChanged (UTC) : dernière modification apportée à l’appartenance au groupe. Cela peut aider à établir une corrélation avec le moment où les utilisateurs ont signalé pour la première fois des problèmes d’ouverture de session.

Indicateurs pour rechercher les groupes à cibler pour une modification :

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

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

• Recherchez des indices dans le nom du groupe pour déterminer si le groupe ne peut plus être utilisé. Par exemple, nous avions 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 des groupes aux administrateurs de votre service et de votre application. Identifiez les groupes qui ne sont plus nécessaires, peut-être uniquement pour cet utilisateur de cette unité commerciale ou de ce service.

Limites :

• L’outil n’inclut pas certains types de SIDs 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 serveur-local. Si vous rencontrez des problèmes uniquement sur certains serveurs d’un domaine de ressources, l’utilisateur ou une partie de son groupe est peut-être membre de groupes serveur-local.

Pour obtenir la liste des groupes locaux de 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élangez et faites correspondre les groupes signalés avec le rapport utilisateur 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 un administrateur.
• Les administrateurs peuvent se connecter à 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 aux groupes 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 transitives aux groupes 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 sont concernés par la modification ou la suppression :

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

• Convertissez des groupes de sécurité inutilisés en groupes de distribution. Les groupes de distribution ne sont pas comptabilisés dans la limite des jetons d’accès. Les groupes de distribution peuvent être reconverti 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 de l’attribut via une restauration faisant autorité.

Méthode 2

La résolution s’applique à la situation dans laquelle le compte 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 à un groupe est membre du groupe Administrateurs, un administrateur disposant des informations d’identification du compte Administrateur (autrement dit, un compte dont l’identificateur relatif [RID] connu est 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 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.

Microsoft a modifié l’algorithme de génération de jeton. La 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. Quand 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 de 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\Authenticated Users (S-1-5-11)
• LOCAL (S-1-2-0)
• Domaine\Utilisateurs du domaine (S-1-5-21-xxxxxxxx-yyyy-zzzzzz-513)
• Domaine\Administrateurs de domaine (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzz-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 identifier et modifier l’appartenance des groupes de sécurité qui ont provoqué le refus du service d’ouverture de session.

Une fois cette modification effectuée, les utilisateurs doivent être en mesure de se connecter correctement après l’expiration d’une période égale à la latence de réplication du domaine.

Méthode 3

Cette option est la plus intéressante 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 des groupes utilisateur, globaux et universels. Toutefois, il contient uniquement les SID de Domain-Local groupes du domaine où se trouvent les serveurs de ressources. Par conséquent, sur 600 groupes dont un utilisateur est membre, 400 aident à accorder l’accès aux ressources du serveur de fichiers sur deux groupes de serveurs, puis les idées suivantes peuvent être réalisables :

• Divisez vos serveurs en plusieurs groupes en fonction du nombre de groupes Domain-Local.
• Au lieu d’un domaine de ressource qui contient tous les groupes et serveurs, vous 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. Par exemple, les serveurs Exchange, car Exchange a une forte préférence 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\Authenticated Users (S-1-5-11)
• Session d’ouverture de session Sid (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 selon le 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 :

• Domaine\Ordinateurs de domaine (S-1-5-21-xxxxxxxx-yyyy-zzzzzz-515)
• Domaine\Utilisateurs du domaine (S-1-5-21-xxxxxxxx-yyyy-zzzzzz-513)
• Domaine\Administrateurs de domaine (S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzz-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 par le service (S-1-18-2)

SID qui fournissent des détails sur le contexte du jeton et les détails de revendication, plus d’un possible :

• Revendications d’appareil utilisées (S-1-5-21-0-0-0-496)
• Revendications utilisateur utilisées (S-1-5-21-0-0-0-0-497)
• Certificat de cette organisation (S-1-5-65-1)
• Le jeton a été créé à l’aide d’une identité PKI vérifiée (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 de l’utilisateur/de l’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 qu’il est membre d’un groupe de domaine local Domaine A\Utilisateurs Chicago. Joe est également membre d’un groupe local de domaine Domaine B\Utilisateurs de Chicago . 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 de groupe universelles et globales, le SID pour les utilisateurs du domaine A\Chicago. Il ne contiendra pas le SID pour les utilisateurs du domaine B\Chicago, car l’ordinateur sur lequel Joe s’est connecté (domaine A\Station de travail1) 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 de groupe universelles et globales, le SID pour les utilisateurs du domaine B\Chicago ; il ne contiendra pas le SID pour les utilisateurs de domaine A\Chicago, car l’ordinateur sur lequel Joe s’est connecté (domaine B\Station de travail1) 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 d’ouverture de session qui contient toutes les appartenances de groupe universelles et globales pour le compte d’utilisateur de Joe. Ni le SID pour domaine A\Utilisateurs Chicago ni le SID pour Domaine B\Utilisateurs Chicago n’apparaissent 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 Domain C\Chicago Users.

References

• SIDs connus

• Structures SID connues

• évaluation de l’appartenance au groupe