Objekte & Struktur: Gruppen, OUs und Delegation

„Nimm den Helpdesk einfach in Account Operators auf, die dürfen genau so etwas.“ Der Satz klingt nach Least Privilege und ist das Gegenteil: Die Gruppe wirkt domänenweit, und ihre Mitglieder dürfen sich laut Dokumentation lokal an Domain Controllern anmelden. Dieses Modul zeigt, wie Struktur in Active Directory wirklich trägt — die drei Gruppen-Scopes samt ihrer Umwandlungsregeln, AGDLP als Entkopplung von Rolle und Ressource, der OU-Schnitt nach Delegation und Richtlinie statt nach Organigramm, verwaltete Dienstkonten und die Stelle, an der ihre Sicherheitsgrenze tatsächlich liegt. Dazu die Obergrenze, die niemand einplant: Ab einer gewissen Zahl von Mitgliedschaften passt das Kerberos-Token nicht mehr — und die Anmeldung scheitert mit einem Fehler, der nach einem Bug in der Webanwendung aussieht.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Zwei Werkzeuge, die ständig verwechselt werden

Objekte anzulegen ist der einfache Teil. Die Arbeit beginnt bei der Frage, wie man sie so ordnet, dass Rechtevergabe, Delegation und Group Policy auch bei fünftausend Objekten noch nachvollziehbar bleiben. Dabei stehen zwei Werkzeuge zur Verfügung, und fast jeder Strukturfehler in AD entsteht daraus, dass man das eine für die Aufgabe des anderen einsetzt.

Gruppe — Bündelt Rechte. Eine Security-Gruppe hat eine SID, steht in Zugriffssteuerungslisten und beantwortet die Frage: *Wer darf was?*

Organizational Unit (OU) — Bündelt Verwaltung. An eine OU lassen sich delegierte Rechte und Group-Policy-Objekte binden. Sie beantwortet die Frage: *Wer verwaltet was, und welche Richtlinien gelten dort?*

MerksatzEine OU vergibt keine Berechtigungen auf Dateien, und eine Gruppe kann kein GPO empfangen. Wer Zugriff regeln will, nimmt Gruppen. Wer Verwaltung und Richtlinien regeln will, nimmt OUs. Es gibt keinen Fall, in dem eine der beiden die andere ersetzt.

Gruppen-Scopes: wer rein darf, wo es zählt

Jede Security-Gruppe hat neben ihrem Typ einen Scope. Er legt drei Dinge fest: welche Objekte Mitglied werden dürfen, in welchem Bereich die Gruppe Berechtigungen bekommen kann, und ob ihre Mitgliederliste in den Global Catalog repliziert wird. Diese drei Eigenschaften hängen zusammen und sind der Grund, warum es überhaupt drei Scopes gibt.

Global: Mitglieder: Konten und globale Gruppen der eigenen Domäne. Berechtigungen: in jeder Domäne des Forests und in vertrauenden Domänen. Mitgliedschaft nicht im Global Catalog.
Domain-local: Mitglieder: Konten und Gruppen aus jeder Domäne des Forests und aus vertrauten Domänen. Berechtigungen: nur in der eigenen Domäne. Mitgliedschaft nicht im Global Catalog.
Universal: Mitglieder: Konten und Gruppen aus jeder Domäne des Forests. Berechtigungen: forest-weit. Mitgliedschaft liegt im Global Catalog.

Die Merkhilfe, die trägtGlobal = nach Rolle („alle Vertriebsmitarbeiter“), Domain-local = nach Ressource („Zugriff auf Ordner Projekt-Nord“), Universal = forest-weit, aber mit Replikationskosten. Wer diese drei Sätze im Kopf hat, trifft die Wahl fast immer richtig.

Umwandeln geht — aber nicht immer

Ein Scope ist keine irreversible Entscheidung. Die Umwandlung ist aber an dokumentierte Bedingungen geknüpft, und die überraschen regelmäßig mitten in einer Migration — weil die Regel nicht an der Gruppe selbst hängt, sondern an ihren Beziehungen zu anderen Gruppen.

Global → Universal: nur, wenn die Gruppe nicht Mitglied einer anderen globalen Gruppe ist
Domain-local → Universal: nur, wenn die Gruppe keine andere domain-lokale Gruppe enthält
Universal → Global: nur, wenn die Gruppe keine andere universelle Gruppe enthält
Universal → Domain-local: nur, wenn die Gruppe nicht Mitglied einer anderen universellen Gruppe ist

Worauf das im Betrieb hinausläuftZweimal zählt, worin die Gruppe steckt, zweimal, was sie enthält. Eine tief verschachtelte Gruppenlandschaft lässt sich deshalb oft nicht in der gewünschten Reihenfolge umbauen: Man muss erst die Verschachtelung auflösen, dann umwandeln, dann neu verschachteln. Wer das im Wartungsfenster entdeckt, hat den Umbau falsch geplant.

AGDLP: die Verschachtelung, die skaliert

Aus den Scope-Eigenschaften folgt ein Muster, das Microsoft seit Jahrzehnten empfiehlt und das den Kürzel AGDLP trägt. Es ist keine Konvention um der Ordnung willen, sondern die einzige Anordnung, die Rollen und Ressourcen sauber entkoppelt.

Accounts — die Benutzer- und Computerkonten↓Global — je Rolle eine globale Gruppe, etwa G-Vertrieb-Innendienst↓Domain Local — je Ressource eine domain-lokale Gruppe, etwa DL-Projekt-Nord-Aendern↓Permission — die Berechtigung steht ausschließlich an der domain-lokalen Gruppe

Rolle rein, Ressource raus

Konten in Rollengruppen, Rollengruppen in Ressourcengruppen, Rechte nur an der Ressourcengruppe. Jede Ebene hat genau einen Grund, sich zu ändern.

Der Gewinn zeigt sich beim Ändern. Wechselt jemand die Rolle, hängst du ein Konto in einer globalen Gruppe um — nicht an dreißig verstreuten Zugriffssteuerungslisten. Bekommt eine Ressource neue Berechtigte, änderst du eine domain-lokale Gruppe und fasst keine einzige Rolle an.

Der Preis, den man nennen mussAGDLP kostet Objekte: Für jede Ressource entsteht mindestens eine zusätzliche Gruppe, oft zwei oder drei je Zugriffsstufe. In kleinen Umgebungen wirkt das wie Bürokratie, und das ist es dort auch. Der Nutzen entsteht erst mit der Zahl der Ressourcen — dafür dann schlagartig, weil eine Zugriffssteuerungsliste mit einer einzigen Gruppe darin auditierbar ist und eine mit vierzig Einzeleinträgen nicht.

Universelle Gruppen und der Global Catalog

Universelle Gruppen sind verlockend, weil sie über Domänengrenzen hinweg funktionieren. Ihr Preis steht in der Architektur: Die Mitgliedschaft universeller Gruppen liegt im Global Catalog und wird bei jeder Änderung an alle GC-Server des Forests repliziert.

Daraus folgt eine Abhängigkeit, die viele erst im Ausfall bemerken. Bei der Anmeldung stellt der Domain Controller das Zugriffstoken zusammen und muss dafür alle Gruppenmitgliedschaften kennen — auch die universellen. Weil der Global Catalog der forest-weite Ort dieser Mitgliedschaften ist, ist der Zugriff auf einen GC-Server laut Dokumentation eine Voraussetzung für die Authentifizierung in einem Forest mit mehreren Domänen.

Die saubere BauformHäufig wechselnde Mitglieder gehören nicht direkt in eine universelle Gruppe. Leg sie je Domäne in eine globale Gruppe und verschachtele nur diese stabile globale Gruppe in die universelle. Dann ändert sich die direkte Mitgliedschaft der universellen Gruppe fast nie — und damit auch die forest-weite GC-Replikation nicht. Moderne Forests replizieren zwar über Linked Value Replication nur die geänderten Einzelwerte statt der ganzen Liste, aber jede Änderung löst weiterhin Replikation über den gesamten Forest aus.

OU-Design: nach Delegation und GPO, nicht nach Orgchart

An eine OU lassen sich genau zwei Dinge binden: delegierte Verwaltungsrechte und Group-Policy-Objekte. Also gibt es genau zwei zulässige Fragen für den Schnitt eines OU-Baums: Wer soll das hier verwalten dürfen? und Welche Richtlinie soll hier gelten? Alles andere ist Dekoration.

Ein OU-Baum, der das Organigramm nachbaut, sieht in der Konsole aufgeräumt aus und ist betrieblich wertlos, sobald Delegations- und Richtliniengrenzen nicht mit Abteilungsgrenzen zusammenfallen — was praktisch immer der Fall ist. Der Laptop einer Vertriebsmitarbeiterin braucht dieselbe Richtlinie wie der Laptop eines Entwicklers und eine andere als der Server im selben Fachbereich. Die tragfähige Trennung verläuft deshalb fast überall zuerst zwischen Benutzern und Computern, dann nach Verwaltungsverantwortung.

Die Falle mit den Standard-ContainernCN=Users und CN=Computers sind keine OUs, sondern Container der Klasse container. Richtlinien lassen sich laut Dokumentation nur an OUs verknüpfen, nicht an Objekte dieser Klasse. Wer neue Konten dort liegen lässt — und dort landen sie ohne Zutun —, hat Objekte in der Umgebung, die keine einzige Richtlinie erfasst. Der Effekt ist tückisch, weil nichts fehlschlägt: Die Objekte funktionieren, sie sind nur ungeregelt. Mit redirusr und redircmp lässt sich das Standardziel einmalig auf eigene OUs umlenken.

Und der Preis dafürDie Umlenkung hat eine Kehrseite, die dieselbe Dokumentation nennt: CN=Users und CN=Computers sind systemgeschützte Objekte und lassen sich gar nicht löschen. Eine OU dagegen kann ein Administrator versehentlich samt Inhalt entfernen. Wer auf eigene OUs umlenkt, sollte deshalb den Schutz gegen versehentliches Löschen setzen — sonst tauscht man ein Richtlinienproblem gegen ein Wiederherstellungsproblem. Zusätzlich hängen einzelne Anwendungen fest an den Standard-Containern; das gehört vor der Umstellung geprüft.

Delegation statt Mitgliedschaft in mächtigen Gruppen

Der Helpdesk soll Passwörter der Vertriebsabteilung zurücksetzen dürfen — sonst nichts. Die richtige Antwort ist Delegation of Control: eine gezielte Berechtigung, etwa Reset Password, auf einer OU, vergeben an eine Gruppe. Der Geltungsbereich ist damit genau der Objektbaum, um den es geht.

Der bequeme Irrweg ist, die Leute stattdessen in eine eingebaute Gruppe zu stecken, die „schon ungefähr passt“. Account Operators ist der klassische Fall: Der Name klingt harmlos und begrenzt, die Gruppe wirkt aber domänenweit auf nahezu alle Konten.

Der Satz, der die Diskussion beendetLaut Dokumentation können Mitglieder von Account Operators die meisten Kontotypen anlegen und ändern — und sich lokal an Domain Controllern anmelden. Damit ist die Gruppe keine Helpdesk-Rolle, sondern eine Tier-0-Exposition: Wer sich an einem DC anmelden darf, steht im Wirkungsbereich jedes Angriffs, der dort Anmeldedaten abgreift. Eine „begrenzte“ Gruppe ist sie nur dem Namen nach.

MerksatzLeast Privilege ist eine Frage des Geltungsbereichs, nicht der guten Absicht. Delegiere die konkrete Aktion auf dem konkreten Objektbaum — nicht die Mitgliedschaft in einer Gruppe, deren Reichweite du nicht vollständig aufzählen kannst.

Dienstkonten: vier Optionen, drei davon schlecht

Ein Dienst, der über das Netz auf Ressourcen zugreift, braucht eine Identität. Vier Wege sind üblich, und sie unterscheiden sich vor allem darin, wer das Passwort kennt und wer es rotiert.

gMSA: Passwort wird von AD verwaltet und automatisch rotiert, kennt niemand. Funktioniert über mehrere Hosts hinweg. Der empfohlene Standard.
Normales Benutzerkonto: Passwort steht in einer Dokumentation, einem Skript oder im Kopf einer Person. Rotation passiert praktisch nie, weil sie einen Dienst-Neustart erzwingt.
Geteiltes Konto für mehrere Dienste: Ein kompromittiertes Passwort öffnet alle beteiligten Dienste gleichzeitig; Rotation ist wegen der Kopplung faktisch blockiert.
`LocalSystem`: Spart ein Konto, tritt im Netz aber als Computerkonto auf. Rechte lassen sich nicht auf den Dienst begrenzen, sondern nur auf die ganze Maschine.

gMSA: wie es wirklich funktioniert

Beim gMSA berechnet der Domain Controller das Passwort aus einem Schlüssel des Key Distribution Service und Attributen des Kontos. Berechtigte Hosts holen sich den aktuellen Wert per LDAP vom DC ab. Voraussetzung im Forest ist genau ein Objekt: ein KDS-Root-Key; ob er existiert, belegt Ereignis-ID 4004 im Operational-Log von KdsSvc.

KDS-Root-Key im Forest anlegen, falls noch keiner existiert→New-ADServiceAccount mit -PrincipalsAllowedToRetrieveManagedPassword <Gruppe> ausführen→Die berechtigten Hosts in diese Gruppe aufnehmen→Den Dienst auf den Hosts auf das gMSA umstellen — ohne Passwort in der Konfiguration

Wo die Sicherheitsgrenze wirklich liegtNicht im Konto, sondern in -PrincipalsAllowedToRetrieveManagedPassword. Wer in dieser Gruppe steht, kann das Dienstkonto sein. Eine zu weit gefasste Gruppe — etwa Domain Computers — macht das verwaltete Passwort für jede Maschine der Domäne abrufbar und hebt den gesamten Gewinn auf. Diese Gruppe ist der Ort, an den ein Audit zuerst schaut.

Wo gMSA nicht trägtDie Grenze ist die Anwendung, nicht das Verzeichnis. Ein gMSA funktioniert nur, wenn der Dienst verwaltete Dienstkonten unterstützt — er darf das Passwort nie selbst zu sehen bekommen. Fachanwendungen, die Anmeldedaten in ihrer eigenen Konfigurationsdatei erwarten, oder geplante Aufgaben in älteren Konstruktionen scheitern daran. Dann bleibt ein reguläres Konto mit dokumentierter Rotation die ehrlichere Lösung als ein gMSA, das man mit Hilfskonstruktionen erzwingt. Prüfe die Unterstützung vor dem Entwurf, nicht bei der Umstellung.

Die Falle beim VerschlüsselungstypDer DC wählt die Verschlüsselung des Kerberos-Tickets anhand von msDS-SupportedEncryptionTypes. Fehlt das Attribut, behandelt er den Host so, als beherrsche er keine stärkeren Verfahren. Ist auf dem Host zugleich RC4 abgeschaltet — heute die Regel —, schlägt die Authentifizierung laut Dokumentation immer fehl. Für verwaltete Dienstkonten gehört AES deshalb ausdrücklich gesetzt; der Fehler sieht sonst nach einem Konto- oder Rechteproblem aus und ist keins.

Verschachtelung hat eine Obergrenze: das Kerberos-Token

AGDLP vermehrt Gruppenmitgliedschaften — das ist der Sinn der Sache. Es gibt dabei aber eine harte, oft übersehene Obergrenze. Bei der Anmeldung baut Windows ein Autorisierungs-Token, das die SID des Benutzers, die SIDs aller seiner Gruppen und die SIDs aus sIDHistory enthält. Kerberos legt dieses Token in der PAC innerhalb des Tickets ab, und dieses Ticket hat eine feste Höchstgröße (MaxTokenSize).

Das Symptom, das nach etwas anderem aussiehtWird das Token zu groß, scheitert die Anmeldung — aber nicht mit „zu viele Gruppen“. Typisch ist HTTP 400 — Request Header too long in einer Webanwendung, dazu Gruppenrichtlinien, die nicht mehr angewendet werden. Der beste Hinweis auf die wahre Ursache: NTLM funktioniert weiter, Kerberos nicht. Wer das Muster kennt, spart sich die Fehlersuche in der Anwendung.

Interessant ist, wie unterschiedlich die Mitgliedschaften ins Gewicht fallen. Die dokumentierte Abschätzung lautet TokenSize = 1200 + 40d + 8s. Dabei zählt d die Mitgliedschaften in universellen Gruppen außerhalb der eigenen Domäne sowie die SIDs in sIDHistory; s zählt globale und domain-lokale Mitgliedschaften sowie universelle innerhalb der eigenen Domäne.

Was daraus folgtEine domänenfremde universelle Mitgliedschaft oder eine SID aus sIDHistory kostet im Token das Fünffache einer gewöhnlichen Gruppenmitgliedschaft. Genau deshalb ist AGDLP mit globalen und domain-lokalen Gruppen nicht nur sauberer, sondern auch billiger — und deshalb ist eine nach einer Migration liegengebliebene sIDHistory nicht bloß Altlast, sondern ein aktiver Verbraucher knappen Ticket-Platzes. Als Faustzahl nennt die Dokumentation, dass ab etwa 120 universellen Gruppen der Standardwert nicht mehr reicht. Ab Windows Server 2012 lässt sich per Richtlinie Warnung für große Kerberos-Tickets ein Ereignis mit der ID 31 protokollieren, bevor es jemanden aussperrt.

Durchgerechnet: Zugriff für ein Projekt über zwei Domänen

Von der Anforderung zur Gruppenstruktur

Szenario

Ein Projektteam aus den Domänen nord.corp und sued.corp braucht Schreibzugriff auf \\fs01\projekt-falcon, der Fileserver steht in nord.corp. Die Mitgliederliste ändert sich wöchentlich.

Anforderungen

Die Berechtigung darf an genau einer Stelle stehen
Wöchentliche Änderungen dürfen keine forest-weite Replikation auslösen
Ein Rollenwechsel darf keine Zugriffssteuerungsliste anfassen

Schritte

Je Domäne eine globale Rollengruppe: G-Projekt-Falcon in nord.corp und dieselbe in sued.corp. Hier landen die Konten, hier passieren die wöchentlichen Änderungen — global heißt: keine GC-Replikation der Mitgliedschaft.
Eine domain-lokale Ressourcengruppe DL-Falcon-Aendern in nord.corp, wo der Fileserver steht. Domain-local darf Mitglieder aus jeder Domäne des Forests aufnehmen — genau der Grund, warum dieser Scope existiert.
Beide globalen Gruppen in DL-Falcon-Aendern verschachteln.
Die Berechtigung Ändern nur an DL-Falcon-Aendern vergeben. In der Zugriffssteuerungsliste des Ordners steht damit ein einziger Eintrag.
Gegenprobe: Keine universelle Gruppe nötig, obwohl zwei Domänen beteiligt sind — die domain-lokale Gruppe erledigt die Domänenüberschreitung auf der Ressourcenseite.

Merksatz: Zwei Domänen sind für sich noch kein Grund für eine universelle Gruppe. Erst wenn die Berechtigung in mehreren Domänen gebraucht wird, ist der universelle Scope die richtige Antwort.

Prüf dich selbst, bevor es zählt

Kurzcheck

Der Helpdesk soll in der OU Vertrieb-Benutzer Passwörter zurücksetzen dürfen. Ein Kollege schlägt vor, die Helpdesk-Gruppe einfach in Account Operators aufzunehmen — „die dürfen genau so etwas“. Was spricht dagegen?

Nichts Grundsätzliches, die Gruppe ist für begrenzte Kontoverwaltung vorgesehen.
Die Gruppe wirkt domänenweit statt auf der OU — und ihre Mitglieder dürfen sich lokal an Domain Controllern anmelden.
Account Operators ist eine Distribution-Gruppe und kann deshalb keine Rechte tragen.

Treffer. Richtig. Beides steht so in der Dokumentation. Der lokale Anmeldepfad auf DCs macht aus einer vermeintlichen Helpdesk-Rolle eine Tier-0-Exposition.

Damit stehen die Achsen dieses Moduls: Gruppen-Scopes und ihre Umwandlungsregeln, AGDLP als Entkopplung von Rolle und Ressource, die GC-Kosten universeller Gruppen, OU-Schnitt nach Delegation und Richtlinie, Delegation of Control statt mächtiger Mitgliedschaften und die Wahl des Dienstkontos.

Gleich im CheckIn den folgenden Entscheidungen wählst du für konkrete Strukturfragen selbst. Achte bei jeder Option darauf, welche der beiden Fragen sie eigentlich beantwortet — *wer darf was* oder *wer verwaltet was*. Die meisten falschen Antworten verwechseln genau das.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität20 Primärquellen · zuletzt geprüft: 2026-09-06

01learn.microsoft.com/en-us/windows-server/ident…tand-security-groups
02learn.microsoft.com/en-us/previous-versions/wi…003/cc737410(v=ws.10
03learn.microsoft.com/en-us/windows-server/secur…ce-accounts-overview
04learn.microsoft.com/en-us/windows-server/secur…ged-service-accounts
05learn.microsoft.com/en-us/windows-server/ident…ing-active-directory
06learn.microsoft.com/en-us/windows-server/ident…security-identifiers
07learn.microsoft.com/en-us/troubleshoot/windows…computers-containers
08learn.microsoft.com/en-us/troubleshoot/windows…er-belongs-to-groups
09Microsoft Learn — Active Directory security groups: Gruppenbereich (global, domänenlokal, universal)
10Microsoft Learn — Best Practices für Gruppenverschachtelung (AGDLP)
11Microsoft Learn — Active Directory security groups: Gruppenbereich und Gruppenverschachtelung
12Microsoft Learn — AGDLP: Role-based access control mit verschachtelten Gruppen
13Microsoft Learn — Organizational Units: Zweck von OUs (Delegation und Group Policy)
14Microsoft Learn — Group Policy: GPOs lassen sich nicht an die Standard-Container Users/Computers linken
15Microsoft Learn — Group Managed Service Accounts (gMSA) Overview
16Microsoft Learn — Service accounts: Auswahl zwischen gMSA, Standalone-Managed-Account und User-Konto
17Microsoft Learn — Active Directory security groups: Universal-Gruppen und Global-Catalog-Replikation der Mitgliedschaft
18Microsoft Learn — Global Catalog und Linked Value Replication (Verhalten bei Gruppenänderungen)
19Microsoft Learn — Delegating administration by using OU objects (Delegation of Control)
20Microsoft Learn — Active Directory security groups: Account Operators (Umfang der Built-in-Gruppe)