LDAP

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is an open IETF standard protocol that lets clients query and modify information in a hierarchical directory service, such as accounts, groups, computers and devices, and use it to authenticate users. LDAP is not a product but a language: directory servers such as Active Directory, OpenLDAP and 389 Directory Server speak it, and thousands of applications use it to centralise authentication and authorisation. In OT environments, too, LDAP is the usual link between SCADA software, HMIs, network equipment and the central user directory.

🧠 Where does LDAP come from?

LDAP emerged in the early 1990s as a lightweight alternative to the heavyweight X.500 Directory Access Protocol (DAP), which required the full OSI stack. The first specification, RFC 1487 (July 1993), was written by Wengyik Yeong, Tim Howes (University of Michigan) and Steve Kille. LDAP ran directly over TCP, which made X.500 directories usable from ordinary PCs and applications.

The current standard is a set of RFCs that together describe the protocol (RFC 4511), the information model (RFC 4512), authentication and security (RFC 4513), the string format of names (RFC 4514) and search filters (RFC 4515). LDAPv2 has formally been historic since 2003; everything you encounter today is LDAPv3.

🔧 How does LDAP work?

LDAP follows a client-server model. The directory is a tree (the Directory Information Tree) of objects with attributes. Every object has a unique Distinguished Name (DN), for example cn=Jansen,ou=Operators,ou=OT,dc=company,dc=com. A typical session runs as follows:

1. Connect - the client opens a TCP connection to the directory server, preferably encrypted from the start.
2. Bind - the client authenticates. With a simple bind it sends a DN and password; with a SASL bind it uses, for example, Kerberos. An anonymous bind is also possible but should be disabled in production.
3. Search - the client searches from a base DN with a filter, such as (&(objectClass=user)(sAMAccountName=jansen)), and requests only the attributes it needs, for example memberOf.
4. Response - the server returns the matching objects. Passwords are never part of the result: the server only checks a password during the bind.
5. Unbind - the client closes the session.

For a login, an application usually takes two steps: first it searches for the user’s DN with a service account, then it binds with that DN and the password the user entered. If that bind succeeds, the user is authenticated; the application then uses the group memberships to decide which role the user gets (RBAC).

🔄 What is the difference between LDAP, Active Directory and Entra ID?

LDAP is often confused with the systems that speak the protocol. The distinction matters when you choose how to integrate an application.

Entra ID itself therefore does not answer LDAP requests. To connect a legacy application to Entra ID, you use Entra Domain Services (a managed domain that does offer LDAPS) or synchronise users back to a local directory.

🏭 How is LDAP used in OT networks?

• Login to process applications - SCADA packages such as Ignition, historians and engineering stations can take users and roles from a directory, so you do not have to manage local accounts on each system.
• Management of network equipment - switches, firewalls and VPN gateways let administrators log in with their directory account, either directly over LDAP or through a RADIUS server that in turn uses LDAP.
• Network access - with 802.1X, the RADIUS server often checks the identity against Active Directory over LDAP.
• Groups as roles - an AD group such as OT-Operators or OT-Engineers is mapped to a role in the application, so access control permissions change centrally.
• Older systems - much industrial software does not support SAML or OpenID Connect but does support LDAP. That keeps LDAP relevant in OT for longer than in the office environment.

A key design decision is which directory OT uses. Many organisations run a separate OT domain in the IDMZ or at level 3 of the Purdue Model, with no trust or a one-way trust to the IT domain. A compromised IT domain then does not automatically give access to the process environment.

🔐 What are the security risks of LDAP?

• Plain-text passwords - a simple bind over port 389 without TLS sends the password unencrypted. Anyone running Wireshark on the same segment can read it.
• Relay and man-in-the-middle attacks - without LDAP signing and channel binding, an attacker can relay an NTLM authentication to a domain controller and make changes.
• Reconnaissance - by default, any authenticated user can read large parts of Active Directory. Attackers use this for lateral movement towards administrator accounts.
• LDAP injection - applications that paste user input into a search filter without escaping it are vulnerable, much like SQL injection.
• Implementation vulnerabilities - in December 2024 Microsoft patched CVE-2024-49112, a critical flaw (CVSS 9.8) in the Windows LDAP code that allowed an unauthenticated attacker to execute code remotely. Timely patching of domain controllers is therefore necessary in OT as well.

Microsoft has tightened the defaults. New Active Directory deployments on Windows Server 2025 require LDAP signing by default and set channel binding to ‘when supported’. An in-place upgrade of an existing domain controller keeps its old settings, however, and on Windows Server 2022 and earlier signing is optional. There you have to enforce it yourself, after checking that older OT clients can cope.

🛠️ How do you use LDAP securely in OT?

A practical approach in six steps:

1. Take inventory of the systems that use LDAP. On a domain controller, event 2887 shows daily how many unencrypted or unsigned binds occurred, and event 2889 (after raising the diagnostic level) shows which clients made them.
2. Encrypt everything - use LDAPS on port 636 or StartTLS on 389, and have the client validate the server certificate. Manage the lifetime of those certificates through certificate management, because an expired certificate stops every login.
3. Enforce signing and channel binding on the domain controllers, first in audit mode, then mandatory.
4. Use separate service accounts for each application, with read-only rights on the required OUs only, following least privilege. Manage their passwords in a PAM solution.
5. Restrict the network path - allow LDAP traffic through the firewall or an ACL only from known OT servers to the domain controllers, in line with your network segmentation. Never expose LDAP to the internet.
6. Monitor and alert - send directory logs to a SIEM, watch for unusual searches and failed binds, and add MFA on the access paths that support it, such as remote access through a jump server.

Plan a fallback as well. If the directory is unreachable, an operator must still be able to intervene. Many OT applications therefore support a small number of local emergency accounts, which you secure and log separately.

🇪🇺 Which standards and laws affect LDAP?

IEC 62443-3-3 requires, among other things, unique identification and authentication of users (SR 1.1), account management (SR 1.3, with unified account management as an enhancement for higher security levels) and protection of confidential information in transit (SR 4.1). A directory queried over encrypted LDAP is a common way to meet these requirements and a building block of OT security. Under the Dutch Cybersecurity Act, the national implementation of NIS2, access management, authentication and the use of encryption are among the mandatory duty-of-care measures. Unencrypted LDAP with a shared administrator account no longer fits that picture.

❓ Frequently asked questions

Is LDAP the same as Active Directory?

No, LDAP is a protocol and Active Directory is a Microsoft directory service. Active Directory uses LDAP as one of its access protocols, alongside Kerberos and DNS among others. Other directory servers, such as OpenLDAP, also speak LDAP.

What is the difference between LDAPS and StartTLS?

LDAPS uses port 636 and is encrypted with TLS from the start of the connection. StartTLS begins on port 389 as an ordinary LDAP connection and then switches to TLS. Both protect the password, provided the client validates the server’s certificate.

Is LDAP secure enough for OT systems?

LDAP is secure if you use it encrypted, enforce signing and channel binding, and restrict the network path. Unencrypted LDAP with a simple bind is not secure, because the password travels across the network in readable form. In OT, also combine LDAP with network segmentation and monitoring.

Does Entra ID support LDAP?

Microsoft Entra ID itself does not support LDAP; it uses modern protocols such as OpenID Connect, OAuth 2.0 and SAML. For applications that only understand LDAP, Microsoft offers the separate Entra Domain Services, which provides a managed domain with LDAPS.

Which ports does LDAP use?

LDAP uses TCP port 389 by default and LDAPS uses port 636. Active Directory adds the Global Catalog on port 3268 and, encrypted, on port 3269. In an OT firewall, allow only the ports you actually need.

Should an OT environment have its own directory?

A separate OT directory is not mandatory, but it is common good practice. A dedicated OT domain prevents an attack on the IT domain from spreading directly into the process environment. Users then do need a second account, which adds administrative effort.

📌 In summary

Since 1993 LDAP has been the standard language for querying a directory, and in hybrid IT/OT environments it connects applications, network equipment and central identities. Its value lies in central management of accounts and roles; its risk lies in unencrypted use, over-privileged service accounts and unpatched domain controllers.

LDAP is the open protocol that applications and devices use to check users against a central directory; in OT, use it only encrypted, with minimal rights and a tightly restricted network path.