[jcifs] NTLM usrname/password failure after each 5 mins

[Kevin Tapperson]

I ran into this same problem a few years ago.  I implemented a refcount as
described and it helped prevent this type of issue.  I think I've still got
the modified code laying around somewhere.  If it helps, I could dig it up
and provide a diff of the changes.

http://article.gmane.org/gmane.network.samba.java/4372/match=nt%5fstatus%5faccess%5fviolation


On Tue, Jun 24, 2008 at 1:17 PM, Michael B Allen <ioplex at gmail.com> wrote:

> On 6/24/08, Asaf Mesika <asaf.mesika at gmail.com> wrote:
> > After investigating some more on the issue, I've found out that the load
> > test problem is not in the synchronize issue I've raised, but its in the
> > hiccup you've described.
> >
> >  The Hiccup as I've seen it
> >  The transport is not being used for 5 minutes, since the load test is
> using
> > the same users, thus jCIFS is using the cache. Once the transport
> performs
> > the disconnect and then the connect, the transport.server.encryptionKey
> > changes. Since the encryptionKey is the challenge jCIFS returns to the
> > browser on the type2 message, it is the heart of the problem.
> >  The problem occurs when we send the challenge, before the disconnect ,in
> > the type2 message.
>
> Aha. Interesting. Nice work!
>
> Unfortunately this is a little difficult to fix because there is no
> way to know if or when the HTTP client will submit hashes that use
> that challenge. The HTTP client could get the challenge, sleep for an
> hour, and then submit the type-3-message. Or it could get the
> challenge and never submit hashes at all. There's no way to handle
> both of those cases gracefully. It's just a limitation in trying to do
> stateful authentication over a stateless protocol.
>
> However, in practice there are idle periods where no clients are
> authenticating and it is safe to disconnect the client and thereby
> free associated resources. We just need to >>stop the transport from
> disconnecting as long as there are outstanding challenges<<.
>
> To implement this, add a "refcount" to jcifs.util.transport.Transport.
> In loop(), detect the soTimeout case (I don't recall what type of
> Exception this triggers) and do NOT call disconnect() if refcount > 0.
>
> Then, in SmbSession.interrogate(), change trans.server.encryptionKey
> to trans.getEncryptionKey() and in SmbTransport.getEncryptionKey(),
> increment trans.refcount++. Also, in SmbSession.logon(), decrement
> trans.refcount-- if it is > 0 after the challenge is used.
>
> However, this will result in a net positive refcount value because
> clients may not send the type-3-message and, again, in general there
> are many things that can go wrong that prevent logon from ever being
> called. So, you also need to decrement trans.refcount in another more
> aggressive way. For example, you could decrement the refcount every
> time you get the exception triggered by soTimeout but do not
> disconnect. Meaning refcount will be decremented every time soTimeout
> fires. That could be enough to offset any misbehaving clients. You
> might also cap the refcount value at some high value that would almost
> never be reached with HTTP clients that are behaving properly.
>
> I'm just brainstorming at this point but basically you need to stop
> the transport from disconnecting if there are outstanding challenges.
> How you detect when there are outstanding challenges and when they
> should no longer be counted is up to you.
>
> Mike
>
>
> --
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/
>



-- 
Kevin Tapperson
kevin at tapperson.net
(615) 403-0817
-------------- next part --------------
HTML attachment scrubbed and removed