[jcifs] Random "Internet Explorer Cannot display the Web page" on Windows 2008 server, IE 7 and Tomcat 6

[Michael B Allen]

Thanks André. Your summary of the situation is mostly accurate.
Although the JCIFS HTTP filter did actually validate the credentials
unlike many "fake" solutions posted in forums that just extract the
account name from one of the authentication tokens. The point being
that if you are unfortunate enough to still be using the HTTP filter,
at least you can rest easy knowing it is actually validating the
credentials against the domain.

I think it was good that you pointed out that JCIFS' primary purpose
has nothing to do with HTTP or servlet filters or even authenticating
clients. I always fail to mention that and I think many people have a
very different impression of what JCIFS actually is. It seems a
project is what it does and it so happed that the HTTP functionality
was much more popular than the CIFS functionality for a span of about
5 years or so. As a result I think "JCIFS" became synonymous with
"HTTP NTLM authentication" when in reality that was only a little
"hack" as you corrected put it.

The first line of text at the top of the JCIFS homepage reads:

  "JCIFS is an Open Source client library that implements the CIFS/SMB
networking protocol in 100% Java. CIFS is the standard file sharing
protocol on the Microsoft Windows platform ..."

The website has had that text there pretty much forever. But of course
no one reads this stuff and I'm not sure I fault them. Our website has
way too much text on it. Who in their right mind would bother to read
everything on the first page? It would take them an hour. One of these
days I will have to reduce it to a manageable amount of information
and organize it better so that people are directed properly.

OTOH, I thought the blue text at the top of the page about the HTTP
auth filter and the updated FAQ would be enough to let people know
what the story is. If there ever were a case for super annoying
blinking text in HTML, that might qualify.

But no, I think I'll just go on ignoring the HTTP filter questions.
There usually very easy to spot so it's not a big deal.

Thanks again,
Mike

On Mon, Nov 2, 2009 at 5:18 PM, André Warnier <aw at ice-sa.com> wrote:
> pardesh wrote:
>>
>> Michael B Allen <ioplex <at> gmail.com> writes:
>>
>>> Your response is totally false.
>>>
>>> All versions of Windows fully support both NTLMv1 and NTLMv2. Windows
>>> 2008 and Windows 7 just use NTLMv2 by default.
>>>
>>> JCIFS fully supports both NTLMv1 and NTLMv2 as a client. As a server
>>> it does not support NTLM or any other authentication protocol at all
>>> (although there is hack that allows it to validate NTLMv1 hashes as a
>>> server that is in the process of being removed from the JCIFS
>>> package).
>>>
>>> Mike
>>
>> Mike,
>>
>> What might be the cause for this random error page? Is the transport
>> socket being closed occasinally causing this issue?
>>
>
> Pardesh, and Joseph, and Venuganan (?),
>
> I am not the authority in this subject.  Michael is the authority.  But he
> is probably so tired of answering these same kinds of questions all the
> time, since a long time, that I am trying to help him out here.
>
> The point is :
>
> there is
>
> - the jCIFS package : that is a Java client package, which (as far as I
> understand it) allows one to write Java program that will talk to MS file
> servers etc.. through the SMB protocol, to share files, copy them etc... In
> the process, *as a client*, that package is also able to authenticate itself
> vis-a-vis these MS servers.
> That package works, is supported, continues to be developed, can be used
> with MS servers requiring all kinds of NTLM client authentication.
>
> and then there is (a very different thing)
>
> - a "hack" that existed at some point, which is a Java servlet filter called
> "jCIFS NTLM HTTP* something, which basically *is not developed and not
> supported anymore*.  That module, in limited circumstances and for NTLMv1
> authentication only, at some point in the past was kind of a solution which,
> for browsers accessing a webapp, was "faking" a MS authentication server,
> and allowed to retrieve the MS Domain user-id under which the browser's
> workstation was logged in, and pass it to Tomcat as a user-id.
>
> I have used that module myself in the past, up to the point about 2 years
> ago, when I started to experience some problems with it.
> The problems had to do with the fact that NTLMv2 is becoming the standard in
> Windows networks authentication, and that this servlet filter *does not
> support NTLMv2 and can not support it*.  It can not support it, because
> NTLMv2 was specifically designed to forbid the kind of "man in the middle"
> trick that this servlet filter used.
> (In other words, that servlet exploited a weakness of NTLMv1, which NTLMv2
> corrected.)
> All recent versions of Windows (workstations and servers) default to NTLMv2.
> So, if in your network there is one Vista station, or one Windows 2003 or
> higher domain controller, the default for them is to be set to accept only
> NTLMv2, and you will (occasionally or all the time) have problems with this
> servlet.  These problems will manifest themselves as failures to
> authenticate, broken connections or whatever.  But nobody is going to help
> analyse or fix these problems.
>
> So, you are welcome to keep losing your time with this servlet filter, and
> it may still work in some limited cases (like if you have only Windows XP
> stations and Win2K servers, and all are using NTLMv1), but in the end you
> will be faced with the fact that it does not work anymore nowadays in a
> general sense, and that nobody is going to fix it.
>
> So, my recommendation to all of you, is to look for some other software
> which does the same thing and works with NTLMv2.
> Jespa, indicated on the page, is one product that works.
>
> Jespa is free to test, and remains free for up to 25 domain users.
>
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/