[jcifs] jcifs comments

[Michael B Allen]

On Fri, 24 Sep 2004 12:54:00 -0500
Tapperson Kevin <Kevin.Tapperson at eHC.com> wrote:

> This brings me to the first problem: while Microsoft Windows clients
> appear to capable of dealing with domain controllers that are down, jcifs
> does not.
> 
> My implementation of the NTLM authenticator, like NtlmHttpFilter and
> NtlmServlet, uses a NetBIOS 0x1C name lookup for the authentication
> domain. The name lookup is done against our WINS servers.  If the domain
> controller at the top of the list returned by the WINS name lookup is
> down, jcifs will fail to complete the NTLM authentication, since it cannot
> connect to the domain controller to generate a challenge.  It throws an
> IOException since the socket cannot be opened.  In order to work around
> this, I have added a loop in the code around retrieving the address for a
> domain controller and generating a challenge.  If a challenge is generated
> successfully, the loop exits, however, if an IOException is thrown, the
> loop will retry to a different domain controller.

I think I should parameterize finding a good domain controller like:

SmbTransport dct = SmbSession.getDomainController("FOONET");
byte[] challenge = dct.server.encryptionKey;

Then I can put some really robust retry code in
SmbSession.getDomainController and get it out of the NTLM HTTP
authentication code.

> In order to retry to a different domain
> controller, I had to disable name caching by setting the
> jcifs.netbios.cachePolicy to 0.  This way, each time the 0x1C name lookup
> is
<snip, snip>
> When the name lookup cache is disabled (jcifs.netbios.cachePolicy=0), a
> different domain controller is used each time a challenge is generated.
> This causes a problem in jcifs since one domain controller is now used to
> generate the challenge sent to the client in the NTLM type 2 response, and
> a different domain controller (unless you're really, really lucky) is used
> to validate the NTLM type 3 message from the client.  This obviously
> doesn't work.  In order to resolve this problem, I added an
> HttpSession.setAttribute() call after the challenge is generated for the
> NTLM type 2 response.  I use this to save the domain controller which was
> used in this step to generate the challenge.  When the client then returns
> to this code with an NTLM type 3 message, I don't query the name service
> for a domain controller, but rather use the saved domain controller in the
> client's HttpSession to validate the response in the type 3 message.  This
> way the type 3 message is always validated against the same domain
> controller that generated the challenge.

Yeah, the stateful nature of mutli-step authentication really clashes
quite badly with the statelessness of HTTP. We really need to ensure
that the challenge sticks with the DC from which it came. This should
not depend on cachePolicy and is just a bug that needs fixing.

This is great feedback Kevin. This is exactly the type of practical
information I need to work out these bugs.

I'll look at these next week and do another stable release.

Thanks,
Mike

-- 
Greedo shoots first? Not in my Star Wars.