On 13/08/11 14:26, Kiran Ayyagari wrote:
Hi Brian,
found the issue, you are using the full DN as user name instead
just use the 'testdigest' alone as the username.
P.S:- there is a bit of valuable information logged in :)
Operation Context: SearchContext for DN 'ou=people,ou=pingtoo.com', filter
:'(0.9.2342.19200300.100.1.1=uid=testdigest,ou=people,o=pingtoo.com)'<----- see
the wrong filter
but it was difficult to trace it until I reproduced the issue and
checked the logs
Kiran,
I am so grateful that you are helping me resolve this problem. I
honestly do not think we are looking for a bug - just a setup problem in
my own configuration. I didn't want you to waste a lot of time, and I am
sorry you tried to reproduce my problem....
In my first post I mentioned that I had found a comment on the mailing
list that said one should code the "bare" username, BUT that my tests
had failed with both that and a FQDN.
Rather than just say so, I went back and reconfigured as you suggested
and.... no difference, as expected.
[15:19:29] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
LdapMessage <2, BIND_REQUEST> from Twix to Snickers.
[15:19:29] DEBUG [org.apache.directory.server.ldap.handlers.BindHandler]
- Received: BindRequest
Version : '3'
Name : ''
Sasl credentials
Mechanism :'DIGEST-MD5'
Credentials :
'charset=utf-8,username="testDigest",realm="pingtoo.com",nonce="7CSePi+QqIRcYUYFvZXkskGQ4JeFWy3XYHt8j6NJ",nc=00000001,cnonce="5YzeVnN1icid65YatG6miIvB4yL83k/57inp+rty",digest-uri="ldap/ldap.pingtoo.com",maxbuf=65536,response=62199b7a9ba6f4e51e0959a115e311bb,qop=auth/
(hex snipped)'
...and...
[15:19:29] DEBUG
[org.apache.directory.server.core.authn.AuthenticationInterceptor] -
Operation Context: SearchContext for DN 'ou=people,ou=pingtoo.com',
filter :'(0.9.2342.19200300.100.1.1=testdigest)'
[15:19:29] DEBUG
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry]
- lookup with id0.9.2342.19200300.100.1.1' of attributeType:
<0.9.2342.19200300.100.1.1, uid>
[15:19:29] DEBUG
[org.apache.directory.server.core.partition.DefaultPartitionNexus] -
Check if DN '2.5.4.11=people,2.5.4.11=pingtoo.com' exists.
[15:19:29] ERROR [org.apache.directory.server.ldap.handlers.BindHandler]
- INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
testDigest in realm : pingtoo.com
Because I am quite paranoid, I even went back through the logs to verify
the oid used in the search filter really does correspond to the uid
attribute:
[15:19:09] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[15:19:09] DEBUG
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry]
- lookup with id0.9.2342.19200300.100.1.1' of attributeType:
<0.9.2342.19200300.100.1.1, uid>
With full debugging turned on, I am surprised the log doesn't show the
inner workings of the search request. I remember that you told me the
error message meant the user entry had been found, but I'm surprised the
log doesn't say how many objects matched the search criteria, let alone
listing their DNs and returned attributes.
So far, the "evidence" says:
a) the user entry was found.
b) the search ran as uid=admin,ou=system (which can definitely read the
userpassword).
c) the userpassword value exists (and is in cleartext).
d) the BindHandler "cannot acquire password".
This evidence is not consistent!
Just to show the depth of my paranoia, I scraped the BindHandler search
arguments from the log file and then ran this BindHandler ldapsearch as
admin to simulate the process (which worked fine as you can see):
brian@schizo:~/sandboxShiraz/LdapPingToo/setup/10-peopleAndThings$
./13-adminReadPwdTestByOid.sh
ldap_initialize( ldap://shiraz.pingtoo.com:10389 )
filter: (&(objectclass=organizationalUnit)(2.5.4.11=people))
requesting: objectclass ou
version: 1
#
# LDAPv3
# base <o=pingtoo.com> with scope subtree
# filter: (&(objectclass=organizationalUnit)(2.5.4.11=people))
# requesting: objectclass ou
#
# people, PingToo.com
dn: ou=people,o=PingToo.com
objectClass: organizationalUnit
objectClass: top
ou: People
# search result
# numResponses: 2
# numEntries: 1
search ended with rc 0
ldap_initialize( ldap://shiraz.pingtoo.com:10389 )
filter: (0.9.2342.19200300.100.1.1=testDigest)
requesting: uid userPassword
version: 1
#
# LDAPv3
# base <ou=people,o=PingToo.com> with scope subtree
# filter: (0.9.2342.19200300.100.1.1=testDigest)
# requesting: uid userPassword
#
# testdigest, People, PingToo.com
dn: uid=testdigest,ou=People, o=PingToo.com
uid: testdigest
userpassword:: c2VjcmV0
# search result
# numResponses: 2
# numEntries: 1
search ended with rc 0
