A read- only domain controller (RODC) is a new feature of Active Directory domain services (AD DS) in the Window Server 2008 operating system that makes it possible for organizations to easily deploy a domain controller in locations where the physical security of a domain controller cannot be guaranteed. An RODC hosts a read-only replica of the Active Directory services database for a given domain. Before the release of Window Server 2008, users who had to authenticate with a domain controller, but were in a branch office that could not provide adequate physical security for a domain controller, had to authenticate over a wide area network (WAN). In many cases, this was not an efficient solution. By placing a read-only Active Directory database replica closer to branch users, these users can benefit from faster logon times and more efficient access to authentication resources on the network, even in environments with inadequate physical security to deploy a traditional domain controller.
The main objective of the RODC is to improve security in branch offices. In branch offices, it is often hard to get the physical security needed for an IT infrastructure, especially for Domain Controllers that contain sensitive data. A DC can be found under a desk in the office. It is not hard to manipulate the system and get access to the data when by someone gets physical access to the DC. These issues can be solved by the RODCs.
Setting up the RODC
The setup process for the RODC is very easy and hardly distinguishable from the normal dcpromo process to add a domain controller - except for the single option to enable the RODC, as shown in Figure A.
Figure A
Figure A
Once the setup of the newly added RODC is complete, you need to reboot and then the system is ready to go with the configured role. Within Active Directory Users And Computers, the RODC type is shown in Figure B to designate its difference from other domain controllers.
Figure B
Figure B
Functionalities of Read-Only Domain Controllers
Read-Only AD DS Database
With the exception of passwords, a RODC contains the same objects and attributes that a writable domain controller holds. However, the Active Directory Domain Services database on an RODC is a read-only database. Read-only database is a fundamental security feature to mitigate risk in the event of compromision of an RODC. In the event that an RODC is compromised, an attacker would not be able to make 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). This is also a pivotal in situations where physical security cannot be guaranteed because gaining physical access to a writable domain controller can put entire forest at risk.
The RODC will perform normal inbound replication from the HUB site for Active Directory and DFS changes. Active Directory of the RODC will receive everything but not sensitive information, such as Domain Admins, Enterprise Admins and Schema Admins. They are excluded from the replication to RODC by default accounts. Therefore, 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. (Roggen, 2007)
If local application needs write access to Active Directory, RODC sends a Lightweight Directory Access Protocol (LDAP) referral response which automatically redirects the application to a writable domain controller normally in the main HUB site. The RODC is also capable of running the Global Catalog Role for faster logon if needed.
RODC filtered attribute set
By using Active Directory Domain Services for some application as a data store may have credential-like data such as passwords, credentials, or encryption keys that should not be stored on a Read-Only Domain Controller in case the RODC which is stolen or compromised. For these types of applications, user can add the attribute to the RODC filtered attribute set to prevent it from replicating to RODCs in the forest, and mark the attribute as confidential which removes the ability from members of the Authenticated Users group to read the data including any RODCs.
Steps to Add an Attribute to the RODC Filtered Attribute Set
For example, if the attribute that you want to add is indexed and no other bits are set, then the current searchflags value is 0x001 (or 1, as stated in decimal format). If you set the 10th bit of the attribute to 0x200 (512) and the 7th bit to 0x080 (128), the new searchFlags value is 0x281 (or 641). In the following procedure, which uses the Employee-Number attribute, no other bits are set for searchFlags, so the current value is 0.
Determine and then modify the current searchFlags value of an attribute
Click Start, right-click Command Prompt, and then click Run as administrator.
Type the following command, and then press ENTER:
ldifde -d CN=Employee-Number,CN=Schema,CN=Configuration,DC=<domain> -f en_ldif -l searchflags
Where <domain> is the distinguished name for your domain.
Verify that the output of the file named en_ldif appears as follows:
dn: CN=Employee-Number,CN=Schema,CN=Configuration,DC=<domain>
changetype: add
searchFlags: 0
Copy the contents of the output file to a new file named en-fas.ldif.
Modify the new file, en-fas.ldif, so that it appears as follows, and then save it:
dn: CN=Employee-Number,CN=Schema,CN=Configuration,DC=<domain>
changetype: modify
replace: searchFlags
searchFlags: 640
Type the following command, and then press ENTER to import the modified en-fas.ldif file:
ldifde -i -f en-fas.ldif
Verify the searchFlags value of the attribute
Use the following procedure to verify that an attribute is added to the RODC filtered attribute set.
Administrative Credentials
To perform this procedure, you can be any authenticated user.
To verify that an attribute is added to the RODC filtered attribute set
Click Start, click Administrative Tools, and then click ADSI Edit.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
Right-click ADSI Edit, and then click Connect to.
Click Select a well known Naming Context, click Schema and then click OK.
In the console tree, double-click Schema, and then click the CN=Schema,CN=Configuration,DC=<domain> container.
In the details pane, right-click CN=Employee-Number, and then click Properties.
In the list of attributes, verify that the Confidential and RODC_Filtered flags are set.
Unidirectional Replication
Replication to RODC
Since RODC contains a read-only database and the objects are not changed directly on it, an RODC will not initiate replication changes. Furthermore, no domain controller will pull replication changes from an RODC. As such, Active Directory Domain Services in Windows Server 2008 uses unidirectional replication for RODCs. RODCs will always receive updates for Active Directory Domain Services objects from a writable domain controller.
Unidirectional replication also applies to SYSVOL replication through the Distributed File System (DFS). This can help to reduce the number of domain controllers that to deploy in the hub site. The total number of connection objects that have to be created is also reduced by about half, because inbound connection objects do not have to be created on the hub domain controllers for each branch domain controller. Consequently, users do not have to plan for as much configuration of hub site Windows Server 2008 domain controllers as compared with Windows Server 2003 domain controllers. This can also help to reduce the end-to-end synchronization time for an enterprise. Writable domain controllers in the hub can be configured to replicate updates to a higher number of RODCs concurrently. This can help to implement security changes such as updates for fine-grained password policies or updates to the RODC FAS as more rapidly.
Credential Caching
RODCs have the ability to provide improved logon times by virtue of credential caching which is the storage of user and computer credentials. The Password Replication Policy for an RODC in a given branch office can be configured to cache the credentials of all users and computers that reside in that branch office. After one of these users or computers is successfully authenticated, the RODC will contact a writable domain controller to request a copy of appropriate credentials. If RODC's Password Replication Policy permits the caching of the credentials, RODC will cache the credentials and subsequently directly service that authentication requests until the credentials change.
In order to improve logon times, credential caching provides further security enhancements. RODC's Password Replication Policy permits credentials to be cached. The credential caching will not occur until the user or computer successfully authenticates against the RODC. This minimizes the cached credentials that are stored on RODCs. Furthermore, if an attacker gains access to an RODC, the attacker can only attempt to crack the cached credentials. Password Replication Policies are fully configurable. User can allow or deny the caching of passwords for users and computers by each RODC.
The benefit of Credential Caching is that is helps with password protection at branch offices and minimizes exposure of credentials, in case the RODC is compromised. When using Credential Caching and if an RODC is stolen, the user account and computer account can have their passwords reset, based on the RODC they belong to. Credential Caching can be left disabled and this will limit the eventual exposure, but it will also increase WAN traffic, since all authentication requests will be forwarded to the writeable DCs in the main HUB site.
Administrative Role Separation
Users can delegate local administrator permissions for the RODC server to any user in Active Directory. The delegated user account will now be able to log onto the server and do server maintenance tasks, without having any AD DS permissions and the user does not have access to other domain controllers in Active Directory. This way is not compromising the security of other domains.
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 users create the RODC account to 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 or UseExistingAccount. Attach at a command prompt to start the installation wizard.
An RODC deployment can be completed in two stages by different persons. User 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 Service. In addition to 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. Allow 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
In addition to the RODC, it's also possible to install a DNS service. An RODC is able to replicate unidirectional all DNS application directory partitions, including Forest DNS Zones and Domail DNS Zones. A DNS server running on an RODC doesn't support dynamic updates. But clients are able to use the DNS server to query for name resolution.
Since the DNS is Read-Only, clients cannot update records on it. But if a client wants to update its own DNS record, the RODC will send a referral forward to a writeable DNS. The single updated record will afterwards be replicated from the writable DNS server to the DNS server on the RODC. This is a special single object (DNS record) replication to keep the RODC DNS servers up-to-date and give the clients in the branch office faster name resolution.
RODC is limited in that it can only support a subset of the roles and functionality normally supported on window server 2008. For example, RODCs- based server can support for any of these technologies that interface with Active Directory Domain Service: ADFS, DNS, DHCP, FRS V1, DFSR (FRS V2), GP (Group Policy), IAS/VPN, DFS, SMS (System Manager Server), ADSI queries and MOM(Microsoft Operations Manager).
With Windows Server 2008, Active Directory Domain Services (AD DS) are now stoppable and restartable. This represent that user can stop the AD DS to perform tasks and maintenance, which in prior versions of Windows Server required a reboot into Directory Services Restore Mode (DSRM). This is an excellent feature for scripting and automating those tasks.
The possible states for AD DS are:
AD DS - started
AD DS - stopped
AD DS Restore Mode (DSRM)
It is a benefit that tasks that used to require a reboot to take the AD DS offline are now available directly from the console. This gives administrators some flexibility towards maintaining and performing offline AD DS operations more quickly.
Even though a RODC can replicate data (schema, configuration, application partitions, PAS-GC) from domain controllers running Windows Server 2003, it can only replicate data or 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 or available in the nearest site (lowest site-link cost) in the RODC topology.
Disadvantages of Windows Server 2008 Read-Only Domain Controller
There have been several different options for managing branch offices. One of the more common ways of dealing with branch offices is to keep all of the servers in the main office, and provide the branch office user connectivity to those servers through a WAN link. By using this method of the most obvious disadvantage to is if the WAN link goes down then the users who are in the branch office are unable to do much of anything, because they are completely cut off from all of the server resources. Even if the WAN link is functional though, productivity may suffer because the WAN links are often slow and easily congested. Another option for dealing with branch offices is to place at least one domain controller in the branch office. Often times, this domain controller will also act as a DNS server and as a global catalog server. That way if the WAN link goes down, the users in the branch office will at least be able to log into the network. Depending on the nature of the branch office user's jobs, there may also be other servers located at the branch office.
The second of disadvantage is the cost. By placing server in branch offices requires the organization to shell out money for server hardware and for any necessary software licenses. There are also support costs to consider. An organization needs to determine whether they want to hire full time IT staff to support the branch office or if they can deal with the amount of time that it takes the IT staff to travel from the main office to the branch office when onsite support is needed.
RODCs are just like any other domain controllers, except that the Active Directory database is not directly writable. Placing an RODC at a branch office does not get rid of Active Directory replication traffic, but it does reduce the workload of the bridgehead servers because only inbound replication traffic is allowed.
Therefore, RODCs may also improve security because people at the branch office cannot make any changes to the Active Directory database. Furthermore, no account information is replicated to RODCs. This means that if someone were to steal a RODC, they would not be able to use the information that they get off of it as a means for hacking user accounts. The fact that user account information is not written to RODCs also reduces the amount of replication traffic that flows across the WAN link, but it does mean that with some exceptions user authentication.
An RODC is an additional domain controller for a domain that hosts read-only partitions of the Active Directory database. An RODC is designed primarily to be deployed in a branch office environment. Branch offices typically have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and little local IT knowledge.
The following figure illustrates the RODC branch office environment.
