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
