Re: LDAP authentication with PAM
>>>>> "Wichert" == Wichert Akkerman <wichert@cistron.nl> writes:
Wichert> That's essential, but you also have to tell slapd which
Wichert> keys to use, and unfortunately that is not extremely well
Wichert> documented. There is some documentation on the
Wichert> faq-o-matic on www.openldap.org tot tells you which
Wichert> commands to put in slapd.conf, but it does not explain
Wichert> how to generate the keys.
Wichert> However since I ran into that same problem a while ago I
Wichert> wrote a little script that creates a dummy certification
Wichert> authority and a service key signed by that dummy CA that
Wichert> you can use here. The script (makekeys) is
Wichert> attached. Please note you need to have the openssl
Wichert> package installed for this.
I am pretty sure I have got all the keys stuff worked out, in fact
all of the debug messages from the server (-d 3) look fine to me:
[...]
ldap_pvt_gethostbyname_a: host=dewey, r=0
connection_get(9): got connid=0
connection_read(9): checking for input on id=0
TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write server done A
TLS trace: SSL_accept:SSLv3 flush data
TLS trace: SSL_accept:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
connection_get(9): got connid=0
connection_read(9): checking for input on id=0
TLS trace: SSL_accept:SSLv3 read client key exchange A
TLS trace: SSL_accept:SSLv3 read finished A
TLS trace: SSL_accept:SSLv3 write change cipher spec A
TLS trace: SSL_accept:SSLv3 write finished A
TLS trace: SSL_accept:SSLv3 flush data
[...]
(hmmm... not sure about that error in SSLv3 read client certificate.
I thought that went away. My mistake. Do I need to generate a client
certificate? If so, how do I use it?).
However, at this point the client crashes with a segmentation fault.
I have compiled a debugging version of openldap, and got a back trace:
(gdb) bt
#0 0x40020fb8 in ldap_int_sasl_external (ld=0x8050a48,
authid=0x806e9d0 "/C=AU/ST=Victoria/L=Melbourne/O=Snoopy's Organization/CN=dewey.chocbit.org.au/Email=bam@snoopy.apana.org.au", ssf=168) at cyrus.c:664
#1 0x40035455 in ldap_pvt_tls_start (ld=0x8050a48, sb=0x8050d60, ctx_arg=0x0)
at tls.c:894
#2 0x4001be03 in ldap_int_open_connection (ld=0x8050a48, conn=0x80511d8,
srv=0x8050b08, async=0) at open.c:332
#3 0x4002b267 in ldap_new_connection (ld=0x8050a48, srvlist=0x8050b08,
use_ldsb=1, connect=1, bind=0x0) at request.c:259
#4 0x4001b8f9 in ldap_open_defconn (ld=0x8050a48) at open.c:29
#5 0x4002af19 in ldap_send_initial_request (ld=0x8050a48, msgtype=96,
dn=0x40038cfe "", ber=0x8050d80) at request.c:91
#6 0x40024c3a in ldap_sasl_bind (ld=0x8050a48, dn=0x40038cfe "",
mechanism=0x0, cred=0xbfffd7b4, sctrls=0x0, cctrls=0x0, msgidp=0xbfffd778)
at sasl.c:146
#7 0x40024cd8 in ldap_sasl_bind_s (ld=0x8050a48, dn=0x0, mechanism=0x0,
cred=0xbfffd7b4, sctrls=0x0, cctrls=0x0, servercredp=0x0) at sasl.c:180
#8 0x4002536f in ldap_simple_bind_s (ld=0x8050a48, dn=0x0, passwd=0x0)
at sbind.c:110
#9 0x4001b8c7 in ldap_bind_s (ld=0x8050a48, dn=0x0, passwd=0x0,
authmethod=128) at bind.c:112
#10 0x804a7e8 in main (argc=0, argv=0xbffff8e4) at ldapsearch.c:781
all of this seems to indicate that my keys are OK, especially the
parameters in stack frame #0.
Breakpoint 1, ldap_pvt_tls_start (ld=0x8050a48, sb=0x8050d60, ctx_arg=0x0)
at tls.c:870
870 ldap_pvt_tls_init();
(gdb) n
875 if ( ldap_pvt_tls_connect( ld, sb, ctx_arg ) < 0 ) {
(gdb) n
890 ssl = (void *) ldap_pvt_tls_sb_handle( sb );
(gdb) n
891 ssf = ldap_pvt_tls_get_strength( ssl );
(gdb) n
892 authid = ldap_pvt_tls_get_peer( ssl );
(gdb) n
894 (void) ldap_int_sasl_external( ld, authid, ssf );
(gdb) print ld
$2 = (LDAP *) 0x8050a48
(gdb) s
ldap_int_sasl_external (ld=0x8050a48,
authid=0x806e9d0 "/C=AU/ST=Victoria/L=Melbourne/O=Snoopy's Organization/CN=dewey.chocbit.org.au/Email=bam@snoopy.apana.org.au", ssf=168) at cyrus.c:664
664 sasl_conn_t *ctx = ld->ld_defconn->lconn_sasl_ctx;
(gdb) print ld
$3 = (LDAP *) 0x8050a48
(gdb) print ld->ld_defconn
$4 = (LDAPConn *) 0x0
I think this has to be significant, but don't know what it means.
Running it again but stepping into ldap_pvt_tls_connect (as this is
what seems to generate *ld):
Breakpoint 1, ldap_pvt_tls_start (ld=0x8050a48, sb=0x8050d60, ctx_arg=0x0)
at tls.c:870
870 ldap_pvt_tls_init();
(gdb) n
875 if ( ldap_pvt_tls_connect( ld, sb, ctx_arg ) < 0 ) {
(gdb) s
ldap_pvt_tls_connect (ld=0x8050a48, sb=0x8050d60, ctx_arg=0x0) at tls.c:561
561 if ( HAS_TLS( sb ) ) {
(gdb) n
564 ssl = alloc_handle( ctx_arg );
(gdb) n
565 if ( ssl == NULL )
(gdb) n
568 ber_sockbuf_add_io( sb, &ber_sockbuf_io_debug,
(gdb) n
571 ber_sockbuf_add_io( sb, &ldap_pvt_sockbuf_io_tls,
(gdb) n
573 }
(gdb) n
575 err = SSL_connect( ssl );
(gdb) s
580 if ( err <= 0 ) {
(gdb) n
596 return 0;
(gdb) print err
$6 = 1
Now I am stuck. It seems that SSL_connect is returning an error, that
goes unchecked by openldap causing the segfault.
--
Brian May <bam@debian.org>
Reply to: