# Domain-Design & Migration

> Die tragenden Design- und Migrationsentscheidungen: Single- vs. Multi-Domain vs. Multi-Forest und wann die Grenze wirklich zählt, was das Anheben von Funktionsleveln freischaltet und warum es eine Einbahnentscheidung ist, In-Place-Upgrade vs. Restructure in einen pristinen Forest, Nutzen und Risiko von SID-History samt SID-Filtering, Trust-Design mit Selective Authentication sowie Koexistenz und Source of Authority während der Migration.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/domain-design  
Stand: 2026-07-27  
Interaktiver Teil: 14 Checks (nur im Browser)

## Domain-Design & Migration: Grenzen, Funktionslevel, Trusts und der saubere Umzug

### Zwei Grenzen: Domäne und Forest

Design in Active Directory heißt, zwei Grenzen richtig zu setzen. Die **Domäne** ist eine **Verwaltungs-, Policy- und Replikationsgrenze**: Sie hat eine eigene Domänen-Partition (Domain NC), ihre eigene Konten-/Passwort-Richtlinie und ihre eigenen domänenweiten Gruppen wie `Domain Admins`. Der **Forest** ist die **Sicherheitsgrenze**: Ein Schema, eine Konfigurationspartition, ein Global Catalog, forest-weite Rollen wie `Enterprise Admins` — und automatische, transitive Trusts zwischen allen Domänen darin.

_[Abbildung: Ein Forest umschließt eine oder mehrere Domänen; Schema, Konfiguration und Global Catalog sind forest-weit, während jede Domäne ihre eigene Partition und Policy trägt.]_

> **Merksatz:** Eine neue **Domäne** trennt Verwaltung und Replikation — nicht Sicherheit. Wer administrative Isolation gegen einen nicht vertrauenswürdigen Admin braucht, braucht einen neuen **Forest**. Diese Unterscheidung entscheidet fast jede Design-Frage in diesem Modul.

### Wie viele Domänen, wie viele Forests?

Die moderne Default-Empfehlung ist **ein Forest mit einer Domäne**. Jede zusätzliche Domäne kostet eigene DCs, eigene FSMO-Rollen, eigene Replikation und eigene Betriebslast — und liefert dafür **keine** Sicherheitsgrenze. Viele historische Gründe für Multi-Domain sind heute weggefallen:

|  |  |
| --- | --- |
| „Andere Passwort-Richtlinie für eine Abteilung“ | Kein Grund mehr für eine eigene Domäne: **Fine-Grained Password Policies (PSO)** erlauben mehrere Passwort-/Lockout-Richtlinien **innerhalb** einer Domäne (setzt ein hinreichendes Domänen-Funktionslevel voraus). |
| „Eigene Administration für einen Standort/Bereich“ | Delegation über **OUs** regelt, wer was verwalten darf, ohne eine Domäne zu spalten. Repliktions-/WAN-Steuerung erledigen **Sites**, nicht Domänengrenzen. |
| „Echte Isolation gegen fremde/kompromittierte Admins“ | Das ist der legitime Grund für eine **eigene Forest-Grenze** (z. B. Zukauf, Hochrisiko-Umgebung) — nicht für eine weitere Domäne im selben Forest. |

Multi-Domain bleibt selten sinnvoll (etwa stark abweichende domänenweite Anforderungen oder Alt-Strukturen, die man nicht auflösen kann). Multi-Forest ist die Wahl, wenn **Sicherheitsisolation** oder rechtlich/organisatorisch getrennte Autonomie das Ziel ist — verbunden bei Bedarf über einen bewusst konfigurierten **Trust**.

### Funktionslevel: was sie freischalten — und warum der Rollback kein Plan ist

**Domain Functional Level (DFL)** und **Forest Functional Level (FFL)** sind Marker, die bestimmte Verzeichnis-Features **freischalten** (z. B. den AD-Papierkorb auf FFL-Ebene). Ein Level anzuheben ist **kein** Update der DCs und macht nichts „schneller“ — es ist ein Schalter, den man umlegt, **nachdem** die gesamte DC-Flotte die nötige OS-Version erreicht hat.

- **Voraussetzung:** Alle DCs (für DFL: in der Domäne; für FFL: alle Domänen auf dem nötigen DFL) müssen mindestens die Ziel-Version erreichen. Ein einziger zurückgebliebener DC **blockiert** das Anheben.
- **Rollback ist kein Betriebsplan:** Aktuelle unterstützte Level lassen sich unter Bedingungen wieder auf ein unterstütztes früheres Level senken; freigeschaltete Features wie der AD-Papierkorb werden dadurch aber nicht zurückgenommen, und ältere DCs bleiben ein Kompatibilitätsrisiko. Behandle das Anheben deshalb wie eine schwer rückgängig zu machende Änderung.
- **Reihenfolge:** Erst DCs aktualisieren/ersetzen, dann Level prüfen, dann anheben — nie umgekehrt.

**Kurzcheck:** Ein Team will das Forest-Funktionslevel anheben, um den AD-Papierkorb zu aktivieren. Ein DC läuft noch auf einer älteren OS-Version als das Ziel-Level. Was gilt?

- [x] Das Anheben ist blockiert, bis dieser DC auf mindestens die Ziel-Version gebracht oder entfernt ist; erst danach wird die Kompatibilität der Flotte erneut geprüft.
- [ ] Das Level lässt sich trotzdem anheben; der zurückgebliebene DC läuft einfach unverändert weiter.
- [ ] Das Anheben hebt automatisch die OS-Version des alten DC mit an.

> Genau. Das Level ist ein Gate über der Flotte: erst müssen alle DCs die Zielversion erfüllen, dann kann das Team den Feature- und Rollback-Risiko bewusst bewerten.

### Migration: In-Place-Upgrade vs. Restructure

Es gibt zwei grundverschiedene Wege, eine AD-Umgebung zu modernisieren:

|  |  |
| --- | --- |
| **In-Place-Upgrade (Domain Upgrade)** | Im **selben** Forest: DCs auf neue OS-Versionen heben, Funktionslevel anheben. Alles bleibt erhalten — Konten, SIDs, Trusts, GPOs. Schnell und billig, **aber** trägt auch jede Altlast weiter: Fehlkonfigurationen, Rechte-Wildwuchs, unklare Delegationen und eine etwaige unentdeckte Kompromittierung. |
| **Restructure (Inter-Forest-Migration)** | Ein **neuer, pristiner** Forest wird aufgebaut und nur gewollte Objekte werden mit einem Migrationswerkzeug (klassisch **ADMT**) hineinmigriert. Ergebnis: sauberer Start, neuer `krbtgt`, keine Alt-Trusts. Preis: ein großes Projekt mit Trust, SID-History und Koexistenzphase. |

> **Wann was:** Restructure ist **kein** Default fürs Modernisieren — es ist die Wahl, wenn ein **sauberer Bruch** nötig ist (nicht sanierbares Alt-Design, verdächtige/bekannte Kompromittierung, organisatorische Trennung). Ist der Forest gesund und gepflegt, ist ein In-Place-Upgrade der günstigere, risikoärmere Weg. Ein `krbtgt`-Reset allein rechtfertigt keinen Rebuild.

### SID-History: Brücke mit scharfer Kante

Bei einer Migration in eine andere Domäne bekommt ein Konto eine **neue SID**. Ressourcen, deren ACLs noch auf die **alte** SID zeigen, würden den Zugriff verweigern. **SID-History** löst das: Die alte(n) SID(s) werden im Attribut `sIDHistory` des neuen Kontos gespeichert und beim Anmelden **dem Access-Token hinzugefügt** — der migrierte Nutzer behält so seinen Zugriff, während man die Ressourcen nach und nach auf die neuen SIDs **re-ACLt**.

Die Kehrseite: `sIDHistory` ist kein bloßes Protokoll — sein Inhalt landet **wirksam im Token**. Wird eine **privilegierte Fremd-SID** injiziert (z. B. die einer hoch privilegierten Gruppe), erhält das Konto diese Rechte. Genau hier greift **SID-Filtering** (Quarantine): Beim Übertritt über einen **Trust** verwirft es fremde/injizierte SIDs — inklusive SID-History.

- Auf **externen** und **Forest**-Trusts ist SID-Filtering standardmäßig **aktiv** (der Trust ist die Filtergrenze).
- **Innerhalb** eines Forests wird **nicht** gefiltert — der Forest ist die Vertrauensgrenze, injizierte SID-History wird intern akzeptiert.
- Für eine Migration über einen Forest-Trust muss man das Filtering **temporär lockern**, damit die noch gebrauchte SID-History honoriert wird — und nach dem Re-ACLing **die SID-History entfernen** (Cleanup) und das Filtering **wieder scharf** stellen.

**Kurzcheck:** Nach der Migration tragen viele Konten noch ihre alte SID in `sIDHistory`, und auf dem Forest-Trust ist das SID-Filtering gelockert. Warum muss man das nach dem Re-ACLing bereinigen?

- [x] Eine injizierte privilegierte Fremd-SID in `sIDHistory` würde über den Trust hinweg im Token akzeptiert; nach Cleanup (Re-ACL → SID-History entfernen → Filtering wieder scharf) fällt dieser Pfad weg.
- [ ] `sIDHistory` ist ein reines Protokollattribut ohne Wirkung auf Zugriffsrechte.
- [ ] Solange der Trust nur einseitig ist, kann SID-History nicht missbraucht werden.

> Richtig. Gelockertes Filtering plus SID-History ist ein offener Eskalationspfad — die Reihenfolge des Aufräumens verhindert zugleich das Aussperren legitimer Zugriffe.

### Trust-Design: Typ, Richtung, Reichweite

Ein Trust ist die bewusst konfigurierte Brücke über eine Grenze. Drei Achsen entscheiden das Design:

|  |  |
| --- | --- |
| **Typ** | **Forest-Trust** (zwischen zwei Forest-Wurzeln, transitiv über die verbundenen Forests) für breiten, mehr-Domänen-Zugriff zwischen zwei Windows-Forests; **externer Trust** (zu einer einzelnen Domäne, **nicht** transitiv) für einen eng begrenzten Einzelfall; Kürzungs-/Realm-Trusts für Sonderfälle. Ein Trust **verschmilzt keine** Sicherheitsgrenzen — er öffnet Zugriff. |
| **Richtung** | Zugriff fließt **entgegen** der Trust-Richtung: Die ressourcenhaltende Seite (trusting) vertraut der kontenhaltenden (trusted). Nur die tatsächlich benötigte Richtung öffnen. |
| **Reichweite (Selective Authentication)** | Standardmäßig dürfen sich die vertrauten Nutzer an **jedem** Rechner der vertrauenden Seite authentifizieren. **Selective Authentication** kehrt das um: Authentifizierung nur dort, wo dem Konto explizit das Recht `Allowed to authenticate` auf dem Computer-Objekt gewährt wurde — der Least-Privilege-Modus für Trusts. |

> **Prinzip:** Trust-Design ist Angriffsflächen-Design: den engsten **Typ**, nur die nötige **Richtung**, die kleinste **Reichweite** (Selective Authentication) und SID-Filtering scharf. Ein bequemer bidirektionaler, forest-weiter Trust ist fast immer mehr, als der Bedarf verlangt.

### Koexistenz: eine Quelle der Wahrheit

Migrationen laufen selten über Nacht — Quell- und Ziel-Umgebung koexistieren eine Weile. Zwei Dinge müssen dabei stimmen:

- **Source of Authority (SoA):** Jedes Objekt hat **eine** maßgebliche Quelle. Ist ein Objekt migriert, wird die **Ziel**-Umgebung autoritativ; das Alt-Objekt wird nicht mehr gepflegt (deaktiviert). Wer parallel in beiden Seiten editiert, erzeugt Divergenz — getrennte Domänen/Forests replizieren **nicht** ineinander.
- **Namensauflösung:** Damit Clients Dienste der jeweils anderen Seite finden, richtet man **Conditional Forwarder** zwischen den DNS-Zonen beider Forests ein — nicht die primäre DNS der Clients auf fremde DCs umbiegen (das bricht die eigene DC-Locator-Auflösung).

Zusammen mit dem Trust und (temporär) der SID-History ergibt das die Koexistenz-Infrastruktur: Zugriff über die Grenze funktioniert, die Autorität bleibt eindeutig, und der Cutover verschiebt die SoA kontrolliert auf die Zielseite.

### Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: **Domänen-Modell** (Single vs. Multi-Domain vs. Multi-Forest, wann die Grenze zählt); **Funktionslevel** (was sie freischalten, Einbahn-Charakter); **Migrationsstrategie** (In-Place vs. Restructure); **SID-History** (Nutzen, Risiko, Cleanup, SID-Filtering); **Trust-Design** (Typ, Richtung, Selective Authentication); **Koexistenz** (Source of Authority, Namensauflösung).

> **Gleich im Check:** Du entscheidest für konkrete Situationen das beste Design oder Vorgehen. Zwei Missionen kommen dazu: eine **Migrationsreihenfolge** in die richtige Abfolge bringen und **einordnen**, was eine Domänengrenze isoliert und was forest-weit gilt. Pro Option siehst du, warum sie die Wurzel trifft oder aus welchem benannten Grund sie nur ein Symptom behandelt.

## Quellen

- Microsoft Learn — What Are Domains and Forests? (Domäne = Verwaltungs-/Replikationsgrenze, Forest = Sicherheitsgrenze; Schema/Konfiguration/GC forest-weit)
- Microsoft Learn — Forest Design Models / AD DS Design (Single-Forest-Empfehlung, wann weitere Domänen/Forests)
- Microsoft Learn — Raise the domain and forest functional level (Voraussetzungen, Irreversibilität)
- Microsoft Learn — Fine-Grained Password Policies (mehrere Passwort-Richtlinien je Domäne, DFL-Voraussetzung)
- Microsoft Learn — AD DS Migration / Upgrade vs. Restructure; Active Directory Migration Tool (ADMT) und SID-History
- Microsoft Learn — Configuring SID Filtering / How Domain and Forest Trusts Work (SID-Filtering-Defaults, Selective Authentication)
- dirkjanm.io — Active Directory forest trusts: How does SID filtering work (praktische Wirkung von SID-Filtering und SID-History über Trusts)
- Microsoft Learn — Active Directory domains and forests design
- Microsoft Learn — Forest security boundary and trust design
- Microsoft Learn — Raise domain and forest functional levels
- Microsoft Learn — Lower AD DS domain and forest functional levels
- Microsoft Learn — Active Directory Recycle Bin
- Microsoft Learn — AD DS upgrade and migration planning
- Microsoft Learn — Active Directory forest recovery
- Microsoft security guidance — compromise recovery
- Microsoft Learn — ADMT and SIDHistory migration
- Microsoft Learn — SID filtering and migration trusts
- Microsoft Learn — Selective authentication for forest trusts
- Microsoft Learn — How domain and forest trusts work
- Microsoft Learn — Active Directory migration coexistence planning
- Microsoft Learn — DNS conditional forwarders
- Microsoft Learn — AD migration planning
- Microsoft Learn — ADMT migration and SIDHistory
- Microsoft Learn — SID filtering
- Microsoft Learn — Domains and forests