[jcifs] Very generic question about NTLM HTTP authentication

[André Warnier]

Hi.

I have tried to find information on the topic of NTLM HTTP 
authentication with Windows Vista and/or NTLMv2, and I am a bit confused.
I am aware of this by Michael Allen :
http://lists.samba.org/archive/jcifs/2008-October/008227.html
and I even understand the argument in it.
I am still a bit confused however, because I have seen later posts in 
various places that tend to indicate that jCIFS NTLM HTTP authentication 
would finally work after all with Windows Vista and/or NTLMv2.

I have an application that consists of parts running under Apache httpd 
2.x, parts running under Tomcat 4.x and above. The part under Tomcat is 
always accessed through Apache and mod_jk.  Until now, I have been using 
the jCIFS-based HTTP authentication filter happily, in various 
configurations, to provide my customers so inclined with an SSO solution 
based on the Windows client station's Windows domain login.

Anyway, recently a customer started deploying Vista workstations, and 
with these stations it doesn't work anymore.  I don't know if it is due 
to something specific to Vista, or to NTLMv2 or whatever.
(Vista/IE sends the type 1 header, the Tomcat server responds with a 
Type 2 header, after which Vista/IE immediately show a blank page 
seemingly with an underlying "forbidden" error; it doesn't even show the 
popup login dialog).
The customer interface which I have tells me that they are using NTLMv2, 
but on the other hand the same scheme works on all their XP worksations 
without fail since 6 months, and they have not changed their DCs or 
policies. They just plugged-in a Vista workstation, they say.

We have been playing around with the jcifs parameters at the HTTP filter 
level, and the registry key at the jCIFS Tomcat host level, and at the 
Vista level, without success. The highest jcfis.jar which we tried was 
1.3.0, and I recently saw some messages which tend to indicate that that 
one was broken respective to the HTTP authentication.
I'm willing to try 1.3.1 or higher, but since this all requires some 
serious disturbance at the customer level, I'd rather only do it if it 
presents a significant chance of success.
I've also looked at alternative schemes such as the Apache auth_SSPI 
module, but I'm not sure at this stage that it would solve the problem 
either.

So to finally put my question : is the following supposed to work, or 
could it under some conditions, or can it not at all ?

In a configuration where the Tomcat host is a Windows server, if one 
configured the jCIFS HTTP filter (on that same server) to authenticate 
against that very server itself (say 127.0.0.1, since it is itself a 
server in the Windows domain), could it work ?

The first-cited article explains why NTLMv2 cannot work with the HTTP 
filter (the man-in-the-middle thing).
Somewhere else in the jCIFS documentation, it is mentioned that the 
server which one authenticates against (theoretically a DC), in fact 
does not need to be a DC at all, and can be any station that is in the 
Windows domain of interest.

I am reasoning that in this case, which happens to be the particular 
case of my current problematic client, there should be no question of 
MITM, or should there ?  The "server" part of the "server token" should 
really point to the machine itself against which IE is authenticating, 
or not ?

Or am I missing something still ?


If I am missing something, and it cannot work, then in all generality, 
what kind of mechanism would work ?  I am really open-minded in that 
respect.  I am considering up to using an IIS proxy server for my 
applications, thinking that this IIS server should be able to do proper 
client NTLM authentication, and that I should be able to figure out a 
way to pass this on with each request to my Apache and Tomcat parts.
Of course, this would not be my preferred solution, and I would much 
rather avoid an IIS proxy, or anything too proprietary.
Basically, what is needed at the level of the Apache and Tomcat 
applications is a user-id as a form of convenience-SSO, to avoid the 
user having to re-login at each application session.  The webserver 
applications themselves are only accessible through well-filtered 
mechanisms that limit the users in what they can do, on a single server 
inside an Intranet.

Thank you for your patience in reading this.