RODC in server 2008R2
Read-only domain controllers (RODCs), a new feature of Active Directory Domain Services, represent a fundamental change in how you'll use DCs. Here's what you need to know to implement them in your enterprise.
When physical security is lacking, it becomes essential to increase the focus on data security. Windows Server 2008 and R2 provide some new ways to do so that seem uniquely tailored for environments like remote offices where physical security may not be as tight. Read-only domain controllers (RODCs) are a new feature of the Active Directory Domain Services (AD DS) in the Windows Server systems. They represent a fundamental change to how you'd typically use domain controllers (DCs).
Because many of RODCs' new capabilities impact key aspects of the design and deployment process, it's important to understand how you can leverage them in your enterprise. There are also critical design and planning considerations you must take into account before introducing them into your environment. RODCs are DCs that host complete, read-only copies of Active Directory database partitions, a read-only copy of SYSVOL, and a Filtered Attribute Set (FAS) that restricts the inbound replication of certain application data from writable DCs.
Generally speaking, RODCs are meant for environments that require local authentication and authorization, but lack the physical security to safely use writable DCs.
Branching Out
The most common environments for RODCs using AD DS are still branch offices. These types of environments are typically end points in a hub-and-spoke network topology. They're widely distributed geographically, in large numbers, and they individually host small user populations, connect to hub sites by slow, unreliable network links. Additionally, they often lack local, experienced administrators.
For branch offices already hosting writable DCs, it's probably unnecessary to deploy RODCs. In this scenario, however, RODCs may not only meet existing AD DS-related requirements, but also exceed them with regard to tighter security, enhanced management, simplified architecture and lower total cost of ownership (TCO). For locations where security or manageability requirements prohibit using DCs, RODCs can help you introduce DCs into the environment and provide a number of beneficial, localized services.
Although the new features and benefits make evaluating RODCs compelling, there are additional factors to consider, like application compatibility issues and service impact conditions. These could render RODC deployments unacceptable for certain environments.
For example, because many directory-enabled applications and services read data from AD DS, they should continue to function and work with an RODC. However, if certain applications require writable access at all times, an RODC may not be acceptable. RODCs also depend on network connectivity to a writable DC for write operations. Although failed write operations may be the cause of most well-known application-related issues, there are other issues to consider, such as inefficient or failed read operations, failed write-read-back operations, and general application failures associated with the RODC itself.
Besides application issues, fundamental user and computer operations can be affected when connectivity to a writable DC is disrupted or lost. For example, basic authentication services may fail if account passwords are not both cacheable and cached locally on the RODC. You can easily mitigate this issue by making accounts cacheable through an RODC's Password Replication Policy (PRP), and then caching the passwords through pre-population. Performing these steps also requires connectivity to a writable DC.
Along with other authentication issues, password expirations and account lockouts are significantly impacted when connectivity to a writable DC is unavailable. Password change requests and any attempts to manually unlock a locked account will continue to fail until connectivity to a writable DC is restored. Understanding these dependencies and subsequent changes in operational behavior is critical to ensuring your requirements and any service level agreements (SLAs).
There are several general scenarios in which you can deploy RODCs. They're useful in locations that don't have existing DCs, or in locations that currently host DCs that will either be replaced or upgraded to a newer version of Windows. Although there are comprehensive planning considerations specific to each scenario, we'll focus here on non-specific approaches. They are, however, distinct to RODCs, rather than to traditional writable DCs.
Preplanning
Before you start any formal RODC planning, you should conduct an appropriate level of due diligence and fundamental AD DS preplanning. This should include key tasks like validating the existing AD DS logical structure, and ensuring the administration model and the AD DS physical structure supports existing business and technical requirements. You'll also have to consider hardware requirements, software upgrade strategies, and applicable operating system known issues, and to evaluate RODC AD DS prerequisites. This information will be critical to the planning and deployment processes. You'll find it's well-documented in detailed deployment check lists.
Management Features
There's a substantial manageability feature in RODCs called Administrator Role Separation (ARS). This delegates to non-service administrators the ability to install and administer RODC servers, without granting Active Directory rights. This is a significant change to the traditional considerations with respect to DC server design, delegation of administration, and deployment procedures. This role separation becomes increasingly important with critical applications requiring direct installation on a DC, or for locations that host single, multi-purpose servers.
Additional Server Roles
As a general rule, you should eliminate from the server all roles not required for the RODC to function. Therefore, the only roles you should add to RODCs are the DNS and global catalog server roles. You should install the DNS server role on each RODC so local DNS clients can perform DNS resolution when network connectivity to a writable DC is unavailable. However, if the DNS server role is not installed through Dcpromo.exe, you'll have to install it afterward. You have to use Dnscmd.exe to enlist the RODC in the DNS application directory partitions that host the Active Directory integrated zones. You should also configure RODCs as global catalog servers so they can perform authentication and global catalog queries using just the RODC. From an authentication standpoint, if the global catalog role is not an option, you can use universal group caching. Successful authentication to an RODC may ultimately be dependent on the RODC's PRP configuration.
Read-only domain controllers (RODCs), a new feature of Active Directory Domain Services, represent a fundamental change in how you'll use DCs. Here's what you need to know to implement them in your enterprise.
When physical security is lacking, it becomes essential to increase the focus on data security. Windows Server 2008 and R2 provide some new ways to do so that seem uniquely tailored for environments like remote offices where physical security may not be as tight. Read-only domain controllers (RODCs) are a new feature of the Active Directory Domain Services (AD DS) in the Windows Server systems. They represent a fundamental change to how you'd typically use domain controllers (DCs).
Because many of RODCs' new capabilities impact key aspects of the design and deployment process, it's important to understand how you can leverage them in your enterprise. There are also critical design and planning considerations you must take into account before introducing them into your environment. RODCs are DCs that host complete, read-only copies of Active Directory database partitions, a read-only copy of SYSVOL, and a Filtered Attribute Set (FAS) that restricts the inbound replication of certain application data from writable DCs.
Generally speaking, RODCs are meant for environments that require local authentication and authorization, but lack the physical security to safely use writable DCs.
Branching Out
The most common environments for RODCs using AD DS are still branch offices. These types of environments are typically end points in a hub-and-spoke network topology. They're widely distributed geographically, in large numbers, and they individually host small user populations, connect to hub sites by slow, unreliable network links. Additionally, they often lack local, experienced administrators.
For branch offices already hosting writable DCs, it's probably unnecessary to deploy RODCs. In this scenario, however, RODCs may not only meet existing AD DS-related requirements, but also exceed them with regard to tighter security, enhanced management, simplified architecture and lower total cost of ownership (TCO). For locations where security or manageability requirements prohibit using DCs, RODCs can help you introduce DCs into the environment and provide a number of beneficial, localized services.
Although the new features and benefits make evaluating RODCs compelling, there are additional factors to consider, like application compatibility issues and service impact conditions. These could render RODC deployments unacceptable for certain environments.
For example, because many directory-enabled applications and services read data from AD DS, they should continue to function and work with an RODC. However, if certain applications require writable access at all times, an RODC may not be acceptable. RODCs also depend on network connectivity to a writable DC for write operations. Although failed write operations may be the cause of most well-known application-related issues, there are other issues to consider, such as inefficient or failed read operations, failed write-read-back operations, and general application failures associated with the RODC itself.
Besides application issues, fundamental user and computer operations can be affected when connectivity to a writable DC is disrupted or lost. For example, basic authentication services may fail if account passwords are not both cacheable and cached locally on the RODC. You can easily mitigate this issue by making accounts cacheable through an RODC's Password Replication Policy (PRP), and then caching the passwords through pre-population. Performing these steps also requires connectivity to a writable DC.
Along with other authentication issues, password expirations and account lockouts are significantly impacted when connectivity to a writable DC is unavailable. Password change requests and any attempts to manually unlock a locked account will continue to fail until connectivity to a writable DC is restored. Understanding these dependencies and subsequent changes in operational behavior is critical to ensuring your requirements and any service level agreements (SLAs).
There are several general scenarios in which you can deploy RODCs. They're useful in locations that don't have existing DCs, or in locations that currently host DCs that will either be replaced or upgraded to a newer version of Windows. Although there are comprehensive planning considerations specific to each scenario, we'll focus here on non-specific approaches. They are, however, distinct to RODCs, rather than to traditional writable DCs.
Preplanning
Before you start any formal RODC planning, you should conduct an appropriate level of due diligence and fundamental AD DS preplanning. This should include key tasks like validating the existing AD DS logical structure, and ensuring the administration model and the AD DS physical structure supports existing business and technical requirements. You'll also have to consider hardware requirements, software upgrade strategies, and applicable operating system known issues, and to evaluate RODC AD DS prerequisites. This information will be critical to the planning and deployment processes. You'll find it's well-documented in detailed deployment check lists.
Management Features
There's a substantial manageability feature in RODCs called Administrator Role Separation (ARS). This delegates to non-service administrators the ability to install and administer RODC servers, without granting Active Directory rights. This is a significant change to the traditional considerations with respect to DC server design, delegation of administration, and deployment procedures. This role separation becomes increasingly important with critical applications requiring direct installation on a DC, or for locations that host single, multi-purpose servers.
Additional Server Roles
As a general rule, you should eliminate from the server all roles not required for the RODC to function. Therefore, the only roles you should add to RODCs are the DNS and global catalog server roles. You should install the DNS server role on each RODC so local DNS clients can perform DNS resolution when network connectivity to a writable DC is unavailable. However, if the DNS server role is not installed through Dcpromo.exe, you'll have to install it afterward. You have to use Dnscmd.exe to enlist the RODC in the DNS application directory partitions that host the Active Directory integrated zones. You should also configure RODCs as global catalog servers so they can perform authentication and global catalog queries using just the RODC. From an authentication standpoint, if the global catalog role is not an option, you can use universal group caching. Successful authentication to an RODC may ultimately be dependent on the RODC's PRP configuration.
