Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LDAP with SASL authentication

92 views
Skip to first unread message

Andreas Schmid

unread,
Sep 15, 2004, 8:49:08 AM9/15/04
to
Hello,

I try to run the example from
http://java.sun.com/products/jndi/tutorial/ldap/security/gssapi.html .

This example works fine with Java 1.4 .
But with Java 1.5 I get this exception:

javax.naming.NamingException: [LDAP: error code 80 - GSSAPI:
gss_unwrap: A token had an invalid MIC; Success; ]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3029)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2732)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2646)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
at ldap4.JndiAction.performJndiOperation(GssExample.java:165)
at ldap4.JndiAction.run(GssExample.java:126)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at ldap4.GssExample.main(GssExample.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)


Can someone help, please?
Is this a bug in Java 1.5?

Karl J. Ots

unread,
Oct 13, 2004, 2:48:31 AM10/13/04
to
letoatr...@freenet.de (Andreas Schmid) wrote in message news:<70284f7b.04091...@posting.google.com>...

I'm having a similar problem:

javax.naming.NamingException: [LDAP: error code 80 - SASL(-1): generic
failure: GSSAPI Error: A token was invalid (No error)]


at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3029)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2732)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2646)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)

at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
at misc.LDAPTester$1.run(LDAPTester.java:56)
at misc.LDAPTester$1.run(LDAPTester.java:48)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at misc.LDAPTester.main(LDAPTester.java:45)

I also am using JDK 1.5.0. I haven't tested it with 1.4 and I have no
intention of doing so (I don't go backwards). As far as I can tell
I've followed the instructions in the GSS-API section of the JAAS
tutorial. Kerberos authenticaton works fine and command line access
using ldapsearch also works without a hitch.

Anyone?


P.S. The server is OpenLDAP 2.1 on Debian Sarge.

Karl J. Ots

unread,
Oct 13, 2004, 11:14:55 PM10/13/04
to
kj...@bigpond.com (Karl J. Ots) wrote in message news:<7a25d7b7.04101...@posting.google.com>...

Well now, I'm getting a different error if I use the JDK's kinit to
log into
kerberos (Before I was using MIT's kinit):

Exception in thread "main" java.security.PrivilegedActionException:
javax.naming.AuthenticationException: GSSAPI [Root exception is
javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Invalid
option setting in ticket request. (101))]]


at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)

at misc.LDAPTester.main(LDAPTester.java:61)
Caused by: javax.naming.AuthenticationException: GSSAPI [Root
exception is javax.security.sasl.SaslException: GSS initiate failed
[Caused by GSSException: No valid credentials provided (Mechanism
level: Invalid option setting in ticket request. (101))]]
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:150)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2637)


at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)

at misc.LDAPTester$1.run(LDAPTester.java:72)
at misc.LDAPTester$1.run(LDAPTester.java:64)
... 3 more
Caused by: javax.security.sasl.SaslException: GSS initiate failed
[Caused by GSSException: No valid credentials provided (Mechanism
level: Invalid option setting in ticket request. (101))]
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:174)
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:105)
... 17 more
Caused by: GSSException: No valid credentials provided (Mechanism
level: Invalid option setting in ticket request. (101))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:654)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:213)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158)
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:155)
... 18 more
Caused by: KrbException: Invalid option setting in ticket request.
(101)
at sun.security.krb5.KrbTgsReq.<init>(DashoA12275:131)
at sun.security.krb5.KrbTgsReq.<init>(DashoA12275:93)
at sun.security.krb5.internal.a1.a(DashoA12275:289)
at sun.security.krb5.internal.a1.a(DashoA12275:106)
at sun.security.krb5.Credentials.acquireServiceCreds(DashoA12275:527)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:583)
... 21 more

It appears to be getting furthur along then with MIT's credentials
cache, making it past the connect() method of
com.sun.jndi.ldap.LdapCtx. Oddly enough I still get the former error
when I'm not using a credentials cache (i.e. by not specifiying
useTicketCache in the login module configuration file).

So to summarize - I get the former error if I use MIT's kinit to
create the credential cache or I don't use a credentil cache at all
(and supply username and password), and I get the latter error if I
use the JDK's kinit to create the credentials cache.

Once again I can still access the LDAP server using the command line
tools, using either kinit to log in.

Karl J. Ots

unread,
Oct 15, 2004, 2:32:47 AM10/15/04
to
I caved in and tested the code on 1.4.2. After much teeth-gnashing
and frustrations (firstly getting rid of any 1.5 code, then spending
most of the day struggling with encryption types (1.4 doesn't support
des3-cbc-sha1)) I finally got essentialy the same code authenticating
successfully.

I have also tried using Novell's JLDAP classes, without success. It
doesn't even complete the SASL bind. An exception is thrown upon a
search with the message "SASL bind in progress". A quick squiz at
slapd's logs reveals that the SASL bind procedures are only invoked
twice, whereas ldapsearch and the JNDI code invoke them three times.

Since the JNDI code worked fine for 1.4 and choked with the error "A
token was invalid" with 1.5, I can only assume the GSSAPI code in 1.5
is broken. If this is the case, I have a simple message for Sun:

FIXITFIXITFIXITFIXITFIXITFIXITFIXITFIXIT!!!!!

Gotta go now. I've already wasted two days on this. At least it's
the weekend...

P.S. FIXITFIXITFIXIT!!!!!!!!!

0 new messages