Active Directory Trusts konfigurieren und absichern

Was sind Active Directory Trusts

Active Directory Trusts (Vertrauensstellungen) ermöglichen es einem Domänencontroller in einer Domäne, die Identität eines Kontos zu bestätigen, das sich in einer anderen Domäne oder Gesamtstruktur (Forest) authentifiziert hat. Intern wird jeder Trust als Trusted Domain Object (TDO) gespeichert, das den Namen der vertrauten Domäne, die Richtung, die Transitivität und ein gemeinsames Geheimnis speichert — das Trust-Passwort —, das den Authentifizierungsverkehr über die Grenze hinweg schützt. Active Directory Trusts machen eine Multi-Domänen-Gesamtstruktur erst nutzbar: Ohne sie wäre jede Domäne eine isolierte Authentifizierungsinsel ohne Möglichkeit, Benutzer oder Gruppen aus einer anderen Domäne zu referenzieren.

Ein Trust allein gewährt keinen Zugriff. Er erweitert lediglich den Authentifizierungspfad — was das anfragende Konto auf der anderen Seite tatsächlich erreichen kann, wird weiterhin durch ACLs, Gruppenmitgliedschaften und Delegationseinstellungen bestimmt. Ein schlecht konfigurierter Trust vergrößert dennoch den Explosionsradius einer Kompromittierung auf beiden Seiten — weshalb die Trust-Konfiguration die gleiche Disziplin verdient wie jede andere Tier-0-Änderung.

Trust-Typen und Transitivität

Nicht jeder Trust verhält sich gleich. Zwei Eigenschaften entscheiden, wie weit ein Trust tatsächlich reicht: die Richtung (welche Seite sich bei der anderen authentifizieren kann) und die Transitivität (ob sich der Trust implizit auf Domänen erstreckt, denen die vertraute Seite selbst vertraut).

Zwei Konsequenzen sind für die Härtung entscheidend:

• Transitivitätsketten. Ein transitiver Forest-Trust endet nicht am Forest-Root — er erstreckt sich auf jede Domäne innerhalb dieser Gesamtstruktur. Wer einer Gesamtstruktur vertraut, vertraut jedem Domänenadministrator darin, nicht nur dem Team, das die Integration angefragt hat.
• Die Richtung begrenzt die Angriffsfläche. Ein einseitiger Trust, bei dem Domäne A Domäne B vertraut, erlaubt Benutzern aus B die Authentifizierung in A, aber nicht umgekehrt. Wo der geschäftliche Bedarf einseitig ist, fügt ein zweiseitiger Trust „zur Sicherheit" nur einen Authentifizierungspfad hinzu, den niemand angefordert hat. TRUST_BIDIRECTIONAL im EtcSec-Katalog markiert jeden zweiseitigen External-, Forest- oder Cross-Tree-Trust (Parent-Child-Trusts sind ausgenommen, da diese per Design zweiseitig sind) — ein Konfigurationssignal, das überprüft werden sollte, keine Feststellung, dass der Datenverkehr in der Praxis nur in eine Richtung fließt.

Sicheren Trust Schritt für Schritt konfigurieren

Die folgenden Schritte konzentrieren sich auf External- und Forest-Trusts — die Fälle, die eine gezielte Härtung benötigen. Parent-Child- und Tree-Root-Trusts werden automatisch durch die Domänen- und Forest-Promotion erstellt und erben die gesamtstrukturweiten Standardeinstellungen; SID-Filtering gilt für sie per Design nicht, da SID-History zwischen Domänen derselben Gesamtstruktur erwartet wird.

Schritt 1 — Den Trust planen, bevor er erstellt wird

Notieren Sie, bevor Sie eine Konsole öffnen: welche Seite die Authentifizierung initiiert, ob er ein- oder zweiseitig sein muss, welche Ressourcen die vertraute Seite tatsächlich erreichen muss, wer die Beziehung verantwortet, und ein Überprüfungsdatum. Ein Trust ohne Owner und ohne Überprüfungsdatum ist genau der, der fünf Jahre nach Ende des Projekts, das ihn angefordert hat, immer noch offen ist.

Schritt 2 — Den Trust erstellen

Erstellen Sie den Trust über die Konsole Active Directory-Domänen und -Vertrauensstellungen (New Trust Wizard) oder nicht-interaktiv mit netdom:

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Lassen Sie /twoway für einen einseitigen Trust weg — richten Sie sich danach, was Schritt 1 tatsächlich erfordert, nicht danach, was sich am schnellsten anklicken lässt.

Schritt 3 — Trust-Verschlüsselung auf AES beschränken

Neue Trusts sollten nie auf dem Verschlüsselungs-Standardwert belassen werden. Prüfen Sie das Attribut msDS-SupportedEncryptionTypes des Interdomain-Trust-Kontos und setzen Sie es auf AES-only (0x18), sobald jedes System, das sich über den Trust authentifiziert, AES unterstützt:

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Ein nicht gesetztes Attribut ist in keine Richtung ein sicherer Standardwert — Microsofts eigene Anleitung weist darauf hin, dass AES standardmäßig nur dann für Domänencontroller, Read-Only-Domänencontroller und Trusts unterstützt wird, wenn der bereitstellende DC für die Kerberos-RC4-Änderungen von 2022 gepatcht ist, und ein veralteter oder nie angefasster Trust kann weiterhin RC4 aushandeln. TRUST_AES_DISABLED löst immer dann aus, wenn das Attribut keine AES-Unterstützung meldet — auch wenn es schlicht nicht gesetzt ist. TRUST_RC4_ONLY ist enger gefasst: Es schlägt nur an, wenn der Trust explizit RC4-Unterstützung ohne AES meldet, sodass ein lediglich nicht gesetztes Attribut es nicht auslöst.

Schritt 4 — SID-Filtering aktivieren (Quarantäne)

SID-Filtering ist bei neuen External- und Forest-Trusts standardmäßig aktiviert, wird jedoch routinemäßig während Migrationen deaktiviert, die von sIDHistory abhängen, und danach oft nie wieder aktiviert. Bestätigen Sie es explizit:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

TRUST_SID_FILTERING_DISABLED markiert jeden External- oder Forest-Trust, bei dem dies deaktiviert ist. Schalten Sie es nicht blind um — wenn eine Migration derzeit von SID-History abhängt, um den Zugriff zu erhalten, unterbricht die Quarantäne diesen Zugriff, bis die Migration abgeschlossen ist.

Schritt 5 — Selective Authentication eingrenzen

Selective Authentication verwandelt „jeder authentifizierte Benutzer auf der vertrauten Seite kann versuchen, alles auf dieser Seite zu erreichen" in eine benannte Allow-List. Aktivieren Sie sie auf der ausgehenden Seite des Trusts und gewähren Sie das erweiterte Recht Allowed to Authenticate dann nur für die spezifischen Computerobjekte, die die Konten der vertrauten Seite tatsächlich benötigen:

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

TRUST_EXTERNAL_NO_SELECTIVE_AUTH löst aus, wenn für einen External-Trust keine Selective Authentication konfiguriert ist — die mit Abstand häufigste Lücke bei Trusts, die für eine einmalige Partnerintegration eingerichtet wurden.

Schritt 6 — Den Trust validieren

Bestätigen Sie, dass sich der Trust so verhält, wie es Schritt 1 vorsah, bevor Sie die Änderung als abgeschlossen betrachten:

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

Erzwingen Sie anschließend einen echten Authentifizierungsversuch über den Trust und lesen Sie den ausgehandelten Verschlüsselungstyp mit klist aus. Konfigurationszustand und das, was tatsächlich auf der Leitung ausgehandelt wird, können auseinanderlaufen, wenn eine nachgelagerte GPO oder ein Legacy-Mitglied die eigene Einstellung des Trusts überschreibt.

Erkennung

Die Erstellung und Änderung von Trusts sind protokollierte Ereignisse, keine stillen Änderungen — wenn Trust-Drift nur in einem periodischen Audit auftaucht statt in einem Alert, ist die Logging-Pipeline die Lücke, nicht die Sichtbarkeit.

Ein einzelnes Ereignis beweist für sich genommen wenig — ein 4716, das SidFilteringEnabled deaktiviert, ist während einer geplanten Migration Routine und überall sonst alarmierend. Alarmieren Sie beim Ereignis und gleichen Sie es dann mit dem Change-Ticket ab.

Remediation und Hardening-Checkliste

1. Jeden Trust inventarisieren mit Get-ADTrust -Filter * und für jeden einen Owner, eine geschäftliche Begründung und ein Überprüfungsdatum festhalten.
2. Richtung am tatsächlichen Bedarf ausrichten — keinen zweiseitigen Trust betreiben, wenn die Authentifizierung nur in eine Richtung fließt.
3. SID-Filtering aktivieren für jeden External- und Forest-Trust, der sich nicht gerade mitten in einer Migration befindet.
4. Selective Authentication eingrenzen auf die spezifischen Systeme, die die vertraute Seite benötigt, nicht auf die gesamte Domäne.
5. Auf AES-only-Verschlüsselung umstellen, sobald jedes authentifizierende System dies unterstützt.
6. Trusts ohne aktuellen Owner oder geschäftlichen Bedarf entfernen, statt sie unbegrenzt „dokumentiert" zu belassen.

Für die vollständige Checkliste mit PowerShell für jede Prüfung und dem Compliance-Mapping siehe Active Directory Trust SID-Filtering und Selective Authentication Audit. Für die Angriffserzählung, gegen die diese Kontrollen schützen, siehe Active Directory Trust-Angriffe: Von der Child-Domäne zum Forest-Root.

Trust-Lifecycle: Zweiseitige, transitive und inaktive Trusts

Trusts sind leicht zu erstellen und leicht zu vergessen. Drei Katalog-Findings zielen genau auf diese Lifecycle-Lücke:

• TRUST_BIDIRECTIONAL — markiert jeden zweiseitigen Trust außerhalb von Parent-Child rein anhand der Konfiguration, unabhängig von der beobachteten Nutzung. Wenn der geschäftliche Bedarf einseitig ist, entfernt eine Einschränkung auf einseitig einen Authentifizierungspfad, ohne Funktionsverlust.
• TRUST_FOREST_TRANSITIVE — ein Forest-Trust erbt jede Domäne innerhalb der vertrauten Gesamtstruktur, nicht nur die Domäne, die die Integration angefragt hat. Prüfen Sie vor der Genehmigung eines Forest-Trusts die eigene Domänenliste und administrative Hygiene der vertrauten Gesamtstruktur, nicht nur die Ressource, die der Antragsteller benötigt.
• TRUST_INACTIVE — ein Trust, dessen Interdomain-Passwort seit über 180 Tagen nicht rotiert wurde. Windows rotiert das Passwort eines aktiven Trusts automatisch etwa alle 30 Tage, sodass ein veraltetes pwdLastSet eher ein Indikator für einen verwaisten, von niemandem gepflegten Trust ist als ein direktes Maß für Authentifizierungsverkehr. Ein inaktiver Trust, den niemand nutzt, ist dennoch ein lebendiger Authentifizierungspfad, den niemand überwacht. Wenn der geschäftliche Bedarf entfallen ist, entfernen Sie den Trust über den normalen Change-Prozess, statt ihn „für alle Fälle" zu belassen.

Keiner dieser drei Punkte erfordert eine Kompromittierung, um relevant zu sein — es handelt sich um Konfigurations- und Lifecycle-Hygiene-Probleme, die die Angriffsfläche vor einem Vorfall verkleinern, nicht danach.

Wie EtcSec das erkennt

EtcSec liest die trustAttributes-Bitmaske jedes Trusted Domain Object sowie das Attribut msDS-SupportedEncryptionTypes des Interdomain-Trust-Kontos direkt aus — dieselben Eigenschaften, die Get-ADTrust und Get-ADObject oben offenlegen. Es markiert TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY und TRUST_AES_DISABLED für jeden Trust in der Umgebung, wobei die Findings mit dem jeweiligen Trust-Objekt verknüpft sind, sodass die Remediation genau auf den benötigten Befehl abzielt.

Weiterführende Themen

Für die Angriffskette, gegen die diese Kontrollen schützen, siehe Active Directory Trust-Angriffe: Von der Child-Domäne zum Forest-Root. Für die ausführliche Audit-Checkliste zu SID-Filtering, Selective Authentication und Verschlüsselung siehe Active Directory Trust SID-Filtering und Selective Authentication Audit. Die Rotation des Trust-Passworts wird behandelt in krbtgt-Passwortrotation, Trust-Konto, Domänencontroller-Computerkennwort, und das Delegationsrisiko, das häufig über eine Trust-Grenze hinweg auftritt, wird behandelt in Kerberos-Delegationsangriffe: Von Unconstrained bis RBCD-Missbrauch. Wo die Trust-Überprüfung in ein vollständiges Umgebungsaudit passt, zeigt Active Directory-Sicherheit auditieren: Was zuerst zu prüfen ist und wie Remediation nachgewiesen wird.

Primärquellen

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack