Hi,
I turned on the logging as you recommended, this is what it get in the
catalina.out
Krb5Context setting mySeqNumber to: 441582303
[Krb5LoginModule]: Entering logout
[Krb5LoginModule]: logged out Subject
13-Feb-2019 14:07:56.755 FINE [http-nio-8080-exec-3]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed
authenticate() test
13-Feb-2019 14:07:56.816 FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Security
checking request GET /favicon.ico
13-Feb-2019 14:07:56.816 FINE [http-nio-8080-exec-5]
org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking
constraint 'SecurityConstraint[Tomcat SPNEGO Login Example]' against
GET /favicon.ico --> true
13-Feb-2019 14:07:56.817 FINE [http-nio-8080-exec-5]
org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking
constraint 'SecurityConstraint[Tomcat SPNEGO Login Example]' against
GET /favicon.ico --> true
13-Feb-2019 14:07:56.817 FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling
hasUserDataPermission()
13-Feb-2019 14:07:56.817 FINE [http-nio-8080-exec-5]
org.apache.catalina.realm.RealmBase.hasUserDataPermission User data
constraint has no restrictions
13-Feb-2019 14:07:56.817 FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling
authenticate()
13-Feb-2019 14:07:56.818 FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.SpnegoAuthenticator.doAuthenticate
No authorization header sent by client
13-Feb-2019 14:07:56.820 FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed
authenticate() test
The part with the "No authorization header sent by client" seems to be
new, however I don't know what to conclude from that information.
Kind regards,
Thomas
Am Mo., 11. Feb. 2019 um 10:24 Uhr schrieb Mark Thomas <ma...@apache.org>:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
