Domain-Design & Migration: Grenzen, Funktionslevel, Trusts und der saubere Umzug
Einführung · 8 Abschnitte · ~9 Min Lesezeit · Stand
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.
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?
- 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. |
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?
- 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. |
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).