[jcifs] Re: jcifs versions

[Gary Rambo]

Michael,

I'm fairly sure I saw the same Unverifiable signature exception using 
8.0b chasing a dfs root a couple of weeks ago.

Thanks.

Gary

Michael B Allen wrote:

>Ah. Ok. 0.7.18 coming up....stay on target...stay on target...
>
>
>  
>
>>>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
>>
>>    
>>
>
>
>  
>