# Active Directory Domain Services: Die Architektur des Vertrauens

TL;DR / Management Summary Active Directory Domain Services (ADDS) ist der zentrale Verzeichnisdienst zur Verwaltung von Identitäten, Computern und Ressourcen. Ein Senior Admin sieht das AD nicht als “Benutzerliste”, sondern als eine verteilte, Multi-Master-Datenbank. Das Verständnis von FSMO-Rollen, Replikations-Topologien und der engen Kopplung an den DNS-Dienst ist die Grundvoraussetzung für einen stabilen Betrieb ohne Anmelde-Verzögerungen.

# 1. Einführung & Logische Architektur

Die Hierarchie der Objekte.

ADDS strukturiert Daten in drei Ebenen:

1. Wald (Forest): Die oberste Sicherheitsgrenze. Ein Forest kann mehrere Domänen enthalten.
2. Domäne (Domain): Eine administrative Grenze. Alle Objekte teilen sich eine Datenbank und Richtlinien.
3. Organisationseinheit (OU): Ein Container zur Strukturierung und Zuweisung von GPOs (Artikel 425).

# Die Datenbank-Partitionen

Das AD besteht aus der Datei ntds.dit, die in Partitionen unterteilt ist:

• Domain Partition: Benutzer, Computer, OUs (wird nur innerhalb der Domain repliziert).
• Configuration Partition: Physische Struktur, Sites, Services (wird in den ganzen Forest repliziert).
• Schema Partition: Definition aller Objekt-Klassen und Attribute (wird in den ganzen Forest repliziert).

# 2. Physische Architektur: Domain Controller

Die Last auf den Schultern der Server.

Ein Domain Controller (DC) ist ein Server, der die ADDS-Rolle hält.

# Der Globale Katalog (GC)

Ein GC ist ein spezieller DC, der eine Teil-Kopie aller Objekte des gesamten Forests hält. Er wird benötigt für:

• Forest-weite Suchen.
• Login-Vorgänge (Prüfung der Universal Groups).

# Architektur-Diagramm (Mermaid)

graph TD
    subgraph "Forest"
    subgraph "Domain A (Root)"
    DC1[DC 01 - GC]
    DC2[DC 02 - FSMO]
    end
    subgraph "Domain B (Child)"
    DC3[DC 03]
    end
    end
    DC1 <-->|Sync| DC2
    DC1 <-->|Sync| DC3
    DC1 --- DNS[Integrated DNS]

# 3. Deep Dive: FSMO-Rollen

Wer hat das Sagen?

Obwohl AD ein Multi-Master System ist, gibt es 5 Aufgaben, die nur von einem DC gleichzeitig ausgeführt werden dürfen (Flexible Single Master Operations).

1. Schema Master: Erlaubt Schema-Änderungen (1 pro Forest).
2. Domain Naming Master: Verhindert doppelte Domain-Namen (1 pro Forest).
3. PDC Emulator: Zeit-Referenz, Passwort-Änderungen, GPO-Master (1 pro Domain).
4. RID Master: Verteilt SIDs an DCs, damit neue Objekte eindeutig sind (1 pro Domain).
5. Infrastructure Master: Verwaltet Cross-Domain Referenzen (1 pro Domain).

# FSMO Rollen-Inhaber anzeigen
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

# 4. Day-2 Operations: Zeit & DNS

Die Lebensadern des AD.

# Ohne DNS kein AD

DCs registrieren ihre Dienste via SRV-Records im DNS. Wenn ein Client den DC nicht findet, schlägt der Login fehl.

• Wichtig: DCs sollten immer den integrierten DNS-Dienst nutzen.

# Ohne NTP kein Kerberos

Das Authentifizierungs-Protokoll Kerberos toleriert maximal 5 Minuten Zeitunterschied.

• Best Practice: Der DC mit der Rolle PDC Emulator muss mit einer externen Zeitquelle (z.B. ptbtime1.ptb.de) synchronisiert sein. Alle anderen DCs und Clients holen sich die Zeit automatisch vom PDC.

# 5. Troubleshooting & “War Stories”

Wenn das Verzeichnis korrumpiert ist.

# Top 3 Fehlerbilder

1. Symptom: “Der Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden”.

   • Ursache: Das Computer-Passwort ist asynchron oder der DC-Sync ist kaputt.
   • Lösung: Test-ComputerSecureChannel -Repair.

2. Symptom: AD-Replikation schlägt fehl (KCC-Fehler).

   • Tool: repadmin /showrepl und dcdiag.
   • Lösung: Meist DNS-Fehler oder blockierte RPC-Ports in der Firewall.

3. Symptom: Tombstone Lifetime Probleme.

   • Ursache: Ein DC war länger als 180 Tage offline und wird nun wieder gestartet.
   • Lösung: DC niemals wieder online nehmen! Er muss komplett neu aufgesetzt werden (Lingering Objects Gefahr).

# “War Story”: Der schweigende RID-Master

In einem Unternehmen konnten plötzlich keine neuen Benutzer mehr angelegt werden. Fehler: “The directory service has exhausted the pool of relative identifiers”. Die Entdeckung: Der Inhaber der RID-Master Rolle war vor zwei Wochen sang- und klanglos gestorben (Hardware-Defekt). Die anderen DCs hatten ihren Vorrat an IDs aufgebraucht. Lösung: Wir mussten die Rolle manuell auf einen gesunden DC “seizen” (erzwingen) via Move-ADDirectoryServerOperationMasterRole -Force. Lehre: Überwachen Sie nicht nur die Erreichbarkeit der DCs, sondern explizit den Status der FSMO-Rollen!

# 6. Monitoring & Reporting

Die Gesundheit des AD.

# Wichtige Metriken

• Replication Latency: Zeit zwischen Änderungen auf DCs.
• LSASS CPU Usage: Hohe Last deutet auf ineffiziente LDAP-Abfragen hin.

# 7. Fazit & Empfehlung

Das Active Directory ist kein statisches Gebilde, sondern ein lebender Organismus.

• Empfehlung: Betreiben Sie immer mindestens zwei Domain Controller pro Domäne, idealerweise auf unterschiedlichen physischen Proxmox-Hosts.
• Sicherheit: Nutzen Sie den AD-Papierkorb (Active Directory Recycle Bin), um versehentlich gelöschte Objekte in Sekunden wiederherzustellen.

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: Active Directory Domain Services Overview
• Active Directory Site and Services Design
• Inside AD: The ntds.dit file format