[Samba] NT4 clients

Ryan Bair ryandbair at gmail.com
Tue Jul 30 03:33:01 MDT 2013


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


More information about the samba mailing list