When you manage an Active Directory infrastructure that spans multiple sites, it is a good idea to test the ability of clients to successfully authenticate against domain controllers in other sites.
Quick Recovery Time Objective (RTO) for services in a disaster recovery situation is a key point in the restoration of business productivity. I won’t go into a whole Business Impact Analysis (BIA), Business Continuity Planning (BCP), or Disaster Recovery (DR) plan here, but I am hoping to help you learn to test a small piece on which a lot of other services depend.
When you get right down to it, Active Directory is a service, just like Exchange, your Point of Sale system, or anything else that have an impact on the bottom line of the business. When building a DR plan, you need to take Active Directory into account in your planning and testing. Fortunately, Active Directory comes with tools that allow you to successfully design and build a resilient architecture for authentication.
For my testing, I’m using a multi-site design which resemble the below simplified configuration:
- Site001:CorpWest
- Los Angeles
- 4 domain controllers
- Site002:CorpEast
- New York
- 4 domain controllers
- Site003:Sales
- Las Vegas
- 2 domain controllers
- Site004:CustSup
- Raleigh
- 2 domain controllers
Not a terribly complex set up, but this will help get the point across. I will be using Site003 as my target site for testing.
Replication of Active Directory between the sites is pretty consistent, with high bandwidth connections between the sites providing an excellent mesh. Now the curveball.
The system engineer prior to me (always blame the guy that came before you) had the splendid idea to make all servers virtual, including domain controllers. So while we have a plentitude of domain controllers to service our authentication and directory needs, if the virtual infrastructure an any one site has a problem, the servers on that hypervisor may become inaccessible. This includes the DCs. As a part of my DR testing, I need to make sure the clients at a site are still able to authenticate to the domain, even if their local DCs are out of action.
Ordinarily, hosts at a site will only be configured with DNS pointers to their local DNS servers. Coupled with AD Sites and Services, it’s an easy way to stop your clients from talking to resources across the WAN, when it is cheaper for them to talk to the host right next to them, so to speak.
Using the DHCP console, I added the DNS servers of all the other sites into each site as extra DNS servers, careful to point to the next geopgrapically closest site. So for example, In Site001, I added the DCs for Site003, then Site004, then Site002. This means that if the DCs in Site001 go away, the clients will then try to contact the DCs in Site003. If Site003 is unavailable, the client then tries Site004, and so on. You can add the extra DNS servers by adding them to option 006 in your scope options for the site you are targeting. Be sure to order them as needed, using the Up and Down buttons to the right of the list of IPs.
By default, the DHCP lease time is 3 days, unless you manually expire them. So after making the changes, I waited five days, to let it percolate naturally. Performing spot checks at my target site, I was able to see that the majority of client machines had the new configuration, and I was set to perform the testing. This includes my Windows 7 client virtual machine at my target site.
So far so good. Now I need to test my “before” state. This is to make sure that all services are functional, and the client can login. This is kind of a no-brainer step, but it needs to be done, in the interest of completeness of documentation. Everything went as expected, I was able to successfully log in utilizing the local DC, and no problems were encountered.
Next, I performed a clean shutdown of both domain controllers at Site003. This first test was performed at night, during a documented maintenance window, so calm down about “middle of the day cowboy ops”.
During the shutdown, I am still logged in to the Windows 7 computer at Site003, and still able to access resources as normal. Email still works, file servers are accessible, etc. This is expected behavior, as the authentiation for the logged in user is still valid for a period of time (I think it’s ten hours).
What I am interested in, and the main focus of this post, is how can I tell which domain controller authenticated me. Well, finally, here it is. There are two methods, both pretty simple. I’ll give the longer one first, though.
Method 1
- Open command prompt
- Type the following, replacing with the name of the Active directory domain:
nlttest /dsgetdc:MyDomainName
Sample Output:DC: \\MyDomainController
Address: \\192.168.10.10
Dom Guid: 1a23b45c-d678-9e01-2345-f678g9a0b1cd
Dom Name: MyDomainName
Forest Name: mydomain.local
Dc Site Name: SiteWhereDCLocated
Our Site Name: SiteWhereWeAreLocated
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_FOREST CLOSE_SITE FULL_SECRET WS 0xC000
The command completed successfully
Method 2
- Open command prompt
- Type the following:
Echo %LogonServer%
The name of the domain controller that authenticated the session will be displayed.
As I mentioned, if you are logged while the outage occurs, your current session won’t be interrupted. You should be able to continue as if nothing happened. Now comes the acid test, though. At this point, I completely shut down the Windows 7 machine, and started it up again. After a few moments, I was presented with the login screen, and lo, I was able to login with no problem.
After login, I checked for which DC had authenticated me, and found that a domain controller at Site001 had let me in. I turned the domain controllers at Site003 back on, rebooted my Windows 7 machine, and logged in again. Running the above commands again, I found that a domain controller at Site003 (the local site) had authenticated me to the domain.
So, a successful test, with the necessary documentation.