my first experiment with ldap back end

Fri Jun 2 21:10:16 EDT 2006

Okay, I've spent more time than I should've needed to staring at
certificate and ldap setup docs and getting distracted with other
issues, but now I've got an LDAP server running and I tried creating a
realm.

I'm using this dbmodules section for my O-P.MIT.EDU realm:

	ldap = {
		db_library = kldap
		ldap_ssl_port = 636
		ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
		ldap_servers = opteron-prime.mit.edu
		ldap_kdc_dn = "cn=admin,dc=mit,dc=edu"
		ldap_kadmind_dn = "cn=admin,dc=mit,dc=edu"
		ldap_service_password_file = /home/raeburn/k5/ldap/linux/Install/etc/ldap-pw
	}

And ran kdb5_ldap_util, on an x86_64 Debian GNU/Linux 3.1 system:

$ env KRB5_CONFIG=`pwd`/Install/etc/krb5.conf ./Install/sbin/kdb5_ldap_util -D cn=admin,dc=mit,dc=edu create 
Password for "cn=admin,dc=mit,dc=edu": 
Default enctype not specified: "des3-cbc-sha1" will be added as the default enctype and to the list of supported enctypes.
Default salttype not specified: "normal" will be added as the default salttype and to the list of supported salttypes.
Initializing database for realm 'O-P.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 
(null): Principal add failed: Invalid syntax while adding entries to database
create: Database store error while adding entries to the database

First problem: Syntax where?  What entry?  Okay, yeah, the error
messages from the krb5 code are pretty poor, but that's no reason to
continue the, um, tradition.

Second problem: "(null)"?  I probably missed a program-name variable
someplace when tweaking the error-message handling.

At this point it stopped; after 10 seconds or so I interrupt it (I'm
running it under gdb), and it seems to be stalled in the LDAP code
(problem #3):

#0  0x0000002a966764df in mallopt () from /lib/libc.so.6
#1  0x0000002a96675d80 in mallopt () from /lib/libc.so.6
#2  0x0000002a96674ff7 in malloc () from /lib/libc.so.6
#3  0x0000002a96cef5de in _gnutls_send_int () from /usr/lib/libgnutls.so.11
#4  0x0000002a96d08647 in gnutls_alert_send () from /usr/lib/libgnutls.so.11
#5  0x0000002a96cef2a0 in gnutls_bye () from /usr/lib/libgnutls.so.11
#6  0x0000002a96869949 in gnutls_SSL_shutdown () from /usr/lib/libldap_r.so.2
#7  0x0000002a9686733a in ldap_pvt_tls_init_def_ctx ()
   from /usr/lib/libldap_r.so.2
#8  0x0000002a96982874 in ber_int_sb_close () from /usr/lib/liblber.so.2
#9  0x0000002a96982114 in ber_sockbuf_free () from /usr/lib/liblber.so.2
#10 0x0000002a96853f18 in ldap_ld_free () from /usr/lib/libldap_r.so.2
#11 0x0000002a96853d99 in ldap_unbind_ext () from /usr/lib/libldap_r.so.2
#12 0x0000002a9685404d in ldap_unbind_s () from /usr/lib/libldap_r.so.2
#13 0x0000002a95becb1f in krb5_ldap_free_server_params (ldap_context=0x50eb60)
    at ../../../../../krb5/src/plugins/kdb/ldap/libkdb_ldap/ldap_misc.c:319
#14 0x0000002a95be4f48 in krb5_ldap_close (context=0x550ef0)
    at ../../../../../krb5/src/plugins/kdb/ldap/libkdb_ldap/kdb_ldap_conn.c:349
#15 0x0000000000403138 in main (argc=0, argv=0x7fbffffbe8)
    at ../../../../../krb5/src/plugins/kdb/ldap/ldap_util/kdb5_ldap_util.c:636

Okay, ignoring that for now, I tried tweaking the config file I had,
and tried removing the quotes from around the DN strings.  I didn't
really expect that to change anything, but making the DN string
syntaxes used consistent seemed like a simple thing to start with.
But on my next attempt to create the database, I got:

create: Already exists while creating realm 'O-P.MIT.EDU'

(and the same hang).  So, I tried "destroy" instead of "create":

Deleting KDC database of 'O-P.MIT.EDU', are you sure?
(type 'yes' to confirm)? yes
OK, deleting database of 'O-P.MIT.EDU'...
destroy: No such object deleting database of 'O-P.MIT.EDU'

(and again a hang).  So, I quite trivially got myself into a state
where I can't create the database because something's there, and I
can't delete it because not enough's there.  (Problem 4.)  So, what's
there?

$ ldapsearch -Z -x -W -D cn=admin,dc=mit,dc=edu -b 'dc=mit,dc=edu' '(objectclass=*)' 
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=mit,dc=edu> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# mit.edu
dn: dc=mit,dc=edu
objectClass: top
objectClass: dcObject
objectClass: organization
o: mit.edu
dc: mit

# admin, mit.edu
dn: cn=admin,dc=mit,dc=edu
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fWtzbXpITTZEUldwOGc=

# krbcontainer, mit.edu
dn: cn=krbcontainer,dc=mit,dc=edu
objectClass: krbContainer
objectClass: top
cn: krbcontainer

# O-P.MIT.EDU, krbcontainer, mit.edu
dn: cn=O-P.MIT.EDU,cn=krbcontainer,dc=mit,dc=edu
cn: O-P.MIT.EDU
objectClass: top
objectClass: krbRealmContainer
objectClass: krbPolicyAux
krbDefaultEncType: 16
krbDefaultSaltType: 0
krbSupportedSaltTypes: 0
krbSupportedSaltTypes: 1
krbSupportedSaltTypes: 2
krbSupportedSaltTypes: 3
krbSupportedSaltTypes: 4
krbSupportedEncTypes: 1
krbSupportedEncTypes: 2
krbSupportedEncTypes: 3
krbSupportedEncTypes: 16
krbSupportedEncTypes: 17
krbSupportedEncTypes: 18
krbSupportedEncTypes: 23

# search result
search: 3
result: 0 Success

# numResponses: 5
# numEntries: 4
$

(The supplied LDAP programs like ldapsearch and ldapadd don't hang.)

In the debugging spew from the slapd process, I see this zipped by.
(Actually, this was from my testing *last* night with slightly
different sources, but having the same problem.)

conn=66 op=4 SRCH base="" scope=2 deref=0 filter="(krbPrincipalName=*@O-P.MIT.EDU)"
conn=66 op=4 SRCH attr=krbprincipalname
send_ldap_result: conn=66 op=4 p=3
send_ldap_result: err=10 matched="" text=""
send_ldap_response: msgid=5 tag=101 err=32
ber_flush: 14 bytes to sd 16
  0000:  30 0c 02 01 05 65 07 0a  01 20 04 00 04 00         0....e... ....    
tls_write: want=90, written=90
  0000:  17 [...]
ldap_write: want=14, written=14
  0000:  30 0c 02 01 05 65 07 0a  01 20 04 00 04 00         0....e... ....    
conn=66 op=4 SEARCH RESULT tag=101 err=32 nentries=0 text=

So, possibly the problem was that it was expecting at least one
principal to exist in the realm, as would normally be the case for a
successfully created realm, though if realm and principal creation are
separate operations and the network isn't reliable....

Okay, now I've patched up the ldap data with ldapdelete, and find that
changing the quoting made no difference.

But, if I try x86 (ia32) binaries on the same system (still running
the x86_64 slapd), it doesn't fail in the same way.  It asks for the
master key, displays "Kerberos container is missing. Creating now..."
because I'd been a little too aggressive with ldapdelete, and then
hangs.  (I've tried running it under valgrind, it didn't report any
memory corruption, but it does seem to think that open() is being
called with a null pointer somewhere, and when I interrupt the
processes, it claims that no malloc storage is in use at that point,
which makes me skeptical.)

At this point it's created krbcontainer, O-P.MIT.EDU, and principals
K/M, krbtgt, kadmin/admin, kadmin/changepw, kadmin/history, and
kadmin/opteron-prime.mit.edu (that being the machine I'm using).  So
it's done better than the x86_64 version.  Is it done?

I then try to destroy the database (ia32 binaries again), and again I
get the "no such object deleting database" error, and a hang.

So, going back to the info from the slapd debug output, I notice the
search base is empty, not under dc=mit,dc=edu.  And, indeed, I find
that if I do an ldapsearch with -b dc=mit,dc=edu, I can see all the
principals, but if I use -b "" or supply no base, it finds nothing.
I'm still an LDAP newbie, perhaps I've got something wrong in my
slapd.conf file.  But shouldn't we be searching under the container
specified in the Kerberos config file?

Ken