[Samba] NT4 clients

[Gaiseric Vandal]

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.aspx 
> state:
> <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 
> <mailto: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/ <http://samba.org/%7Eabartlet/>
>     Authentication Developer, Samba Team http://samba.org
>     Samba Developer, Catalyst IT http://catalyst.net.nz
>
>