[Samba] NT4 clients

[Ryan Bair]

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.


On Mon, Jul 29, 2013 at 5:23 PM, Gaiseric Vandal
<gaiseric.vandal at gmail.com>wrote:

> I wouldn't  have even guessed that NT4 would join a modern AD domain.   It
> looks like MS did provide client software to join a Windows 2000 AD domain.
>    Or does the NT4 machine think it is in an NT4 / Samba3 type domain?
>
>
> Presumably you can see the domain users in the local user manager program
> on the NT4 machine?   And verify the security options.
>
> http://www.windowsnetworking.**com/articles-tutorials/**
> windows-nt/nt4user.html<http://www.windowsnetworking.com/articles-tutorials/windows-nt/nt4user.html>
>
>
> Do you have a a WINS server running?          With XP/Windows 7 when you
> join an AD domain, the machine name usually gets set to a fully qualified
> domain name.  e.g. mypc.mydomain.com.     Does the host name of the NT4
> machine match the expected AD fully qualified domain name (does nslookup
> ip_address on the NT4 machine return the expected hostname? )       Are all
> machines in DNS? I think a hostname or dns mismatch could cause  problems
> validating AD kerberos tickets.
>
> I am running Samba 3, not 4, but found that using a WINS server and making
> sure key systems were in DNS helped solve some issues.
>
>
>
>
>
>
>
> On 07/29/13 17:05, Ryan Bair wrote:
>
>> Oh, forgot to mention. Samba 4.0.7-4 Sernet packages running on CentOS
>> 6.4.
>>
>>
>> On Mon, Jul 29, 2013 at 5:00 PM, Ryan Bair <ryandbair at gmail.com> wrote:
>>
>>  I'm attempting to get an old NT4 client participating in a Samba4 domain.
>>> Users can logon to the machine locally and access network shares on other
>>> machines in the network. However, no one can access shares on the NT4
>>> machine using the machine name. Attempting this results in an error "The
>>> account is not authorized to log in from this station." Using the IP
>>> address does work however.
>>>
>>> The clients are configured to allow no smb signing and NTLMv1, I think I
>>> have all the security settings covered.
>>>
>>> I noticed while looking at wireshark though that the client is doing
>>> TGS-REQ for cifs/nt4test and Samba is returning a full TGS-REP. This
>>> feels
>>> very odd to me since there is no such SPN cifs/nt4test on the network.
>>> 'setspn -Q cifs/nt4test' confirms this.
>>>
>>> I've also noticed that the MS docs state:
>>> <94> Section 3.2.5.2:
>>> <http://msdn.microsoft.com/en-**us/library/d367854f-5eee-45e8-**
>>> a588-eed596a1a521#endNote94<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<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<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<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<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.
>>>
>>> The client does have CAP_EXTENDED_SECURITY set and I'm guessing the
>>> TGS-REQ is how Windows is testing the presence of the SPN. Since the test
>>> is succeeding and the server doesn't advertise the extended security
>>> capability, Windows disconnects.
>>>
>>> Can someone confirm my hypothesis?
>>>
>>>
>>>
>>>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/**mailman/options/samba<https://lists.samba.org/mailman/options/samba>
>