Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4C0F5C5C.8050409@ice-sa.com>
Date: Wed, 09 Jun 2010 11:18:20 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Question on IE zones with Mod_jk
References: <vmime.4c0e0906.30f6.12d9b2a5925e266@zarafanlcom.intra.nlcom.nl>
In-Reply-To: <vmime.4c0e0906.30f6.12d9b2a5925e266@zarafanlcom.intra.nlcom.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Robin Diederen wrote:
> Hi Andre,
> 
> Thanks for the tip. What should I be looking for when analyzing this communication?

You should be examining the detail of the requests/responses between 
bnrowser and server, to see if your assumptions are correct about the 
redirection etc..

A 401 response is not an error.  It is the server telling the browser 
that this resource is protected and requires authentication.
With NTLM, there is a 3-phase exchange that must take place, before the 
connection is authenticated.  Maybe that sequence is not being 
respected, and therefore IE thinks your are "somewhere else".
Also, the NTLM authentication system (starting with v2) is specially 
designed to avoid "man in the middle" attacks, so this can give problems 
with firewalls and proxies, and in this case you do have a man in the 
middle (Apache+mod_jk).
It is difficult for anyone else than yourself to debug this, because by 
definition, one must be inside your Windows domain to see really what 
happens.

To even begin to help, you need to be really precise when supplying the 
information about the components you are using (versions). "The latest 
versions" is not precise, because there are dozens of sites where you 
can download each of these modules, and their latest versions may not match.

You should also find out from your windows network security people, 
which kind of authentication (and NTLM version) your servers and 
workstations should be using (for example, if NTLMv2 is mandatory, or if 
NTLMv1 is allowed also).

You can also change the log level of mod_jk (e.g. to "debug") and see if 
the request from mod_jk to Tomcat contains a user-id or not.

Browser/server authentication with NTLM is a sequence like this :
1) browser sends request to server, without authentication
2) server responds with 401 (auth required, type=NTLM)
3) browser re-sends request with an Authorization header, type=NTLM, 
plus an encoded token
4) server responds with a new (different) 401 response, type=NTLM, plus 
also an encoded token
5) browser repeats the request again, with an Authorization header, 
type=NTLM, with a final encoded token
6) server now checks, and grants or denies the authentication.  If 
granted, it sends the requested document. If denied, it sends a 403 
response (forbidden).
All the above must happen on the same browser-to-server TCP connection, 
because in the end it is this connection which will be authenticated.
If the connection is somehow broken in the middle and a new connection 
created, it will not work.

But first, check with Fiddler2 the exact sequence of requests/responses, 
and see if that matches your assumptions.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org