https://issues.apache.org/bugzilla/show_bug.cgi?id=57022
Bug ID: 57022 Summary: Tomcat Spnego authentication against Active Directory fails with Java 8 Product: Tomcat 7 Version: 7.0.55 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: detelinyorda...@gmail.com Created attachment 32059 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32059&action=edit Tomcat JAAS configuration Hello everyone, I'm successfully using Tomcat 7.0.55 configured with Spnego authentication against Active Directory running Windows 2008 Server and Java 1.7.0.51. After switching to Java 1.8.0_20, authentication does not work anymore, Tomcat logs the following error message: SEVERE: Exception performing authentication javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided ( Mechanism level: Failed to find any Kerberos tgt)]]; remaining name 'CN=Users,DC=example,DC=com' at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:169) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:236) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2696) at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2670) at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1941) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1446) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1297) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1233) at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2049) at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:1965) at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:513) at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:309) at org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:249) at org.apache.catalina.authenticator.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:255) Tomcat is configured according to the "Windows Authentication How-To" document, I'm attaching the krb5.ini, jaas.conf and server.xml that contains the JNDIRealm definition. I have investigated the problem and I believe it is related to the Kerberos constraint delegation support added in Java 8, see: http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-features.html http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6355584 It seems that per default, GSS API in Java 8 will attempt constraint delegation on the acceptor side, see referenced changes and in particular the getCredDelegState() method: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a1bbb8805e22 The result of this, is that Tomcat's JNDIRealm now finds the delegated credential delivered with the constraint delegation and switches GSSAPI security mechanism for JNDI/LDAP (this was not the case on Java 7). However, the Kerberos initiation during LDAP authentication does not find the Kerberos TGT in the Subject. After digging further, I noticed that the Subject used during the LDAP authentication is not set. Though the SpnegoAuthenticator initializes a Subject instance using Kerberos login via JAAS and this contains the obtained TGT, this Subject instance is not used for performing the LDAP authentication. I saw the following comment in JNDIRealm.getPrincipal: // Note: Subject already set in SPNEGO authenticator so no need for Subject.doAs() here So I decided to modify this and execute the getPrincipal using Subject.doAs() and the Subject instance available after the Kerberos login. This lead to successful authentication to LDAP and I was able to access the Spnego-secured webapp again. Please note that this setup is not using any file-system Kerberos credential cache, so it requires that the Kerberos TGT is available in the Subject instance associated with current ACC. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org