[jcifs] NTLM version help

[André Warnier]

Bret Comstock Waldow wrote:
> Hello,
> 
> I'm newly assigned to support a java app that runs on Windows only and
> uses jCIFS.  Authentication is against an Active Directory server via
> NTLM, and it appears to be single-sign-on with the user's Windows
> credentials.
> 
> A few months ago, before I joined to company, they had problems with
> authentications failing with no apparent changes.  Someone tried the
> pre-authentication work-around as below, and that appears to have
> completely stopped the problem:
> 
>         <init-param>
>             <param-name>jcifs.smb.client.username</param-name>
>             <param-value>DummyAccount</param-value>
>         </init-param>
>         <init-param>
>             <param-name>jcifs.smb.client.password</param-name>
>             <param-value>DummyPassword</param-value>
>         </init-param>
> 
> I am investigating whether there is some deeper issue we can know of and
> possibly fix, or whether this is just the way it is.  As it has worked
> for years before without this, it's easy to think something changed. 
> Note that we don't maintain the Active Directory server and getting
> information is difficult, but they swear they changed nothing.
> 
> I'm reading about the components, but not getting a good understanding
> of what is involved.
> 
> Question 1: Does the presence of the above work-around mean we are using
> the JCIFS NTLM HTTP Authentication Filter?  I read this can't work with
> NTLMv2.
> 
> Question 2: Fiddler shows me this authentication information:
> -[NTLM Type1: Negotiation]------------------------------
> Provider: NTLMSSP
> Type: 1
> OS Version: 5.1:2600
> Flags:    0xa208b207
>     Unicode supported in security buffer.
>     OEM strings supported in security buffer.
>     Request server's authentication realm included in Type2 reply.
>     NTLM authentication.
>     Client workstation domain provided.  Server can determine if the
> client eligible for local authentication.
>     Client workstation name provided.  Server can determine if the
> client eligible for local authentication.
>     Negotiate Always Sign.
>     Negotiate NTLM2 Key.
>     Supports 56-bit encryption.
>     Supports 128-bit encryption.
> Domain_Offset: 48; Domain_Length: 4; Domain_Length2: 4
> Host_Offset: 40; Host_Length: 8; Host_Length2: 8
> Host: AF368408
> Domain: APAC
> ------------------------------------
> 
> Does this mean the connection is using NTLMv2, or just that it would be
> willing to if the server provides it?
> 
Short answer : it cannot be using NTLMv2, because the jCIFS NTLM HTTP filter does not 
support it, cannot support it and never will.
Your message above indicates that you have probably read the warning on the web page, so I 
will not repeat it here.
The only reason why it works in your case is that /currently/, you network admins have not 
yet updated the environment to require NTLMv2, which is pretty much the standard nowadays.

If you want an alternative which supports NTLMv2 and is an easy plugin replacement for the 
filter, have a look at Jespa (www.ioplex.com).