MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Token Limit/Token Bloat

Je größer eine Firma ist oder je feiner Berechtigungen über Gruppen vergeben werden, desto mehr "Mitgliedschaften" summieren sich bei einem einem Benutzer auf. Neben der Größe des Kerberos-Tickets gibt es noch eine zweite Grenze, die sogar noch direkter Einfluss auf die Arbeit des Mitarbeiters hat.

Wenn sie Benutzerkonten in mehr als 1000 Gruppen aufnehmen wollen, dann lesen Sie vorher diese Seite! 

Fehler bei der Anmeldung

Wenn nur das Kerberos-Ticket zu groß wird, dann können Sie bestimmte Dienste nicht mehr nutzen. Aber ein Windows Client hat zudem einen "Security Context" der eine bestimmte Größe nicht überschritten werden darf. Sobald dies passiert, kann sich der Anwender nicht mehr auf seinem Computer anmelden und sehen folgenden Fehler auf dem Anmeldebildschirm:


Quelle: Windows 11 25H2 bei Anmeldung mit Benutzer

Auf einem englischen Server lautet der Fehler:

"During a logon the user's security context accumulate too many security Id's".

Wenn sich dann ein Administrator das Eventlog anschaut, dann finden Sie hier den passenden Eintrag:

Protokollname: System
Quelle:        LsaSrv
Datum:         23.02.2026 14:35:30
Ereignis-ID:   6035
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      WIN11A.lab4.msxfaq.de
Beschreibung:
Während eines Anmeldeversuchs hat der Sicherheitskontext des Benutzers zu viele 
  Sicherheits-IDs angesammelt. Dies ist eine sehr ungewöhnliche Situation. 
  Entfernen Sie den Benutzer von einigen globalen oder lokalen Gruppen, 
  um die Anzahl der Sicherheits-IDs zu reduzieren und in den Sicherheitskontext
  aufgenommen zu werden.
Benutzer-SID: LAB4\user1
Wenn es sich hier um ein Administratorkonto handelt, werden durch die Anmeldung im 
sicheren Modus Gruppenmitgliedschaften automatisch eingeschränkt.

Wenn man dann etwas sucht, finden wir:

Analyse

Auf den Seiten Kerberos Ticketsize und Gruppen habe ich schon einige Details zu Gruppen und ihren Mitgliedern beschrieben, z.B. dass ADSync mit Gruppen bis maximal 50.000 Mitgliedern repliziert, dass Windows 2003 DC keine Gruppen mit mehr als 5000 Mitgliedern replizieren konnten oder Gruppenrichtlinien bei ca.1015 Mitgliedschaften nicht mehr funktioniert haben. Der Benutzerkann sich hier aber gar nicht mehr anmelden und die Eventlogmeldung sagt hat schon, dass da ein Puffer zu voll wird. Bei der Quellensuche findet sich dann:

When a user logs on to a computer, the Local Security Authority (LSA, a part of the Local Security Authority Subsystem) generates an access token. The token represents the user's security context. The access token consists of unique security identifiers (SID) for every group that the user is a member of. These SIDs include transitive groups and SID values from SIDHistory of the user and the group accounts.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/logging-on-user-account-fails#cause

Der Anwender meldet sich also an einem Client an, welcher dann vom Domain Controller ein "Security Ticket" bekommt, welches folgende SIDs enthält:

  • User SID
    also die SID meines angemeldeten Users
  • SIDs der Sicherheitsgruppen, in denen ich Mitglied bin
    Alle Gruppen ohne SID, d.h. Verteiler oder dynamische Gruppen sind nicht enthalten
  • SIDHistory-Einträge
    Wenn ich von früheren Migrationen noch SIDs mitschleife, dann kommt die SID meiner früheren Benutzer und früherer Gruppen mit dazu.

Wie lange und groß diese Liste ist, kann ich als angemeldeter Benutzer einfach anfragen.

[System.Security.Principal.WindowsIdentity]::GetCurrent().groups.count
[System.Security.Principal.WindowsIdentity]::GetCurrent().groups

Mein Admin in der Laborumgebung hat folgende 16 Gruppenmitgliedschaften. Sie sehen die Domain-Gruppen mit den SIDs aber auch die lokalen Gruppen ohne DomainSID und auch die unterschiedliche Größe der Einträge in Byte:

 

Als Administrator lässt sich die Größe nicht so einfach ermitteln, aber auch das ist per LDAP und der Nutzung von TokenGroup und MemberOf.

Hinweis: TokenGroups liefert nur die Gruppen mit SID aber auch verschachtelt. "MemberOf" liefert nur die alle direkten Gruppenmitgliedschaften ohne Rekursion, unabhänigig von einer SID

$dn= (get-aduser user1).distinguishedname
(Get-ADUser -Identity $dn -Property TokenGroups).tokengroups
(Get-ADUser -Identity $dn -Property TokenGroups).tokengroups.count

Die Ausgabe entspricht der Ausgabe der Eigenabfrage, aber kann hier natürlich auf beliebige Objekte der Domain ausgedehnt werden. Allerdings funktioniert die Abfrage mit Get-ADUser nur, wenn Sie keine Suche machen, sondern direkt den distinguishedName angeben. Ansonsten bekommen Sie einen "The requested search operation is only supportet for basic searches"

Wenn Sie daher von allen Objekten die Größe und Anzahl abfragen wollen, dann ist eine Schleife erforderlich

Foreach ($user in Get-ADUser -Filter *)  {
   $userdetails = Get-ADUser -identity $user.distinguishedname -property TokenGroups
   [pscustomobject]@{
      samaccountname  = $user.samaccountname
      TokenGroupcount = $userdetails.TokenGroups.count
      TokenGroupsize  = ($userdetails.TokenGroups.BinaryLength |measure-Object -Sum).Sum
   }
}

Sie sehen hier sehr gut, dass mein "User1" in 1027 Sicherheitsgruppen als Mitglied geführt wird und anscheinend ca. 28744 Bytes groß ist. Ob diese Größe auch die Größe des "Security Context" wiederspiegelt, konnte ich nicht ermitteln. Microsoft beschreibt auf einem Dokument eine maximale Anzahl von 1015 Mitgliedern:

“Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups. This limitation is due to the size limit for the access token that is created for each security principal. The limitation is not affected by how the groups may or may not be nested.

Active Directory Maximum Limits - Scalability
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10)?#group-memberships-for-security-principals

Interessant ist, dass der Link, der nämlich einen einen KB-Artikel mit anderen Grenzen führt und das Eventlog (Applications/Security) hat eine Event log ID 4625 mit dem Fehler 0xc000015a: STATUS_TOO_MANY_CONTEXT_IDS.


https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/logging-on-user-account-fails

Allerdings beschreibt eine andere Quelle ein Limit von 1000 Mitgliedschaften:

This behavior occurs because Windows systems contain a limit that prevents a user’s security access token from containing more than 1,000 security identifiers (SIDs). This means that when a user is being validated for access rights to establish a new session with a server, that user must not be a member of more than 1,000 groups in that server’s domain. If this limit is exceeded, access to the server is denied, and the error code 1384 is returned to the user. If the server that the user connects to is in a second domain (for example, if the user connects to a server in a Windows 2000 resource domain), the total number of groups the user is a member of is determined by adding the user’s group membership in that second domain to the user’s global group membership in their domain.

Error message: During a logon attempt, the user's security context accumulated too many security IDs
https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/security-content-accumated-many-security-ids

Ich habe in einem kleinen Textfeld mit  1x Windows 2022 DC und 1x Windows 11 Client habe ich viele Gruppen und einen Testuser angelegt, um die Mitgliedschaften anzupassen.

 

<1000       Anmeldung sicher möglich
1000-1024   Anmeldung meist möglich
>1025       Keine Anmeldung möglich

Allerdings gibt es hier eine Unschärfe. Sobald ich die 1025 Mitgliedschaften innehatte, war keine Anmeldung mehr möglich und unter 1000 Mitgliedschaften konnte ich mich immer anmelden. In dem Bereich von 1000-1024 Mitgliedschaften waren die Ergebnisse nicht eindeutig. Manchmal konnte ich mich anmelden und manchmal nicht. Das kann ein Caching-Thema gewesen sein aber sicher keine AD-Replikation, da ich nur einen DC nutze und eine SIDHistory gab es nicht

Wir können festhalten: Ein Benutzer sollte nicht mehr als 1000 SIDs in seinem Security Context einsammeln. Sicherheitsgruppen sein. Dabei werden alle Rekursionen mitgezählt.

Entra ID, ADSync und Entra ID Login

Das Feld "MemberOf" ist kein echten Feld im Active Directory, sondern wird "errechnet". Es wird also nicht wirklich zwischen Domain Controllern oder anderen Systemen repliziert. ADSync repliziert z.B. immer nur Gruppen mit dem Attribute "Member". Das bedeutet natürlich, dass es auch in Entra ID Benutzer geben kann, die in sehr vielen Gruppen enthalten sind. Ich habe in Entra ID also erst einmal 2000 Gruppen angelegt. Per Graph wurden ca. 3-4 Gruppen/Sekunde angelegt.

1..2000 | Foreach { 
   New-EntraGroup `
      -SecurityEnabled $true `
      -MailEnabled $false `
      -DisplayName "group$($_)" `
      -MailNickname "group$($_)" 
} 

Dann habe ich einen TestUser in eben diese 2000 Gruppen addiert. Das Addieren hat mit ca. 2 Aktionen/Sek etwas länger gedauert

$user = Get-EntraUser -UserId "Clouduser1@msxfaqdev.onmicrosoft.com"

1..2000 | foreach {
   $group = Get-EntraGroup -Filter "displayName eq 'group$($_)'" 
   Add-EntraGroupMember `
      -GroupId $group.Id `
      -MemberId $user.Id
}

Das hat schon mal problemlos funktioniert. Danach habe ich mich an einem Windows 11 25H2 Client mit diesem Benutzer angemeldet, der nur EntraID Joined ist und mir die Gruppen anzeigen lassen:

[System.Security.Principal.WindowsIdentity]::GetCurrent().groups

Hier sehe ich nur die Standard-Gruppen und Rollen, in denen der User enthalten ist. Die EntraID-Gruppen tauchen hier aber nicht auf. Insofern werden sehr große Mitgliedschaften in Entra ID-Gruppen

Insofern wird es hier wohl keine Probleme mit einem zu großen Security Token geben. Ein anderes Thema könnten natürlich OAUTH-Tokens sein, in denen ebenfalls Gruppen enthalten sein können. Auch die Ausstellung dieser Tokens, die Anwendung von Lizenzen anhand von Gruppenmitgliedschaften, Conditional Access-Richtlinien etc. können sehr viele Gruppenmitgliedschaften negativ beeinflusst werden. Nicht umsonst beschriebt Microsoft einige Grenzen in ihren Service Descriptions:

  • Ein Benutzer kann maximal 250 Gruppen erstellen
    Das trifft mich nicht, da in meinen Tenants Benutzer sowieso keine Gruppen anlegen dürfen. Das macht ein IDM, ADSync oder ein Admin
  • max. 15.000 dynamische Gruppen pro Tenant
    Auch das ist eigentlich kein Problem
  • max. 1010 Gruppen in Entra-Kerberos
    Das ist wieder ein interessantes Thema. Wenn Entra ID ein Ticket ausstellt, dürfen maximal 1010 Gruppen mit SIDs enthalten sein
  • max. 2028 Gruppenmitgliedschaften eines Benutzers
    Das sind zwar mehr als die 1000 bei Windows AD aber ebenfalls nicht Tausende
  • SharePoint Online: max. 2047 Mitgliedschaften
    Wenn der Benutzer in mehr Gruppen Mitglied ist, sind die Berechtigungen nicht vorhersehbar.
  • SAML-Token: max. 150 Gruppen
    Wenn ein Ticket mit Gruppen ausgestellt wird und das Konto in mehr als 150 Gruppen ist, wird keine Gruppe ausgegeben und eine Überlastung gemeldet
  • JWT/OIDC-Token. Max 200 Gruppen
    Verhalten Vergleichbar zu SAML-Token

Es gibt also auch in Entra ID verschiedene Grenzen, die sie im Blick behalten sollten. 

Einschätzung. Sicher unter 1000 MemberOf

ich könnte nun jammern, warum bei 1000, 1010, 1024, 1050 und anderen Mitgliedschaften eines Benutzer verschiedene Dinge nicht mehr wie erwartet funktionieren. Aber ich beklage mich nicht, denn es gibt immer technische Grenzen und auch immer Kunden, die an die Grenzen stoßen werten. Aber überlegen Sie einmal, wozu sie Gruppen verwenden.

  • Sie steuern Berechtigungen 
    Sicher gibt es viele Dateiserver, SharePoint Server, Webserver u.a. Aber wenn ein Benutzer in 1000 Gruppen ist, um auf 1000 Ressourcen berechtigt zu sein, dann frage mich mich, wie der Anwender über die unterschiedlichen Datentöpfe den Überblick behalten soll. Ist vielleicht einfach ihr Berechtigungskonzept zu granular ausgelegt? Sicher möchten Sie genau die passenden Berechtigungen delegieren aber durch die Komplexität fällt ihnen ein Oversharing vielleicht gar nicht mehr auf. Vielleicht haben Sie aber auch einfach ganz viele alte Projekte, auf denen Sie die Berechtigungen nicht verlieren wollen. Aber ist es aus Frage des Datenschutzes, Vertraulichkeit, Schutz gegen Trojaner und Verschlüsselung überhaupt sinnvoll, dass Benutzer auf abgeschlossene Projekte noch jederzeit zugreifen können?
    Vielleicht sind genau die Grenzen der Mitgliedschaft der Anlass über die Berechtigung, deren Beantragung aber auch wieder Abgabe nachzudenken
  • Sie steuern damit Gruppenrichtlinien
    Auch hier gibt es ein Limit und ich habe viele Firmen mit noch mehr GPOs gesehen. Oft lassen sich diese Richtlinien aber doch zusammenfassen und vereinfachen. Mit einem Scope auf OUs gibt es vielleicht nur ganz wenige GPOs, deren Anwendung über Sicherheitsgruppen gesteuert werden. Prüfen Sie doch mal, ob Einstellungen nicht auch über Intune, MDM oder andere Produkte umgesetzt werden können.
  • Mailverteiler
    Wenn ein Verteiler nicht für Berechtigungen auf Postfächer o.ä. genutzt wird, dann muss diese Gruppe keine SID haben. Ein reiner "Verteiler" ohne SID reicht auch und vergrößert nicht ihr Access-Token.

Es gibt sicher noch weitere Einsatzzwecke aber haben Sie dabei immer die Größe des SecurityToken im Blick, denn wenn Sie sich einfach gar nicht mehr anmelden können, dann können Sie nicht arbeiten. Prüfen Sie regelmäßig, ob Konten schon in die Nähe der 1000 Mitgliedschaften kommen. Selbst wenn Microsoft das Limit, welches Windows schon sehr lange mit sich führt, anheben würde, dann kommt sehr schnell die Maximalgröße des Kerberos Tickets als nächste Hürde, welche nicht verhandelbar ist. Mehr als 64Kbyte ist nicht möglich und das betrifft nicht nur Windows.

Denken Sie daran: Sie können immer noch mit lokalen Gruppen auf Memberservern arbeiten, die nicht Bestandteil des initialen Security Context sind, sondern erst beim Zugriff auf den Server vor Ort addiert werden. Prüfen Sie auch, ob Applikationen wirklich eine "SecurityGroup" brauchen oder nicht einfach nur Mitgliedschaften per LDAP auflösen. Einige Applikationen, z.B. SharePoint können auch eigene Applikationsgruppen zur Berechtigungsvergabe nutzen und müssen nicht mit dem Active Directory gekoppelt sein.

Weitere Links