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" <abart...@samba.org
<mailto:abart...@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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
