[Samba] SOLVED Re: Windows 7 Pro/64 unable to contact domain controller

[Gary Dale]

On 26/08/14 05:56 PM, Gregory Sloop wrote:
> Re: [Samba] Windows 7 Pro/64 unable to contact domain controller
>
>
> *GD> On 26/08/14 05:18 PM, Rowland Penny wrote:
> >> On 26/08/14 22:09, Gary Dale wrote:
> >>> On 26/08/14 04:42 PM, Gregory Sloop wrote:
> >>>> Re: [Samba] Windows 7 Pro/64 unable to contact domain controller
>
>
> >>>> *GD> On 26/08/14 12:26 PM, Gary Dale wrote:
> >>>> >> I have a number of systems running Windows 7/pro 64bit connecting
> >>>> to a
> >>>> >> Debian/Wheezy Samba DC. After one was rebooted today, I was
> >>>> unable to
> >>>> >> log on with a domain account, with the usual message about being
> >>>> >> unable to connect to a domain controller.
>
> >>>> >> After logging on with a local account, I tried rejoining the 
> domain
> >>>> >> but was unable - again Windows complained that it can't 
> contact the
> >>>> >> domain controller. Re-did the Window registry settings change to
> >>>> allow
> >>>> >> Win7 to connect to an NT-style domain but still no luck. Same 
> when I
> >>>> >> turned off the firewall. Rebooted multiple times in the process.
>
> >>>> >> I can connect to network shares on the Samba DC (3.6.6) and can
> >>>> >> connect with SWAT using the NetBIOS name but others can't 
> connect to
> >>>> >> shares on this computer.
>
> >>>> >> Any ideas?
>
> >>>> GD> The Samba logs show absolutely nothing happening which suggests
> >>>> that
> >>>> GD> Windows is accurate when it says it can't find or connect to a
> >>>> login
> >>>> GD> server / domain controller.
>
> >>>> GD> I've been through all the Google searches I can think of and
> >>>> haven't
> >>>> GD> found much beyond the local security policy and local registry
> >>>> changes.
>
> >>>> GD> I can connect to shares on the computer only when I use a local
> >>>> account.
>
> >>>> *This sounds a lot like DNS that isn't operating as you'd expect.
> >>>> [i.e. A DNS query doesn't return the correct address for the server,
> >>>> or perhaps any address at all.]
>
> >>>> What's handling DNS for the problem workstation, and is it handing
> >>>> out answers properly. [A rogue DHCP server which pollutes DNS could
> >>>> cause it too.]
>
> >>>> -Greg
> >>> The DNS is handled through a D-Link DIR-825 router, although it
> >>> doesn't do it properly. I've pointed it to the PDC for WINS (a manual
> >>> setting that it has). I've tried the router with the Advanced DNS
> >>> turned on (which it was until yesterday, when I tracked that
> >>> "feature" to an intermittent time-out error with database 
> connections).
>
> >> By DNS, do you mean that the clients are being pointed at the router
> >> as the DNS server ?, if so, then this could be your problem, the
> >> clients should be using the S4 AD DC as the DNS server. This would
> >> entail using either the internal dns server or bind9 with forwarders
> >> pointing the way out of the samba domain.
> GD> Except I'm running Samba 3.6.6 (Debian/Wheezy). The workstations get
> GD> their DNS from whatever DHCP hands out, which should be the router's
> GD> address. The router points to the Samba server for WINS. This seems to
> GD> be working to the extent that I can ping machines by name.
>
>
>
> >>> When I turned it off, name resolution seemed to be working fine for
> >>> the local computers. This was tried with both OpenDNS and the DNS
> >>> servers provided by the ISP.
>
> >>> I turned it back on several hours ago but that doesn't seem to make
> >>> things any better.
>
> >>> The problem only seems to be affecting this one machine. there are 8
> >>> other workstations that seem to have no problems with domain logins.
>
> >> Could be that this one machine could be the only one that is running
> >> correctly and the others are going to start following suit.
> GD> It's been almost 8 hours and so far it's just the one machine.
>
>
> *Active directory is completely dependent on DNS.
> [i.e. Nothing works, at least properly, without a proper DNS.]
>
> To do a domain join, it looks up the FQDN you supply to know which AD 
> domain to join. [Short netbios names get around this, because they can 
> get resolved without DNS.]
>
> For AD, the DHCP server should hand out the IP of the AD server(s) as 
> what stations should use for DNS.
>
> The server can have a "forward" address where it will forward DNS 
> queries that it doesn't know the answers to. [Namely, anything outside 
> the AD domain.]
>
> So, in your situation, I suppose the following would work. (Though 
> it's not optimal.)
>
> Stations get DHCP addresses and for DNS they point to the AD server.
> The AD Server is configured to look to the DLink router for any DNS 
> addresses it doesn't know the answer to.
> [And then the router will go to whatever it's configured as for it's 
> DNS queries.]
>
> (So probably omitting the router as a DNS source would be a good 
> thing, even though it technically works.)
>
> If that isn't configured, then when you do any _non_ NETBIOS lookups, 
> that involve the AD Domain, who the heck is going to provide the 
> answers? Comcast, or OpenDNS isn't going to know about your internal 
> AD server DNS information - the only thing(s) that knows that data is 
> the AD servers themselves.
>
> HTH
>
> -Greg
OK Greg, got it. I set up an lmhosts file on the flaky workstation to 
point to the PDC (looks like this):
192.168.1.17    servername#20
192.168.1.17    servername#1b

which apparently tells Windows that the machine is a domain controller 
(the second line - the first tells windows it is a workstation). I was 
then able to re-add it to the domain, reboot and everything is working.

I never needed this before, so I'm not sure why it is needed now, but 
for now, its running.