Active Directory LDAP Authentication and Security
2012-02-02 Updated
2012-01-23 Initial post
One of our application administrators asked me to help him troubleshoot why LDAP user authentication didn't work correctly in his application, Oracle Agile PLM (Product Lifecycle Management) 9.3.1. I decided to look into LDAP authentication a little more and here are some notes I made. I wasn't able to find a nice simple article that answers this question: How is LDAP user authentication handled in AD?
- LDAP, when used with non-Microsoft systems, could send user credentials in clear text. For example, the Softerra LDAP Browser and JXplorer LDAP browsers have options for authentication which could send the credentials in clear text.
- LDAP, when used with modern Microsoft operating systems and applications, will use Kerberos to secure the user credentials.
- Basically, LDAP v3, which AD supported from the first version (Windows 2000), provides a functionality called SASL (Simple Authentication and Security Layer) that allows the LDAP authentication process to use one of several secure mechanisms, with Kerberos v5 being the default in AD.
- I wasn't sure if there's a difference between an app querying AD and the app passing user authentication to AD. Here's my observation regarding that:
- For example, a non-Microsoft app has a service account named svcSomeApp. That account is only a member of Domain Users so it has read-only permission to many AD object attributes. The app uses that account to query AD for specific attributes of users who use the app. The app also uses AD to authenticate the users, e.g., the app has a form on its logon page that passes the credentials to AD. So AD will basically reply back with something like "yes, this is a valid user and the password is correct" or "no, this is not a valid user" or "user is valid but password is incorrect."
- It looks it doesn't matter whether the app is using its service account to authenticate itself to AD or passing user authentication to AD, it's all done via port 389 by default with the credentials in clear text (unless the app supports SASL and both the app and AD agree to use the same security mechanism).
From Softerra LDAP Browser 4.5 help file:
- Simple Standard LDAP authentication mechanism. The principal and the password are transmitted in plain text, which makes this mechanism potentially vulnerable to cyber attacks. This mechanism is not recommended for usage in an unsafe environment like the Internet. However, using this mechanism when you connect to an LDAP server over SSL or a protected VPN channel is quite secure.
- Digest MD5 This is a SASL authentication mechanism that provides a much higher protection from cyber attacks. If your server supports this mechanism, it's recommended you always prefer Digest MD5 over Simple.
- GSS Negotiate A SASL mechanism that allows both client and server to negotiate for and then use the best authentication mechanism they mutually support. It’s recommended you prefer GSS Negotiate over Simple or Digest MD5 whenever possible.
From http://msdn.microsoft.com/en-us/library/windows/desktop/ms808911.aspx:
The Active Directory is an implementation of the Lightweight Directory Access Protocol (LDAP) version 3 standard as specified in RFC-2251. LDAP version 3 supports authenticated connections using simple authentication through NTLM, SSL, and SASL/GSSAPI (RFC-2222) mechanisms.
The Kerberos authentication service is an implementation of the Kerberos version 5 as specified in RFC-1510. The authentication service implements the Key Distribution Center (KDC) service and forms the core security mechanism for Windows 2000.
From http://www.symantec.com/connect/articles/audit-active-directory-security-part-3:
LDAP v3 integrates SASL into the picture. With SASL, any authentication/encryption system can be implemented. In the case of Active Directory, Microsoft chose to go with Kerberos v5 sort of.
In the case of AD authentication, SASL works with another technology: SPNEGO, or Security Protocol NEGOtiation. SASL and SPNEGO determine exactly what protocol or protocols can be used to authenticate to the directory (in an ideal situation, where all LDAP v2 functionality is as removed as possible.)
Currently, SPNEGO only seems to choose between two protocols, NTLM and Kerberos. (Some more experienced readers may be asking why I'm not mentioning the component called GSS-API. I'm choosing to ignore it in this case for simplicity's sake). Users who opt to authenticate to the directory with some other protocol will get an error message stating that no common authentication mechanisms are available.
From http://www.unixwiz.net/techtips/security-ldap-ad.html, the author did a test with a packet sniffer and was able to see his LDAP authentication password in clear text (search for "mypass" on that page).
From http://www.codeproject.com/Articles/18742/Simple-Active-Directory-Authentication-Using-LDAP, the author "added the AuthenticationType.Secure to enable the Kerberos/NTLM encryption of the data as it's passed along the network." Before that, LDAP authentication credentials had been sent in clear text.
This is a long article from MS, but if you skim through it, there's some interesting info about LDAP anonymous binds: How Active Directory Searches Work.
Petri has a nice short article titled Anonymous LDAP operations in Windows 2003 AD.
