I haven't followed this thread closely at all - but how about simply really
limiting the players.
Reduce the network to just the DC's and client that's supposed to join
the domain those DC's hold.
Unplug everything else from the network.
Yeah, it's a total PITA, but it sure simplifies things and ensures
there's not an interaction elsewhere with something else. And while it's
a PITA, it seems a lot "easier" than more elaborate troubleshooting.
(I speak from experience. Sometimes I find it's my own error. Sometimes I
find really weird interactions I didn't think were possible. But swapping
hardware and really limiting the complexity of the network and the number of
devices involved has saved me a ton of time and frustration over the years. And
frankly it's often just way *easier* and *quicker*.)
Part of my underlying thought is that it sure looks like there's some
services being offered that sure appear to be coming from something else other
than the DC's intended. [Packet captures could be revealing, though
that's often more work than simply unplugging stuff.]
Of course, not having read the whole thread - I could be wildly off. Take it for
what it's worth.
-Greg
Rpvs> On 01/03/2021 17:18, K. R. Foley wrote:
>> On 3/1/21 11:06 AM, Rowland penny via samba wrote:
>>> On 01/03/2021 16:29, K. R. Foley wrote:
>>>> Is there a way to run a command on the server (ie. smbclient)
that
>>>> will tell what protocols are supported?
>>> Easiest way would be to run on the DC:
>>> smbclient -L localhost -N
>>> The last line of the output should be:
>>> SMB1 disabled -- no workgroup available
>>> I wonder if your problem is down to a lack of encryption ? Try
adding
>>> 'smb encrypt = enabled' to the smb.conf on the DC.
>>> After this, I am running out of ideas.
>>> Rowland
>> Yes. I had already tried that. See below.
>> [root at ss-prod kr]# smbclient -L localhost -N
>> Anonymous login successful
>> Sharename Type Comment
>> --------- ---- -------
>> sysvol Disk
>> netlogon Disk
>> IPC$ IPC IPC Service (Samba 4.11.13)
>> SMB1 disabled -- no workgroup available
Rpvs> Well at least it shows that your DC is not using SMBv1, so why does
your
Rpvs> Windows client think it is ?
>> Additionally, I also tried adding 'smb encrypt = enabled'. No
change.
Rpvs> It was just a thought.
Rpvs> I think this is looking like a dns problem on your Windows client or at
Rpvs> least a Windows problem. You have this in the log you posted:
Rpvs> NetUseAdd to \\ss-prod.local.richardshapiro.com\IPC$ returned 384
Rpvs> IPC$ is a hidden Samba share that is required for Samba to function and
Rpvs> '384' means it isn't secure.
Rpvs> Try running this on the DC: smbclient //ss-prod/IPC$ -UAdministrator
Rpvs> After entering the password, you should find yourself at a prompt:
Rpvs> Try "help" to get a list of possible commands.
Rpvs> Press 'q' to exit
Rpvs> Rowland