AD-Trusts und Multi-Domain-Forest-Szenarien

Warum Trusts ueberhaupt ein Thema sind

Solange dein KMU einen einzigen Forest mit einer einzigen Domain betreibt, begegnest du Trusts kaum – abgesehen von den unsichtbaren, automatisch erstellten Trusts zwischen Domains im selben Forest. Spannend wird es, sobald zwei getrennte AD-Umgebungen zusammenarbeiten muessen: nach einer Firmenuebernahme, bei einer Fusion zweier Standorte mit historisch getrennten Domains, bei einer Auslagerung an einen Dienstleister mit eigenem Forest, oder wenn ein Kunde dir Zugriff auf sein AD geben will, ohne dass eure Benutzer in seiner Domain landen.

Ein Trust ist im Kern eine Vertrauensbeziehung zwischen zwei Kerberos-Realms (Domains oder Forests), die es Benutzern aus der einen Seite erlaubt, sich gegen Ressourcen auf der anderen Seite zu authentifizieren – ohne dass ihr Konto dort dupliziert werden muss. Wer das Konzept einmal sauber verstanden hat, spart sich bei Merger-Projekten Wochen an Troubleshooting.

Die Trust-Typen im Ueberblick

AD kennt mehrere Trust-Typen, die sich in Richtung, Transitivitaet und Reichweite unterscheiden. Die folgenden vier entstehen automatisch, sobald du eine Domain-Struktur aufbaust:

• Parent-Child-Trust: entsteht automatisch, wenn du eine Child-Domain unter eine bestehende Domain haengst (z.B. zh.firma.ch unter firma.ch). Zweiseitig, transitiv.
• Tree-Root-Trust: entsteht automatisch, wenn du im selben Forest einen neuen Domain-Baum mit eigenem Namensraum hinzufuegst. Zweiseitig, transitiv.
• Shortcut-Trust: manuell erstellt zwischen zwei Domains im selben Forest, um lange Authentifizierungspfade abzukuerzen (relevant bei tiefen, verschachtelten Domain-Baeumen). Transitiv.
• Realm-Trust: verbindet eine AD-Domain mit einem Nicht-Windows-Kerberos-Realm, z.B. einem MIT-Kerberos- oder Heimdal-Realm unter Linux/Unix. Kann transitiv oder nicht-transitiv sein.

Fuer die Praxis im KMU-Kontext bei Firmenzusammenschluessen sind aber vor allem diese zwei relevant:

• Forest-Trust: verbindet die Root-Domains zweier kompletter Forests miteinander. Alle Domains innerhalb beider Forests koennen sich danach gegenseitig vertrauen.
• External Trust: verbindet zwei einzelne Domains (nicht ganze Forests) miteinander, auch domainuebergreifend zwischen verschiedenen Forests.

Forest-Trust vs. externer Trust im Detail

Forest-Trust

Ein Forest-Trust wird zwischen den Forest-Root-Domains zweier Forests eingerichtet und wirkt sich auf alle Domains beider Forests aus – vorausgesetzt, beide Forests laufen mindestens auf Forest-Funktionsebene Windows Server 2003. Innerhalb des Trusts werden automatisch Name-Suffix-Routing-Eintraege fuer jeden UPN-Suffix und jede Domain im jeweils anderen Forest angelegt, sodass Kerberos-Referrals korrekt durchgereicht werden.

Wichtige Eigenschaften:

• Transitiv innerhalb des eigenen Forests (alle Domains im Forest A vertrauen automatisch allen Domains im Forest B), aber nicht transitiv ueber einen dritten Forest hinweg. Forest A vertraut Forest B, Forest B vertraut Forest C – das bedeutet nicht, dass Forest A automatisch Forest C vertraut.
• Kann ein- oder zweiseitig eingerichtet werden.
• SID-Filtering ist standardmaessig aktiv (siehe unten).
• Voraussetzung: eindeutige, sich nicht ueberschneidende Namensraeume (DNS-Namen, NetBIOS-Namen, SID-Namespaces) zwischen beiden Forests. Ueberschneidungen fuehren zu Konflikten beim Trust-Aufbau.

External Trust

Ein External Trust verbindet zwei einzelne Domains, unabhaengig davon, in welchem Forest sie liegen. Er ist immer nicht-transitiv: Vertraut Domain A der Domain B, betrifft das ausschliesslich diese eine Beziehung – keine anderen Domains im jeweiligen Forest sind eingeschlossen.

Typische Einsatzszenarien:

• Migration von einer alten Windows-NT4-Domain (die kein Forest-Konzept kennt) in eine moderne AD-Domain.
• Punktuelle Zusammenarbeit mit einer einzelnen Fremd-Domain, ohne dass gleich der ganze Forest involviert werden soll.
• Zwischenschritt waehrend einer Domain-Migration mit ADMT, wenn (noch) kein sauberer Forest-Trust moeglich oder gewuenscht ist.

Transitive Trusts – was das konkret bedeutet

Transitivitaet ist der Punkt, an dem viele Admins ins Straucheln geraten, weil er intuitiv falsch verstanden wird. Transitiv heisst: Wenn Domain A der Domain B vertraut und Domain B der Domain C vertraut, dann vertraut A automatisch auch C – aber nur innerhalb desselben Forests, weil dort die Transitivitaet durch die gemeinsame Kerberos-Vertrauenskette (ueber die Forest-Root) technisch gegeben ist.

Ueber Forest-Grenzen hinweg gilt das nicht automatisch. Ein Forest-Trust zwischen Forest A und Forest B ist zwar “transitiv” in dem Sinne, dass er alle Domains innerhalb von A und B einschliesst – er propagiert sich aber nicht weiter zu einem Forest C, selbst wenn B einen eigenen Trust zu C hat. Diese Nicht-Weitervererbung ueber mehr als zwei Forests hinweg ist eine bewusste Sicherheitsgrenze, keine technische Einschraenkung.

Praxisbeispiel: Firma A (Forest firma-a.ch) fusioniert mit Firma B (Forest firma-b.ch), beide behalten vorerst ihre Forests. Ein Jahr spaeter kommt Firma C dazu, die bereits einen Forest-Trust mit Firma B hat. Die Nutzer von A koennen nicht automatisch auf Ressourcen von C zugreifen, nur weil B mit beiden einen Trust hat – dafuer braucht es einen eigenen, expliziten Trust zwischen A und C.

Selektive Authentifizierung

Ein Forest-Trust oder externer Trust oeffnet standardmaessig sehr viel: Jeder authentifizierte Benutzer der Gegenseite kann sich grundsaetzlich gegen jede Ressource authentifizieren, sofern die NTFS-/Freigabe-Berechtigungen es erlauben. Das ist bei einer Vollfusion oft gewuenscht, bei einer losen Partnerschaft oder waehrend einer laufenden Integration meist zu offen.

Selektive Authentifizierung (Selective Authentication) engt das ein: Nur explizit autorisierte Benutzer oder Gruppen der vertrauten Seite duerfen sich ueberhaupt gegen einen bestimmten Computer authentifizieren – unabhaengig davon, welche Freigabeberechtigungen dort liegen. Technisch geschieht das ueber eine zusaetzliche Berechtigung (“Allowed to Authenticate”) direkt auf dem Computerobjekt in AD.

Ablauf beim Einrichten:

1. Trust erstellen und die Option “Selective authentication” statt “Forest-wide authentication” waehlen (im Assistenten fuer neue Vertrauensstellung oder per PowerShell).
2. Auf jedem Zielserver, auf den Nutzer der Gegenseite zugreifen sollen, in den erweiterten Sicherheitseinstellungen des Computerobjekts (Tab “Security” in ADUC bei aktivierten erweiterten Features) die Berechtigung “Allowed to Authenticate” fuer die betreffenden Benutzer oder Gruppen der Fremd-Domain setzen.
3. Ohne diese explizite Freigabe schlaegt die Authentifizierung fehl, selbst wenn NTFS-Berechtigungen auf der Freigabe an sich passen wuerden.

# Forest-Trust mit selektiver Authentifizierung per PowerShell (ActiveDirectory-Modul)
# Trust muss bereits bestehen; hier wird SelectiveAuthentication nachtraeglich gesetzt
$trustTarget = "firma-b.ch"
Set-ADTrust -Identity $trustTarget -SelectiveAuthentication $true

# Kontrolle: aktuelle Trust-Eigenschaften anzeigen
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

# "Allowed to Authenticate" auf einem Zielserver-Objekt setzen (Beispiel via dsacls)
# Gruppe FIRMA-B\VertriebGlobal darf sich gegen SRV-FILE01 authentifizieren
dsacls "CN=SRV-FILE01,OU=Server,DC=firma-a,DC=ch" /I:S /G "FIRMA-B\VertriebGlobal:CA;Allowed to Authenticate"

SID-Filtering und SID-Quarantine

Jeder Benutzer bringt bei der Kerberos-Authentifizierung ein PAC (Privilege Attribute Certificate) mit, das unter anderem seine Gruppenmitgliedschaften als SIDs enthaelt – inklusive eines moeglichen SID-History-Attributs. SID-History wird bei Domain-Migrationen genutzt, damit ein migrierter Benutzer seine alten Berechtigungen (ueber die alte SID) behaelt, ohne dass alle ACLs neu gesetzt werden muessen.

Das Problem: Ein boesartiger Domain-Admin auf der vertrauten (trusted) Seite koennte einem eigenen Konto per SID-History beliebige SIDs unterschieben – zum Beispiel die SID von “Domain Admins” der vertrauenden (trusting) Seite – und sich damit Admin-Rechte im fremden Forest erschleichen. Das ist als SID-History-Injection ein bekannter Angriffsvektor in AD-Pentests.

SID-Filtering (Quarantine) ist die Gegenmassnahme: Es filtert bei der Authentifizierung ueber den Trust alle SIDs heraus, die nicht aus der Domain stammen, mit der der Trust direkt besteht. Bei Forest-Trusts ist SID-Filtering standardmaessig fuer alle Domains ausserhalb der unmittelbar vertrauten Domain aktiv (SIDFilteringForestAware), bei externen Trusts ist die Quarantaene (SIDFilteringQuarantined) ebenfalls standardmaessig eingeschaltet.

# Aktuellen SID-Filtering-Status eines Trusts pruefen
Get-ADTrust -Identity "firma-b.ch" | Format-List Name, SIDFilteringQuarantined, SIDFilteringForestAware

# SID-Filtering ueber netdom kontrollieren (klassisches Tool, funktioniert weiterhin zuverlaessig)
netdom trust firma-a.ch /domain:firma-b.ch /quarantine:yes /userD:firma-a\admin /passwordD:*

# Fuer Forest-Trusts: SID-History bei der Migration temporaer erlauben
netdom trust firma-a.ch /domain:firma-b.ch /enablesidhistory:yes /userD:firma-a\admin /passwordD:*

Entscheidungstabelle: Welcher Trust fuer welches Szenario?

Firmenzusammenschluesse und Domain-Migration mit ADMT

Der haeufigste Grund, warum ein KMU sich ueberhaupt mit Multi-Forest-Trusts beschaeftigt, ist eine Firmenuebernahme oder Fusion. Zwei typische Zielbilder:

1. Koexistenz mit Trust: Beide Forests bleiben bestehen, ein Forest-Trust verbindet sie dauerhaft. Geringerer Migrationsaufwand, aber doppelte Administration auf unbestimmte Zeit.
2. Konsolidierung per Migration: Eine Domain wird komplett in die andere migriert (Benutzer, Gruppen, Computer, Server), danach wird der alte Forest stillgelegt. Hoeherer initialer Aufwand, aber langfristig ein sauberes, einheitliches AD.

Fuer Variante 2 ist das Active Directory Migration Tool (ADMT) das Standardwerkzeug von Microsoft. Es ist kostenlos, wird aber nicht mehr aktiv weiterentwickelt (letzte Version 3.2) und muss auf einem Mitgliedsserver der Ziel-Domain installiert werden.

Ablauf einer typischen ADMT-Migration

1. Vorbereitung: Forest-Funktionsebene, DNS-Aufloesung und Namensraum-Konflikte pruefen. Trust zwischen Quell- und Zieldomain aufbauen (bidirektional, da ADMT in beide Richtungen kommunizieren muss).
2. Password Export Server (PES) in der Quelldomain installieren – noetig, wenn Passwoerter mitmigriert werden sollen (verhindert, dass alle User ein neues Passwort brauchen).
3. SID-History aktivieren: Auf dem Trust muss SID-History temporaer erlaubt sein, damit migrierte Benutzer ihre alte SID als SID-History-Eintrag behalten und weiterhin auf noch nicht migrierte Ressourcen zugreifen koennen.
4. Testlauf: ADMT bietet fuer User-, Gruppen- und Computer-Migration jeweils einen “Test”-Modus, der simuliert, ohne tatsaechlich zu schreiben. Immer zuerst nutzen.
5. Migration in der richtigen Reihenfolge: zuerst Gruppen (ohne Mitglieder), dann Benutzer, dann Gruppenmitgliedschaften aktualisieren, dann Computer/Server, zuletzt Freigabeberechtigungen per SecurityTranslation (Security Translation Wizard in ADMT) auf die neuen SIDs umschreiben.
6. Nacharbeiten: Profile-Migration auf Client-PCs (ADMT bringt dafuer einen Agent mit, der lokale Profile umhaengt), Exchange-/M365-Attribute anpassen falls Hybrid im Spiel ist, alte SID-History nach Abschluss bereinigen.
7. Trust abbauen oder SID-Filtering reaktivieren, sobald die Migration fertig ist.

# Beispiel: Vorbereitender Trust-Aufbau fuer eine ADMT-Migration (auf Quelldomain-Controller)
netdom trust firma-alt.local /domain:firma-neu.ch /add /twoway /userD:firma-neu\admin /passwordD:*

# SID-History fuer die Dauer der Migration erlauben (auf dem Trust in Richtung Quelldomain)
netdom trust firma-alt.local /domain:firma-neu.ch /enablesidhistory:yes /userD:firma-neu\admin /passwordD:*

# Nach Abschluss der Migration: SID-Filtering wieder aktivieren
netdom trust firma-alt.local /domain:firma-neu.ch /enablesidhistory:no /userD:firma-neu\admin /passwordD:*

Entscheidungsbaum: Trust behalten oder migrieren?

Firmenzusammenschluss / Fusion mit zweitem AD-Forest
│
├─ Bleibt die uebernommene Firma organisatorisch eigenstaendig?
│    ├─ Ja → Forest-Trust dauerhaft, selektive Authentifizierung pruefen
│    └─ Nein, volle Integration geplant
│         │
│         ├─ Wie viele Objekte (User/Computer/Gruppen)?
│         │    ├─ < 200 Objekte, wenig Komplexitaet → ADMT reicht meistens
│         │    └─ > 1000 Objekte, Exchange/komplexe ACLs → kommerzielles Tool pruefen
│         │
│         └─ Zeitdruck?
│              ├─ Hoch → erst Trust + Koexistenz, Migration spaeter in Wellen
│              └─ Niedrig → direkte Konsolidierungsmigration in einem Projekt

Haeufige Fallstricke in der Praxis

• DNS vergessen: Ein Trust ohne funktionierende, beidseitige DNS-Aufloesung schlaegt schon bei der Validierung fehl. Conditional Forwarder oder Secondary Zones einrichten, bevor du den Trust-Assistenten startest.
• UPN-Suffix-Kollisionen: Wenn beide Seiten zufaellig dasselbe UPN-Suffix nutzen (z.B. beide .local), fuehrt das zu Mehrdeutigkeiten beim Login. Vor der Migration klaeren, wer welches Suffix behaelt.
• Vergessene Reaktivierung von SID-Filtering: Der klassische Fehler nach einer erfolgreichen Migration – SID-History bleibt aktiviert, weil “es ja noch laeuft”. Das ist ein offenes Sicherheitsloch, das bei jedem Security-Audit sofort auffaellt.
• Gruppenverschachtelung ueber Forest-Grenzen: Universal-Gruppen funktionieren ueber Forest-Trusts hinweg, Domain Local und Global Groups nicht in gleicher Weise. Bei Berechtigungskonzepten mit AGDLP/AGUDLP-Modell (Account, Global, Universal, Domain Local, Permission) muss das beruecksichtigt werden, sonst fehlen nach der Migration ploetzlich Berechtigungen.
• Kerberos vs. NTLM-Fallback: Wenn die Namensaufloesung oder die Trust-Konfiguration nicht ganz sauber ist, faellt die Authentifizierung stillschweigend auf NTLM zurueck – das funktioniert oft trotzdem, versteckt aber das eigentliche Problem und schwaecht die Sicherheit.
• Firewall zwischen den Standorten: Ein Trust braucht deutlich mehr als nur Port 389/636 (LDAP/LDAPS) – auch Kerberos (88), RPC-Endpoint-Mapper (135) und einen dynamischen RPC-Portbereich muessen zwischen den DCs beider Seiten offen sein.

Weiterlernen

• Trusts – Active Directory Domain Services | Microsoft Learn
• Security Considerations for Trusts | Microsoft Learn
• Netdom trust | Microsoft Learn
• Using DsAddSidHistory (ADMT SID-History-Migration) | Microsoft Learn
• Active Directory forest trusts – How does SID filtering work? | dirkjanm.io
• Get-ADTrust | Microsoft Learn

Verwandte Themen: AD-Grundlagen · AD Benutzer und Gruppen · AD Security Hardening & Tier-Modell · DNS-Grundlagen · Entra Connect Sync im Detail