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

[Gregory Sloop]

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

-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---