Blog
Active Directory Trust Considerations
Einleitung
Will „harmj0y“ Schroeder veröffentlichte einen hervorragenden technischen Beitrag mit dem Titel „Not A Security Boundary: Breaking Forest Trusts“, in dem er darlegt, wie sich ein AD Forest von außerhalb kompromittieren lässt, was Microsofts bisherige Aussage „der Forest ist eine Sicherheitsgrenze“ sprengt. Dazu werden Standardeinstellungen mit einer neuartigen Angriffsmethode kombiniert.
Dabei ist in seinem Schreiben die Grundlage für den Angriffspfad eine bestehende gegenseitige Vertrauensstellung (two-way trust) zwischen zwei Forests (Gesamtstrukturen). Trusts und ihre Auswirkungen auf die Sicherheit wurden in den letzten Jahren in vielen Diskussionen thematisiert. Sie sind aber gleichzeitig für viele Unternehmensorganisationen aus historischen Gründen und aufgrund von Fusionen und Übernahmen ein aktuelles Thema.
Christoph Kuderna von Skaylink und Enno Rey und weitere Mitarbeiter vom Active-Directory-Sicherheitsteam von ERNW arbeiteten für eine Organisation, in der genau diese Diskussion statt fand. Ein Ergebnis ist ein Dokument, in dem die Risiken von AD-Trusts zusammen mit einigen Lösungsvorschlägen für die Entschärfung diskutiert werden.
Wir haben uns entschieden, einige Teile dieses Dokuments zu extrahieren, um zu einer fundierten Entscheidungsfindung im Zusammenhang mit AD-Trusts beizutragen.
1. Konfigurationen im Active Directory mit Trusts
Dieser Blogbeitrag beleuchtet Sicherheitsaspekte beim Erstellen von Active Directory Trusts Relationships (Vertrauensbeziehungen) zwischen dem Active Directory Forest (Gesamtstruktur) eines Beispiel-Unternehmens und anderen Domänen/Forests.
Der primäre Anwendungsfall besteht darin, dass Benutzer einer externen AD-Domäne auf ihre Exchange-Postfächer zugreifen, die auf Servern in der Unternehmens-Domäne („dir.company.com“) mit Kerberos als Authentifizierungsprotokoll gehostet werden. In der Active Directory-Terminologie ist die Vertrauensrichtung (trust direction) der Zugriffsrichtung (direction of access) entgegengesetzt. (siehe Bild unten)
Dieser Beitrag konzentriert sich auf das Szenario eines „one-way trust“, einer einseitigen Vertrauensstellung, bei der der AD-Forest des Beispiel-Unternehmens dir.company.com (= „company“) den AD-Forests der Partner vertraut, jedoch nicht umgekehrt.
Anmerkung: Windows implementiert einen „two-way trust” als zwei entgegengesetzte „one-way trusts“. Insofern sind die folgenden Betrachtungen auch für „two-way trusts“ relevant.
Das folgende Bild zeigt das typische Szenario, in dem die vertrauende Domäne auf der linken Seite die Unternehmens-AD und auf der rechten Seite die vertrauenswürdige Domäne das Partner-AD sein würde:
Selbst wenn dir.company.com auf diese Weise mehreren anderen AD-Domänen vertraut, erstrecken sich die Vertrauensbeziehungen nicht auf die externen Domänen selbst. Wenn also dir.company.com zwei Domänen A und B vertraut, besteht zwischen der Domäne A und der Domäne B immer noch kein Vertrauensverhältnis.
Anders ausgedrückt: Externe Active-Directory-Trusts und AD-Trusts zwischen Gesamtstrukturen (inter-forest AD) sind standardmäßig nicht transitiv. Dies bedeutet, dass eine Vertrauensstellung zwischen einer Active-Directory-Umgebung eines Partners und der Unternehmens-AD niemals auf eine andere Domäne ausgeweitet wird, selbst wenn sie von dir.company.com oder der Partner AD als vertrauenswürdig eingestuft wird. Die einzige mögliche Ausnahme wären andere Domänen in derselben AD-Gesamtstruktur, wenn die Partner-Gesamtstruktur aus mehreren Domänen besteht und man einen Forest-Trust implementiert – der dann immer zur Root-Domäne gehen muss.
Von Microsoft gibt es hier ein Blog mit allgemeinen Überlegungen zu Vertrauensstellungen: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/top-ten-issues-with-active-directory-trusts-and-corporate/ba-p/258968
2. Allgemeine Richtlinien zu Active Directory Trusts
Um allgemeine Risiken zu vermeiden, die durch Trusts (Vertrauensbeziehungen) entstehen, empfiehlt es sich die folgenden allgemeinen Richtlinien für AD-Trusts in dir.company.com zu definieren:
- Trusts dürfen nur nach Bedarf und nach vorheriger Genehmigung erstellt werden.
- Sie dürfen nur in den erforderlichen Richtungen erstellt werden. Unidirektionale Vertrauensstellungen sollten immer bevorzugt werden, jede Vertrauensrichtung (trust direction) muss gerechtfertigt sein.
- Die SID-Filterung muss aktiviert sein. Das bedeutet, wenn ein Partnerbenutzer über den Trust auf eine Ressource in dir.company.com zugreifen möchte, wird das Zugriffs-Token gefiltert und alle SIDs, die nicht aus der Partnerdomäne stammen, werden entfernt. Dies kann zu Problemen beim Zugriff führen, wenn für den Ressourcenzugriff noch SIDs aus früheren Migrationen erforderlich sind und diese Ressource später in die Domäne dir.company.com migriert wird. Die SID-Filterung deaktiviert die Verwendung von SID-History implizit.
- Die TGT-Delegierung über den Trust muss deaktiviert sein, d.h. unconstrained Kerberos-Delegation ist nicht möglich. Microsoft hat, nachdem entsprechende Angriffsszenarien bekannt wurden, eine entsprechende neue Einstellung für Trusts bereitgestellt und als Standardwert „disabled“ gewählt. Details unter Updates to TGT delegation across incoming trusts in Windows Server (microsoft.com)
- Der Trust sollte für die AES-Verschlüsselung konfiguriert sein.
- Trusts sollten so konfiguriert werden, dass die Kerberos-Authentifizierung funktioniert, vorzugsweise als Forest-Trusts anstelle von externen Trusts.
- Standardmäßig muss die selektive Authentifizierung aktiviert sein. Ausnahmen müssen von Tier-0-Administratoren der Firma ausdrücklich genehmigt werden. Application Owner müssen Tier-0-Administratoren die Liste der Systeme zur Verfügung stellen, für die das Recht DARF AUTHENTIFIZIEREN (ALLOWED TO AUTHENTICATE) konfiguriert sein muss, damit ihr Dienst von Benutzern aus vertrauenswürdigen Domänen verwendet werden kann.
- Da Benutzer von vertrauenswürdigen Domänen AUTHENTICATED USERS/AUTHENTIFIZIERTE BENUTZER in der vertrauenden Domäne sind, unabhängig aus welcher vertrauten Domäne sie stammen, sollten Berechtigungen in der vertrauenden Domäne (dir.company.com) nicht die Gruppe AUTHENTICATED USERS/AUTHENTIFIZIERTE BENUTZER verwenden, um Zugriff zu gewähren.
In praktisch allen von uns untersuchten Domänen ist die Gruppe AUTHENITCATED USERS Mitglied der Gruppe „Pre-Windows 2000 compatible access“, die weitreichende Leserechte in der Domäne erlaubt. Somit können Benutzer aus einer Domäne, der Sie vertrauen, ihr AD genauso auslesen, wie ihre eigenen Benutzer – und auch die sollten eigentlich nicht so viel sehen dürfen.
- Jede Art von administrativem Zugriff auf die Domäne dir.company.com und die darin enthaltenen Ressourcen darf niemals Accounts aus den Partnerdomänen gewährt werden. Administratorkonten müssen sich in dir.company.com befinden. Die Mitgliedschaft in administrativen Gruppen muss überwacht werden, alle nicht genehmigten Mitglieder müssen sofort entfernt werden. Ohne diese Einschränkung könnte eine Kompromittierung in den direkten Partnern die Dienste in dir.company.com beeinträchtigen.
Nochmals zur Klarstellung: dies sind Empfehlungen, für deren Umsetzung es gute Gründe gibt, die aber nicht technisch zwingend sind.
2.1 Überwachung von Trusts
Windows erstellt die erforderlichen Event-Log-Einträge, wenn die Überwachungsrichtlinie für Domänen-Controller (definiert in der Default Domain Controllers Policy) ordnungsgemäß konfiguriert ist.
From Microsoft’s “WINDOWS 10 AND WINDOWS SERVER 2016 SECURITY AUDITING AND MONITORING REFERENCE” document:
“Audit Authentication Policy Change determines whether the operating system generates audit events when changes are made to authentication policy.
Changes made to authentication policy include:
- Creation, modification, and removal of forest and domain trusts.
- Changes to Kerberos policy under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy.
- When any of the following user logon rights is granted to a user or group:
- Access this computer from the network
- Allow logon locally
- Allow logon through Remote Desktop
- Logon as a batch job
- Logon as a service
- Namespace collision, such as when an added trust collides with an existing namespace name.
This setting is useful for tracking changes in domain-level and forest-level trust and privileges that are granted to user accounts or groups.
Event volume: Low.
The following events belong to this category:
- 4670: Permissions on an object were changed
- 4706: A new trust was created to a domain.
- 4707: A trust to a domain was removed.
- 4716: Trusted domain information was modified.
- 4713: Kerberos policy was changed.
- 4717: System security access was granted to an account.
- 4718: System security access was removed from an account.
- 4739: Domain Policy was changed.
- 4864: A namespace collision was detected.
- 4865: A trusted forest information entry was added.
- 4866: A trusted forest information entry was removed.
- 4867: A trusted forest information entry was modified.
Das Dokument von Microsoft enthält darüber hinaus sehr detaillierte Informationen über die Information in den einzelnen Events.
3. Erstellen einer Vertrauensbeziehung (Trust Relationship) in dir.company.com
Eine Vertrauensbeziehung kann nur mit Administratorrechten auf beiden Seiten des Trusts hergestellt werden. Bei der Erstellung des Trusts wird ein Trust-Passwort vereinbart, das regelmäßig (standardmäßig alle 30 Tage) automatisch geändert wird. Das aktuelle Trust-Kennwort muss Domänencontrollern auf beiden Seiten der Vertrauensstellung (Trust) bekannt sein, um die für den Ressourcenzugriff erforderlichen verweisenden Tickets erstellen oder verwenden zu können.
3.1 Trust Erstellung und Prüfung
Die DNS-Namensauflösung in beide Richtungen muss bereits vorhanden sein. Wir empfehlen die Verwendung von bedingten Weiterleitungen (Conditional Forwarders).
Da weder das alte Befehlszeilentool NETDOM noch ein POWERSHELL-Cmdlet zum Erstellen einer Gesamtstrukturvertrauensstellung (forest trust) verwendet werden kann, wird das GUI-Tool AD DOMAINS AND TRUSTS verwendet.
Die folgenden Screenshots zeigen das Setup mit einer Beispiel-Partner-Domäne namens example.dir:
Klicken Sie auf „New Trust“, dann sehen Sie dies:
Geben Sie den Namen der Domäne an, der vertraut werden soll, bitte IMMER den vollständigen DNS-Namen verwenden:
Ändern Sie die Einstellung auf FOREST TRUST:
Benutzer von example.dir müssen in der Lage sein, auf Ressourcen in dir.company.com zuzugreifen und benötigen daher eine einseitige ausgehende Vertrauensstellung (outgoing trust):
Zur Vereinfachung nehmen wir an, dass Administrator Credentials aus beiden Domänen verfügbar sind. Ist dies nicht der Fall, kann das Setup auf beiden Seiten separat abgeschlossen werden, wenn ein erforderliches initiales Trust Passwort sicher zwischen den Administratoren ausgetauscht wird.
Die Authentifizierung muss in „selective authentication“ geändert werden:
In der Partner-Domäne sollten dann die Trust-Eigenschaften geöffnet und das Kontrollkästchen „“The other domain supports Kerberos AES Encryption” aktiviert werden. Dies erfordert Windows Server 2008 R2 (oder höher) als Betriebssystem der Domänencontroller und ein Domain Functional Level von mindestens Windows Server 2008 R2.
Überprüfung der Konfiguration in dir.company.com:
Hinweis: SIDFilteringForestAware muss auf FALSE gesetzt sein (= SIDFiltering ist aktiv).
SIDFilteringQuarantined gilt nur für externe Trusts, wir verwenden jedoch Forest Trusts.
Der gleiche Trust aus Sicht der Partnerdomäne:
Klicken Sie auf „New Trust“, dann sehen Sie dies:
Hinweis: „UsesAESKeys“ gilt nur für Kerberos-Realm-Trusts. „SelectiveAuthentication“ wird auf „false“ festgelegt, da der Trust nicht ausgehend ist.
3.2 Potenzielle Risiken und Entschärfungen
Ohne eine detaillierte Evaluation und permanente Überwachung des Integritätszustands (health state) eines Partnerverzeichnisses müssen die Administratoren von dir.company.com die Kompromittierung dieses Partnerverzeichnisses annehmen und die damit verbundenen potenziellen Risiken berücksichtigen. In den folgenden Absätzen werden relevante Risiken aufgeführt und wie diese durch die in 2. in „Allgemeine Richtlinien zu Active Directory Trusts“ beschriebenen AD Trust gemildert werden.
3.2.1 Modifikation der Trust-Einstellungen
Ein bösartiger Angreifer könnte in einem Partner-Directory versuchen, die Trust Settings zu ändern oder Trusts zu anderen Domänen zu erstellen. Da Trusts nicht einseitig erstellt werden können, ist dies kein Problem, wenn ein Angreifer nicht beide Seiten kompromittiert hat. Das Abschwächen der Sicherheitseinstellungen des einseitigen (one-way) Trust, bei dem das Beispiel-Unternehmen COMPANY dem Partner vertraut, kann nur von der COMPANY-Seite aus vorgenommen werden.
Lesen Sie hierzu auch 2.1 Monitoring von Trusts
3.2.2 Erstellen von gefälschten Anmeldeinformationen (Fake Credentials)
Ein Angreifer mit Administratorrechten in einem Kontoverzeichnis (Partner Directory) kann das SIDHistory-Attribut von Gruppen, Computern und Benutzerkonten so ändern, dass zusätzliche SIDs hinzugefügt werden, die möglicherweise den Zugriff auf Ressourcen ermöglichen, auf die sie keinen Zugriff haben sollen (z. B. Postfächer von verschiedenen Benutzer). Dieses Szenario ist besonders gefährlich, wenn die hinzugefügten SIDs zu anderen Forests gehören (andere Partner oder COMPANY selbst).
Um dieses Risiko auszuschließen, werden die Vertrauensstellungen mit aktivierter SID-Filterung konfiguriert. Das bedeutet, dass alle SIDs, die nicht zum Partnerverzeichnis gehören, bei der Verwendung der Vertrauensstellung automatisch entfernt werden. Eine ausführliche technische Beschreibung von SIDFiltering finden Sie unter https://msdn.microsoft.com/de-de/library/cc237940.aspx.
In einem ähnlichen Szenario könnte der böswillige Akteur SIDs aus seinem eigenen AD-Forest hinzufügen und somit die Identität anderer Benutzer annehmen und auf deren Ressourcen in den Shared Services zugreifen. Dies kann nicht verhindert werden, könnte aber überwacht werden. Um dieses Szenario zu implementieren, benötigt der Angreifer Administratorzugriff auf einen Domänen-Controller. In diesem Fall könnte er jedoch Konten im Verzeichnis bereits direkt ändern und Benutzerkennwörter usw. zurücksetzen. Es besteht dadurch zwar kein direktes Risiko für die Domäne dir.company.com oder deren Ressourcen, solange Benutzern aus dem Partnerverzeichnis keine Administratorrechte in dir.company.com erteilt werden. Aber natürlich ist es im Sinne der Vertraulichkeit und Datenintegrität nicht günstig, wenn auf Daten anderer Benutzer zugegriffen werden kann, auch wenn diese „nur“ aus der bereits kompromittierten Kontendomäne stammen, nicht jedoch aus anderen.
3.2.3 Manipulation von Verzeichnisdaten
Ein Angreifer könnte Daten im Partnerverzeichnis manipulieren oder zerstören. Dies kann zu Denial-of-Service-Problemen für diese Umgebung führen. Wenn eine Synchronisierung zwischen dem Partnerverzeichnis und der Unternehmensdomäne implementiert ist, muss das Synchronisationsmodul Mechanismen zur Behandlung dieser Szenarien implementieren. Andernfalls ist dies hauptsächlich für den Partner ein Problem, nicht für dir.company.com.
3.2.4 Auflistung der COMPANY-Domäne
Die Verwendung des Trusts erfordert das Recht, auf die Domänen-Controller in dir.company.com zuzugreifen. Sofern der Benutzer authentifiziert und vertrauenswürdig ist, können die meisten Inhalte der Unternehmensumgebung aufgelistet werden.
Wenn das Unternehmen diese Auflistung als ernstes Problem ansieht, können zusätzliche Maßnahmen in Betracht gezogen werden, bis zur Aktivierung des LIST OBJECT Modus im Active Directory. Die möglichen negativen Auswirkungen auf den täglichen Betrieb – im Vergleich zu einem durch die Auflistung verursachten geringen Risiko – sollten berücksichtigt werden.
3.2.5 Auflistung anderer vertrauenswürdiger Domänen
Mehrere Trusts zwischen dir.company.com und verschiedenen Partnern gewähren Benutzern aus einer Partnerdomäne aufgrund des Trusts noch kein Recht, die Domäne eines anderen Partners aufzulisten, zum einen wegen der Richtung der Vertrauensstellung (Trust Direction) und aufgrund der Tatsache, dass sie nicht transitiv sind.
Das Erstellen von Vertrauensstellungen erfordert eine funktionierende DNS-Namensauflösung in beide Richtungen. Auf diese Weise könnte jemand von einem Partner-AD die DNS-Zonen anderer Partner abfragen und Informationen über Computer in diesen Domänen sammeln.
Wenn das Unternehmen dies als problematisch ansieht, können zusätzliche Maßnahmen zur Minderung dieses Risikos implementiert werden. Wir haben erfolgreich getestet, dass die READ-Berechtigungen der Gruppe EVERYONE für die bedingten DNS-Weiterleitungen in dir.company.com durch spezifischere Gruppen ersetzt werden können.
3.2.6 Eskalation von Privilegien in der Domäne dir.company.com
Die Verwendung von SID-Filterung verhindert häufige Angriffe, z. B. Verwenden von Mimikatz zum Hinzufügen von SIDs von dir.company.com-Konten zu Anmelde-Token, die aus dem Partnerverzeichnis stammen. Eine Privilegien-Eskalation würde dann Fehlkonfigurationen oder fehlende Sicherheitspatches usw. auf Servern von dir.company.com erforderlich machen, Probleme, die nicht direkt mit Trusts zusammenhängen.
3.2.7 Zugriff auf andere Ressourcen in dir.company.com
Benutzer aus vertrauten Domänen sind automatisch Mitglieder der Gruppe AUTHENTICATED USERS in einer Domäne, wodurch sie möglicherweise Zugriff auf Ressourcen erhalten, für die diese Gruppe standardmäßig Berechtigungen hat.
Um dieses Problem zu beheben, implementieren wir SELECTIVE AUTHENTICATION (auch als „Authentifizierungs-Firewall“ bezeichnet), bei der Benutzern aus vertrauenswürdigen Domänen explizit das Recht DARF AUTHENTIFIZIEREN/ALLOWED TO AUTHENITCATE für jede Ressource in der vertrauenden Domäne zugewiesen werden muss. Diese Einstellung ist für die Computerobjekte in der vertrauenden Domäne zu konfigurieren und wird daher von Administratoren von dir.company.com gesteuert.
Außerdem wurde empfohlen, die Gruppe AUTHENTICATED USERS für Objekte und Ressourcen in der vertrauenden Domäne erforderlichenfalls durch spezifischere Gruppen zu ersetzen.
3.2.8 Angriffe auf Accounts
3.2.8.1 Kerberoasting
Benutzer einer Partnerdomäne können Kerberos Service Tickets für jedes Konto bei dir.company.com anfordern, dem ein Service Prinicipal Name zugeordnet ist. Diese Servicetickets können dann für einen Offline-Angriff zum Knacken von Passwörtern verwendet werden, da sie in Teilen mit dem Passwort des Zieldienstkontos verschlüsselt werden. Wenn es einem Benutzer gelingt, viele Service Tickets für ein Konto anzufordern, kann die Zeit zum Knacken des Kennworts erheblich reduziert werden¹.
Die üblichen Abhilfemaßnahmen sollten vorhanden sein:
- Service Account Passwörter sollten mindestens 32 Zeichen lang sein und dürfen nicht leicht zu erraten sein
- Managed oder Group Managed Service Accounts sollten, wann immer es möglich ist, verwendet werden
- Alle Admin- oder Service Accounts sollten auf Änderungen an ihrem Service Principal Name Attributen hin überwacht werden. Konten mit administrativen Rechten sollten generell keinen Service Principal Namen haben.
- Die Event-ID 4769 auf Domänen-Controllern sollte überwacht werden, insbesondere mit dem Verschlüsselungstyp (Encryption Type) 0x17 (siehe Detecting Kerberoasting Activity – Active Directory Security).
- Es sollte getestet werden, ob ein Servicekonto funktioniert, wenn auf dem Konto die Einstellung „This account supports Kerberos AES 256 bit encryption“ aktiviert wird
¹ siehe Cracking Kerberos TGS Tickets
3.2.8.2 Kontensperrungen (Account Lockout)
Benutzer können die für den Ressourcenzugriff erforderliche Netzwerkverbindung verwenden und versuchen, Benutzerkonten anderer Benutzer zu sperren. Es sind drei Szenarien zu berücksichtigen:
- Sperren von Konten anderer Benutzer aus derselben Partnerdomäne
Dieses Szenario ist bereits intern in jedem AD des Partners mit dem Trust vorhanden. - Sperren der zum Unternehmen COMPANY gehörenden Konten
Dies erfordert Kenntnisse über Kontonamen, wäre jedoch möglich, wenn die Kontosperrung für COMPANY-Konten konfiguriert ist. Microsoft empfiehlt nicht das Sperren des Accounts, stattdessen sollten fehlgeschlagene Anmeldungen überwacht werden. - Sperren von Konten von anderen vertrauenswürdigen Partnerdomänen
Dies erfordert ebenfalls Kenntnisse über Account-Namen. Um dieses Risiko-Szenario zu verringern, sollte die Kontosperrung in den Partnerverzeichnissen entsprechend konfiguriert werden.