Red Hat Bugzilla – Full Text Bug Listing
|Summary:||slapd crashes during SASL authentication|
|Product:||[Community] 389||Reporter:||MIchael Kolmodin <michael>|
|Component:||Directory Server||Assignee:||Rich Megginson <rmeggins>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Chandrasekar Kannan <ckannan>|
|Version:||7.1||CC:||benl, jgalipea, vtsuryawanshi|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-06-06 14:04:43 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description MIchael Kolmodin 2005-08-16 14:56:39 EDT
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): 7.1 How reproducible: Always 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. Additional info: This happens on Fedora core 4, updated to today's date.
Comment 2 Rich Megginson 2005-08-26 18:45:29 EDT
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.
Comment 3 MIchael Kolmodin 2005-08-29 11:22:21 EDT
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
Comment 4 MIchael Kolmodin 2005-08-29 11:24:48 EDT
Created attachment 118207 [details] /etc/ldap.conf
Comment 5 Rich Megginson 2005-08-29 11:32:50 EDT
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.
Comment 6 Kevin M. Myer 2005-10-06 13:10:34 EDT
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. https://www.redhat.com/archives/fedora-directory-users/2005-July/msg00186.html
Comment 7 Rich Megginson 2005-10-06 13:28:28 EDT
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.
Comment 8 Rich Megginson 2005-11-03 10:32:44 EST
Reviewed by: Noriko (Thanks!) Files: saslbind.c 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 done
Comment 9 Jenny Galipeau 2011-06-06 14:04:43 EDT
cloned bug verified and automated testing covers SASL authentications