You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tommy Schneider <to...@gmail.com> on 2019/02/08 11:54:07 UTC
Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed
authenticate() test"
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.com@MYCOMPANY.COM
Found ticket for
HTTP/mymachine.mycompany.com@MYCOMPANY.COM to go to
krbtgt/MYCOMPANY.COM@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.com@MYCOMPANY.COM
Added key: 17version: 15
Added key: 18version: 15
Added key: 23version: 15
Found unsupported keytype (3) for
HTTP/mymachine.mycompany.com@MYCOMPANY.COM
Found unsupported keytype (1) for
HTTP/mymachine.mycompany.com@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/myusername@MYCOMPANY.COM
to myusername@MYCOMPANY.COM|
HTTP/mymachine.mycompany.com@MYCOMPANY.COM
>>> KrbApReq: authenticate succeed.
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
>>>Delegated Creds have pname=myusername@MYCOMPANY.COM
sname=krbtgt/MYCOMPANY.COM@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 "myusername@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
thx and kind regards,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed
authenticate() test"
Posted by Tommy Schneider <to...@gmail.com>.
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.com@MYCOMPANY.COM
> >> Found ticket for
> >> HTTP/mymachine.mycompany.com@MYCOMPANY.COM to go to
> >> krbtgt/MYCOMPANY.COM@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.com@MYCOMPANY.COM
> >> Added key: 17version: 15
> >> Added key: 18version: 15
> >> Added key: 23version: 15
> >> Found unsupported keytype (3) for
> >> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
> >> Found unsupported keytype (1) for
> >> HTTP/mymachine.mycompany.com@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/myusername@MYCOMPANY.COM
> >>
> >> to myusername@MYCOMPANY.COM|
> >> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
> >> >>> KrbApReq: authenticate succeed.
> >> >>> EType:
> >> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
> >> >>>Delegated Creds have pname=myusername@MYCOMPANY.COM
> >> sname=krbtgt/MYCOMPANY.COM@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 "myusername@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed
authenticate() test"
Posted by 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.com@MYCOMPANY.COM
>> Found ticket for
>> HTTP/mymachine.mycompany.com@MYCOMPANY.COM to go to
>> krbtgt/MYCOMPANY.COM@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.com@MYCOMPANY.COM
>> Added key: 17version: 15
>> Added key: 18version: 15
>> Added key: 23version: 15
>> Found unsupported keytype (3) for
>> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
>> Found unsupported keytype (1) for
>> HTTP/mymachine.mycompany.com@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/myusername@MYCOMPANY.COM
>>
>> to myusername@MYCOMPANY.COM|
>> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
>> >>> KrbApReq: authenticate succeed.
>> >>> EType:
>> sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
>> >>>Delegated Creds have pname=myusername@MYCOMPANY.COM
>> sname=krbtgt/MYCOMPANY.COM@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 "myusername@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5 SPNEGO Active Directory stuck with a "Failed
authenticate() test"
Posted by Michael Osipov <mi...@apache.org>.
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.com@MYCOMPANY.COM
> Found ticket for
> HTTP/mymachine.mycompany.com@MYCOMPANY.COM to go to
> krbtgt/MYCOMPANY.COM@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.com@MYCOMPANY.COM
> Added key: 17version: 15
> Added key: 18version: 15
> Added key: 23version: 15
> Found unsupported keytype (3) for
> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
> Found unsupported keytype (1) for
> HTTP/mymachine.mycompany.com@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/myusername@MYCOMPANY.COM
> to myusername@MYCOMPANY.COM|
> HTTP/mymachine.mycompany.com@MYCOMPANY.COM
> >>> KrbApReq: authenticate succeed.
> >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
> >>>Delegated Creds have pname=myusername@MYCOMPANY.COM
> sname=krbtgt/MYCOMPANY.COM@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 "myusername@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org