Sicheres Active-Directory-Design (1)
Abhärten!
Veröffentlicht in Ausgabe 09/2024 - PRAXIS
Es wäre eine maßlose Untertreibung, zu sagen, dass das Active Directory (AD) bei IT-Sicherheitsspezialisten keinen guten Ruf genießt. Ein in der Szene angesehener Incident-Response-Experte schrieb auf LinkedIn, AD sei "ein Krebsgeschwür, das lieber gestern als heute wegoperiert gehört". Natürlich spielt bei solchen Aussagen der "Survivorship Bias" eine Rolle - die Infrastrukturen, bei denen solche hochkarätigen Spezialisten die Kastanien aus dem Feuer holen dürfen, sind genau solche, in denen zwischen der Attraktivität für Angreifer und dem Maß an Härtung die größte Diskrepanz besteht. Der Begriff "Härtung" bezieht sich dabei sowohl auf IT-Infrastrukturen selbst als auch auf Menschen und Prozesse, die in deren Verwaltung eingebunden sind.
Näher an der Praxis ist da der deutsche IT-Berater Holger Voges, der zwar seinen Golem-Kommentar [1] mit "Windows-Netzwerke sind inhärent unsicher" eröffnet, dann aber konkrete Hinweise auf Sicherheitslücken und Maßnahmen zu deren Bekämpfung gibt. Viele dieser Maßnahmen sind Klassiker, die auch in diesem Artikel Erwähnung finden. In Wirklichkeit lässt sich ein Active Directory durchaus recht sicher betreiben, wenn die Organisation bereit ist, zumindest die ganz alten Zöpfe abzuschneiden und statt nur in Third-Party-Tools auch in sicheres, modernes Design zu investieren. Das klingt zwar nicht so sexy im Geschäftsbericht wie das neuste XDR, MDR oder ITDR, bringt jedoch im Zweifel mehr.
AD ist nicht gleich AD
Gleich vorab: Wenn vom "unsicheren AD" die Rede ist, sind in der Regel die "Active Directory Domain Services" (ADDS) gemeint, also ein mit Kerberos-Authentifizierung und Gruppenrichtlinien verheirateter Verzeichnisdienst. Manchmal geben die "Active Directory Certificate Services" (ADCS), die Microsoft-Umsetzung einer Public Key Infrastructure (PKI), der Sicherheit der Umgebung noch den finalen Todesstoß.
Es wäre eine maßlose Untertreibung, zu sagen, dass das Active Directory (AD) bei IT-Sicherheitsspezialisten keinen guten Ruf genießt. Ein in der Szene angesehener Incident-Response-Experte schrieb auf LinkedIn, AD sei "ein Krebsgeschwür, das lieber gestern als heute wegoperiert gehört". Natürlich spielt bei solchen Aussagen der "Survivorship Bias" eine Rolle - die Infrastrukturen, bei denen solche hochkarätigen Spezialisten die Kastanien aus dem Feuer holen dürfen, sind genau solche, in denen zwischen der Attraktivität für Angreifer und dem Maß an Härtung die größte Diskrepanz besteht. Der Begriff "Härtung" bezieht sich dabei sowohl auf IT-Infrastrukturen selbst als auch auf Menschen und Prozesse, die in deren Verwaltung eingebunden sind.
Näher an der Praxis ist da der deutsche IT-Berater Holger Voges, der zwar seinen Golem-Kommentar [1] mit "Windows-Netzwerke sind inhärent unsicher" eröffnet, dann aber konkrete Hinweise auf Sicherheitslücken und Maßnahmen zu deren Bekämpfung gibt. Viele dieser Maßnahmen sind Klassiker, die auch in diesem Artikel Erwähnung finden. In Wirklichkeit lässt sich ein Active Directory durchaus recht sicher betreiben, wenn die Organisation bereit ist, zumindest die ganz alten Zöpfe abzuschneiden und statt nur in Third-Party-Tools auch in sicheres, modernes Design zu investieren. Das klingt zwar nicht so sexy im Geschäftsbericht wie das neuste XDR, MDR oder ITDR, bringt jedoch im Zweifel mehr.
AD ist nicht gleich AD
Gleich vorab: Wenn vom "unsicheren AD" die Rede ist, sind in der Regel die "Active Directory Domain Services" (ADDS) gemeint, also ein mit Kerberos-Authentifizierung und Gruppenrichtlinien verheirateter Verzeichnisdienst. Manchmal geben die "Active Directory Certificate Services" (ADCS), die Microsoft-Umsetzung einer Public Key Infrastructure (PKI), der Sicherheit der Umgebung noch den finalen Todesstoß.
Es gibt allerdings in der Windows-Server-Familie noch drei weitere ADs. Als Erstes ist der Active Directory Rights Management Service (ADRMS) zu nennen. Dies ist ein auf Kryptografie basierter Schutz digitaler Inhalte wie Dokumente, E-Mails und andere. Der Dienst kommt nur sehr selten in lokalen Umgebungen zum Einsatz, bildet jedoch die technologische Grundlage für "Azure Information Protection", die sich zu "Microsoft Information Protection" und schließlich zu "Microsoft Purview Information Protection" [2] weiterentwickelt hat.
Auf die Sicherheit der Infrastruktur hat ADRMS in der Regel keinen Einfluss, abgesehen von ausgeklügelten Szenarien, wo eine entwendete E-Mail dem Spearphishing dient, um an privilegierte Credentials heranzukommen.
Als Zweites müssen wir die Active Directory Lightweight Directory Services (ADLDS) betrachten. Ehemals als "Active Directory Application Mode" (ADAM) bekannt, ist dies ein LDAP-konformer Verzeichnisdienst, der auf die Multimaster-Replikationsmechanismen von ADDS aufbaut, jedoch keine Computermitgliedschaften, Kerberos und Gruppenrichtlinien bietet. Dafür ist das Schema frei konfigurierbar und findet in Szenarien Verwendung, für die ADDS vollkommen ungeeignet ist. Ferner kann der Dienst auf beliebigen Ports hören und es lassen sich mehrere Instanzen von LDS auf dem gleichen Windows-Server nebeneinander ausführen. Diese Serverrolle kann durchaus die Sicherheit einer ADDS-Organisation erhöhen, indem IT-Verantwortliche beispielsweise für DMZ und andere potenziell unsichere Szenarien ein "Metaverzeichnis" damit erzeugen und keine direkten AD-Abfragen aus unsicheren Zonen mehr zulassen.
Schließlich sind die Active Directory Federation Services (ADFS) ein SAML- und openID-Connect-konformer Identity Provider (IdP) für Verbundauthentifizierung. In Verbindung mit Anwendungen, die SAML-Authentifizierung unterstützen (das sind in erster Linie Applikationen mit einem Web-Frontend) kann eine gut konfigurierte ADFS-Farm die Sicherheit des dahinterliegenden AD erheblich verbessern. Eine schlecht konfigurierte ADFS-Farm hingegen eröffnet ganz neue Angriffsvektoren und macht die Absicherung der gesamten Umgebung umso schwieriger. Besonders prekär wird die Situation, wenn ADFS nicht nur im Unternehmens-LAN eingesetzt wird, sondern für externe Anwendungen, beispielsweise in Verbindung mit Entra ID.
IT-Administrator Sonderheft "Active Directory"
Im zweiten IT-Administrator Sonderheft des Jahres 2024 "Active Directory - Administration, Security und Troubleshooting" widmet sich unser Autorenteam zentralen Aufgaben beim Verwalten von Microsofts Verzeichnisdienst. Auf 180 Seiten zeigt das Sonderheft Best Practices im lokalen als auch im hybriden Betrieb des Active Directory auf und deckt dabei praxisnah Aspekte wie Betriebsmasterrollen und Globalen Katalog, AD-Migration und -Upgrades, Replikation und Standortkonzepte wie auch Zertifikatsdienste samt PKI ab.Als zentraler Infrastrukturdienst bringt das AD daneben hohe Anforderungen an die Sicherheit mit, um die sich das Sonderheft mit Themen wie dem sicheren AD-Design, dem Einsatz von Jump-Servern und Privileged-Acccess-Workstations zur Administration, dem AD-Auditing und -Monitoring, dem Einsatz von Smardcards zur Authentifizierung und vielem mehr kümmert. Und wenn die Technik einmal nicht so will wie der Admin, hilft die Troubleshooting-Rubrik bei Aspekten wie dem Beheben von Kerberos-Problemen, der Fehlersuche in den AD-Zertifikatsdiensten, der Reparatur der AD-Datenbank und dem Zurückspielen von alten AD-Ständen. Abgerundet wird das neue Sonderheft durch Workshops zu ausgewählten hilfreichen Drittanbietertools, die die Security weiter optimieren oder neue Funktionen für die AD-Administration bereitstellen.Das Sonderheft ist ab Oktober 2024 verfügbar und kostet für Abonnenten des IT-Administrator lediglich 24,90 Euro, Nicht-Abonnenten zahlen 29,90 Euro.
Bekannte Sicherheitsprobleme des Active Directory
Der schlechte Ruf des Active Directory ist weder einem bestimmten Umstand noch einem bestimmten Akteur zuzuschreiben. Vielmehr ist es eine "Mannschaftsleistung": Microsoft machte hier den Anfang durch Design-Entscheidungen, die dauerhaft eine bestimmte Entwicklungsrichtung vorgaben. Vor allem aber sind Default-Einstellungen zu nennen, die bereits zur Zeit ihrer Entstehung nicht zeitgemäß waren, jedoch der damaligen Philosophie des Herstellers Rechnung tragen mussten, wonach Abwärtskompatibilität und Benutzerkomfort Vorrang vor allen anderen Leistungsmerkmalen hatten - insbesondere vor Sicherheit.
Auf Grundlage der Microsoft-Technologie zementierten dann Architekten, Berater und Buchautoren gewisse "Design Patterns" für Jahrzehnte als Best Practices, obwohl die Welt sich weiterdrehte und Windows, AD und die Infrastruktur darunter sich entwickelten und die Sicherheitsaspekte an Bedeutung gewannen. Und - last but not least - tragen täglich die Betreiber von AD-Infrastrukturen das Ihre zum unsicheren und unzuverlässigen Betrieb bei - durch "Abkürzungen", Bequemlichkeitspraktiken, veraltete Tools oder schlechte Scripting-Gewohnheiten.
An den Eigenarten der Technologie selbst können wir nichts ändern, müssen uns ihrer jedoch bewusst sein, da sie das unverrückbare Grundgerüst des AD-Designs und -Betriebs darstellen. Die aus Sicherheitssicht wichtigsten Design-Entscheidungen sind:
- die Vergabe von Schreib- und Administrationsrechten im AD an Prinzipale aus dem AD selbst. Das ist die technologische Grundlage aller Privilege-Escalation-Angriffe bis hin zur Übernahme des gesamten AD-Forests.
- die schwierige Rolle eines Domaincontrollers (DC): Er hat zwar eine eigene Maschinenidentität, aber keine eigene Sicherheitsdatenbank. Er kann zwar replizieren, das können aber andere auch - Berechtigungen vorausgesetzt. Der DC besitzt zwar eine eigene Kopie der AD-Domäne, kann aber nur richtig funktionieren, wenn er weiß, dass diese Kopie aktuell ist und mit denen der anderen DCs in der Domäne übereinstimmt. Diese komplexe Gemengelage eröffnet Hunderte von Angriffsvektoren, von Denial-of Service bis hin zur Übernahme des gesamten Forests oder sogar benachbarter Forests.
- Selbstregistrierung im AD-integrierten DNS, die an keine Konsistenzprüfung geknüpft wird und Namespoofing aller Art erlaubt, was für Man-in-the-Middle (MitM) unerlässlich ist.
- Identische Kryptografie für NTLM und Kerberos RC4: Der Grund dafür liegt in der Migration von NT-Domänen zum AD, deren negativen Auswirkungen, wie die Overpass-the-Hash-Technik, gravierend sind.
Auf der Architekturseite gibt es einige Klassiker, die uns in der Praxis immer wieder begegnen. Viele dieser "Design Antipatterns" sind der missverstandenen Rolle von Domänen, Forests und Vertrauensstellungen geschuldet. Dazu zählt der Missbrauch von Domänen innerhalb eines Forests, um regionalen Admin-Teams oder einzelnen Unternehmensteilen die Verwaltungshoheit über ihren Teil des AD zu ermöglichen. Tatsächlich ist jedoch jeder Domain-Admin nur einen Handlungsschritt davon entfernt, Enterprise- oder Domain-Admin in einer anderen Domäne desselben Forests zu werden. Die Segmentierung der Verwaltungsaufgaben ist ausschließlich über die Rechtevergabe möglich, und da ist der Aufwand der Implementierung in einer separaten Domäne identisch mit dem einer separaten OU. Der einzige Teil, wo es etwas aufwendiger wird, sind Gruppenrichtlinien, aber auch das ist lösbar.
Klassiker Nummer zwei ist der Missbrauch von Domänen, um einzelnen Unternehmenseinheiten die Anmeldung an "ihrer Firma" zu ermöglichen. Eine vernünftige Namenskonvention für E-Mail-Adressen, das Angleichen des User Principal Name (UPN) an diese und "Face- book-Anmeldung" lösen dieses politisch-optische Problem viel besser und nachhaltiger, ohne eine weitgefächerte Domänenstruktur pflegen zu müssen. Noch komfortabler und sicherer sind freilich passwortlose Anmeldeverfahren wie Smartcards, Sicherheitstoken oder Windows Hello for Business. Die problematische Konstellation, die dabei entsteht, ist ein AD-Forest mit mehreren oder mitunter sogar vielen Domänen. Wir gehen gleich noch näher darauf ein.
Die Menge an Worst Practices, die in der täglichen Administration und fortlaufender Pflege zahlreicher AD-Umgebungen fest verankert sind, sprengt den Rahmen dieses Artikels bei Weitem: Jahrelang ungepatchte Systeme, unsichere PKI-Konfigurationen, Enterprise-Admin-Accounts für die Desktop-Administration und Dienste wie SQL oder SharePoint - die Liste lässt sich beliebig fortsetzen. Oft scheitern Versuche, die tägliche Administration in sicherere Bahnen zu lenkenn an "das geht bei uns nicht", "wir haben es schon immer so gemacht", "oben sticht unten" und "wir sind zu klein und unbedeutend, um gehackt zu werden". Nicht umsonst lautet das zweite Gesetz der "10 immutable laws of security administration" [3] aus dem Jahr 2000 "Security only works if the secure way also happens to be the easy way."
Drei AD-Funktionen und ihre Angriffsvektoren
Wie gelingt es den Cyberkriminellen, häufig mit Leichtigkeit, den zentralen Identitätsdienst einer Organisation unter ihre Kontrolle zu bringen? Natürlich gibt es Sicherheitslücken in Windows, keine Software ist davor gefeit. Doch meistens müssen Angreifer so große Geschütze gar nicht erst auffahren. Sie verwenden die eigentliche Funktionalität des AD, um ihre Ziele zu erreichen. Um sich optimal vor solchen Angriffstechniken zu schützen, müssen Administratoren sich darüber im Klaren sein, welchen Nutzen das AD ihrer Organisation bringen soll. Zum Glück ist das einfach zu beantworten, denn AD hat nur drei grundlegende Funktionen:
- Lookup: Informationen aus dem Verzeichnis über ein definiertes Protokoll zur Verfügung stellen, hierzu gehören auch DNS-Informationen.
- Authentifizierung: Wahlweise mit Kerberos oder NTLM.
- Bereitstellung der Konfiguration der angeschlossenen Geräte: Gruppenrichtlinien oder spezifisches Verhalten anhand von Informationen aus dem Verzeichnis wie beispielsweise Home-Lauf- werke oder LAPS.
Aus diesen drei AD-Funktionen leiten Angreifer Techniken ab, die in den folgenden wichtigen taktischen Feldern nach MITRE ATT&CK [4] Anwendung finden: Reconnaissance und Discovery (Lookup), Execution (Konfiguration), Persistence, Privilege Escalation und Lateral Movement (Konfiguration, Authentifizierung), Defense Evasion (Konfiguration, Authentifizierung) und Credential Access (Authentifizierung). Es ist sehr selten, dass AD den initialen Zugriffsvektor ("Initial Access") darstellt, für Datenklau ("Exfiltration") genutzt wird, und fast nie ist die Übernahme des AD das endgültige Ziel des Angreifers ("Impact"). Auf dem Weg dahin leistet ein ungehärtetes und schlecht administriertes AD allerdings wertvolle Dienste.
Nicht zum AD-Funktionsumfang gehören hingegen Identity Management (die einzige halbwegs verlässliche Lifecycle-Information über ein AD-Objekt ist das Erstellungsdatum), Accessmanagement (AD liefert mit Gruppen und wahlweise Claims die technologische Grundlage für die Autorisierung, jedoch keine wirklichen Verwaltungsfunktionen für diese) und das Configuration-Management (hier fehlen nicht nur Managementfunktionen, sondern auch die Möglichkeit, den aktuellen Stand der Umge- bung mit dem gewünschten zu vergleichen). Dies sind sehr häufig missverstandene Punkte und für diese Funktionen existieren Produkte, die auf das Active Directory als Datenspeicher und Auslieferungsmechanismus zurückgreifen. Das Active Directory selbst ist jedoch kein derartiges Managementsystem und war nie als ein solches vorgesehen.
Prinzipien des modernen AD-Designs
Um ein der heutigen Zeit entsprechendes AD-Design zu erstellen und umzusetzen, müssen Sie sich aktueller Anforderungen bewusst werden. Es ist auch sehr wichtig zu verstehen, wie sich diese seitens der Organisationen und der Endbenutzer in den vergangenen zwanzig Jahren geändert haben. In den späten Neunzigerjahren, als Microsoft das Active Directory konzipierte, waren alle Büroarbeitsstationen fest verdrahtet und häufig auch mit festen IP-Adressen versehen - selbst in größeren Organisationen. Standorte eines Unternehmens waren meist durch Leitungen miteinander verbunden, die hohe Latenzen und geringe Bandbreiten aufwiesen. Der vollständige Ausfall einer Standortverbindung für mehrere Tage war ein Ereignis, womit nicht nur theoretisch, sondern auch praktisch zu rechnen war. Gleichzeitig waren alle maßgeblichen Unternehmensanwendungen auf zentrale Dienste wie eben den AD und auf gute Konnektivität zum jeweiligen Backend angewiesen.
Heute müssen Betreiber von zentralen Diensten in Unternehmen andere Anforderungen erfüllen. Durch die Verlagerung vieler Unternehmensanwendungen in die öffentliche Cloud spielt die Standortautonomie der internen Systeme bei Ausfall einer Standortverbindung oft eine geringere Rolle. In vielen IT-Organisationen ist das herkömmliche AD zwar nach wie vor der führende Identitätsspeicher, die meisten Anmeldevorgänge finden jedoch gegen Cloudverzeichnisse wie Entra ID statt, die mit dem AD synchronisiert sind. Gleichzeitig sind die Arbeitsgeräte der Nutzer mobiler geworden. Selbst innerhalb der Unternehmensstandorte ist es Gang und Gäbe, das Laptop zu Besprechungen in Büros anderer Teams und in Konferenzräume mitzunehmen. Dauerhaftes Arbeiten ohne eine Verbindung zu den Kernsystemen wie dem Active Directory musste spätestens während der Covid-19-Pandemie in den meisten Organisationen etabliert werden.
Ein weiterer Faktor, der heute eine viel größere Rolle spielt als noch vor zwanzig Jahren, sind Firmenübernahmen (Mergers & Acquisitions) beziehungsweise Firmenspaltungen (Divestiture). Zwar wurden auch im letzten Jahrhundert Firmen durch andere Unternehmen übernommen, Behörden zusammengelegt oder Fachbereiche herausgetrennt, doch war es damals nicht annähernd so wichtig, IT-Systeme der zusammenfließenden Organisationen schnellstmöglich zu harmonisieren und letztendlich miteinander zu verschmelzen. Die Identität und damit verbundene Dienste wie Messaging und Groupware sowie die Autorisierung in diesen und weiteren Anwendungen stehen dabei erfahrungsgemäß an erster Stelle.
Doch auch die Bedrohungslage, der sich zentrale IT-Dienste ausgesetzt sehen, hat sich grundlegend gewandelt. Es gab zwar früher bereits Firewalls, Virenscanner und Verschlüsselung, auf der Liste der konkreten Gefahren für eine AD-Infrastruktur im Jahr 2000 standen Brand und Überschwemmung an erster Stelle, gefolgt vom Ausfall von Festplatten und menschlichem Versagen. Zugang eines Büro- oder Produktionsstandorts zum Internet und ein E-Mail-Postfach für jeden Mitarbeiter waren nicht überall selbstverständlich. Wenn professionelle Hacker in ein System einbrachen, hatten sie meist den konkreten Auftrag, Informationen zu stehlen. Inzwischen sind Internet, Mail und Instant Messaging allgegenwärtig, und die Kriminellen haben herausgefunden, dass sie das Geld viel leichter vom Angegriffenen selbst bekommen, wenn sie seinen Datenbestand wahllos komplett verschlüsseln.
Viele der neuen Anforderungen betreffen zunächst das Clientmanagement und berühren AD nur insofern, als dass Einstellungen in Gruppenrichtlinien und Konfigurationseinstellungen im AD mit dem Mobile Device Management wie Intune abzugleichen sind. Doch bieten die heute übliche bessere Konnektivität zwischen den Standorten und die Verlagerung einiger Anwendungen in die Cloud eine Chance, das Design der Active-Directory-Forests radikal zu verschlanken und damit indirekt auch sicherer zu machen.
Der Zusammenhang zwischen Topologie und Sicherheit
Das achte Gesetz der bereits zitierten "Immutable Laws of Security Administration" besagt, dass das Netzwerk umso schwerer zu verteidigen ist, je komplexer es ausgelegt ist. In Bezug auf das Active Directory ist die Domänen-Topologie innerhalb eines Forests ein Paradebeispiel für diese Feststellung. Nicht nur erzeugt jede zusätzliche Domäne potenzielle Enterprise-Admins, die Sicherheitsverantwortliche im Blick behalten und irgendwie in ihrer Reichweite beschränken müssen, ein Multi-Domänen-Forest ist auch in jeder anderen Hinsicht schwerer zu verwalten.
Die Nachteile dieser Topologie-Entscheidung treten in besonderem Maße zutage, wenn der Forest komplett zerstört wird (etwa durch Ransomware oder Wiper) und möglichst schnell wiederhergestellt werden muss. Ein Single-Domain-Forest verfügt bereits mit dem ersten aus dem Backup wiederhergestellten DC über den gesamten Datenbestand und es ist lediglich eine Metadaten-Bereinigung notwendig, um die funktionale Gesundheit des Forests wiederherzustellen. Der globale Katalog ist streng genommen nicht erforderlich, denn er bringt keine neuen Erkenntnisse gegenüber direkten LDAP-Abfragen. Bei einem Forest mit mehreren Domänen hingegen muss der Admin im Zweifel jede Domäne wiederherstellen, bereinigen und erneut mit dem Rest des Forests verknüpfen. Das offizielle Forest-Recovery-Handbuch [5] ist inzwischen auf 54 Seiten angewachsen. Dieses Dokument sollten Sie Ihrer Notfallmappe hinzufügen und müssen es, je nach Komplexität des ursprünglichen Forests, im Ernstfall komplett durcharbeiten.
Besonders widersinnig erscheint im Hinblick auf eine Notfall-Wiederherstellung die früher sehr verbreitete Topologie mit einer leeren Forest-Root-Domäne und produktiven Objekten ausschließlich in weiteren Domänen. Hier hängt die Wiederherstellung des gesamten Forests vom Erfolg der Wiederherstellung der Root-Domäne ab, ohne dass sie inhaltlich etwas zum Betrieb beiträgt.
Prüfen Sie, ob ein Design, das ausschließlich Single-Domain-Forests beinhaltet, möglich ist. Die Aufteilung nach Forests sollte in erster Linie erfolgen, weil besonders sichere (Red Forest, Dokumentenmanagement-System für Geheimsachen, Forschung und Entwicklung) oder besonders unsichere (Exchange) Anwendungen in einen eigenen Forest ausge-lagert werden sollen. Auch kommt dieses Vorgehen in Betracht, falls Geschäftsbereiche für ein Buy-out vorgesehen sind oder Teile der Infrastruktur sich an Orten mit extrem schlechter Konnektivität befinden, sodass Replikation und Erreichbarkeit der FSMO-Rollen ein Problem darstellen.
Gang in den roten Wald
Einen Red Forest sollten Sie zur Absicherung Ihrer administrativen Credentials auf jeden Fall in Betracht ziehen. Die oft zitierte Aussage, Microsoft würde das ESAE-Model (bekannt auch als Red Forest), administratives Tiering und alle anderen Komponenten bereits als veraltet einstufen und nicht mehr empfehlen, ist nicht ganz korrekt. Es ist lediglich nicht mehr die Sicherheitsarchitektur, die Microsoft "unbesehen" als Standard empfehlen wird.
Interessant in diesem Zusammenhang ist auch der Kasten auf der Titelseite von ESAE [6]: Microsoft empfiehlt zwar kein isoliertes gehärtetes Gesamtstrukturmodell für die meisten Szenarien in Organisationen, arbeitet jedoch intern mit einer ähnlichen Architektur (mit den zugehörigen Supportprozessen und Mitarbeitern) aufgrund der extremen Sicherheitsanforderungen für die Bereitstellung vertrauenswürdiger Clouddienste für Firmen auf der ganzen Welt.
Wie jede Sicherheitsvorrichtung, müssen IT-Verantwortliche auch einen Red Forest richtig betreiben, um das Sicherheitsniveau der gesamten Infrastruktur zu steigern. Richten Sie einen unidirektionalen PAM-Trust [7] in Richtung des Red Forests ein. Prüfen Sie den Einsatz von Smartcards für Red-Forest-Anmeldungen und nutzen Sie Shadow Principals, um den Prinzipalen aus den Red-Forest-Berechtigungen in dem oder den Golden Forest(s) zuzuweisen. Als weitere Härtung müssen Sie die Rechte von "Authenticated Users" im Red Forest so beschneiden, dass nicht nur keine Escalation of Privileges, sondern auch kein Suchen und Anzeigen von Objekten und Attributen erlaubt ist. Das Trust-Objekt aus dem vertrauenden Forest lässt sich nämlich missbrauchen, um doch einen Fuß in die Tür des vertrauten Forests zu bekommen. Diese exotische, aber recht leicht ausnutzbare Lücke schließt Windows Server 2025.
Falls Ihre AD-Infrastruktur mehr als einen Forest umfasst (Red Forest zählt dazu), sollten Sie darauf achten, dass Namen der AD-Sites und ihre Zuordnung zu den Subnetzen übereinstimmen. Das verschlankt die Cross-Forest-Anmeldungen und andere AD-Zugriffe erheblich, denn der DC-Locator-Prozess beginnt die Suche nach einem geeigneten DC für den User mit dem Standortnamen, der für den Computer aus seinem Forest bereits bestimmt wurde. Falls Ihre Site- und Subnet-Topologie sehr umfangreich ist, müssen Sie sie nicht in jedem Forest komplett nachbilden. Standorten, aus denen nie Anmeldungen gegenüber dem Forest erfolgen, können Sie, inklusive der ihnen zugewiesenen Subnetze, auch weglassen.
Für den einen Adressbuch, für den anderen Aufklärung
Die erste Funktion des Active Directory, das Objekt-Lookup, ist das primäre Ziel eines jeden LDAP-Verzeichnisdiensts. Auch Microsoft dachte, mit dem AD eine Art "unternehmensweites Adressbuch" anzubieten, in dem Mitarbeiter interne Informationen nachschlagen können. Die Suchfunktion in Windows 2000 und XP hatte ein "Im Verzeichnis suchen"-Widget, um den Benutzern das Durchsuchen des AD aus dem Startmenü heraus zu ermöglichen. Allerdings wurde dieses Feature eher selten eingesetzt, denn erstens konnte der Nutzer mit den gefundenen Objekten nicht viel anfangen und zweitens haben die verbreiteten E-Mail- und Groupware-Produkte wie Exchange oder Lotus Notes bereits damals Adressbücher angeboten, die in Komfort und Leistungsumfang weit über das Such-Widget im Startmenü hinausreichten. Und diese anwendungseigenen Adressbücher erfordern keinerlei direkten Zugriff des Endbenutzers auf das LDAP-Verzeichnis dahinter.
In den allermeisten Fällen muss der gemeine User also gar nicht in der Lage sein, das gesamte Verzeichnis (Domäne oder gar Forest) mithilfe des globalen Katalogs auszulesen. Dies ist jedoch genau der "Ausblick", den das AD jedem Mitglied der "Authenticated Users"-Gruppe ab Werk gewährt. Doch neben den Objekten selbst ist auch der Umfang der per Default lesbaren Attribute problematisch - in einem Maß, dass oft behauptet wird, im AD würde "jeder alles lesen" dürfen.
Ein Großteil dieser übermäßigen Rechte, beispielsweise das "userAccountControl"-Attribut eines anderen User-Objektes zu lesen, wird dabei durch die Gruppe "Prä-Windows-2000-Kompatibler Zugriff" erteilt. Nach der Installation einer AD-Domäne ist, selbst mit Windows Server 2025, die Gruppe "Authentifizierte Benutzer" dort Mitglied. In sehr vielen Organisationen führt das Entfernen dieser Mitgliedschaft zu keinerlei Störungen im Betrieb.
Es gibt jedoch Anwendungen, die den Zugriff ausgewählter User auf bestimmte Attribute anderer Objekte verlangen. Der Grund dafür sind in 99 Prozent der Fälle veraltete Softwarekomponenten, die noch eine NT-Domäne voraussetzen. In diesem Fall müssen Sie die Berechtigungen gezielter kanalisieren und als Erstes die Berechtigungen sowohl für "Authenticated Users" als auch für "Prä-Windows-2000-Kompatibler Zugriff" auf allen OUs und Containern entfernen, die privilegierte Objekte beinhalten. Erteilen Sie diese Berechtigungen den notwendigen Admin-Gruppen, sofern nicht ohnehin bereits geschehen. Kein normaler User muss in der Lage sein, Administratoren, hochprivilegierte Gruppen und Tier-0-Systeme aufzulisten. Denken Sie dabei auch auf die Berechtigungen des "AdminSDHolder"-Containers.
Als Zweites leeren Sie die Gruppe "Prä-Windows-2000-Kompatibler-Zugriff". Wenn sich herausstellt, dass bestimmte Anwendungen diese Rechte benötigen, können Sie die erforderlichen Maschinen oder User dort wieder aufnehmen. Wenn sich wider Erwarten herausstellt, dass eine Anwendung diese Rechte gegenwärtig für alle Standardbenutzer erfordert, erteilen Sie diese mithilfe einer speziellen Gruppe, die Sie dann mit einem Arbeitsschritt löschen können, nachdem Sie die veralteten Applikationen endlich aus Ihrem AD verbannt haben.
Als dritte Maßnahmen schränken Sie die Attribut-Sichtbarkeit auch für Authenticated Users noch weiter ein. Dabei sollten Sie auch die "Configuration"-Partition berücksichtigen, denn diese enthält ebenfalls viele Informationen, die einen potenziellen Angreifer interessieren, für den Standard-User hingegen unwichtig sind.
Aber aufgepasst: Die Windows-Server-Rolle "Network Policy Server" braucht einige der Rechte, die die "Prä-Windows-2000-Kompatibler-Zugriff"-Gruppe erteilt, sodass Sie den jeweiligen Maschinen die benötigten Leseberechtigungen wieder einräumen müssen.
Sie sollten versuchen - und das gilt nicht nur für Berechtigungen im Active Directory, sondern für jede Berechtigungsvergabe in Windows - ausschließlich mit "Allow"-Rechten zu arbeiten. Ist dies nicht möglich und Sie sind auf "Deny" angewiesen, können Sie mit dem "List Object Mode" die Visibilität granular kontrollieren [8]. In großen Umgebungen mit tiefen OU-Hierarchien führt das Aktivieren des List Object Mode jedoch zu einer messbaren Mehrbelastung der Domaincontroller.
Beachten Sie, dass die Technik der Einschränkung der Sichtbarkeit, die die initiale Erkundung durch die Cyberkriminellen wirkungsvoll erschwert, in einer späteren Phase des Angriffs auch als "Defense Evasion" gegen Sie eingesetzt werden kann. Der Angreifer ist dann in der Lage, einen hochprivilegierten User zu erstellen und die Zugriffsrechte auf dieses Objekt allen AD-Prinzipalen zu entziehen. Das verhindert nicht die Authentifizierung und Autorisierung eines solchen Accounts, macht es aber für normale Konsolen und Skripte unsichtbar. Es existieren einige spezialisierte Tools [9], um solcherart versteckte Administratoren aufzudecken.
Falls Sie in Ihrem AD Tools einsetzen, die die Objekte und ihre Konfigurationen auswerten, um eine Bewertung der Angriffsfläche vorzunehmen, müssen Sie bei allen Härtungsmaßnahmen dafür sorgen, dass diese die Fähigkeiten dieser Werkzeuge nicht einschränken - stellen Sie notfalls ein spezielles Konto dafür bereit und räumen Sie diesem Konto das Recht, "alles zu sehen" ein.
Fazit
Der erste Teil unseres Workshops zum sicheren Active-Direcotoy-Design - eines "inhärent unsicher" geglaubten Dienstes - hat gezeigt, wo die Fallstricke in Sachen Security stecken und wie Admins diese umschiffen. Im zweiten Teil widmen wir uns der Härtung der Authentifizierung im Active Directory zum Schutz vor dem Anmeldedaten-Klau, der Konfigurationspflege und der praktischen Einführung dieser Maßnahmen in einer bestehenden Infrastruktur.
(jp)
Link-Codes
[1] Holger Voges: Das große Security-Desaster in der IT: https://www.golem.de/news/microsoft-netzwerke-das-grosse-security-desaster-in-der-it-2311-179535.html
[2] Microsoft Purview: https://learn.microsoft.com/de-de/purview/information-protection
[3] Die zehn unumstößlichen Gesetze der Sicherheit: https://web.archive.org/web/20050314224039/http://www.microsoft.com/technet/archive/community/columns/security/essays/10salaws.mspx
[4] MITRE ATT&CK: https://attack.mitre.org/
[5] Leitfaden zur Wiederherstellung der AD-Gesamtstruktur: https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-guide
[6] Erweiterte Sicherheits- Administratorumgebung: https://learn.microsoft.com/de-de/security/privileged-access-workstations/esae-retirement
[7] Privileged Access Management und Shadow Principals: https://www.teal-consulting.de/2018/08/14/esae-serie-teil-3-privileged-access-management-und-shadow-principals-feature
[8] Kontrolle der Objektsichtbarkeit: https://learn.microsoft.com/en-us/windows/win32/ad/controlling-object-visibility
[9] Versteckte AD-Objekte finden: https://www.semperis.com/blog/find-hidden-active-directory-objects