[jcifs] Occasionally NTLM Filter fails...Please Help.

[Andrew Murphy]

I apologize if this is not the right place to post this request for help, 
please let me know if so.

We have had much success with the JCIFS NTLM Filter to provide our clients 
with a SSO solution for their web applications.

We have one client however who are able to authenticate with multiple users 
most of the time, but they occasionally cannot connect and are continuously 
prompted with the Internet Explorer login dialog.
We have created a wrapper class that extends the jcifs.http.NtlmHttpFilter 
class and we initialize the filter by doing a database lookup.
The properties that we send are:
jcifs.smb.client.domain
jcifs.http.domainController
jcifs.smb.client.username
jcifs.smb.client.password
jcifs.util.loglevel

The client is using WIN2003 Active Directory as the domain controller.

When we enable the detailed logging, we see samples like this in the tomcat 
console:

NtlmHttpFilter: CLIENTDOMAINNAME\bkahugu successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bkahugu successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\Dbankhea successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\dlyons successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison successfully authenticated against 
CO_SERVER21.CLIENTDOMAINNAME.COM/10.17.1.21
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison: 0xC000006D: 
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password.
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison: 0xC000006D: 
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password.

So there are many instances of successful authentication then we have a 
failure out of the blue.  The failed account goes on to continue to try to 
authenticate and winds up having their account locked.

NtlmHttpFilter: CLIENTDOMAINNAME\bmadison: 0xC0000234: 
jcifs.smb.SmbAuthException: The referenced account is currently locked out and 
may not be logged on to.
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison: 0xC0000234: 
jcifs.smb.SmbAuthException: The referenced account is currently locked out and 
may not be logged on to.
NtlmHttpFilter: CLIENTDOMAINNAME\bmadison: 0xC0000234: 
jcifs.smb.SmbAuthException: The referenced account is currently locked out and 
may not be logged on to.

We have been attempting to debug this issue, so we took a network capture.  
Only one strange thing seems different from the successful attempts to 
authenticate versus the failed attempts.  In comparing these two network 
packets, the difference seems to be in the inclusion of a Unicode Password. In 
the successful attempts there are two passwords included in the SMB block.  
There is an ANSI password and a Unicode Password.  In the failed attempts 
there is only the ANSI password.

Does anyone know why the browser (or the filter) might occasionally drop the 
Unicode version of the password?  Is this difference even significant?  Is 
there a change in the environment that we can make to overcome this issue?

I appreciate whatever help you might be able to offer.

Thank you.

Andrew Murphy