[jcifs] jcifs comments

[Tapperson Kevin]

Hello,

We have been using jcifs to support NTLM as one of the authentication
mechanisms for our corporate intranet for a while now.  We are running jcifs
on WebSphere 5 on AIX, and it has been working great (for the most part).
Thank you very much for the time and effort that you have put into making
jcifs available and so easy to integrate.

We do not use the packaged NtlmHttpFilter or NtlmServlet classes as is.  I
have written a customized version that integrates into the authentication
framework provided by our intranet portal vendor.  We have recently resolved
a couple of issues related to NTLM authentication, which I see could be
problems with the NtlmHttpFilter and NtlmServlet classes as they are
currently in the distribution package.  I thought that you would be
interested to know the details of these problems and how I resolved them.

Our security infrastructure is supported by about 50 Windows 2003 Active
Directory domain controllers.  There are 14 domain controllers in our
primary domain which lead our directory services administration team to the
conclusion that they can shutdown any of the domain controllers at any time
without consequence.

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.  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
performed a different domain controller is returned.  These changes have
eliminated the problems caused when a domain controller is shutdown.

The changes as described above, however, have magnified another problem
present in the jcifs code, causing it to occur almost every time, rather
than just occasionally.  Ever since our go-live date, we have had occasional
reports of users being unable to authenticate properly with NTLM.  If they
retried the authentication a second time, it would work; a minor annoyance.

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.  Since implementing this patch, we
have had no further unexplained reports of users not authenticating properly
on the first time with NTLM.  (Obviously, we still receive support calls
from users with locked out accounts and/or expired passwords, etc.)

Please let me know if I can be of any further assistance with either of
these problems.  If you would like, I can provide my customized source code
as a reference.

Kevin Tapperson
Senior Java Developer
Product Development: Enterprise Systems
HCA Information Technology & Services

One Park Plaza B3-2
Nashville, TN 37203
t:   615.344.6307
e:  kevin.tapperson at hcahealthcare.com
w:  www.hcahealthcare.com