Red Hat Bugzilla – Bug 166081
slapd crashes during SASL authentication
Last modified: 2015-01-04 18:19:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
Happens when trying to enable SASL authentication. After issuing
$ldapsearch -Y digest-md5 -U "dn:employeeNumber=1,ou=people,dc=lss,dc=bd,dc=se" -w 1 -s sub -b "ou=people,dc=lss,dc=bd,dc=se" '(employeeNumber=1)'
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
the server is just dead. Tail of errorlog is:
[16/Aug/2005:20:34:48 +0200] - sasl(5): DIGEST-MD5 server step 1[16/Aug/2005:20:34:48 +0200] - sasl(5): DIGEST-MD5 server step 2
The last line is incomplete, no newline in place.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start server
2. issue ldapsearch command as described above
Actual Results: slapd dead
Expected Results: Successful (or failed) bind operation, slapd running.
This happens on Fedora core 4, updated to today's date.
What setup did you perform on the server? I tried to reproduce this bug without
doing anything on the server - I just started the server, added the user entries
(password hashed in SSHA), and executed an ldapsearch as you described. I got
this error message:
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
Which is what I would expect, since the password was not in clear text.
To be honest, I don't have complete control of what I've done. It happened while
I was trying to enable SASL. At first, the system did not recognize my dn and
there was no crash. The crash happened when I had configured for a while.
At least, I have configured /etc/ldap.conf. I enclose that file a starter. I can
still reproduce the crash, so just tell me what you need from my configuration I
will try to hand it to you
Created attachment 118207 [details]
There's not much in that file, so I don't think that's related to the problem.
What I would really like to know is how you enabled SASL on the server. In
other words, you said "It happened while I was trying to enable SASL" - did you
mean on the client side or on the server side? I don't know that there is much
needed to be done on the server side to enable SASL DIGEST-MD5, except that the
users' passwords must be in clear text.
I had a similar issue that I reported to the list in July. I was in very early
testing stages that that point and had not touched anything SASL related. Just
trying to do a ldapsearch and forgot to add the -x argument to ldapsearch.
I think I found the problem. The source code is checked in, if you want to
build it yourself, or we will be releasing another binary soon.
Reviewed by: Noriko (Thanks!)
Fix Description: When we build cyrus-sasl on RHEL, we tell it to use
berkeley db for its sasldb database. It uses whatever version of
berkeley db is installed in the system. On RHEL3, this is usually
libdb-4.1. However, at runtime, slapd uses 4.2, leading to conflicts.
This doesn't happen on RHEL4 because it already has 4.2 on it. The db
is used to lookup auxiliary properties (auxprop) related to the user,
such as password or whatever. This happens in sasl after the user is
looked up. In our server, the way we use it, we don't care about these
auxprops, or we get them in another way. If you don't tell sasl which
auxprop plugin you want to use, it tries to use all of them, which means
it will attempt to use the sasldb plugin, which will lead to the crash.
The solution is to add our own auxprop plugin which is just a dummy that
does nothing, and tell sasl to use our plugin.
Platforms tested: RHEL3, RHEL4
Flag Day: no
Doc impact: no
Checking in saslbind.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/saslbind.c,v <-- saslbind.c
new revision: 1.11; previous revision: 1.10
cloned bug verified and automated testing covers SASL authentications