There’s an update coming below that might be subtitled: why using ldapcompare to check passwords isn’t such a good idea after all.
Most gui LDAP browsers come with some way of verifying user passwords (usually stored in the userpassword attribute). There’s also a CLI (command line) way of doing this, with ldapcompare.
The ldapcompare utility is a much neglected tool. One good use to which it can be put is in verifying “known” user passwords.
Syntax shown is for the OpenLDAP version that ships with Red Hat Enterprise Linux.
ldapcompare -x -h [ldaphost] -D [admin dn] -W [entry dn] userpassword:[known value]
ldapcompare -x -h myldap -D "cn=directory manager" "uid=myname,ou=people,dc=example,dc=com" userpassword:mypass123
If the “known value” is correct, you’ll get back a simple “TRUE”. Otherwise you’ll get “FALSE”.
I got a very thoughtfully worded response from Andrew Findlay of Skills 1st regarding this post that is worth sharing. Basically the gist of it was that using ldapcompare for this purpose is probably not a good idea because: (1) you need to be an admin to use it; (2) it won’t work where the password isn’t stored in an LDAP directory; (3) it requires you to reveal the clear text password on the command line; (4) there are better alternatives like ldapwhoami (or ldapsearch, etc).
All of these are good points that should be kept in mind. That last one is probably the most noteworthy. All of the OpenLDAP versions (as opposed to other vendors, like… Oracle) of the standard client tools allow you to use the -W switch. This causes the utility to prompt for a password that isn’t echoed back to the console. The second important point is that testing a password value by doing a bind operation as the target user can be done without admin privileges. You can use ldapwhoami, ldapsearch or any other utility for this. For example:
ldapsearch -x -h myldapserver.example.com -D "uid=auser,ou=people,dc=example,dc=com" -W -b "" -s base "objectclass=*"
will return an LDAP Error 49, “Invalid Credentials”, if the password is not what you think it is.
The only problem with this method is that enough failed attempts could result in the account being locked if there’s a password policy in place that enforces a limit such things. As I admitted in my reply today that’s really a straw man argument: unlocking an account should be child’s play for any competent admin.
So the bottom line is that while using ldapcompare to test passwords is an interesting exercise, it’s probably not such a good idea after all.
You cannot use ldapcompare to test password values that are SSHA (Salted Secure Hashing Algorithm) hashed. For many of us SSHA is the hashing method of choice because it’s way more secure than SHA. This enhanced security is achieved by using a “salt” (an additional value) during the hashing process that results in hashed strings that won’t match each other even where the plaintext submitted was identical.