AD-Vertrauensstellungen und Gesamtstrukturgrenzen härten

Die Active-Directory-Dokumentation und ein Großteil der zugehörigen Werkzeuge sprechen noch immer von „Domänensicherheit“, als wäre eine Domäne eine Isolationsgrenze. Das ist sie nicht. Jeder Domänencontroller einer Gesamtstruktur hält ein vollständiges, beschreibbares Replikat der Schema- und der Konfigurationspartition, jede Domäne vertraut der Gesamtstrukturstammdomäne implizit, und Enterprise Admins in der Stammdomäne verfügt über Rechte in jeder Domäne der Gesamtstruktur. Eine untergeordnete Domäne oder Ressourcendomäne als Sicherheitsgrenze zu behandeln und bei der Härtung der Vertrauensstellungen zu sparen, gehört zu den hartnäckigsten Designfehlern in AD-Umgebungen – und genau das erlaubt es einem Angreifer, der in einer unbedeutenden Domäne landet, in die Domäne zu wechseln, auf die es wirklich ankommt.

Dieser Beitrag zeigt, wie Sie die Vertrauensstellungen innerhalb und zwischen Ihren Gesamtstrukturen inventarisieren und härten: Vertrauenstypen und Transitivität, SID-Filterung und Quarantäne, selektive Authentifizierung – und wann eine dedizierte Verwaltungs-Gesamtstruktur oder eine PAM-Vertrauensstellung tatsächlich gerechtfertigt ist und wann das moderne Enterprise Access Model Sie bereits abdeckt.

Die Gesamtstruktur ist die Grenze, nicht die Domäne

Einige Fakten, die jede Entscheidung über Vertrauensstellungen leiten sollten:

• Die Schemapartition und die Konfigurationspartition werden auf jeden DC der Gesamtstruktur repliziert. Eine Schemaänderung oder ein bösartiges Objekt in der Konfigurationspartition (etwa ein gefälschter Gruppenrichtliniencontainer oder eine manipulierte Standortverknüpfung) wirkt sich auf alle Domänen aus.
• Enterprise Admins und Schema Admins (Gesamtstrukturstammdomäne) besitzen gesamtstrukturweite Rechte, einschließlich der Möglichkeit, das Schema zu ändern und Domänen hinzuzufügen.
• Jede Kompromittierung eines Domänencontrollers – in welcher Domäne auch immer – ist ein realistischer Weg zur vollständigen Kompromittierung der Gesamtstruktur, sei es über Replikationsmissbrauch, Schemamanipulation oder das Ausnutzen von Vertrauensstellungen.

Praktische Konsequenz: Wenn Sie echte Isolation benötigen (eine Tochtergesellschaft, die Ihre Kernumgebung nicht beeinträchtigen darf, eine M&A-Übernahme mit unbekanntem Hygienezustand, eine regulatorische Anforderung an getrennte Administration), brauchen Sie eine separate Gesamtstruktur mit einer sorgfältig eingegrenzten Vertrauensstellung – keine untergeordnete Domäne in derselben Gesamtstruktur.

Vertrauenstypen und Transitivität im Überblick

Gesamtstruktur- und externe Vertrauensstellungen sind diejenigen, die eine echte Sicherheitsgrenze überschreiten und die unten beschriebenen Maßnahmen verdienen. Vertrauensstellungen innerhalb der Gesamtstruktur liegen bereits in Ihrem Schadensradius; das beheben Sie mit Tiering (Tier 0 und privilegierter Zugriff), nicht mit Einstellungen der Vertrauensstellung.

Zuerst vorhandene Vertrauensstellungen inventarisieren

Bevor Sie etwas ändern, sollten Sie wissen, was vorhanden ist:

Get-ADTrust -Filter * -Properties * |
  Select-Object Name, Direction, TrustType, ForestTransitive, SIDFilteringForestAware, SIDFilteringQuarantined, SelectiveAuthentication, IntraForest, DisallowTransivity |
  Format-Table -AutoSize

Prüfen Sie jede Vertrauensstellung zusätzlich mit netdom:

netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify
netdom query trust

Markieren Sie jede Vertrauensstellung, bei der:

• SIDFilteringQuarantined auf einer externen Vertrauensstellung False ist oder SIDFilteringForestAware auf einer Gesamtstruktur-Vertrauensstellung True ist (SID-Verlauf wird darüber zugelassen).
• SelectiveAuthentication auf einer externen oder Gesamtstruktur-Vertrauensstellung zu einem nicht vertrauenswürdigen oder niedriger eingestuften Partner False ist.
• die Richtung bidirektional ist, obwohl tatsächlich nur eine Richtung benötigt wird – eine unidirektionale ausgehende Vertrauensstellung von der sensiblen Seite aus beseitigt einen kompletten Angriffspfad.
• die Vertrauensstellung alt, undokumentiert oder an eine stillgelegte Partnerdomäne gebunden ist. Verwaiste Vertrauensstellungen sind in Umgebungen, die Fusionen, Ausgliederungen oder Migrationen durchlaufen und danach nie aufgeräumt haben, weit verbreitet.

SID-Filterung und Quarantäne

Der SID-Verlauf (sIDHistory) dient dazu, Zugriffe über Domänenmigrationen hinweg zu erhalten: Ein Benutzer, der von Domäne A nach Domäne B verschoben wird, behält seine alten SIDs, damit bestehende ACLs weiterhin aufgelöst werden. Derselbe Mechanismus ist die Grundlage von SID History Injection – kompromittiert ein Angreifer Domäne A (oder einen DC darin) und filtert die Vertrauensstellung den SID-Verlauf nicht, kann er einem Prinzipal in Domäne A etwa die SID von Enterprise Admins aus Domäne B anhängen und sich authentifizieren, als wäre er in B privilegiert.

Die SID-Filterung ist bei Gesamtstruktur-Vertrauensstellungen standardmäßig aktiv (SIDs, die nicht zur vertrauenswürdigen Gesamtstruktur gehören, werden verworfen) und – als Quarantäne – auch bei externen Vertrauensstellungen, die mit aktuellen Windows-Server-Versionen erstellt wurden. Während Migrationen wird sie jedoch häufig gelockert (/quarantine:no oder /enablesidhistory:yes) und danach nie zurückgesetzt. Prüfen und erzwingen Sie sie:

:: Enable quarantine (SID filtering) on an external trust
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:yes /userD:<Admin> /passwordD:*

:: On a forest trust: explicitly disable SID history acceptance (only re-enable temporarily during a real migration)
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:no

Programmatisch überprüfen:

Get-ADTrust -Filter {Name -eq "<TrustedDomainName>"} | Select-Object Name, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware

SIDFilteringQuarantined sollte auf jeder externen Vertrauensstellung True und SIDFilteringForestAware auf jeder Gesamtstruktur-Vertrauensstellung False sein – es sei denn, Sie befinden sich in einem aktiven, zeitlich begrenzten Migrationsfenster, in dem der SID-Verlauf benötigt wird. Behandeln Sie dieses Fenster dann als Hochrisikophase, überwachen Sie die Gruppenmitgliedschaftsereignisse 4728/4732/4756 engmaschig und deaktivieren Sie die Annahme des SID-Verlaufs wieder, sobald die Migration abgeschlossen ist.

Selektive Authentifizierung

Die SID-Filterung steuert, welche Identitätsangaben akzeptiert werden. Die selektive Authentifizierung steuert, welche Ressourcen Prinzipale der vertrauenswürdigen Domäne überhaupt zu erreichen versuchen dürfen. Auf einer Gesamtstruktur- oder externen Vertrauensstellung mit aktivierter selektiver Authentifizierung erhält ein Prinzipal aus der vertrauenswürdigen Domäne nirgendwo in der vertrauenden Domäne Zugriff, bis ein Administrator auf bestimmten Computerobjekten ausdrücklich die Berechtigung „Allowed to Authenticate“ (Authentifizierung zulassen) erteilt.

Aktivieren:

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth:yes

Gewähren Sie den Zugriff anschließend nur dort, wo er benötigt wird – pro Computerobjekt über die Registerkarte Security → Allowed to Authenticate oder mit dsacls:

dsacls "CN=<TargetComputer>,OU=Servers,DC=trusting,DC=example,DC=com" /G "TRUSTEDDOMAIN\SomeGroup:CA;Allowed to Authenticate"

Damit wird aus einer offenen Vertrauensstellung – bei der sich jeder authentifizierte Benutzer der Partnerdomäne überall anzumelden versuchen kann – eine explizite Positivliste. Es ist die wirkungsvollste Einzelmaßnahme für eine externe oder Gesamtstruktur-Vertrauensstellung und sollte die Standardhaltung für jede Vertrauensstellung zu einem Partner sein, den Sie nicht vollständig kontrollieren.

Missbrauch des SID-Verlaufs: worauf Sie achten sollten

Auch bei aktivierter Quarantäne sollten Sie auf Auffälligkeiten achten, statt die Maßnahme für unfehlbar zu halten:

• Plötzlich auftauchende sIDHistory-Werte auf Konten außerhalb einer bekannten, geplanten Migration.
• Kerberos-Tickets im Stil eines Golden Ticket, die SID-Verlauf für privilegierte Gruppen enthalten – diese erscheinen als auffällige PAC-Inhalte in Erkennungswerkzeugen und als Warnungen in Microsoft Defender for Identity.
• Authentifizierungsereignisse aus einer vertrauenswürdigen Domäne gegen Tier-0-Systeme, die außerhalb der von Ihnen konfigurierten „Allowed to Authenticate“-Berechtigungen liegen.

Unter Auditing, Protokollierung und Erkennung finden Sie die Ereignis-IDs und die SACL-Konfiguration, die dies sichtbar machen.

Wann Sie tatsächlich einen Red Forest oder eine PAM-Vertrauensstellung brauchen

Microsofts ursprüngliches ESAE (Enhanced Security Admin Environment), landläufig „Red Forest“ genannt, verwendete eine dedizierte, gehärtete Verwaltungs-Gesamtstruktur mit einer unidirektionalen PAM-Vertrauensstellung (Privileged Access Management) in die Produktions-Gesamtstruktur, sodass Tier-0-Anmeldeinformationen nie auf Arbeitsstationen der Produktions-Gesamtstruktur gelangten. Microsoft hat ESAE Ende 2020 im Rahmen seiner Strategie für privilegierten Zugriff als Standardempfehlung zurückgezogen – zugunsten des modernen Enterprise Access Model auf Basis von Azure AD / Microsoft Entra ID, Privileged Access Workstations sowie Just-In-Time/Just-Enough-Administration. Der Grund: Eine eigenständige Verwaltungs-Gesamtstruktur ist teuer im Betrieb, wird selbst zum Angriffsziel und adressiert Angriffspfade über Cloud-Identitäten überhaupt nicht.

Eine dedizierte Verwaltungs-Gesamtstruktur oder PAM-Vertrauensstellung sollten Sie dennoch in Betracht ziehen, wenn:

• Ihre Umgebung per Air Gap getrennt ist oder Sie keine Cloud-Identitätssteuerungsebene einführen können (regulatorische, klassifizierte oder OT-Umgebungen).
• Sie eine sehr große Umgebung mit mehreren Gesamtstrukturen betreiben, in der eine wirklich separate administrative Vertrauensgrenze den gesamtstrukturübergreifenden Schadensradius wirksamer verkleinert als Tiering allein.
• Sie während einer langwierigen Migration von AD zu Cloud-Identitäten eine Brücke benötigen und Tier 0 in der Zwischenzeit isolieren wollen.

Für die meisten Umgebungen gilt: Investieren Sie zuerst in das Tiering nach Tier 0 und privilegierter Zugriff, in Privileged Access Workstations und in die in diesem Artikel beschriebene Härtung der Vertrauensstellungen – das schließt die meisten Angriffspfade, auf die ESAE abzielte, zu einem Bruchteil der Betriebskosten.

Was dadurch nicht mehr funktioniert

• Gesamtstruktur- oder domänenübergreifende Zugriffe, die auf einer offenen (nicht selektiven) Vertrauensstellung beruhten. Anwendungen, Dateifreigaben oder Dienstkonten, die sich aus der Partnerdomäne über die Vertrauensstellung authentifizieren, schlagen fehl, bis Sie auf jedem Zielcomputerobjekt ausdrücklich „Allowed to Authenticate“ erteilen. Inventarisieren Sie die vertrauensstellungsübergreifenden Zugriffsmuster (über Anmeldeereignisse 4624/4625, gefiltert nach Quelldomäne), bevor Sie die selektive Authentifizierung in der Produktion aktivieren.
• Migrationen, die auf den SID-Verlauf angewiesen sind, brechen ab, wenn Sie enablesidhistory deaktivieren, während eine Migration noch läuft. Stellen Sie den SID-Verlauf erst unter Quarantäne, wenn die Migrationsarbeiten über diese Vertrauensstellung vollständig abgeschlossen sind.
• Legacy-Vertrauensstellungen zu stillgelegten oder schlecht gepflegten Partnerdomänen müssen womöglich einfach entfernt statt gehärtet werden – netdom trust /remove ist oft die richtige Antwort, sobald Sie bestätigt haben, dass keine aktiven Abhängigkeiten mehr bestehen.

Kombinieren Sie dies mit Härtung der Domänencontroller und Objekt- & ACL-Sicherheit – die Härtung von Vertrauensstellungen begrenzt, was eine kompromittierte Partnerdomäne erreichen kann, ersetzt aber nicht die Härtung der DCs und Objekte auf Ihrer Seite der Vertrauensstellung.