Domain-Design & Migration

„Wir brauchen eine eigene Domäne, damit unsere Administratoren nicht an eure Systeme kommen.“ Der Satz enthält eine Anforderung und einen Lösungsvorschlag — und der Vorschlag erfüllt die Anforderung nicht: Ein Domain Admin einer beliebigen Domäne kann sich dokumentiert Forest-weite Rechte verschaffen. Dieses Modul behandelt die tragenden Designentscheidungen und ihre Kosten: wann eine Grenze wirklich zählt und was eine zusätzliche Domäne jeden Monat kostet, was Funktionsebenen freischalten und warum der Rückweg kein Plan ist, In-Place-Upgrade gegen den Neuaufbau in einem pristinen Forest, sIDHistory als Brücke mit scharfer Kante samt der Frage, wo SID-Filterung greift und wo konstruktionsbedingt nicht — und Trust-Design als Angriffsflächen-Design.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-07-27

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.

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.

MerksatzEine 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?

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.

Treffer. 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.

Warum der Rückweg kein Plan istEine Funktionsebene ist kein Schalter mit zwei Stellungen, sondern eine Zusage an alle Domain Controller der Umgebung. Sie anzuheben schaltet Verzeichnisfunktionen frei und schließt zugleich ältere Serverversionen dauerhaft aus. Wo eine Absenkung überhaupt möglich ist, ist sie an Bedingungen geknüpft und nimmt die freigeschalteten Funktionen wieder mit — Konfigurationen, die darauf aufbauen, bleiben dann ohne Grundlage zurück. Plane deshalb vorwärts: Welche Version müssen alle DCs erreichen, bis wann, und was hängt danach daran?

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 wasRestructure 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?

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.

Treffer. 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.

PrinzipTrust-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.

Der Trust, den niemand mehr kenntTrusts überleben die Projekte, für die sie angelegt wurden. Ein Zukauf wird integriert, ein Dienstleister abgelöst, eine Testumgebung stillgelegt — der Trust bleibt, weil ihn niemand vermisst. Für einen Angreifer ist genau das interessant: eine Vertrauensbeziehung zu einer Umgebung, die heute womöglich schlechter gepflegt ist als die eigene. Ein Trust gehört deshalb mit einem Ablaufdatum und einem benannten Verantwortlichen angelegt, und die Liste der bestehenden Trusts gehört in dieselbe wiederkehrende Prüfung wie privilegierte Gruppen.

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.

Was eine zusätzliche Domäne wirklich kostet

„Eine Domäne mehr“ klingt nach einer Konfigurationsentscheidung und ist eine dauerhafte Betriebsverpflichtung. Die Kosten fallen nicht am Tag der Einrichtung an, sondern jeden Monat danach — und sie stehen selten in dem Antrag, der die Domäne begründet.

Eigene Domain Controller, mindestens zwei, an jedem Standort, der lokal anmelden können soll — samt Patchen, Sichern und Überwachen.
Eigene FSMO-Rollen: drei zusätzliche domänenweite Rollen, deren Ausfall wieder eigene Verfahren braucht.
Eigene Kontorichtlinie, eigene Sicherung, eigener Wiederherstellungsplan, eigener Wiederherstellungstest.
Global-Catalog-Pflicht: In einem Forest mit mehreren Domänen ist der Zugriff auf einen GC Voraussetzung für die Anmeldung — jeder Standort braucht einen erreichbaren.
Größere Tokens: Mitgliedschaften über Domänengrenzen hinweg gehen mit höherem Gewicht in das Kerberos-Token ein als domäneninterne. Was heute passt, kann nach einer Migration die Ticket-Obergrenze reißen.

Die ehrliche RechnungDie Frage lautet nie „können wir eine zweite Domäne haben“, sondern: Welche Anforderung erfüllt sie, die eine OU mit Delegation und ein PSO nicht erfüllen? Für abweichende Kennwortregeln ist das ein PSO. Für eigene Verwaltung ist das eine OU mit delegierten Rechten. Es bleibt genau eine Anforderung übrig, die tatsächlich eine Grenze verlangt — und die verlangt dann meist gleich einen eigenen Forest, keine Domäne.

SID-Filtering: wo die Brücke gesichert ist und wo nicht

Weil ein Token alle SIDs eines Kontos trägt — die aktuelle, die aus sIDHistory und die aller Gruppen — und jede davon Zugriff gewähren kann, ist eine eingeschleuste fremde SID ein vollwertiger Angriffspfad. Dagegen gibt es einen Schutz, und seine Reichweite ist der entscheidende Punkt.

Externe Trusts: SID-Filter-Quarantäne ist standardmäßig aktiv. Eingehende Anfragen dürfen nur SIDs von Prinzipalen der vertrauten Domäne enthalten.
Forest-Trusts: SID-Filterung wird erzwungen. Sie verhindert laut Dokumentation, dass jemand mit Domänenadministrator-Rechten in der vertrauten Domäne sich selbst erhöhte Rechte in der vertrauenden verschafft.
Innerhalb eines Forests: Kein Filter. Die Dokumentation sagt ausdrücklich, dass die Erzwingung auf Forest-Trusts die Nutzung von SID-History bei Migrationen innerhalb desselben Forests nicht verhindert.

Warum das die Forest-Grenze noch einmal bestätigtDie dritte Zeile ist kein Versehen, sondern folgerichtig: Innerhalb eines Forests gibt es keine Sicherheitsgrenze, also gibt es dort auch nichts zu filtern. Wer SID-History innerhalb eines Forests für harmlos hält, weil „der Filter das ja abfängt“, verlässt sich auf einen Schutz, den es an dieser Stelle konstruktionsbedingt nicht gibt.

Der pristine Forest: wie ein Restructure abläuft

Wenn ein Altbestand nicht sanierbar ist — gewachsene Rechte, unklare Delegationen, ein Sicherheitsvorfall in der Vergangenheit —, hilft kein Upgrade. Dann wird eine neue, saubere Umgebung aufgebaut und der Bestand hinüberbewegt. Der Reiz liegt darin, dass die Altlasten nicht mitkommen; der Preis liegt in der Koexistenzphase.

Ziel aufbauen — neuer Forest, sauberes Design, nichts übernommen↓Brücke bauen — Trust mit dem engsten Typ und der nötigen Richtung↓Wellenweise migrieren — Objekte umziehen, sIDHistory als temporäre Brücke↓Ressourcen nachziehen — Zugriffssteuerungslisten auf die neuen SIDs umschreiben↓Brücke abbauen — sIDHistory bereinigen, Trust entfernen, Altforest stilllegen

Die letzten beiden Schritte entscheiden über den Erfolg

Wo Restructures tatsächlich scheiternNicht in der Migration, sondern im Abbau. Sind die Objekte drüben und funktioniert alles, verschwindet die Dringlichkeit — und sIDHistory, Trust und Altforest bleiben stehen. Das Ergebnis ist die schlechteste aller Welten: zwei Umgebungen zu betreiben, die Altlasten weiterhin am Hals, und dazu einen Trust als zusätzliche Angriffsfläche. Ein Restructure ohne verbindlichen, terminierten Abbauplan ist deshalb kein Projekt, sondern eine dauerhafte Verdopplung.

Durchgerechnet: „Wir brauchen eine eigene Domäne“

Vier Anforderungen, eine Entscheidung

Szenario

Ein zugekaufter Geschäftsbereich soll in die bestehende Umgebung. Das dortige IT-Team nennt vier Anforderungen und beantragt dafür eine eigene Domäne im bestehenden Forest.

Anforderungen

Jede Anforderung dem kleinsten Werkzeug zuordnen, das sie erfüllt
Die verbleibende Anforderung ehrlich bewerten

Schritte

„Wir brauchen strengere Kennwortregeln.“ Kein Grund für eine Domäne — dafür gibt es ein PSO, gebunden an eine globale Sicherheitsgruppe.
„Wir wollen unsere Benutzer selbst verwalten.“ Kein Grund für eine Domäne — dafür gibt es eine OU mit Delegation of Control auf genau die nötigen Aktionen.
„Wir wollen eigene Gruppenrichtlinien.“ Kein Grund für eine Domäne — GPOs werden an OUs verknüpft. Nur wenige Einstellungen wirken tatsächlich domänenweit; die gehören einzeln geprüft.
„Unsere Administratoren sollen nicht an eure Systeme kommen — und umgekehrt.“ Das ist der einzige echte Grund, und eine Domäne erfüllt ihn nicht: Ihr Domain Admin könnte sich Forest-weite Rechte verschaffen. Isolation verlangt einen eigenen Forest mit Trust.
Die ehrliche Rückfrage: Ist diese Isolation wirklich gefordert — oder ist sie eine Formulierung für „wir wollen unabhängig arbeiten“? Im zweiten Fall lösen die ersten drei Punkte das Anliegen vollständig, zu einem Bruchteil der Betriebskosten.

Merksatz: Anforderungen kommen fast immer als Lösungsvorschlag formuliert. Sie zurück in Anforderungen zu übersetzen und dem kleinsten passenden Werkzeug zuzuordnen ist die eigentliche Designarbeit — und sie entscheidet über Betriebskosten auf Jahre.

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 CheckDu 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.

Jetzt anwenden

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

Zum Modul →

Quellen & Aktualität29 Primärquellen · zuletzt geprüft: 2026-07-27

01Microsoft Learn — What Are Domains and Forests? (Domäne = Verwaltungs-/Replikationsgrenze, Forest = Sicherheitsgrenze; Schema/Konfiguration/GC forest-weit)
02Microsoft Learn — Forest Design Models / AD DS Design (Single-Forest-Empfehlung, wann weitere Domänen/Forests)
03Microsoft Learn — Raise the domain and forest functional level (Voraussetzungen, Irreversibilität)
04Microsoft Learn — Fine-Grained Password Policies (mehrere Passwort-Richtlinien je Domäne, DFL-Voraussetzung)
05Microsoft Learn — AD DS Migration / Upgrade vs. Restructure; Active Directory Migration Tool (ADMT) und SID-History
06Microsoft Learn — Configuring SID Filtering / How Domain and Forest Trusts Work (SID-Filtering-Defaults, Selective Authentication)
07dirkjanm.io — Active Directory forest trusts: How does SID filtering work (praktische Wirkung von SID-Filtering und SID-History über Trusts)
08learn.microsoft.com/en-us/previous-versions/wi…003/cc773178(v=ws.10
09learn.microsoft.com/en-us/windows-server/ident…security-identifiers
10learn.microsoft.com/en-us/troubleshoot/windows…er-belongs-to-groups
11learn.microsoft.com/en-us/previous-versions/wi…003/cc759073(v=ws.10
12Microsoft Learn — Active Directory domains and forests design
13Microsoft Learn — AD DS upgrade and migration planning
14Microsoft Learn — Raise domain and forest functional levels
15Microsoft Learn — Domains and forests
16Microsoft Learn — How domain and forest trusts work
17Microsoft Learn — ADMT and SIDHistory migration
18Microsoft Learn — Forest security boundary and trust design
19Microsoft Learn — Selective authentication for forest trusts
20Microsoft Learn — Lower AD DS domain and forest functional levels
21Microsoft Learn — Active Directory Recycle Bin
22Microsoft Learn — Active Directory migration coexistence planning
23Microsoft Learn — DNS conditional forwarders
24Microsoft Learn — AD migration planning
25Microsoft Learn — SID filtering and migration trusts
26Microsoft Learn — Active Directory forest recovery
27Microsoft security guidance — compromise recovery
28Microsoft Learn — ADMT migration and SIDHistory
29Microsoft Learn — SID filtering