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.
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
