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

Gregory Sloop gregs at sloop.net
Tue Aug 26 15:56:07 MDT 2014

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. 



More information about the samba mailing list