SASL/GSSAPI

[Allan E Johannesen <aej@WPI.EDU>]

I have a bug I can't seem to decode.  slapd dies when accessed via GSSAPI on
one Linux (Red Hat 7.3 2.4.18-5smp) box, but works on another box.  I'm trying
to run ldap 2.1.7.

The failing system has both host/ and ldap/ keys in the keytab, and the ldap
client (ldapsearch) system gets as far as having the ldap/ key cached on it.

However it fails:

ldapsearch -Y GSSAPI -h utility5.wpi.edu '(uid=aej)'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server

The core looks like this;

(gdb) where
#0  0x08220d0b in ?? ()
#1  0x400166eb in _sasldb_getdata (utils=0x8214260, context=0x82135c8, auth_identity=0x8220ae8 "aej",
    realm=0x8220ad8 "WPI.EDU", propName=0x8147ca6 "authzDN", out=0x408b87c4 "", max_out=8192, out_len=0x408b87b8)
    at db_berkeley.c:169
#2  0x4001508a in sasldb_auxprop_lookup (glob_context=0x0, sparams=0x820fd08, flags=0, user=0x8213fd9 "aej@WPI.EDU",
    ulen=11) at sasldb.c:113
#3  0x400d9032 in _sasl_auxprop_lookup (sparams=0x820fd08, flags=0, user=0x8213fd9 "aej@WPI.EDU", ulen=11)
    at auxprop.c:835
#4  0x400d94d1 in _sasl_canon_user (conn=0x82135c8, user=0x8213fd9 "aej@WPI.EDU", ulen=0, flags=3, oparams=0x8213e28)
    at canonusr.c:190
#5  0x4025372e in gssapi_server_mech_step (conn_context=0x820ed20, params=0x820fd08,
    clientin=0x821253e "`?\006\t*\206H\206%/1€Œiso8859-15,Aw\022\001\002\002\002\001\004", clientinlen=65, serverout=0x408ba99c,
    serveroutlen=0x408ba9a0, oparams=0x8213e28) at gssapi.c:980
#6  0x400e2169 in sasl_server_step (conn=0x82135c8,
    clientin=0x821253e "`?\006\t*\206H\206%/1€Œiso8859-15,Aw\022\001\002\002\002\001\004", clientinlen=65, serverout=0x408ba99c,
    serveroutlen=0x408ba9a0) at server.c:1264
#7  0x080800be in slap_sasl_bind (conn=0x40472d28, op=0x821d3a8, dn=0x408baa20, ndn=0x408baa28, cred=0x408baa3c,
    edn=0x408baa10, ssfp=0x408baa18) at sasl.c:1503
#8  0x08066504 in do_bind (conn=0x40472d28, op=0x821d3a8) at bind.c:291
#9  0x08051e4d in connection_operation (ctx=0x8214ac0, arg_v=0x821d430) at connection.c:945
#10 0x0809c911 in ldap_int_thread_pool_wrapper (xpool=0x81789d8) at tpool.c:431
#11 0x40172fef in pthread_start_thread () from /lib/i686/libpthread.so.0

I don't know why it would be looking in db_berkeley.  There was no /etc/sasldb
nor /etc/sasldb2 installed on either this or the working system.  I put "aej"
into saslpasswd and saslpasswd2, and it still dumps.  I don't want there to
have to be a sasldb, but I was curious if there would be a difference.

The end of the debug on the slapd server looks like this:

bdb_group: rc=1
<= check a_dn_pat: users
<= acl_mask: [2] applying read(=rscx) (stop)
<= acl_mask: [2] mask: read(=rscx)
=> access_allowed: search access granted by read(=rscx)
<= test_filter 6
====> bdb_cache_return_entry_r( 1331 ): created (0)
<==slap_sasl2dn: Converted SASL name to wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=people,dc=wpi,dc=edu
getdn: dn:id converted to wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=people,dc=wpi,dc=edu
SASL Canonicalize [conn=0]: authcDN="wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=people,dc=wpi,dc=edu"
Segmentation fault

Can anyone point me in the direction of a clue?

Thanks.