Can't log in using second domain controller when first DC is unreachable

Question

We're a small web development company. Our domain has two DCs: a main one (BEEHIVE, 192.168.3.20) in the datacenter and a second one (SPHERE2, 10.0.66.19) in the office. The office is connected to the datacenter via a VPN.

We recently had a brief network outage in the office. During this outage, we weren't able to access the domain from our office machines. I had hoped that they would fail over to the DC in the office, but that didn't happen. So I'm trying to figure out why. I'm not an expert on Active Directory so maybe I'm missing something obvious.

Both domain controllers are running a DNS server. Each office workstation is configured to use the datacenter DC as its primary DNS server, and the office DC as its secondary:

  DNS Servers . . . . . . . . . . . : 192.168.3.20
                                      10.0.66.19

Both DNS servers are working, and both domain controllers are working (at least, I can connect to them both using AD Users + Computers).

Here are the SRV records that point to the domain controllers (I've changed the domain name but I've left the rest alone):

C:\>nslookup
Default Server:  beehive.ourcorp.com
Address:  192.168.3.20

> set type=srv
> _ldap._tcp.ourcorp.com
Server:  beehive.ourcorp.com
Address:  192.168.3.20

_ldap._tcp.ourcorp.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = beehive.ourcorp.com
_ldap._tcp.ourcorp.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = sphere2.ourcorp.com
beehive.ourcorp.com     internet address = 192.168.3.20
sphere2.ourcorp.com     internet address = 10.0.66.19

Does anyone have any ideas?


Thanks,
Richard

Solution 1

Check to make sure that BOTH are Global Catalogs.

Howto:

1.) Open Active Directory Sites and Services.

2.) Scroll down, expand the site that your DC's are in. Expand
`Servers'.

3.) Expand each of your DC's so that they're showing `NTDS Settings'.

4.) Right-click on 'NTDS Settings', select `Properties'.

5.) Ensure that the `Global Catalog' checkbox on each is checked.

DISCLAIMER:

I'm assuming that you've already checked your replication, made sure everything else is working properly, etc. This is intended to be a quick-check option.

Solution 2

My wild guess is your site boundaries are wrong.

Comments

[Spence]

An obvious and perhaps silly, but necessary question: Did the outage affect connectivity to the 10.x.x.x subnet? From what I'm seeing if 192.168.3.20 fell off the network but 10.0.66.19 remained reachable to clients you should have seen logons being processed by 10.0.66.19.

[Richard Beier]

Thanks Evan - yes, the 10.x.x.x network is all in the office and it remained reachable during the outage.

[user70200]

Can you be more specific as to what you mean by site boundaries??

[Richard Beier]

Thank you Greg. You were right, the domain controller in the office is not a global catalog server. I didn't realize that would prevent logins to the same domain from working. (We do have a separate domain for our production servers, but we had problems just accessing other machines in the same corporate domain as the workstations.)

[Richard Beier]

I think the reason we didn't make the office DC a global catalog was because we didn't want our Exchange server in the datacenter reaching out to it. If I recall correctly, Exchange selects a GC automatically and we can't force it to choose a particular one. We didn't want it to reach out over the Internet to our office unnecessarily. But the problem is that we don't have sites set up, as Jim mentioned... Thanks, Richard

[Richard Beier]

You're right, our sites are a problem. We only have "Default-First-Site-Name" for the whole domain, even though the office and the datacenter are not connected by a high-bandwidth link. (It's around 1 megabit.) We inherited this infrastructure from someone who's no longer here, and there is definitely some cleanup to do. I hadn't expected the site boundaries to cause problems connecting to a DC, but like I said I'm definitely not an expert. Thanks, Richard

[ansonl]

np mate! Glad I could help!