[jcifs] jCIFS NtlmHttpFilter

[Brett Beaumont]

Is there an ETA for jcifs-0.9.0 being released? I've discovered that our
client doesn't currently have Win2003 domain controllers as I'd thought.
However, there is a project that is aiming to cut across to 2003 in October.
Obviously whether jCIFS continues to work when they do that will depend on
whether they configure the SMB Session Signing. If there is a high level of
confidence that v0.9 will be released in the next couple of months, I should
be able to upgrade/test/configure the filter prior to the Win2003 upgrade.

Our current solution for NTLM is the mod_ntlm Apache module (running on
RedHat). I believe that this sets up a new connection for each
authentication request, so using jCIFS with suppressed multiplexing
wouldn't, in theory, be any worse than what we currently have. Under our
current load, mod_ntlm seems to encounter a lot of broken pipe errors, which
I'm hoping jCIFS doesn't encounter. Also, with jCIFS only authenticating the
session, rather than every connection, I'd hope to see a lower load being
placed on the DCs.

Many thanks for your quick responses.

Regards,

Brett Beaumont


-----Original Message-----
From: Michael B Allen [mailto:mba2000 at ioplex.com]
Sent: Friday, 7 May 2004 6:30 a.m.
To: Eric
Cc: Brett Beaumont; 'jcifs at lists.samba.org'
Subject: Re: [jcifs] jCIFS NtlmHttpFilter


Brett said:
>
>> We have a maximum of about 4000 users that use the intranet (though it
>> would

>From comments that I've heard 4000 should be no problem. One person claims
"100,000 clients" or something to that effect but they didn't indicate the
time window. Generally the NtlmHttpFilter is reported to work very well.

>> Also, I've seen a few messages about SMB Signing with Win2003 causing
>> problems. Does this affect the NtlmHttpFilter?
>>

The NtlmHttpFilter does not work with Windows 2003 if signing is required.
This is because the mac signing key can only be computed with the raw
plain text password (or it's precursor hash?). At first we thought we
would still be ok because a user authentication
(SMB_COM_SESSION_SETUP_ANDX) doesn't actually use signing. But we were
wrong. It doesn't use it the first time, but after the first
authentication, the server thinks signing is enabled so subsequent
authentications fail due to the fact that we don't have a valid mac key to
sign with.

The solutions are as follows:

1) Implement the NETLOGON RPC so we can "join the domain" and authenticate
users like any other windows box. This will work because the machine
account password used to "join the domain" will also be used to generate
the mac signing key. This solution is superior as it more purely emulates
the current behavior of MS networks. Incedentally it is also necessary to
implement NTLMv2.

2) Use local credentals to pre-authenticate the NtlmHttpFilter against the
domain controller so that the password is available to generate the mac
signing key. Subsequent authentications should then work as they will be
signed properly. This functionality is currently being added to
jcifs-0.9.0. The standard jcifs.smb.client.{domain,username,password} will
be used like a "machine account" to connect to IPC$ before any subsequent
authentications are performed on that transport.

3) Supress multiplexing of transports such that each authentication is
given it's own transport. This is not favorable as it eliminates the
primary source of the NtlmHttpFilters scalability. Regardless, this
functionality has already been added to jcifs-0.9.0 as it is useful for a
variety of other reasons. The behavior is contolled using the
jcifs.smb.client.ssnLimit property which used to close 10% of the
connections when the ssnLimit was reached but it now opens to transports
when the ssnLimit is reached. Thus by setting ssnLimit to 1 each
SMB_COM_SESSION_SETUP_ANDX will be conducted on it's own transport. This
has been tested and verified.

Mike