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 ~$ _
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) ~$ _
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _
The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above.
This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be?
Thanks,
Jaap
As stated by ldap* tools... error 49 Invalid credentials so you're misstyping either the DN or the password (or both)
Jaap Winius 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 ~$ _
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) ~$ _
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _
The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above.
This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be?
Thanks,
Jaap
Jaap Winius 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.
Hello,
[originally intended reply] I'll just shoot here, but isn't it because this command works only for SASL-related stuff [authzid]? Thus some appropriate stuff like rewriting [?] is needed in slapd.conf etc. etc. ? I'm not familiar with SASL or this command, but that's what I've got from man page. [/originally ...] None of it is probably true.
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
### ACL ## Users can change their own passwords. Other users can attempt to authenticate, but ## can't read the userPassword value. access to attrs=userPassword by ssf=128 self write by ssf=64 * auth
access to dn.base="" by * read
access to * by dn="cn=admin,dc=umrk,dc=nl" write by * read
I have +'by anonymous auth' here.
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 ~$ _
I get same result.
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) ~$ _
However, this works for me and returns the correct DN. We're using nss-ldap and nscd. About being -D "useless". No, it's not. LDAP is not all-knowing and it can't tell if it is "cn=testuser,dc..." or "uid=testuser,dc..." or "uid=testuser,ou=people,..." and so on so forth. But it depends on how and with "what" % ldapwhoami; works with. Probably somebody else will clarify this one (?).
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _
The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above.
It sounds to me you've mis-configured ACL somewhere. If you have only these three ACL, how about to start over? Comment them out and add one by one. I know it's not the straight solution, but-
This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be?
Thanks,
Jaap
Regards, Zdenek
Jaap Winius jwinius@umrk.nl writes:
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 ~$ _
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) ~$ _
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _
The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above.
This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be?
Here are some variations of presenting credentials to ldapwhoami, the result is the same entry. Ldapwhoami is quite helpful in debugging authz-regexp errors and proxy authentication.
1. simple bind with DN and password ldapwhoami -D "cn=dieter kluenter,ou=partner,o=avci,c=de" -W -H ldapi:/// dn:cn=Dieter Kluenter,ou=Partner,o=avci,c=de
2. SASL bind with EXTERNAL sasl mechanism on local socket ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de
3. SASL bind with EXTERNAL sasl mechanism and X.509 certificate ldapwhoami -Y EXTERNAl -ZZ -H ldap://localhost SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de
4. SASL bind with DIGEST-MD5 sasl mechanism ldapwhoami -Y DIGEST-MD5 -U dieter -w secret -H ldapi:/// SASL/DIGEST-MD5 authentication started SASL username: dieter SASL SSF: 128 SASL data security layer installed. dn:cn=dieter kluenter,ou=partner,o=avci,c=de
5. proxy authentication with SASL bind of proxy user ldapwhoami -Y DIGEST-MD5 -U admanager -X u:dieter -W -H ldap://localhost SASL/DIGEST-MD5 authentication started SASL username: u:dieter SASL SSF: 128 SASL data security layer installed. dn:cn=dieter kluenter,ou=partner,o=avci,c=de
-Dieter
--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 * readMy 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
On Monday, 14 December 2009 02:04:23 Jaap Winius 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 * readMy 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 ~$ _
Well, you are doing an anonymous simple bind here, so the result is expected, and may have ended up showing you something you had incorrectly assumed would magically do something, does not.
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),
Well, you may just want to test that authentication *is* working the way you intended, without doing a search.
I get this error:
~$ ldapwhoami -x -D "cn=testuser,dc=umrk,dc=nl" -w testpass ldap_bind: Invalid credentials (49) ~$ _
So, now you know your DN or password is wrong, or your ACLs don't allow simple authtentication. Which should make you wonder how your "login" is working. It may not be the way you think it is working ...
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _The "ldapsearch" command is the same: I can get a response when binding anonymously ("-x"), as well as when binding as the admin user, but not when I use a normal user account, which results in the same error 49 as above.
This behavior seems rather useless to me. Surely I've made a mistake somewhere. Can anyone say what it might be?
Well, in the case of an environment with only simply binds, the only utility of ldapwhoami is to test authentication (and, account policy status with -E ppolicy option).
However, in environments where other types of binds are available (e.g., SASL GSSAPI, SASL EXTERNAL), you may want to be able to test that you get the DN you should (from your Kerberos ticket, SSL certificate, user/group). In the case where OpenLDAP is the server, this may help when testing sasl-regexp's.
E.g.:
# ldapwhoami SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:uid=account admin,ou=system accounts,dc=ranger,dc=dnsalias,dc=com
[bgmilne@tiger ~]$ ldapwhoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: bgmilne@RANGER.DNSALIAS.COM SASL SSF: 56 SASL data security layer installed. dn:uid=bgmilne,ou=people,dc=ranger,dc=dnsalias,dc=com
Regards, Buchan
Quoting Jaap Winius jwinius@umrk.nl:
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) ~$ _
I've discovered that I was making a stupid mistake. I should have done:
~$ ldapwhoami -x -D "uid=testuser,dc=umrk,dc=nl" -w testpass dn:uid=testuser,dc=umrk,dc=nl ~$
Both of these DNs exist, but only the second one has a password (objectClass: posixAccount, objectClass: shadowAccount). The DN I used earlier is for the group entry (objectClass: posixGroup).
On the other hand, this does work if I supply the admin DN and password:
~$ ldapwhoami -x -D "cn=admin,dc=umrk,dc=nl" -w adminpass dn:cn=admin,dc=umrk,dc=nl ~$ _
It worked straight away for the LDAP administrator's DN, because it does have a password. It is "objectClass: organizationalRole" and there is no "uid=admin,dc=umrk,dc=nl".
I still don't understand why the utility of ldapwhoami is limited when using simple binds, but I guess that's just the way it is.
Thanks to Luca, Zdenek, Dieter, Quanah and Buchan.
Cheers,
Jaap
openldap-technical@openldap.org
-
Buchan Milne -
Dieter Kluenter -
Jaap Winius -
Luca Scamoni -
Quanah Gibson-Mount -
Zdenek Styblik