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