Im ersten Teil des Workshops haben wir die Probleme analysiert, die für den schlechten Ruf des Active Directory (AD) bei Sicherheitsverantwortlichen geführt haben. Die bekannten Anfälligkeiten haben indes nur zu einem geringen Teil in der Beschaffenheit des AD selbst ihren Ursprung. Viele Probleme sind das Resultat der Standardeinstellungen, mit denen Microsoft das AD bis heute ausliefert. Noch problematischer sind oft Konfigurationen und Prozesse, die IT-Teams in ihren AD-Organisationen implementieren.

Um das Active Directory – im Kontext dieses Artikels sprechen wir über "Active Directory Domain Services" – möglichst sicher zu gestalten und zu betreiben, ist es sehr wichtig zu verstehen, welche Cyberbedrohungen der heutigen Zeit das AD tatsächlich betreffen, welche Ziele Angreifer dabei verfolgen und welche Techniken sie anwenden, um diese Ziele zu erreichen. Für einen Laien mag die aktuelle Fachpresse bisweilen den Eindruck erwecken, dass eine IT-Infrastruktur den Cyberkriminellen praktisch schutzlos ausgeliefert ist, wenn sie auf ein Active Directory aufsetzt. Tatsächlich jedoch ist AD nie der erste Berührungspunkt oder Einfallstor für den Angreifer, und ebenso selten ist die Übernahme des AD das endgültige Ziel.

Der Initialkontakt kommt in der Regel über ein Client-Endgerät (Phishing, Drive-by-Downloads) oder über eine Anwendung (Exchange-Administratoren werden sich noch an den HAFNIUM-Angriff erinnern) zustande. Die Ziele der Angreifer rangieren zwischen totaler Zerstörung (Wiper) und dem Entwenden einer sehr spezifischen Information (Forschungsdaten für Industriespionage, kaufmännische Dokumente für Marktmanipulationen oder "Whale Phishing"-Angriffe auf andere Unternehmen). Dazwischen liegen Verschlüsselung der gesamten Datenbestände als Erpressungsmittel (Ransomware), Einschleusen von Code in den Entwicklungszyklus (Software-Supply-Chain-Angriffe) oder Beeinflussen der vernetzten physischen Infrastruktur (Angriffe auf Stromerzeugung oder Gas-Pipelines).

Das Active Directory bietet in den meisten "historisch gewachsenen" Ausführungen den Angreifern zahlreiche Möglichkeiten, ihr anvisiertes Ziel relativ schnell zu erreichen, ohne dabei frühzeitig aufzufallen. Für die Ersterkundung kann ein User-Account, Arbeitsplatz-Computer oder Anwendungsserver, den der Angreifer unter seine Kontrolle gebracht hat, umfangreiche Informationen über die Umgebung inklusive Konfigurationen, Berechtigungen und Eskalationspfade bereits mit Bordmitteln des Betriebssystems auslesen. Manchmal werden schon in dieser Phase Zugangsdaten für weitere Konten bekannt, beispielsweise lokale Konten, die über Gruppenrichtlinien erzeugt werden, oder Funktionsaccounts mit Passwörtern im Beschreibungsfeld. Über diesen Teil der Angriffskette und Methoden der Einschränkung der Sichtbarkeit von hochprivilegierten Objekten sprachen wir bereits im ersten Teil des Artikels.

Gelingt es dem Angreifer, einen oder mehrere Member-Computer unter seine Kontrolle zu bringen, also beliebige Prozesse im Systemkontext dieser Maschinen ausführen zu können, ist er potenziell in der Lage, auf Zugangsdaten von anderen Konten zuzugreifen, die sich an diesen Computern angemeldet haben. Meistens handelt es sich bei dem erbeuteten Material zwar nur um Kennwort-Hashes, doch solange NTLM und RC4 in der Umgebung möglich sind, ist ein Hash direkt für die Authentifizierung verwendbar (Pass-the-Hash) oder dient zumindest zum Beantragen von Kerberos-Tickets (Overpass-the-Hash). Außerdem sind Hashes nach diesen Verfahren mit vertretbarem Aufwand crackbar, wenn das ursprüngliche Kennwort relativ kurz und einfach ist. Handelt es sich beim erbeuteten Hash-Material um die Zugangsdaten hochprivilegierter Accounts, ist der Angreifer damit in der Lage, neue privilegierte Identitäten zu erzeugen, Replikationsrechte zu erweitern oder Auditing-Einstellungen zu manipulieren. Kommen in der Umgebung Legacy-Service-Accounts zum Einsatz, können diese Kerberoasting-Angriffen zum Opfer fallen. Oft sind solche Service-Accounts mit einem nicht ablaufenden und dennoch relativ kurzen Kennwort versehen, was das Cracken eines Service-Tickets erschwinglich macht.

Stößt der Angreifer bei seiner Erkundung auf Replikationsrechte, die er direkt ausnutzen kann, ist es ihm möglich, wertvolle Daten direkt aus dem Active Directory zu replizieren. Dazu gehören die Passwort-Hashes des KRBTGT-Accounts ("Golden Ticket") und DPAPI-Backup-Keys, mit denen sich alle durch DPAPI geschützten Secrets der Member-Computer und AD-User entschlüsseln lassen.

Falls eine Enterprise-PKI im AD-Forest implementiert und nicht hinreichend gehärtet ist, kann der Bösewicht Kerberos-Zertifikate ausstellen lassen, die ihm eine direkte Anmeldung im Kontext hochprivilegierter Accounts ermöglichen. Und Computer- und Service-Accounts ermöglichen weitere Angriffe auf Zugangsdaten, indem Fehlkonfigurationen in der Kerberos-Delegierung ausgenutzt werden.

Hat sich der Angreifer in die Lage versetzt, Gruppenrichtlinien zu manipulieren, bringt es ihn seinem endgültigen Ziel meistens ein ganzes Stück näher. So kann er beispielsweise in Ransomware- oder Wiper-Szenarien die Schadsoftware über Startup-Skripte oder geplante Tasks auf die gesamte Umgebung ausrollen und zum vorgesehenen Zeitpunkt zünden. Doch auch Persistence und Eskalation sind damit möglich; schafft es der Eindringling, eine Gruppenrichtlinie auf die OU der Domaincontroller zu verknüpfen, die lokale Adminrechte auf Member-PCs an Benutzerkonten vergibt, wandelt er diese Accounts zu Domain-Admins.

Um diese und einige weitere verwandte Techniken dreht sich jede Initiative, die einen möglichst sicheren Betrieb einer Active-Directory-Umgebung zum Ziel hat. Behalten Sie stets im Hinterkopf, dass IT- Sicherheit eine Disziplin des Risikomanagements ist, und es geht dabei nicht um Risikovermeidung, sondern um Risikominimierung. Wenn Sie es mit Ihren Härtungs- maßnahmen schaffen, jeden Angriffspfad möglichst aufwendig und teuer zu machen, wird sich der eine oder andere Cyberkriminelle leichterer Beute zuwenden.

Im Sinne des Risikomanagements sorgt ein sicheres Active-Directory-Design dafür, dass sich die Eintrittswahrscheinlichkeit eines Missbrauchs von Anmeldedaten reduziert – je stärker, je höher die Privilegien der jeweiligen Identität ausfallen. Zudem müssen die Auswirkungen eines erfolgten Diebstahls von Credentials möglichst gering bleiben, besonders dann, wenn sich dieses Entwenden inklusive Klartext-Kennwort nicht ausschließen lässt, wie es beispielsweise bei Domain-Join-Accounts der Fall ist.

Das Begrenzen der Auswirkungen erfordert eine rigorose Umsetzung des Principle of Least Privilege. Dies beginnt mit dem Einschränken von Lese- und Schreibrechten im AD selbst auf das für den Einsatzzweck des jeweiligen Accounts unbedingt Notwendige. Doch auch die Fähigkeit, sich an Computern anzumelden und dort Prozesse zu starten, ist ein Privileg, das missbraucht werden kann. Unter Umständen stellt sogar einfacher lesender Netzwerkzugriff auf "offiziell" freigegebene Ressourcen ein aus Sicht des Angreifers wertvolles Recht dar – beispielsweise dann, wenn das Entwenden eines bestimmten Dokuments bereits sein eigentliches Angriffsziel ist.

Der vollständige Berechtigungsentwurf für ein Least-Privilege-Modell ist ein großes Unterfangen und die wenigsten Administratoren und Architekten sind in der Lage, einen solchen Entwurf auf dem Reißbrett zu erstellen. Die Aufgabe wird auch durch die Tatsache erschwert, dass viele der Rechte, die idealerweise weggenommen werden müssen, standardmäßig an virtuelle Gruppen wie "Authenticated Users" oder "Everyone" vergeben sind, aus denen Sie einzelne Benutzer oder Computer nicht entfernen können.

Sie müssen sich daher trauen, die Berechtigungseinträge dieser virtuellen Gruppen zu entfernen und durch eine Kombination von Optionen zu ersetzen, die die erforderlichen Rechte an "echte" Gruppen delegieren. Diese Umstellung gibt Ihnen gleich die Gelegenheit, hochprivilegierte Objekte von vornherein für normale User und Computer unsichtbar zu machen. Sie sollten die Vergabe der Rechte im AD stets per Skript durchführen, denn das liefert Ihnen bereits 90 Prozent des Codes, um die korrekten Berechtigungen nachträglich zu kontrollieren, und ermöglicht außerdem eine schnelle Berechtigungsvergabe in einem weiteren Forest.

Wenn es um den Schutz der Credentials vor Entwendung und Missbrauch geht, müssen Sie die verschiedene Bedrohungsszenarien betrachten. Zunächst ist hier das Bekanntwerden von Benutzername und Kennwort zu nennen, also der berühmte gelbe Zettel unter der Tastatur oder die Datei "passwords.txt" auf dem Desktop. In der modernen Cloudwelt sind Sie in der Lage, diese Bedrohungen durch Multifaktor-Authentifizierung zumindest etwas einzudämmen. Klassische On-Premises-Technologien bieten da deutlich weniger Spielraum, sodass die konsequente Fortbildung aller Mitarbeiter inklusive IT-Administratoren die einzige Methode ist, um der physischen Kennwort-Weitergabe zu begegnen. Ein anderer Ansatz, der auch lokal gut funktioniert, ist der Verzicht auf Kennwörter zugunsten von Smartcards beziehungsweise Windows Hello for Business. Prüfen Sie dafür, ob alle Anwendungen in Ihrer Infrastruktur Kerberos oder zumindest NTLM unterstützen. Falls Sie eine wichtige und von vielen Benutzern verwendete Webapplikation, die darauf besteht, dass Benutzername und Kennwort in eine Anmeldemaske einzugeben sind, betreiben müssen, checken Sie, ob sie gegebenenfalls ADFS als Authentifizierungsverfahren unterstützt.

Der nächste Punkt sind Brute-Force-Angriffe auf explizite Authentifizierung: Die offensichtliche Antwort auf diese Art von Bedrohungen ist eine Kontosperrungsrichtlinie. Allerdings ist automatische Kontosperrung ein zweischneidiges Schwert – schließlich kann sie den gesamten Betrieb mit minimalem Aufwand lahmlegen. Falls Sie dieses Policy dennoch einsetzen wollen, stellen Sie die Anzahl fehlgeschlagener Anmeldungen bis zur Sperrung deutlich höher ein als den Wert "10", den sowohl Microsoft als auch das CIS standardmäßig empfehlen. Ein möglicher Lösungsansatz ohne Denial-of-Service-Potenzial ist die adaptive Drosselung. Anwendungen mit Webfrontend bedienen sich dieser Technologie regelmäßig, wie jeder FritzBox-Benutzer weiß, der sich schon einmal beim Kennwort vertippt hat. Mit Server 2025 führt Microsoft den "Authentication Rate Limiter" für SMB-Dateifreigaben ein. Dieser ist zwar nicht adaptiv in dem Sinne, dass die Pause nach jedem weiteren erfolglosen Anmeldeversuch länger wird, aber definitiv ein Schritt in die richtige Richtung. Authentifizierungsrichtlinien helfen, die Angriffsfläche für Brute Force zumindest etwas einzuschränken. So kann beispielsweise ein Tier-0-Account nicht durch einen Brute-Force-Angriff auf Anwendungsserver gesperrt werden, ein Service-Account nicht vom Client aus und ein normaler User nicht durch Angriffe auf die NETLOGON-Freigabe eines DC. Als letztes Mittel der Absicherung bleibt die Überwachung fehlgeschlagener Anmeldeversuche – dies bringt natürlich nur dann Vorteile im Betrieb, wenn Sie den Meldungen tatsächlich zeitnah nachgehen.

Zu Brute-Force-Angriffen auf erbeutete Kennwort-Hashes gehören einerseits Hashes, die aus Anmeldesitzungen an Workstations oder Servern ausgelesen werden, und andererseits Techniken wie Kerberoasting, die auf die Datenstruktur eines Kerberos-Service-Tickets aufsetzen und sich die Tatsache zunutze machen, dass standardmäßig jeder User für jeden Dienst ein Service-Ticket anfordern kann. Schränken Sie rigoros ein, welcher Benutzer sich wo anmelden darf. Dazu nutzen Sie Authentifizierungs- und Gruppenrichtlinien ("Zuweisen der Benutzerrechte"), wobei erstere viel wirkungsvoller sind. Für den Schutz hochprivilegierter Accounts ist diese Technik als "Administratives Tiering" bekannt, Sie können sie jedoch auch innerhalb eines Tiers anwenden ("Zoning"), um die potenziell abgreifbaren Credentials noch weiter zu kanalisieren und neben Eskalation auch das Lateral Movement zu erschweren. Auf allen unterstützten Windows-Versionen bietet Microsoft zudem mit Credential Guard eine auf Virtualisierung basierende, extrem wirkungsvolle Technik, die Sie jedoch erst aktivieren müssen.

Um den letzten Teil des Angriffsvektors zu erschweren, nämlich die Brute-Force-Rekonstruktion des Klartext-Kennworts aus dem Hash oder Service-Ticket, hilft nur eine drastische Erhöhung der Kennwortlänge, idealerweise erzwungen durch Kennwortrichtlinien oder durch den Prozess, den Sie für den Kennwortwechsel eingerichtet haben. Benutzerfortbildung mit dem Ziel, Kennwörter durch Passphrasen zu ersetzen und auf diese Weise lange und dennoch gut merkbare Kennwörter zu realisieren, ist ein sehr lohnenswertes Unterfangen. Empfehlungen sowohl des NIST als auch des BSI gehen sogar so weit, dass Unternehmen ab einer gewissen Mindestlänge (meistens 20 Zeichen) auf regelmäßige Kennwortwechsel verzichten können. In einer hypothetischen Umgebung, wo ein Kennwort ausschließlich per Tastatur in eine Maske eingegeben wird, wäre diese Empfehlung sogar berechtigt. Leider ist das Passwort-Hash oft auch ohne Brute Force wertvoll, sodass Sie für alle Accounts – normale User, Admins, Service-Accounts und sogar Break Glass – ein praktikables Verfahren zum Kennwortwechsel vorsehen müssen.

Bei der direkten Verwendung von Kennwort-Hashes (Pass-the-Hash/Overpass-the-Hash) machen sich die Angreifer zwei Eigenarten der Windows-Authentifizierung zunutze. Erstens benötigt NTLM ausschließlich das Kennwort-Hash für den gesamten Authentifizierungsprozess und zweitens ist das RC4-Hash in Kerberos identisch mit dem NTLM-Hash. Bei direkter Verwendung der Hashes spielt die Länge der ihnen zugrunde liegenden Kennwörter keine Rolle. Solange also Ihre Umgebung NTLM akzeptiert beziehungsweise Kerberos die RC4-Kryptografie zulässt, ist regelmäßiger Passwortwechsel nicht optional. Für privilegierte Accounts sollten Sie sich der Authentifizierungsrichtlinien oder zumindest der Gruppe "Protected Users" bedienen, denn damit sind NTLM und RC4 nicht möglich oder auf bestimmte Kommunikationsbeziehungen beschränkt. Für Service- und Task-Accounts müssen Sie, falls noch nicht geschehen, den Wechsel zu Group Managed Service Accounts (gMSA) prüfen – dort wird die Kennwortänderung automatisch durch AD selbst durchgeführt. Alle oben beschriebenen weiteren Maßnahmen, die ein Erbeuten von Hashes verhindern, helfen auch bei diesem Angriffsvektor.

Das Abgreifen von Hashes aus Anmeldesitzungen ist natürlich nicht der einzige Weg, um an dieses wertvolle Datenmaterial zu kommen. Eine ganze Reihe von Relay- und Replay-Angriffstechniken, die den Begriff "Potato" im Namen tragen [1], haben das Offenbaren von Hash-Material zum Ziel. Ist es dem Angreifer gelungen, an Replikationsberechtigungen zu kommen, kann er die Hashes direkt aus AD mittels Verzeichnisreplikation auslesen. Und natürlich bietet ein ungeschütztes System-State-Backup eines Domaincontrollers, sollte es in falsche Hände geraten, ungehinderten Zugriff auf diese Informationen. Da gleichzeitig die Aussage, dass "Microsoft im Disaster-Fall ausschließlich ein System-State-Backup supportet", zu den hartnäckigsten Mythen über Disaster Recovery im AD-Umfeld gehört, sind System-State-Backups von DCs in vielen Umgebungen zu finden. Falls Sie Ihre Disaster-Recovery-Strategie für das AD ebenfalls darauf aufbauen, sollten Sie zumindest dafür sorgen, dass der Zugriff auf diese Datenbestände extrem restriktiv ist.

Zu den bereits bekannten gefährlichen Fehlkonfigurationen im AD kam in den letzten Jahren eine Reihe von Angriffsvektoren hinzu, die zwar Active Directory Domain Services zum Ziel haben, sich jedoch eines anderen AD bedienen – der AD Certificate Services (ADCS; Microsofts Implementierung einer Enterprise-PKI). Die erste systematische Abhandlung über ADCS-Anfälligkeiten, die zur Kompromittierung von ADDS führen, ist das Whitepaper "Certified Pre-Owned" [2] von Will Schroeder und Lee Christensen aus dem Jahr 2021. Die dort beschriebenen Angriffstechniken wurden inzwischen mehrfach verfeinert und erweitert, sodass jedem Sicherheitsverantwortlichen klar sein dürfte, dass hier ernsthaftes Problempotenzial schlummert. Bevor Sie also über die optimale PKI-Strategie in Ihrer Organisation entscheiden, müssen Sie sich der PKI-basierten Angriffsvektoren bewusst sein und die Techniken kennen, mit denen Sie die Auswirkungen der Enterprise PKI auf die Sicherheit Ihres AD eindämmen können.

Jeder PKI liegt Vertrauen zugrunde. Die Bedrohungen durch die Zertifikatsdienste basieren auf zwei Möglichkeiten, dieses Vertrauen zu missbrauchen. Erstens ist der Umstand zu nennen, dass Kerberos in Windows Zertifikate als valide Authentifizierungsmethode akzeptiert, worauf sowohl Smartcards als auch Windows Hello basieren. Das Teilprotokoll dafür heißt "PKINIT". Der KDC in einem Domaincontroller vertraut für die Validierung von Smartcard-Zertifikaten allerdings nicht jeder CA, die sich bis in die "Trusted Roots" des DC zurückverfolgen lässt, sondern bedient sich eines speziellen NTAUTH-Zertifikatsspeichers. In diesen trägt sich eine Enterprise-CA bei ihrer Installation selbsttätig ein, unabhängig davon, ob die Organisation überhaupt beabsichtigt, aus dieser PKI authentifizierungsfähige Zertifikate auszustellen oder nicht. Damit führen diverse Angriffe auf eine solche Root CA zu Zertifikaten, die für Kerberos valide und auf hochprivilegierte Identitäten wie Admin-Accounts, Domaincontroller oder sogar ganze Domänen (zum Durchbrechen von einseitigen Vertrauensstellungen) ausgestellt sind.

Nicht so gravierend, aber auch schwieriger zu behandeln sind Zertifikatstypen, die zwar nicht direkt für erfolgreiche Kerberos-Authentifizierung sorgen, aber dennoch Kommunikationsbeziehungen ermöglichen. Dazu gehören in erster Linie Serverzertifikate, die einem Angreifer erlauben, eine HTTPS-Seite zu spoofen, ohne dass es zu Zertifikatsmeldungen in den Anwendungen führt. Doch auch Computerzertifikate, die für 802.1X-Authentifizierung valide sind, können dem Angreifer Zugang zu Netzwerken verschaffen, in denen sich seine Angriffsziele befinden.

Beide Problemfelder werden dadurch verstärkt, dass es mit der Microsoft-PKI sehr einfach ist, die Situation herbeizuführen, in der ein nicht besonders hochprivilegierter Benutzer sowohl die für Angreifer interessanten Zertifikatstypen beantragen und erhalten als auch den "Subject Name" dieser Zertifikate frei definieren kann. Damit wäre er in der Lage, ein Smartcard-Zertifikat für den Domänen-Admin auszustellen und hätte somit die Domäne übernommen. Oder, falls das Ziel des Angreifers hinter einem Webportal liegt, bei dem zwingend das Kennwort eines entsprechend berechtigten Nutzers eingegeben werden muss, könnte sich der Angreifer ein HTTPS-Zertifikat für die entsprechende URL ausstellen lassen. So kann er anschließend DNS spoofen, um Zugriffe der Nutzer auf einen Webserver zu lenken, den er selbst kontrolliert.

Für ein sicheres PKI-Design (zu dem durchaus auch der Verzicht auf eine interne PKI gehören kann) ist es also wichtig zu definieren, wer mit welchen Verfahren Zertifikate beantragen kann und bis zu welchem Grad ihnen vertraut wird:

- Setzen Sie keine zertifikatsbasierte Authentifizierung in Kerberos ein (was wir jedoch dringend empfehlen), entfernen Sie die Zertifikate Ihrer PKI aus dem NTAuth-Container. Sie können die Zertifikate später wieder hinzufügen, wenn es erforderlich sein sollte.

- Ihre PKI ist ein Tier-0-System. Regeln Sie den Zugang zu ihr und die Verwaltungsrechte entsprechend. Das gilt übrigens unabhängig davon, ob Sie die Microsoft-PKI (ADCS) oder ein anderes Produkt einsetzen.

- In einer mehrstufigen PKI sind alle CAs Tier 0 zuzuordnen.

- Nutzen Sie CA-Beschränkungen, um die Ausstellung von Zertifikaten zu kanalisieren. Stellen Sie bei Bedarf getrennte CAs für Smart-Card-Zertifikate und andere Typen wie Webserver-Zertifikate bereit.

- Auch der Betrieb mehrerer PKI-Bäume mit separaten Root-CAs für verschiedene Anwendungszwecke ist durchaus eine valide Option.

- Installieren Sie keine PKI-Webdienste auf Verdacht. Falls Sie diese benötigen, konfigurieren Sie sie in einer dem Nutzungszweck entsprechenden Weise. Den veralteten Dienst "Zertifikatsdienste-Webregistrierung" dürfte niemand mehr benötigen, denn er basiert auf ActiveX-Steuerelementen.

- Nur Tier-0-Administratoren sollten in der Lage sein, Smartcard-Zertifikate zu beantragen. Ist für Admins niedrigerer Tier oder normale User eine Smartcard erforderlich, benutzen Sie einen Enrollment-Agenten, statt den Anwendern die Berechtigung zum Beantragen dieser Zertifikate zu erteilen. Wenn gar nicht anders möglich, erzwingen Sie die Freigabe der Smartcard-Zertifikate durch einen Administrator, ganz gleich, wer der ursprüngliche Antragsteller ist.

- Nutzen Sie unbedingt das "Tame My Certs"-Policy-Modul mit Ihrer MS-PKI. Damit können Sie verbindlich regeln, welche Adressen und Identitäten in Ihren Zertifikaten enthalten sein dürfen.

- Nutzen Sie zumindest für hochbrisante Zertifikate deterministische OCSP-Konfigurationen [3] statt einer einfachen CRL. Damit sind Zertifikate, die der Angreifer aus der PKI ausstellt, weiterhin valide, doch können Sie immerhin den Fall abfangen, dass der Angreifer an den privaten Schlüssel einer ausstellenden CA gekommen ist und Zertifikate an der PKI vorbei signiert.

Falls Ihre Organisation noch keine klar formulierte Strategie für den Umgang mit Zertifikaten hat, ist es in jedem Fall sicherer, keine interne PKI zu betreiben und HTTPS-Zertifikate für eventuelle Webanwendungen bei einer öffentlichen Zertifizierungsstelle einzukaufen. Sie benötigen dafür entweder einen öffentlich auflösbaren Domänennamen (der Ihnen auch gehört) oder eine Split-Horizon-DNS-Konfiguration, die öffentliche Namen zu privaten IP-Adressen auflöst, wenn interne DNS-Server angesprochen werden.

Viele Maßnahmen, die Ihr Active Directory entscheidend sicherer machen werden, sind nicht so sehr im AD selbst verankert wie in der Infrastruktur darum herum, inklusive der Windows-Server, die die Domaincontroller-Rolle ausführen. Da der Erstkontakt des Angreifers mit der Umgebung entweder auf einem Endgerät oder auf einem extern veröffentlichten Anwendungsserver stattfindet, können Sie die Angriffsfläche Ihrer Umgebung bereits signifikant verringern, indem Sie auf diesen Maschinen Folgendes einsetzen:

- Aktuelle, verwaltete und intelligente Antimalware

- Prozess-Whitelisting: Idealerweise Windows Defender Application Control oder zumindest AppLocker

- Eingeschränkte Verwaltungsrechte: Keine regelmäßige interaktive Anmeldung mit Adminrechten, kein Internetzugang aus einer administrativen Sitzung heraus

- Credential Guard

Um Lateral Movement und Eskalation zu erschweren, helfen Firewalls. Auch diese müssen Sie im Sinne einer Whitelist konfigurieren – nur das, was explizit erlaubt ist, ist möglich. Die ersten Hürden können Sie bereits mit sehr einfachen Firewallregeln aufstellen:

- Clients dürfen nicht untereinander kommunizieren, egal auf welchen Protokollen. Falls Sie zu den wenigen Organisationen gehören, die "Delivery Optimization" in ihr Updatemanagement integriert haben, ist es die einzige Ausnahme. Zusammen mit LAPS schließt diese Einrichtung das Lateral Movement praktisch aus.

- Zugriff in Managementnetze für etwa Hardware- und Virtualisierungsmanagement, Netzwerkgeräte, Storage sowie Klima- und Stromsteuerung ist nur von ausgewählten Geräten zulässig, auf keinen Fall jedoch von Client- oder Druckernetzen aus. Wenn Sie auf Nummer sicher gehen wollen, platzieren Sie einen Jumphost in den jeweiligen Segmenten und sichern Sie den Zugriff darauf mit MFA ab – im einfachsten Fall mit einem Remote Desktop Gateway.

- Managementprotokolle wie WinRM und WMI, inzwischen auch zunehmend SSH auf Infrastrukturservern dürfen nur von einer kleinen Anzahl explizit angegebener Management- und Monitoringmaschinen erreichbar sein.

Setzen Sie bei der Auswahl von Monitoring- und Managementanwendungen auf agentenbasierte Produkte, deren Agent Verbindungen von den verwalteten Geräten aus zum jeweiligen Verwaltungssystem aufbaut und nicht umgekehrt. Je weniger eingehende Kommunikationsbeziehungen für den ordnungsgemäßen Betrieb Ihrer Systeme notwendig sind, desto besser.

Regeln Sie verbindlich, wer Gruppenrichtlinien bearbeiten darf und vor allem, wer sie mit OUs mit hochprivilegierten Objekten (Domaincontroller, Tier-0-Admins), an Domänen und AD-Sites verknüpfen kann. Leider ist die mitgelieferte Group-Policy-Management-Konsole nicht besonders kooperativ, wenn Sie die Berechtigungen allzu sehr einschränken. Erwägen Sie daher, entweder das gesamte Gruppenrichtlinien-Management in Tier 0 anzusiedeln oder ein Third-Party-Produkt für die GPO-Verwaltung einzusetzen, das eine wirksame Delegation erlaubt.

Nutzen Sie BitLocker auf Domaincontrollern, sobald eine ernsthafte Gefahr besteht, dass deren Festplatten entwendet werden können – sei es zusammen mit dem physischen Server oder als virtuelle Disk-Images auf dem zentralen Storage. BitLocker hat natürlich nur dann das Potenzial, die Sicherheit Ihrer DCs zu erhöhen, wenn sich der solcherart entwendete DC beim Hochfahren nicht automatisch entsperrt. In der täglichen Administration bedeutet dieser Umstand, dass Sie Ihre DCs nicht unbeaufsichtigt neu starten können. Sie sollten daher den Einsatz von Network Unlock prüfen.

Deaktivieren Sie alle nicht benötigten Dienste auf hochprivilegierten Systemen. Leider gibt Microsoft seit Server 2019 keine eigenen Empfehlungen mehr dazu, sodass Sie auf eigene Erfahrungen, Informationen aus der Community sowie Trial and Error angewiesen sind. In jedem Fall sollten Sie den Druckspooler-Dienst auf Tier-0-Systemen ein für alle Mal deaktivieren. Falls Sie freigegebene Drucker im AD veröffentlichen, stellen Sie fest, dass die Print-Queue-Objekte dann nicht mehr automatisch gelöscht werden. Dies ist jedoch ein sehr geringer Preis für ein wichtiges Sicherheitsfeature.

Haben Sie eine Konfiguration sowohl für Ihren AD-Forest als auch für die Maschinen in ihm erstellt und ausgerollt, ist Ihr Werk noch nicht vollbracht. Sie müssen von jetzt an den Istzustand kontinuierlich überwachen, um Abweichungen von der definierten Konfiguration ("configuration drift") frühzeitig zu erkennen und zu beheben. Je nachdem, welche Technologien der AD- und Konfigurationsverwaltung in Ihrer Organisation etabliert sind, können Sie dabei auf Monitoring, Desired State Configuration, Infrastructure-as-Code oder andere Techniken setzen. Wichtig ist, dass Sie die Abweichungen erkennen und darauf reagieren.

Ein Vorgang, der viele potenziellen Angriffspfade offenbart, ist das Hinzufügen eines neuen Computers zur Domäne. Als Teil der allgemeinen Account-Hygiene sollten Sie die Berechtigung entfernen, bis zu zehn Computer in die Domäne aufzunehmen, die standardmäßig an jeden User vergeben ist. Damit verhindern Sie immerhin, dass ein möglicher Angreifer bereits sehr früh in seiner Angriffskette neue Computerobjekte erzeugen und Maschinen seiner Wahl in Ihr AD aufnehmen kann.

Viel schwerwiegender ist jedoch der Domain-Join-Vorgang in Bezug auf Server. Wenn ein Domain-Admin diesen Vorgang manuell von der neuen Maschine aus initiiert, ist der Eigentümer des so entstandenen Computerobjekts die Gruppe der Domain-Admins, was eine gute und sichere Wahl ist. Möchten Sie den Vorgang jedoch automatisieren, müssen Sie damit rechnen, dass die Credentials des für Domain Join vorgesehenen Accounts effektiv im Klartext vorliegen. Denn diese sind an einen frisch installierten Computer zu übermitteln, mit dem keine gemeinsame Vertrauensbasis besteht. Daher müssen Sie bestrebt sein, die Rechte des Join-Users auf das notwendige Minimum zu beschränken – mit der Folge, dass der Join-User Eigentümer des Computer-Objektes im AD sein wird. Wenn Sie nicht aufpassen und der neue Server ein Tier-0-System, vielleicht sogar ein Domaincontroller wird, dann haben Sie ein hochprivilegiertes System geschaffen, dessen Computerobjekt einem User gehört, dessen Credentials effektiv im Klartext exponiert sind. Es gibt einige Wege aus diesem Dilemma, mit denen sich (auch unternehmensspezifische) Join-Prozesse absichern lassen:

- Vorprovisionieren des Computerobjekts, sodass der Join-User noch weniger Rechte benötigt und nicht als Eigentümer des neuen Maschinen-Accounts eingetragen wird.

- Vorprovisionieren des Computerobjektes unter Verwendung des "offline Joins" (mit dem DJOIN-Befehl [4]). In diesem Fall übertragen Sie nicht Credentials eines Join-Accounts, sondern eine Offline-Join-Datei an den neuen Computer. Wenn Sie dafür einen sicheren und robusten Prozess finden, ist es ein sehr guter Ansatz.

- Verwendung eines ephemeren Domain-Admin-Accounts, den Sie pro Computer erstellen und nach erfolgtem Deployment wieder löschen. Dies sollte allerdings nicht Ihre erste Wahl sein.

Vorprovisionierte Computerobjekte haben den zusätzlichen Charme, dass Sie diese bereits vor der Installation des eigentlichen Computers in die richtigen OU und Gruppe aufnehmen können. Denken Sie daran, dass Microsoft den Join-Vorgang unter Verwendung eines bestehenden Computer-Objektes 2022 und noch einmal 2023 gehärtet hat [5], was Ihre Gestaltungsmöglichkeiten etwas einschränkt.

Eine weitere Maßnahme, die Sie gleich in den Deployment- beziehungsweise den Domain-Join-Prozess integrieren sollten, ist das Entfernen der Gruppe der Domain-Admins aus der lokalen Admin-Gruppe der frisch gebackenen AD-Mitglieder. In der Standardkonfiguration der AD-Berechtigungen können Sie dies ganz einfach mit Group Policy Preferences oder, etwas weniger komfortabel, mit der Gruppenrichtlinie "Eingeschränkte Gruppen" lösen. Allerdings ist dafür notwendig, dass das Computerkonto die Domain-Admins-Gruppe zumindest sehen kann. Das Gleiche gilt für die Gruppen oder Benutzer, die Sie anstelle der Domain-Admins zur lokalen Administration berechtigen wollen – der Computer muss diese Objekte sehen, um die Policy zu verarbeiten. Ein möglicher Lösungsansatz wäre, das vorprovisionierte Computerobjekt temporär zu einer Gruppe mit Sicht auf die benötigten privilegierten Gruppen hinzuzufügen und nach Abschluss des Deployments wieder aus dieser Gruppe zu entfernen.

Falls Ihr Active Directory bereits hybrid ausgelegt ist und alle Nutzer neben ihrem AD-Account auch ein synchronisiertes Entra-ID-Konto besitzen, sollten Sie erwägen, Ihre Clientmaschinen gar nicht erst ins AD aufzunehmen, sondern direkt Entra ID zuzuordnen. Der Zugriff auf lokale Ressourcen kann sich, sofern eine Netzwerkverbindung zu Domaincontrollern gegeben ist, weiterhin mit Kerberos authentifizieren – lediglich Dienste und Systeme, die NTLM erfordern, blieben dann auf der Strecke. Natürlich stehen Gruppenrichtlinien zur Konfiguration nicht mehr zur Verfügung, sodass Sie auf Intune oder ein anderes Werkzeug zurückgreifen müssen. Der Zugewinn an Sicherheit ist allerdings gewaltig.

Techniken des sicheren AD-Designs sind relativ einfach umzusetzen, wenn Sie einen neuen AD-Forest auf der grünen Wiese bauen. Bei einer gewachsenen Infrastruktur können Sie zwar alle einzelnen Maßnahmen technisch umsetzen, IT-Verantwortliche scheuen jedoch meistens davor zurück, da nicht klar ist, welche Nebenwirkungen diese Härtungs- und Reorganisationsmaßnahmen haben. Da nichts zu unternehmen heutzutage keine Option mehr ist, läuft dieses Dilemma oft auf einen Neuaufbau des Active Directory mit anschließender Migration hinaus.

Wenn Sie wissen, was Sie tun, ist gegen eine Migration auch nichts einzuwenden und ein neuer Forest ist besonders in den folgenden Situationen dringend angezeigt:

- Die bisherige AD-Struktur beinhaltet viele Domänen in einem Forest, die auf eine flache Single-Domain-Topologie reduziert werden sollen, was ohnehin eine Migration darstellt.

- Der Umgang mit System-State-Backups von Domaincontrollern war bisher eher locker geregelt, sodass Sie davon ausgehen müssen, dass ein potenzieller Angreifer im Besitz Ihrer DPAPI-Backup-Keys ist.

Doch auch in Forests, in denen Sie die Berechtigungs- und Delegations-Strukturen bereits stark verbogen haben, kann ein Befreiungsschlag einer Migration einfacher durchzuführen sein als eine minutiöse Bereinigung mit schwer vorhersehbaren Konsequenzen jedes Anpassungsschritts. Falls Sie diesen Weg gehen, sollten Sie versuchen, die Migration ohne Hinzunahme von SIDHistory durchzuführen. Macht die geplante Koexistenz des alten und des neuen AD in Verbindung mit den vorhandenen Applikationen die SIDHistory unabdingbar, müssen Sie wenigstens einen klaren Fahrplan zur Auflösung der Koexistenz und Entfernung der SIDHistory vorhalten.

Sie können Ihr Active Directory in einer sicheren Art und Weise betreiben. Dafür müssen Sie jedoch einem auf Sicherheit ausgerichteten Generalplan folgen und massiv von den Default-Werten abweichen, mit denen Active Directory und die Maschinen darum herum ausgeliefert werden. Account-Hygiene inklusive Service-Accounts, Kryptografie und PKI, Berechtigungen und scheinbar harmlose Prozesse wie die Aufnahme neuer Computer ins AD – mit diesem Artikel können wir nur an der Oberfläche kratzen und eine grobe Richtung vorgeben. Doch es lohnt sich, Zeit und Mühe in die Sicherheit des AD zu investieren, denn es bleibt Ihnen noch eine ganze Weile erhalten.