Win2008 R2 Domain Controller: Careful Planning of RODC

In the absence of physical security, it is important to increase the focus on data security. Windows Server 2008 and R2 provide some new ways to do this, and these methods seem to be tailored to environments such as remote offices where physical security is not critical. A read-only domain controller (RODC) is a new feature of Active Directory Domain Services (AD DS) in Windows Server systems. Read-only domain controllers represent a fundamental change to the way that domain controllers (DCs) are typically used.

Because many of the new features of RODC affect key aspects of the design and deployment process, it's important to understand how to leverage these features in your enterprise. There are some key design and planning considerations that must be considered before introducing these features into your environment. An RODC is a DC that hosts a full read-only copy of an Active Directory database partition, a read-only copy of SYSVOL, and a Filtered Property Set (FAS) that limits inbound replication of certain application data from writable DCs. .

By default, RODC does not selectively store user and computer account credentials, but you can configure it for selective storage. This usually only guarantees the use of RODCs in remote branch offices or in perimeter networks where data security is often lacking in the data center intranet. The RODC also provides other lesser-known security features, such as a dedicated Kerberos RODC ticket-granting account for ticket-based attacks associated with the compromised RODC itself.

While security concerns are the most common reason for deploying RODCs, RODCs also offer many other benefits, such as enterprise manageability and scalability. In general, RODCs are used in environments that require local authentication and authorization but lack the secure use of writable DC physical security. Therefore, RODCs are the most common in data center perimeter networks or branch locations.

A data center that requires AD DS is an example of the effective use of RODC, but due to security constraints it is not possible to leverage the company's AD DS forest in the perimeter network. In this case, the RODC may meet the relevant security requirements, thus changing the company's infrastructure to implement AD DS. Such situations will likely become more common. This also reflects the current best practice AD ​​DS model for perimeter networks, such as the extended company forest model.

Establishing Branch Offices with RODCs

The most common environment for RODCs using AD DS is still branch offices. Such environments are typically endpoints in a hub-and-spoke network topology. They are typically distributed across a wide geographic location and are large in number, each carrying a small number of user groups, connected to the central site via slow and unreliable network links, and often lacking experienced local administrators.

For branch offices that already host writable DCs, it may not be necessary to deploy an RODC. However, in this case, the RODC not only meets the existing AD DS related requirements, but also exceeds its requirements for improving security, enhancing management, simplifying the architecture, and lowering the total cost of ownership (TCO). For locations where DCs are prohibited due to security or manageability requirements, RODC can help you bring DCs into the environment and provide a number of useful localization services.

While new features and benefits make RODC highly regarded, there are other factors to consider, such as application compatibility issues and service impact. These factors may cause some environments to be unacceptable for RODC deployment.

For example, because many applications and services that support directories read data from AD DS, they should continue to run and use RODC. However, if some applications require writable permissions at all times, the RODC may not be accepted. The RODC write to the writable DC also depends on the network connection. While write failures can be the most common application-related issue, there are other issues to consider, such as inefficient or failed read operations, write-read-return operations, and associations with the RODC itself. The general application is faulty.

In addition to application issues, basic user and computer operations can be affected when a connection to a writable DC is lost or lost. For example, if the account password is not cacheable and is not cached on the local RODC, the basic authentication service might fail. You can eliminate this problem by making the account cacheable by the RODC's Password Replication Policy (PRP) and then pre-populating the password. Performing these steps also requires connecting to a writable DC.

When you can't connect to a writable DC, password expiration, account lockout, and other authentication issues are significantly affected. Password change requests and any attempt to manually unlock a locked account will fail until the connection to the writable DC is restored. Understanding these dependencies and subsequent changes in operational behavior is critical to ensuring that your requirements and any service level agreements (SLAs) are met.

In a few general cases, you can deploy an RODC. RODC is useful where the DC does not currently exist, or where the currently hosted DC will be replaced or upgraded to a newer version of Windows. While there are specific comprehensive planning considerations for each situation, we focus here on non-specific methods. However, these methods are a completely different approach to RODC, not for traditional writable DCs.