[jcifs] NTLM authentication performance

[Eric]

Jason Bainbridge wrote:
> I'm guessing I am doing some dumbass thing as I am only realtively new to Java
> still but I can't for the life of me get the below to work:
> 
> OS: Windows 2000 Pro,
> JDK: Sun 1.4.0
> Tomcat 4.1.24 with modjk2 running inprocess with Apache
> 
> I compiled the attached servlet in the jcifs.http package as it was setup,
> deployed it to my webapp, removed the filter from web.xml and added the
> following instead:
> 
> <servlet>
>     <servlet-name>FrontPage</servlet-name>
>     <jsp-file>/intranet/index.jsp</jsp-file>
>     <init-param>
>         <param-name>jcifs.http.domainController</param-name>
>         <param-value>192.168.0.1</param-value>
>     </init-param>
> </servlet>
> <servlet-mapping>
>     <servlet-name>FrontPage</servlet-name>
>     <url-pattern>/intranet/index.jsp</url-pattern>
> </servlet-mapping>
> 
> and then I added <%@ page extends="jcifs.http.NtlmJspBase" %> to the top of
> index.jsp
> 
> Am I missing a step here does FrontPAge actually have to physically exist? If
> so what does it need to do?
> 

This is just how init-params are passed to jsp files;  you create a 
servlet entry (with any name, FrontPage is just an example), and instead 
of specifying a servlet-class, you specify a jsp-file.  You still need 
to provide a servlet-mapping for FrontPage to explicitly map the 
jsp-file; internally all *.jsp are mapped to a container-provided 
servlet, which you need to override to properly receive the init-params.


> With my current config the page loads first timeall the way up to my
> getremoteuser call (that was working fine before with the filter) but
> subsequent requests result in  HTTP Status 503 - No domain controller
> specified. errors in Tomcat. Any ideas? I'm sure I'm missing something
> obvious...
> 
> The reason I don't want to use the filter is that I only need to retrieve the
> logged in user details to use within the web application's own security and if
> I use the filter than it has to be on all pages otherwise POST won't work.
>

You shouldn't ever have to use anything but the filter under a 2.3 
container; I don't think there are any additional features provided by 
the legacy stuff.  Assuming your "entry page" to your web app is 
index.jsp (and that's the only page you want the filter to affect), you 
would do the following in web.xml

<filter>
     <filter-name>ntlm</filter-name>
     </filter-class>jcifs.http.NtlmHttpFilter</filter-class>
     <init-param>
         <param-name>jcifs.http.domainController</param-name>
         <param-value>10.10.2.20</param-value>
     </init-param>
</filter>
<filter-mapping>
     <filter-name>ntlm</filter-name>
     <url-pattern>/index.jsp</url-pattern>
</filter-mapping>

The filter should provide authentication for 
http://somebox/someapp/index.jsp, and all other pages/servlets in 
"someapp" would be unaffected.

However, none of these approaches addresses the item you are looking for 
-- basically (if I understand you correctly) you just want to do NTLM 
against the front page (one time), and then perform user identification 
manually from then on, using your own system, with no NTLM involved. 
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'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.

Eric