directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: SASL authentication with DIGEST-MD5
Date Thu, 11 Aug 2011 19:42:37 GMT
On Thu, Aug 11, 2011 at 11:11 PM, Brian Burch <> 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 :]
> 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

View raw message