Access management

Latest — Jun 17, 2026

Was ist LDAP: Ist es 2026 noch relevant?

LDAP (Lightweight Directory Access Protocol) ist ein Client-Server-Protokoll zum Lesen und Schreiben von Verzeichnisdiensten über ein Netzwerk. Definiert in RFC 4511, bietet es Anwendungen eine standardisierte Möglichkeit, ein Verzeichnis abzufragen — mit Fragen wie „Existiert dieser Benutzer?", „Zu welchen Gruppen gehört er?" und „Auf welche Ressourcen hat er Zugriff?"

Obwohl LDAP erstmals Anfang der 1990er Jahre standardisiert wurde, bleibt es auch 2026 das Rückgrat der Unternehmens-Identitätsinfrastruktur. Active Directory, das auf LDAP basiert, ist nach wie vor bei etwa 90 % der Organisationen weltweit im Einsatz.

Wichtigste Erkenntnisse

LDAP ist ein Protokoll. Es definiert, wie Anwendungen ein Verzeichnis abfragen — Benutzerkonten, Gruppenmitgliedschaften, Zugriffsrechte. Active Directory implementiert es, aber LDAP läuft unabhängig auf OpenLDAP und anderen Servern ohne jegliche Microsoft-Software.
AD kann ohne LDAP nicht funktionieren. Jedes Nicht-Windows-System, das sich gegen Active Directory authentifiziert, tut dies über LDAP. Ohne LDAP verliert AD die Fähigkeit, Drittanbieteranwendungen, Netzwerkgeräte und Linux-Infrastruktur zu bedienen.
Port 389 ist in Produktionsumgebungen nicht akzeptabel. Standard-LDAP überträgt Anmeldedaten im Klartext. LDAPS auf Port 636 verschlüsselt die gesamte Sitzung. Microsoft setzt seit 2020 Anforderungen für Signierung und Channel Binding durch.
Zwei kritische Schwachstellen wurden 2025 gepatcht. CVE-2025-26663 ermöglicht nicht authentifizierte Remote-Code-Ausführung auf Domänencontrollern durch einen Speicherfehler im Windows-LDAP-Dienst. CVE-2025-54918 umgeht Channel-Binding- und Signierungsschutz durch NTLM-Relay. Für beide gibt es Patches — ungepatchte Domänencontroller haben höchste Priorität bei der Behebung.
LDAP und moderne Protokolle sind keine Alternativen. SAML übernimmt browserbasiertes SSO. OAuth übernimmt API-Autorisierung. LDAP übernimmt Verzeichnisabfragen für Systeme, die keines von beiden sprechen. Die meisten Unternehmensumgebungen betreiben alle drei gleichzeitig.
Manuelle Zugriffsverwaltung schafft Lücken. Wenn AD-Gruppenänderungen nicht automatisch an abhängige Systeme weitergegeben werden, bleiben Konten länger aktiv als sie sollten. Die Synchronisierung des Anmeldedatenzugriffs mit der Verzeichnis-Gruppenmitgliedschaft eliminiert diese Verzögerung.

LDAP verstehen: Die Grundlagen

LDAP ist ein Standardprotokoll für den Zugriff auf und die Verwaltung von verteilten Verzeichnisinformationsdiensten. Es arbeitet mit einem hierarchischen Datenmodell, das vom X.500-Standard abgeleitet ist, und ermöglicht Clients die Authentifizierung von Benutzern, das Nachschlagen von Attributen und das Abrufen von Gruppenmitgliedschaften aus einem zentralen Verzeichnis. Organisationen nutzen es, um eine grundlegende Frage im großen Maßstab zu beantworten: Wer darf was tun und wo?

Die Daten, die LDAP organisiert, befinden sich in einem Directory Information Tree (DIT) — einer hierarchischen Struktur von Einträgen, die jeweils durch einen Distinguished name (DN) identifiziert werden. Ein typischer DN sieht so aus:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Jeder Eintrag enthält Attribute: Ein Benutzereintrag könnte mail, uid, memberOf und userPassword enthalten. Anwendungen fragen diese Attribute ab, um Authentifizierungs- und Autorisierungsentscheidungen zu treffen.

Wie funktioniert LDAP? (Client-Server-Modell)

Ein LDAP-Client sendet eine Anfrage an einen LDAP-Server (genannt Directory System Agent oder DSA). Der Server verarbeitet die Operation gegen seine Verzeichnisdatenbank und gibt eine Antwort zurück. Die in RFC 4511 definierten Kernoperationen umfassen:

Bind — authentifiziert einen Client beim Verzeichnis
Search — fragt Einträge ab, die einem Filter entsprechen
Compare — prüft, ob ein Eintrag einen bestimmten Attributwert hat
Modify / Add / Delete — Schreiboperationen auf Verzeichniseinträgen
Unbind — beendet die Sitzung

Die Bind-Operation ist der Ort, an dem die Authentifizierung stattfindet. Ein Client sendet einen DN und Anmeldedaten. Der Server validiert diese und gewährt oder verweigert die Sitzung. Die meisten Unternehmensanwendungen verwenden LDAP-Bind, um die Benutzeridentität vor der Gewährung des Zugriffs zu überprüfen.

LDAP-Port 389 vs. LDAPS-Port 636

Standard-LDAP läuft auf TCP-Port 389 und überträgt Daten im Klartext. Das bedeutet, dass Anmeldedaten, einschließlich Passwörter, unverschlüsselt über das Netzwerk übertragen werden. In jeder Umgebung, in der Netzwerkverkehr abgefangen werden könnte (was jede Umgebung ist), ist dies inakzeptabel.

LDAPS (LDAP über SSL/TLS) läuft auf TCP-Port 636 und umhüllt die gesamte LDAP-Sitzung mit TLS, wodurch der gesamte Datenverkehr einschließlich der Bind-Anmeldedaten verschlüsselt wird. Eine dritte Option, StartTLS, aktualisiert eine bestehende Port-389-Verbindung mitten in der Sitzung auf TLS, führt jedoch zu Verhandlungskomplexität und ist fehleranfälliger bei der korrekten Konfiguration.

	LDAP (Port 389)	LDAPS (Port 636)
Transport	Klartext-TCP	TLS-verschlüsseltes TCP
Anmeldedaten bei Übertragung	Exponiert	Verschlüsselt
Zertifikat erforderlich	Nein	Ja
Anfällig für MITM	Ja	Nein (mit gültigem Zertifikat)
NTLM-Relay-Risiko	Hoch	Reduziert (mit Channel Binding)
Microsoft-Durchsetzung	Für Produktion veraltet	Erforderlich (ADV190023)
Einsatz in Produktion	Nein	Ja
StartTLS-Alternative	Port 389 + STARTTLS-Upgrade	N/A

Microsoft schreibt seit 2020 schrittweise LDAP-Channel-Binding und LDAP-Signierung vor, wobei die Durchsetzung in nachfolgenden Windows-Server-Updates verschärft wurde. Unverschlüsseltes LDAP auf Port 389 in der Produktion zu betreiben, ist eine Sicherheitslücke. Port 636 ist die korrekte Standardeinstellung.

Was ist TCP-Port 389?

TCP-Port 389 — der standardmäßige unverschlüsselte Port für LDAP-Kommunikation (Lightweight Directory Access Protocol). Er ermöglicht Verzeichnisdiensten das Abfragen und Verwalten von Benutzerinformationen, Authentifizierungsdaten und Organisationsdaten auf LDAP-Servern ohne Verschlüsselung. Häufig in Unternehmensumgebungen für Verzeichnisabfragen verwendet, überträgt aber Daten im Klartext, was ihn weniger sicher als verschlüsselte Alternativen macht.

Was ist TCP-Port 636?

TCP-Port 636 — der Standardport für LDAPS (LDAP über SSL/TLS), also LDAP-Kommunikation, die mit SSL/TLS-Sicherheitsprotokollen verschlüsselt ist. Er bietet sichere, verschlüsselte Verbindungen für Verzeichnisdienstabfragen und Authentifizierung und schützt sensible Daten vor Abfangen. Dieser Port wird in sicherheitsbewussten Umgebungen gegenüber Port 389 bevorzugt und wird häufig in Unternehmensverzeichnisdiensten wie Active Directory verwendet.

Was ist SSL/TLS?

SSL/TLS (Secure Sockets Layer / Transport Layer Security) — kryptografische Protokolle, die sichere, verschlüsselte Verbindungen zwischen Clients und Servern über Netzwerke herstellen. SSL ist das ältere Protokoll (inzwischen veraltet), während TLS sein moderner Nachfolger ist. Sie bieten Authentifizierung, Verschlüsselung und Datenintegrität für sensible Kommunikation wie HTTPS, E-Mail und Verzeichnisdienste. TLS verwendet digitale Zertifikate zur Verifizierung der Serveridentität und verschlüsselt alle übertragenen Daten, um Abhören zu verhindern.

Was ist StartTLS?

StartTLS — eine Protokollerweiterung, die eine bestehende unverschlüsselte Verbindung auf eine verschlüsselte unter Verwendung von TLS-Verschlüsselung aktualisiert. Anstatt einen separaten sicheren Port zu erfordern, ermöglicht StartTLS einem Client, sich über einen Standardport (wie LDAP-Port 389 oder SMTP-Port 25) zu verbinden und dann einen STARTTLS-Befehl zu senden, um die Verbindung auf Verschlüsselung umzustellen. Dies bietet Flexibilität durch Unterstützung von verschlüsselten und unverschlüsselten Modi auf demselben Port, erfordert jedoch Serverunterstützung und ist weniger sicher als dedizierte verschlüsselte Ports wie LDAPS (Port 636).

LDAP vs. Active Directory: Was ist der Unterschied?

Active Directory (AD) ist kein Ersatz für LDAP — es ist ein Verzeichnisdienst, der LDAP als eines seiner Zugriffsprotokolle verwendet. Die Verwechslung beider ist eines der häufigsten Missverständnisse in der Unternehmens-IT. Die Abhängigkeit besteht nur in eine Richtung: LDAP steht für sich allein, AD nicht.

Kann LDAP ohne AD betrieben werden?

Ja. LDAP ist ein Protokoll — es definiert, wie ein Client einen Verzeichnisserver nach Informationen fragt und wie dieser Server antwortet. Es kann unabhängig von jeglicher Microsoft-Software eingesetzt werden.

OpenLDAP ist die am weitesten verbreitete Open-Source-Implementierung. 389 Directory Server und Apache Directory Server sind gängige Alternativen. Diese eigenständigen Server speichern Benutzeridentitäten und Gruppenmitgliedschaften und stellen sie Linux/Unix-Systemen, Mailservern und benutzerdefinierten Anwendungen zur Verfügung.

Kann AD ohne LDAP betrieben werden?

Nein. Active Directory ist ein vollständiger Verzeichnisdienst, der von Microsoft auf Basis des X.500-Datenmodells entwickelt wurde. Domänencontroller verwenden LDAP intern zum Lesen, Schreiben und Replizieren von Verzeichnisdaten: Benutzer, Computer, Gruppenrichtlinien. Jede Drittanbieteranwendung oder Nicht-Windows-Maschine, die sich gegen AD authentifiziert, tut dies über LDAP.

Ohne LDAP kann AD nicht mit dem Rest Ihrer Infrastruktur kommunizieren.

Wie sie in der Praxis zusammenhängen

Typ	LDAP	Active Directory
Typ	Offenes Protokoll (RFC 4511)	Proprietärer Verzeichnisdienst
Anbieter	IETF-Standard	Microsoft
Primäre Authentifizierungsmethode	Simple Bind, SASL	Kerberos (Windows), LDAP-Bind (alles andere)
Plattform	Plattformübergreifend	Windows Server
Läuft unabhängig	Ja	Nein — erfordert LDAP
Gängige Implementierungen	OpenLDAP, 389 Directory Server, Apache DS	Active Directory Domain Services

Wenn sich ein Linux-Server gegen Active Directory authentifiziert, spricht er LDAP. Wenn sich eine Windows-Workstation anmeldet, verwendet sie Kerberos. AD unterstützt beides — aber LDAP ist das, was AD für den Rest Ihrer Infrastruktur zugänglich macht.

Moderne Alternativen: LDAP vs. SAML, OAuth und OpenID Connect

LDAP wurde für die interne Netzwerkauthentifizierung konzipiert — das Abfragen eines Verzeichnisses innerhalb eines Unternehmensperimeters. Die Protokolle, die ihm folgten, wurden für eine andere Welt entwickelt: föderierte Identität über Organisationsgrenzen hinweg, Webanwendungen und mobile Clients.

Protokoll	Primärer Anwendungsfall	Transport	Anmeldedaten-Exponierung
LDAP	Interne Verzeichnisabfragen	TCP (Port 389/636)	Anmeldedaten werden an Server gesendet
SAML	Föderiertes SSO (Unternehmens-Webanwendungen)	HTTP/XML	Anmeldedaten bleiben beim IdP
OAuth 2.0	Delegierte Autorisierung (API-Zugriff)	HTTPS	Keine Anmeldedaten ausgetauscht
OpenID Connect	Föderierte Authentifizierung auf Basis von OAuth	HTTPS	Keine Anmeldedaten ausgetauscht

Diese Protokolle ersetzen LDAP nicht — sie arbeiten auf einer anderen Ebene. SAML und OpenID Connect übernehmen browserbasiertes SSO. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle gleichzeitig.

Ist LDAP 2026 noch relevant? (Die Hybrid-Cloud-Realität)

LDAP ist nach wie vor das dominierende Unternehmens-Authentifizierungsprotokoll, das durch Active-Directory-Implementierungen bei etwa 90 % der Organisationen weltweit präsent ist. Die Cloud-Adoption hat daran nichts geändert.

Die meisten Unternehmen sind nicht vollständig cloud-nativ. Sie betreiben ein Hybridmodell: einige Workloads in Azure oder AWS, andere vor Ort, mit Active Directory als Identitätsanker für beide. Microsoft Entra ID (ehemals Azure AD) verbindet sich über Synchronisation mit dem lokalen AD, aber das lokale AD (und damit LDAP) bleibt für viele Identitätsentscheidungen die maßgebliche Quelle.

Die Rolle von LDAP in der Zero-Trust-Architektur

Zero Trust erfordert kontinuierliche Verifizierung: Jede Zugriffsanfrage muss authentifiziert und autorisiert werden, unabhängig vom Netzwerkstandort. LDAP sitzt an einem kritischen Knotenpunkt in diesem Modell, da es oft das System ist, das diese Verifizierungsanfragen beantwortet.

Die Herausforderung besteht darin, dass LDAP nicht mit Zero-Trust-Prinzipien im Sinn entwickelt wurde. Es setzt Netzwerknähe voraus, verwendet persistente Verbindungen und exponiert in seiner unverschlüsselten Form Anmeldedaten bei der Übertragung. Die Einbindung von LDAP in eine Zero-Trust-Architektur erfordert kompensierende Kontrollen:

Obligatorisches LDAPS
Strikte Firewall-Regeln
Einschränkung, welche Systeme Port 636 erreichen können
Durchsetzung der LDAP-Signierung
Überwachung von Bind-Versuchen auf anomale Muster

LDAP bricht Zero Trust nicht, erfordert aber gezielte Härtung, um es zu unterstützen. Organisationen, die LDAP als Legacy-Komponente behandeln und es unkonfiguriert lassen, schaffen genau die Art von implizitem Vertrauen, das Zero Trust beseitigen soll.

DevOps und CI/CD-Secrets-Management

Automatisierte Pipelines stellen eine spezifische LDAP-Herausforderung dar. CI/CD-Systeme (Jenkins, GitLab CI, GitHub Actions Runner) müssen sich oft gegen LDAP authentifizieren, um auf interne Ressourcen zuzugreifen. Diese Authentifizierung umfasst typischerweise ein Dienstkonto: einen dedizierten LDAP-Bind-DN mit einem statischen Passwort.

Statische Dienstkonto-Anmeldedaten sind ein anhaltendes Risiko. Sie werden selten rotiert, werden oft über Pipelines hinweg gemeinsam genutzt, und wenn sie in Build-Logs oder Konfigurationsdateien erscheinen, sind sie schwer zu erkennen und zu widerrufen. Die Lösung besteht darin, diese Anmeldedaten über einen dedizierten Secrets-Manager zu verwalten, anstatt sie in der Pipeline-Konfiguration hart zu kodieren.

Die CLI-Tools und REST API von Passwork ermöglichen es DevOps-Teams, Dienstkonto-Anmeldedaten zur Laufzeit abzurufen, anstatt sie in Pipeline-Konfigurationen zu speichern. Berechtigungen werden von AD-Gruppen geerbt, sodass der Zugriff ohne manuellen Eingriff mit Ihrem Verzeichnis synchronisiert bleibt. Starten Sie noch heute Ihre kostenlose Testversion und testen Sie es in Ihrer Infrastruktur

Kritische LDAP-Sicherheitsrisiken 2026

LDAP ist nicht nur ein Legacy-Protokoll mit theoretischen Risiken. Es ist eine aktive Angriffsfläche mit dokumentierten, ausgenutzten Schwachstellen.

Die Bedrohung durch Anmeldedatendiebstahl und Ransomware

Laut dem X-Force Threat Intelligence Index 2026 von IBM war das Abgreifen von Anmeldedaten die häufigste Angriffsauswirkung, die 2025 beobachtet wurde. Bedrohungsakteure sammelten Anmeldedaten durch Phishing und Infostealer und fügten sich dann in normale Authentifizierungsströme ein, um sich lateral zu bewegen. LDAP-Dienstkonto-Anmeldedaten passen genau in dieses Muster: anwendungsübergreifend wiederverwendet, selten rotiert und fast nie auf anomale Bind-Aktivitäten überwacht.

Die Angriffskette ist gut dokumentiert: Kompromittierung einer LDAP-Anmeldedaten durch Phishing oder Password Spraying, Nutzung zur Aufzählung des Verzeichnisses, Identifizierung privilegierter Konten und Eskalation. Der Digital Defense Report von Microsoft hat durchgängig die Kompromittierung von AD/LDAP-Anmeldedaten mit Ransomware-Bereitstellung in Verbindung gebracht. Das Verzeichnis ist eine Karte der gesamten Zugriffsstruktur einer Organisation, und Angreifer lesen sie, bevor sie handeln.

Aktuelle Schwachstellen: CVE-2025-26663 und CVE-2025-54918

Zwei kritische Schwachstellen, die 2025 offengelegt wurden, zeigen, dass die Angriffsfläche von LDAP aktiv wächst.

CVE-2025-26663 ist eine Use-after-free-Schwachstelle für Remote-Code-Ausführung in Windows LDAP, die im April 2025 offengelegt wurde. Ein Angreifer kann einen Speicherverwaltungsfehler im Windows-LDAP-Dienst (speziell in wldap32.dll) ausnutzen, um beliebigen Code auf einem Zielserver ohne gültige Anmeldedaten auszuführen.

Der Angriff erfordert nur Netzwerkzugriff auf den LDAP-Dienst. Domänencontroller, die LDAP naturgemäß exponieren, sind die Hauptziele. Ungepatchte Domänencontroller mit dieser Schwachstelle sind praktisch offen für nicht authentifizierte Remote-Code-Ausführung (RCE) von jedem System, das Port 389 oder 636 erreichen kann.

CVE-2025-54918, offengelegt im September 2025, ist eine Privilegieneskalations-Schwachstelle, die NT LAN Manager Relay mit erzwungener Authentifizierung kombiniert, um LDAP-Channel-Binding- und Signierungsschutz zu umgehen. Ein Angreifer mit einem niedrig privilegierten Domänenkonto kann einen Domänencontroller zwingen, sich bei einem vom Angreifer kontrollierten System zu authentifizieren, die NTLM-Authentifizierungspakete während der Übertragung manipulieren und die modifizierte Authentifizierung zurück an den Domänencontroller weiterleiten — und so SYSTEM-Level-Zugriff erlangen. Der Angriff ist besonders gefährlich, weil er Kontrollen umgeht, auf die sich Organisationen üblicherweise als Härtungsmaßnahmen verlassen.

⚠️

Für beide Schwachstellen sind Patches verfügbar. Wenn Ihre Domänencontroller die Sicherheitsupdates vom April 2025 und nachfolgende Windows-Updates nicht erhalten haben, hat das Patchen unmittelbare Priorität.

Best Practices zur Absicherung von LDAP im Unternehmen

Die folgende Checkliste umfasst die Mindestkontrollen für eine LDAP-Produktionsbereitstellung. Dies sind Empfehlungen, die einen spezifischen, dokumentierten Angriffsvektor adressieren.

LDAPS auf Port 636 durchsetzen. Klartext-LDAP auf Port 389 für den gesamten Produktionsverkehr deaktivieren. TLS-Zertifikate von Ihrer internen CA oder einer vertrauenswürdigen öffentlichen CA konfigurieren.
LDAP-Signierung und Channel Binding aktivieren. Verhindert Relay-Angriffe. Erforderlich zur Minderung von CVE-2025-54918 — wobei zu beachten ist, dass CVE-2025-54918 diese Kontrollen auf ungepatchten Systemen umgeht, sodass das Patchen weiterhin obligatorisch ist.
Alle Windows-Sicherheitsupdates anwenden. Für CVE-2025-26663 und CVE-2025-54918 gibt es Patches. Ungepatchte Domänencontroller sind das Behebungselement mit höchster Priorität.
LDAP-Zugriff nach IP einschränken. Nur Systeme, die legitimerweise LDAP abfragen müssen, sollten Port 636 erreichen können. Firewall-Regeln sollten dies durchsetzen, nicht nur Annahmen zur Netzwerksegmentierung.
Dienstkonto-Anmeldedaten auditieren. Jeden Bind-DN identifizieren, der in Ihrer Umgebung verwendet wird. Passwörter nach einem Zeitplan rotieren. Konten entfernen, die nicht mehr benötigt werden.
Bind-Versuche überwachen. Ungewöhnliche Bind-Muster — wiederholte Fehlschläge, Binds von unerwarteten Quell-IPs, Binds zu ungewöhnlichen Zeiten — sind frühe Indikatoren für Credential Stuffing oder laterale Bewegung.
Anonyme LDAP-Binds deaktivieren. Anonyme Abfragen ermöglichen nicht authentifizierte Aufzählung von Verzeichnisinhalten. Die meisten modernen Implementierungen haben keine legitime Verwendung für anonyme Binds.
Dienstkonten nach Funktion trennen. Ein Dienstkonto, das von einem VPN verwendet wird, sollte nicht die gleichen Berechtigungen haben wie eines, das von einem Backup-System verwendet wird. Das Prinzip der geringsten Rechte gilt auch für LDAP-Bind-Konten.

Unternehmens-Zugriff mit der Passwork-LDAP-Integration optimieren

Der operative Aufwand der LDAP-basierten Zugriffsverwaltung summiert sich im Laufe der Zeit. Benutzer wechseln Teams, treten Projekten bei und verlassen die Organisation — und jeder Übergang erfordert Zugriffsänderungen über mehrere Systeme hinweg. Wenn diese Änderungen manuell erfolgen, hinken sie hinterher. Konten bleiben länger aktiv als sie sollten. Anmeldedaten sammeln sich an Orten an, die niemand verfolgt.

Passwork verbindet sich direkt mit Active Directory oder jedem LDAP-kompatiblen Verzeichnis und ordnet Gruppenmitgliedschaften automatisch dem Tresor-Zugriff zu:

Fügen Sie einen Benutzer zur SRE-Gruppe in AD hinzu — die korrekten Anmeldedaten erscheinen in seinem Passwork-Tresor, keine separate Admin-Aktion erforderlich
Entfernen Sie ihn aus der Gruppe — der Zugriff wird widerrufen
Das Verzeichnis bleibt die einzige Wahrheitsquelle dafür, wer auf was Zugriff hat

Für selbst gehostete Umgebungen wird Passwork vollständig innerhalb Ihres eigenen Perimeters bereitgestellt. Anmeldedaten verlassen ihn nie. SAML SSO wird neben LDAP unterstützt, sodass Teams, die beide Protokolle für verschiedene Anwendungsebenen verwenden, ihre Identitätsarchitektur nicht neu aufbauen müssen.

Jedes Lesen, Schreiben, Teilen und Exportieren wird im Audit-Log aufgezeichnet — relevant sowohl für interne Sicherheitsüberprüfungen als auch zum Nachweis der Compliance mit SOC 2 CC6.1 und DSGVO Artikel 32.

Fazit

LDAP wird nicht verschwinden. Der Markt für Verzeichnissoftware wurde 2025 auf 8,4 Milliarden US-Dollar geschätzt und soll laut der Marktforschung von Dataintelo bis 2034 19,7 Milliarden US-Dollar erreichen — eine Zahl, die fortgesetzte Unternehmensinvestitionen in Verzeichnisinfrastruktur widerspiegelt, nicht eine Technologie im Niedergang. Mit 90 % der Unternehmen, die noch Active Directory betreiben, bleibt LDAP das verbindende Gewebe des Unternehmens-Identitätsmanagements.

Was sich geändert hat, ist die Bedrohungsumgebung. CVE-2025-26663 und CVE-2025-54918 sind aktiv gepatchte Schwachstellen, die auf die LDAP-Dienste abzielen, die Ihre Domänencontroller gerade jetzt exponieren.

Die praktische Maßnahme ist einfach: LDAPS durchsetzen, Ihre Domänencontroller patchen, Ihre Dienstkonto-Anmeldedaten auditieren und sicherstellen, dass Zugriffsänderungen in Ihrem Verzeichnis automatisch an die Systeme weitergegeben werden, die davon abhängen. Manuelle Zugriffsverwaltung im Maßstab, in dem die meisten Unternehmen operieren, ist dort, wo Lücken entstehen.

Passwork integriert sich mit Active Directory und LDAP, um den Anmeldedatenzugriff mit Ihren Verzeichnisgruppen synchronisiert zu halten — automatisch, ohne benutzerdefinierte Skripte. Selbst gehostet, AES-256-verschlüsselt, ISO 27001, mit vollständigem Audit-Trail. Testen Sie es in Ihrer Infrastruktur

Häufig gestellte Fragen zu LDAP

Wofür wird LDAP verwendet?

LDAP wird zur Authentifizierung von Benutzern und zum Nachschlagen von Verzeichnisinformationen verwendet — Gruppenmitgliedschaften, E-Mail-Adressen, Kontoattribute — über Unternehmensanwendungen hinweg. Häufige Anwendungsfälle umfassen VPN-Authentifizierung, Mailserver-Benutzerabfrage, Anwendungs-SSO und zentralisierte Benutzerverwaltung. Die meisten Unternehmensanwendungen, die eine Identität gegen ein Unternehmensverzeichnis verifizieren müssen, verwenden LDAP.

Was ist der Unterschied zwischen LDAP und Active Directory?

LDAP ist ein offenes Protokoll (RFC 4511) für den Zugriff auf Verzeichnisdienste. Active Directory ist der Verzeichnisdienst von Microsoft, der LDAP als eines seiner Zugriffsprotokolle verwendet. AD verwendet auch Kerberos für die Windows-Authentifizierung. LDAP kann ohne Active Directory verwendet werden (z. B. über OpenLDAP), aber Active Directory ist auf LDAP angewiesen, um Verzeichnisabfragen an Nicht-Windows-Anwendungen zu bedienen.

Was ist LDAPS und warum ist es wichtig?

LDAPS ist LDAP über TLS, läuft auf Port 636. Standard-LDAP auf Port 389 überträgt Anmeldedaten im Klartext, wodurch sie für jeden sichtbar sind, der Netzwerkverkehr abfangen kann. LDAPS verschlüsselt die gesamte Sitzung. Im Jahr 2026 ist das Betreiben von unverschlüsseltem LDAP in der Produktion nicht vertretbar — Microsoft setzt seit 2020 Anforderungen für LDAP-Signierung und Channel Binding durch, und sowohl CVE-2025-26663 als auch CVE-2025-54918 zielen direkt auf LDAP-Dienste ab.

Wird LDAP 2026 noch verwendet?

Ja. Active Directory, das auf LDAP angewiesen ist, wird bei etwa 90 % der Unternehmen weltweit eingesetzt. Die Cloud-Adoption hat dies nicht verdrängt — die meisten Organisationen betreiben Hybridumgebungen, in denen das lokale AD die maßgebliche Identitätsquelle bleibt. LDAP ist auch in Tausenden von Anwendungen eingebettet, die sich gegen Unternehmensverzeichnisse authentifizieren und ohne erhebliche Umgestaltung nicht durch SAML oder OAuth ersetzt werden.

Wie passt LDAP in eine Zero-Trust-Architektur?

LDAP kann Zero Trust unterstützen, wenn es korrekt gehärtet wird. Zero Trust erfordert kontinuierliche Verifizierung jeder Zugriffsanfrage, und LDAP ist oft das System, das diese Anfragen beantwortet. Die Anforderungen: LDAPS durchsetzen (Port 636), Signierung und Channel Binding aktivieren, Verzeichniszugriff nach Quell-IP einschränken, Bind-Versuche überwachen und Dienstkonto-Anmeldedaten regelmäßig rotieren. Die Standardkonfiguration von LDAP ist nicht Zero-Trust-kompatibel — aber das Protokoll selbst ist nicht das Hindernis.

Was sind die wichtigsten Sicherheitsrisiken bei LDAP?

Die primären Risiken sind die Exponierung von Anmeldedaten über unverschlüsselte Verbindungen (Port 389), Diebstahl von Dienstkonto-Anmeldedaten, NTLM-Relay-Angriffe (CVE-2025-54918) und nicht authentifizierte RCE über Speicherkorruptions-Schwachstellen (CVE-2025-26663). Der X-Force Threat Intelligence Index 2025 von IBM ergab, dass identitätsbasierte Angriffe — viele auf Verzeichnis-Anmeldedaten abzielend — 2024 30 % aller Einbrüche ausmachten. Patchen, LDAPS-Durchsetzung und Dienstkonto-Hygiene adressieren die Mehrheit dieser Risiken.

Kann LDAP durch SAML oder OAuth ersetzt werden?

Nicht vollständig. SAML und OAuth übernehmen browserbasierte föderierte Authentifizierung bzw. API-Autorisierung. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle drei Protokolle für verschiedene Ebenen ihres Anwendungsstacks. Die Frage ist nicht, welches gewählt werden soll — sondern welche Anwendungen LDAP erfordern und ob diese Verbindungen ordnungsgemäß gesichert sind.

Was ist LDAP: Ist es 2026 noch relevant?

LDAP betreibt die Identitätsinfrastruktur bei 90 % der Unternehmen — und ist eine aktive Angriffsfläche. Zwei kritische RCE-Schwachstellen wurden 2025 gepatcht, Credential Harvesting erreicht Rekordniveau. Was zu beheben ist, wie man es härtet und wo das eigentliche Risiko liegt.

Access management

Jun 17, 2026 — 18 min read

Qué es LDAP: ¿sigue siendo relevante en 2026?

LDAP (Lightweight Directory Access Protocol) es un protocolo cliente-servidor para leer y escribir servicios de directorio a través de una red. Definido en RFC 4511, proporciona a las aplicaciones una forma estándar de consultar un directorio — respondiendo preguntas como «¿existe este usuario?», «¿a qué grupos pertenece?» y «¿a qué recursos puede acceder?»

A pesar de haber sido estandarizado por primera vez a principios de los años 90, LDAP sigue siendo la columna vertebral de la infraestructura de identidad empresarial en 2026. Active Directory, que funciona sobre LDAP, todavía está implementado en aproximadamente el 90% de las organizaciones en todo el mundo.

Puntos clave

LDAP es un protocolo. Define cómo las aplicaciones consultan un directorio — cuentas de usuario, membresías de grupos, derechos de acceso. Active Directory lo implementa, pero LDAP funciona de forma independiente en OpenLDAP y otros servidores sin ningún software de Microsoft.
AD no puede funcionar sin LDAP. Cada sistema que no es Windows y que se autentica contra Active Directory lo hace a través de LDAP. Si se elimina, AD pierde la capacidad de servir a aplicaciones de terceros, dispositivos de red e infraestructura Linux.
El puerto 389 no es aceptable en producción. LDAP estándar transmite credenciales en texto plano. LDAPS en el puerto 636 cifra toda la sesión. Microsoft ha estado aplicando requisitos de firma y vinculación de canal desde 2020.
Dos vulnerabilidades críticas fueron parcheadas en 2025. CVE-2025-26663 permite la ejecución remota de código no autenticada en controladores de dominio a través de un fallo de memoria en el servicio LDAP de Windows. CVE-2025-54918 elude las protecciones de vinculación de canal y firma mediante retransmisión NTLM. Ambas tienen parches — los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
LDAP y los protocolos modernos no son alternativas. SAML maneja SSO basado en navegador. OAuth maneja la autorización de API. LDAP maneja las búsquedas de directorio para sistemas que no hablan ninguno de los dos. La mayoría de los entornos empresariales ejecutan los tres simultáneamente.
La gestión manual de accesos crea brechas. Cuando los cambios en grupos de AD no se propagan automáticamente a los sistemas dependientes, las cuentas permanecen activas más tiempo del debido. Sincronizar el acceso a credenciales con la membresía de grupos del directorio elimina ese retraso.

Entendiendo LDAP: Los fundamentos

LDAP es un protocolo estándar para acceder y gestionar servicios de información de directorio distribuidos. Opera en un modelo de datos jerárquico derivado del estándar X.500 y permite a los clientes autenticar usuarios, buscar atributos y recuperar membresías de grupos desde un directorio central. Las organizaciones lo utilizan para responder una pregunta fundamental a escala: ¿quién tiene permitido hacer qué y dónde?

Los datos que LDAP organiza residen en un Árbol de Información de Directorio (DIT) — una estructura jerárquica de entradas, cada una identificada por un Distinguished Name (DN). Un DN típico tiene este aspecto:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Cada entrada contiene atributos: una entrada de usuario puede contener mail, uid, memberOf y userPassword. Las aplicaciones consultan estos atributos para tomar decisiones de autenticación y autorización.

¿Cómo funciona LDAP? (modelo cliente-servidor)

Un cliente LDAP envía una solicitud a un servidor LDAP (llamado Directory System Agent, o DSA). El servidor procesa la operación contra su base de datos de directorio y devuelve una respuesta. Las operaciones principales definidas en RFC 4511 incluyen:

Bind — autenticar un cliente en el directorio
Search — consultar entradas que coincidan con un filtro
Compare — verificar si una entrada tiene un valor de atributo específico
Modify / Add / Delete — operaciones de escritura en entradas del directorio
Unbind — terminar la sesión

La operación bind es donde ocurre la autenticación. Un cliente envía un DN y credenciales. El servidor las valida y concede o deniega la sesión. La mayoría de las aplicaciones empresariales utilizan LDAP bind para verificar la identidad del usuario antes de conceder acceso.

Puerto LDAP 389 vs. puerto LDAPS 636

LDAP estándar funciona en el puerto TCP 389 y transmite datos en texto plano. Esto significa que las credenciales, incluidas las contraseñas, viajan por la red sin cifrar. En cualquier entorno donde el tráfico de red pueda ser interceptado (que es cualquier entorno) esto es inaceptable.

LDAPS (LDAP sobre SSL/TLS) funciona en el puerto TCP 636 y envuelve toda la sesión LDAP en TLS, cifrando todo el tráfico incluyendo las credenciales de bind. Una tercera opción, StartTLS, actualiza una conexión existente del puerto 389 a TLS a mitad de sesión, pero introduce complejidad en la negociación y es más propenso a errores de configuración.

	LDAP (puerto 389)	LDAPS (puerto 636)
Transporte	TCP en texto plano	TCP cifrado con TLS
Credenciales en tránsito	Expuestas	Cifradas
Certificado requerido	No	Sí
Susceptible a MITM	Sí	No (con certificado válido)
Riesgo de retransmisión NTLM	Alto	Reducido (con vinculación de canal)
Aplicación de Microsoft	Obsoleto para producción	Requerido (ADV190023)
Uso en producción	No	Sí
Alternativa StartTLS	Puerto 389 + actualización STARTTLS	N/A

Microsoft ha estado exigiendo progresivamente la vinculación de canal LDAP y la firma LDAP desde 2020, con aplicación reforzada en actualizaciones posteriores de Windows Server. Ejecutar LDAP sin cifrar en el puerto 389 en producción es una brecha de seguridad. El puerto 636 es el valor predeterminado correcto.

¿Qué es el puerto TCP 389?

Puerto TCP 389 — el puerto estándar sin cifrar utilizado para las comunicaciones LDAP (Lightweight Directory Access Protocol). Permite a los servicios de directorio consultar y gestionar información de usuarios, credenciales de autenticación y datos organizacionales en servidores LDAP sin cifrado. Comúnmente utilizado en entornos empresariales para búsquedas de directorio, pero transmite datos en texto plano, lo que lo hace menos seguro que las alternativas cifradas.

¿Qué es el puerto TCP 636?

Puerto TCP 636 — el puerto estándar para LDAPS (LDAP sobre SSL/TLS), que es la comunicación LDAP cifrada con protocolos de seguridad SSL/TLS. Proporciona conexiones seguras y cifradas para consultas de servicios de directorio y autenticación, protegiendo datos sensibles de la interceptación. Este puerto es preferido sobre el puerto 389 en entornos conscientes de la seguridad y se utiliza comúnmente en servicios de directorio empresariales como Active Directory.

¿Qué es SSL/TLS?

SSL/TLS (Secure Sockets Layer / Transport Layer Security) — protocolos criptográficos que establecen conexiones seguras y cifradas entre clientes y servidores a través de redes. SSL es el protocolo más antiguo (ahora obsoleto), mientras que TLS es su sucesor moderno. Proporcionan autenticación, cifrado e integridad de datos para comunicaciones sensibles como HTTPS, correo electrónico y servicios de directorio. TLS utiliza certificados digitales para verificar la identidad del servidor y cifra todos los datos transmitidos para prevenir la interceptación.

¿Qué es StartTLS?

StartTLS — una extensión de protocolo que actualiza una conexión sin cifrar existente a una conexión cifrada utilizando cifrado TLS. En lugar de requerir un puerto seguro separado, StartTLS permite que un cliente se conecte a un puerto estándar (como el puerto LDAP 389 o el puerto SMTP 25) y luego emita un comando STARTTLS para actualizar la conexión a cifrado. Esto proporciona flexibilidad al soportar modos cifrados y sin cifrar en el mismo puerto, aunque requiere soporte del servidor y es menos seguro que los puertos cifrados dedicados como LDAPS (puerto 636).

LDAP vs. Active Directory: ¿Cuál es la diferencia?

Active Directory (AD) no es un reemplazo de LDAP — es un servicio de directorio que utiliza LDAP como uno de sus protocolos de acceso. Confundir los dos es uno de los conceptos erróneos más comunes en TI empresarial. La dependencia solo va en una dirección: LDAP funciona de forma independiente, AD no.

¿Se puede ejecutar LDAP sin AD?

Sí. LDAP es un protocolo — define cómo un cliente solicita información a un servidor de directorio y cómo ese servidor responde. Se puede implementar independientemente de cualquier software de Microsoft.

OpenLDAP es la implementación de código abierto más utilizada. 389 Directory Server y Apache Directory Server son alternativas comunes. Estos servidores independientes almacenan identidades de usuarios y membresías de grupos y los sirven a sistemas Linux/Unix, servidores de correo y aplicaciones personalizadas.

¿Se puede ejecutar AD sin LDAP?

No. Active Directory es un servicio de directorio completo construido por Microsoft sobre el modelo de datos X.500. Los controladores de dominio utilizan LDAP internamente para leer, escribir y replicar datos del directorio: usuarios, equipos, políticas de grupo. Cualquier aplicación de terceros o máquina que no sea Windows que se autentique contra AD lo hace hablando LDAP.

Si se elimina LDAP, AD no puede comunicarse con el resto de la infraestructura.

Cómo se relacionan en la práctica

Tipo	LDAP	Active Directory
Tipo	Protocolo abierto (RFC 4511)	Servicio de directorio propietario
Proveedor	Estándar IETF	Microsoft
Método de autenticación principal	Simple bind, SASL	Kerberos (Windows), LDAP bind (todo lo demás)
Plataforma	Multiplataforma	Windows Server
Funciona de forma independiente	Sí	No — requiere LDAP
Implementaciones comunes	OpenLDAP, 389 Directory Server, Apache DS	Active Directory Domain Services

Cuando un servidor Linux se autentica contra Active Directory, habla LDAP. Cuando una estación de trabajo Windows inicia sesión, utiliza Kerberos. AD soporta ambos — pero LDAP es lo que hace que AD sea accesible para el resto de la infraestructura.

Alternativas modernas: LDAP vs. SAML, OAuth y OpenID Connect

LDAP fue diseñado para la autenticación de red interna — consultar un directorio dentro de un perímetro corporativo. Los protocolos que le siguieron fueron diseñados para un mundo diferente: identidad federada a través de límites organizacionales, aplicaciones web y clientes móviles.

Protocolo	Caso de uso principal	Transporte	Exposición de credenciales
LDAP	Consultas de directorio interno	TCP (puerto 389/636)	Credenciales enviadas al servidor
SAML	SSO federado (aplicaciones web empresariales)	HTTP/XML	Credenciales permanecen en el IdP
OAuth 2.0	Autorización delegada (acceso a API)	HTTPS	No se intercambian credenciales
OpenID Connect	Autenticación federada sobre OAuth	HTTPS	No se intercambian credenciales

Estos protocolos no reemplazan a LDAP — operan en una capa diferente. SAML y OpenID Connect manejan SSO basado en navegador. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan todos ellos simultáneamente.

¿Sigue siendo relevante LDAP en 2026? (la realidad de la nube híbrida)

LDAP sigue siendo el protocolo de autenticación empresarial dominante, presente en aproximadamente el 90% de las organizaciones en todo el mundo a través de sus implementaciones de Active Directory. La adopción de la nube no ha cambiado esto.

La mayoría de las empresas no son completamente nativas de la nube. Ejecutan un modelo híbrido: algunas cargas de trabajo en Azure o AWS, otras en las instalaciones, con Active Directory como ancla de identidad para ambos. Microsoft Entra ID (anteriormente Azure AD) se conecta al AD local a través de sincronización, pero el AD local (y por lo tanto LDAP) sigue siendo la fuente autorizada para muchas decisiones de identidad.

El rol de LDAP en la arquitectura de confianza cero

La confianza cero requiere verificación continua: cada solicitud de acceso debe ser autenticada y autorizada, independientemente de la ubicación en la red. LDAP se encuentra en una intersección crítica en este modelo porque a menudo es el sistema que responde a esas solicitudes de verificación.

El desafío es que LDAP no fue diseñado con los principios de confianza cero en mente. Asume proximidad de red, utiliza conexiones persistentes y en su forma sin cifrar expone credenciales en tránsito. Adaptar LDAP a una arquitectura de confianza cero requiere controles compensatorios:

LDAPS obligatorio
reglas de firewall estrictas
limitar qué sistemas pueden alcanzar el puerto 636
aplicación de firma LDAP
monitorización de intentos de bind para detectar patrones anómalos

LDAP no rompe la confianza cero pero requiere un endurecimiento deliberado para soportarla. Las organizaciones que tratan LDAP como un componente heredado y lo dejan sin configurar están creando exactamente el tipo de confianza implícita que la confianza cero está diseñada para eliminar.

DevOps y gestión de secretos en CI/CD

Los pipelines automatizados presentan un desafío específico de LDAP. Los sistemas CI/CD (Jenkins, GitLab CI, ejecutores de GitHub Actions) a menudo necesitan autenticarse contra LDAP para acceder a recursos internos. Esa autenticación típicamente implica una cuenta de servicio: un DN de bind LDAP dedicado con una contraseña estática.

Las credenciales estáticas de cuentas de servicio son un riesgo persistente. Rara vez se rotan, a menudo se comparten entre pipelines, y cuando aparecen en registros de compilación o archivos de configuración, son difíciles de detectar y revocar. La respuesta es gestionar estas credenciales a través de un gestor de secretos dedicado en lugar de codificarlas en la configuración del pipeline.

Las herramientas CLI y REST API de Passwork permiten a los equipos DevOps obtener credenciales de cuentas de servicio en tiempo de ejecución en lugar de almacenarlas en configuraciones de pipeline. Los permisos heredan de los grupos de AD, por lo que el acceso permanece sincronizado con el directorio sin intervención manual. Comience su prueba gratuita hoy y pruébelo en su infraestructura

Riesgos críticos de seguridad de LDAP en 2026

LDAP no es solo un protocolo heredado con riesgos teóricos. Es una superficie de ataque activa con vulnerabilidades documentadas y explotadas.

La amenaza del robo de credenciales y ransomware

Según el X-Force Threat Intelligence Index 2026 de IBM, la recolección de credenciales fue el impacto de ataque más común observado en 2025. Los actores de amenazas recolectaron datos de inicio de sesión mediante phishing e infostealers, luego se mezclaron en flujos de autenticación normales para moverse lateralmente. Las credenciales de cuentas de servicio LDAP encajan precisamente en este patrón: reutilizadas entre aplicaciones, rara vez rotadas y casi nunca monitorizadas para detectar actividad de bind anómala.

La cadena de ataque está bien documentada: comprometer una credencial LDAP a través de phishing o password spraying, usarla para enumerar el directorio, identificar cuentas privilegiadas y escalar. El Digital Defense Report de Microsoft ha vinculado consistentemente el compromiso de credenciales AD/LDAP con el despliegue de ransomware. El directorio es un mapa de toda la estructura de acceso de la organización, y los atacantes lo leen antes de actuar.

Vulnerabilidades recientes: CVE-2025-26663 y CVE-2025-54918

Dos vulnerabilidades críticas divulgadas en 2025 demuestran que la superficie de ataque de LDAP se está expandiendo activamente.

CVE-2025-26663 es una vulnerabilidad de ejecución remota de código use-after-free en Windows LDAP, divulgada en abril de 2025. Un atacante puede explotar un fallo de gestión de memoria en el servicio LDAP de Windows (específicamente en wldap32.dll) para ejecutar código arbitrario en un servidor objetivo sin credenciales válidas.

El ataque solo requiere acceso de red al servicio LDAP. Los controladores de dominio, que exponen LDAP por diseño, son los objetivos principales. Los controladores de dominio sin parchear que ejecutan esta vulnerabilidad están efectivamente abiertos a Ejecución Remota de Código (RCE) no autenticada desde cualquier sistema que pueda alcanzar el puerto 389 o 636.

CVE-2025-54918, divulgada en septiembre de 2025, es una vulnerabilidad de escalada de privilegios que combina retransmisión NT LAN Manager con autenticación forzada para eludir las protecciones de vinculación de canal y firma LDAP. Un atacante con una cuenta de dominio de bajo privilegio puede forzar a un controlador de dominio a autenticarse en un sistema controlado por el atacante, manipular los paquetes de autenticación NTLM en tránsito y retransmitir la autenticación modificada de vuelta al controlador de dominio — logrando acceso de nivel SYSTEM. El ataque es particularmente peligroso porque elude controles en los que las organizaciones comúnmente confían como medidas de endurecimiento.

⚠️

Ambas vulnerabilidades tienen parches disponibles. Si los controladores de dominio no han recibido las actualizaciones de seguridad de Windows de abril de 2025 y posteriores, el parcheo es la prioridad inmediata.

Mejores prácticas para asegurar LDAP en la empresa

La siguiente lista de verificación cubre los controles mínimos para una implementación LDAP en producción. Estas son recomendaciones que abordan un vector de ataque específico y documentado.

Aplicar LDAPS en el puerto 636. Deshabilitar LDAP en texto plano en el puerto 389 para todo el tráfico de producción. Configurar certificados TLS de su CA interna o una CA pública de confianza.
Habilitar firma LDAP y vinculación de canal. Previene ataques de retransmisión. Requerido para la mitigación de CVE-2025-54918 — aunque tenga en cuenta que CVE-2025-54918 elude estos controles en sistemas sin parchear, por lo que el parcheo sigue siendo obligatorio.
Aplicar todas las actualizaciones de seguridad de Windows. CVE-2025-26663 y CVE-2025-54918 tienen parches. Los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
Restringir el acceso LDAP por IP. Solo los sistemas que legítimamente necesitan consultar LDAP deberían poder alcanzar el puerto 636. Las reglas de firewall deberían aplicar esto, no solo las suposiciones de segmentación de red.
Auditar credenciales de cuentas de servicio. Identificar cada DN de bind en uso en su entorno. Rotar contraseñas según un calendario. Eliminar cuentas que ya no se necesitan.
Monitorizar intentos de bind. Patrones de bind inusuales — fallos repetidos, binds desde IPs de origen inesperadas, binds a horas inusuales — son indicadores tempranos de credential stuffing o movimiento lateral.
Deshabilitar binds LDAP anónimos. Las consultas anónimas permiten la enumeración no autenticada del contenido del directorio. La mayoría de las implementaciones modernas no tienen un uso legítimo para binds anónimos.
Separar cuentas de servicio por función. Una cuenta de servicio utilizada por una VPN no debería tener los mismos permisos que una utilizada por un sistema de respaldo. El principio de mínimo privilegio también aplica a las cuentas de bind LDAP.

Optimizando el acceso empresarial con la integración LDAP de Passwork

La carga operativa de la gestión de acceso basada en LDAP se acumula con el tiempo. Los usuarios cambian de equipo, se unen a proyectos y abandonan la organización, y cada transición requiere cambios de acceso en múltiples sistemas. Cuando esos cambios son manuales, se retrasan. Las cuentas permanecen activas más tiempo del debido. Las credenciales se acumulan en lugares que nadie está rastreando.

Passwork se conecta directamente a Active Directory o cualquier directorio compatible con LDAP y mapea la membresía de grupos al acceso a bóvedas automáticamente:

Añadir un usuario al grupo SRE en AD — las credenciales correctas aparecen en su bóveda de Passwork, sin necesidad de acción administrativa separada
Eliminarlo del grupo — el acceso se revoca
El directorio permanece como la única fuente de verdad para quién tiene acceso a qué

Para entornos autoalojados, Passwork se implementa completamente dentro de su propio perímetro. Las credenciales nunca lo abandonan. SSO SAML está soportado junto con LDAP, por lo que los equipos que usan ambos protocolos para diferentes capas de aplicación no necesitan reconstruir su arquitectura de identidad.

Cada lectura, escritura, compartición y exportación se registra en el registro de auditoría — relevante tanto para revisiones de seguridad internas como para demostrar cumplimiento con SOC 2 CC6.1 y GDPR Artículo 32.

Conclusión

LDAP no va a desaparecer. El mercado de software de directorio se valoró en 8,4 mil millones de dólares en 2025 y se proyecta que alcanzará los 19,7 mil millones de dólares para 2034, según la investigación de mercado de Dataintelo — una cifra que refleja la inversión empresarial continua en infraestructura de directorio, no una tecnología en declive. Con el 90% de las empresas todavía ejecutando Active Directory, LDAP sigue siendo el tejido conectivo de la gestión de identidad corporativa.

Lo que ha cambiado es el entorno de amenazas. CVE-2025-26663 y CVE-2025-54918 son vulnerabilidades activamente parcheadas que apuntan a los servicios LDAP que sus controladores de dominio exponen ahora mismo.

La acción práctica es sencilla: aplicar LDAPS, parchear los controladores de dominio, auditar las credenciales de cuentas de servicio y asegurarse de que los cambios de acceso en el directorio se propaguen automáticamente a los sistemas que dependen de él. La gestión manual de acceso a la escala a la que operan la mayoría de las empresas es donde aparecen las brechas.

Passwork se integra con Active Directory y LDAP para mantener el acceso a credenciales sincronizado con los grupos de su directorio — automáticamente, sin scripts personalizados. Autoalojado, cifrado AES-256, ISO 27001, con un registro de auditoría completo. Pruébelo en su infraestructura

Preguntas frecuentes sobre LDAP

¿Para qué se utiliza LDAP?

LDAP se utiliza para autenticar usuarios y buscar información de directorio — membresías de grupos, direcciones de correo electrónico, atributos de cuentas — en aplicaciones empresariales. Los casos de uso comunes incluyen autenticación VPN, búsqueda de usuarios en servidores de correo, SSO de aplicaciones y gestión centralizada de usuarios. La mayoría de las aplicaciones empresariales que necesitan verificar identidad contra un directorio corporativo utilizan LDAP.

¿Cuál es la diferencia entre LDAP y Active Directory?

LDAP es un protocolo abierto (RFC 4511) para acceder a servicios de directorio. Active Directory es el servicio de directorio de Microsoft, que utiliza LDAP como uno de sus protocolos de acceso. AD también utiliza Kerberos para la autenticación de Windows. Se puede usar LDAP sin Active Directory (a través de OpenLDAP, por ejemplo), pero Active Directory depende de LDAP para servir consultas de directorio a aplicaciones que no son de Windows.

¿Qué es LDAPS y por qué es importante?

LDAPS es LDAP sobre TLS, funcionando en el puerto 636. LDAP estándar en el puerto 389 transmite credenciales en texto plano, haciéndolas visibles para cualquiera que pueda interceptar el tráfico de red. LDAPS cifra toda la sesión. En 2026, ejecutar LDAP sin cifrar en producción es indefendible — Microsoft ha estado aplicando requisitos de firma LDAP y vinculación de canal desde 2020, y tanto CVE-2025-26663 como CVE-2025-54918 apuntan directamente a servicios LDAP.

¿Todavía se usa LDAP en 2026?

Sí. Active Directory, que depende de LDAP, está implementado en aproximadamente el 90% de las empresas en todo el mundo. La adopción de la nube no lo ha desplazado — la mayoría de las organizaciones ejecutan entornos híbridos donde el AD local sigue siendo la fuente de identidad autorizada. LDAP también está integrado en miles de aplicaciones que se autentican contra directorios empresariales y no será reemplazado por SAML u OAuth sin una reingeniería significativa.

¿Cómo encaja LDAP en una arquitectura de confianza cero?

LDAP puede soportar la confianza cero si se endurece correctamente. La confianza cero requiere verificación continua de cada solicitud de acceso, y LDAP a menudo es el sistema que responde a esas solicitudes. Los requisitos: aplicar LDAPS (puerto 636), habilitar firma y vinculación de canal, restringir el acceso al directorio por IP de origen, monitorizar intentos de bind y rotar credenciales de cuentas de servicio regularmente. La configuración predeterminada de LDAP no es compatible con la confianza cero — pero el protocolo en sí no es el obstáculo.

¿Cuáles son los principales riesgos de seguridad con LDAP?

Los riesgos principales son la exposición de credenciales a través de conexiones sin cifrar (puerto 389), robo de credenciales de cuentas de servicio, ataques de retransmisión NTLM (CVE-2025-54918) y RCE no autenticado a través de vulnerabilidades de corrupción de memoria (CVE-2025-26663). El X-Force Threat Intelligence Index 2025 de IBM encontró que los ataques basados en identidad — muchos dirigidos a credenciales de directorio — representaron el 30% de todas las intrusiones en 2024. El parcheo, la aplicación de LDAPS y la higiene de cuentas de servicio abordan la mayoría de estos riesgos.

¿Puede LDAP ser reemplazado por SAML u OAuth?

No completamente. SAML y OAuth manejan la autenticación federada basada en navegador y la autorización de API respectivamente. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan los tres protocolos para diferentes capas de su stack de aplicaciones. La pregunta no es cuál elegir — es qué aplicaciones requieren LDAP y si esas conexiones están debidamente aseguradas.

Qué es LDAP: ¿sigue siendo relevante en 2026?

LDAP todavía gestiona la infraestructura de identidad en el 90 % de las empresas — y es una superficie de ataque activa. Dos vulnerabilidades RCE críticas parcheadas en 2025, recolección de credenciales en niveles récord. Qué corregir, cómo fortalecerlo y dónde está el riesgo real.

Access management

Jun 17, 2026 — 16 min read

What is LDAP: Is it still relevant in 2026?

LDAP (Lightweight Directory Access Protocol) is a client-server protocol for reading and writing directory services over a network. Defined in RFC 4511, it gives applications a standard way to query a directory — asking questions like "does this user exist?", "what groups do they belong to?", and "what resources can they access?"

Despite being first standardized in the early 1990s, LDAP remains the backbone of enterprise identity infrastructure in 2026. Active Directory, which runs on LDAP, is still deployed at approximately 90% of organizations worldwide.

Key takeaways

LDAP is a protocol. It defines how applications query a directory — user accounts, group memberships, access rights. Active Directory implements it, but LDAP runs independently on OpenLDAP and other servers without any Microsoft software.
AD cannot function without LDAP. Every non-Windows system that authenticates against Active Directory does so over LDAP. Remove it, and AD loses the ability to serve third-party applications, network devices, and Linux infrastructure.
Port 389 is not acceptable in production. Standard LDAP transmits credentials in plaintext. LDAPS on port 636 encrypts the entire session. Microsoft has been enforcing signing and channel binding requirements since 2020.
Two critical vulnerabilities were patched in 2025. CVE-2025-26663 allows unauthenticated remote code execution on domain controllers via a memory flaw in the Windows LDAP service. CVE-2025-54918 bypasses channel binding and signing protections through NTLM relay. Both have patches — unpatched domain controllers are the highest-priority remediation item.
LDAP and modern protocols are not alternatives. SAML handles browser-based SSO. OAuth handles API authorization. LDAP handles directory lookups for systems that speak neither. Most enterprise environments run all three simultaneously.
Manual access management creates gaps. When AD group changes don't propagate automatically to dependent systems, accounts stay active longer than they should. Synchronizing credential access to directory group membership eliminates that lag.

Understanding LDAP: The basics

LDAP is a standard protocol for accessing and managing distributed directory information services. It operates on a hierarchical data model derived from the X.500 standard and allows clients to authenticate users, look up attributes, and retrieve group memberships from a central directory. Organizations use it to answer one fundamental question at scale: who is allowed to do what, and where?

The data LDAP organizes sits in a Directory Information Tree (DIT) — a hierarchical structure of entries, each identified by a Distinguished Name (DN). A typical DN looks like this:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Each entry holds attributes: a user entry might contain mail, uid, memberOf, and userPassword. Applications query these attributes to make authentication and authorization decisions.

How does LDAP work? (client-server model)

An LDAP client sends a request to an LDAP server (called a Directory System Agent, or DSA). The server processes the operation against its directory database and returns a response. Core operations defined in RFC 4511 include:

Bind — authenticate a client to the directory
Search — query entries matching a filter
Compare — check whether an entry has a specific attribute value
Modify / Add / Delete — write operations on directory entries
Unbind — terminate the session

The bind operation is where authentication happens. A client sends a DN and credentials. The server validates them and either grants or denies the session. Most enterprise applications use LDAP bind to verify user identity before granting access.

LDAP port 389 vs. LDAPS port 636

Standard LDAP runs on TCP port 389 and transmits data in plaintext. That means credentials, including passwords, travel across the network unencrypted. In any environment where network traffic could be intercepted (which is every environment) this is unacceptable.

LDAPS (LDAP over SSL/TLS) runs on TCP port 636 and wraps the entire LDAP session in TLS, encrypting all traffic including bind credentials. A third option, StartTLS, upgrades an existing port 389 connection to TLS mid-session, but it introduces negotiation complexity and is more error-prone to configure correctly.

	LDAP (port 389)	LDAPS (port 636)
Transport	Plaintext TCP	TLS-encrypted TCP
Credentials in transit	Exposed	Encrypted
Certificate required	No	Yes
Susceptible to MITM	Yes	No (with valid cert)
NTLM relay risk	High	Reduced (with channel binding)
Microsoft enforcement	Deprecated for production	Required (ADV190023)
Use in production	No	Yes
StartTLS alternative	Port 389 + STARTTLS upgrade	N/A

Microsoft has been progressively mandating LDAP channel binding and LDAP signing since 2020, with enforcement tightened in subsequent Windows Server updates. Running unencrypted LDAP on port 389 in production is a security gap. Port 636 is the correct default.

What is TCP port 389?

TCP Port 389 — the standard unencrypted port used for LDAP (Lightweight Directory Access Protocol) communications. It enables directory services to query and manage user information, authentication credentials, and organizational data on LDAP servers without encryption. Commonly used in enterprise environments for directory lookups, but transmits data in plaintext, making it less secure than encrypted alternatives.

What is TCP port 636?

TCP Port 636 — the standard port for LDAPS (LDAP over SSL/TLS), which is LDAP communication encrypted with SSL/TLS security protocols. It provides secure, encrypted connections for directory service queries and authentication, protecting sensitive data from interception. This port is preferred over port 389 in security-conscious environments and is commonly used in enterprise directory services like Active Directory.

What is SSL/TLS?

SSL/TLS (Secure Sockets Layer / Transport Layer Security) — cryptographic protocols that establish secure, encrypted connections between clients and servers over networks. SSL is the older protocol (now deprecated), while TLS is its modern successor. They provide authentication, encryption, and data integrity for sensitive communications like HTTPS, email, and directory services. TLS uses digital certificates to verify server identity and encrypts all transmitted data to prevent eavesdropping.

What is StartTLS?

StartTLS — a protocol extension that upgrades an existing unencrypted connection to an encrypted one using TLS encryption. Instead of requiring a separate secure port, StartTLS allows a client to connect on a standard port (like LDAP port 389 or SMTP port 25) and then issue a STARTTLS command to upgrade the connection to encryption. This provides flexibility by supporting both encrypted and unencrypted modes on the same port, though it requires server support and is less secure than dedicated encrypted ports like LDAPS (port 636).

LDAP vs. Active Directory: What's the difference?

Active Directory (AD) is not a replacement for LDAP — it is a directory service that uses LDAP as one of its access protocols. Conflating the two is one of the most common misconceptions in enterprise IT. The dependency only runs one way: LDAP stands alone, AD does not.

Can you run LDAP without AD?

Yes. LDAP is a protocol — it defines how a client asks a directory server for information and how that server responds. You can deploy it independently of any Microsoft software.

OpenLDAP is the most widely used open-source implementation. 389 Directory Server and Apache Directory Server are common alternatives. These standalone servers store user identities and group memberships and serve them to Linux/Unix systems, mail servers, and custom applications.

Can you run AD without LDAP?

No. Active Directory is a full directory service built by Microsoft on top of the X.500 data model. Domain controllers use LDAP internally to read, write, and replicate directory data: users, computers, group policies. Any third-party application or non-Windows machine that authenticates against AD does so by speaking LDAP to it.

Remove LDAP, and AD cannot communicate with the rest of your infrastructure.

How they relate in practice

Type	LDAP	Active Directory
Type	Open protocol (RFC 4511)	Proprietary directory service
Vendor	IETF standard	Microsoft
Primary auth method	Simple bind, SASL	Kerberos (Windows), LDAP bind (everything else)
Platform	Cross-platform	Windows Server
Runs independently	Yes	No — requires LDAP
Common implementations	OpenLDAP, 389 Directory Server, Apache DS	Active Directory Domain Services

When a Linux server authenticates against Active Directory, it speaks LDAP. When a Windows workstation logs in, it uses Kerberos. AD supports both — but LDAP is what makes AD accessible to the rest of your infrastructure.

Modern alternatives: LDAP vs. SAML, OAuth, and OpenID Connect

LDAP was designed for internal network authentication — querying a directory inside a corporate perimeter. The protocols that followed it were designed for a different world: federated identity across organizational boundaries, web applications, and mobile clients.

Protocol	Primary use case	Transport	Credential exposure
LDAP	Internal directory queries	TCP (port 389/636)	Credentials sent to server
SAML	Federated SSO (enterprise web apps)	HTTP/XML	Credentials stay at IdP
OAuth 2.0	Delegated authorization (API access)	HTTPS	No credentials exchanged
OpenID Connect	Federated authentication on top of OAuth	HTTPS	No credentials exchanged

These protocols do not replace LDAP — they operate at a different layer. SAML and OpenID Connect handle browser-based SSO. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all of them simultaneously.

Is LDAP still relevant in 2026? (the hybrid cloud reality)

LDAP is still the dominant enterprise authentication protocol, present in approximately 90% of organizations worldwide through their Active Directory deployments. Cloud adoption has not changed this.

Most enterprises are not fully cloud-native. They run a hybrid model: some workloads in Azure or AWS, others on-premises, with Active Directory as the identity anchor for both. Microsoft Entra ID (formerly Azure AD) connects to on-premises AD through synchronization, but the on-premises AD (and therefore LDAP) remains the authoritative source for many identity decisions.

The role of LDAP in zero trust architecture

Zero trust requires continuous verification: every access request must be authenticated and authorized, regardless of network location. LDAP sits at a critical junction in this model because it is often the system that answers those verification requests.

The challenge is that LDAP was not designed with zero trust principles in mind. It assumes network adjacency, uses persistent connections, and in its unencrypted form exposes credentials in transit. Fitting LDAP into a zero trust architecture requires compensating controls:

mandatory LDAPS
strict firewall rules
limiting which systems can reach port 636
LDAP signing enforcement
monitoring of bind attempts for anomalous patterns

LDAP does not break zero trust but it requires deliberate hardening to support it. Organizations that treat LDAP as a legacy component and leave it unconfigured are creating exactly the kind of implicit trust that zero trust is designed to eliminate.

DevOps and CI/CD secrets management

Automated pipelines present a specific LDAP challenge. CI/CD systems (Jenkins, GitLab CI, GitHub Actions runners) often need to authenticate against LDAP to access internal resources. That authentication typically involves a service account: a dedicated LDAP bind DN with a static password.

Static service account credentials are a persistent risk. They rarely rotate, they are often shared across pipelines, and when they appear in build logs or configuration files, they are difficult to detect and revoke. The answer is to manage these credentials through a dedicated secrets manager rather than hardcoding them in pipeline configuration.

Passwork's CLI tools and REST API let DevOps teams pull service account credentials at runtime rather than storing them in pipeline configs. Permissions inherit from AD groups, so access stays synchronized with your directory without manual intervention. Start your free trial today and test it on your infrastructure

Critical LDAP security risks in 2026

LDAP is not just a legacy protocol with theoretical risks. It is an active attack surface with documented, exploited vulnerabilities.

The threat of credential theft and ransomware

According to IBM's X-Force Threat Intelligence Index 2026, credential harvesting was the most common attack impact observed in 2025. Threat actors harvested login data via phishing and infostealers, then blended into normal authentication flows to move laterally. LDAP service account credentials fit this pattern precisely: reused across applications, rarely rotated, and almost never monitored for anomalous bind activity.

The attack chain is well-documented: compromise an LDAP credential through phishing or password spraying, use it to enumerate the directory, identify privileged accounts, and escalate. Microsoft's Digital Defense Report has consistently linked AD/LDAP credential compromise to ransomware deployment. The directory is a map of the entire organization's access structure, and attackers read it before they act.

Recent vulnerabilities: CVE-2025-26663 and CVE-2025-54918

Two critical vulnerabilities disclosed in 2025 demonstrate that LDAP's attack surface is actively expanding.

CVE-2025-26663 is a use-after-free remote code execution vulnerability in Windows LDAP, disclosed in April 2025. An attacker can exploit a memory management flaw in the Windows LDAP service (specifically in wldap32.dll) to execute arbitrary code on a target server without valid credentials.

The attack requires only network access to the LDAP service. Domain controllers, which expose LDAP by design, are the primary targets. Unpatched domain controllers running this vulnerability are effectively open to unauthenticated Remote Code Execution (RCE) from any system that can reach port 389 or 636.

CVE-2025-54918, disclosed in September 2025, is a privilege escalation vulnerability that combines NT LAN Manager relay with coerced authentication to bypass LDAP channel binding and signing protections. An attacker with a low-privileged domain account can coerce a domain controller into authenticating to an attacker-controlled system, manipulate the NTLM authentication packets in transit, and relay the modified authentication back to the domain controller — achieving SYSTEM-level access. The attack is particularly dangerous because it bypasses controls that organizations commonly rely on as hardening measures.

⚠️

Both vulnerabilities have patches available. If your domain controllers have not received April 2025 and subsequent Windows security updates, patching is the immediate priority.

Best practices for securing LDAP in the enterprise

The following checklist covers the minimum controls for a production LDAP deployment. These are recommendations that address a specific, documented attack vector.

Enforce LDAPS on port 636. Disable plaintext LDAP on port 389 for all production traffic. Configure TLS certificates from your internal CA or a trusted public CA.
Enable LDAP signing and channel binding. Prevents relay attacks. Required for CVE-2025-54918 mitigation — though note that CVE-2025-54918 bypasses these controls on unpatched systems, so patching is still mandatory.
Apply all Windows security updates. CVE-2025-26663 and CVE-2025-54918 both have patches. Unpatched domain controllers are the highest-priority remediation item.
Restrict LDAP access by IP. Only systems that legitimately need to query LDAP should be able to reach port 636. Firewall rules should enforce this, not just network segmentation assumptions.
Audit service account credentials. Identify every bind DN in use across your environment. Rotate passwords on a schedule. Remove accounts that are no longer needed.
Monitor bind attempts. Unusual bind patterns — repeated failures, binds from unexpected source IPs, binds at unusual hours — are early indicators of credential stuffing or lateral movement.
Disable anonymous LDAP binds. Anonymous queries allow unauthenticated enumeration of directory contents. Most modern deployments have no legitimate use for anonymous binds.
Separate service accounts by function. A service account used by a VPN should not have the same permissions as one used by a backup system. Least privilege applies to LDAP bind accounts too.

Streamlining enterprise access with Passwork LDAP integration

The operational burden of LDAP-based access management compounds over time. Users change teams, join projects, and leave the organization and each transition requires access changes across multiple systems. When those changes are manual, they lag. Accounts stay active longer than they should. Credentials accumulate in places no one is tracking.

Passwork connects directly to Active Directory or any LDAP-compatible directory and maps group membership to vault access automatically:

Add a user to the SRE group in AD — the correct credentials appear in their Passwork vault, no separate admin action required
Remove them from the group — access is revoked
The directory stays the single source of truth for who has access to what

For self-hosted environments, Passwork deploys entirely within your own perimeter. Credentials never leave it. SAML SSO is supported alongside LDAP, so teams using both protocols for different application layers don't need to rebuild their identity architecture.

Every read, write, share, and export is recorded in the audit log — relevant both for internal security reviews and for demonstrating compliance with SOC 2 CC6.1 and GDPR Article 32.

Conclusion

LDAP is not going away. The directory software market was valued at $8.4 billion in 2025 and is projected to reach $19.7 billion by 2034, according to Dataintelo's market research — a figure that reflects continued enterprise investment in directory infrastructure, not a technology in decline. With 90% of enterprises still running Active Directory, LDAP remains the connective tissue of corporate identity management.

What has changed is the threat environment. CVE-2025-26663 and CVE-2025-54918 are actively patched vulnerabilities targeting the LDAP services your domain controllers expose right now.

The practical action is straightforward: enforce LDAPS, patch your domain controllers, audit your service account credentials, and make sure access changes in your directory propagate automatically to the systems that depend on it. Manual access management at the scale most enterprises operate is where gaps appear.

Passwork integrates with Active Directory and LDAP to keep credential access synchronized with your directory groups — automatically, without custom scripts. Self-hosted, AES-256 encrypted, ISO 27001, with a full audit trail. Try it in your infrastructure

Frequently asked questions about LDAP

What is LDAP used for?

LDAP is used to authenticate users and look up directory information — group memberships, email addresses, account attributes — across enterprise applications. Common use cases include VPN authentication, email server user lookup, application SSO, and centralized user management. Most enterprise applications that need to verify identity against a corporate directory use LDAP.

What is the difference between LDAP and Active Directory?

LDAP is an open protocol (RFC 4511) for accessing directory services. Active Directory is Microsoft's directory service, which uses LDAP as one of its access protocols. AD also uses Kerberos for Windows authentication. You can use LDAP without Active Directory (via OpenLDAP, for example), but Active Directory relies on LDAP to serve directory queries to non-Windows applications.

What is LDAPS and why does it matter?

LDAPS is LDAP over TLS, running on port 636. Standard LDAP on port 389 transmits credentials in plaintext, making them visible to anyone who can intercept network traffic. LDAPS encrypts the entire session. In 2026, running unencrypted LDAP in production is indefensible — Microsoft has been enforcing LDAP signing and channel binding requirements since 2020, and both CVE-2025-26663 and CVE-2025-54918 target LDAP services directly.

Is LDAP still used in 2026?

Yes. Active Directory, which relies on LDAP, is deployed at approximately 90% of enterprises worldwide. Cloud adoption has not displaced it — most organizations run hybrid environments where on-premises AD remains the authoritative identity source. LDAP is also embedded in thousands of applications that authenticate against enterprise directories and will not be replaced by SAML or OAuth without significant re-engineering.

How does LDAP fit into a zero trust architecture?

LDAP can support zero trust if hardened correctly. Zero trust requires continuous verification of every access request, and LDAP is often the system answering those requests. The requirements: enforce LDAPS (port 636), enable signing and channel binding, restrict directory access by source IP, monitor bind attempts, and rotate service account credentials regularly. LDAP's default configuration is not zero trust-compatible — but the protocol itself is not the obstacle.

What are the main security risks with LDAP?

The primary risks are credential exposure over unencrypted connections (port 389), service account credential theft, NTLM relay attacks (CVE-2025-54918), and unauthenticated RCE via memory corruption vulnerabilities (CVE-2025-26663). IBM's X-Force Threat Intelligence Index 2025 found that identity-based attacks — many targeting directory credentials — accounted for 30% of all intrusions in 2024. Patching, LDAPS enforcement, and service account hygiene address the majority of these risks.

Can LDAP be replaced by SAML or OAuth?

Not entirely. SAML and OAuth handle browser-based federated authentication and API authorization respectively. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all three protocols for different layers of their application stack. The question is not which to choose — it is which applications require LDAP and whether those connections are secured properly.

What is LDAP: Is it still relevant in 2026?

LDAP still runs identity infrastructure at 90% of enterprises — and it's an active attack surface. Two critical RCE vulnerabilities patched in 2025, credential harvesting at record levels. What to fix, how to harden it, and where the real risk sits.