[jcifs] NTLM Authentication issue

[Matt Parker]

On Tue, Aug 26, 2008 at 9:25 AM, Michael B Allen <ioplex at gmail.com> wrote:
> No one should ever reduce the jcifs.smb.client.soTimeout value when
> using the NTLM HTTP Filter.
>
> I don't know where people got the idea of reducing soTimeout but just
> in case someone reads this thread and thinks it's something they
> should try I think it's important that I speak up and say clearly that
> it's not something anyone should ever do. The soTimeout says "close
> the transport after soTimeout milliseconds". So even though you think
> you're making your SMB signing problem better (because it
> reinitializes the transport for each authentication) you're not fixing
> anything and in fact you're making things worse because you're greatly
> increasing the chance that the transport will close in the middle of
> an authentication (aka the "hiccup" bug).
>
> Mike

My experience has been (and from what I can tell from this list, I
suspect others are also running into this) that even with
pre-authentication set up and working correctly, and leaving soTimeout
with its default value, I indeterminately get ACCESS_DENIED errors. I
say indeterminately because I have seen it work consistently, then the
next time I restart the application it fails consistently, then the
next time it works, etc.

Here's what I am seeing:

1. When it "works", multiple users can authenticate over the same
transport, and life is good. The only real failures are what you
describe as the "hiccup bug", where a transport shuts down after
sending the type 2. And the "hiccup bug" is so infrequent that I don't
actually know if I've seen it.

2. When it "doesn't work", the transport successfully authenticates
_only the first user_, and all subsequent users get ACCESS_DENIED.

The way I reproduce this behavior is to simply restart the
application, and run a script which loops through three (or more)
sequential requests from different users. Without changing anything,
sometimes I see the behavior described above in 1, and sometimes I see
the behavior described in 2.

The only way I could avoid this was to use the patch I sent to the
list a couple weeks back, where my custom filter directly creates and
uses transports, rather than relying on SmbSession.

Matt