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
