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

[Gary Dale]

On 26/08/14 06:48 PM, Gregory Sloop wrote:
> Re: [Samba] SOLVED Re: Windows 7 Pro/64 unable to contact domain 
> controller
>
>
> *GD> 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
> GD> OK Greg, got it. I set up an lmhosts file on the flaky workstation to
> GD> point to the PDC (looks like this):
> GD> 192.168.1.17    servername#20
> GD> 192.168.1.17    servername#1b
>
> GD> which apparently tells Windows that the machine is a domain controller
> GD> (the second line - the first tells windows it is a workstation). I was
> GD> then able to re-add it to the domain, reboot and everything is 
> working.
>
> GD> I never needed this before, so I'm not sure why it is needed now, but
> GD> for now, its running.
>
> *See my prior post. Your "fix" may perhaps "fix" the problem by making 
> the symptoms go away - but you have a root problem with name resolution.
>
> If you don't track it down and fix it now, you're likely to spend a 
> lot of time fighting it later. [Unless it's something that's purely 
> with this station - but, IMO, you don't know that with _any_ certainty 
> at the moment.]
>
> In short, beware of "cludges" that fix symtoms but leave root causes 
> untouched.
>
> -Greg
Agreed. I've already done another change in the name resolve order that 
seems to have obviated the need for the lmhosts file. Not sure how that 
worked, but it is letting me login using domain accounts and so far 
hasn't shown any other side effects.

The other machines continue to operate normally, so I think the major 
name resolve problems were limited to this one machine. The one minor 
issue is that I can't ping the domain name from the other machines.