tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: isapi_redirect.dll fail in SSO on high cpu load
Date Wed, 21 Jul 2010 07:45:57 GMT
Yun Feng Chua wrote:
> Hi, 
> Currently using Tomcat 5.5 and isapi_redirect.dll 1.2.14 
(that is old, the current version is 1.2.30 or so)
in IIS 6.0
> Configure with IIS integrated authentication for SSO.

So, it is IIS doing the authentication with the browser, right ?

> Notice that under high cpu load in the server, 100% util, the website prompt for authentication.
> When the cpu load subsided, the SSO is working. 
> Any ideas why it prompt for authentication under heavy cpu load?

Not per se, but this does not sound like a Tomcat or mod_jk/isapi_redirect problem.
If IIS is doing the Windows Integrated Authentication (otherwise known as NTLM), this is a
dialog between the browser, the IIS server, and some domain controller (to check the
user's/browser's credentials).  mod_jk/isapi_redirect and Tomcat do not participate in
that dialog.
Only when the dialog is succesful, does IIS pass the request to mod_jk/isapi_redirect
(with a user-id), and from there to Tomcat.
At first sight, it looks as if, under heavy IIS load, IIS may have problems achieving the
NTLM user authentication (e.g., trouble contacting the domain controller ?).  If that is
the case, it will not be able to authenticate the browser's credentials, and will send
back a 401 error to the browser.  That is when the browser pops up a login dialog.

When you say "the website prompt for authentication", you mean that the browser shows the
built-in pop-up login window, right ?

Tip: with IE, you can get an add-on called Fiddler2, which captures and shows the exact
dialog between browser and server.  That is useful for this kind of problem.

Theoretically, you could also set the log level of mod_jk/isapi_redirect to "debug", and
see that the request do not even reach mod_jk/isapi_redirect or Tomcat.
But because this happens under heavy load, that would give you /tons/ of output to check,
and would not be very usable in this case. Specially since you are looking for request
that /do not/ reach Tomcat.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message