8

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?

Community
  • 1
Canadian Luke
  • 885
  • 14
  • 41

2 Answers2

4

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

Boris_yo
  • 156
  • 5
0

You're likely running into issues in part because the Samba 3 DC doesn't really speak the version of Active Directory that Windows 7 Pro was designed from the ground up to operate with. Samba 3 doesn't natively have the Microsoft-specific Kerberos or DNS operability that modern AD environments depend on. For that reason, I would recommend upgrading your domain from Samba 3 to Samba4 (link is for an in-place upgrade) to take advantage of the updated AD compatability, including Kerberos and DNS capabilities that will likely make your Win7 systems work much better and also provide things like Group Policy that will enable you to not have to touch every single workstation repeatedly to make configuration changes.

Short of that, in your current setup I wonder why you keep having to change the LMHOSTS file? Is it getting changed somehow between when you run that command? Have you checked its contents before you do this? If you have to manually configure name resolution on each workstation, look at the HOSTS file in the same directory as LMHOSTS and make sure there are no entries that continue to point to the 192.168.0.1 server. Also, what addresses are your Win7 systems set to use for primary/secondary DNS? Do they point only to DNS servers on the Internet (e.g., your ISP's or Google's servers), or are there any internal addresses?

Even if you do choose to upgrade Samba, note that any manual changes to the HOSTS or LMHOSTS files on your workstations will be used instead of querying DNS for those entries, so you may need to clean this up on each workstation (ensure HOSTS only has an entry for 127.0.0.1 localhost).

nedm
  • 5,610
  • 5
  • 30
  • 52
  • 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. – nedm Aug 02 '13 at 17:52
  • 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 – Canadian Luke Aug 02 '13 at 18:30
  • 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. – nedm Aug 02 '13 at 18:39
  • No, once I set the option once, it stuck – Canadian Luke Aug 02 '13 at 18:52
  • I see -- my misunderstanding then. Again, glad you got it sorted. – nedm Aug 02 '13 at 18:55
  • Me too! But because I can't make the decision on my own about upgrading to later software (I'm part of a large organization), I will not be upgrading to Samba4 right away, but will bring it up at our next meeting – Canadian Luke Aug 02 '13 at 19:08