Wie viele Mitglieder bzw. Objekte sollte eine Gruppe maximal haben?

Hallo, Fabian schreibt. Grundsätzlich ist es im Forestmodus Windows Server 2003 möglich, über 5.000 Objekte einer Gruppe zuzuordnen (siehe "How to raise domain and forest functional levels in Windows Server 2003" https://support.microsoft.com/default.aspx?scid=kb;EN-US;322692). Dabei kann es sich beispielsweise um Benutzer-, Computer-, Druckerobjekte oder ähnliches handeln.

Es ist jedoch nicht empfehlenswert diese 5.000er Grenze tatsächlich zu überschreiten, da viele weitere Abhängigkeiten existieren. Ein paar davon sollen in diesem Beitrag kurz angesprochen werden.

Hinweis: Um es gleich zu Beginn noch einmal genau zu definieren: Es geht in diesem Beitrag um Gruppen und Ihre Mitglieder und nicht um Benutzer und Ihre Gruppenmitgliedschaften, denn dort existieren andere Grenzen (siehe z.B. 328889 "Users Who Are Members of More Than 1,015 Groups May Fail Logon Authentication" https://support.microsoft.com/default.aspx?scid=kb;EN-US;328889 oder 327825 "New resolution for problems with Kerberos authentication when users belong to many groups" https://support.microsoft.com/default.aspx?scid=kb;EN-US;327825).

 

Folgende Punkte sollten Beachtung finden, wenn man das Thema "maximale Anzahl an Objekten in Gruppen" betrachtet:

• Bei einer Anzahl von mehr als 5.000 Objekten (oder auch schon darunter, je nach Umgebung) ist praktisch gesehen kein Management über die GUI mehr möglich, da die Abfragezeiten bis zur Darstellung aller Gruppenmitglieder bzw. Objekte unheimlich lange dauern würde.

• Grundsätzlich können die Antwortzeiten bei der Abfrage einer solchen Gruppe und deren Gruppenmitgliedschaften sehr hoch sein, auch was den Zugriff von Drittapplikationen, LDAP-Abfragen o.ä. betrifft.
   

• Eine Gruppe mit solch einer Anzahl an Objekten ist in der Praxis wahrscheinlich nur noch über automatisierte Tools (ggf. mit eigenem, strukturiertem Katalog) wartbar.
   

• Applikationen müssen bei Abfragen der Gruppenmitgliedschaften / -objekte sogenannte „Attribute Range Retrieval“ Abfragen beherrschen, d.h. inkrementelle Abfragen von jeweils 1.500 Attributwerten (siehe „Enumerating Groups That Contain Many Members“ https://msdn2.microsoft.com/en-us/library/ms676302.aspx). Können die verwendeten Anwendungen diese Funktionalität nicht gewährleisten, ist eine Abfrage der Gruppenmitgliedschaften schon ab 1.500 Gruppenmitgliedern / -objekten nicht mehr möglich.
  Man muß jedoch dazu sagen, daß dann höchstwahrscheinlich auch andere Probleme auftreten, hier bilden die Gruppenmitgliedschaften keine Ausnahme. Es ist jedoch ein Punkt mehr, den man im Auge behalten sollte.

• Die DCs des Forests können - je nach Leistungsfähigkeit - bei der Gruppenverarbeitung durch die hohe Last beim Auslesen der Gruppenmitgliedschaften an Leistungsgrenzen stoßen.

• Eine Zuordnung von dermaßen vielen Objekten z.B. in Universelle Gruppen kann problematisch werden, sollten häufig Änderungen vorgenommen werden müssen (Stichwort: Global Catalog). Die „Link Value Replication“ ab Windows Server 2003 entschärft das Problem zwar, ist jedoch in bestimmten Konstellationen (z.B. Initialreplikation zu einem neuen DC) nicht wikrlich gut nutzbar.

• Auch im Windows Server 2003 Forest Modus existieren einige Einschränkungen, die das Schreiben von mehr als 5.000 Einträgen in die Active Directory Datenbank limitieren. So ist es lediglich möglich, 5.000 Updates in einer einzigen Transaktion in die Datenbank zu schreiben. Das Hinzufügen von mehr als 5.000 Gruppenobjekten kann also nicht auf einmal erfolgen, sondern müßte in 5.000er Schritten erfolgen (siehe „Originating Updates“ unter https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbh_rep_qusc.mspx). Dies muß programmatisch ebenfalls möglich sein wie auch das "Attribute Range Retrieval" (siehe oben).

"Ok", könnte man sich jetzt denken, in den "Domain Users" sind standardmäßig doch auch mehr Objekte vorhanden, wenn in der Domäne mehrere tausend Benutzer angelegt sind.

Das ist natürlich grundsätzlich korrekt - nur werden diese standardmäßig nicht bei allen Abfragen angezeigt bzw. ausgelesen. Standardmäßig sind diese Gruppen nämlich die "Primary Group" von den besagten Benutzerobjekten. Da die Primary Group bei LDAP-Abfragen nicht mit ausgelesen bzw. deren Mitglieder ("MemberOf"-Attribut) nicht in der Ergebnisliste zurückgegeben werden, ist hier per default nicht mit einer erhöhten Last zu rechnen - es sei denn, man möchte die GUI zur Verwaltung dieser Gruppe verwenden (siehe oben).

Kurzer Hinweis am Rande: Möchte man auch die Primary Group in LDAP-Abfragen auslesen, kann beispielsweise ADSI genutzt werden:  "How to use native ADSI components to find the primary group" https://support.microsoft.com/default.aspx?scid=kb;EN-US;321360)

Aus den genannten Gründen ergeben sich folgende Empfehlungen:

• Sollte es in der entsprechenden Umgebung möglich sein, sollten mehrere Gruppen angelegt und genutzt werden (z.B. mit einer Einteilung nach Standorten, Managementbereich, nach Anfangsbuchstaben des Objekts o.ä.) Eine Grenze von maximal 5.000 Gruppenmitgliedern muß seit FFL Windows Server 2003 - wie oben angesprochen - zwar nicht mehr eingehalten werden, wird jedoch als Best Practice weiterhin empfohlen. Ich persönlich würde weiterhin gleich die 1.500er Grenze bezüglich des "Attribute Range Retrievals" (siehe oben) einhalten.

• Der Scope / Bereich dieser Gruppen ("Domain Local", "Global" oder "Universal") sollte unbedingt überdacht werden, je nachdem ob die Gruppen im Globalen Katalog geführt werden sollen oder nicht (siehe https://technet2.microsoft.com/windowsserver/en/library/79d93e46-ecab-4165-8001-7adc3c9f804e1033.mspx).

• Auch in Bezug auf ein etwaiges Backup & Recovery Szenario sind solch riesige Gruppen nicht empfehlenswert. Dies kann schon bei einem unbeabsichtigten Löschvorgang massive Konsequenzen nach sich ziehen bzw. beim Rücksichern einen sehr hohen Zeitaufwand nach sich ziehen (Stichwort: Replikation und Wiederherstellung der Mitgliedschaften).
  Diesbezüglich sollte folgender KB-Artikel ebenfalls Beachtung finden: "After you restore deleted objects by performing an authoritative restoration on a Windows Server 2003-based domain controller, the linked attributes of some objects are not replicated to the other domain controllers" https://support.microsoft.com/default.aspx?scid=kb;EN-US;937855

  Update 30.09.2009: Weiterführend ist dieser Blog-Eintrag von uns das Tehma ebenfalls auf: https://blogs.technet.com/deds/archive/2009/02/06/gesichert-sicher-auch-wieder-hergestellt.aspx

Gruß, Fabian.