[jcifs] Re: jcifs versions (packet-signing)

[Gary Rambo]

Siby's description covers my problem as well. Using jcifs-0.7.12 I can 
connect to and browse a W2k3 server that requires signatures; using 
post-0.7.12 I cannot.

The tcpdump shows that both versions attempt the Session Setup AndX 
request with <domain>\GUEST and are rejected with "unknown srv error" 
(error code 8bf). 7.14 quits, throwing an SmbException: "Unverifiable 
signature". 7.12 persists, re-sending the Session Setup AndX request 
with user "anonymous", and succeeds. (Tcpdump capture files available on 
request.)

Gary


eglass1 at comcast.net wrote:

>>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
>
>  
>