[jcifs] Is the work-around also the answer?

André Warnier aw at ice-sa.com
Sun Oct 23 04:09:15 MDT 2011


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.




More information about the jCIFS mailing list