Re: New installation for GSSAPI, sample application error

[Alberto Patino <jalbertop@aranea.com.mx>]

On Sun, 2003-11-02 at 10:09, Robert Fitzpatrick wrote:
> I am running Heimdal 0.6 and having trouble with the SASL and did not get any responses to help. My problem is just after installing and trying the sample application.
> 
> I am brand new to SASL setting up with GSSAPI support for Kerberos to be used with OpenLDAP. I
> have exported a key 'ldap/directory.webtent.net@WEBTENT.NET' into a
> keytab file readable by the sample application in the distribution. I
> start the sample server:
> 
> [root sample]# ./server -s ldap
> trying 10, 1, 6
> socket: Invalid argument
> trying 2, 1, 6
> trying 1, 1, 0
> 


This is a SASL configuration problem and not a Heimdal problem. So,
first think you MUST read under your sasl source directory the
doc/gssapi.html document.

Anyway be certain that you build SASL with GSSAPI support. The fact you
don't see the GSSAPI mechanism is because the GSSAPI plugin cannot be
loaded.

Please verify that you have libgssapiv2.so in your sasl directory. (
/usr/lib/sasl2)

This is a listing of my sasl directory:

[albertop@turing cyrus-sasl-2.1.15]$ ls /usr/lib/sasl2.1.15/
libanonymous.la         libcrammd5.so.2.0.15    libgssapiv2.so.2    
libplain.so
libanonymous.so         libdigestmd5.la         libgssapiv2.so.2.0.15 
libplain.so.2
libanonymous.so.2       libdigestmd5.so         libotp.la             
libplain.so.2.0.15
libanonymous.so.2.0.15  libdigestmd5.so.2       libotp.so             
libsasldb.la
libcrammd5.la           libdigestmd5.so.2.0.15  libotp.so.2           
libsasldb.so
libcrammd5.so           libgssapiv2.la          libotp.so.2.0.15      
libsasldb.so.2
libcrammd5.so.2         libgssapiv2.so 

I built with these options:
./configure  --with-gnu-ld --with-dblib=berkeley
--with-bdb-libdir=/usr/local/db-4.1.25.NC/lib
--with-bdb-incdir=/usr/local/db-4.1.25.NC/include
--with-openssl=/usr/local/openssl-0.9.7c/ --disable-krb4 --enable-shared
--enable-gssapi=/usr/local/heimdal-0.6
--prefix=/usr/local/cyrus-sasl-2.1.15
--with-plugindir=/usr/lib/sasl2.1.15
#

[albertop@turing sample]$ ./client turing
receiving capability list... recv: {46}
ANONYMOUS PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5
ANONYMOUS PLAIN GSSAPI OTP DIGEST-MD5 CRAM-MD5
please enter an authorization id:


If you do have libgssapiv2.so be certain that has been
built in the right way:

[albertop@turing cyrus-sasl-2.1.15]$ ldd
/usr/lib/sasl2.1.15/libgssapiv2.so 

        libgssapi.so.1 => /usr/local/heimdal-0.6/lib/libgssapi.so.1
(0x40008000)
        libkrb5.so.17 => /usr/local/heimdal-0.6/lib/libkrb5.so.17
(0x40018000)
        libasn1.so.6 => /usr/local/heimdal-0.6/lib/libasn1.so.6
(0x40058000)
        libroken.so.16 => /usr/local/heimdal-0.6/lib/libroken.so.16
(0x40083000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x400a9000)
        libcom_err.so.1 => /usr/local/heimdal-0.6/lib/libcom_err.so.1
(0x400d6000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x400d9000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libcrypto.so.0.9.7 =>
/usr/local/openssl-0.9.7c/lib/libcrypto.so.0.9.7 (0x400eb000)
        libdb-4.1.so => /usr/local/db-4.1.25.NC/lib/libdb-4.1.so
(0x401db000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libdl.so.2 => /lib/libdl.so.2 (0x402b6000)
        libz.so.1 => /usr/lib/libz.so.1 (0x402b9000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x402c7000)

  



> Then try to connect via the sample client:
> 
> [root sample]# ./client -s ldap -m GSSAPI directory
> receiving capability list... recv: {39}
> ANONYMOUS PLAIN OTP DIGEST-MD5 CRAM-MD5
> ANONYMOUS PLAIN OTP DIGEST-MD5 CRAM-MD5
> server doesn't offer mandatory mech 'GSSAPI'
> closing connection
> 
> Is it required at this point to have a service configuration file in the
> /usr/lib/sasl2 directory? My book is not clear on that and what it
> should be named, ldap? When the client tries the connection you see
> above, the server responds:
> 
> accepted new connection
> send: {39}
> ANONYMOUS PLAIN OTP DIGEST-MD5 CRAM-MD5
> client didn't choose mechanism
> closing connection
> 
> The cyrus-sasl-2.1.15 was installed with '--enable-gssapi=/usr', where
> '/usr' was the prefix for the Kerberos installation. Did not have any
> configuration or building errors.
> 
> Can someone point me to what I'm doing wrong?