[Samba] NT4 clients

[Ryan Bair]

Understood. The machine I'm trying to connect is just a member, not a DC.
This is something which was well supported in earlier versions of Windows
with AD (NT4 didn't die overnight), and reportedly still works in 2012.
I'm not expecting any Kerberos to come out of NT4, nor do I see any.

The issue is that the Samba DC is fulfilling a TGS request when it really
should not. I spelled this out in a bit more detail a few messages back.

Thank you for pointing out the security issues. I'm well aware of the
issues with having an OS so old hanging around. The machine is involved in
ultimately driving a piece of equipment, but the set up requires several
other clients to have access via named pipe and SMB share. It's presently
isolated as best it can be given all the constraints. It's far from ideal
on several fronts, but the solution has been extremely reliable for a long
time and we realistically have at least 12 months until replacing the
solution is feasible.

On Tue, Jul 30, 2013 at 6:12 PM, Gaiseric Vandal
<gaiseric.vandal at gmail.com>wrote:

>  For what it is worth -  it looks like NT4 does NOT use kerberos even
> with the Active Directory client installed.
>
> http://www.petri.co.il/dsclient_for_win98_nt.htm#
>
>
> Windows 2003 Active Directory had some compatibility with NT4 domain
> controllers.     I don't think Samba 4 does.    Your best bet may be to try
> putting the NT4 machine in a separate NT4/Samba 3 domain and establishing
> trusts.   Or more realistically take it OUT of the domain and just create
> local user accounts with same passwords as the network accounts.
>
> The only legit reason I could see  to be running NT4 is if it is managing
> a specialized piece of equipment (e.g. on a manufacturing floor.)    In
> that case the machine(s) should be airgapped from any regular network with
> internet access.       If you follow security news you can imagine why it
> is important to keep unpatched systems physically isolated from the
> internet or other networks.
>
>
>
>
>
> On 07/30/13 05:33, Ryan Bair wrote:
>
>  Hi Andrew,
>
>  To clarify, it is the Win7 client sending the TGS request to the DC and
> the DC responds positively. I now have a more complete understanding of
> what's going on:
>
>  1. Win7 initiates a session with NT4. Nothing interesting.
>  2. Win7 sends the negotiate protocol response. Of note, we state that we
> support extended security.
>  3. NT4 responds that it does not support extended security. More
> precisely, when NT4 dinosaurs roamed the earth, that bit was likely still
> reserved.
>  4. Win7 issues a TGS request to the _DC_ to see if the host with that
> name really doesn't support extended security, or if the NT4 machine is
> trying to subject it to some sort of elaborate ruse. (i)
>  5. DC responds positively to the TGS req. (!!!)
>  6. Win7 closes the connection, and displays the error to the user.
>
>  i. The notes on http://msdn.microsoft.com/en-us/library/cc246806.aspxstate:
> <94> Section 3.2.5.2:
> <http://msdn.microsoft.com/en-us/library/d367854f-5eee-45e8-a588-eed596a1a521#endNote94>When
> the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag
> as not set, Windows-based SMB clients query the Key Distribution Center
> (KDC)<http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC>to verify whether a service ticket is registered for the given security
> principal name (SPN)<http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn>.
> If the query indicates that the SPN<http://msdn.microsoft.com/en-us/library/54af12e1-fcc1-4d62-bd47-c80514ac2615#spn>is registered with the
> KDC<http://msdn.microsoft.com/en-us/library/0aa17e1f-b3c1-478a-9bf0-2d826888d081#key_distribution_center_KDC>,
> then the SMB client terminates the connection and returns an
> implementation-specific security downgrade error to the caller.
>
>  Since the Samba DC replies that the SPN is available (by fulfilling the
> request), I'm assuming we're triggering this documented behavior in the
> Win7 client.
>
>  Also of note, `klist` on the client has an entry for cifs/nt4test which
> `setspn -Q cifs/nt4test` confirms does not exist. I can't confirm the
> behavior in #5 is a bug, but it certainly seems suspect.
>
> On Jul 30, 2013 1:07 AM, "Andrew Bartlett" <abartlet at samba.org> wrote:
>
>> On Mon, 2013-07-29 at 19:29 -0400, Ryan Bair wrote:
>> > Yes, AD has explicit support for pre-2000 clients.
>> >
>> > WINS is alive and well and name resolution is working.
>> >
>> > I really think the bogus TGS reply is messing things up,  but I'd like
>> to
>> > have someone more knowledgeable confirm the behavior is incorrect.
>>
>> NT4 doesn't know about Kerberos, I think any TGS traffic is highly
>> likely a red herring.  Are you really sure the client is issuing it, and
>> you have not additional software installed on the NT4 machine?
>>
>> Andrew Bartlett
>> --
>> Andrew Bartlett
>> http://samba.org/~abartlet/
>> Authentication Developer, Samba Team           http://samba.org
>> Samba Developer, Catalyst IT                   http://catalyst.net.nz
>>
>>
>>
>