If you would like to read the other parts in this article series please go to:
- Active Directory Insights (Part 1): Configuring DNS on domain controllers
- Active Directory Insights (Part 2): Digging into Trusts
- Active Directory Insights (Part 3): Re-examining read-only domain controllers
- Active Directory Insights (Part 5) – Domain controller hardware sizing
- Active Directory Insights (Part 6): Domain controllers and NIC teaming
- Active Directory Insights (Part 7) – More on using virtual domain controllers
- Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
- Active Directory Insights (Part 9) – Automating user account provisioning
- Active Directory Insights (Part 10) – DHCP and domain controllers
- Active Directory Insights (Part 11) – sIDHistory
- Active Directory Insights (Part 12) – MaxTokenSize
- Active Directory Insights (Part 13) – Digging into the Global Catalo
- Active Directory Insights (Part 14) – More about the Global Catalog
Intorduction
In the previous article of this series we began reviewing some key resources on how read-only domain controllers (RODCs) work, why they’re useful, and how they can be deployed. RODCs can provide some extra security for your Active Directory environment, particularly if your business has remote branch offices where physical security is not up to the same level as at your central office site. I then said that once you’ve downloaded and read all of the RODC documentation that Microsoft has provided, you may still come across a few issues or scenarios not covered by those docs or at least aren’t covered very well by them. We then looked at two important considerations involving RODCs:
- RODCs and their compatibility with your line-of-business applications
- RODCs need to be able to communicate directly with the domain controller holding the PDC Emulator role
In this present article we’ll examine a few more things you might need to be aware of when you plan on deploying RODCs in your environment.
SharePoint on RODCs
The RODC Application Compatibility Guide indicates that Windows SharePoint Services is compatible with RODCs but then qualifies this by saying that it might not work properly if it is directly installed on an RODC. A colleague of mine took a closer look at this as one of his clients insisted on trying to deploy SharePoint Server 2010 in the DMZ segment of their network. The client wanted to either install SharePoint directly on the RODC in the DMZ if possible, or at least installed it on another server in the DMZ. The RODC of course was the only domain controller in their DMZ.
First off, it wouldn’t even be possible to deploy SharePoint in the DMZ. That’s because the SharePoint 2010 installation process needs to be able to write to Active Directory in order to successfully complete the installation. This is explained in the article Track or block SharePoint Server 2010 installations in the TechNet Library. So right off the top, it looks like this scenario is unworkable. Of course you could try temporarily introducing a writeable domain controller into the DMZ in order to complete the SharePoint installation and then remove the writeable domain controller once setup is finished, leaving only the RODC. Might that work?
Before we answer this, let’s look first at the other issue of what happens when you install SharePoint on an RODC. Bill Baer, a Senior Product Marketing Manager for SharePoint at Microsoft, has a post on his blog titled SharePoint and Read-Only Domain Controllers (RODC) that describes in detail some of the limitations that occur when you install SharePoint on an RODC. We’ll skip right to Bill’s conclusion where he says the following:
“In most cases an organization should not experience the issues listed above as a RODC implementation should include writable partner replication servers. In Extranet and perimeter network scenarios, writer operations will fail, RODC is not a candidate in such scenarios; however, where connectivity exists between and RODC and a partner replication server, a write operation will return a referral to a writable domain controller – if connectivity to a writable domain controller is not available, then Write operations fail regardless of whether the application uses LDAP or ADSI.”
So it seems best practice here is not to deploy SharePoint in a DMZ where only RODCs are present and no writeable domain controllers. But if you’re only planning on deploying SharePoint for hosting an externally-facing web site so that no write backs to the RODC are required, then it’s probably OK to implement something like this.
Configuring password caching on RODCs
When you first deploy an RODC into your Active Directory environment, you need to configure the Password Replication Policy on the writable domain controller that will be the replication partner for the RODC. This policy functions as an access control list that determines whether or not the RODC should cache passwords for user and computer accounts in Active Directory. The steps for configuring the Password Replication Policy for an RODC are explained in this article in the TechNet Library.
A good deal of the problems businesses often experience with RODCs result from incorrectly configured Password Replication Policies for their RODCs. For example, one company I know deployed RODCs at several remote branch offices for better security. Then because of hardware failure the WAN link went down for more than a week between the company’s head office and one of their remote sites, and after a couple of days several users at that remote site could no longer access any local resources at their own site because the RODC would no longer authenticate them. The users at the remote site became frustrated, the manager complained, and the IT person got mad at Microsoft for designing RODCs so badly!
Of course, the real problem was that the IT person had not properly configured the Password Replication Policy for the RODCs at the remote sites. The Password Replication Policy for a RODC includes a built-in security group named Allowed RODC Password Replication Group which by default grants to the members of this group the ability to cache passwords on any RODC in the domain where the RODC resides. However, it’s not enough to just add the user accounts of users at the remote site to this group. You should also add the computer accounts of the computers at the remote site to this group. As it says in Appendix A of the RODC Planning and Deployment Guide on TechNet:
“Caution: For an RODC to authenticate a logon request locally, both the user and computer credentials must be cached locally. If the user’s credentials are cached, but the computer credentials are not cached, the RODC cannot provide a service ticket for the user to log on to the computer. If a network outage prevents the RODC from contacting a writeable domain controller running Windows Server 2008 or later, the RODC will not be able to provide a service ticket for the computer account and the user logon will fail.”
It’s also important to realize that just because you’ve specified the list of user and computer accounts that are allowed to be cached by the RODC doesn’t mean that the passwords for those accounts have actually been cached. The way around this issue is to manually pre-populate the logon credentials for user and computer accounts that you need the RODC to be able to authentication. The procedure for doing this is described in the section titled “Prepopulating the password cache for an RODC” on this page in the TechNet Library. Be sure also to read the Note at the end of this section concerning latency between the RODC and the writeable domain controller after PRP permission changes are implemented.
There are a few other issues regarding RODCs that I’ve heard about from the field, but we’ll postpone examining these until later in this series.
Got questions about Active Directory?
If you have any questions about using read-only domain controllers, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.
If you would like to read the other parts in this article series please go to:
- Active Directory Insights (Part 1): Configuring DNS on domain controllers
- Active Directory Insights (Part 2): Digging into Trusts
- Active Directory Insights (Part 3): Re-examining read-only domain controllers
- Active Directory Insights (Part 5) – Domain controller hardware sizing
- Active Directory Insights (Part 6): Domain controllers and NIC teaming
- Active Directory Insights (Part 7) – More on using virtual domain controllers
- Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
- Active Directory Insights (Part 9) – Automating user account provisioning
- Active Directory Insights (Part 10) – DHCP and domain controllers
- Active Directory Insights (Part 11) – sIDHistory
- Active Directory Insights (Part 12) – MaxTokenSize
- Active Directory Insights (Part 13) – Digging into the Global Catalo
- Active Directory Insights (Part 14) – More about the Global Catalog
