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

Ein Kollege legt für die zugekaufte Firma eine eigene Domäne an — „damit deren Admins nicht an unsere Systeme kommen“. Der Satz klingt vernünftig und ist falsch: Eine Domäne isoliert niemanden, ihr Domain Admin kann sich dokumentiert Forest-weite Rechte verschaffen. Dieses Modul baut das mentale Modell, an dem sich solche Vorschläge in einer Minute prüfen lassen — Forest, Domain und OU als das, was sie wirklich abgrenzen, die drei Partitionen und ihre Reichweite, Multi-Master-Replikation samt der Lücke, durch die entsperrte Konten gesperrt bleiben, und warum ein erreichbarer Domain Controller trotzdem unauffindbar sein kann. Vorkenntnisse brauchst du keine.

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

Was ein Verzeichnisdienst löst

Stell dir fünfzig Windows-Server vor, jeder mit eigenen lokalen Konten. Ein Mitarbeiter verlässt die Firma. Du musst fünfzig Maschinen anfassen — und die eine vergessen, auf der sein Konto weiterlebt, ist genau die, die später im Incident-Report steht. Lokale Konten sind nicht falsch, sie skalieren nur nicht: Sie leben pro Maschine, und es gibt keinen Ort, an dem „alle Konten“ steht.

Verzeichnisdienst — Eine zentrale, replizierte Datenbank der Identitäten und Ressourcen einer Organisation, zusammen mit den Protokollen, über die andere Systeme sie abfragen und sich gegen sie authentifizieren. Active Directory Domain Services (AD DS) ist Microsofts Umsetzung davon.

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

Zentrale Identität — ein Konto, gültig an jedem Domänenrechner. Deaktivieren an einer Stelle sperrt überall.
Single Sign-on über Kerberos — einmal anmelden, danach Zugriff auf Dienste ohne erneute Passworteingabe.
Zentrale Richtlinien über Group Policy — Konfiguration und Sicherheitsvorgaben werden zentral gesetzt und automatisch durchgesetzt.
Zentrale Autorisierung — Rechte hängen an Gruppen, nicht an einzelnen Maschinen.

Security Principal — Ein Objekt, das ein Recht *tragen* kann, weil es eine SID (Security Identifier) besitzt — Benutzerkonten, Computerkonten und Security-Gruppen. Alles andere im Verzeichnis ist Struktur oder Beschreibung, aber nichts, worauf sich eine Berechtigung berufen kann.

MerksatzDer Sprung ist nicht die Zentralisierung von Daten, sondern dass Identität eine verwaltete Sache wird — mit genau einem Ort, an dem sie entsteht, sich ändert und endet.

Forest, Domain, OU — und wo die Grenze wirklich liegt

AD ist hierarchisch. Drei Ebenen musst du auseinanderhalten, weil ihre Verwechslung die folgenreichste Fehlannahme im ganzen Themengebiet ist:

Forest: Die oberste Grenze, eine vollständige Instanz des Verzeichnisses. Enthält eine oder mehrere Domänen, die sich Schema, Konfiguration und Global Catalog teilen.
Domain: Eine administrative Einheit und ein Replikationsbereich innerhalb des Forests. Eigener Bereich für Kontorichtlinien.
OU (Organizational Unit): Container innerhalb einer Domäne — Ziel für Delegation und für die Verknüpfung von Group Policy.

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

Die Dokumentation ist an dieser Stelle ungewöhnlich deutlich: Der Forest ist die einzige Komponente der logischen Struktur, die eine Sicherheitsgrenze darstellt. Eine Domäne ist es ausdrücklich nicht — und der Grund dafür ist konkreter, als die meisten erwarten.

Der Befund, der die Sache entscheidetEin Dienstadministrator einer beliebigen Domäne im Forest — etwa ein Mitglied von Domain Admins einer kleinen Zweigstellen-Domäne — kann sich laut Microsoft-Dokumentation mit nicht-standardmäßigen Werkzeugen und Verfahren Vollzugriff auf jede Domäne des Forests verschaffen; ausdrücklich genannt ist der Weg, sich selbst zu Enterprise Admins oder Schema Admins hinzuzufügen. Wer also eine Domäne aufmacht, um „einen eigenen Bereich“ zu haben, hat keine Isolation gebaut, sondern nur Verwaltungsautonomie — und dem neuen Domain Admin faktisch Forest-Rechte gegeben.

Autonomie vs. Isolation — Autonomie heißt: eine Gruppe verwaltet ihren Bereich selbst. Isolation heißt: niemand außerhalb kann hineinregieren. Domänen liefern Autonomie. Isolation liefert nur ein eigener Forest — mit manuell angelegten Trusts, wenn Zugriff trotzdem nötig ist.

Was auf jedem DC liegt: die drei Partitionen

Ein Domain Controller speichert nicht „das ganze AD“. Die Datenbank ist logisch in Verzeichnispartitionen (auch Naming Contexts) zerlegt, und jede hat einen anderen Replikationsumfang. Wer das einmal sauber im Kopf hat, versteht danach die Hälfte aller Replikations- und Berechtigungsfragen von selbst.

Domain-Partition: Benutzer, Gruppen, Computer, OUs. Vollständige, beschreibbare Kopie auf jedem DC dieser Domäne.
Configuration-Partition: Sites, Subnetze, Dienste, Replikationstopologie. Vollständige, beschreibbare Kopie auf jedem DC im gesamten Forest.
Schema-Partition: Die Definition aller Objektklassen und Attribute. Auf jedem DC im Forest, aber als schreibgeschützte Kopie.

Warum das Schema anders istDie Schema-Partition ist der einzige Teil des Verzeichnisses, der überall nur lesbar liegt. Beschreibbar ist sie ausschließlich auf dem DC mit der Rolle Schema-Master, und selbst dort verlangt ein Schreibzugriff laut Dokumentation zuerst das Setzen eines Registry-Eintrags. Diese doppelte Hürde ist Absicht: Eine Schemaänderung gilt forest-weit und lässt sich nicht zurücknehmen — ein Attribut kann deaktiviert, aber nicht gelöscht werden.

Dazu kommt der Global Catalog. Ein als GC ausgewiesener DC hält zusätzlich zu seiner eigenen Domäne teilweise, schreibgeschützte Kopien jeder anderen Domänen-Partition des Forests — „teilweise“, weil nur eine Teilmenge der Attribute mitkommt. Deshalb kann eine forest-weite Suche einen GC fragen und muss nicht jede Domäne einzeln abklappern.

Multi-Master: es gibt keinen primären DC

Eine Domäne läuft auf mehreren Domain Controllern, und AD repliziert Multi-Master: Jeder DC hält eine beschreibbare Kopie, jede Änderung darf an jedem DC entstehen und wird von dort zu den anderen verteilt. Es gibt keinen „primären“ DC, dem die übrigen untergeordnet wären.

Jeder DC ist Quelle und Ziel zugleich. Änderungen entstehen verteilt und konvergieren — sie fließen nicht durch einen zentralen Punkt.

Damit das ohne Endlosschleifen funktioniert, führt jeder DC Buch. Jede Änderung bekommt eine fortlaufende USN (Update Sequence Number) des DCs, an dem sie entstanden ist. Jeder Replikationspartner merkt sich in einem High-Watermark, bis zu welcher USN er von diesem Partner schon alles hat, und in einem Up-to-dateness-Vector, was er über Umwege bereits kennt. Kommt eine Änderung auf zwei Wegen an, erkennt der Empfänger das am Vector und fordert sie nicht erneut an — das nennt die Dokumentation Propagation Dampening.

Die betriebliche KonsequenzKonvergenz braucht Zeit. Innerhalb eines Standorts benachrichtigt ein DC seine Partner nach einer kurzen Verzögerung von standardmäßig 15 Sekunden; zwischen Standorten läuft Replikation nach Zeitplan. Eine Änderung, die auf DC A sichtbar ist und auf DC B noch nicht, ist damit normales Verhalten — kein Fehler. Wer in diesem Fenster „repariert“, erzeugt den Fehler oft erst.

Multi-Master hat einen Preis, den man beim Entwurf mitdenken muss: Zwei Administratoren können dieselbe Eigenschaft gleichzeitig an verschiedenen DCs ändern. AD löst das über einen dreiteiligen Stempel je Attribut — Version, Ursprungszeit, Ursprungs-DC — und vergleicht in genau dieser Reihenfolge. Dass die Version und nicht die Uhrzeit zuerst zählt, ist Absicht: So kann eine falsch gestellte Uhr laut Dokumentation niemals verhindern, dass ein Wert überschrieben wird. Der Konflikt wird damit aufgelöst, aber nicht gemeldet — eine der beiden Änderungen verschwindet stillschweigend. repadmin /showobjmeta zeigt alle drei Bestandteile des Stempels und ist deshalb das Werkzeug, mit dem man „wer hat das zuletzt angefasst“ überhaupt beantworten kann.

Wenn es eilt: dringende Replikation — und ihre Lücke

Für sicherheitsrelevante Ereignisse ist Warten keine Option. AD kennt deshalb dringende Replikation (urgent replication): Statt die übliche Benachrichtigungsverzögerung abzuwarten, meldet der Quell-DC seinen Partnern die Änderung sofort per RPC. Welche Ereignisse das auslösen, ist eine feste, dokumentierte Liste — und die interessanteste Information steckt darin, was nicht auf ihr steht.

Kontosperrung (Lockout): dringend — verhindert, dass ein gesperrtes Konto an anderen DCs weiter probiert werden kann
Änderung der Domänen-Passwortrichtlinie: dringend
Änderung eines LSA-Secrets (z. B. Trust-Passwort): dringend
Änderung des Computerkonto-Passworts eines DCs: dringend
Entsperrung eines Kontos: nicht dringend — repliziert wie jede andere Änderung

Der Fall, der dich sonst am Helpdesk erwischtEine Kontosperrung repliziert dringend, die Entsperrung nicht. Du entsperrst ein Konto an DC A, der Nutzer meldet sich sofort wieder an — und landet an DC B, der die Sperre noch kennt. Der Anruf lautet dann „du hast es nicht entsperrt“, und der Fehler sitzt nicht im Konto, sondern in der Replikationslatenz. Die saubere Antwort ist, die Entsperrung am DC des Nutzers vorzunehmen oder die Konvergenz abzuwarten — nicht, das Konto ein zweites Mal anzufassen.

Der PDC-Emulator: kein Master, aber der Notnagel

Multi-Master heißt nicht, dass alle Aufgaben überall stattfinden. Fünf Aufgaben verträgt AD nicht verteilt; sie liegen als FSMO-Rollen (Flexible Single Master Operations) bei je einem DC. Zwei davon gelten forest-weit (Schema-Master, Domain-Naming-Master), drei je Domäne (RID-Master, Infrastructure-Master, PDC-Emulator). Nur den letzten brauchst du hier.

Der Name PDC-Emulator stammt aus der Windows-NT-Zeit und führt in die Irre: Er ist kein Master, dem die anderen DCs untergeordnet wären. Er trägt aber drei Aufgaben, die im Alltag ständig durchschlagen:

Passwortänderungen werden von anderen DCs bevorzugt zu ihm repliziert — nicht als Sonderfall der dringenden Replikation, sondern als eigener Vorzugspfad.
Fehlgeschlagene Anmeldungen wegen falschem Passwort leitet der annehmende DC an den PDC-Emulator weiter, bevor er ablehnt. Deshalb funktioniert ein frisch geändertes Passwort auch dort, wo die Replikation noch nicht angekommen ist.
Zeit: Der PDC-Emulator ist die Zeitautorität seiner Domäne. Der PDC-Emulator der Forest-Root-Domäne ist es für den gesamten Forest und sollte seine Zeit aus einer externen Quelle beziehen.

Warum die Zeitrolle hier stehtKerberos ist zeitempfindlich: Weicht die Uhr eines Rechners zu weit von der des DCs ab, scheitert die Authentifizierung — mit einer Fehlermeldung, die nach Konto oder Netz aussieht und keine ist. Die Zeithierarchie ist deshalb kein Nebenschauplatz, sondern eine Voraussetzung der Anmeldung.

DNS: wie ein Client einen DC überhaupt findet

AD ist ohne funktionierendes DNS nicht betriebsfähig — nicht als Komfortfunktion, sondern weil die Suche nach einem Domain Controller über DNS läuft. Es gibt keine feste Adresse und keine Broadcast-Suche, auf die man sich verlassen könnte. DCs registrieren stattdessen `SRV`-Records, die ihre Fähigkeiten und ihren Standort beschreiben.

Client fragt DNS nach SRV-Records im Format _<dienst>._<protokoll>.<DNS-Domänenname>, etwa _ldap._tcp.dc._msdcs.contoso.com→DNS liefert die passenden SRV- und A-Records der in Frage kommenden DCs→Client prüft die Kandidaten mit einem LDAP-Ping über UDP, statt blind den ersten zu nehmen→Der antwortende DC bestimmt anhand des IP-Subnetzes des Clients dessen Standort→Liegt der DC nicht im optimalen Standort, nennt er dem Client dessen richtigen Standortnamen — der Client sucht standortspezifisch neu→Client speichert den gefundenen DC zwischen

Der DC sagt dem Client, wo der Client steht

Die Zahl, die niemand erwartetLandet ein Client bei einem DC, der nicht in seinem optimalen Standort liegt, verwirft er den zwischengespeicherten Eintrag laut Dokumentation nach 15 Minuten und sucht erneut. Genau das erklärt Störungen, die „nach einer Viertelstunde von selbst weggehen“ — und ebenso solche, die alle 15 Minuten wiederkehren, solange die Subnetz-zu-Standort-Zuordnung unvollständig ist. Ein fehlendes Subnetz in der Configuration-Partition ist ein Konfigurationsfehler, kein Netzproblem.

Daraus folgt die wichtigste Faustregel der Client-Konfiguration: Domänen-Mitglieder und DCs müssen auf die AD-integrierte DNS zeigen, in aller Regel auf die DCs selbst — niemals auf einen Provider- oder Public-Resolver. Ein Client mit Public-DNS bekommt die SRV-Records nicht zu sehen. Anmeldung, GPO-Verarbeitung und DC-Suche brechen dann oder werden quälend langsam, während ping auf den DC tadellos funktioniert.

Womit du das nachsiehstnltest /dsgetdc:<domäne> zeigt, welchen DC der Client tatsächlich auswählt und welchen Standort er dabei annimmt — die direkteste Antwort auf „wo lande ich eigentlich“. nslookup -type=srv _ldap._tcp.dc._msdcs.<domäne> prüft, ob die Records überhaupt beantwortet werden. dcdiag /test:dns prüft die DNS-Gesundheit auf dem DC selbst, repadmin /replsummary gibt den schnellsten Überblick über hängende Replikation. Merke dir die Reihenfolge: erst feststellen, wo der Client landet, dann warum dort.

Objekte, SIDs und der Gruppentyp-Fallstrick

AD verwaltet Objekte: Benutzer (Personen und Dienstkonten), Computer (domänengejointe Maschinen) und Gruppen, mit denen du Rechte bündelst, statt sie einzeln zu vergeben. Bei Gruppen gibt es zwei Typen, und der Unterschied ist keine Geschmacksfrage.

Security-Gruppe: Ist ein Security Principal, hat also eine SID. Nur sie kann in einer DACL stehen, also Berechtigungen auf Dateien, Freigaben und Objekte tragen. Kann zusätzlich mail-enabled sein.
Distribution-Gruppe: Reine Verteilerliste für E-Mail. Kein Security Principal, keine SID — kann in keiner DACL stehen und keinerlei Zugriff gewähren.

MerksatzBrauchst du Rechte und Mailverteilung, nimm eine mail-enabled Security-Gruppe. Eine Distribution-Gruppe für Zugriffe zu verwenden scheitert nicht mit einer klaren Fehlermeldung — sie taucht in der Auswahl schlicht nicht auf oder gewährt am Ende nichts.

Trusts: Richtung, Transitivität, Durchreichen

Ein Trust verbindet zwei Domänen oder Forests, sodass Identitäten der einen Seite in der anderen genutzt werden können. Innerhalb eines Forests entstehen Trusts automatisch und sind transitiv: Vertraut A der Domäne B und B der Domäne C, wirkt das auch zwischen A und C. Zwischen Forests angelegte Trusts sind das nicht zwangsläufig.

Trusting und Trusted — Die trusting-Seite hält die Ressourcen und vertraut. Die trusted-Seite hält die Konten und wird vertraut. Ein beidseitiger Trust ist technisch nichts anderes als zwei einseitige Trusts in entgegengesetzter Richtung.

Der Mechanismus dahinter macht die Richtung nachvollziehbar: Muss die Ressourcen-Domäne die Identität eines fremden Benutzers prüfen, reicht sie dessen Anmeldedaten über den Netlogon-Dienst an die Konto-Domäne zur Prüfung durch — pass-through validation. Vertrauen zeigt also dorthin, wo die Konten liegen.

KernmissverständnisZugriff fließt entgegen der Trust-Richtung. Damit Benutzer der Konto-Domäne auf Ressourcen der Ressourcen-Domäne zugreifen können, muss die Ressourcen-Domäne der Konto-Domäne vertrauen. Wer den Pfeil andersherum setzt, hat einen technisch einwandfreien Trust gebaut, der genau nichts freischaltet — und sucht den Fehler danach stundenlang in Berechtigungen.

Durchgerechnet: „Der Kollege kommt nicht rein“

Vier Meldungen, vier verschiedene Ursachen

Szenario

Vier Tickets an einem Vormittag, alle mit demselben Wortlaut: „Anmeldung funktioniert nicht.“ Ohne Modell greifst du viermal zum selben Werkzeug. Mit Modell trennst du sie in der ersten Minute.

Anforderungen

Jede Meldung genau einer der bisher behandelten Achsen zuordnen
Vor jeder Änderung benennen, welche Beobachtung sie rechtfertigt

Schritte

Nur ein Nutzer, nur seit eben, Passwort gerade geändert. Achse: Replikationslatenz. Der annehmende DC fragt bei falschem Passwort ohnehin den PDC-Emulator, bevor er ablehnt — schlägt es trotzdem fehl, liegt es nicht am Änderungszeitpunkt. Nicht das Konto zurücksetzen, sondern prüfen, ob die Anmeldung überhaupt am erwarteten DC ankommt.
Nur ein Nutzer, gerade eben entsperrt, scheitert weiter. Achse: die Lücke in der dringenden Replikation. Die Entsperrung repliziert nicht dringend. Am DC des Nutzers entsperren oder Konvergenz abwarten — ein zweites Zurücksetzen ändert nichts.
Alle Nutzer eines Standorts, `ping` auf den DC funktioniert. Achse: DC-Locator. Erreichbarkeit auf IP-Ebene beweist nichts über SRV-Records. Prüfen, auf welchen Resolver die Clients zeigen — und ob das Subnetz des Standorts in der Configuration-Partition einem Standort zugeordnet ist.
Ein Nutzer aus der anderen Domäne, auf eine Freigabe hier. Achse: Trust-Richtung. Nicht die Berechtigungen der Freigabe zuerst prüfen, sondern ob die Ressourcen-Domäne der Konto-Domäne vertraut — und nicht umgekehrt.

Merksatz: Dieselbe Meldung, vier Achsen. Der Wert des mentalen Modells liegt nicht darin, die Antwort zu kennen, sondern darin, die Frage in der ersten Minute richtig zu stellen.

Prüf dich selbst, bevor es zählt

Kurzcheck

Ein Kollege schlägt vor, für die neue Tochterfirma eine eigene Domäne im bestehenden Forest anzulegen — „damit deren Administratoren nicht an unsere Systeme kommen“. Was ist daran falsch?

Nichts — eine eigene Domäne isoliert die Administratoren voneinander.
Die Domäne isoliert nicht: Ihre Domain Admins können sich Forest-weite Rechte verschaffen. Isolation verlangt einen eigenen Forest.
Der Vorschlag ist zu teuer — eine OU erfüllt denselben Zweck günstiger.

Treffer. Richtig. Der Forest ist die einzige Sicherheitsgrenze; ein Domain Admin einer beliebigen Domäne kann sich dokumentiert zu Enterprise Admins hinzufügen.

Damit stehen die Achsen, auf denen der ganze Track aufbaut: Verzeichnisdienst statt lokaler Konten, Forest als einzige Sicherheitsgrenze, Partitionen und ihr Replikationsumfang, Multi-Master mit Latenz, dringende Replikation und ihre Lücke, PDC-Emulator, DNS und DC-Locator, Objekt- und Gruppentypen sowie Trust-Richtung.

Gleich im CheckIn den folgenden Entscheidungen wählst du für konkrete Betriebssituationen selbst. Zu jeder Option steht danach, warum sie trägt oder aus welchem benannten Grund nicht — die Begründung ist der eigentliche Lerninhalt, nicht das Häkchen.

Jetzt anwenden

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

Zum Modul →

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