Date: Thu, 15 Jul 2010 08:14:33 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Henrik /KaarPoSoft <henrik@kaarposoft.dk> Cc: mamalos@eng.auth.gr, freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 Message-ID: <20100715151433.GA71946@icarus.home.lan> In-Reply-To: <4C3E0D7D.5020305@kaarposoft.dk> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <4C3E0D7D.5020305@kaarposoft.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 14, 2010 at 09:18:21PM +0200, Henrik /KaarPoSoft wrote: > On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: > >>I have a problem: ldapsearch results in "Segmentation fault" under > >>openldap-2.4.23 with cyrus-sasl-2.1.23. > >>[...] > > Jeremy Chadwick wrote: > >If I was to build a test box from scratch, can you tell me how to set up > >all the necessary software/etc. to mimic your environment so that I > >could try to reproduce this? Reviewing the source isn't enough, I'd > >have to actually build a debug version of libgssapi to track it down. > Jeremy, I would really appreciate your going through this! > Thank you very much in advance. > > Here is what I did: > > [...] Before I get started, I should note that the system I'm testing on was built with the following two features in src.conf and make.conf; the lesser is for world, the lesser for world, respectively. /etc/src.conf: DEBUG_FLAGS=-g3 -ggdb /etc/make.conf: CFLAGS+=-g3 -ggdb > [...] I did not create a CA + self-signed SSL cert at this point, I save that for later (see bottom), where I've also run into a complexity. > cat > /etc/krb5.conf > [libdefaults] > default_realm = EXAMPLE.LAN > > kstash At this point kstash asked for a "Master Key" and for me to validate it. I just hit enter at both prompts. I don't know if that's correct (I'm not familiar with Kerberos administration). > kadmin -l > kadmin> init EXAMPLE.LAN At this point I was prompted for "Realm max ticket life" and "Realm max renewable ticket life". I chose the defaults of unlimited. > kadmin> add TestOne At this point I was prompted for numerous parameters (max ticket life, max renewable life, principle expiration time, password expiration time, attributes, and a password + verification). I hit enter at all the prompts. > kadmin> list "*" For me, this returned: TestOne default kadmin/admin kadmin/hprop hadmin/changepw changepw/kerberos krbtgt/EXAMPLE.LAN > cd /usr/ports/security/cyrus-sasl2 > make config > [X] Berkeley DB > [X] /dev/urandom > make > make install During the configure stage a warning caught my eye: checking for crypt in -lcrypt... yes configure: WARNING: The system type is not recognized. If you believe that CyberSafe GSSAPI works on this platform, please update the configure script checking gssapi.h usability... yes checking gssapi.h presence... yes checking for gssapi.h... yes checking for res_search in -lresolv... no checking for gss_unwrap in -lgssapi... yes checking GSSAPI... with implementation heimdal checking for res_search in -lresolv... (cached) no checking for gsskrb5_register_acceptor_identity... no checking to use mutexes aroung GSS calls... no Just noting that here for posterity. It may be safe. I simply don't know. > cd /usr/ports/net/openldap24-sasl-client > make > make install At this point I was prompted for OPTIONS, and SASL (for "Cyrus SASL 2 Support") was not checked, so I checked it. This seems strange; a port called "sasl-client" asking me if I want SASL support? Seems like that should be implied given the port name -- could be a stub port issue. I just hope I chose the right option. > cd /usr/ports/net/openldap24-server > make config > [x] SASL > make At this point OPTIONS already had SASL checked, so I went with that. I also kept the default options, which were all unchecked except the following: FETCH, TCP_WRAPPERS, SEQMOD, SYNCPROV, and DYNAMIC_BACKENDS. I should point out that this port pulled in db46-4.6.21.4, while the security/cyrus-sasl2 port pulled in db41-4.1.25_4. I don't think this will be a problem since I don't see any SleepyCat/Oracle DB calls in the stack trace. Just noting it here for posterity. Next, during the configure phase (since we're discussing cyrus-sasl2), I saw this: checking sasl/sasl.h usability... yes checking sasl/sasl.h presence... yes checking for sasl/sasl.h... yes checking sasl.h usability... no checking sasl.h presence... no checking for sasl.h... no checking for sasl_client_init in -lsasl2... yes checking Cyrus SASL library version... yes checking for sasl_version... yes checking fetch(3) library... yes checking for crypt... no checking for crypt in -lcrypt... yes I also did "make install" after "make". > cat >> /etc/rc.conf > slapd_enable="YES" > slapd_flags="-h ldaps:///" > > touch /var/db/openldap-data/DB_CONFIG > > srv02# diff /usr/local/etc/openldap/slapd.conf.ORIG /usr/local/etc/openldap/slapd.conf This is where things got a little wild (I hate contextual diffs). I added the following lines to slapd.conf before the "BDB database definitions" section: ####################################################################### # EXAMPLE ####################################################################### #=# Shemas we need include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #=# Logging loglevel stats stats2 shell parse ACL config filter BER conns #=# GSSAPI mapping #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI #=# http://www.openldap.org/doc/admin24/sasl.html#Mapping Authentication Identities authz-regexp uid=([^,]*),cn=example.lan,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=lan #=# LDAP over TSL (SSL) #=# http://www.openldap.org/doc/admin24/tls.html security ssf=128 TLSCertificateFile /etc/certs/new.crt TLSCertificateKeyFile /etc/certs/myca.key TLSCACertificateFile /etc/certs/new.crt Note that my TLS* lines are changed. See bottom of the mail. Then I modified the following already-existing lines to contain the following (which should match your diff): suffix "dc=example,dc=lan" rootdn "uid=LDAProot,cn=example.lan,cn=gssapi,cn=auth" Finally, I commented out the "rootpw secret" line. > [...] > cat >> /usr/local/etc/openldap/ldap.conf > base dc=example,dc=lan > uri ldaps://ldap.example.lan/ > tls_cacert /etc/exampleCA/cacert.pem I modified tls_cacert above in my configuration to look like this (keep reading): tls_cacert /etc/certs/myca.key At this point your steps end, so I took an educated guess. Note that I'm familiar with creating SSL certificates + requests, but getting them signed by a CA is something I usually rely upon a public CA for, not creating my own CA and self-signing my certs, so I may have gotten something wrong here. I followed this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssl.html What's confusing here is that your configuration refers to 4 separate PEMs: /etc/exampleCA/certs/ldap.pem /etc/exampleCA/private/ldap.pem /etc/exampleCA/certs/example.pem /etc/exampleCA/cacert.pem The FreeBSD documentation, for self-signed certs, only refers to two (new.crt and myca.key). I made the assumption that in this test setup I'm working with, I actually want to do the following: # mkdir /etc/certs # cd /etc/certs # openssl dsaparam -rand -genkey -out myRSA.key 1024 # openssl gendsa -des3 -out myca.key myRSA.key [...entered in a 4 character PEM key of "abcd"...] # openssl req -new -x509 -days 365 -key myca.key -out new.crt [...] Common Name (eg, YOUR name) []:ldap.example.lan [...] # /usr/local/etc/rc.d/slapd start Starting slapd. /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd syslog shows this is the error: Jul 15 08:08:47 testbox slapd[61084]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 15 2010 07:31:07) $ root@testbox.example.lan:/usr/ports/net/openldap24-server/work/openldap-2.4.23/servers/slapd Jul 15 08:08:48 testbox slapd[61084]: line 65 (authz-regexp) Jul 15 08:08:48 testbox slapd[61084]: /usr/local/etc/openldap/slapd.conf: line 65: keyword <authz-regexp> missing <regexp> <DN> argument If you'd rather set all of this stuff up yourself (vs. me fiddling around with it, since I really don't know how to configure all of this), I can provide you root-level SSH access to the testbox and can let you build + configure everything yourself. Just let me know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100715151433.GA71946>