Domain Controller is a new type of domain controller in Windows Server 2008 Operating System. Organizations can set up a domain controller in locations easily but the main problem faced is low physical security. RODC is an addition domain controller that hosts complete, read-only partitions of Active Directory Domain Services database and a read-only copy of SYSVOL contents.
Without Windows Server 2008, users from other locations had to be authenticated over wide area network if users want to access to domain controller. It is not an efficient solution. The physical security is low since all the users can access to writable domain controller. They can get information easily such as the users try to steal the confidential information since the information is store in a same domain controller. In addition, the network bandwidth will become poor when users are connected to the hub site.
So, Windows Server 2008 has released with a feature called RODC to address these problems. There are three main benefits of using RODC:
Get your grade
or your money back
using our Essay Writing Service!
The main purpose of read-only copies of Active Directory database and the SYSVOL shared folder work with unidirectional replication is to prevent malicious users make changes on a compromised read-only domain controller (RODC) from affecting the rest of the forest.
Read-Only Active Directory Database with Unidirectional Replication
An RODC holds all the Active Directory objects and attributes that a writable domain controller holds. Domain controller is replicating data by pulling in any changes made on other domain controllers. Inbound replication which is single threaded is used by domain controller. RODC will perform this inbound replication from the HUB site for Active Directory changes. RODC will receive all the information from Active Directory but not sensitive information such as Domain Admins, Enterprise Admins and Schema Admins are excluded from the replication.
Any request Read access to the directory can be succeed but request Write access not. Lightweight Directory Application Protocol (LDAP) applications that request Write access receive an LDAP referral response. This response will directs it to writable domain controller.
Domain controller can only pull update from one replication partner each moment. So, replication will become bottleneck if domain controller has a large number of replication partners. With RODC, the replication topology will be simplified and the load on the domain controllers in central locations will be reduced. Domain controller will not pull changes from RODCs. In the other words, domain controller can ignore RODCs when replicate changes.
The SYSVOL on RODC is read only and it is shared by domain controller. To make changes on the SYSVOL, the changes must be performed on the writable domain controller and then replicated to the RODC. There are two types of replications handle updates to SYSVOL on RODC which are File Replication Service (FRS) and Distribute File System (DFS) Replication. There are using different way to handle the updates on SYSVOL and DFS Replication is used at Windows Server 2008 domain functional level.
The reason Windows Server 2008 using DFS instead of FRS is because SYSVOL content on RODC is possible to become out of sync with domain controller. For example, if a delegated RODC administrator adds or deletes file or directory in the SYSVOL folder on RODC, the changes is not replicated from the RODC to other domain controllers. So, the contents of the SYSVOL folder are different from the contents of SYSVOL on other domain controller. These will affects computers might obtain unintended Group Policy objects or logon script.
So, we need to solve this problem if we using FRS. If we want to synchronize the contents of the SYSVOL folder again, we have to manually delete the file or directory that we add or we can make a change on a writable domain controller to force the file to replicate to the RODC if we delete a file or directory. But if we are using DFS Replication service, it will reverse all changes that have been made locally
RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC
RODC Filtered Attribute Set (FAS)
RODC Filtered Attribute is a dynamic set of attribute that is not replicated to any RODC in the forest. There attributes are not replicated because it contains sensitive data. The purpose for not replicate this attribute set is to prevent malicious user to expose these sensitive data. So, malicious user cannot be exposed unnecessary if RODC is stolen or compromised.
Always on Time
Marked to Standard
The default RODC FAS are as below:-
If we want to configure RODC FAS for security precaution purpose, we have to ensure that our forest functional level is Windows Server 2008. It is because if RODC tries to replicate those attributes from domain controller, the request will be denied if the forest functional level is Windows Server 2008. Else the replication request can be succeed.
The attributes that configured as a part of RODC will not present on RODC. So, RODC FAS data cannot be read although the RODC is stolen. We are recommended to mark attribute as part of RODC FAS if it is confidential. Marking it as confidential provides an additional safeguard against an RODC by removing the permissions to read the data.
For example, some application store data in Active Directory Domain Services (AD DS). These data may have credential-like data such as passwords, credentials, or encryption keys that do not want to store on an RODC. There are two ways to do for preventing replicate to RODC. The first solution is to extend the RODC FAS to include any credential-like attributes that do not want to replicate to RODC in the forest. The second step is marking the attributes as confidential as mentioned above. This will deny the ability to read the data include RODC. So, this can prevent attacker from using a compromised RODC to read the attribute even if they are not replicated to the RODC.
Credential caching is the storage of user or computer credentials. By default, RODC is not going to store any user credentials or credentials except for its own computer account and a special "krbtgt" account that each RODC has.
When users or computers in a site that is serviced by an RODC attempt to authenticate to the domain, RODC will forward the authentication request to writable domain controller. It is because RODC cannot validate their credential by default. Authentication request will be failed if there is no connectivity to the domain controller. So, RODC provides a solution to solve this problem which is call credential caching.
RODC can be configured to cache passwords which are handled by Password Replication Policy (PRP). PRP acts as an access control list (ACL). It determines whether an RODC is permitted to cache credentials for an account. If the user is allowed, then the credentials are cache on the RODC at login. If the account passwords are cache on RODC, it can authenticate those accounts when there is no connectivity to writable domain controller. If the password is not cache, RODC will forward authentication and caching request to writable domain controller. After domain controller authenticates the password, it will checks with PRP and determine whether the password can be cache or not. If the password is cached, RODC does not have to contact the writable domain controller and it can authenticate it by referring to the credentials cached.
Authentication Process with RODC
Computer account authentication using an RODC
Domain member computer must be authenticated by domain before access to the RODC. When computer accounts are located in sites that serviced by an RODC, they will attempt to authenticate through RODC. The following figure and steps describe the process that occurs when BKCOMPUTER authenticates to the domain for the first time.
Since RODC is advertised as the Kerberos Key Distribution Center (KDC) for the site, RODC1 is used as the KDC. The KDC is a network service that supplies session tickets and temporary session keys that are used in the KerberosÂ V5 authentication protocol.
Conclusion: BKCOMPUTER has a TGT that is signed with the domain key and its account credentials are cached on RODC1.
Administrator Role Separation
Administrator Role Separation (ARS) on a RODC is used to delegate RODC administration to a user who is not a member of Domain Admins group. With the used of RODC, domain administrator can delegate both installation and administration of RODC to any domain user. This delegation will not grant any additional rights besides the installation and administration. There are 2 purposes of using Administrator Role Separation which are RODC installation and RODC maintenance.
This Essay is
a Student's Work
This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.Examples of our work
After choosing which computer will be promoted as an RODC, domain administrator creates an account in the domain. During this process, domain administrator specifies that this created account will have the right to promote and administer the RODC in the PRP.
The delegated administrator for the RODC can log on to perform maintenance work such as upgrading a driver, perform off line defragmentation of disks and others. But this delegated administrator cannot log on to any other domain controller to perform administrative task. So, this can ensure that it will not compromise the security of the rest of domain.
Differences between an RODC and a Writable Domain Controller
Advantages of an RODC
RODC can replicate changes inbound is called unidirectional replication. Although there are changes on an RODC, there is no any domain controllers will replicate changes from an RODC. This kind of replication will improve security by restricting potentially malicious updates that can originate in a branch office.
Password Replication Policy (PRP)
Each RODC has a PRP that does not allow any password to be cached on the RODC by default. This helps to make sure that we can set up an RODC with a more secure security level. If configuration remains default and do not make any changes on PRP, no account and passwords can be obtained or cached on the RODC. In other words, only the trusted user will only encourage administrator to edit the PRP so that his/her account and passwords can be cached.
RODC filtered attribute set (FAS)
We can restrict the sensitive data so that it will not replicate to RODC. We can do it by adding attributes to the RODC FAS and marking them as confidential. Once it has been added and marked as confidential, that data cannot be exposed on RODC although RODC has been compromised or stolen.
Branch office server administration
RODC provides a feature called Administrator Role Separation which we can delegate administration of an RODC to a non-administrative user or group. This shows that RODC has good manageability. For example, a highly privileged administrator is not necessary to log on to the domain controller in the branch office to perform routine server maintenance. There will be some problems will be faced when we use ARS too. For example, hub site is link to the client side using wide area network. If the network is not available, the maintenance work cannot be done. So, we have to ensure that the PRP allows the delegated RODC administrator account password to be cached.
Branch office application administration
We can also deploy an RODC which fulfils special requirements that related to administering application in branch office. For example, line-of-business (LOB) application will be run on a domain controller in branch office. To administrate this application, owner has to log on to the domain controller or by Terminal Service. To solve this case, RODC provide a secure mechanism for granting non-administrative domain users to log on and perform administrative task without jeopardizing security of Active Directory Domain Services.
Writable domain controller will no pull any changes from an RODC and RODC will contain copies of partition of the Active Directory. So, setting up an RODC can reduce the number of domain controller in hub site. At the same time, the total number of connection objects that have to be created is also reduced. Besides, synchronization time for an enterprise is going to be reduced if we use RODC. Domain controllers in hub can replicate updates to a number of RODCs concurrently. This can help to replicate the security changes to RODCs more rapidly.
Prerequisites for Deploying an RODC
There are prerequisites to be complete before we deploy a read-only domain controller.
Ensure that the forest functional level is Windows Server 2003 or higher.
This will provides a higher level of replication consistency.
Run Adprep commands
These commands are to prepare the existing forest and domains for domain control that run Windows Server 2008.
Prepare forest by running adprep /forestprep
Prepare domain by running adprep /domainprep /gpprep
If installing an RODC in existing Windows Server 2003 domain, run adprep / rodcprep
Deploy at least one writable domain controller.
An RODC must replicate domain updates from a writable domain controller.
Peter Schmidt. (2008).Â Windows Server 2008 Domain Services - Part 1: Active Directory Domain Services.Â Available: http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2008-Domain-Services-Part1.html. Last accessed 3rd Dec 2010.