Objekte & Struktur: Gruppen, OUs und Delegation, die skalieren
Einführung · 8 Abschnitte · ~7 Min Lesezeit · Stand
Die Bausteine: Objekte im Verzeichnis
Active Directory verwaltet Objekte: Benutzer, Computer, Gruppen und Dienstkonten. Die eigentliche Kunst ist nicht, sie anzulegen — sondern sie so zu strukturieren, dass Rechtevergabe, Delegation und Group Policy auch mit 500 Benutzern und drei Standorten noch wartbar bleiben.
Dieses Modul dreht sich um drei Achsen, die im Alltag am häufigsten schieflaufen: Gruppen-Scoping, OU-Design und die Wahl des richtigen Dienstkontos. Wer sie beherrscht, vermeidet Rechte-Wildwuchs, ungewollt breite Admin-Rechte und statische Passwörter.
Gruppen-Scopes: global, domain-local, universal
Jede Sicherheitsgruppe hat einen Scope, der festlegt, wer Mitglied sein darf, wo die Gruppe Rechte bekommen kann und — wichtig für den Betrieb — ob ihre Mitgliedschaft in den Global Catalog (GC) repliziert wird.
| Global | Bündelt Konten nach Rolle aus der eigenen Domäne. Kann in jeder Domäne Rechte erhalten. Mitgliedschaft nicht im GC repliziert. |
|---|---|
| Domain-local | Wird an der Ressource vergeben. Nimmt Konten und Gruppen aus dem ganzen Forest auf, gewährt Rechte aber nur in der eigenen Domäne. Nicht im GC repliziert. |
| Universal | Gilt forest-weit und kann Mitglieder aus mehreren Domänen aufnehmen. Aber: die Mitgliedschaft wird in den GC repliziert. |
AGDLP: die Verschachtelung, die skaliert
Das Standardmuster für Rechtevergabe heißt AGDLP: Accounts kommen in Globale Gruppen (nach Rolle), diese werden in Domain-Local-Gruppen (nach Ressource) verschachtelt, und die Permission wird ausschließlich an die domain-lokale Gruppe vergeben.
Der Gewinn: Wer eine Rolle wechselt, wird in einer globalen Gruppe umgehängt — nicht an dutzenden ACLs. Wer eine Ressource neu berechtigt, ändert eine domain-lokale Gruppe. Rechte und Rollen bleiben entkoppelt.
OU-Design: für Delegation und GPO, nicht fürs Orgchart
Eine Organizational Unit (OU) ist ein Container, an den du zwei Dinge binden kannst: delegierte Verwaltungsrechte und Group-Policy-Objekte (GPOs). Genau danach — und nur danach — solltest du OUs schneiden. Die Frage lautet nicht „wie sieht das Organigramm aus?“, sondern „welche Objekte will ich gemeinsam verwalten und gleich konfigurieren?“.
Ein OU-Baum, der 1:1 das Orgchart abbildet, sieht ordentlich aus, ist aber betrieblich wertlos, sobald sich Delegations- und GPO-Grenzen nicht an Abteilungsgrenzen halten — was fast immer der Fall ist.
Delegation of Control statt breiter Built-in-Gruppen
Soll der Helpdesk nur Passwörter einer Abteilung zurücksetzen, ist die richtige Antwort Delegation of Control: gezielte Rechte (z. B. „Reset Password“) auf einer OU. Der Delegation-of-Control-Assistent oder direkte ACL-Delegation auf der OU macht das nachvollziehbar und eng begrenzt.
Der bequeme Irrweg ist, die Person in eine Built-in-Gruppe wie Account Operators oder gar Domain Admins zu stecken. Diese Gruppen wirken domänenweit und weit über den Bedarf hinaus — Account Operators darf die meisten Konten der gesamten Domäne verwalten.
Dienstkonten: gMSA gegen die Alternativen
Eine Windows-Dienst-Anwendung braucht eine Netzwerk-Identität. Der moderne Default ist ein group Managed Service Account (gMSA): Das Passwort wird von AD automatisch verwaltet und rotiert, ist maschinell lang und zufällig, und nur die autorisierten Hosts können es abrufen. Ein gMSA trägt einen SPN (für Kerberos) und erlaubt keine interaktive Anmeldung.
| gMSA | Passwort auto-rotiert, an Hosts gebunden, SPN-fähig. Braucht einen KDS-Root-Key im Forest. |
|---|---|
| Normales User-Dienstkonto | Statisches Passwort, oft „läuft nie ab“ — muss manuell rotiert werden und ist ein dauerhaftes Kerberoasting-Ziel. |
| Geteiltes Konto | Ein Konto für mehrere Dienste/Personen: keine Nachvollziehbarkeit, großer Blast-Radius bei Leak. |
Universal vs. global: die Replikationskosten
Universelle Gruppen sind verlockend, weil sie forest-weit gelten. Der Haken: Ihre Mitgliedschaft liegt im Global Catalog und wird bei jeder Änderung an alle GCs im Forest repliziert. Bei einer großen, oft geänderten Mitgliedschaft erzeugt das dauernd Replikationsverkehr.
Die saubere Lösung: Die häufig wechselnden Mitglieder in eine globale Gruppe legen und nur diese stabile globale Gruppe in die universelle Gruppe verschachteln. Dann bleibt die direkte Mitgliedschaft der universellen Gruppe konstant — die GC-Replikation bleibt minimal. Universelle Gruppen sind für stabile, forest-weite Mitgliedschaften gedacht.
Zusammenfassung — gleich entscheidest du selbst
Du kennst jetzt die Achsen: Gruppen-Scopes und AGDLP, OU-Design für Delegation und GPO, Delegation of Control statt breiter Rechte, die Wahl des Dienstkontos und die GC-Replikationskosten universeller Gruppen.