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
