directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: SASL authentication with DIGEST-MD5
Date Sat, 13 Aug 2011 16:40:53 GMT
On Sat, Aug 13, 2011 at 8:36 PM, Brian Burch <brian@pingtoo.com> 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

Mime
View raw message