Active Directory Trust SID-Filterung Selektive Authentifizierung Audit: Erkennung und Behebung

Active Directory Trust SID-Filterung Selektive Authentifizierung Audit-Checkliste

Ein Active Directory Trust SID-Filterung Selektive Authentifizierung Audit beantwortet eine Frage: Wenn die Domäne oder der Forest am anderen Ende eines Trusts kompromittiert ist, wie weit kann ein Angreifer in Ihre Umgebung vordringen? Ein Trust ist kein einzelner Ein/Aus-Schalter — er ist ein Trusted Domain Object (TDO) mit mehreren unabhängigen Sicherheitsattributen, und jedes davon kann über die Lebensdauer des Trusts unbemerkt von einer sicheren Standardeinstellung abweichen. Diese Checkliste behandelt die drei wichtigsten Einstellungen, die genauen Befehle zu ihrer Prüfung und wie jeder Befund behoben wird, ohne die Authentifizierung für legitime Nutzer zu unterbrechen. Sie ist als ein Baustein eines breiteren Reviews gedacht — siehe Active Directory Sicherheit auditieren: Was zuerst zu prüfen ist und wie die Behebung nachgewiesen wird für die Einordnung von Trusts im Gesamtumfang.

Drei Einstellungen leisten den Großteil der Arbeit:

• SID-Filterung (Quarantäne) — verhindert, dass eine kompromittierte Trusted Domain gefälschte SID-History injiziert, um privilegierte Gruppenmitgliedschaft auf Ihrer Seite zu beanspruchen.
• Selektive Authentifizierung — schränkt ein, welche Konten in der Trusted Domain/dem Trusted Forest sich bei welchen Ressourcen auf Ihrer Seite authentifizieren dürfen, statt der gesamten Population zu vertrauen.
• Trust-Verschlüsselung — ob Kerberos-Traffic über den Trust noch auf RC4 zurückfallen kann, oder ausschließlich AES nutzt.

Wo die Einstellungen tatsächlich liegen

Jedes Trust-Attribut liegt in der trustAttributes-Bitmaske des TDO. Gemäß dem TrustAttributes-Feld, das für das Windows-Sicherheitsereignis 4716 dokumentiert ist, sind die für dieses Audit wichtigsten Bits 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — SID-Filterung aktiv), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — Cross-Forest-Trust) und 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — lockert die Forest-Trust-Filterung auf die Regeln eines External Trust). Selektive Authentifizierung und die vom Trust unterstützten Kerberos-Verschlüsselungstypen werden separat gespeichert, im Attribut msDS-SupportedEncryptionTypes des Interdomain-Trust-Kontos. Keine dieser drei Einstellungen hängt von den anderen ab — ein Trust kann SID-Filterung aktiviert haben und trotzdem nur RC4-Verschlüsselung oder forest-weite Authentifizierung erlauben, daher braucht jede ihre eigene Prüfung.

SID-Filterung: Prüfen, ob die Quarantäne tatsächlich aktiv ist

SID-Filterung ist sowohl bei External Trusts als auch bei Forest Trusts standardmäßig aktiviert — sie ist bei Intra-Forest-Trusts (Parent/Child) explizit deaktiviert, wo SID-History erwartet wird und vertrauenswürdig ist. Die Katalog-Lücke TRUST_SID_FILTERING_DISABLED schlägt an, wenn die Quarantäne bei einem Inter-Forest- oder External-Trust abgeschaltet wurde — fast immer das Ergebnis eines Migrationsprojekts, das sie zur Erhaltung der SID-History deaktiviert und nie wieder aktiviert hat.

Quarantäne-Status prüfen

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

SIDFilteringQuarantined = $False bei einem External- oder Forest-Trust bedeutet, dass SID-History von der Gegenseite ungefiltert akzeptiert wird — ein kompromittierter Administrator in der Trusted Domain kann einen SID-History-Eintrag fälschen, der Mitgliedschaft in Domain Admins (oder Enterprise Admins) beansprucht, und direkt über den Trust eindringen. netdom liest und setzt dasselbe Attribut:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine
netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

Beheben, ohne eine Migration zu unterbrechen

Selektive Authentifizierung: Wer sich authentifizieren darf, eingrenzen

Selektive Authentifizierung wird auf der ausgehenden Seite eines External- oder Forest-Trusts konfiguriert und beschränkt die Authentifizierung auf nur die Konten der Trusted-Seite, denen das erweiterte Recht Allowed to Authenticate explizit für die konkreten Computerobjekte gewährt wurde, die sie erreichen müssen. Ohne diese Einstellung kann sich jeder authentifizierte Nutzer in der Trusted Domain oder dem Trusted Forest an jeder Ressource auf der Trusting-Seite zu authentifizieren versuchen — Kerberos erzwingt weiterhin objektbezogene ACLs, aber die Angriffsfläche für Credential-Angriffe, Ressourcen-Enumeration und Lateral Movement ist dramatisch größer.

Die Lücke TRUST_EXTERNAL_NO_SELECTIVE_AUTH markiert External Trusts, die ohne selektive Authentifizierung laufen — External Trusts werden häufig für eine einzelne Fachintegration eingerichtet (eine Partnerdomäne, eine übernommene, noch nicht fusionierte Tochtergesellschaft) und bleiben bei forest-weiter Authentifizierung, weil niemand die "Allowed to Authenticate"-Berechtigungen beim Setup eingegrenzt hat.

Status der selektiven Authentifizierung prüfen

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

Ein Wert von $False bei einem External- oder One-Way-Forest-Trust bedeutet, dass der Trust für jedes Konto auf der Trusted-Seite offen ist. Vergleichen Sie das mit dem tatsächlichen fachlichen Bedarf — wenn nur drei Service-Konten aus einer Partnerdomäne einen Dateiserver erreichen müssen, ersetzt selektive Authentifizierung plus drei "Allowed to Authenticate"-Berechtigungen den Zustand "die gesamte Partnerdomäne kann alles erreichen" durch eine benannte, auditierbare Allow-Liste.

Trust-Verschlüsselung: RC4 vs. AES auf der Leitung

Das Attribut msDS-SupportedEncryptionTypes des Interdomain-Trust-Kontos bestimmt, welche Kerberos-Verschlüsselungstypen für Cross-Trust-Tickets ausgehandelt werden, unter Verwendung derselben Bitmaske, die Microsoft für Konto-Verschlüsselungstypen dokumentiert: 0x4 = nur RC4, 0x18 = nur AES128 + AES256, 0x1C = RC4 plus beide AES-Stärken. Ein Wert von 0 (undefiniert) fällt auf RC4_HMAC_MD5 zurück. Für das breitere Bild, wo RC4-Fallback außerhalb von Trusts noch auftritt, siehe Kerberos RC4-Fallback in Active Directory.

Die Verschlüsselungstypen des Trusts prüfen

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Get-ADObject $trustDN -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

• TRUST_RC4_ONLY schlägt an, wenn das Attribut auf 0x4 steht — jedes Service-Ticket über den Trust nutzt RC4, den Verschlüsselungstyp hinter CVE-2022-37966 und der Kerberoasting-Angriffsklasse. Microsoft hat angekündigt, RC4 bis Ende Q2 2026 als standardmäßig angenommenen unterstützten Verschlüsselungstyp für Domänencontroller zu deaktivieren, daher ist ein RC4-only-Trust auch ein Zukunftsfähigkeitsproblem, nicht nur eine Härtungslücke.
• TRUST_AES_DISABLED schlägt an, wenn AES-Bits (0x8/0x10) im Attribut vollständig fehlen — der Trust wurde nie für AES konfiguriert und verlässt sich darauf, worauf der domänenweite Standard zufällig auflöst.

Erkennung

Erkennung im Ereignisprotokoll

Für das vollständige Bild, welche Windows-Sicherheitsereignis-IDs über Trusts hinaus priorisiert werden sollten, siehe Active Directory Monitoring: Sicherheitsereignis-IDs, die zählen.

PowerShell-Statusprüfungen

# Einmalige Statusprüfung über alle Trusts
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Ein Ticket über den Trust anfordern und den ausgehandelten Verschlüsselungstyp auslesen
klist get HOST/dc01.trusted.example.com

Ein klist-Ergebnis, das RC4-HMAC zeigt, wo AES256-CTS-HMAC-SHA1-96 erwartet wurde, bestätigt, dass der Trust in der Praxis noch RC4 aushandelt, nicht nur in der Konfiguration.

Behebung

Schrittweise Härtung

1. SID-Filterung reaktivieren bei jedem External- und Forest-Trust, der sich nicht mitten in einer Migration befindet: netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Selektive Authentifizierung eingrenzen bei External- und One-Way-Forest-Trusts: auf der ausgehenden Seite aktivieren, dann Allowed to Authenticate nur für die konkreten Computerobjekte vergeben, die die Konten der Trusted-Seite tatsächlich benötigen — nicht für die gesamte OU.
3. Trusts auf AES-only umstellen: msDS-SupportedEncryptionTypes beim Interdomain-Trust-Konto auf 0x18 setzen und die GPO Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren anwenden, um domänenweit auf AES128/AES256 einzugrenzen, bevor RC4 auf Trust-Ebene deaktiviert wird — so werden Legacy-Mitglieder, die nur RC4 unterstützen, nicht unterbrochen.
4. Nach dem Änderungsfenster erneut verifizieren: die Get-ADTrust-Prüfung erneut ausführen und bestätigen, dass Event-ID 4716 die erwartete Änderung protokolliert hat, dann einige Tage lang 4768/4769 beobachten, um sicherzustellen, dass keine unerwarteten Authentifizierungsfehler von Geräten auftreten, die noch RC4 benötigten.

Häufiger Fehlerfall, den es zu testen gilt

Compliance-Zuordnung

Trust-Härtung ordnet sich auch der etablierten französischen ANSSI-Active-Directory-Leitlinie zu (ANSSI-PA-099, Abschnitt 3.2.3.1), nützlich, wenn Ihr Audit an ein benanntes Framework anknüpfen soll statt nur an interne Best Practice: R24 ("Durcir la configuration des relations d'approbation AD sortantes extraforêt") deckt die Reaktivierung der SID-Filterung ab — Entfernen von TREAT_AS_EXTERNAL und Hinzufügen von QUARANTINED_DOMAIN — bei ausgehenden Forest- und External-Trusts, und R25+ ("Utiliser des relations d'approbation sortantes avec authentification sélective") deckt die Eingrenzung selektiver Authentifizierung bei denselben Trusts ab. Ein Trust, der gleichzeitig R24 und R25+ verfehlt, sollte als höchstprioritärer Befund im Audit behandelt werden, da ihm keine der beiden in diesem Artikel behandelten Zugriffskontrollschichten zur Verfügung steht. Der ANSSI-Leitfaden veröffentlicht keine Trust-spezifische Empfehlung zu RC4/AES-Verschlüsselung, behandeln Sie die obige Verschlüsselungsprüfung daher als eigenständige Härtungsmaßnahme. Betrachten Sie R24/R25+ als eine Möglichkeit, den Schweregrad gegenüber Auditoren und Stakeholdern zu kommunizieren, die bereits mit dem ANSSI-Framework arbeiten, nicht als Ersatz für die zugrundeliegenden Get-ADTrust- und msDS-SupportedEncryptionTypes-Prüfungen oben.

Wie EtcSec dies erkennt

Die Trusts-Prüfungen von EtcSec lesen die trustAttributes-Bitmaske des TDO und das msDS-SupportedEncryptionTypes-Attribut des Interdomain-Trust-Kontos direkt aus und markieren TRUST_SID_FILTERING_DISABLED und TRUST_AES_DISABLED/TRUST_RC4_ONLY auf dieselbe Weise wie Get-ADTrust und Get-ADObject oben, plus TRUST_EXTERNAL_NO_SELECTIVE_AUTH für External Trusts ohne selektive-Authentifizierung-Flag. Befunde verlinken zurück auf das konkrete Trust-Objekt und seine Richtung, sodass die Behebung genau auf den benötigten netdom- oder PowerShell-Befehl zielt — kein manuelles Abgleichen von AD-Domänen und -Trusts gegen eine Tabellenkalkulation. Falls Trust-Drift zwischen Audits immer wieder auftritt, behandelt Wiederkehrendes AD-Audit-Workflow, wie man das kontinuierlich statt nur einmal jährlich erkennt.