Jaap Winius <[email protected]> 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 -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E
