You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Brian Burch <br...@pingtoo.com> on 2011/08/11 19:41:22 UTC
SASL authentication with DIGEST-MD5
I've just started trying to use SASL DIGEST-MD5 to authenticate Studio
to my production apacheds 1.5.4 directory.
The authentication failed - [LDAP: error code 49 - INVALID_CREDENTIALS:
DIGEST-MD5: cannot acquire password for xxxx in realm : pingtoo.com]
I'm reasonably sure I have configured server.xml to match the
credentials for studio - a wireshark trace looks reasonable. I have
supplied a bare username, rather than the user's full DN - server.xml
has the correct search base. (Nevertheless, I get the same error message
when I specify the full DN.)
Searching the mail archive I found a comment that indicates the
userpassword attribute has to be supplied in cleartext, so I defined a
new user with an ldapmodify ldif. Studio tells me the new user really
has a cleartext password, and ldapsearch returns a base64 encoding of
the correct value, but the error is identical.
I have three relevant prescriptive aci's over the entire directory tree.
The first prohibits general access to user passwords; the second grants
it to member of the admins group; the third allows users to browse and
modify their own entries.
My first failing user (shown as xxxx above) is a member of the admins
group and can certainly read passwords of all users (including its own)
with ldapsearch and studio. However, I can already see this user will
not be able to authenticate using SASL because the directory entry only
holds a SHA hash at the moment.
The test user can do basic authentication against its own cleartext
password, but not with SASL. I am not 100% sure my third prescriptive
ACI is working, because this user can't retrieve its own password.
Without trawling the source, can anyone help me with some basic questions:
1. Does the error message mean the user entry was actually found (as
implied)?
2. Does the error message really mean the attribute value cannot be read
from the directory, or simply that a hash was made that did not match
the SASL response from the client?
3. Does the SASL logic run under the authenticating user's credentials
and is constrained by that user's ACI's? (I can't think what else it
could use except some kind of "super-user" privilege that puts it
outside the directory's ACI's).
Sorry to bother everyone, but thanks in anticipation of a clue or two!
Brian
Re: SASL authentication with DIGEST-MD5
Posted by Kiran Ayyagari <ka...@apache.org>.
On Sat, Aug 13, 2011 at 8:36 PM, Brian Burch <br...@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
Re: SASL authentication with DIGEST-MD5
Posted by Brian Burch <br...@pingtoo.com>.
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
Re: SASL authentication with DIGEST-MD5
Posted by Kiran Ayyagari <ka...@apache.org>.
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
HTH
On Sat, Aug 13, 2011 at 3:23 PM, Brian Burch <br...@pingtoo.com> wrote:
> On 12/08/11 16:12, Brian Burch wrote:
>>
>> I will try to do the test again tomorrow with debugging turned on unless
>> you see something useful above.
>
> Well, I am baffled. The debug log is quite big but doesn't tell me anything
> we didn't know already. I don't want to fill up the mail archive, so here is
> a summary:
>
> The SASL dialog progresses normally until the client response to the server
> challenge arrives, and is decoded without error.
>
> [10:24:08] DEBUG [org.apache.directory.shared.ldap.codec.TwixTransformer] -
> Transforming LdapMessage <2, BIND_REQUEST> from Twix to Snickers.
> [10:24:08] DEBUG [org.apache.directory.server.ldap.handlers.BindHandler] -
> Received: BindRequest
> Version : '3'
> Name : ''
> Sasl credentials
> Mechanism :'DIGEST-MD5'
> Credentials :
> 'charset=utf-8,username="uid=testDigest,ou=people,o=pingtoo.com",realm="pingtoo.com",nonce="G33N7OiolRjzUUPZ0rt9Xd+yekVkscWuLSGaTbpV",nc=00000001,cnonce="NLeTmnE3GMTyaUC7fm0PvSu6rLzCgdr5aNIZvGrj",digest-uri="ldap/ldap.pingtoo.com",maxbuf=65536,response=01f3099702d77231b7e00b0ce97ed1fd,qop=auth
> (hex snipped out)'
>
> Then only this is logged:
>
> [10:24:08] DEBUG
> [org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
> - Processing callback 1 of 3: {}class javax.security.sasl.RealmCallback
> [10:24:08] DEBUG
> [org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
> - RealmCallback default text: pingtoo.com
> [10:24:08] DEBUG
> [org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
> - Processing callback 2 of 3: {}class
> javax.security.auth.callback.NameCallback
> [10:24:08] DEBUG
> [org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
> - NameCallback default name: uid=testDigest,ou=people,o=pingtoo.com
> [10:24:08] DEBUG
> [org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
> - Processing callback 3 of 3: {}class
> javax.security.auth.callback.PasswordCallback
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '2.5.4.35' with id 'userPassword'
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry]
> - lookup with id2.5.4.35' of attributeType: <2.5.4.35, userPassword>
> [10:24:08] DEBUG
> [org.apache.directory.server.core.authn.AuthenticationInterceptor] -
> Operation Context: LookupContext for DN 'ou=people,ou=pingtoo.com',
> attributes : <>
> [10:24:08] DEBUG
> [org.apache.directory.server.core.partition.DefaultPartitionNexus] - Check
> if DN '2.5.4.11=people,2.5.4.11=pingtoo.com' exists.
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '0.9.2342.19200300.100.1.1' with id 'uid'
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '0.9.2342.19200300.100.1.1' with id 'uid'
> [10:24:08] 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>
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '0.9.2342.19200300.100.1.1' with id 'uid'
> [10:24:08] 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>
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '0.9.2342.19200300.100.1.1' with id 'uid'
> [10:24:08] 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>
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultNormalizerRegistry] -
> registered normalizer with oid: 2.5.13.2
> [10:24:08] DEBUG
> [org.apache.directory.server.schema.registries.DefaultOidRegistry] - looked
> up OID '0.9.2342.19200300.100.1.1' with id 'uid'
> [10:24:08] 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=uid=testdigest,ou=people,o=pingtoo.com)'
> [10:24:08] 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>
> [10:24:08] DEBUG
> [org.apache.directory.server.core.partition.DefaultPartitionNexus] - Check
> if DN '2.5.4.11=people,2.5.4.11=pingtoo.com' exists.
> [10:24:08] ERROR [org.apache.directory.server.ldap.handlers.BindHandler] -
> INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
> uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com
> [10:24:08] DEBUG [org.apache.directory.shared.ldap.codec.TwixTransformer] -
> Transforming message type BIND_RESPONSE
> [10:24:08] DEBUG [org.apache.directory.shared.ldap.codec.TwixTransformer] -
> Transformed message : LdapMessage
> message Id : 2
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched DN : ''
> Error message : 'INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire
> password for uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com'
>
>
> I've looked carefully for some trivial typo, but I can't find any. The user
> entry exists and holds a cleartext userpassword. The SASL authentication
> thread logged earlier that it was running as
>
> dn[n]: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>
> ... who definitely is able to read the user's password via studio or
> ldapsearch. Why can't it read the userpassword within the SASL
> authentication dialogue?
>
> I don't have a debugger environment set up, so it will take me quite a while
> before I'm able to step through the source at the time of the error.
>
>
--
Kiran Ayyagari
Re: SASL authentication with DIGEST-MD5
Posted by Brian Burch <br...@pingtoo.com>.
On 12/08/11 16:12, Brian Burch wrote:
> I will try to do the test again tomorrow with debugging turned on unless
> you see something useful above.
Well, I am baffled. The debug log is quite big but doesn't tell me
anything we didn't know already. I don't want to fill up the mail
archive, so here is a summary:
The SASL dialog progresses normally until the client response to the
server challenge arrives, and is decoded without error.
[10:24:08] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
LdapMessage <2, BIND_REQUEST> from Twix to Snickers.
[10:24:08] DEBUG [org.apache.directory.server.ldap.handlers.BindHandler]
- Received: BindRequest
Version : '3'
Name : ''
Sasl credentials
Mechanism :'DIGEST-MD5'
Credentials :
'charset=utf-8,username="uid=testDigest,ou=people,o=pingtoo.com",realm="pingtoo.com",nonce="G33N7OiolRjzUUPZ0rt9Xd+yekVkscWuLSGaTbpV",nc=00000001,cnonce="NLeTmnE3GMTyaUC7fm0PvSu6rLzCgdr5aNIZvGrj",digest-uri="ldap/ldap.pingtoo.com",maxbuf=65536,response=01f3099702d77231b7e00b0ce97ed1fd,qop=auth
(hex snipped out)'
Then only this is logged:
[10:24:08] DEBUG
[org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
- Processing callback 1 of 3: {}class javax.security.sasl.RealmCallback
[10:24:08] DEBUG
[org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
- RealmCallback default text: pingtoo.com
[10:24:08] DEBUG
[org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
- Processing callback 2 of 3: {}class
javax.security.auth.callback.NameCallback
[10:24:08] DEBUG
[org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
- NameCallback default name: uid=testDigest,ou=people,o=pingtoo.com
[10:24:08] DEBUG
[org.apache.directory.server.ldap.handlers.bind.AbstractSaslCallbackHandler]
- Processing callback 3 of 3: {}class
javax.security.auth.callback.PasswordCallback
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '2.5.4.35' with id 'userPassword'
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry]
- lookup with id2.5.4.35' of attributeType: <2.5.4.35, userPassword>
[10:24:08] DEBUG
[org.apache.directory.server.core.authn.AuthenticationInterceptor] -
Operation Context: LookupContext for DN 'ou=people,ou=pingtoo.com',
attributes : <>
[10:24:08] DEBUG
[org.apache.directory.server.core.partition.DefaultPartitionNexus] -
Check if DN '2.5.4.11=people,2.5.4.11=pingtoo.com' exists.
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[10:24:08] 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>
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[10:24:08] 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>
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[10:24:08] 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>
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultNormalizerRegistry] -
registered normalizer with oid: 2.5.13.2
[10:24:08] DEBUG
[org.apache.directory.server.schema.registries.DefaultOidRegistry] -
looked up OID '0.9.2342.19200300.100.1.1' with id 'uid'
[10:24:08] 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=uid=testdigest,ou=people,o=pingtoo.com)'
[10:24:08] 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>
[10:24:08] DEBUG
[org.apache.directory.server.core.partition.DefaultPartitionNexus] -
Check if DN '2.5.4.11=people,2.5.4.11=pingtoo.com' exists.
[10:24:08] ERROR [org.apache.directory.server.ldap.handlers.BindHandler]
- INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com
[10:24:08] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transforming
message type BIND_RESPONSE
[10:24:08] DEBUG
[org.apache.directory.shared.ldap.codec.TwixTransformer] - Transformed
message : LdapMessage
message Id : 2
BindResponse
Ldap Result
Result code : (INVALID_CREDENTIALS) invalidCredentials
Matched DN : ''
Error message : 'INVALID_CREDENTIALS: DIGEST-MD5: cannot
acquire password for uid=testDigest,ou=people,o=pingtoo.com in realm :
pingtoo.com'
I've looked carefully for some trivial typo, but I can't find any. The
user entry exists and holds a cleartext userpassword. The SASL
authentication thread logged earlier that it was running as
dn[n]: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
... who definitely is able to read the user's password via studio or
ldapsearch. Why can't it read the userpassword within the SASL
authentication dialogue?
I don't have a debugger environment set up, so it will take me quite a
while before I'm able to step through the source at the time of the error.
Re: SASL authentication with DIGEST-MD5
Posted by Brian Burch <br...@pingtoo.com>.
On 11/08/11 20:42, Kiran Ayyagari wrote:
>> 1. Does the error message mean the user entry was actually found (as
>> implied)?
> yes, indeed
>> 2. Does the error message really mean the attribute value cannot be read
>> from the directory, or simply that a hash was made that did not match the
>> SASL response from the client?
> as you already mentioned that the password is in clear text so there
> seems to be some other factor that is causing this
> but which is not entirely clear to me at the moment
>> 3. Does the SASL logic run under the authenticating user's credentials and
>> is constrained by that user's ACI's? (I can't think what else it could use
>> except some kind of "super-user" privilege that puts it outside the
>> directory's ACI's).
> no the attribute fetching is done by using the admin session, (for
> this the default internal admin
> account uid=admin,ou=system is used)
Thanks very much for your clear and helpful answers, Kiran. You have
saved me a lot of time.
> do you have any stack traces on the server logs?
Here is the test user entry as seen by a directory administrator:
#
# LDAPv3
# base <o=PingToo.com> with scope subtree
# filter: (&(objectclass=top)(uid=testDigest))
# requesting: cn sn givenName ou userPassword dontcare
#
# testdigest, People, PingToo.com
dn: uid=testdigest,ou=People, o=PingToo.com
givenname: Brian
cn: Brian Testing Digest
sn: ClearPassword
userpassword:: c2VjcmV0
ou: People
# search result
# numResponses: 2
# numEntries: 1
search ended with rc 0
... and then the cleartext password is...
echo c2VjcmV0 | base64 -d -
secret
Using Directory Studio authenticating as this test user and NO
encryption, when I click the "check network parameter" button, the
connection is established successfully.
On the authentication tab, DIGEST-MD5, correct bindDN, password and SASL
realm, QOP is authentication only and strength is high. When I click the
"check authentication button" it fails with this:
The authentication failed
- [LDAP: error code 49 - INVALID_CREDENTIALS: DIGEST-MD5: cannot
acquire password for uid=testDigest,ou=people,o=pingtoo.com in realm :
pingtoo.com]
javax.naming.AuthenticationException: [LDAP: error code 49 -
INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3041)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2602)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2576)
at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2572)
at
javax.naming.ldap.InitialLdapContext.reconnect(InitialLdapContext.java:173)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper$7.run(JNDIConnectionWrapper.java:1055)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.runAndMonitor(JNDIConnectionWrapper.java:1272)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.doBind(JNDIConnectionWrapper.java:1065)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.bind(JNDIConnectionWrapper.java:254)
at
org.apache.directory.studio.connection.core.jobs.CheckBindRunnable.run(CheckBindRunnable.java:80)
at
org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:123)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
The server's wrapper.log and also the rolling log have only these two
messages:
INFO | jvm 1 | 2011/08/12 15:54:45 | [15:54:45] INFO
[org.apache.directory.server.ldap.handlers.BindHandler] - Continuation
token had length 167
INFO | jvm 1 | 2011/08/12 15:54:45 | [15:54:45] ERROR
[org.apache.directory.server.ldap.handlers.BindHandler] -
INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com
How easy would it be to turn on more messages from the server... do I
just need to change the log4j properties to say:
log4j.logger.org.apache.directory.shared.ldap.name=DEBUG
I will try to do the test again tomorrow with debugging turned on unless
you see something useful above.
Brian
Re: SASL authentication with DIGEST-MD5
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Aug 11, 2011 at 11:11 PM, Brian Burch <br...@pingtoo.com> wrote:
> I've just started trying to use SASL DIGEST-MD5 to authenticate Studio to my
> production apacheds 1.5.4 directory.
>
> The authentication failed - [LDAP: error code 49 - INVALID_CREDENTIALS:
> DIGEST-MD5: cannot acquire password for xxxx in realm : pingtoo.com]
>
> I'm reasonably sure I have configured server.xml to match the credentials
> for studio - a wireshark trace looks reasonable. I have supplied a bare
> username, rather than the user's full DN - server.xml has the correct search
> base. (Nevertheless, I get the same error message when I specify the full
> DN.)
>
> Searching the mail archive I found a comment that indicates the userpassword
> attribute has to be supplied in cleartext, so I defined a new user with an
> ldapmodify ldif. Studio tells me the new user really has a cleartext
> password, and ldapsearch returns a base64 encoding of the correct value, but
> the error is identical.
>
>
> I have three relevant prescriptive aci's over the entire directory tree. The
> first prohibits general access to user passwords; the second grants it to
> member of the admins group; the third allows users to browse and modify
> their own entries.
>
> My first failing user (shown as xxxx above) is a member of the admins group
> and can certainly read passwords of all users (including its own) with
> ldapsearch and studio. However, I can already see this user will not be able
> to authenticate using SASL because the directory entry only holds a SHA hash
> at the moment.
>
> The test user can do basic authentication against its own cleartext
> password, but not with SASL. I am not 100% sure my third prescriptive ACI is
> working, because this user can't retrieve its own password.
>
>
> Without trawling the source, can anyone help me with some basic questions:
>
> 1. Does the error message mean the user entry was actually found (as
> implied)?
>
yes, indeed
> 2. Does the error message really mean the attribute value cannot be read
> from the directory, or simply that a hash was made that did not match the
> SASL response from the client?
>
as you already mentioned that the password is in clear text so there
seems to be some other factor that is causing this
but which is not entirely clear to me at the moment
> 3. Does the SASL logic run under the authenticating user's credentials and
> is constrained by that user's ACI's? (I can't think what else it could use
> except some kind of "super-user" privilege that puts it outside the
> directory's ACI's).
>
no the attribute fetching is done by using the admin session, (for
this the default internal admin
account uid=admin,ou=system is used)
> Sorry to bother everyone, but thanks in anticipation of a clue or two!
>
> Brian
>
do you have any stack traces on the server logs?
--
Kiran Ayyagari