[jcifs] Re: jcifs versions

[eglass1 at comcast.net]

> Prior to jCIFS 0.7.13 there is no support for signing. So how are you using
> 0.7.3 if your Windows 2003 server is configured to require signing? Is it
> possible that it does not require signing? Is it possible that you are really
> authenticating against a different server? JCIFS will only use signing if the
> server requires it or if jcifs.smb.client.signingPreferred is explicitly set
> to true. Also, signing and NTLM HTTP Authentication do NOT work together
> because the original password or precursor password hash is required to
> generate the MAC signing key. So I am very interested in how you managed to
> get a version of jCIFS that doesn't support SMB signing at all to work with
> your Windows 2003 server that requires it! Perhaps you could take a packet
> capture of your current working setup with jcifs-0.7.3 and verify that the
> server is really requiring signing.

This is an edge case (though I suspect a prevalent one); currently, jCIFS
throws an exception in SmbTransport.initSigning if the
NtlmPasswordAuthentication object has "external" hashes (i.e., in the case of
HTTP auth).  In reality, however, signing doesn't start until the session
setup response from the server.  So previous jCIFS versions would authenticate
successfully; you just wouldn't be able to perform any SMB operations *after*
authentication.  The current implementation fails artificially before
authentication completes, so the noted behavior occurs.

One remediation would be to remove the exception throw in initSigning (just
set useSigning to false); HTTP auth would work normally except in the case of
something like Davenport (where it is expecting to use the
NtlmPasswordAuthentication object to access resources after authentication).


Eric