[Samba] NT4 clients

[Ryan Bair]

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