I've tested all the following public JDKs jdk-7u45-windows-i586.exe jdk-7u65-windows-i586.exe jdk-7u75-windows-i586.exe jdk-8-windows-i586.exe jdk-8u5-windows-i586.exe jdk-8u11-windows-i586.exe jdk-8u20-windows-i586.exe jdk-8u25-windows-i586.exe jdk-8u31-windows-i586.exe jdk-8u40-windows-i586.exe <-- Only this one fails SPNEGO / Bad GSS Token
Seems a recent "fix" must broken it. David ---------------------------------------- > Subject: Re: SPNEGO test configuration with Manager webapp > From: felix.schumac...@internetallee.de > Date: Sun, 29 Mar 2015 10:13:29 +0200 > To: users@tomcat.apache.org > > > > Am 28. März 2015 17:46:50 MEZ, schrieb Mark Thomas <ma...@apache.org>: >>On 28/03/2015 14:43, David Marsh wrote: >>> Ok so I went back to basics and created three new VM's. >>> >>> Windows Server 2008 R2 >>> Windows 7 Client >>> Windows 7 Tomcat >>> >>> I still had same issues, until I changed the Java on the tomcat >>server to JDK 7 u45. >>> >>> It appears there are breaking changes to JAAS/GSS in newer JDKs ? >> >>Thank you for doing all this testing. That is useful information to >>know. The next step (for you, me or anyone who has the time and wants >>to >>help) is to test subsequent Java 7 releases and see at which version it >>stops working. I'd hope that a review of the relevant change log would >>identify the change that triggered the breakage and provide some clues >>on how to fix it. >> >>It would be worth testing the Java 8 releases the same way. > > I read it, that jdk 7 works and jdk 8 is problematic. > > There are a few Kerberos related Chaves in jdk 8 ( > http://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html). > > Interesting are the two changes: > > * DES is disabled by default > * constrained delegation is supported. > > My guess would be, that it would help (in this case) to reenable DES by > adding allow_weak_crypto=true in the krb5.conf. > > Regards > Felix >> >>Mark >> >> >>> >>> David >>> >>> ---------------------------------------- >>>> From: dmars...@outlook.com >>>> To: users@tomcat.apache.org >>>> Subject: RE: SPNEGO test configuration with Manager webapp >>>> Date: Fri, 27 Mar 2015 23:40:06 +0000 >>>> >>>> By the way Tomcat 8 was running on JDK :- >>>> >>>> C:\Windows\system32>java -version >>>> java version "1.8.0_40" >>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>> Java HotSpot(TM) Client VM (build 25.40-b25, mixed mode) >>>> >>>> Version update 40 should include some JRE fixes around GSS and >>SPNEGO, including ignoring parts of NegoEx, however >>>> it does not seem to work. >>>> >>>> I've also created a Windows 7 client with same config just different >>DNS of win-pc02.kerbtest.local >>>> >>>> It has the same issue going from firefox to >>http://win-tc01.kerbtest.local/manager/html >>>> I get the same three 401's and the Negotiate. >>>> >>>> ---------------------------------------- >>>>> Date: Thu, 26 Mar 2015 12:11:34 +0100 >>>>> From: a...@ice-sa.com >>>>> To: users@tomcat.apache.org >>>>> Subject: Re: SPNEGO test configuration with Manager webapp >>>>> >>>>> David Marsh wrote: >>>>>> Hi Mark, >>>>>> >>>>>> Thanks for that, yes I've got 30 years windows experience, I can >>use Linux at a push but its not really my area expertise. >>>>>> >>>>>> I'm a Java / Windows programmer so I should be able to understand >>it, but not kerberos or Active Directory expert. >>>>>> >>>>>> I have used Waffle in the past with success and used JAAS/GSS-API >>in Java thick clients. >>>>>> >>>>>> I made the IE settings you outlined but it seems to still prompt. >>>>>> IE has win-tc01.kerbtest.local as a trusted site. >>>>>> Enable Windows Integrated Authentication is on >>>>>> Auto logon only in Intranet Zone is on >>>>>> >>>>>> I've been using Firefox to test and that does send 401 and >>negotiate, but causes the GSS token error mentioned. >>>>>> >>>>>> Active directory and krb5.ini are using eType 23 which is rc4-hmac >>>>>> >>>>>> The windows client OS and tomcat server OS has registry setting >>for allowtgtsessionkey set to 1 (enabled). >>>>>> >>>>>> Java kinit test works and stores a ticket in the Java session >>cache. >>>>>> >>>>>> So problem seems to be either :- >>>>>> >>>>>> 1. Browser sends bad token >>>>>> 2. Token is good but Oracle JDK 8 GSS-API cannot handle it >>>>>> >>>>> >>>>> Another shot almost in the dark : while browsing hundreds of >>Kerberos-related pages on the >>>>> WWW, one other recommendation which seems to appear regularly (and >>Mark also mentioned >>>>> that somewhere), is that each time you make a change somewhere, you >>should reboot the >>>>> machine afterward, before re-testing. (Particularly on Windows >>machines). >>>>> I know it's a PITA, but I have also found the same to be true >>sometimes when merely >>>>> dealing with NTLM matters. There are probably some hidden caches >>that get cleared only in >>>>> that way. >>>>> >>>>> >>>>>> many thanks >>>>>> >>>>>> David >>>>>> >>>>>>> Date: Thu, 26 Mar 2015 11:32:39 +0100 >>>>>>> From: a...@ice-sa.com >>>>>>> To: users@tomcat.apache.org >>>>>>> Subject: Re: SPNEGO test configuration with Manager webapp >>>>>>> >>>>>>> David Marsh wrote: >>>>>>>> Hi Mark, >>>>>>>> Thanks that would be great ! >>>>>>>> Do you have a good mechanism to test and ensure kerberos token >>is passed to tomcat and not NTLM token ? >>>>>>> I believe that I can answer that. >>>>>>> >>>>>>> And the basic answer is no. >>>>>>> >>>>>>> First the basic principle, valid for this and many many other >>areas : the server cannot >>>>>>> "impose" anything on the browser. The local user can always >>override anything received >>>>>>> from the server, by a setting in the browser. And a hacker can of >>course do anything. >>>>>>> All the server can do, is tell the browser what it will accept, >>and the browser can tell >>>>>>> the server ditto. >>>>>>> So, never assume the opposite, and you will save yourself a lot >>of fruitless searches and >>>>>>> dead-ends. >>>>>>> >>>>>>> Now more specific : >>>>>>> 1) For Kerberos to be used at all at the browser level, the >>server must send a 401 >>>>>>> response with "Negociate" as the requested authentication method. >>Unless it does that, >>>>>>> the browser will never even attempt to send a Kerberos >>"Authorization" back. >>>>>>> 2) for the browser to consider returning a Kerberos Authorization >>header to the server, >>>>>>> additional conditions depend on the browser. >>>>>>> For IE : >>>>>>> a) the "enable Windows Integrated Authentication" setting must be >>on (checked), whether >>>>>>> this is done locally by the user, or part of the standard IE >>settings company-wide, or >>>>>>> imposed by some "network policy" at corporate level. >>>>>>> b) the server to which the browser is talking, must be known to >>IE as either >>>>>>> - part of the "Intranet" >>>>>>> - or at least a "trusted" server >>>>>>> That is defined in IE's "security zones" (which again can be >>local, or corporation-wide). >>>>>>> >>>>>>> If condition (a) is not met, when the server sends a 401 >>"Negociate", IE will fall back to >>>>>>> NTLM, always. And there is nothing you can do about that at the >>server level. >>>>>>> (Funnily enough, disabling the "enable Windows Integrated >>Authentication" at the IE level, >>>>>>> has the effect of disabling Kerberos, but not NTLM). >>>>>>> >>>>>>> If condition (b) is not met, IE will try neither Kerberos nor >>NTLM, and it /might/ fall >>>>>>> back to Basic authentication, if its other settings allow that. >>That's when you see the >>>>>>> browser popup login dialog; and in an SSO context, this is a sure >>sign that something >>>>>>> isn't working as expected. >>>>>>> >>>>>>> Some authentication modules, at the server level, are able to >>adapt to what the browser >>>>>>> sends, others not. I believe that Waffle can accept either >>browser NTLM or Kerberos >>>>>>> authentication. Waffle works only on a Windows Tomcat server, not >>on a Linux Tomcat server. >>>>>>> I do not know about the SPNEGO thing in Tomcat (from the name, it >>should). >>>>>>> The Jespa module from www.ioplex.com does not handle Kerberos, >>just NTLM, but it works >>>>>>> under both Windows and Linux. >>>>>>> >>>>>>> And finally, about your problems : it seems that you have fallen >>in a very specific kind >>>>>>> of hell, because you are trying to talk to a Windows-based >>Kerberos KDC (which is using >>>>>>> Windows Kerberos libraries and encryption method choices and >>hostname formats etc..), from >>>>>>> a Java JVM-based "client" (in this case the Tomcat server, >>whatever its underlying >>>>>>> platform is), which is using Java Kerberos libraries and >>encryption method choices etc... >>>>>>> And it seems that between this Java Kerberos part and the Windows >>Kerberos part, there >>>>>>> are a number of areas of mutual incomprehension (such as which >>key encryption methods they >>>>>>> each implement, or which ones are the "default" ones for each). >>>>>>> >>>>>>> And I am sure that the issue can be resolved. But it is probably >>a question of finding >>>>>>> out which among the 25 or more settings one can alter on each >>side, overlap and either >>>>>>> agree or contradict eachother. >>>>>>> >>>>>>> One underlying issue is that, as well in corporations as on the >>WWW, the "Windows people" >>>>>>> and the "Linux people" tend to be 2 separate groups. If you ask >>the "Windows people" how >>>>>>> to set this up, they will tell you "just do this and it works" >>(assuming that all the >>>>>>> moving parts are Windows-based); and if you ask the "Linux >>people", they will tell you >>>>>>> "just do this and it works" (assuming that all the moving parts >>are Linux-based). >>>>>>> And there are very few people (and web pages) which span both >>worlds with their various >>>>>>> combinations. >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Date: Thu, 26 Mar 2015 09:00:22 +0000 >>>>>>>>> From: ma...@apache.org >>>>>>>>> To: users@tomcat.apache.org >>>>>>>>> Subject: Re: SPNEGO test configuration with Manager webapp >>>>>>>>> >>>>>>>>> On 26/03/2015 00:36, David Marsh wrote: >>>>>>>>>> Still getting :- >>>>>>>>>> java.security.PrivilegedActionException: GSSException: >>Defective token detected (Mechanism level: G >>>>>>>>>> SSHeader did not find the right tag) >>>>>>>>>> >>>>>>>>>> Folks here mention lack of NegoEx support or bugs in GSS-APi ? >>>>>>>>>> >>>>>>>>>> >>http://sourceforge.net/p/spnego/discussion/1003769/thread/990913cc/?page=1 >>>>>>>>>> >>>>>>>>>> Does Tomcat 8 work with NegoEx ? >>>>>>>>>> >>>>>>>>>> Is Windows 8.1 and Windows Server 2012 RC2 supported ? >>>>>>>>> My test environment is Windows 2008 R2 server and Windows 7. It >>is >>>>>>>>> certainly possibly security has been tightened between those >>versions >>>>>>>>> and 2012/R2 + 8 that means things don't work by default with >>Java. >>>>>>>>> >>>>>>>>> I'll see if I can find some time in the next few weeks to >>update my test >>>>>>>>> environment and do some more testing. >>>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>> >>--------------------------------------------------------------------- >>>>>>>>> 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 >>>>> >>>> >>>> >>--------------------------------------------------------------------- >>>> 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 > > > --------------------------------------------------------------------- > 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
