I have read a fairly good amount of info about LDAP but there's something I don't understand.

Let's suppose I have a J2EE app that is capable of both authenticating local users or LDAP users (mutually exclusive alternatives). After I specify LDAP server ip address, base DN and connection DN and password in the app, now my users can log in using their LDAP info.

Now, suppose "myuser" with password "mypassword" logs into the application. What of the following occurs?

  1. The app receives the login request, then binds to LDAP using its very own credentials and then looks up the entry for the "myuser" and compares "mypassword" with the password stored in the LDAP directory for the matching entry, then allows or rejects the access.

  2. The app receives the login request, then passes the "myuser" and "mypassword" credentials to LDAP (bind DN and password) and then, depending on the response received for the binding operation, allows or rejects the user?

How does it really work?

1 Answer 1


As I understand it (and I'm not an expert on these matters) it's more like 1 than 2, but not exactly so. The app receives the login request. It binds to LDAP using its own credentials, the password being transmitted in clear (which is why LDAPS, or LDAP that escalates via TLS, is a good idea). These credentials must be sufficiently-privileged for the LDAP server to permit a search for various stored parameters relating to myuser's account, including the stored, hashed, user password.

The app then hashes mypassword, as presented by the user, and compares it to the hash returned from LDAP. If they match, it knows the credentials presented are good, and myuser is authenticated; if not, then not.

  • This is a very interesting question, I think I might dig into it a bit later. I suspect though, that it is possible to implement both ways and you can control which ldap entry properties are available for reading by the ldap connecting account. Need to check this though.
    – Gnudiff
    Dec 14, 2017 at 9:33
  • 1
    Allowing some bogus account to read passwords hashes is a security flaw. Basic recommended ACLs for OpenLDAP are pretty simple: allow administrators group and the user himself to read password field and no one else can have access to it. First, use app credentials (because anonymous bind may be and should be disabled) and perform user lookup, then (optional) perform filter search for group mapping check, and last use user credentials to bind, if the bind is successful then authorize him. Dec 14, 2017 at 11:36
  • @MichalSokolowski just to be clear, are you saying that the model as I describe it is poor, or that Gnudiff's model (use the authenticating account's credentials to bind) is poor?
    – MadHatter
    Dec 14, 2017 at 13:07
  • @MadHatter, with all due respect, I think both of them are. The behavior I just described is used for example in Samba's, proftpd's, OpenVPN's LDAP modules. It's based on analyzing both packet traces and OpenLDAP logs in the same time. As I understand it both of use cases presuppose the existence of some bogus LDAP account allowed to read password hashes which do not belong to them. And that is IMHO wrong. Dec 15, 2017 at 2:37
  • @MichalSokolowski that is clear, and your opinion is valuable and I welcome it. I disagree about the security implications: the cons of mine involve an account which lets the VPN server read hashes, but the pros are that the wide variety of credentials to be authenticated don't have to be retransmitted from the VPN server to the LDAP server. Whether the risks of the former outweigh the benefits of the latter will depend on your threat model, and that will change from site to site.
    – MadHatter
    Dec 15, 2017 at 7:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .