# AD-Grundlagen: Directory, Forest und die drei Säulen

> Das mentale Modell hinter Active Directory — was ein Verzeichnisdienst leistet, warum der Forest die Sicherheitsgrenze ist, wie Multi-Master-Replikation und DNS zusammenspielen und welche Objekte AD verwaltet.

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

## AD-Grundlagen: Directory, Forest und die drei Säulen

### Was ein Verzeichnisdienst leistet

**Active Directory Domain Services (AD DS)** ist ein **Verzeichnisdienst**: eine zentrale, replizierte Datenbank aller Identitäten und Ressourcen einer Organisation — Benutzer, Computer, Gruppen. Statt auf jedem Windows-Rechner eigene **lokale Accounts** zu pflegen, gibt es eine Identität, die überall gilt.

Der Gewinn ist nicht „ein Server mehr“, sondern vier Dinge, die lokale Accounts strukturell nicht liefern können:

- **Zentrale Identität**: ein Konto, an jedem Domänenrechner gültig — deaktivieren an einer Stelle sperrt überall.
- **Single Sign-On (SSO) über Kerberos**: einmal anmelden, dann ohne erneute Passworteingabe auf Dienste zugreifen. Kerberos ist das Authentifizierungsprotokoll der Domäne.
- **Zentrale Richtlinien (Group Policy / GPO)**: Konfiguration und Sicherheitsvorgaben werden zentral gesetzt und automatisch durchgesetzt.
- **Zentrale Autorisierung**: Rechte hängen an Gruppen, nicht an einzelnen Maschinen.

> **Merksatz:** Lokale Accounts skalieren nicht: Sie leben pro Maschine. Ein Verzeichnisdienst macht Identität zu **einer** verwalteten Sache — das ist der eigentliche Sprung, nicht die reine Zentralisierung von Daten.

### Forest, Domain, OU — und wo die Sicherheitsgrenze liegt

AD ist hierarchisch aufgebaut. Drei Ebenen musst du auseinanderhalten, weil man sie ständig verwechselt:

|  |  |
| --- | --- |
| **Forest** | die oberste Grenze. Enthält eine oder mehrere Domänen. **Die Sicherheitsgrenze.** |
| **Domain** | eine administrative und Replikations-Einheit im Forest. **Keine** Sicherheitsgrenze. |
| **OU (Organizational Unit)** | Container **innerhalb** einer Domäne zum Verwalten und für GPO-Verknüpfung. Reine Verwaltungsstruktur. |

_[Abbildung: Der Forest umschließt alles und ist die Sicherheitsgrenze. Domänen darin sind über automatische, transitive Trusts verbunden — sie isolieren einander nicht. OUs und Domänen sind Verwaltungs- und Policy-Grenzen, keine Sicherheitsgrenzen.]_

> **Kernmissverständnis:** **Der Forest ist die Sicherheitsgrenze — nicht die Domain.** Domänen im selben Forest sind über automatische, transitive Trusts verbunden; ein Angreifer mit forest-weiten Admin-Rechten (z. B. `Enterprise Admins`) reicht über Domänengrenzen hinweg. Echte Isolation zweier Bereiche verlangt **getrennte Forests**.

### Replikation: Multi-Master, kein „primärer“ DC

Eine Domäne läuft auf mehreren **Domain Controllern (DCs)**. AD repliziert **Multi-Master**: **jeder** DC ist beschreibbar, Änderungen dürfen an jedem DC entstehen und werden zu den anderen repliziert. Es gibt **keinen** „primären DC“, dem alle anderen untergeordnet wären.

Folge: Änderungen sind nicht sofort überall sichtbar. **Konvergenz braucht Zeit** — zwischen Standorten typischerweise nach einem Replikationsintervall. Das ist normales Verhalten, kein Fehler.

> **Sonderrolle PDC-Emulator:** Eine der FSMO-Rollen ist der **PDC-Emulator**. Der Name ist historisch und irreführend — er ist **kein** Master. Er behandelt aber Dringendes: Eine **Passwortänderung** wird sofort (out of band) an ihn gemeldet; schlägt eine Anmeldung an einem anderen DC wegen falschem Passwort fehl, fragt dieser DC **erst den PDC-Emulator**, bevor er ablehnt. Deshalb funktioniert ein frisches Passwort auch vor voller Replikation.

### DNS: das Fundament, an dem alles hängt

AD ist ohne funktionierendes **DNS** nicht betriebsfähig. Clients und DCs finden Domain Controller **nicht** über eine feste Adresse, sondern über **DNS-`SRV`-Records** (z. B. `_ldap._tcp.dc._msdcs...`), die sagen: „Welcher DC ist für diese Domäne/diesen Standort zuständig?“

Deshalb müssen Domänen-Mitglieder und DCs auf die **AD-integrierte DNS** zeigen (üblicherweise die DCs selbst) — **nicht** auf einen ISP- oder Public-Resolver. Zeigt ein Client auf Public-DNS, fehlen ihm die `SRV`-Records: Anmeldung, GPO-Verarbeitung und DC-Lokalisierung brechen oder werden quälend langsam.

> **Merksatz:** „Es ist immer DNS.“ Bei AD-Anmeldeproblemen ist die DNS-Konfiguration der Clients der erste Blick — nicht das Konto.

### Objekte: User, Computer, Gruppen — und der Gruppentyp-Fallstrick

AD verwaltet **Objekte**: **User** (Personen/Dienstkonten), **Computer** (domänengejointe Maschinen) und **Gruppen**, mit denen du Rechte und Zugehörigkeiten bündelst statt sie einzeln zu vergeben.

Bei Gruppen gibt es **zwei Typen**, und der Unterschied ist betrieblich entscheidend:

|  |  |
| --- | --- |
| **Security-Gruppe** | kann Rechte tragen: nur sie kann in einer **ACL** (Berechtigung auf Dateien, Freigaben, Ressourcen) verwendet werden. Kann zusätzlich mail-enabled sein. |
| **Distribution-Gruppe** | reine **Verteilerliste** (E-Mail). Kann **keine** Rechte in ACLs tragen — sie ist kein `security principal`. |

> **Merksatz:** Nur **Security-Gruppen** können Berechtigungen tragen. Brauchst du Rechte **und** Mailverteilung, nimm eine Security-Gruppe (mail-enabled) — nie eine Distribution-Gruppe für Zugriffe.

### Trusts: Richtung und Transitivität

Ein **Trust** verbindet zwei Domänen/Forests, sodass Identitäten der einen in der anderen genutzt werden können. Zwei Eigenschaften zählen:

- **Transitivität**: Trusts innerhalb eines Forests sind automatisch und transitiv (vertraut A B und B C, dann faktisch auch A C). Manuell zwischen Forests angelegte Trusts sind es nicht zwangsläufig.
- **Richtung**: Ein Trust ist ein- oder beidseitig gerichtet — und die Richtung ist **kontraintuitiv**.

> **Kernmissverständnis:** **Zugriff fließt entgegen der Trust-Richtung.** Damit Benutzer der **Account-Domain** auf Ressourcen der **Ressourcen-Domain** zugreifen, muss die **Ressourcen-Domain der Account-Domain vertrauen** (die trusting-Domain hält die Ressourcen, die trusted-Domain die Konten). Wer die Pfeilrichtung falsch setzt, baut einen Trust, der nichts freischaltet.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: **Verzeichnisdienst vs. lokale Accounts**, **Forest als Sicherheitsgrenze**, **Multi-Master-Replikation + PDC-Emulator**, **DNS-Abhängigkeit**, **Objekt-/Gruppentypen** und **Trust-Richtung**.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Situationen selbst — und siehst pro Option, **warum** sie trägt oder aus welchem konkreten Grund nicht.

## Quellen

- Microsoft Learn — Active Directory Domain Services Overview
- Microsoft Learn (Windows Server) — What Are Domains and Forests? (Abschnitt „Forests as Security Boundaries“)
- Microsoft Learn — Active Directory Replication Concepts (Multi-Master)
- Microsoft Support — Password change processing and conflict resolution functionality in Windows (PDC-Emulator)
- Microsoft Learn — How DNS Support for Active Directory Works (SRV-Records)
- Microsoft Learn — Active Directory security groups (Security- vs. Distribution-Gruppen)
- Microsoft Learn — How Domain and Forest Trusts Work (Trust-Richtung und Transitivität)
- Microsoft Learn — Kerberos Authentication Overview
- Microsoft Learn — Best Practices for Securing Active Directory (Forest als Sicherheits- und Verwaltungsgrenze)
- Microsoft Learn — How DNS Support for Active Directory Works (SRV-Records, DC-Lokalisierung)
- Microsoft Learn — Configure DNS for Active Directory Domain Services
- Microsoft Learn — Understand security identifiers / security principals
- Microsoft Learn — How Domain and Forest Trusts Work (Trust-Richtung, trusting/trusted)
- Microsoft Learn — Forest and domain trust relationships (Zugriff entgegen der Trust-Richtung)
- learn.microsoft.com/en-us/windows-server/ident…ds/manage/dc-locator — https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator
- learn.microsoft.com/en-us/troubleshoot/windows…ller-location-issues — https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-domain-controller-location-issues
- learn.microsoft.com/en-us/troubleshoot/windows…-dns-client-settings — https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings