This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 166081 - slapd crashes during SASL authentication
slapd crashes during SASL authentication
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
n/a
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-16 14:56 EDT by MIchael Kolmodin
Modified: 2015-01-04 18:19 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-06 14:04:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/ldap.conf (6.83 KB, text/plain)
2005-08-29 11:24 EDT, MIchael Kolmodin
no flags Details

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.