Hello Rainer,
It turned out that the KeepAlive setting of Apache could solve our issue. Thanks for the tip! Best, Robin -----Original message----- From: Rainer Jung <rainer.j...@kippdata.de> Sent: Wed 09-06-2010 13:00 To: Tomcat Users List <users@tomcat.apache.org>; Subject: Re: Question on IE zones with Mod_jk 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
