Ntlm v1 - more reasons for failure

All valid points. One other thing. Its also possible that the underlying application (that I couldnt see identified) may have evolved internally. I had a similar experience once upon a time, but the scenario of jcifs usage was specific. I would second the opinion that the commercial ntlm v2 authenticator be looked at.

Rgds,
Andy
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[email protected] wrote:

Send jCIFS mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.samba.org/mailman/listinfo/jcifs
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of jCIFS digest..."


Today's Topics:

1. Is the work-around also the answer? (Bret Comstock Waldow)
2. Re: Is the work-around also the answer? (Andr? Warnier)
3. Re: Is the work-around also the answer? (Bret Comstock Waldow)
4. Re: Is the work-around also the answer? (Andr? Warnier)


_____________________________________________


Message: 1
Date: Sun, 23 Oct 2011 14:17:40 +0800
From: Bret Comstock Waldow <[email protected]>
To: [email protected]
Subject: [jcifs] Is the work-around also the answer?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

Hello,

As I mentioned in another post, I am supporting software that uses
jCIFS. I am newly arrived on the job, and I'm assigned a problem in
software someone else wrote, although I can duplicate the problem.

The "pre-authentication" work-around solves our problem, and I am tasked
with finding out if there is a deeper problem that needs to be fixed.

Our Windows OS clients use Single-Sign-On (SSO) authentication against
an Active Directory server to gain access to our data servers (a
Weblogic-deployed app backed by Oracle).

We don't manage the AD server, and our relationship with the company
that does is delicate - we had to involve management to get answers from
them. I can ping the servers, and perhaps script against them, but I
can't really expect much response from them although with clear
questions to ask, I might be able to get answers.

We are using the pre-authentication solution to deal with a problem that
cropped up this last June. The system mentioned above had authenticated
clients for years without problems, and then began rejecting sign-ons. 
One of the fixes we tried was to switch from jCIFS 1.2.13 to 1.3.16, but
that made no difference.

By adding or removing the stanzas below, I can prevent or cause the
sign-on problem:

<init-param>
<param-name>jcifs.smb.client.username</param-name>
<param-value>DummyAccount</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.password</param-name>
<param-value>DummyPassword</param-value>
</init-param>

When this is removed, the first logon may authenticate, and the second
is rejected. The first may open several clients - a different login is
rejected.


1) If I am to report this is the way it is, I must be able to justify
that somehow. Is it Microsoft's error in their implementation of NTLM? 
If this is the best that can be expected, why is that so?

I can say "this is how it is" as long as I have something more than
"because that's all I can find" to go on.


2) Why did this work until June of this year, and then fail? Can anyone
provide an idea of what might have caused that behaviour, and (big help)
suggest a way to check to confirm what may have changed? Having a
theory would be very helpful.


I will be happy to carry out queries and report results (subject to
revealing company info) in order to give more to go on. Any discussion
of what the mechanisms involved (in the problem) are would also be
helpful - there's a lot to educate myself on, and no guarantee I'll
start in the right place. Note that I don't have a mandate to learn all
about AD & NTLM - just put the problem to rest & be sure it won't happen
again - so there's some time pressure for me.

I am a Java coder, but not knowledgeable about AD & NTLM & jCIFS, so
please use a few more words than less, so I have some terms to search for.

Thanks for any help and suggestions.

Cheers,
Bret



_____________________________________________


Message: 2
Date: Sun, 23 Oct 2011 12:09:15 +0200
From: Andr? Warnier <[email protected]>
To: JCIFS Samba list <[email protected]>
Subject: Re: [jcifs] Is the work-around also the answer?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed

Bret Comstock Waldow wrote:
> Hello,
> 
> As I mentioned in another post, I am supporting software that uses
> jCIFS. I am newly arrived on the job, and I'm assigned a problem in
> software someone else wrote, although I can duplicate the problem.
> 
> The "pre-authentication" work-around solves our problem, and I am tasked
> with finding out if there is a deeper problem that needs to be fixed.
> 
> Our Windows OS clients use Single-Sign-On (SSO) authentication against
> an Active Directory server to gain access to our data servers (a
> Weblogic-deployed app backed by Oracle).
> 
> We don't manage the AD server, and our relationship with the company
> that does is delicate - we had to involve management to get answers from
> them. I can ping the servers, and perhaps script against them, but I
> can't really expect much response from them although with clear
> questions to ask, I might be able to get answers.
> 
> We are using the pre-authentication solution to deal with a problem that
> cropped up this last June. The system mentioned above had authenticated
> clients for years without problems, and then began rejecting sign-ons. 
> One of the fixes we tried was to switch from jCIFS 1.2.13 to 1.3.16, but
> that made no difference.
> 
> By adding or removing the stanzas below, I can prevent or cause the
> sign-on problem:
> 
> <init-param>
> <param-name>jcifs.smb.client.username</param-name>
> <param-value>DummyAccount</param-value>
> </init-param>
> <init-param>
> <param-name>jcifs.smb.client.password</param-name>
> <param-value>DummyPassword</param-value>
> </init-param>
> 
> When this is removed, the first logon may authenticate, and the second
> is rejected. The first may open several clients - a different login is
> rejected.
> 
> 
> 1) If I am to report this is the way it is, I must be able to justify
> that somehow. Is it Microsoft's error in their implementation of NTLM? 
> If this is the best that can be expected, why is that so?
> 
> I can say "this is how it is" as long as I have something more than
> "because that's all I can find" to go on.
> 
> 
> 2) Why did this work until June of this year, and then fail? Can anyone
> provide an idea of what might have caused that behaviour, and (big help)
> suggest a way to check to confirm what may have changed? Having a
> theory would be very helpful.
> 
> 
> I will be happy to carry out queries and report results (subject to
> revealing company info) in order to give more to go on. Any discussion
> of what the mechanisms involved (in the problem) are would also be
> helpful - there's a lot to educate myself on, and no guarantee I'll
> start in the right place. Note that I don't have a mandate to learn all
> about AD & NTLM - just put the problem to rest & be sure it won't happen
> again - so there's some time pressure for me.
> 
> I am a Java coder, but not knowledgeable about AD & NTLM & jCIFS, so
> please use a few more words than less, so I have some terms to search for.
> 
> Thanks for any help and suggestions.
> 
Hi.
If I understand the above correctly, you are talking about the jCIFS HTTP NTLM 
authentication filter.
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.

You should replace the current filter by another product which supports NTLMv2.
For example, Jespa, at www.ioplex.com.

Anything else would be a waste of your time. Really.




_____________________________________________


Message: 3
Date: Sun, 23 Oct 2011 19:15:28 +0800
From: Bret Comstock Waldow <[email protected]>
To: JCIFS Samba list <[email protected]>
Subject: Re: [jcifs] Is the work-around also the answer?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8

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 - it's useful
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.

Thank you,
Bret



_____________________________________________


Message: 4
Date: Sun, 23 Oct 2011 15:01:31 +0200
From: Andr? Warnier <[email protected]>
To: JCIFS Samba list <[email protected]>
Subject: Re: [jcifs] Is the work-around also the answer?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed

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.

it's useful
> 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 
automatically adapt.
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).




_____________________________________________


_____________________________________________

jCIFS mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/jcifs


End of jCIFS Digest, Vol 106, Issue 16
**************************************