[jcifs] Is the work-around also the answer?
aw at ice-sa.com
Sun Oct 23 07:01:31 MDT 2011
Bret Comstock Waldow wrote:
> On 23/10/11 18:09, André Warnier wrote:
>> If I understand the above correctly, you are talking about the jCIFS
>> HTTP NTLM authentication filter.
> I think so, although my own exposure is new enough that I might be
> missing something.
>> If so, you should go the corresponding page on the website, and read
>> the notice that is highlighted. And really, really, believe it.
>> The fundamental part of it is that this filter can stop working at any
>> time, for example simply because the network admins have decided to
>> switch to NTLMv2 authentication (which is nowadays the default),
>> instead of continuing to support NTLMv1.
>> They may not even have "decided" this, but simply updated a Domain
>> Controller, making NTLMv2 the default in the process.
> No. That can't be done.
> This is Large, Huge, International Resource Company, and that's not
> going to happen. Period.
> There is a project in it's early stages to replace this software with
> something else, but I'm not doing that, and it won't happen soon. Maybe
> next year, but I have my doubts.
> I'm in Support, and I'm maintaining what's there, which will/must work
> 24/7/365 or huge amounts of money are lost. It WILL continue for months
> or years from now, and no one is going to flip switches like that and
> keep their job - full stop ("period" for you Yanks).
> There is no uncertainty or choice about this.
> I need the answers I ask for - that's the only help that can matter
> this time.
> I would really, really like to hear any ideas anyone has, because this
> is the problem I must solve, either by justifying the "work-around" as
> the solution, or by finding how the situation might have changed on our
> side, or "their" side (the people that manage the AD servers), so I can
> try to track it down.
> I am hoping that the people who have been managing jCIFS all this time
> (and fixing the problems that arose that led to suggesting the
> "pre-authentication" solution) can give me the benefit of their
> knowledge, which I can't acquire in any short time with the
> documentation that is available.
> I don't need to make the system work "like it should", or "the best way"
> - that is well outside my power.
> I need to know what has happened now with it as it is, and what to do
> about it. And if the "pre-authentication" is the proper fix, I need to
> be able to show that this is so, and not just that we're accepting a
> hack because we didn't look far enough (it matters).
> Please give me the benefit of your hard-won experience -
That is exactly what I did.
> again here, I would be grateful, and it will help me learn even if it's
> not the future way. Knowing the past is useful, sometimes. I am on a
> rotating roster for 24/7 support - if it breaks, I get woken up to fix it.
Well yes, maybe. In a way, I am always fascinated by people who have such certainties in
their opinions. But in this case, denying reality is not going to help you sleep better.
You described a problem whereby something which has been working for a long time, suddenly
doesn't work anymore in a number of cases.
Based on my experience, I told you what my best guess what, as to what causes such symptoms.
I am not telling you that this /is/ the problem. I am telling you that there is a very
strong probability that this is the problem, and that you should investigate further to
find out if this is really the issue, before you go chasing other rabbits.
The warning on the jCIFS website has been there for, mm.. 5 years ?
Since then, new Windows versions and updates have come, which have gradually replaced the
(relatively unsafe) NTLMv1 default by the (safer) NTLMv2 default, which is not supported
by the jCIFS filter, and never will be.
The random problems you are seeing may be caused for example by a circumstance like this :
- a group of workstations usually authenticate with a certain Domain Controller A, which
is set for NTLMv2, but (because it is an older machine) still accepts the older and
deprecated NTLMv1 as an alternative
- for some reason, this DC is turned off for a while (say for maintenance)
- the same group of workstations now authenticates with a backup DC, which happens to be
set for NTLMv2 *only*
It won't make a jot of difference for Windows logins, because since at least 5 years any
Windows workstation can authenticate using *either* NTLMv2 or NTLMv1, so they will
But jCIFS cannot automatically adapt, because it cannot support NTLMv2.
So it fails to authenticate. And when the primary DC is turned on again, it will work
again for a while.
You get it now ?
Again, I am not telling you that it /is/ the problem. But at least, have a look, rather
than discarding it out of hand.
Because if it /is/ the problem, then no amount of pre-authentication or reconfiguration of
jCIFS or discussion here or elsewhere is going to help, and you will just be wasting your
time (and sleep badly).
More information about the jCIFS