Anonymer LDAP-Zugriff dsHeuristics: Wie ein einziges schwaches Attribut Ihre gesamte Domäne offenlegt

Anonymer LDAP-Zugriff dsHeuristics in Active Directory erklärt

Anonymer LDAP-Zugriff dsHeuristics in Active Directory – wenn Sie über genau diese Suche hierher gefunden haben, ahnen Sie bereits, was dieser Artikel bestätigt: Ein einziges Zeichen in einem einzigen Attribut reaktiviert stillschweigend unauthentifizierte LDAP-Operationen in einem gesamten Active-Directory-Forest, und fast nichts im Standard-Admin-Werkzeugkasten zeigt Ihnen, dass es passiert ist.

Active-Directory-Domänencontroller akzeptieren unauthentifizierte LDAP-Verbindungen nur für genau zwei eng begrenzte Zwecke: das Aushandeln der Bindung selbst und Abfragen von rootDSE (die eigenen Fähigkeits- und Konfigurationsdaten des Servers). Microsofts eigene Dokumentation zieht diese Grenze klar: „Anonyme LDAP-Operationen (Lightweight Directory Access Protocol) gegen Active Directory, mit Ausnahme von rootDSE-Suchen und -Bindungen, sind nicht zulässig" auf Domänencontrollern ab Windows Server 2003. Alles darüber hinaus – das Durchsuchen des Verzeichnisbaums selbst, das Lesen von Benutzer-, Gruppen- oder OU-Objekten – erfordert einen authentifizierten Client.

Dieser Standardwert ist neuer, als die meisten Administratoren annehmen. Domänencontroller auf Basis von Windows 2000 unterstützen diese Einschränkung überhaupt nicht: Sind sie in einem Forest auf Basis von Windows Server 2003 vorhanden, setzen sie die Sperre anonymer Operationen schlicht nicht durch. Dieses Sperrverhalten wurde mit Windows Server 2003 eingeführt und ist an die Funktionsebene des Domänencontrollers gebunden, nicht allein an die Betriebssystemversion. Jeder Domänencontroller unterhalb der Windows-Server-2003-Funktionsebene lässt anonyme Operationen standardmäßig zu; jeder Domänencontroller auf oder über dieser Ebene blockiert sie standardmäßig.

Die Sperre ist der Standard. dsHeuristics ist das eine Attribut, das sie leise wieder abschalten kann – forest-weit, für jeden Domänencontroller, ohne eine einzige GUI-Checkbox, die jemanden warnt, dass es passiert ist.

So funktioniert es – das Attribut dsHeuristics

dsHeuristics ist ein Unicode-String-Attribut, das auf dem Objekt CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration unter der Forest-Root-Domäne gespeichert ist. Jede Zeichenposition im String ist eine unabhängige Heuristik, und die Reihenfolge ist fest – Zeichen können nur ausgelassen werden, indem der String vom Ende her gekürzt wird. Laut der [MS-ADTS]-Protokollspezifikation existiert das Attribut standardmäßig überhaupt nicht, und der Standardwert jedes möglichen Zeichens ist "0".

Das siebte Zeichen – fLDAPBlockAnonOps

Das siebte Zeichen ist fLDAPBlockAnonOps: Steht es auf "2", ist die Heuristik zur Sperre anonymer Operationen FALSE, das heißt, anonyme LDAP-Operationen sind erlaubt. Jeder andere Wert – oder das schlichte Fehlen des Zeichens – lässt die Sperre auf Domänencontrollern ab der Windows-Server-2003-Funktionsebene in Kraft.

dSHeuristics: 0000002
              ^      ^
              Zeichen 1-6 auf Standardwerten (0)
                     Zeichen 7 = 2 -> anonyme LDAP-Operationen erlaubt

Das Attribut hat kein eigenes Panel in Active Directory-Benutzer und -Computer, keine Gruppenrichtlinien-Einstellung und keinen Warnhinweis irgendwo im Standard-Admin-Tooling. Die einzigen Wege, es zu sehen, sind ADSI-Edit (adsiedit.msc) oder ldp.exe, verbunden mit dem Configuration-Namenskontext. Eine Umgebung kann jede Checkliste bestehen, die nur GPO-Einstellungen betrachtet, und trotzdem anonymen LDAP-Zugriff weit offen haben, weil nichts im Standard-Tooling diesen Wert sichtbar macht, sofern nicht gezielt danach gesucht wird.

Das achte Zeichen – fAllowAnonNSPI

Eine benachbarte, häufig übersehene Heuristik liegt eine Position weiter: Position 8, fAllowAnonNSPI, steuert, ob anonyme Aufrufer die NSPI-RPC-Bindungsmethode nutzen können – das Protokoll hinter dem Outlook/Exchange-Adressbuch. Das ist eine separate, von LDAP unabhängige Angriffsfläche für anonymen Zugriff, aber es lohnt sich, sie im selben Zug zu prüfen, da sie im selben Attribut und im selben blinden Fleck liegt.

Nicht dasselbe wie RestrictAnonymous

Es lohnt sich außerdem, dies von einer Kontrolle abzugrenzen, die die meisten Hardening-Checklisten bereits abdecken: den Registrierungswert RestrictAnonymous und die Sicherheitsrichtlinie „Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen". Diese regeln die anonyme SAM/RPC-Enumeration – ein völlig anderer Codepfad. Teams, die RestrictAnonymous gehärtet haben und weitergezogen sind, gehen oft davon aus, dass LDAP durch dieselbe Einstellung abgedeckt ist. Ist es nicht; dsHeuristics ist die Kontrolle, die LDAP tatsächlich absichert, und sie muss eigenständig geprüft werden – zusammen mit den anderen Netzwerkeinstellungen der Domänencontroller aus Domain Controller LDAPS schwaches TLS, Print Spooler, Zeitsynchronisation Audit: Eine Checkliste für die Netzwerkhygiene.

Wenn Ihre Organisation bereits LDAP-Signierung gehärtet hat: Signierung und dsHeuristics schützen vor unterschiedlichen Dingen. Signierung verhindert Manipulation und Relay auf einer bereits authentifizierten Verbindung; dsHeuristics entscheidet, ob eine Verbindung sich überhaupt authentifizieren muss. Das eine zu beheben, bewirkt für das andere nichts.

Was ein Angreifer davon hat

Ist fLDAPBlockAnonOps deaktiviert, kann ein anonymer LDAP-Client jede Operation ausführen, die die Zugriffssteuerungsliste (ACL) eines Objekts dem Prinzipal „Anonymous Logon" / „Everyone" erlaubt – keine Zugangsdaten erforderlich, nicht einmal ein Gastkonto mit niedrigen Rechten. In der Praxis sind das die Standard-Objekt-ACLs der meisten Domänen auf Benutzer, Gruppen und Organisationseinheiten, was ausreicht, um den gesamten Baum abzulaufen: Benutzernamen, Gruppenmitgliedschaften, OU-Struktur und oft beschreibende Attribute wie Jobtitel oder Freitext-Beschreibungsfelder, die am Ende mehr preisgeben, als sie sollten.

Genau dieses Muster benennt die gemeinsame Anleitung von CISA, NSA und internationalen Partnern zur Erkennung und Eindämmung von Active-Directory-Kompromittierungen immer wieder: Unauthentifizierte Verzeichnis-Enumeration ist ein Standard-Aufklärungsschritt vor der eigentlichen Kompromittierung, weil er einem Angreifer die Benutzerliste, Gruppenmitgliedschaften und OU-Struktur der Domäne in die Hand gibt, bevor auch nur ein einziger Authentifizierungsversuch stattfindet – und bevor ein einziger Alert für fehlgeschlagene Anmeldungen einen Grund hat, auszulösen. Öffentliche Tools, die genau dafür gebaut wurden, etwa Windapsearch, setzen exakt dieses Szenario voraus: gegen einen Domänencontroller ohne Zugangsdaten richten und sehen, was eine anonyme Bindung preisgibt, bevor man auch nur ein einziges Passwort rät.

Exposition mit einem direkten Bind-Test bestätigen

Der direkte Weg, die Exposition zu bestätigen, ist der Test selbst:

# Kein -D (Bind-DN) und kein -w (Passwort) => anonyme einfache Bindung
ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" \
  "(objectClass=user)" sAMAccountName

Liefert dieser Befehl Benutzerobjekte statt einer Fehlermeldung zu unzureichenden Rechten, ist anonymer LDAP-Zugriff auf diesem Domänencontroller aktiviert.

Erkennung

Das direkte Auslesen des Attributs ist die zuverlässigste Prüfung, da sie nicht davon abhängt, ob irgendwo Audit-Protokollierung aktiviert ist. Der Bind-Test ist die zweitzuverlässigste Methode, weil er zeigt, was ein Client tatsächlich erlebt, statt was die Konfiguration behauptet. Die Ereignisprotokoll-Signale sind ergänzend, nicht primär: Sie helfen zu bestätigen, dass die Exposition genutzt wurde, nicht nur, dass sie vorhanden war.

Ist die Audit-Protokollierung für diese Kategorien auf Ihren Domänencontrollern noch nicht aktiviert, ist das eine Voraussetzungslücke, die es zuerst zu schließen lohnt – siehe Active Directory Auditrichtlinien-Konfigurationsluecken für die Kategorien, die die meisten Umgebungen ausgeschaltet lassen, bevor sie die Protokolle je brauchen.

Behebung

Schritt 1 – Erst lesen, dann schreiben

Notieren Sie zunächst den vollständigen, bestehenden dsHeuristics-String – ihn blind zu ändern riskiert, eine unabhängige Heuristik umzukippen, von der eine andere Anwendung oder ein anderer Prozess möglicherweise abhängt.

Schritt 2 – Das siebte (und achte) Zeichen korrigieren

Setzen Sie das siebte Zeichen auf 0 (oder lassen Sie es ganz weg, wenn es das letzte Zeichen ist), um die Standard-Sperre anonymer Operationen wiederherzustellen. Die Änderung repliziert auf jeden Domänencontroller im Forest und wirkt ohne Neustart. Prüfen Sie dabei auch das achte Zeichen (fAllowAnonNSPI) und setzen Sie es zurück, sofern keine dokumentierte Legacy-Abhängigkeit von Exchange/Outlook-Adressbuch besteht, die tatsächlich anonyme NSPI-Bindungen benötigt. Gehen Sie nicht davon aus, dass RestrictAnonymous bereits eines der beiden abdeckt – es ist eine andere Kontrolle für einen anderen Protokollpfad, also prüfen Sie dsHeuristics unabhängig, selbst in Umgebungen, die sich bereits für gehärtet halten.

Schritt 3 – Erneut testen

Führen Sie denselben anonymen ldapsearch-/ldp.exe-Bindungstest erneut aus, der zur Erkennung diente. Er sollte jetzt eine Fehlermeldung zu unzureichenden Rechten liefern, keine Verzeichnisobjekte. Wird anonymer LDAP-Zugriff für eine bestimmte Legacy-Anwendung tatsächlich benötigt, grenzen Sie ihn auf Netzwerkebene ein (eine Firewall-Regel zur spezifischen Quelle), statt den forest-weiten dsHeuristics-Wert für jeden unauthentifizierten Client offen zu lassen.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec liest das Attribut dsHeuristics direkt aus dem Configuration-Namenskontext und meldet zwei zusammenhängende Prüfungen: ANONYMOUS_LDAP_ACCESS, wenn bestätigt ist, dass anonyme LDAP-Operationen erreichbar sind, und DS_HEURISTICS_LDAP_SECURITY, wenn das Attribut selbst auf einen Wert gesetzt ist, der die LDAP-Sicherheit schwächt – sodass die Fehlkonfiguration an der Quelle erkannt wird, statt erst, wenn Enumerationsverkehr in den Protokollen auftaucht. Für einen breiteren Überblick über die Einstellungen, die die meisten Umgebungen zuerst prüfen sollten, siehe Active Directory haerten: Was Sie zuerst absichern und wie Sie es validieren und Welche Sicherheitsfehlkonfigurationen in Active Directory sind am haeufigsten?