Die Anmeldung bei einem Benutzerkonto, das Mitglied von mehr als 1.010 Gruppen ist, kann auf einem Windows Server-basierten Computer fehlschlagen.

In diesem Artikel wird ein Problem behoben, bei dem die Anmeldung bei einem Benutzerkonto, das Mitglied von mehr als 1.010 Gruppen ist, fehlschlägt.

Gilt für: Windows Server 2008 R2 Service Pack 1
Ursprüngliche KB-Nummer: 328889

Symptome

Wenn ein Benutzer versucht, sich mit einem lokalen Computerkonto oder einem Domänenbenutzerkonto bei einem Computer anzumelden, schlägt die Anmeldeanforderung möglicherweise fehl. Und Sie erhalten die folgende Fehlermeldung:

Anmeldemeldung: Das System kann Sie aufgrund des folgenden Fehlers nicht anmelden: Während eines Anmeldeversuchs hat sich der Sicherheitskontext des Benutzers zu viele Sicherheits-IDs angesammelt. Versuchen Sie es erneut, oder wenden Sie sich an Ihren Systemadministrator.

Das Problem tritt auf, wenn der Anmeldebenutzer ein explizites oder transitives Mitglied von etwa 1.010 oder mehr Sicherheitsgruppen ist.

Anwendungen und die Sicherheitsereignisprotokoll-ID 4625 zeigen möglicherweise diesen Fehlercode an:

0xc000015a

Der Fehler ist STATUS_TOO_MANY_CONTEXT_IDS.

Ursache

Wenn sich ein Benutzer bei einem Computer anmeldet, generiert die lokale Sicherheitsautorität (LSA, teil des Subsystems für lokale Sicherheitsautorität) ein Zugriffstoken. Das Token stellt den Sicherheitskontext des Benutzers dar. Das Zugriffstoken besteht aus eindeutigen Sicherheits-IDs (SID) für jede Gruppe, in der der Benutzer Mitglied ist. Diese SIDs enthalten transitive Gruppen und SID-Werte aus SIDHistory des Benutzers und der Gruppenkonten.

Das Array, das die SIDs der Gruppenmitgliedschaften des Benutzers im Zugriffstoken enthält, darf nicht mehr als 1.024 SIDs enthalten. Die LSA kann keine SID aus dem Token löschen. Wenn also mehr SIDs vorhanden sind, kann die LSA das Zugriffstoken nicht erstellen, und der Benutzer kann sich nicht anmelden.

Wenn die Liste der SIDs erstellt wird, fügt die LSA neben den SIDs auch mehrere generische, bekannte SIDs für die Gruppenmitgliedschaften des Benutzers ein (transitiv ausgewertet). Wenn ein Benutzer also Mitglied von mehr als 1.010 benutzerdefinierten Sicherheitsgruppen ist, kann die Gesamtzahl der SIDs den SID-Grenzwert von 1.024 überschreiten.

Wichtig

  • Token für Administrator- und Nicht-Administratorkonten unterliegen dem Grenzwert.
  • Die genaue Anzahl der benutzerdefinierten SIDs variiert je nach Anmeldetyp (z. B. interaktiv, Dienst, Netzwerk) und Betriebssystemversion des Domänencontrollers und computers, der das Token erstellt.
  • Die Verwendung von Kerberos oder NTLM als Authentifizierungsprotokoll hat keine Auswirkungen auf das Zugriffstokenlimit.
  • Die Kerberos-Clienteinstellung MaxTokenSize wird unter Probleme mit der Kerberos-Authentifizierung erläutert, wenn ein Benutzer zu vielen Gruppen gehört. Token im Kerberos-Kontext bezieht sich auf den Puffer für die Tickets, die von einem Windows Kerberos-Host empfangen werden. Abhängig von der Größe des Tickets, der Art der SIDs und ob die SID-Komprimierung aktiviert ist, kann der Puffer weniger oder viel mehr SIDs enthalten, als in das Zugriffstoken passen würde.

Die Liste der benutzerdefinierten SIDs enthält Folgendes:

  • Die primären SIDs des Benutzers/Computers und der Sicherheitsgruppen, in der das Konto Mitglied ist.
  • Die SIDs im SIDHistory-Attribut der Gruppen im Bereich der Anmeldung.

Da das SIDHistory-Attribut mehrere Werte enthalten kann, kann der Grenzwert von 1.024 SIDs schnell erreicht werden, wenn Konten mehrmals migriert werden. Die Anzahl der SIDs im Zugriffstoken ist kleiner als die Gesamtzahl der Gruppen, denen der Benutzer in der folgenden Situation angehört:

  • Der Benutzer stammt aus einer vertrauenswürdigen Domäne, in der SIDHistory und SIDs herausgefiltert werden.
  • Der Benutzer stammt aus einer vertrauenswürdigen Domäne in einer Vertrauensstellung, in der SIDs unter Quarantäne stehen. Dann sind nur SIDs aus derselben Domäne wie die des Benutzers enthalten.
  • Es sind nur die LOKALEN Domänengruppen-SIDs aus der Domäne der Ressource enthalten.
  • Es sind nur die LOKALEN Servergruppen-SIDs des Ressourcenservers enthalten.

Aufgrund dieser Unterschiede kann sich der Benutzer möglicherweise bei einem Computer in einer Domäne anmelden, aber nicht bei einem Computer in einer anderen Domäne. Der Benutzer kann sich möglicherweise auch bei einem Server in einer Domäne anmelden, aber nicht bei einem anderen Server in derselben Domäne.

Sie können sich über die Domänengruppenmitgliedschaften eines betroffenen Benutzers mit NTDSUTIL informieren. Es verfügt über ein Tool zur Bewertung der Gruppenmitgliedschaft, das auch über Gesamtstrukturen hinweg funktioniert. Das Tool funktioniert auch für die folgenden Benutzer:

  • Benutzer, die deutlich über dem Grenzwert von 1.024 SIDs liegen
  • Benutzer, die sich in so vielen Gruppen befinden, dass Kerberos den Ticketabruf auch mit 65.535 Bytes des Puffers nicht erfüllt

Gehen Sie folgendermaßen vor:

  1. Öffnen Sie eine Eingabeaufforderung auf einem Computer mit AD-Verwaltungstools (Domänencontroller oder einem Computer mit RSAT).

  2. Wechseln Sie zum Tool, gro mem eva und rufen Sie dann die verfügbaren Befehle wie im folgenden Screenshot ab:

    Screenshot der Ausgabe nach dem Ausführen des Befehls

  3. Stellen Sie eine Verbindung mit den DOmänencontrollern her, die für die Auswertung erforderlich sind:

    • Festlegen des Kontodomänencontrollers %s – DC der Domäne des Benutzers
    • Festlegen des globalen Katalogs %s – GC der Gesamtstruktur des Benutzers
    • Festlegen des Ressourcen-DC %s – Domänencontroller der Ressourcendomäne
    • Legen Sie nach Bedarf Anmeldeinformationen oder ausführliche Protokolle fest, wenn die Ergebnisse falsch erscheinen oder die Sammlung fehlschlägt.
  4. Führen Sie die Auswertung wie folgt aus (z. B. für Admin in contoso.com):

    Run contoso.com Admin

  5. Bei der Ausführung werden die Benutzerdetails in den Schritten 1 bis 2 und Details zur Ressourcendomänengruppe in Schritt 3 erfasst und dann der Bericht in den Schritten 4 und 5 kompiliert.

  6. Die Ergebnisse werden wie im folgenden Screenshot in einer TSV-Datei im aktuellen Verzeichnis gespeichert:

    Screenshot: Die Ergebnisse werden in einer TSV-Datei im aktuellen Verzeichnis gespeichert.

Informationen zum Lesen einer TSV-Datei finden Sie im folgenden Leitfaden:

  • SID-Typ: Gibt an, ob es sich um die primäre SID der Gruppe/Des Benutzers oder SIDHistory handelt.
  • SID-Verlaufsanzahl: Wie viele SIDs von SIDHistory führt dieses Konto ein?
  • One Level MemberOf Count: Wie viele SIDs fügt dieser Eintrag der Auflistung auf einer einzelnen Ebene (dem Element der Einträge von) hinzu?
  • Total MemberOf Count: Wie viele SIDs fügt dieser Eintrag insgesamt zur Sammlung hinzu?
  • Gruppenbesitzer: Für Umgebungen mit delegierter Gruppenverwaltung erhalten Sie möglicherweise Hinweise dazu, wie zu viele Gruppen für Angriffe auf die Benutzeranmeldung verwendet werden.
  • Gruppentyp: Art der Sid. WellKnown, Benutzer-SID, globale und universelle Sicherheitsgruppen wären in allen Token enthalten, die für diesen Benutzer erstellt wurden. Die lokale Sicherheitsgruppe der Domäne würde sich nur in dieser Ressourcendomäne befinden. Dies kann wichtig sein, wenn ein Benutzer nur in einer bestimmten Ressourcendomäne Anmeldeprobleme hat.
  • Member WhenChanged (UTC): Letzte Änderung an der Gruppenmitgliedschaft. Es kann hilfreich sein, mit dem Zeitpunkt zu korrelieren, zu dem die Benutzer zum ersten Mal Anmeldeprobleme gemeldet haben.

Hinweise zum Suchen von Gruppen für eine Änderung:

  • Gruppen mit SIDHistory haben einen guten Nutzen, um die SID-Anzahl zu reduzieren.

  • Gruppen, die viele andere Gruppen durch Schachtelung einführen, haben einen großen Nutzen, um die SID-Anzahl zu reduzieren.

  • Suchen Sie im Gruppennamen nach Hinweisen, um festzustellen, ob die Gruppe nicht mehr verwendet werden darf. Beispielsweise hatten wir einen Kunden, der eine Gruppe pro Anwendung in seiner Softwarebereitstellungslösung hat. Außerdem wurden Gruppen gefunden, die office2000 oder access2000 enthielten.

  • Übergeben Sie den Bericht der Gruppenliste an Ihre Dienst- und Anwendungsadministratoren. Identifizieren Sie Gruppen, die nicht mehr benötigt werden, möglicherweise nur für diesen Benutzer in dieser Geschäftseinheit oder Abteilung.

Einschränkungen:

  • Das Tool enthält keine Arten von speziellen/WellKnown-SIDs, die unten in diesem Artikel aufgeführt sind. Denken Sie daher daran, dass ein Benutzer mehrere SIDs von 1.024 im Bericht löschen muss, bevor er sich erfolgreich anmelden kann.

  • Das Tool deckt auch keine lokalen Servergruppen ab. Wenn Probleme nur auf bestimmten Servern einer Ressourcendomäne auftreten, sind der Benutzer oder ein Teil seiner Gruppe möglicherweise Mitglied von lokalen Servergruppen.

So rufen Sie eine Liste der lokalen Servergruppen und deren Mitglieder ab:

Hinweis

Führen Sie als Administrator in einer Eingabeaufforderung mit erhöhten Rechten aus.

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

So rufen Sie eine Liste der Mitglieder aus einer Domäne ab:

Md server-groups

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

Kombinieren Sie die dort gemeldeten Gruppen mit dem Benutzerbericht von NTDSUTIL, und stimmen Sie sie ab.

Lösung

Um dieses Problem zu beheben, verwenden Sie je nach Situation eine der folgenden Methoden.

Methode 1

Diese Entschließung gilt für die folgende Situation:

  • Der Benutzer, der auf den Anmeldefehler stößt, ist kein Administrator.
  • Administratoren können sich erfolgreich am Computer oder der Domäne anmelden.

Diese Lösung muss von einem Administrator durchgeführt werden, der über berechtigungen zum Ändern der Gruppenmitgliedschaften des Benutzers verfügt. Der Administrator muss die Gruppenmitgliedschaften des Benutzers ändern, um sicherzustellen, dass der Benutzer nicht mehr Mitglied von mehr als 1.010 Sicherheitsgruppen ist. Betrachten Sie die transitiven Gruppenmitgliedschaften und die lokalen Gruppenmitgliedschaften.

Folgende Optionen zum Reduzieren der Anzahl von SIDs im Benutzertoken sind verfügbar. Die Datensammlung von NTDSUTIL sollte Ihnen helfen, zu sehen, welche Gruppen sich im Bereich für Änderungen oder Entfernungen befinden:

  • Entfernen Sie den Benutzer aus einer ausreichenden Anzahl von Sicherheitsgruppen.

  • Konvertieren nicht verwendeter Sicherheitsgruppen in Verteilergruppen. Verteilergruppen werden nicht auf den Grenzwert für Zugriffstoken angerechnet. Verteilergruppen können wieder in Sicherheitsgruppen konvertiert werden, wenn eine konvertierte Gruppe erforderlich ist.

  • Bestimmen Sie, ob Sicherheitsprinzipale den SID-Verlauf für den Ressourcenzugriff verwenden. Wenn nicht, entfernen Sie das SIDHistory-Attribut aus diesen Konten. Sie können den Attributwert durch eine autoritative Wiederherstellung abrufen.

Hinweis

Obwohl die maximale Anzahl von Sicherheitsgruppen, in denen ein Benutzer Mitglied sein kann, 1.024 beträgt, beschränken Sie die Anzahl als bewährte Methode auf weniger als 1.010. Diese Zahl stellt sicher, dass die Tokengenerierung immer erfolgreich ist, da sie Platz für generische SIDs bereitstellt, die von der LSA eingefügt werden.

Methode 2

Die Lösung gilt für die Situation, in der sich das Administratorkonto nicht am Computer anmelden kann.

Wenn der Benutzer, dessen Anmeldung aufgrund zu vieler Gruppenmitgliedschaften fehlschlägt, Mitglied der Gruppe Administratoren ist, muss ein Administrator, der über die Anmeldeinformationen für das Administratorkonto verfügt (d. b. ein Konto mit dem bekannten relativen Bezeichner [RID] von 500), einen Domänencontroller neu starten, indem er die Startoption abgesicherter Modus (oder die Startoption Abgesicherter Modus mit Netzwerk) auswählt. Im abgesicherten Modus muss sich der Administrator dann mit den Anmeldeinformationen des Administratorkontos beim Domänencontroller anmelden.

Microsoft hat den Tokengenerierungsalgorithmus geändert. Die LSA kann ein Zugriffstoken für das Administratorkonto erstellen, sodass sich der Administrator unabhängig davon anmelden kann, wie viele transitive Gruppen oder intransitive Gruppen mitglied sind. Wenn eine dieser Startoptionen für den abgesicherten Modus verwendet wird, enthält das Zugriffstoken, das für das Administratorkonto erstellt wird, die SIDs aller integrierten und aller globalen Domänengruppen, in denen das Administratorkonto Mitglied ist.

Diese Gruppen umfassen in der Regel:

  • Jeder (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)
  • LOKAL (S-1-2-0)
  • Domäne\Domänenbenutzer (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-513)
  • Domänen\Domänenadministratoren (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-512)
  • BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554), wenn Jeder Mitglied dieser Gruppe ist
  • NT AUTHORITY\This Organization (S-1-5-15), wenn auf dem Domänencontroller Windows Server 2003 ausgeführt wird

Hinweis

Wenn die Startoption abgesicherter Modus verwendet wird, ist die Active Directory-Benutzer und -Computer Snap-In-Benutzeroberfläche (UI) nicht verfügbar. In Windows Server 2003 kann sich der Administrator alternativ anmelden, indem er die Startoption Abgesicherter Modus mit Netzwerkbetrieb auswählen. In diesem Modus ist die Active Directory-Benutzer und -Computer-Snap-In-Benutzeroberfläche verfügbar.

Nachdem sich ein Administrator angemeldet hat, indem er eine der Startoptionen im abgesicherten Modus ausgewählt und die Anmeldeinformationen des Administratorkontos verwendet hat, muss der Administrator die Mitgliedschaft der Sicherheitsgruppen identifizieren und ändern, die den Denial-of-Anmeldedienst verursacht haben.

Nachdem diese Änderung vorgenommen wurde, sollten sich Benutzer nach Ablauf eines Zeitraums, der der Replikationslatenz der Domäne entspricht, erfolgreich anmelden können.

Methode 3

Diese Option hat den größten Reiz, wenn Sie über viele Gruppen verfügen, die erstellt wurden, um Zugriff auf Ressourcen zu gewähren, die auf einer bestimmten Gruppe von Servern verwendet werden, und diese sind für viele andere Server nicht relevant. Das Zugriffstoken von Benutzern enthält immer die SIDs der Benutzer-, globalen und universellen Gruppen. Es enthält jedoch nur die SIDs von Domain-Local Gruppen der Domäne, in der sich die Ressourcenserver befinden. Von 600 Gruppen, in denen ein Benutzer Mitglied ist, helfen 400 beim Gewähren des Zugriffs auf Dateiserverressourcen auf zwei Gruppen von Servern, und dann können die folgenden Ideen durchführbar sein:

  • Teilen Sie Ihre Server in mehrere Gruppen auf, je nach Anzahl von Domain-Local Gruppen.
  • Anstelle einer Ressourcendomäne mit allen Gruppen und Servern verfügen Sie über mehrere Domänen, in denen nur die Gruppen definiert sind, die die benötigten Server enthalten.
  • Sie verfügen über eine separate Domäne für Server mit geringem Bedarf an lokalen Domänengruppen. Ein Beispiel wären Exchange-Server, da Exchange eine starke Präferenz für universelle Gruppen hat.

Weitere Informationen

Die generischen SIDs eines Kontos enthalten häufig Folgendes:

  • Jeder (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)
  • Anmeldesitzungs-Sid (S-1-5-5-X-Y)
  • BUILTIN\Pre-Windows 2000 Compatible Access(S-1-5-32-554), wenn der Benutzer Mitglied dieser Gruppe ist (geschachtelt)

Wichtig

Das Tool Whoami wird häufig verwendet, um Zugriffstoken zu untersuchen. Dieses Tool zeigt die SID der Anmeldesitzung nicht an.

Beispiele für SIDs in Abhängigkeit vom Typ der Anmeldesitzung:

  • LOKAL (S-1-2-0)
  • KONSOLENANMELDUNG (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)

SIDs für häufig verwendete primäre Gruppen:

  • Domäne\Domänencomputer (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-515)
  • Domäne\Domänenbenutzer (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-513)
  • Domänen\Domänenadministratoren (S-1-5-21-xxxxxxxx-yyyyyyy-zzzzzzzzzz-512)

SIDs, die dokumentieren, wie die Anmeldesitzung überprüft wurde, einer der folgenden Werte:

  • Durch die Authentifizierungsstelle bestätigte Identität (S-1-18-1)
  • Dienstbestätigte Identität (S-1-18-2)

SIDs, die Details zum Tokenkontext und zu Anspruchsdetails angeben, mehrere mögliche:

  • Verwendete Geräteansprüche (S-1-5-21-0-0-0-496)
  • Verwendete Benutzeransprüche (S-1-5-21-0-0-0-497)
  • Dieses Organisationszertifikat (S-1-5-65-1)
  • Token wurde mit Hilfe einer PKI-verifizierten Identität erstellt (S-1-18-4)
  • Token wurde mithilfe des MFA-Ansatzes (S-1-18-5) erstellt.
  • Credential Guard wurde verwendet (S-1-18-6)

SIDs, die die Konsistenzebene des Tokens beschreiben, die häufigsten Beispiele:

  • Mittlere Obligatorische Stufe (S-1-16-8192)
  • Hohe obligatorische Stufe (S-1-16-12288)

Das Zugriffstoken enthält eine SID relativ zum Benutzer-/Computerursprung, einen der folgenden Werte:

  • NT AUTHORITY\OTHER_ORGANIZATION (S-1-5-1000)
  • NT AUTHORITY\This Organization (S-1-5-15), wenn das Konto aus derselben Gesamtstruktur wie der Computer stammt.

Hinweis

  • Wie Sie mit dem Hinweis unter SID-Eintrag Anmeldesitzungs-SID sehen können, zählen Sie die SIDs nicht in der Liste der Toolausgaben, und gehen Sie davon aus, dass sie für alle Zielcomputer und Anmeldetypen vollständig sind. Sie sollten bedenken, dass ein Konto Gefahr läuft, in diesen Grenzwert zu geraten, wenn es über mehr als 1.000 SIDs verfügt. Vergessen Sie nicht, dass abhängig vom Computer, auf dem ein Token erstellt wird, auch lokale Server- oder Arbeitsstationsgruppen hinzugefügt werden können.
  • xxxxxxxxxx-yyyyyy-zzzzzzzzzz gibt die Domänen- oder Arbeitsstationskomponenten der SID an.

Im folgenden Beispiel wird veranschaulicht, welche lokalen Sicherheitsgruppen der Domäne im Token des Benutzers angezeigt werden, wenn sich der Benutzer bei einem Computer in einer Domäne anmeldet.

Gehen Sie in diesem Beispiel davon aus, dass Joe zu Domäne A gehört und Mitglied einer lokalen Domänengruppe ist Domain A\Chicago Users. Joe ist auch Mitglied einer lokalen Domänengruppe Domain B\Chicago Users. Wenn Joe sich bei einem Computer anmeldet, der zu Domäne A gehört (z. B. Domäne A\Workstation1), wird ein Token für Joe auf dem Computer generiert, und das Token enthält zusätzlich zu allen universellen und globalen Gruppenmitgliedschaften die SID für Domänen A\Chicago Users. Sie enthält nicht die SID für Domäne B\Chicago Users, da der Computer, auf dem sich Joe angemeldet hat (Domäne A\Workstation1) zu Domäne A gehört.

Wenn Joe sich bei einem Computer anmeldet, der zu Domäne B gehört (z. B. Domäne B\Workstation1), wird auf ähnliche Weise ein Token für Joe auf dem Computer generiert, und das Token enthält neben allen universellen und globalen Gruppenmitgliedschaften die SID für Domänen B\Chicago-Benutzer. Sie enthält nicht die SID für Domäne A\Chicago Users, da der Computer, auf dem Joe sich angemeldet hat (Domäne B\Workstation1) zu Domäne B gehört.

Wenn Joe sich jedoch bei einem Computer anmeldet, der zu Domäne C gehört (z. B. Domäne C\Workstation1), wird ein Token für Joe auf dem Anmeldecomputer generiert, das alle universellen und globalen Gruppenmitgliedschaften für Joes Benutzerkonto enthält. Weder die SID für Domänen-A\Chicago-Benutzer noch die SID für Domäne B\Chicago-Benutzer werden im Token angezeigt, da sich die lokalen Domänengruppen, in denen Joe Mitglied ist, in einer anderen Domäne befinden als der Computer, auf dem Sich Joe angemeldet hat (Domäne C\Workstation1). Wenn Joe hingegen Mitglied einer lokalen Domänengruppe wäre, die zu Domäne C gehört (z. B. Domänen-C\Chicago-Benutzer), würde das Token, das für Joe auf dem Computer generiert wird, zusätzlich zu allen universellen und globalen Gruppenmitgliedschaften die SID für Domäne C\Chicago-Benutzer enthalten.

References