On 08/02/2019 21:43, Michael Osipov wrote: > Am 2019-02-08 um 12:54 schrieb Tommy Schneider: >> Hello, >> >> I'm trying to set up Tomcat 8.5 with SPNEGO in the following environment: >> >> Tomcat: 8.5.37 built: Dec 12 2018 12:07:02 UTC >> Platform/OS: AIX 7.2 ppc64 >> Java: Eclipse OpenJ9 9-internal+0-adhoc.jenkins >> >>> From what I can see in the catalina log I think it's almost working >> (AD user is returned back correctly), but in the web application I >> always get stuck with a HTTP 401. No matter whether I'm using a JNDI >> realm or a simple JAAS realm. I also tried different approaches in the >> application's web.xml like using "*" as generic role name or >> specifiying a list of role names like they should come back from the >> AD). I'm starting to think the cause may still be somewhere in the >> SPNEGO/Kerberos stuff and not in my realm/application config. >> >> Currently I'm trying to use a simple JAAS realm (as I found a tutorial >> saying this is the simplest way to go when you just need the user name >> and no roles) >> snippet from server.xml >> <Host name="localhost" appBase="webapps" unpackWARs="true" >> autoDeploy="true"> >> <Context docBase="SPNEGO.war" path=""> >> <Valve >> className="org.apache.catalina.authenticator.SpnegoAuthenticator" >> storeDelegatedCredential="true"> >> <Realm >> className="org.apache.catalina.realm.JAASRealm" >> allRolesMode="strictAuthOnly" /> >> </Context> >> >> snippet from catalina.out: >> Found KeyTab /opt/apache-tomcat-8.5/conf/tomcat.keytab for >> HTTP/mymachine.mycompany....@mycompany.com >> Found ticket for >> HTTP/mymachine.mycompany....@mycompany.com to go to >> krbtgt/mycompany....@mycompany.com expiring on Fri Feb 08 21:26:27 CET >> 2019 >> Entered Krb5Context.acceptSecContext with state=STATE_NEW >> Looking for keys for: >> HTTP/mymachine.mycompany....@mycompany.com >> Added key: 17version: 15 >> Added key: 18version: 15 >> Added key: 23version: 15 >> Found unsupported keytype (3) for >> HTTP/mymachine.mycompany....@mycompany.com >> Found unsupported keytype (1) for >> HTTP/mymachine.mycompany....@mycompany.com >> >>> EType: >> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> Using builtin default etypes for permitted_enctypes >> default etypes for permitted_enctypes: 18 17 16 23. >> >>> EType: >> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> MemoryCache: add >> 1549621587/000784/231A915D0FE70A039CF82095FC685C843F4D981D20A70F972015D8EB16D07CA5/myusern...@mycompany.com >> >> to myusern...@mycompany.com| >> HTTP/mymachine.mycompany....@mycompany.com >> >>> KrbApReq: authenticate succeed. >> >>> EType: >> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> >>>Delegated Creds have pname=myusern...@mycompany.com >> sname=krbtgt/mycompany....@mycompany.com authtime=null >> starttime=20190208095329Z >> endtime=20190208195235ZrenewTill=20190215095235Z >> Krb5Context setting peerSeqNumber to: 883655442 >> >>> EType: >> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> Krb5Context setting mySeqNumber to: 318684000 >> [Krb5LoginModule]: Entering logout >> [Krb5LoginModule]: logged out Subject >> 08-Feb-2019 11:26:27.415 FINE [https-jsse-nio-443-exec-5] >> org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed >> authenticate() test >> >> I'm happy with the part where "myusern...@mycompany.com" is returned >> back from the AD, so I think most of the stuff is configured correctly >> so far. However I have no idea what the last 3 lines indicate. Is it >> ok that the "logout" occurs here? What causes the authenticator to >> fail? Is this still related to the SPNEGO stuff or is it caused by the >> realm or an incorrect web.xml in the application (I tried different >> variants here and it all seems to end up with a >> "org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed >> authenticate() test". >> >> Let me know if you need more configuration details. >> Any help would be greatly appreciated > > We need more debug output. This doesn't really help. Please enable it, > it will help. The Kerberos debug output you see is is just Sun-internal > which has nothing to do with the Tomcat code.
To be more specific, add the following to you logging.properties: org.apache.catalina.authenticator.level = FINE Restart Tomcat and then try the test again. Mark > > The logout() is performed on the LoginContext required to obtain server > credentials. The are released (hence logout performed) as soon as the > security context has been established and the GSS src name has been > obtained. > > Michael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
