--On Monday, December 14, 2009 2:04 AM +0100 Jaap Winius jwinius@umrk.nl wrote:
Hi all,
The utility of the "ldapwhoami" tool is a mystery to me. As opposed to the usual Unix "whoami" command, which prints the effective userid, "ldapwhoami" doesn't seem to print the matching LDAP DN... at least not for me.
My test setup includes an OpenLDAP server and a separate client. The server's slapd.conf includes these ACLs:
access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=umrk,dc=nl" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=umrk,dc=nl" write by * read
My LDAP DIT includes an account for a normal user with a password. Without any problem I can use this to login to the client host, but when I want to test, or verify, the account's LDAP DN, all I get is this:
~$ ldapwhoami -x anonymous ~$ _
So you did an anonymous bind, and it confirmed you are anonymous...
Even stranger, if I supply the account's DN and password (although this would seem a useless thing to do, since it's the very same info I'm asking for), I get this error:
~$ ldapwhoami -x -D "cn=testuser,dc=umrk,dc=nl" -w testpass ldap_bind: Invalid credentials (49)
This indicates that the password for your testuser is *not* testpass
Error 49 = invalid credentials. I.e., bad password.
The main point of ldapwhoami is to (a) verify passwords (which obviously you have wrong here) or to ensure that *SASL* mappings, which you aren't using, give you the expected result, such as:
tribes:~> ldapwhoami -h ldap.stanford.edu SASL/GSSAPI authentication started SASL username: quanah@stanford.edu SASL SSF: 56 SASL installing layers dn:uid=quanah,cn=accounts,dc=stanford,dc=edu Result: Success (0)
So, as you can see, my quanah@stanford.edu credentials map me to the uid=quanah,cn=accounts,dc=stanford,dc=edu entry.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration