[Samba] NT4 clients

[Ryan Bair]

Last bit of info.

This article, http://support.microsoft.com/kb/258503, indicates that
Windows should indeed be setting up its own default SPNs (host and machine
name).

http://support.microsoft.com/kb/320187 states that the pre-Windows 2000
checkbox is ADUC assigns the machine password based on the machine name. I
haven't found any information indicating that it does anything more than
this.

I'll try to confirm the behavior against a Win2008 DC this week, but right
now I'm leaning towards the CIFS SPN being dependent upon a HOST SPN being
present.


On Tue, Jul 30, 2013 at 8:58 PM, Ryan Bair <ryandbair at gmail.com> wrote:

> I've noticed that Win2k+ clients have filled in their servicePrincipalName
> attribute in AD. I know that the cifs SPN is implicit, but are you certain
> the host SPN is also implicit? If cifs was only meant to be implicit off of
> the host (and the host not implicit itself), that could be a way to
> determine if the request should be fulfilled.
>
> I have not tried against a Windows DC. I may set up a test DC to see what
> the behavior is.
>
> Connecting by IP address does work. I'll try using an alternative name,
> that sounds promising as well.
>
> In ADUC, there is a checkbox for pre-Windows 2000 when creating a new
> machine account. I wonder what this does and if we could use it somehow. I
> know it's not stored anywhere directly, but I'd suspect its there for a
> reason.
>
>
> On Tue, Jul 30, 2013 at 6:02 PM, Andrew Bartlett <abartlet at samba.org>wrote:
>
>> On Tue, 2013-07-30 at 05:33 -0400, 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: 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) to verify whether a
>> > service ticket is registered for the given security principal name
>> > (SPN). If the query indicates that the SPN is registered with the 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.
>>
>> Indeed.
>>
>> > 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.
>>
>> The cifs/nt4test SPN is implicit, from the implicit host/nt4test SPN
>> that comes from nt4test being the machine's name.
>>
>> The issue for us as a KDC is that there is no flag that I know of that
>> can be set to say that this domain member should not be issued a ticket,
>> and the downgrade protection is an important part of the security of the
>> network.  (that protection isn't useful if the member server can still
>> negotiate for only NTLM without protection, but waiting for that is for
>> another day).
>>
>> Have you tested and shows windows behaves any differently?
>>
>> Finally, as a workaround try connecting to the machine by IP or by a
>> name the KDC doesn't know.
>>
>> Andrew Bartlett
>>
>>
>> --
>> Andrew Bartlett
>> http://samba.org/~abartlet/
>> Authentication Developer, Samba Team           http://samba.org
>> Samba Developer, Catalyst IT                   http://catalyst.net.nz
>>
>>
>>
>