[Samba] NT4 clients

[Gaiseric Vandal]

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


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