Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to configure openldap 2.4.33 (built from source on OS X 10.8) to support digest-md5 authentication, and not succeeding. I'm unable to authenticate, getting an error no secret in database, and I can't for the life of me work out why.

The configuration so far...

I have a user specified as follows:

dn: cn=eb01,ou=bennet,o=meryton
objectclass: Person
objectclass: inetOrgPerson
cn: eb01
givenname: Elizabeth
sn: Bennet
userPassword: pw1
# or try...
#userPassword:: cHcx
#userPassword: {CLEARTEXT}pw1

(and there are no trailing spaces there, I've checked!). I have appropriate olcAuthzRegexp entries configured for the cn=config, to map authentication identities to the right dn:

olcAuthzRegexp: uid=([^,]*),cn=digest-md5,cn=auth
  ldap:///o=meryton??sub?(cn=$1)

When I search, however, I'm unable to authenticate:

% ldapsearch -H ldap://localhost:8389 -LLL -b o=meryton \
      -Y DIGEST-MD5 -X u:eb01 -w pw1
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: SASL(-13): user not found: no secret in database
%

The debug chatter from the server suggests I'm doing the mapping correctly:

5120be85 <==slap_sasl2dn: Converted SASL name to cn=eb01,ou=bennet,o=meryton
5120be85 slap_sasl_getdn: dn:id converted to cn=eb01,ou=bennet,o=meryton
5120be85 SASL Canonicalize [conn=1000]: slapAuthzDN="cn=eb01,ou=bennet,o=meryton"
5120be85 SASL [conn=1000] Failure: no secret in database
5120be85 send_ldap_result: conn=1000 op=1 p=3
5120be85 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database"

However, while that chatter includes logs of access requests:

5120be85 => access_allowed: auth access to "cn=eb01,ou=bennet,o=meryton" "cn" requested

the chatter does not include any logs of access requests for the userPassword attribute.

That is, it appears as if the server, in this configuration, doesn't know that the userPassword attribute is the secret on which it should perform the digest-md5 authentication. I haven't configured that, but (a) I get the impression that this is the default secret, (b) I can't find anything in the manpages or openldap manual which appears to indicate how to configure this, and (c) can't find anything in the various bits of online advice which even hints that this is necessary.

Simple authentication is fine.

Now, this is a slightly odd configuration -- clear text passwords and no SASL database, because this is intended to be a dummy/lightweight LDAP configuration to run regression tests against -- but I've completely run out of ideas of what to read next, or any more keywords or log-file fragments to google for. No-one on the entire planet appears to have had this precise problem (it's not that exotic), so I'm suspecting I've somehow broken this with another part of the configuration. But I believe I understand what everything else in the configuration is doing, and ... there's nothing obvious.

I have the nasty feeling this is going to have a head-bashingly simple fix, but right now, I'm open to any ideas at all.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

That bang, bang, bang, bang you can hear is the sound of a head and a wall in glorious harmony.

The problem was not with the configuration, but with the request. In the ldapsearch invocation, I had -X u:eb01. But this is for proxy authorization; to bind with a specific username, one needs -U eb01.

Thank you Howard Chu in 2003.

share|improve this answer
    
I upvoted this not because it solved my problem, but because of the enjoyment of reading the whole thing and the prophetic resolution. :-) Thanks for the diversion from my own problem. –  flickerfly Jul 7 at 16:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.