Bug 173770 - Bugs in /etc/init.d/ldap - Kerberos/SASL broken
Bugs in /etc/init.d/ldap - Kerberos/SASL broken
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
http://www.cdkkt.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-20 15:56 EST by Dan Thurman
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-24 09:07:34 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)
My ladp configuration file (1.80 KB, text/plain)
2005-11-21 18:35 EST, Dan Thurman
no flags Details
My ladp configuration file, access file (3.58 KB, text/plain)
2005-11-21 18:36 EST, Dan Thurman
no flags Details

  None (edit)
Description Dan Thurman 2005-11-20 15:56:04 EST
There is a problem/bug with /etc/init.d/ldap script from the original FC4 
distribution.

1) line 74: 'klist' should read: $klist because it is a pathname variable
so klist fails to run

2) I am running kerberos with SASL. Per openldap recommendations it is 
requested that we use a seperate ldap keytab (ldap.keytab for security 
reasons), and setting the KRB5_KTNAME variable in /etc/sysconfig/ldap that does 
get pulled in, but this varaible is somehow not getting "passed" to the slapd 
program.

In function start(), I suspect that the daemon() function obtained from 
the /etc/init.d/functions file apparently fails to pass the KRB5_KTNAME 
environment to the slapd program.  By-passing daemon() and running slapd 
directly temporarily fixes the problem.

======================================================================
REPRODUCABILITY: Everytime.
======================================================================

STEPS TO REPRODUCE:
===================
1.Install and configure kerberos
2.Install and configure ldap w/ SSL and SASL support and add ldap/ host/ keys 
to /etc/openldap/ldap.keytab
3. Add - export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" 
to /etc/sysconfig/ldap 
4. Obtain a ticket (kinit)
5.Invoke: (SASL Authorization, no encryption)
  ldapsearch -H ldap://ldap.MYDOMAIN.com/ -b dc=mydomain,dc=com
=====================================================================

ACTUAL RESULTS:
===============
# ldapsearch -H ldap://ldap.MYDOMAIN.com/ -b dc=mydomain,dc=com
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
        additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous 
failure (Resource temporarily unavailable)
==========================================================================

EXPECTED RESULTS:
=================
# ldapsearch -H ldap://ldap.MYDOMAIN.com/ -b dc=mydomain,dc=com
SASL/GSSAPI authentication started
SASL username: admin/admin@MYREALM.COM
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <dc=mydomain,dc=com> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

...  dump of all ldap records
==========================================================================

ADDITIONAL INFORMATION:
=======================
Following is temporary script I am using to get all ldap invocations to work, 
i.e. with SSL/TLS, SASL and with ldap, ldaps

======================================================
#!/bin/bash

# =================================================
# TEMPORARY FIX BY DBT: ORIGINAL IS BROKEN!
# =================================================

# Source function library.
. /etc/init.d/functions

# Source an auxiliary options file if we have one, and pick up OPTIONS,
# SLAPD_OPTIONS, SLURPD_OPTIONS, SLAPD_LDAPS, SLAPD_LDAPI, and maybe
# KRB5_KTNAME.
if [ -r /etc/sysconfig/ldap ] ; then
        . /etc/sysconfig/ldap
fi

slapd=/usr/sbin/slapd
[ -x ${slapd} ] || exit 0

user=ldap
url="ldap:/// ldaps:///" 
prog=`basename ${slapd}`

RETVAL=0

function start() {

  # Start daemons.
  echo -n "Starting ${prog} "
  slapd -u ldap -h "ldap:/// ldaps:///"
  [ "$?" -eq 0 ] && success $"$base startup" || failure $"$base startup"
  RETVAL=$?
  echo

}

function stop() {

  killproc ${slapd}
  RETVAL=$?
  echo 'Stopped '${prog}

}

case "$1" in
      start)
        start
        ;;
       stop)
        stop
        ;;
    restart)
        stop
        start
        ;;
     status)
        status ${slapd}
        ;;
          *)
        echo "Usage: $0 {start|stop|restart|status}"
esac

exit $RETVAL
======================================================================

SEVERITY:
=========
Normal: It's a bug that should be fixed.
Comment 1 Jay Fenlason 2005-11-21 17:06:18 EST
1) ldap.init has had this typo fixed in rawhide since 
revision 1.16 
date: 2005/08/05 17:51:39;  author: nalin;  state: Exp;  lines: +1 -1 
- fix typo in ldap.init (call $klist instead of klist, from Charles Lopes) 
---------------------------- 
 
 
2) To see if KRB5_KTNAME was successfully passed to slapd, you can start it 
using the standard FD init scripts, then find the process ID of slapd, and run 
"od -c /proc/{slapd}/environ"  If KRB5_KTNAME appears there, the daemon() 
function didn't strip it, and the problem lies elsewhere.  I can confirm that 
on my FC-4 box, KRB5_KTNAME gets passed correctly to slapd, using 
openldap-2.2.29-1.FC4 and initscripts-8.11.1-1.  To debug further, I'll need a 
copy of your /etc/openldap/slapd.conf 
Comment 2 Dan Thurman 2005-11-21 18:35:22 EST
Created attachment 121322 [details]
My ladp configuration file

This is my /etc/openldap/slapd.config file as requested
Comment 3 Dan Thurman 2005-11-21 18:36:27 EST
Created attachment 121323 [details]
My ladp configuration file, access file

This is part 2, slapd.conf access file
Comment 4 Dan Thurman 2005-11-21 18:41:01 EST
I have tried your method to see if the KRB5_KTNAME appears in the slapd 
processes environment and it appears there (/proc/slapd-procId/environ so you 
are correct that it is in the slapd process space but I am not certain why 
slapd still does not find the proper keytab nor run properly.

Anyway, I have provided two files: (1) slapd.conf and (2) slapd.access
Comment 5 Christian Iseli 2007-01-19 19:33:16 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 6 Jan Safranek 2007-05-24 09:07:34 EDT
I'm sorry nobody helped you with the bug. FC4 is not supported anymore, please
try FC-6 or F7 when it gets out and reopen the bug if the problem still persists.

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