Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 9668 - openldap w/GSSAPI (sasl) fails to authenticate
Summary: openldap w/GSSAPI (sasl) fails to authenticate
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Nick Hadaway
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-25 16:15 UTC by Michael Farnbach
Modified: 2003-02-04 19:42 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Updated ebuild (openldap-2.0.25-r3.ebuild,2.26 KB, text/plain)
2002-10-28 17:10 UTC, Andy Dustman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Farnbach 2002-10-25 16:15:50 UTC
Merged krb5 1.2.5-r2, cyrus-sasl 2.1.7-r3, openldap 2.0.25-r2

USE="X -gnome -kde -arts \
	mms \
	ncurses readline \
	pam ssl sasl crypt socks5 imap ldap tcpd kerberos \
	guile java perl python ruby slang libwww libg++ pic \
	berkdb mysql postgres odbc -gdbm \
	gpm zlib"

when I execute an ldapsearch with -I and -Y GSSAPI I get


<== slap_sasl_bind: authzdn: "uid=ldapadm/onlawn"
send_ldap_sasl: err=0 len=-1
send_ldap_response: msgid=3 tag=97 err=0
ber_flush: 14 bytes to sd 9
<== slap_sasl_bind: rc=0
connection_get(9): got connid=3
connection_read(9): checking for input on id=3
ldap_pvt_sasl_install
ber_get_next
sb_sasl_pkt_length: received illegal packet length of 129 bytes
ber_get_next on fd 9 failed errno=0 (Success)
connection_read(9): input error=-2 id=3, closing.
connection_closing: readying conn=3 sd=9 for close
connection_close: conn=3 sd=9
connection_get(14): got connid=4
connection_read(14): checking for input on id=4
ber_get_next
ber_get_next on fd 14 failed errno=0 (Success)
connection_read(14): input error=-2 id=4, closing.
connection_closing: readying conn=4 sd=14 for close
connection_close: conn=4 sd=14
TLS trace: SSL3 alert write:warning:close notify

On the client side I see...

SASL/GSSAPI authentication started
SASL Interaction
Please enter your authorization name: 
SASL SSF: 56
SASL installing layers
ldap_result: Can't contact LDAP server

klist shows...

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ldapadm/onlawn@REALM.NET

Valid starting     Expires            Service principal
10/25/02 14:31:10  10/26/02 00:31:08  krbtgt/REALM.NET@REALM.NET
10/25/02 14:31:19  10/26/02 00:31:08  ldap/host@REALM.NET


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Comment 1 Andy Dustman 2002-10-28 17:10:43 UTC
Created attachment 5150 [details]
Updated ebuild

See if this ebuild helps. It has explicit support for kerberos and sasl USE
flags. Also, from what I can tell from the README and the openldap.org site,
OpenLDAP-2.0.x will NOT work with Cyrus-SASL-2.0+ and you must use a 1.5.x
version. This is reflected in the dependencies. You may have to unmask
cyrus-sasl or emerge the correct .ebuild for 1.5.x to get it installed.
Comment 2 Michael Farnbach 2002-10-28 17:28:58 UTC
Oops, forgot to mention that I did install Cyrus 1.5.7 as it won't compile
without it.  The cyrus version was the one that emerge -s told me I had, and I
forgot to mention the other one.
Comment 3 Michael Farnbach 2002-10-28 21:28:11 UTC
The ebuild is wonderful, I just tried it out.  I hope it goes into production.  Unfortunately the GSSAPI thing is still not working, and the "-k" option in ldapsearch still returns "compiled without kerberos support".  But that is probably becuase I don't have krb v4 installed, and the GSSAPI thing appears to be an upstream bug
Comment 4 Andy Dustman 2002-10-29 13:08:11 UTC
Is your cyrus-sasl compiled with kerberos support? The ebuild has
IUSE="kerberos". However, it appears to rely on the configure step to find
kerberos automatically, and it's explicitly --disable-krb4. (I'm looking at
cyrus-sasl-1.5.27-r5.ebuild.) --enable-gssapi (which is specified) will turn it
on and it looks like it should work with both the MIT krb5 and heimdal.

It looks like the the 1.5.27 ebuild could use some more work.
Comment 5 Michael Farnbach 2002-10-29 13:45:51 UTC
It is compiled with krb v5, but not krb v4.

I've never worried much about the "-k" option for ldapsearch since "-Y GSSAPI"
is the one I use (which uses kv5.)

I have some old gentoo builds around that use the GSSAPI just fine (but that was
when I was hand tweaking the ebuilds).  I'm not sure this is an upstream bug,
but here is the evidence I've collected...

The particular error mentioned in the first post contains a string
"sb_sasl_pkt_length: received illegal packet length of 129 bytes" which for
various lengths has turned up in BSD and Solaris builds of this combination. 
One of the proposed solutions *was* to use sasl2.

http://www.netsys.com/openldap-software/2002/07/msg00005.html

for the most relevant info I could find.

http://www.openldap.org/lists/openldap-devel/200206/msg00041.html

contains an old patch that was supposed to fix this problem.
Comment 6 Nick Hadaway 2002-12-01 21:43:11 UTC
The newest versions of ldap and sasl are now available in portage.  They are
currently marked unstable.  If you have any luck using the newer versions please
let me know.  I would like to unmask them if they fix problems for you.
Comment 7 Nick Hadaway 2002-12-18 21:42:02 UTC
The OpenLDAP-2.1.x series includes actual working code for sasl authentication.

The 1.5.x and 2.0.x series have what is considered experimental sasl support.

OpenLDAP-2.1.9 is currently available in portage.