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

[SAlappatt at unicacorp.com]

I just found out that we do have packet signing turned on to required in 
the win2003 domain controller. jcifs authentication seems to work with 
0.7.3.  I am using only the HttpFilter functionality of jcifs and do not 
use jcifs after authentication. I will try to send you guys a packet 
capture ASAP. I have to figure out how to do it first..:-(

Where do I get jcifs jar of 0.7.12 ?  Does that version have the benign 
"socket closed" stack trace issue?...

-Siby





cheers,
-Siby



Gary Rambo <c-grambo at aventail.com> 
Sent by: jcifs-bounces+salappatt=unicacorp.com at lists.samba.org
01/07/2004 12:57 PM

To
jcifs at lists.samba.org
cc

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






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

-------------- next part --------------
HTML attachment scrubbed and removed