directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject SASL authentication with DIGEST-MD5
Date Thu, 11 Aug 2011 17:41:22 GMT
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 :]

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 

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!


View raw message