[Samba] NT4 clients

[Ryan Bair]

OK. I got all excited and ran the test against a 2008 DC this morning.
After allowing NT4 crypto through group policy, it worked seamlessly.

Here's what I saw through wireshark:
1. same old failed extended security negotiation ..
2. Win7 sends DC TGS-REQ for cifs/nt4test
3. DC replies KRB-ERROR: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN

Just for grins, I then added HOST entries for the NT4 box in AD and tested
again. The result was exactly the same as with the Samba DC, Windows issued
a ticket and Win7 rejected the connection to the NT4 box.

In summary, the evidence strongly points to CIFS being a mapped alias to
the HOST SPN. If HOST exists, we can map it to CIFS, if it does not, we
should tell the client that the principal does not exist.

I will open a bug for this.




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

> 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
>>>
>>>
>>>
>>
>