<html><head></head><body>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.<br>
<br>
Rgds,<br>
Andy<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">jcifs-request@lists.samba.org wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">Send jCIFS mailing list submissions to<br /> jcifs@lists.samba.org<br /><br />To subscribe or unsubscribe via the World Wide Web, visit<br /> <a href="https://lists.samba.org/mailman/listinfo/jcifs">https://lists.samba.org/mailman/listinfo/jcifs</a><br />or, via email, send a message with subject or body 'help' to<br /> jcifs-request@lists.samba.org<br /><br />You can reach the person managing the list at<br /> jcifs-owner@lists.samba.org<br /><br />When replying, please edit your Subject line so it is more specific<br />than "Re: Contents of jCIFS digest..."<br /><br /><br />Today's Topics:<br /><br /> 1. Is the work-around also the answer? (Bret Comstock Waldow)<br /> 2. Re: Is the work-around also the answer? (Andr? Warnier)<br /> 3. Re: Is the work-around also the answer? (Bret Comstock Waldow)<br /> 4. Re: Is the work-around also the answer? (Andr? Warnier)<br /><br /><br /><hr /><br /><br
/>Message: 1<br />Date: Sun, 23 Oct 2011 14:17:40 +0800<br />From: Bret Comstock Waldow <bcw1000@yahoo.com><br />To: jcifs@lists.samba.org<br />Subject: [jcifs] Is the work-around also the answer?<br />Message-ID: <4EA3B184.90107@yahoo.com><br />Content-Type: text/plain; charset=UTF-8<br /><br />Hello,<br /><br />As I mentioned in another post, I am supporting software that uses<br />jCIFS. I am newly arrived on the job, and I'm assigned a problem in<br />software someone else wrote, although I can duplicate the problem.<br /><br />The "pre-authentication" work-around solves our problem, and I am tasked<br />with finding out if there is a deeper problem that needs to be fixed.<br /><br />Our Windows OS clients use Single-Sign-On (SSO) authentication against<br />an Active Directory server to gain access to our data servers (a<br />Weblogic-deployed app backed by Oracle).<br /><br />We don't manage the AD server, and our relationship with the company<br />that does is
delicate - we had to involve management to get answers from<br />them. I can ping the servers, and perhaps script against them, but I<br />can't really expect much response from them although with clear<br />questions to ask, I might be able to get answers.<br /><br />We are using the pre-authentication solution to deal with a problem that<br />cropped up this last June. The system mentioned above had authenticated<br />clients for years without problems, and then began rejecting sign-ons. <br />One of the fixes we tried was to switch from jCIFS 1.2.13 to 1.3.16, but<br />that made no difference.<br /><br />By adding or removing the stanzas below, I can prevent or cause the<br />sign-on problem:<br /><br /> <init-param><br /> <param-name>jcifs.smb.client.username</param-name><br /> <param-value>DummyAccount</param-value><br /> </init-param><br /> <init-param><br />
<param-name>jcifs.smb.client.password</param-name><br /> <param-value>DummyPassword</param-value><br /> </init-param><br /><br />When this is removed, the first logon may authenticate, and the second<br />is rejected. The first may open several clients - a different login is<br />rejected.<br /><br /><br />1) If I am to report this is the way it is, I must be able to justify<br />that somehow. Is it Microsoft's error in their implementation of NTLM? <br />If this is the best that can be expected, why is that so?<br /><br />I can say "this is how it is" as long as I have something more than<br />"because that's all I can find" to go on.<br /><br /><br />2) Why did this work until June of this year, and then fail? Can anyone<br />provide an idea of what might have caused that behaviour, and (big help)<br />suggest a way to check to confirm what may have changed? Having a<br />theory would be very helpful.<br /><br /><br />I will be
happy to carry out queries and report results (subject to<br />revealing company info) in order to give more to go on. Any discussion<br />of what the mechanisms involved (in the problem) are would also be<br />helpful - there's a lot to educate myself on, and no guarantee I'll<br />start in the right place. Note that I don't have a mandate to learn all<br />about AD & NTLM - just put the problem to rest & be sure it won't happen<br />again - so there's some time pressure for me.<br /><br />I am a Java coder, but not knowledgeable about AD & NTLM & jCIFS, so<br />please use a few more words than less, so I have some terms to search for.<br /><br />Thanks for any help and suggestions.<br /><br />Cheers,<br />Bret<br /><br /><br /><br /><hr /><br /><br />Message: 2<br />Date: Sun, 23 Oct 2011 12:09:15 +0200<br />From: Andr? Warnier <aw@ice-sa.com><br />To: JCIFS Samba list <jcifs@lists.samba.org><br />Subject: Re: [jcifs] Is the work-around also the
answer?<br />Message-ID: <4EA3E7CB.9040208@ice-sa.com><br />Content-Type: text/plain; charset=UTF-8; format=flowed<br /><br />Bret Comstock Waldow wrote:<br />> Hello,<br />> <br />> As I mentioned in another post, I am supporting software that uses<br />> jCIFS. I am newly arrived on the job, and I'm assigned a problem in<br />> software someone else wrote, although I can duplicate the problem.<br />> <br />> The "pre-authentication" work-around solves our problem, and I am tasked<br />> with finding out if there is a deeper problem that needs to be fixed.<br />> <br />> Our Windows OS clients use Single-Sign-On (SSO) authentication against<br />> an Active Directory server to gain access to our data servers (a<br />> Weblogic-deployed app backed by Oracle).<br />> <br />> We don't manage the AD server, and our relationship with the company<br />> that does is delicate - we had to involve management to get answers from<br />>
them. I can ping the servers, and perhaps script against them, but I<br />> can't really expect much response from them although with clear<br />> questions to ask, I might be able to get answers.<br />> <br />> We are using the pre-authentication solution to deal with a problem that<br />> cropped up this last June. The system mentioned above had authenticated<br />> clients for years without problems, and then began rejecting sign-ons. <br />> One of the fixes we tried was to switch from jCIFS 1.2.13 to 1.3.16, but<br />> that made no difference.<br />> <br />> By adding or removing the stanzas below, I can prevent or cause the<br />> sign-on problem:<br />> <br />> <init-param><br />> <param-name>jcifs.smb.client.username</param-name><br />> <param-value>DummyAccount</param-value><br />> </init-param><br />> <init-param><br />>
<param-name>jcifs.smb.client.password</param-name><br />> <param-value>DummyPassword</param-value><br />> </init-param><br />> <br />> When this is removed, the first logon may authenticate, and the second<br />> is rejected. The first may open several clients - a different login is<br />> rejected.<br />> <br />> <br />> 1) If I am to report this is the way it is, I must be able to justify<br />> that somehow. Is it Microsoft's error in their implementation of NTLM? <br />> If this is the best that can be expected, why is that so?<br />> <br />> I can say "this is how it is" as long as I have something more than<br />> "because that's all I can find" to go on.<br />> <br />> <br />> 2) Why did this work until June of this year, and then fail? Can anyone<br />> provide an idea of what might have caused that behaviour, and (big help)<br />> suggest a way to check to
confirm what may have changed? Having a<br />> theory would be very helpful.<br />> <br />> <br />> I will be happy to carry out queries and report results (subject to<br />> revealing company info) in order to give more to go on. Any discussion<br />> of what the mechanisms involved (in the problem) are would also be<br />> helpful - there's a lot to educate myself on, and no guarantee I'll<br />> start in the right place. Note that I don't have a mandate to learn all<br />> about AD & NTLM - just put the problem to rest & be sure it won't happen<br />> again - so there's some time pressure for me.<br />> <br />> I am a Java coder, but not knowledgeable about AD & NTLM & jCIFS, so<br />> please use a few more words than less, so I have some terms to search for.<br />> <br />> Thanks for any help and suggestions.<br />> <br />Hi.<br />If I understand the above correctly, you are talking about the jCIFS HTTP NTLM <br
/>authentication filter.<br />If so, you should go the corresponding page on the website, and read the notice that is <br />highlighted. And really, really, believe it.<br /><br />The fundamental part of it is that this filter can stop working at any time, for example <br />simply because the network admins have decided to switch to NTLMv2 authentication (which <br />is nowadays the default), instead of continuing to support NTLMv1.<br />They may not even have "decided" this, but simply updated a Domain Controller, making <br />NTLMv2 the default in the process.<br /><br />You should replace the current filter by another product which supports NTLMv2.<br />For example, Jespa, at <a href="http://www.ioplex.com">www.ioplex.com</a>.<br /><br />Anything else would be a waste of your time. Really.<br /><br /><br /><br /><br /><hr /><br /><br />Message: 3<br />Date: Sun, 23 Oct 2011 19:15:28 +0800<br />From: Bret Comstock Waldow <bcw1000@yahoo.com><br />To: JCIFS Samba list
<jcifs@lists.samba.org><br />Subject: Re: [jcifs] Is the work-around also the answer?<br />Message-ID: <4EA3F750.7050409@yahoo.com><br />Content-Type: text/plain; charset=UTF-8<br /><br />On 23/10/11 18:09, Andr? Warnier wrote:<br />> If I understand the above correctly, you are talking about the jCIFS<br />> HTTP NTLM authentication filter.<br />I think so, although my own exposure is new enough that I might be<br />missing something.<br /><br /><br />> If so, you should go the corresponding page on the website, and read<br />> the notice that is highlighted. And really, really, believe it.<br />><br />> The fundamental part of it is that this filter can stop working at any<br />> time, for example simply because the network admins have decided to<br />> switch to NTLMv2 authentication (which is nowadays the default),<br />> instead of continuing to support NTLMv1.<br />> They may not even have "decided" this, but simply updated a
Domain<br />> Controller, making NTLMv2 the default in the process.<br />No. That can't be done.<br /><br />This is Large, Huge, International Resource Company, and that's not<br />going to happen. Period.<br /><br />There is a project in it's early stages to replace this software with<br />something else, but I'm not doing that, and it won't happen soon. Maybe<br />next year, but I have my doubts.<br /><br />I'm in Support, and I'm maintaining what's there, which will/must work<br />24/7/365 or huge amounts of money are lost. It WILL continue for months<br />or years from now, and no one is going to flip switches like that and<br />keep their job - full stop ("period" for you Yanks).<br /><br />There is no uncertainty or choice about this.<br /><br /> I need the answers I ask for - that's the only help that can matter<br />this time.<br /><br />I would really, really like to hear any ideas anyone has, because this<br />is the problem I must solve, either by justifying the
"work-around" as<br />the solution, or by finding how the situation might have changed on our<br />side, or "their" side (the people that manage the AD servers), so I can<br />try to track it down.<br /><br />I am hoping that the people who have been managing jCIFS all this time<br />(and fixing the problems that arose that led to suggesting the<br />"pre-authentication" solution) can give me the benefit of their<br />knowledge, which I can't acquire in any short time with the<br />documentation that is available.<br /><br />I don't need to make the system work "like it should", or "the best way"<br />- that is well outside my power.<br /><br />I need to know what has happened now with it as it is, and what to do<br />about it. And if the "pre-authentication" is the proper fix, I need to<br />be able to show that this is so, and not just that we're accepting a<br />hack because we didn't look far enough (it matters).<br /><br />Please give me the benefit of your hard-won experience
- it's useful<br />again here, I would be grateful, and it will help me learn even if it's<br />not the future way. Knowing the past is useful, sometimes. I am on a<br />rotating roster for 24/7 support - if it breaks, I get woken up to fix it.<br /><br />Thank you,<br />Bret<br /><br /><br /><br /><hr /><br /><br />Message: 4<br />Date: Sun, 23 Oct 2011 15:01:31 +0200<br />From: Andr? Warnier <aw@ice-sa.com><br />To: JCIFS Samba list <jcifs@lists.samba.org><br />Subject: Re: [jcifs] Is the work-around also the answer?<br />Message-ID: <4EA4102B.4040101@ice-sa.com><br />Content-Type: text/plain; charset=UTF-8; format=flowed<br /><br />Bret Comstock Waldow wrote:<br />> On 23/10/11 18:09, Andr? Warnier wrote:<br />>> If I understand the above correctly, you are talking about the jCIFS<br />>> HTTP NTLM authentication filter.<br />> I think so, although my own exposure is new enough that I might be<br />> missing something.<br />> <br />>
<br />>> If so, you should go the corresponding page on the website, and read<br />>> the notice that is highlighted. And really, really, believe it.<br />>><br />>> The fundamental part of it is that this filter can stop working at any<br />>> time, for example simply because the network admins have decided to<br />>> switch to NTLMv2 authentication (which is nowadays the default),<br />>> instead of continuing to support NTLMv1.<br />>> They may not even have "decided" this, but simply updated a Domain<br />>> Controller, making NTLMv2 the default in the process.<br />> No. That can't be done.<br />> <br />> This is Large, Huge, International Resource Company, and that's not<br />> going to happen. Period.<br />> <br />> There is a project in it's early stages to replace this software with<br />> something else, but I'm not doing that, and it won't happen soon. Maybe<br />> next year, but I have my
doubts.<br />> <br />> I'm in Support, and I'm maintaining what's there, which will/must work<br />> 24/7/365 or huge amounts of money are lost. It WILL continue for months<br />> or years from now, and no one is going to flip switches like that and<br />> keep their job - full stop ("period" for you Yanks).<br />> <br />> There is no uncertainty or choice about this.<br />> <br />> I need the answers I ask for - that's the only help that can matter<br />> this time.<br />> <br />> I would really, really like to hear any ideas anyone has, because this<br />> is the problem I must solve, either by justifying the "work-around" as<br />> the solution, or by finding how the situation might have changed on our<br />> side, or "their" side (the people that manage the AD servers), so I can<br />> try to track it down.<br />> <br />> I am hoping that the people who have been managing jCIFS all this time<br />> (and fixing the
problems that arose that led to suggesting the<br />> "pre-authentication" solution) can give me the benefit of their<br />> knowledge, which I can't acquire in any short time with the<br />> documentation that is available.<br />> <br />> I don't need to make the system work "like it should", or "the best way"<br />> - that is well outside my power.<br />> <br />> I need to know what has happened now with it as it is, and what to do<br />> about it. And if the "pre-authentication" is the proper fix, I need to<br />> be able to show that this is so, and not just that we're accepting a<br />> hack because we didn't look far enough (it matters).<br />> <br />> Please give me the benefit of your hard-won experience - <br /><br />That is exactly what I did.<br /><br />it's useful<br />> again here, I would be grateful, and it will help me learn even if it's<br />> not the future way. Knowing the past is useful, sometimes. I am on a<br
/>> rotating roster for 24/7 support - if it breaks, I get woken up to fix it.<br />> <br />Well yes, maybe. In a way, I am always fascinated by people who have such certainties in <br />their opinions. But in this case, denying reality is not going to help you sleep better.<br /><br />You described a problem whereby something which has been working for a long time, suddenly <br />doesn't work anymore in a number of cases.<br />Based on my experience, I told you what my best guess what, as to what causes such symptoms.<br />I am not telling you that this /is/ the problem. I am telling you that there is a very <br />strong probability that this is the problem, and that you should investigate further to <br />find out if this is really the issue, before you go chasing other rabbits.<br /><br />The warning on the jCIFS website has been there for, mm.. 5 years ?<br />Since then, new Windows versions and updates have come, which have gradually replaced the <br />(relatively
unsafe) NTLMv1 default by the (safer) NTLMv2 default, which is not supported <br />by the jCIFS filter, and never will be.<br />The random problems you are seeing may be caused for example by a circumstance like this :<br />- a group of workstations usually authenticate with a certain Domain Controller A, which <br />is set for NTLMv2, but (because it is an older machine) still accepts the older and <br />deprecated NTLMv1 as an alternative<br />- for some reason, this DC is turned off for a while (say for maintenance)<br />- the same group of workstations now authenticates with a backup DC, which happens to be <br />set for NTLMv2 *only*<br />It won't make a jot of difference for Windows logins, because since at least 5 years any <br />Windows workstation can authenticate using *either* NTLMv2 or NTLMv1, so they will <br />automatically adapt.<br />But jCIFS cannot automatically adapt, because it cannot support NTLMv2.<br />So it fails to authenticate. And when the primary DC is
turned on again, it will work <br />again for a while.<br /><br />You get it now ?<br /><br />Again, I am not telling you that it /is/ the problem. But at least, have a look, rather <br />than discarding it out of hand.<br />Because if it /is/ the problem, then no amount of pre-authentication or reconfiguration of <br />jCIFS or discussion here or elsewhere is going to help, and you will just be wasting your <br />time (and sleep badly).<br /><br /><br /><br /><br /><hr /><br /><br /><hr /><br />jCIFS mailing list<br />jCIFS@lists.samba.org<br /><a href="https://lists.samba.org/mailman/listinfo/jcifs">https://lists.samba.org/mailman/listinfo/jcifs</a><br /><br /><br />End of jCIFS Digest, Vol 106, Issue 16<br />**************************************<br /></pre></blockquote></div></body></html>