Active Directory Domain Services: RODC (Read-Only Domain Controller)

Refer: http://trycatch.be/
A read-only domain controller (RODC) is a new type of domain controller in the Windows Server 2008 operating system.  An RODC provides the ability to easily deploy a domain controller that hosts a read-only replica of the domain database/partition.  The Read-Only Domain Controller (RODC) is primarily targeted towards branch offices or edge sites, where physical security cannot be guaranteed. 

The RODC brings a read-only AD database, unidirectional replication, credential caching and administrator role separation and read-only DNS.  

Read-only Active Directory database

An RODC holds all the Microsoft Active Directory Domain Services (AD DS) objects and attributes that a writable domain controller holds.  However, clients are not able to write changes directly to the RODC.  This means that changes that a malicious user makes at branch locations cannot corrupt the forest (because they are not replicated back: unidirectional). 
Local applications requesting Read access to the directory obtain access, whereas Lightweight Directory Access Protocol (LDAP) applications performing a Write operation are referred/forwarded to a writable domain controller in a hub site.

Unidirectional replication

Because no changes are written directly to the RODC, and therefore no changes originate from the RODC, writable domain controllers that are replication partners do not have to pull changes from the RODC.  This also reduces the workload of bridgehead servers in the hub site(s).

RODC unidirectional replication also applies to both Active Directory and Distributed File System Replication (both FRS and/or DFS-R).  The RODC performs normal inbound replication for AD DS and Distributed File System Replication changes.

As I mentioned above, a RODC holds the same objects and attributes as a writable domain controller holds.
However, locally originating changes are not made to the RODC replica itself; instead, these changes are made on a writable domain controller and then replicated back to the RODC.  This prevents malicious changes made at branch locations from potentially polluting or corrupting the AD forest via replication.

If some security concerns/reasons, you don't want all attributes to be available on RODCs, you can dynamically configure a set of attributes in the schema for domain objects that will not replicate to an RODC.  This set of attributes is called the RODC filtered attribute set.  Attributes that are defined in the RODC filtered attribute set are not allowed to replicate to any RODCs in the forest (schema level).

RODCs do not store any passwords, by default.  This way, if the RODC is compromised, an administrator doesn’t have to worry about someone gaining access to the entire network using the information stored on that server.  This addresses the lack of (physical) security that can occur at branch offices.

Credential Caching 

RODC also uses credential caching.  Credential caching is the storage of user and/or computer computer credentials.  The exceptions are the credentials on the RODC, consisting of 10 passwords that are associated with the security principals.
By default, a RODC does not store any user or computer account of the RODC and a special krbtgt account that each RODC has.  Credential caching must be explicitly configured through a Password Replication Policy on the RODC computer object.

So, the first time a user attempts to authenticate to an RODC, the RODC forwards the request to a writable domain controller.  If the authentication is successful, the RODC also requests a copy of the user credentials.  The Password Replication Policy determines if the credentials are allowed to be replicated and cached on the RODC.  If the credentials are cached, the next time that user attempts to log on, the request can be directly serviced by the RODC until it is subsequently notified, through replication of a credential change.

As mentioned above, each RODC has its own "special" and dedicated KDC KrbTGT account - this is the account that issues Kerberos tickets.  The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests.  It provides cryptographic isolation (in case password are compromised and/or account has to be removed). 

When a TGT is signed with the krbtgt account of the RODC, the RODC recognizes that it has a cached copy of the credentials.  If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.

Administrator Role Separation

With Role Separation you can delegate the local administrator role of an RODC to any domain user without granting that user any user rights for the domain or other domain controllers (!!).  This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver.  However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain.  In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain.


So, a member of the Domain Admins group will create an RODC account by using the Active Directory Users and Computers snap-in.  Right-click the Domain Controllers OU and click Pre-create Read-only Domain Controller account to launch the wizard and create the account.  When you create the RODC account, you can delegate the installation and administration of the RODC to a user or better a security group.
On the server that will become the RODC, the user who has been delegated the permissions to install and administer it can then run dcpromo /UseExistingAccount:Attach at a command prompt to start the installation wizard. 

An RODC deployment, can be completed in two stages by different persons.  You can use the Active Directory Domain Services Installation Wizard to complete each stage of the installation.

The first stage of the installation creates an account for the RODC (pre-staging) in Active Directory Domain Services.
The second stage of the installation attaches the actual server that will be the RODC to the computer account/object that was previously created for it.

During this first stage, the "AD installation wizard" records all data about the RODC that will be stored in the distributed Active Directory database, such as its domain controller account name, database and log file location and the site in which it will be placed.
This stage must be performed by a member of the Domain Admins group.
The user who creates the RODC account can also specify at that time which users or groups can complete the next stage of the installation.

The second stage of the installation can be performed by any user/group who was delegated the right to complete the installation when the computer account was created.  This stage does not require any membership in built-in groups such as the Domain Admins group. 
If the user who creates the RODC account does not specify any delegate to complete the installation (and administer the RODC), only a member of the Domain Admins or Enterprise Admins groups can complete the installation.

Read-only DNS

You can install the DNS Server service on an RODC.  An RODC is able to replicate (unidrectional) all DNS application directory partitions, including ForestDNSZones and DomainDNSZones.  If the DNS server is installed on an RODC, clients can query it for name resolution as they query any other DNS server.
However, the DNS server on an RODC does not support client (dynamic) updates directly.  Consequently, the RODC does not register name server (NS) resource records for any Active Directory–integrated zone that it hosts.

RODCs provide support for any of these technologies that interface with Active Directory Domain Services: ADFS, DNS, DHCP, FRS V1, DFSR (FRS V2), Group Policy, IAS/VPN, DFS, SMS, ADSI queries, and MOM.

Deploying RODCs

RODCs do work in an existing Windows Server 2003 environment.  However, a Windows Server 2003 forest functionality level is required (for Kerberos constrained delegation and link value replication).  The FSMO PDCe role is not required to be Windows Server 2008 to support RODCs (located in the hub site), but preferably is.  Preferably also have multiple writable Windows Server 2008 DCs to distribute the load of multiple pulling RODCs. 
Also run adprep /rodcprep once in the forest to update the permissions on all the DNS application directory partitions in the forest.  This way, all RODCs that are also DNS servers can replicate successfully.

The Windows Server 2008 PDCe FSMO role is also responsible for creating the new KrbTGT account for the RODCs.

NOTE: Eventhough a RODC can replicate data (schema, configuration, application partitions, PAS-GC) from domain controllers running Windows Server 2003, it can only replicate data/updates of the domain partition from a domain controller running Windows Server 2008.
For this reason, a writable Windows Server 2008 based domain controller should be placed/available in the nearest site (read: lowest site-link cost) in the RODC topology.

More information: Step-by-step Guide Read Only Domain Controller