# AD Design: Forest, Tree & Domain Best Practices

TL;DR / Management Summary Ein schlechtes Active Directory Design verfolgt Sie über Jahrzehnte. Wir unterscheiden zwischen dem Wald (Forest) als ultimative Sicherheitsgrenze, dem Baum (Tree) als Namensraum-Hierarchie und der Domäne als Replikationsgrenze. Ein Senior Admin folgt heute dem Single-Forest Design: So wenig Domänen wie möglich, so viele OUs wie nötig. Komplexität (Child-Domains) wird nur für internationale Standorte mit extrem schlechten Leitungen oder regulatorischen Trennungen genutzt.

# 1. Einführung & Logische Hierarchie

Vom Samen zum Wald.

# Der Wald (Forest)

• Teilt sich ein gemeinsames Schema.
• Teilt sich eine Konfigurationspartition.
• Wichtig: Der Forest ist die einzige echte Sicherheitsgrenze. Ein Domain-Admin in einer Child-Domain kann durch technische Tricks oft Forest-Admin-Rechte erlangen.

# Die Domäne (Domain)

• Grenze für GPO-Anwendungen.
• Grenze für Passwort-Richtlinien (ohne FGPP).
• Replikationsbereich für die Domain-Partition (Benutzer/Computer).

# Der Baum (Tree)

• Eine Sammlung von Domänen mit einem zusammenhängenden DNS-Namensraum (z.B. de.firma.com und us.firma.com).

# 2. Design-Strategien

Welche Struktur passt zu uns?

# 1. Single-Domain Modell (Empfohlen für 90%)

• Ein Forest, eine Domain (z.B. corp.firma.de).
• Strukturierung erfolgt ausschließlich über Organisationseinheiten (OUs).
• Vorteil: Minimaler administrativer Aufwand, kein Vertrauensstellungs-Overhead.

# 2. Regionales Domain-Modell

• Ein Root-Forest, mehrere Child-Domains (z.B. asia.firma.local).
• Anwendungsfall: Wenn Replikations-Traffic über uralte WAN-Leitungen minimiert werden muss.

# 3. Deep Dive: Trusts (Vertrauensstellungen)

Die Diplomatie zwischen Wäldern.

Wenn zwei Firmen fusionieren, müssen Identitäten geteilt werden.

# Trust-Typen

1. Parent-Child: Automatisch erstellt, bidirektional, transitiv.
2. Forest Trust: Verbindet zwei komplette Wälder.
3. External Trust: Verbindet eine Domäne mit einer externen Domäne (nicht transitiv).
4. Shortcut Trust: Verkürzt den Authentifizierungsweg zwischen zwei tief verschachtelten Child-Domains.

# 4. Day-2 Operations: Namenskonventionen

Namen sind nicht nur Schall und Rauch.

# Der Root-Name

Nutzen Sie niemals echte Top-Level-Domains (TLDs), die Sie nicht besitzen (z.B. nicht firma.local).

• Best Practice: corp.firma.de oder ad.firma.com.
• Warum?: Verhindert DNS-Namenskonflikte bei Cloud-Integrationen (Microsoft 365).

# 5. Troubleshooting & “War Stories”

Wenn die Wurzel fault.

# Top 3 Fehlerbilder

1. Symptom: User in Domain A können nicht auf Ressourcen in Domain B zugreifen.

   • Ursache: Trust ist gebrochen oder DNS-Conditional-Forwarder fehlen.
   • Lösung: netdom trust /verify und DNS-Suffix-Suche prüfen.

2. Symptom: Passwort-Änderung in einer Domäne führt zu Lockout in der anderen.

   • Ursache: Veraltete Cached Credentials oder asynchroner PDC-Emulator Sync.

3. Symptom: Das Schema-Update für eine neue Exchange-Version schlägt fehl.

   • Ursache: Der Admin führt den Befehl in einer Child-Domain aus, hat aber keine Rechte im Forest-Root.

# “War Story”: Das “.local” Erbe

Ein Kunde benutzte firma.local. Später kaufte er firma.com und wollte Microsoft 365 einführen. Das Problem: Da .local keine im Internet routbare Domain ist, gab es massive Probleme beim Single-Sign-On und dem UPN-Matching (User Principal Name). Lösung: Wir mussten mühsam einen UPN-Suffix im AD hinzufügen und hunderte User-IDs ändern. Lehre: Planen Sie Ihren AD-Namen so, als müssten Sie ihn morgen mit der Cloud verknüpfen.

# 6. Monitoring & Reporting

Die Topologie visualisieren.

# AD Topologie Map

Nutzen Sie PowerShell, um die Vertrauensstellungen zu exportieren:

Get-ADForest | Select-Object -ExpandProperty ForestTrusts

# 7. Fazit & Empfehlung

Halten Sie es einfach (KISS Principle).

• Empfehlung: Bauen Sie einen einzigen Forest mit einer einzigen Domain. Trennen Sie Administration und Standorte über OUs und Gruppen.
• Sicherheit: Wenn Sie eine echte Trennung brauchen (z.B. für die Administration Ihres Proxmox-Clusters), bauen Sie einen separaten Management Forest (“Red Forest” / ESAE Modell - auch wenn Microsoft dies durch Cloud-Konzepte ablöst, bleibt das Prinzip der Isolation valide).

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: AD DS Design Guide
• Best Practices for AD Naming
• Enterprise Administrative Model (Tier Model)