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