# Objekte & Struktur: Gruppen, OUs und Delegation

> Gruppen-Scoping nach AGDLP, OU-Design für Delegation und Group Policy statt Orgchart, Delegation of Control und die richtige Wahl von Dienstkonten.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/objects-and-structure  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Objekte & Struktur: Gruppen, OUs und Delegation, die skalieren

### 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.

> **Trennschärfe:** **Gruppen** bündeln Rechte. **OUs** bündeln Verwaltung (Delegation + GPO). Das sind zwei verschiedene Werkzeuge — verwechsle sie nie.

### 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**. |

> **Merksatz:** **Global = nach Rolle. Domain-local = nach Ressource. Universal = forest-weit, aber teurer.**

### AGDLP: die Verschachtelung, die skaliert

Das Standardmuster für Rechtevergabe heißt **AGDLP**: **A**ccounts kommen in **G**lobale Gruppen (nach Rolle), diese werden in **D**omain-**L**ocal-Gruppen (nach Ressource) verschachtelt, und die **P**ermission wird **ausschließlich an die domain-lokale Gruppe** vergeben.

_[Abbildung: Accounts → globale Rollengruppe → domain-lokale Ressourcengruppe → Berechtigung. Rechte hängen nur an der letzten Stufe.]_

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.

> **Warum nur an die DL-Gruppe:** Rechte direkt an Benutzer oder an globale Gruppen zu hängen, streut Berechtigungen über die ganze Umgebung. Eine ACL pro Ressourcengruppe ist auditierbar; verstreute ACLs sind es nie.

### 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.

> **Häufige Falle:** Die Standard-Container `Users` und `Computers` sind **keine OUs**. An sie lässt sich **kein GPO linken** und keine saubere Delegation hängen. Neue Konten gehören in eigens angelegte OUs.

### 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.

> **Prinzip:** **Least Privilege ist eine Frage des Scopes.** Delegiere die konkrete Aktion auf dem konkreten Objektbaum — nicht die Mitgliedschaft in einer mächtigen Gruppe.

### 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. |

> **Merksatz:** Ein gutes Dienstkonto hat eine **eigene Identität**, ein **verwaltetes Passwort** und **nur die nötigen Rechte** — gMSA liefert die ersten beiden Punkte ab Werk.

### 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.

> **Kalibriert:** Moderne AD-Forests replizieren nur **geänderte** Mitgliedswerte (Linked Value Replication), nicht die ganze Liste — der Effekt ist also kleiner als früher, aber häufige Änderungen lösen weiterhin forest-weite GC-Replikation aus. Das Design-Prinzip bleibt.

### 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.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete AD-Szenarien selbst — und siehst pro Option, **warum** sie trägt oder kippt.

## Quellen

- Microsoft Learn — Active Directory security groups: Gruppenbereich (global, domänenlokal, universal) und Global-Catalog-Replikation
- Microsoft Learn — Group Managed Service Accounts (gMSA) Overview
- Microsoft Learn — Delegating administration of OUs und Best Practices für die Delegierung der AD-Verwaltung
- Microsoft Learn — How the Global Catalog and Linked Value Replication work
- Microsoft Learn — Active Directory security groups: Gruppenbereich (global, domänenlokal, universal)
- Microsoft Learn — Best Practices für Gruppenverschachtelung (AGDLP)
- Microsoft Learn — Active Directory security groups: Gruppenbereich und Gruppenverschachtelung
- Microsoft Learn — AGDLP: Role-based access control mit verschachtelten Gruppen
- Microsoft Learn — Organizational Units: Zweck von OUs (Delegation und Group Policy)
- Microsoft Learn — Group Policy: GPOs lassen sich nicht an die Standard-Container Users/Computers linken
- Microsoft Learn — Delegating administration by using OU objects (Delegation of Control)
- Microsoft Learn — Active Directory security groups: Account Operators (Umfang der Built-in-Gruppe)
- Microsoft Learn — Service accounts: Auswahl zwischen gMSA, Standalone-Managed-Account und User-Konto
- Microsoft Learn — Active Directory security groups: Universal-Gruppen und Global-Catalog-Replikation der Mitgliedschaft
- Microsoft Learn — Global Catalog und Linked Value Replication (Verhalten bei Gruppenänderungen)
- Microsoft Learn — Active Directory security groups and group scope
- Microsoft Learn — Global Catalog and universal group membership