Re: SASL/GSSAPI

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I agree that the stack backtrace looks quite odd.

Have you gotten the Cyrus sample client/server working?

Kurt

At 01:35 PM 2002-10-18, Allan E Johannesen wrote:
>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(B\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(B\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.