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
