Reset Domain Trust with workstations from Samba 3.x server

Question

I am having issues on a network I inherited with a Samba 3 server acting as the domain controller, and many, but not all, Windows 7 Pro PCs. The issues described here and here do not solve my issue.

On boot up, on some PCs, I get an error message saying The trust relationship between this workstation and the domain controller has failed. My Google searches explain to remove/re-add the machine from the domain, and this requires manual intervention, and sometimes doesn't work. What I have been doing, since this is intermittent, even with systems that are currently logging in OK, is to run the following command from an Elevated Command Prompt on each PC: echo 192.168.0.3 smb > c:\windows\system32\drivers\etc\lmhosts. I then reboot, and the error stays away then.

The weird thing is that once in a while, it just assumes my server is at a different IP address. The computers sometimes think that the SMB server is 192.168.0.1 instead of 192.168.0.3. I can verify this, because when I do net use \\smb, I get a Network name not found, but I can ping it and get the right address. When I do a new view \\smb, it would go to the old server (which is now 192.168.0.1, never had this name though). Doing a net view \\192.168.0.3 would show the correct server, then let me login to Windows just the one time, until reboot.

My issue is that I need to figure out why this is happening, so I do not need to touch every PC. It's a fast fix, once everything loads, but is not ideal. Below is the output of my testparm command on the Primary Domain Controller:

Load smb config files from /etc/samba/smb.conf
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Processing section "[netlogon]"
Processing section "[homes]"
Processing section "[Programs]"
Processing section "[Login]"
Processing section "[Windsor]"
Processing section "[Office]"
Processing section "[Admin]"
Processing section "[Student_Share]"
Processing section "[Tech_Tips]"
Processing section "[Tech_Apps]"
Processing section "[DropBox]"
Processing section "[SSS]"
Processing section "[JMC]"
Processing section "[DRC]"
Processing section "[FASD]"
Processing section "[CLA]"
Processing section "[YAPS]"
Processing section "[IMAGES]"
Processing section "[Printer_Drivers]"
Processing section "[Self_Serve]"
Loaded services file OK.
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_DOMAIN_PDC

All of the shares are OK. The time on each workstation is matched up with the domain controller (NET TIME \\SMB /SET /Y in the startup script), and I can log in as the Local Administrator only. What can I look for on my Samba server to not require this weird workaround?

Solution

Is there a backup Samba server running on the network, which is also the DNS server? Did it try electing itself all the time for WINS? Change the OS level to 240 so the main WINS server would win (255). Try to disable the backup Samba server. After disabling, and waiting about 24 hours, do the machines connect properly?

Tools you can use to figure this out: Mainly just the smbfind tool included in Debian

Comments

[antpaw]

I see you solved this (posted while I was writing my answer!) and glad you found a solution that worked. To make your life easier going forward, I'd still recommend looking into upgrading to a Samba4 domain.

[Arunkumar]

The LMHosts file is non-existent by default. It's used just for WINS resolution; that's why I can ping and get the right address, but net view with the name goes to a different machine

[antpaw]

Right, but you still shouldn't have to run the same command to set it repeatedly once you've created it -- unless that's not what you meant regarding the intermittent nature of the problem. If it was getting changed some other way without your intervention, something else would need to be going on.

[antpaw]

I see -- my misunderstanding then. Again, glad you got it sorted.