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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
