You might have faced this question from your security team that ldap protocol is not secured and its not allowed in your organization. During your legacy application migration when you have limited support from vendor, it might only support ldap, you might have decided to scrap the deployment. Lets discuss the scenario and find how secure ldap is?
Lightweight Directory Access Protocol (LDAP) was developed in 1990 by Tim Howes to access the light weight directory access version of X.500 protocol. LDAP works on tcp/389 considered to be an unsecured protocol due to its legacy nature however over the period to time several security measures have been implemented as given below.
There are two bind method available while the LDAP needs to access the server resources or browse directory.
(1) ldap_simple_bind(): Perform a Simple LDAP Bind Request; The ldap_simple_bind() function is used to authenticate a distinguished name (DN) to a directory server over simple bind method typically without encryption or passing plain text password as per image given below.
(2) ldap_sasl_bind()–Perform an LDAP SASL Bind Request; The ldap_sasl_bind() function is used to authenticate a distinguished name (DN) to a directory server using Simple Authentication Security Layer (SASL).
LDAP protocol can be encrypted and protected in multiple ways;
(1) LDAP (389) + StartTLS
(2) LDAPS (636) (LDAP over TLS on port 636/TCP)
(3) LDAP with SASL/GSSAPI/SPNEGO with data integrity and data confidentiality layer GSS-API
(4) LDAPI (IPC over Unix socket):
We are specifically going to talk about; (3) LDAP with SASL/GSSAPI/SPNEGO with data integrity and data confidentiality layer. Lets first understand, what is GSS-API and SPNEGO before we get into more depth?
- Generic Security Services (GSS-API):
Generic Security Services (GSS) was originally developed for Unix based OS to access and authenticate Kerberos services using security however, being vendor agnostic and in Windows system a well, GSS-API support ldap clients to authenticate with Kerberos V5 based server to get Kerberos tickets and by establishing the session encryption. SASL GSS-API authentication must be triggered in Directory Server so that Kerberos tickets are sent to client for authentication.
2. Simple and Protected GSS-API Negotiation (SPNEGO)
SPNEGO stands for Simple and Protected GSS-API Negotiation Mechanism. SPNEGO helps as a part of GSS-API to handshake the choice of security mechanism to use offered by ldap server, It could be Kerberos or NTLM. Depending upon the server, Kerberos or NTLM would be served. We are more focused on getting the Kerberos, which is a pure Network Authentication Protocol operating primarily in the transport layer (TCP/UDP). While this is good for many use cases, this falls short of requirements for the modern web. If we have an application that operates on a higher abstraction, like HTTP, it is not possible to use Kerberos directly.
This is where SPNEGO comes to our help. In the case of a web application, communication primarily happens between a web browser like Chrome and a web server like Tomcat hosting the web application over HTTP. If enabled, they can negotiate Kerberos as a security mechanism through SPNEGO and exchange tickets as SPNEGO tokens over HTTP.
when we ran a packet sniffer from the ldap client to ldap server, we saw that ldap is handing over the bind request to sasl (Figure1) so it was not plain text or simple bind method we talked above.
We found (Figure 2) that the supported security mechanism were GSSAPI, GSS-SPNEGO, External or MD5, I still don’t vouch MD5 as secured mechanism however
in next Figure 3, we found the LDAP was handing over the session to Simple Protect Negotiation (GSS-API), krb5_token_id and enc-part: etype as AES256 bits encryption
In Figure 4, authentication bind was sasl, GSS-API and token was negotiated with krb5.
Conclusion
With the above test, its confirmed that ldap bind process decide the security of authentication whether it would on Kerberos, NTLM, external or MD5. in absence of Kerberos based authentication, ldap bind can handover the authentication to NTLM which is yet not secured method and prone to man in middle attack. However till its Kerberos based ticket and AES256 bits encrypted, we can consider a secured method of directory access and authentication.
Reference:
1. 9.11. Using Kerberos GSS-API with SASL Red Hat Directory Server 11 | Red Hat Customer Portal
2. *Understanding LDAP Security Processing – Microsoft Community Hub