Bug 166081

Summary: slapd crashes during SASL authentication
Product: [Retired] 389 Reporter: MIchael Kolmodin <michael>
Component: Directory ServerAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: medium    
Version: 7.1CC: benl, jgalipea, vtsuryawanshi
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: n/a
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-06 18:04:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
/etc/ldap.conf none

Description MIchael Kolmodin 2005-08-16 18:56:39 UTC
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):

How reproducible:

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 22:45:29 UTC
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 15:22:21 UTC
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 15:24:48 UTC
Created attachment 118207 [details]

Comment 5 Rich Megginson 2005-08-29 15:32:50 UTC
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 17:10:34 UTC
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.


Comment 7 Rich Megginson 2005-10-06 17:28:28 UTC
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 15:32:44 UTC
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

Comment 9 Jenny Galipeau 2011-06-06 18:04:43 UTC
cloned bug verified and automated testing covers SASL authentications