LDAP
Last updated
Last updated
Lightweight Directory Access Protocol (LDAP) is an open-source and cross-platform protocol used for authentication against various directory services (such as AD). The latest LDAP specification is Version 3, published as RFC 4511. LDAP uses port 389, and LDAP over SSL (LDAPS) communicates over port 636. LDAP is used as a standardized access protocol that allows for queries and changes following a client-server model.
LDAP, along with Kerberos, SMB and DNS, is one of the four central standard protocols used to provide seamless communication and data transfer in AD environments: Active Directory is designed to integrate LDAP-based services.
AD stores user account information and security information such as passwords and facilitates sharing this information with other devices on the network. LDAP is the language that applications use to communicate with other servers that provide directory services. In other words, LDAP is how systems in the network environment can "speak" to AD.
An LDAP session begins by first connecting to an LDAP server, also known as a Directory System Agent. The Domain Controller in AD actively listens for LDAP requests, such as security authentication requests.
The relationship between AD and LDAP can be compared to Apache and HTTP. The same way Apache is a web server that uses the HTTP protocol, Active Directory is a directory server that uses the LDAP protocol.
While uncommon, some organization do not have AD but are using LDAP, meaning that they most likely use another type of LDAP server such as OpenLDAP.
LDAP is set up to authenticate credentials against AD using a "BIND" operation to set the authentication state for an LDAP session.
There are three main types of LDAP authentication:
Simple Authentication or Simple Bind: This includes anonymous authentication, unauthenticated authentication, and username/password authentication. Simple authentication means that a username and password create a BIND request to authenticate to the LDAP server.
SASL Authentication or SASL Bind: The Simple Authentication and Security Layer (SASL) framework uses other authentication services such as Kerberos (through GSSAPI), NTLM (through GSS-SPNEGO) or DIGEST-MD5 (used as a last straw as it's fairly unsecure compared to the other two), to bind to the LDAP server. The LDAP server uses the LDAP protocol to send an LDAP message to the authorization service, which initiates a series of challenge/response messages resulting in either successful or unsuccessful authentication. SASL can provide additional security due to the separation of authentication methods from application protocols. The same functionality can be achieved through external authentication protocols such as TLS with a client certificates, although this is mostly used in scenarios like smart card authentication.
Anonymous Bind: allows LDAP clients to connect to the server without providing credentials. Anonymous authentication is typically disabled by default for security reasons.
LDAP authentication messages are sent in cleartext by default so anyone can sniff out LDAP messages on the internal network. It is recommended to use TLS encryption or similar to safeguard this information in transit.
By default, LDAP communicates using port 389. To use LDAPS, port 636 should be used. The Microsoft SSL provider selects the first certificate in the local computer store. LDAPS will also be enabled automatically whenever the enterprise root CA certificate is installed on the host. Generally, these are the requirements for LDAPS to function:
The certificate used by LDAPS has to be installed in the local computer's certificate store
The private key associated with the certificate should be present in the local computer's certificate store
The certificate should be issued by a CA with domain controller and client trust
LDAPs is not fundamentally a different protocol than LDAP as it just uses the SSL protocol for communication to provide encrypted and secure communications between the client and the server.
The following are the main steps involved in a bind operation, keep in mind that the process changes based on the authentication protocol and whether TLS is used or not:
Connection Initialization by the client: the client opens a TCP connection to the LDAP server, either on port 389 for LDAP or 636 for LDAPS
Bind Request: the client sends a BindRequest to authenticate to the server specifying the authentication mechanism, some kind of user identifier (User Principal Name or Distinguished Name) and some form of credential related to the authentication protocol used (password, cryptographic key, Kerberos ticket)
The server processes the request by verifying the provided credentials against AD and determines the client's identity and access rights / permissions
Bind Response: the server sends a BindResponse indicating whether the bind operation was successful; if authentication fails, the server should also return an error code (for example 0 for success, 49 for invalid credentials and 50 for insufficient rights) and a human-readable error message
If the authentication succeeds, a session is established between the client and LDAP server allowing the former to perform queries and modify attributes based on their permissions within the domain
The following are examples of different requests and responses
Bind Request
Successful Bind Response
Failed Bind Response
If LDAPS or STARTTLS are being used for the connection, a TLS handshake occurs before the bind request. The differences is that while LDAPS uses a separate port from the standard service (636 instead of 389) and encrypts communications from the very beginning, STARTTLS still uses port 389 and the client needs to send a STARTTLS command to initiate the encryption process; the service also keeps plaintext communications as fallback if the server doesn't support TLS.