You are not logged in.

#1 2008-05-18 22:13:36

arew264
Member
From: Friendswood, Texas, US
Registered: 2006-07-01
Posts: 394
Website

LDAP + Kerberos = Crash?

I'm trying to get a setup of Kerberos and LDAP working. LDAP works fine with plain authentication and everything seems to be set up correctly, but when I try to use GSSAPI authentication, slapd crashes.
Application Versions:
openldap 2.3.40
heimdal 1.0.1

Server log from startup to crash:

May 17 21:50:07 Lagbox slapd[11161]: @(#) $OpenLDAP: slapd 2.3.40 (Jan 15 2008 23:41:27) $      nobody@tk-gwa:/build/src/openldap-2.3.40/servers/slapd
May 17 21:50:07 Lagbox slapd[11161]: /etc/openldap/slapd.conf: line 139: "attr" is deprecated (and undocumented); use "attrs" instead.
May 17 21:50:07 Lagbox slapd[11161]: /etc/openldap/slapd.conf: line 144: "attr" is deprecated (and undocumented); use "attrs" instead.
May 17 21:50:07 Lagbox slapd[11162]: bdb_db_open: unclean shutdown detected; attempting recovery.
May 17 21:50:07 Lagbox slapd[11162]: bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/openldap/openldap-data: (2) Expect poor performance for suffix dc=wileynetworks,dc=org.
May 17 21:50:07 Lagbox slapd[11162]: slapd starting
May 17 21:51:04 Lagbox slapd[11162]: conn=0 fd=14 ACCEPT from IP=127.0.0.1:54066 (IP=0.0.0.0:389)
May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SRCH attr=supportedSASLMechanisms
May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 17 21:51:04 Lagbox slapd[11162]: conn=0 op=1 BIND dn="" method=163
May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=1 RESULT tag=97 err=14 text=
May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=2 BIND dn="" method=163
May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=2 RESULT tag=97 err=14 text=
May 17 21:51:05 Lagbox slapd[11162]: conn=0 op=3 BIND dn="" method=163
May 17 21:51:05 Lagbox slapd[11165] general protection eip:b7abeb05 esp:b6c80df0 error:0

Search command that causes crash:

[arew264@Lagbox ~]$ ldapsearch -H ldap://localhost/ -b dc=wileynetworks,dc=org
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
[arew264@Lagbox ~]$

Note: I am leaving all names intact here because this is a test setup and not any sort of production server.

The user that ran the search command is in kerberos and had run kinit and gotten a ticket before running the search. With just a crash and no error messages, I don't know where to start in tracking this down.

slapd.conf:

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.

include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral    ldap://root.openldap.org

#pidfile    /var/run/slapd.pid
#argsfile    /var/run/slapd.args

# Create a replication log in /var/lib/ldap for use by slurpd.
#   REPLICA: Comment this out on the replicas
replogfile    /var/lib/ldap/master-slapd.replog

# SSL certificate and key with the official (as reported by a reverse
# DNS lookup) hostname in the CN field.
# Make sure the key file is not world-readable.  Best also if the
# ldap user can't write to it.  Something like the following should do:
# chown root; chgrp ldap; chmod 640
#   REPLICA:  Each replica should have it's own SSL cert/key
TLSCertificateFile /etc/openldap/newcert.pem
TLSCertificateKeyFile /etc/openldap/newreq.pem
#TLSCertificateKeyFile /etc/openldap/cakey.pem
#TLSCertificateFile /etc/openldap/cacert.pem

#
# Access Control
#

# This is a bit of a hack to restrict the SASL mechanisms that the
# server advertises to just GSSAPI.  Otherwise it also advertises
# DIGEST-MD5, which the clients prefer.  Then you have to add "-Y
# GSSAPI" to all of your ldapsearch/ldapmodify/etc. command lines, which
# is annoying.  The default for this is noanonymous,noplain so the
# addition of noactive is what makes DIGEST-MD5 and the others go away.
sasl-secprops noanonymous,noplain,noactive

# Map SASL authentication DNs to LDAP DNs
#   This leaves "username/admin" principals untouched
saslRegexp uid=([^/]*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=wileynetworks,dc=org
# This should be a  ^  plus, not a star, but slapd won't accept it

# REPLICA:
#   On replica servers replace the first line of each section below (the
#   line that allows /admin principals to write to things) with the
#   following line (allowing the primary server to write instead).  Thus
#   admins can make changes on the primary server, and the primary
#   server can push changes to the replicas.
#by dn.exact="uid=host/foo.example.com,cn=GSSAPI,cn=auth" write

# Users with /admin principals can change anything

# Users can change their shell, anyone else can see it
access to attr=loginShell
    by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write
    by self write
    by * read
# Only the user can see their employeeNumber
access to attr=employeeNumber
    by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write
    by self read
    by * none
# Default read access for everything else
access to *
    by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write
    by * read

# Limit number of search results to prevent trolling of directory
# by spammers, etc.
#sizelimit 10
# Alternatively, specify a large enough size limit to ensure we can dump
# the entire directory
sizelimit 5000

# Limit the number of threads
# The default is 16 and that has been reported on the openldap mailing
# list to be too many for a machine with < 1 GB of RAM
threads 8
                                                                                
# Disconnect idle connections after 4 hours.  Otherwise connections
# from nss_ldap keep piling up and we eventually exceed our open file
# handle limit.  Increasing that limit above 1024 is difficult on Linux
# because slapd uses select(2) and the FD_SETSIZE is hard-coded at 1024.
# Presumably slapd will eventually be converted to use poll(2) instead
# of select, which doesn't have that limit.  But until then this is our
# workaround.
idletimeout 14400
                                                                                
# Turn off logging.  We can always turn it back on when we need to see
# what's going on.
# 256 is the default.  256 logs connections, operations and results,
# it would be nice to log only operations but there isn't a level just
# for operations.
loglevel 256
                                                                                
# Allow LDAPv2 for Mozilla's address book
allow bind_v2

#######################################################################
# ldbm database definitions
#######################################################################

database    bdb
suffix        "dc=wileynetworks,dc=org"

# Increase the size of slapd's entry cache.  Note that this is a
# seperate cache from BDB's cache, who's size is configured in DB_CONFIG
cachesize 10000

# BDB tuning
# It would be preferable to do all BDB tuning in BDB's configuration
# file, but there are some settings that aren't supported there.
# BDB's config file is var/openldap-data/DB_CONFIG
# Docs:  http://www.openldap.org/faq/data/cache/893.html
#
# Turn on checkpointing, which is off by default.  This reduces the
# amount of time it takes db_recover to run on a restart.
checkpoint 256 15

# Uncomment these only for the initial load, then comment them back
# out and restart slapd.
rootdn        "cn=Manager,dc=wileynetworks,dc=org"
rootpw        poop

# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory    /var/lib/openldap/openldap-data
# Indices to maintain
index    objectClass,uid,uidNumber,gidNumber,memberUid    eq
index    cn,mail,surname,givenname            eq,subinitial

# Replicas to which we should propagate changes
# Make sure you have a cronjob set up to keep a ticket for this principal
# up to date and that slurpd is started with a KRB5CCNAME environment
# variable pointing to the cache file containing that ticket.
#   REPLICA:  Comment this out on replicas
#replica host=ldap2.example.com:389 tls=critical
#    bindmethod=sasl saslmech=GSSAPI
#    authcId=host/foo.example.com@EXAMPLE.COM

# The purpose of the updatedn is to tell slapd not to send the updateref
# if that DN tries to make changes.  Any other user which attempts to
# submit a change will be refered to the master LDAP server found in
# updateref.
#   REPLICA:  Uncomment these on replicas
#updatedn "uid=host/foo.example.com"
#updateref ldaps://ldap1.example.com/

Offline

#2 2008-05-19 22:52:34

cipparello
Member
From: Verona, Italy
Registered: 2008-05-19
Posts: 16

Re: LDAP + Kerberos = Crash?

Hello,
   the problem lies on the fact that in Arch the package openldap has dependence on BDB 4.5 (correctly in fact only the branch 2.4.x of openldap is compatible with BDB 4.6) but the packages libsasl and cyrus-sasl have dependence on BDB 4.6.

For this reason when you use LDAP + Kerberos you get the error 'ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)' because you have
a version mismatch, regarding the BDB, between SASL and OpenLDAP.

You can find evidence of that at the openldap FAQ list: http://www.openldap.org/faq/data/cache/1432.html

I think that you have two solutions for your problem:

- create your openldap 2.4.x package with dependence on BDB 4.6
- create your libsasl and cyrus-sasl packages with explicit dependence on BDB 4.5

A few months ago I've followed the second choice for the same problem and for this reason I've built the
packages libsasl and cyrus-sasl with dependence on BDB 4.5.

Hope that it will be useful for your problem.

Offline

#3 2008-05-20 00:17:48

arew264
Member
From: Friendswood, Texas, US
Registered: 2006-07-01
Posts: 394
Website

Re: LDAP + Kerberos = Crash?

Thank you!
I probably never would have found that on my own.
I'll try openldap 2.4, if I have no problems there, I'll just stick with it when I set up the production installation I may be running.

Offline

#4 2008-05-20 02:20:58

arew264
Member
From: Friendswood, Texas, US
Registered: 2006-07-01
Posts: 394
Website

Re: LDAP + Kerberos = Crash?

w00t, OpenLDAP 2.4.9 and I'm up and running.
Thanks again!

Offline

Board footer

Powered by FluxBB