The typical process for testing authentication in LDAP is:

1. Bind as an application user account
2. Search for the user's dn based on their uid (may have additional restrictions, eg, we had a 'hostname' multivalue attribute that listed which machines the user was allowed on, so I'd search for the equivalent of &(uid=username)(hostname=machine))
3. Attempt to bind as the user w/ their password

It seems like it's a lot of work -- eg, you could just form the DN from the uid and the base, but this prevents you from being able to handle hierarchies in your tree. (eg, you might have 2 groups of accounts under different OUs). You also can't read the userPassword attribute unless you're either bound as that user, or you give your application user extra access ... which is dangerous. You'd also have to parse the userPassword, which could be:

• {hashtype}hashedpassword
• plaintext

As the password encryption is done when the password's written, it's entirely possible for there to be more than one type of encryption used in the LDAP server. (including plaintext passwords, which is all the more reason to not have application users able to read the attribute directly). Every time toy upgrade your LDAP server, you'd have the change of it using a new encryption, and your authentication checks suddenly failing if you're attempting to parse userPasssword.