Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I can browse the user details of an existing LDAP directory using a bind DN and bind password. I cannot find any entry storing the users password. Is it possible that password attributes are hidden from the bind account I used to connect to the MSAD LDAP? If no, then does LDAP store the passwords separately elsewhere?

I plan to configure my application to authenticate users based on this LDAP.

share|improve this question
    
Completely depends on the LDAP server. AD does one thing OpenLDAP does something else. –  Zoredache May 16 '13 at 8:31
    
Hi @Zoredache - I updated the question.. I am working with MSAD. I thought that possibly all LDAP directory service providers used a common scheme for storing/managing user account credentials. –  Kent Pawar May 16 '13 at 8:39

2 Answers 2

up vote 1 down vote accepted

I plan to configure my application to authenticate users based on this LDAP.

The correct way to authenticate ldap account is to simply try binding to the ldap server with the credenrials. For some servers you need to provide the full distinguished name based to login. So you will need to setup an account to lookup the DN given some other identifier.

Where are the credentials stored.

Most servers store a hash in an attribute named 'password'. But ACLs are set on this attribute so nobody can read it. Microsoft simply does not permit reading the password hash at all via LDAP as a security feature. It can only be set over an LDAPS connection, that is LDAP in SSL. Setting up windows to support LDAPS takes creating a CA or buying certificates.

share|improve this answer
    
Thanks for the explanation! Yes I have setup a bind account just for that.. so the application uses it to bind with LDAP server and validate the credentials. –  Kent Pawar May 16 '13 at 10:31

In general, while attributes may look like attributes in any LDAP system, the password attribute is almost always a special case. Perhaps it is restricted by the LDAP server as a special case. Perhaps ACL's protect it. Perhaps it is write-able, but not readable.

Often there are actually several password attributes (AD has unicodePassword and userPassword), and it kind of depends which is to be used in which case. Novell/NetIQ eDirectory has userPassword, which depends on how you are configured, as to what value is underneath it (RSA keypairs, nspmPassword, or the simple password, which is an even odder case than a simple attribute, as it is stored in pieces across multiple attributes)

Some LDAP servers will let you bind with a hashed value, that matches the hashed value stored and the hashed value might be retrievable, but not reversible.

But the key is, it should not matter. Since every LDAP server is different you need to use the standards approach to LDAP passwords which is to try and Bind as a user with the provided DN and password. And if they do not provide a DN, do a search for uid=Username or cn=username or whatever your naming attribute is, to find the full DN.

Finally, be aware that the LDAP standard says a bind with a blank password will succeed, but as an anonymous connection. So you need to be sure the passwords you allow are not blank, else you will get a successful bind, and possibly let someone in, unwittingly.

share|improve this answer
    
+1. Thank you @geoffc. This is very informative. –  Kent Pawar Aug 1 '13 at 11:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.