Tag Archives: Sites & Services

Active Directory Architecture: Read-Only Domain Controllers

Recently we had a situation come up where it was necessary to provide a domain controller in a unique location. This was a “one off” scenario for us; this location was in a third-world country (not unique) and connected with a government controlled crappy DSL line (very unique) and physical security of the equipment could not yet be guaranteed (very, very unique). Nevertheless, we had to provide a local domain controller (as always, like… right now) for a variety of reasons.

While the personnel onsite were our personnel, the overwhelming majority were new to the company.

As we have recently begun migrating all of our domain controllers to Microsoft Windows Server 2008 R2, a read-only domain controller was the perfect fit (actually, the perfect fit would have been better bandwidth and App-V in a country with plumbing).

Read Only Domain Controllers (RODC’s) allow for granular control of the password database; that is you can choose which accounts are cached locally, and which accounts must transverse the WAN for authentication. In addition, the local Active Directory database is read-only. Modifications to it are not replicated to the other domain controllers.

This is important in a situation where physical security cannot be guaranteed initially (as in our case) or network bandwidth is less than ideal (also in our case). If an interested party (and there are a lot) obtained physical access to a standard domain controller, it is possible (alright, easy) to decrypt the Active Directory database and obtain all passwords… this would be particularly devastating if they were able to obtain the passwords for accounts with admin access.

In cases where bandwidth is a concern, the updates that are pushed to a Read Only domain controller are much smaller as they do not contain all account information.

Deploying an RODC is actually quite simple and not much different than a standard domain controller.

First, you need to prepare your domain for the addition of a RODC. Assuming you already have a Windows 2008-based domain controller, you need to run the following command in order to prep the directory:

Adprep /rodcprep

Adprep.exe is located on your Windows Server 2008 CD under the Support Tools directory. It doesn’t take very long to run and is a relatively safe operation (though, by nature, I’m pretty paranoid about anything that makes modifications to the schema).

Now, you’re ready to promote a domain controller as a new RODC. Assuming you have a prepped Windows Server 2008 box by selecting the Active Directory Domain Services role in Server Manager, just run dcpromo as always. Ideally, select “Advanced Mode” on the first screen so that you can configure the password replication policy and other settings during the AD DS installation.

As you pass through the promotion screens, simply select “Read-only domain controller” (RODC) on the same screen where you select the DNS Server and Global Catalog options. I think making the RODC a DNS server is important, but making it a Global Catalog is a matter of debate.

When you get to the password replication screen, you are presented with a number of options. By default, no passwords will be replicated except those accounts that are members of the “Read-Only Domain Controllers” group. I think that unless there is an exceptional circumstance, it is best to leave this be.

Now, add the accounts for the local users at that site to the Read-Only Domain Controllers group. This will allow them to log on locally without their credentials traversing the WAN. It’s important to note that if a user is not a member of this group, and the site link is terminated due to WAN issues, they will not be able to log on at that site until WAN access is restored.

It’s important to note that the following operations will fail if the WAN link is terminated for any reason:

  • Password changes
  • Attempts to join a computer to the domain
  • Computer rename operations
  • Authentications attempts for accounts whose credentials are not cached on the RODC
  • Group Policy updates that an administrator might attempt by running the gpupdate /force command

However, these operations will still succeed even with the WAN link terminated:

  • Authentication and logon attempts, if the credentials for the resource and the requester are already cached
  • Local RODC server administration performed by a delegated RODC server administrator

Read-only Domain Controllers give the Active Directory Architect an important tool in intelligent AD design… allowing them to further refine their architecture when heightened consideration must be given to security and bandwidth.

Hopefully, this article has given you a “real world” introduction to RODC’s. I highly encourage any administrator to thoroughly review Microsoft’s Read-only Domain Controllers Step-by-Step Guide.

Active Directory Architecture: Real World Site Link Benefits & Configuration

I rarely used site links until recently, as the majority of my customers had a single site and didn’t need them. When I did need them, I was only proficient with the basics of setting up Active Directory Sites and, by extension, Active Directory Site Links.

Recently, Site Links have become a major part of my life. Seems silly, I know, but when you’re dealing with a global network with thousands of users and hundreds of servers, it’s critical to get them right and to maintain them. Site Links are definitely not fire and forget. Bandwidth and latency change over time, and it’s important to revisit them every quarter.

I’m faced with an interesting challenge because, due to uber-high security, I’m not “in the know” when it comes to how each physical site is connected to the rest of the network. I’ve been told “it’s sufficient” and little else. So, I had to figure it out on my own. More on that in a minute.

As a refresher, I want to be sure and cover what a site is exactly in Active Directory as well as define a site link.

On the surface, it’s actually very simple. In Active Directory Sites & Services, you create a subnet and then create a site, assigning that subnet to a site which is generally (but not always) related to a physical site. Once you have a site set up, you assign domain controllers to sites. All other servers and workstations then know (via the subnet) which domain controllers they should authenticate against.

Site Links are also created in Active Directory Sites & Services and provide information as to how and when the Active Directory database should be copied.

When you’re dealing with thousands and thousands of computer objects, your Active Directory database can get quite large and probably changes more often than you would think (a LOT of information that changes often is stored in Active Directory and it’s getting more robust as Microsoft transitions more and more data to Active Directory). That large database needs to be copied (often) to all other domain controllers in your domain. If you have lots of sites, you should have lots of domain controllers, and that’s a lot or replication.

Windows Active Directory does set up default site connectors, but they are worthless as they do not take into account latency or bandwidth between sites which just encourages chaos.

With Site Links though, you are able to direct that replication so that it happens when and how you want it to happen.

Back to the network I am currently working with. We don’t know what my bandwidth between sites is, and I don’t know what kind of media it rides on or how it gets there… that’s top secret info, even if we do think we need to know to do our job right.

So, we had to improvise. We simply logged on to each DC and pinged all other DC’s and recorded the latency, making a manual Visio map (did I mention we also cannot install any third party software, so we’re kind of stuck with what is built in to Windows). After that, we did tracert’s between all sites to get an idea of the how traffic was routed. Finally, we did some arbitrary data copies between DCs to get an idea of how much bandwidth we were dealing with.

It’s messy, but it works in a pinch when you can’t get details as to bandwidth, latency, media or even if you’re dealing with a carrier or a private network.

Now that we know what servers talk to each other best, we can set up our Site Links. Site Links are actually quite simple to set up, you simply specify two servers and the “cost” of that connection. The lower the cost, the more likely Windows will elect to use that link when replicating Active Directory Changes. In addition, you can specify a schedule as to when information is replicated. You don’t want it so often that it chokes the network, but you don’t want it so seldom that it presents an unacceptable security risk.

So, say you had multiple sites in the US, Japan, Germany, Guam, Columbia and some parts of Asia with lots of sand. All of those sites connect to each other with different degrees of latency and bandwidth. Germany & the US connect nice and quick, but Asia is a slow, slow link (probably satellite) to Asia, but some sites in Asia actually connect reasonably fast to one another, just not outside the country.

With a Site Link then, we can replicate changes to one domain controller in Asia, and then set up Site Links so that all other domain controllers in Asia first attempt to get their replica’s from that primary site. This allows the Active Directory architect to intelligently route what can be significant traffic along the most efficient route.

Now, multiply that times dozens and dozens of sites and you can see how even a small mistake could result in choking off parts of the network every time Active Directory replication occurs, just like clockwork.

In summary, never underestimate any part of a Windows Active Directory network or assume that “out-of-the-box” is just fine. It’s not… you really, really need to pay attention to the details in order to ensure proper operation, security and service availability.