If you would like to read the other parts in this article series please go to:
Introduction
In my previous article, I explained the basic reasoning behind Microsoft’s decision to offer Read Only Domain Controllers in Windows Server 2008. This article continues the series by examining some of the practical aspects of working with Read Only Domain Controllers.
In the first part of this article series, I began discussing some of the benefits associated with using Read Only Domain Controllers in branch offices. In this article, I want to continue the discussion of talking about the way that Read Only Domain Controllers work, but in a little bit more depth than I was able to get into last time.
User Account Credentials
I want to start off by clarifying something that I said at the end of the first article. Near the end of that article, I stated that no user account information is stored on read only domain controllers. As I read over that article in preparation for this one, I realized that my choice of wording was very poor.
In actual fact, user account information is stored on read only domain controllers. What the domain controllers are lacking is the user’s passwords. Passwords are not replicated to Read Only Domain Controllers. If someone were to steal a domain controller from a branch office, they would not be able to use information stored in the Active Directory database to crack the user’s passwords.
User Attributes
By default, passwords are the only user attributes that are not replicated to Read Only Domain Controllers. You do however have the option of manually configuring Windows to prevent other user attributes from being replicated.
So why would you use such a feature? If you are only using the Active Directory as an authentication mechanism, then you probably wouldn’t. Keep in mind though, that there are organizations that depend heavily on the Active Directory for things other than just authentication.
To give you an example of what I am talking about, let me tell you about a place I used to work in. It was a large enterprise environment, and they had their own on site development staff. The company’s developers had created custom applications for just about every internal business process that you can imagine. Almost all of these custom applications were database driven, but none of the databases were linked with each other.
What this meant was that every database contained some duplicate information. For example, each employee’s name, telephone extension, and employee ID number (among other things) were included in each database. Inevitably though, mistakes that occurred during the data entry process meant that data was not always consistent from one database to the next. For example, an employee’s name might be misspelled in one database but not on another, or, two digits in an employee’s ID number might get transposed in one of the databases.
A few years ago, some companies began to realize that using this approach was very inefficient. Not only is it prone to errors, but the company was paying its data entry clerks to enter data that already existed in another database. There are a lot of different solutions to this sort of problem, but one common approach is to include commonly used information in the Active Directory.
For example, I know of one organization that has created a human resources application that they use internally. Although the bulk of the data is stored in a SQL Server database, things like employee’s names, titles, phone numbers, etc. are stored in the Active Directory as user account attributes. This allows common information to be reused in multiple locations, and it provides a disconnection between the user’s names and the more confidential data. The SQL Server database contains things like social security numbers and salary information, but it does not contain any employee names. The only thing tying the two databases together is an employee number that is found in both databases.
The reason why I am telling you all this is to point out the fact that some organizations use user account attributes heavily and these attributes can sometimes contain sensitive information. As such, unless there is a direct need for this type of information to be stored locally on a domain controller in a branch office, you might consider blocking some of the more sensitive attributes from being replicated.
One thing that you should keep in mind is that while some organizations do make use of user attributes within applications, it is more common for applications to utilize application directory partitions. In case you are not familiar with application directory partitions, they are special Active Directory partitions that are created specifically to be used by an application. Read Only Domain Controllers fully support one way replication of data that is stored in application directory partitions.
On a similar note, Read Only Domain Controllers can also be configured to act as read only DNS servers. Essentially this means that if you host a DNS server on a Read Only Domain Controller, then an intruder would not be able to tamper with the DNS records.
Administrative Issues
I am sure that by now you probably have a lot of questions about the administration of read only domain controllers. I’m going to try to do my best to anticipate these questions and answer them.
How Do Users Authenticate if There is No Password Data?
This is a tricky one. As you may know, both user accounts and computer accounts have passwords associated with them. By default, the only passwords that a Read Only Domain Controller will store are its own computer account password, and the password for a special account named “krbtgt”, which is used by Kerberos.
Because no passwords are stored locally, authentication requests are forwarded to a writable domain controller. If your goal is to allow users to be able to logon even if a writable domain controller can not be contacted, then you need to enable password caching. If password caching is enabled, then only accounts that authenticate through the domain controller will have their passwords cached. If the domain controller is compromised, you can use your other domain controllers to find out which accounts’ passwords were cached so that you can reset those passwords.
How does the administration work?
A lot of times in branch offices a domain controller will also be configured to act as an application server. If there are not any dedicated IT staff members in a branch office, then you can designate someone to be an administrator of a read only domain controller without making them a domain administrator. That way, they can have local administrative control over the server without being able to mess up the Active Directory. This allows them to install software patches and perform any required day to day maintenance tasks. Designating someone as an administrator over a Read Only Domain Controller is similar to making someone a local administrator over a member server or a standalone server.
Conclusion
Hopefully you now have a basic understanding of how Read Only Domain Controllers are used in the real world. In the third part of this series, I will walk you through the process of deploying a Read Only Domain Controller.
If you would like to read the other parts in this article series please go to:
