On Sat, Aug 13, 2011 at 8:36 PM, Brian Burch <[email protected]> wrote: > 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.... > np, you are welcome > 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. > so far haven't found any clue on why this is happening (I have 1.5.4 source)
P.S:- it is not the right solution to say, but do you have any chance to upgrade to 2.0 M1, if yes, then I highly recommend it. > [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 > -- Kiran Ayyagari
