Nahezu jede AD-Sicherheitsbewertung, jeder Penetrationstest oder jede Diskussion über die Architektur endet mit der Empfehlung, für Ihr Active Directory (AD) „von ungesichertem LDAP auf LDAPS umzusteigen“. Da ich für einen Softwareanbieter arbeite, dessen Produkte „mit AD arbeiten“, werde ich mehrmals pro Woche gefragt: „Unterstützt Ihr Produkt XY LDAPS? Falls nicht, ist dies in Planung?“ In den meisten Fällen lautet die richtige Antwort: „Nein, und das ist auch kein Sicherheitsproblem.“ Betrachten wir die Gründe für diese Antwort.
Was ist das Problem mit LDAPS?
Im Internet finden sich Tausende von Artikeln, Blogs und Videos dazu, wie Sie TLS-Zertifikate erstellen und in Ihre Domänencontroller (DCs) importieren können, damit diese LDAP über TLS auf Port 636/TCP bereitstellen. Weitere Informationen zu der Methode, mit der DCs ihr LDAPS-Zertifikat auswählen, wenn mehrere Kandidaten vorhanden sind, finden Sie in diesem Beitrag von Marc-André Moreau bei AwakeCoding. Zusammenfassend erklärt Moreau Folgendes:
Die Aktivierung und Durchsetzung von LDAPS ist heutzutage eine gängige Maßnahme zur Verbesserung der Sicherheit in Windows Active Directory-Umgebungen. Theoretisch erscheint dies sehr vorteilhaft, bis man feststellt, dass man nicht nur das zu verwendende LDAPS-Zertifikat nicht explizit auswählen kann, sondern dass es auch keine Protokolle gibt, die aktiviert werden können, und keine Möglichkeit, das Problem zu diagnostizieren.
Was in diesen Artikeln zum Thema „LDAPS implementieren“ in der Regel nicht erwähnt wird, ist, wie Sie mit LDAPS nach der Aktivierung umgehen sollten. Eines ist jedoch sicher: Ihre DCs werden weiterhin TLS-loses LDAP auf Port 389 bereitstellen, und Sie können es nicht deaktivieren oder in der Firewall blockieren, ohne Ihre AD-Mitglieder erheblich zu beeinträchtigen.
Ich wiederhole: Ein AD-Mitglied verwendet für alle LDAP/GC-Abfragen, die es aufgrund seiner Eigenschaft als AD-Mitglied durchführen muss, immer Port 389/3268. Es gibt keine Möglichkeit, dieses Verhalten zu ändern oder einen Mitgliedscomputer dazu zu veranlassen, das TLS-gestützte LDAPS auf Port 636/3269 zu verwenden. Es gibt auch keine standardisierte, allgemein zuverlässige Methode, um die Infrastruktur dazu zu veranlassen, LDAPS für Anwendungen zu bewerben.
Warum LDAPS-Workarounds nicht funktionieren
Da der einzige bekannte Mechanismus für die LDAP-Dienstermittlung DNS ist, wurden verschiedene Techniken erprobt:
- Fügen Sie einen SRV-Eintrag für LDAPS hinzu, beispielsweise _ldaps._tcp.domain.com, zusammen mit _ldap und _gc.
- Ändern Sie die Portnummer in den LDAP-Dienstdatensätzen von 389 auf 636 (und verhindern Sie, dass sie von DCs aktualisiert werden).
- Ersetzen Sie die _ldap -SRV-Einträge durch _ldaps (d. h. löschen Sie die _ldap- und _gc- Einträge).
Das Problem bei diesen Ansätzen ist, dass sie nicht funktionieren.
Das Hinzufügen eines SRV-Eintrags für LDAPS hat keine Auswirkungen.
Da _ldaps kein Standarddienst ist, wird keine Anwendung im DNS danach suchen. Wenn Sie eine Anwendung erstellen, die von LDAP über TLS profitieren würde, können Sie die LDAPS-Dienstermittlung gerne in Ihrem Code implementieren; sie funktioniert dann wie jede benutzerdefinierte Dienstermittlung. Es handelt sich jedoch nicht um einen Industriestandard und es wird auch nie einer werden, sodass keine andere Anwendung davon Gebrauch machen wird.
Das Ändern der Portnummer ist nicht möglich.
Die Änderung der Portnummer beeinträchtigt die Kommunikation der AD-Mitglieder nicht, da Port 389 in Windows fest codiert ist. Diese Maßnahme kann jedoch andere LDAP-basierte Anwendungen beeinträchtigen, da die Umstellung des Ports von 389 auf 636 nicht dazu führt, dass diese versuchen, vor dem LDAP-Bind einen TLS-Handshake herzustellen.
Löschen von _ldap- und _gc-Einträgen = Bitte nicht durchführen.
Der dritte Ansatz ist eine hervorragende Methode, um die Dienstermittlung für LDAP zu unterbrechen, einschließlich derjenigen von Domänenmitgliedern. Bitte wenden Sie diese Methode nicht zu Hause (oder am Arbeitsplatz … oder an irgendeinem anderen Ort) an.
Einfache Bindungen im Vergleich zu SASL-Bindungen
Ist LDAP in Active Directory also „von Grund auf unsicher“? Ganz im Gegenteil.
Der Grund, warum Ihnen empfohlen wurde, zu LDAPS zu wechseln, ist der Schutz der Klartext-Anmeldedaten, die LDAP bei einer einfachen Bindung verwendet . AD-Mitglieder – und die meisten Anwendungen, die über LDAP auf AD zugreifen – verwenden jedoch keine einfachen Bindungen. Stattdessen verwenden sie SASL-Bindungen, bei denen die Authentifizierung durch GSS-SPNEGO erfolgt und die LDAP-Verschlüsselungsebene mit Sitzungsschlüsseln ausgehandelt wird, die während des Authentifizierungsprozesses ausgetauscht werden.
Es müssen also nicht nur keine Klartext-Anmeldedaten geschützt werden, sondern die Kommunikation ist tatsächlich bereits verschlüsselt, ohne dass Zertifikate für die TLS-Schicht erforderlich sind. Dieser Mechanismus ist nicht auf Domänenmitglieder beschränkt. Jede Anwendung kann dies tun, unabhängig vom Betriebssystem und der Domänenmitgliedschaft.
Was sollten Sie unternehmen, um AD LDAP zu sichern, wenn Sie Port 389 nicht blockieren?
Wenn Sie sicher sind, dass keine Anwendung in Ihrer Umgebung tatsächlich einfache Bindungen mit Klartext-Anmeldedaten benötigt, setzen Sie die LDAP-Signierung auf Ihren DCs durch, indem Sie die Gruppenrichtlinie wie hier beschrieben festlegen. Zusätzlich zur Signierung der Kommunikation, wodurch eine Vielzahl von Kerberos- und NTLM-Relay-Angriffen verhindert wird, lehnen die DCs auch eine einfache Bindung über eine unverschlüsselte LDAP-Verbindung ab.
Um sicherzustellen, dass Sie keine Störungen verursachen, empfehlen wir Ihnen, die Ereignisprotokolle Ihrer DCs zu beobachten, wie in diesem zeitlosen Learn-Artikel über LDAP-Signierung, Channel Binding und LDAPS beschrieben.
Sollten Sie Anwendungen haben, die eine einfache Bindung erfordern, stellen Sie bitte sicher, dass diese Anwendungen Port 636/3269 verwenden, indem Sie dieses Verhalten (und das Vertrauen in die LDAPS-Zertifikate) innerhalb der Anwendungen selbst konfigurieren.
[Anmerkung der Redaktion: Dieser Blogbeitrag wurde aus dem Originalbeitrag des Autors adaptiert.]
