[jcifs] NTLM authentication performance

eglass1 at attbi.com eglass1 at attbi.com
Mon May 19 20:42:47 EST 2003


> > The problem is that POSTs will fail (since they will be expecting the
> > server to re-negotiate NTLM before they send the data).
> >
> > Unfortunately, I wasn't able to figure out a way around this.  At first,
> > I tried sending a "Connection: close" header from the front page
> > (thinking that if I terminated the connection, IE would "forget" that
> > NTLM was negotiated).  It still kept sending the Type 1 with an empty
> > POST, however.  I also tried closing the connection and redirecting to
> > another page (thinking that the redirect might make it forget about
> > NTLM); this didn't work either.  Apparently, once NTLM has been
> > negotiated to a server, there doesn't seem to be any way to stop this
> > behavior.  This is probably a security "feature" (to prevent someone
> > from hijacking the connection and sniffing the POST data).  You could
> > possibly redirect to another *server*, and then back again, but that is
> > just plain kludgy.
> >
> 
> I even tried to switch to BASIC authentication after NTLM has been
> authenticated but I couldn't get it to work quite right.
> 
> > I'll keep looking at this -- this is interesting behavior, and deserves
> > some scrutiny.  In the meantime, unfortunately, you will probably have
> > to use NTLM on all your POST pages.

The solution to the above (or "a" solution at least; there are probably others) 
is to do this in your servlet/JSP:

if (request.getHeader("Authorization") != null) {
    response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
}

This will only change the status if an authorization header is present; the 
only time you would see one in a page using our NTLM stuff is in the Type 3 
request (the Type 1 request would be captured and processed by the 
filter/servlet before reaching your page).  IE interprets this response to mean 
that NTLM negotiation was unsuccessful, and subsequent requests (i.e., POSTs) 
act as if it had never taken place.

I'm going to do a bit more testing with this approach; if it doesn't break 
anything, it may be useful to put into the main codebase as an option 
(jcifs.http.dropNtlm or something).  Setting the status after handling the Type 
3 message in the filter/servlet would cut out a roundtrip for all subsequent 
POSTs.  Theoretically, it could make our implementation more efficient than 
Microsoft's.  In the meantime, you can either set the status manually in all 
your affected pages or do a custom tweak; the appropriate place to add it would 
probably be in NtlmSsp.doAuthentication, around line 170:

...
} else if (src[8] == 3) {
    resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    return decodeType3Message(src);
}
...


Eric



More information about the jcifs mailing list