directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <br...@pingtoo.com>
Subject Re: SASL authentication with DIGEST-MD5
Date Sat, 13 Aug 2011 15:06:32 GMT
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

Mime
View raw message