[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Problems with ldapwhoami -> slapd -> segmentation fault
Hi all,
I don’t really know whether the question actually belongs here (*it* seems
to be indicating a problem in the Cyrus SASL arena), but then again, the
problem only shows with slapd (2.2.15 and cvs HEAD).
Following is the situation:
I set up db4 from source+patches, OpenSSL 0.9.7d, MIT krb5 on top, then I
compiled Cyrus SASL, and took 3 weeks to figure out what the hell was wrong
with the saslauthd (it would always say NO, until I figured, I have the
wrong service/FQDN pair in the keytab). So that worked, and I happily
progressed on to OpenLDAP.
I compiled 2.2.15 using
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host jupiter.junior.net:
#
# ./configure --prefix=/opt/openldap-2.2.15 --with-cyrus-sasl
--with-tls=openssl --enable-bdb --with-kerberos --enable-crypt
--enable-spasswd --enable-kpasswd
and the HEAD I compiled using
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host jupiter.junior.homenet:
#
# ./configure --prefix=/opt/openldap-devel --with-cyrus-sasl
--with-tls=openssl --enable-bdb --enable-crypt --enable-lastmod
--with-kerberos=/opt/krb5 --enable-spasswd
All compiled fine, all tests were ran successfully, so I installed a small
database using ldapadd, and started slapd: [root@jupiter slapd]$ ./slapd –h
“ldap://ldap.junior.homenet ldaps://ldap.junior.homenet” –u ldap –g ldap –d
65535
Then on a different terminal, I tested
[leeuwg@jupiter tools]$ ./ldapsearch -H ldap://ldap.junior.homenet -b "" -s
base -x -LLL -ZZ OpenLDAProotDSE
[answers snipped]
[leeuwg@jupiter tools]$ ./ldapsearch -H ldap://ldap.junior.homenet -b "" -s
base -x -LLL -ZZ supportedSASLMechanisms
[answers snipped]
[leeuwg@jupiter tools]$ ./ldapsearch -H ldaps://ldap.junior.homenet -b "" -s
base -x -LLL supportedSASLMechanisms
[answers snipped]
[leeuwg@jupiter tools]$ ./ldapsearch -H ldaps://ldap.junior.homenet -b "" -s
base -I -LLL supportedSASLMechanisms
[answers snipped]
So I was happy that it all seemed to work so far ;) (This is actually the
first time I try to base OpenLDAP on SASL->KRB5, I’ve got OpenLDAP 2.early
running as a passwd authentication place for Samba3.0.3 acting as PDC...
Which runs just fine, but I want true single sign on throughout the whole
heterogenous network (1 WXP, 1W2k, 1 linux-desk, 1 linux-server ;))
Anyways, I created a test user (leeuwg-t), added the principal
(leeuwg-t@JUNIOR.HOMENET) to kadmin.local (addprinc), and did following:
[leeuwg@jupiter tools]$ kinit leeuwg-t
Password for leeuwg-t@JUNIOR.HOMENET: <= test1pwD
[leeuwg@jupiter tools]$ echo $?
0
[leeuwg@jupiter tools]$ klist
Ticket cache: FILE:/tmp/krb5cc_1003
Default principal: leeuwg-t@JUNIOR.HOMENET
Valid starting Expires Service principal
08/25/04 07:33:03 08/25/04 19:33:03 krbtgt/JUNIOR.HOMENET@JUNIOR.HOMENET
renew until 08/26/04 07:33:03
Kerberos 4 ticket cache: /tmp/tkt1003
klist: You have no tickets cached
[leeuwg@jupiter tools]$ ./ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) [leeuwg@jupiter
tools]$
On the terminal running root, I can see all sorts of text flying by, but the
slapd stops with:
<==slap_sasl2dn: Converted SASL name to cn=guus leeuw
(test),ou=people,dc=junior,dc=homenet
getdn: dn:id converted to cn=guus leeuw
(test),ou=people,dc=junior,dc=homenet
slap_sasl_getdn done
SASL Canonicalize 2 [conn=0]: slapAuthcDN="cn=guus leeuw
(test),ou=people,dc=junior,dc=homenet"
/etc/sasldb2
Segmentation fault
[root@jupiter slapd]#
So now the big thing is:
How come? ;)
Obviously I did not yet set userPassword to be
{SASL}leeuwg-t@JUNIOR.HOMENET, but then again, the slapd sasl.c specifically
says, it does not care, since it is binding to SASL anyways, so that’s not
the point...
What strikes me as weird, is that slapd refers to /etc/sasldb2, although
saslauthd is never contacted… Is OpenLDAP implementing an own SASL server
(hence the calls to sasl_server_new(...)? OK, might be... Then the answer I
probably need goes along the lines: What about saslauthd.conf and what do I
stick in there to point to krb5?
I tried to hack away in the code adding Debug(...) statements in sasl.c to
figure out what was wrong, but the only thing I can see is that
session_callbacks is being SLAP_CALLOCed for 5 entries (SASL_VERSION_MAJOR
>= 2) and only 3 entries are actually filled in. The last one says
session_callbacks[cb].id = SASL_CB_LIST_END, which seems to indicate that
this is the end of the callback list ;) Why allocating 5 entries and only
using 4? And the segfault seems to point at a spot where slapd actually
calls address 0x00 or somewhere close ;)
If you have questions, or need more information, please ask, and I’ll
happily provide ;) ( I do have the -d 65535 outputs, ldif, slapd.conf etc
files, in case somebody wants to see them...)
Hope someone might be able to help...
Regards,
Guus
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004