[jcifs] Re: jcifs versions (packet-signing)
SAlappatt at unicacorp.com
SAlappatt at unicacorp.com
Wed Jan 7 18:10:14 GMT 2004
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
More information about the jcifs
mailing list