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.van...@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 <ryandb...@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> > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
