On 09.06.2010 11:18, André Warnier wrote:
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.
Have a look at:
http://marc.info/?l=tomcat-user&m=119886120025980
Maybe that helps.
Caution: NTLM is a broken protocol. It assumes that the connection
between the client and the authenticating server does not change during
the NTLM flow of a couple of requests. If there is nothing between the
client and the authentication server, this is easy by just enabling HTTP
Keep Alive. If there is a reverse proxy between the client and the
backend, i.e. the proxy does not do the authentication, but the backend,
this will likely break, because proxies do not make any guarantees about
reusing the same backend conection even when the same client connection
is used for multiple requests. This is especially true for mod_jk and
mod_proxy.
It might work with low load, because then there might be only one
backend connection but when load increases more backend connections will
be opened and finally requests will be dispatched to different connections.
When using Apache you can "fix" that by using the prefork MPM. It is
signle threaded and each client connection is associated with a single
Apache process. mod_jk in combination with prefork only opens one
backend connection per process, so for prefork no connection switching
will happen.
Not sure whether that all really is your problem.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
