[jcifs] jcifs NtlmHttpFilter - random "Page cannot be displayed"

Michael B Allen miallen at ioplex.com
Fri Apr 4 15:29:10 GMT 2008


On Fri, 4 Apr 2008 04:30:04 -0700 (PDT)
RicardoSanchez <ricardo.sanchez at polarisworld.com> wrote:

> 
> Hi,
> 
> I'm using jcifs-1.2.18e.jar in a jbosss-tomcat environment to provide sso
> for a web site: users with internet explorer are automatically
> authenticated. In a normal morning there can be 500 users accessing to the
> site, with several visits.
> Before, users had to type user and password, and I validated them against
> the Active Directory LDAP. It worked ok, never had a problem.
> 
> As you know, the NTLM authentication works in three steps:
> -Internet explorer sends request #1 without an NTLM header -> server sends a
> 401 response code with a ("WWW-Authenticate", "NTLM") header
> -IE sends request #2 with an NTLM header -> server sends a 401 response code
> with a ("WWW-Authenticate", "NTLM " + msg) header
> -IE sends request #3 with an NTLM header -> server sends a 200 response code
> 
> The problem is the following: in the hours of maximum accesses, sometimes
> when a user tries to access to the site, the #3 request is never sent. For
> some reason, IE doesn't like the response to the request #2, and shows a
> "The page cannot be displayed" error.
> 
> This only happens in "peak hours": many errors in busy days, no errors in
> weekends or holidays.
> 
> I increased the log level but I can't find the problem: for some reason the
> request #3 is not sent.
> 
> Any help would be highly appreciated

Hi Ricardo,

Actually there is a bug that could be responsible for the behavior
you're seeing.

It was reported that, under high load, it is possible for JCIFS to
"hiccup" every jcifs.smb.client.soTimeout milliseconds (default
is 35 seconds). Meaning if you put JCIFS under a constant stream of
authentications, it will likely fail once every 35 seconds. If JCIFS is
not under a constant stream of authentications the hiccup is much less
likely to occur. It seems JCIFS can attempt to disconnect and cause a
failure. Currently there is no fix for this bug.

Try setting jcifs.smb.client.soTimeout to 350000 instead of the default
35000. If that reduces the incidence by 10x then the "hiccup" bug is
probably responsible.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/


More information about the jcifs mailing list