Implementing Read Only Domain Controllers

A read only domain controller abbreviated as RODC is a form of domain controllers found in the windows 2008 server operating system. RODC helps businesses or organizations to set out a domain controller where there is not a guarantee of physical security. Their hosts can only read the Active Directory Domain Services: AD DS databases.  Windows server 2008 operating system came to solve some typical problems that were experienced by users since before then, users had to relay with a domain controller that was set out in over the internet or in a wide area network. This was not a viable solution since the offices located in branches of organizations could not provide total security needed for domain controllers. It is also known that when connected to a hub site, most branch networks have poor bandwidth connectivity. This in turn causes the logon process to be slow. This has also been seen to hinder access to resources located in the network.

When using windows server 2008, deployment of RODC can be done in order to address these issues. Consequently, users are able to receive the benefits of improved security, fast duration of logging in and most important, having a more efficient access to network resources. Since lack of adequate security physically is the core reason of considering the implementation of RODC, it therefore provides a manner which cannot guarantee security of a domain controller that is writeable, but it give a way of setting out a domain controller which has great security in areas that do require faster and authentication services that can be relied on. 

An organization may also opt for implementing RODC for specific administrative requirements. A good case is where an organization may opt to use line of business applications, in such a case these applications may only rum well only if they are installed on a domain controller or else the domain controller might be the only one in the branch server in any branch and hence it has to host server applications. In a situation like this managers or the directors must continuously be able to log in to this domain controller or they must then be forced to use other terminal services in order to either manage or configure these applications. This is an outstanding security risk which is not likely to be acceptable on a domain controller that is writeable.

In this instance, RODC gives a mechanism which is secure. It is also possible to non administrative domain users the rights to log in to the read only domain controller while on the same time reducing the chances of a security breach to the Active Directory forest. RODC can also be implemented in the case where local storage of all the domain user passwords is a threat. This is in a situation where extranet is being used or there is an application forcing role. In order to set out RODC, one domain controller which is writable must be present and it has to be running Windows Server 2008. It is also wise to note that the functioning level of both the forest and the domain must be that of windows 2008 server or of higher specifications.

RODC functionality is there to address problems that are mostly found in branch offices. These locations may not be having a domain controller. Or, there exists a writable domain controller but not the network bandwidth, physical security or local proficiency to support it. The RODC functions alleviate the following problems: Credential caching, Read-only AD DS database, separation of the role of the administrator; duplication which is unidirectional, and the read only Domain name systems.

In the Read-only AD DS database, RODC holds all the objects in the Active Directory and attributes that a writable domain controller hold but passwords for account, however, it is not possible to make changes to in a database that is stored on the read only domain controller. These changes must only be made on a domain controller that is writeable and then duplicated on to the RODC. Applications that are local, can obtain access. LDAP referral response is sent to the lightweight directory application protocol when it requests access to write. In turns they are directed to the writable domain controller and in most cases is a hub site.

RODC is known to possess filtered attribute set. For applications that have their data store as ADDS might have data which is credential like which may comprises encryption keys, passwords, and other credentials that the user does not want stored on the RODC if it is compromised. For such applications, it is possible to configure these attributes dynamically in a table for the domain objects that cannot replicate to an RODC. Such set of attributes is referred to as the RODC filtered attribute set. These attributes are not allowed to replicate in the forest. In RODC which is in the windows 2008 server is very good when it comes to issues of malicious users who can try to configure replication of attributes defined in the RODC since it counters then with access denied messages.  It is also not possible to add system-critical attributes to the RODC filtered attribute set. A system critical attribute is an attribute that is required by the Security Accounts Manager and the local security authority. However, system-critical attributes cannot be added to the Read-Only Domain Controller filtered attribute set. Further, it is critical to use an attribute in the system for the proper functioning of any AD DS; SAM- Security Accounts Manager, LSA - Local Security Authority or any Security Service Provider Interfaces that are dependent on Microsoft such as Kerberos. Normally, attributes that are system-critical entail schemaFlagsEx whose attribute value is set to 1 such that attribute value & 0x1 = TRUE).

The server that contains all master operations of the schema configures the RODC filtered attribute set. Therefore, a system-critical attribute cannot be added to the filtered set in the RODC as far as the schema master is still running in Windows Server 2008.  Otherwise, an LDAP error normally displayed as "unwillingToPerform" occurs. Further, an attempt to attach a system-critical attribute to the filtered attribute set of the RODC appears to be successful in the schema master when running Windows Server 2003. However, this attribute is in practice not added. Hence, it is highly recommended that in adding attributes to the RODC in its set of filtered attributes the schema master be a domain controller in a Windows Server 2008. This is vital in ensuring that these attributes that are system-critical are not added to the filtered set. s

Unidirectional replication

There are no changes or errors that occur at the RODC since changes are not directly written to the RODC. Hence, domain controllers which are replication partners are mot obligated to incorporate changes made in the RODC. This eliminates all chances of corruption originating from any branch users which may be malicious from replicating. Further, it reduces the workload assigned to bridgehead servers held in the hub and the associated monitoring of replication.

The unidirectional replication in the RODC is critical in DFS and AD DS whereby standard inbound duplication for AD DS and SYSVOL in the DFS takes place. However, any further DFS Replication configured in the RODC must be bidirectional.

Credential caching

This entails storing of all credentials be they from a user or the computer itself. Credentials are normally a set not exceeding ten 10 passwords under several security principals. No credentials are stored by the RODC under default settings with the exception of the RODC computer account and all special krbtgt accounts held by each RODC. All other credential caching must nonetheless be allowed.

The Key Distribution Center (KDC) is a advertising brand for the RODC in branch offices. A different and special krbtgt account and its associated password is used by the RODC other than that used by the KDC on the domain controller in signing or granting requests such as Ticket-granting ticket (TGT).

After successful authentication of an account, an attempt by the RODC is made to contact the hub site that holds the writable domain controller so as to request a copy of the suitable credentials. This request is recognized by the writable domain controller recognizes as emanating from the RODC hence a request is made to the Password Replication Policy. The PRP determines whether these credentials can be replicated to the RODC from the writable domain controller. If the request is valid, the domain controller replicates this credentials which are then cached by the RODC. This allows service to the user's log-on demands till changes are effected. This limits any resultant exposure of user's credentials since only those users that have been authenticated have access. In addition, few credentials can be cached in any RODC hence in the event of loss or theft; few credentials can be compromised in event of cracking. Any such events can be eliminated by disabling the cache. However, in such a case, all requests for authentication are forwarded to the writable domain controller. Hence, an administrator should modify the PRP to allow the RODC to cache credentials.

Administrator role separation

It is possible to delegate authority of access for any RODC to all domain users without in effect granting rights for that domain or any domain controllers. This is vital in allowing update of drivers in any local branch via logging in to any RODC for maintenance. This branch user has no access to the domain controller whereby the user could change any settings or perform any malicious tasks otherwise performed rightfully by the administrator in that domain. Hence, effective management of the RODC can take place at the branch office without any compromise to the overall security of the domain.

Read-only DNS

It is possible to install a DNS server on any RODC. This is since all directory partitions that this application uses can be replicated by the RODC such as the DomainDNSZones and the crucial ForestDNSZones. When the DNS server is installed on any RODC, a query for the name resolution can be placed just as in other DNS servers with the only de-merit being that the direct customer updates are not supported.  

Changes in Settings:

In support of the RODC PRP (Password Replication Policy), new attributes are included in the 2008 Windows Server.  These AD DS attributes that have been added in the Active Directory schema so as to provide support RODCs are msDS-RevealedList, msDS-Reveal-OnDemandGroup msDS-AuthenticatedToAccountList and the msDS-NeverRevealGroup

Deploying the feature

Several prerequisites are necessary in deploying this feature: First, the RODC forwards any requests for authentication to a writable domain controller which must be running on a 2008 Windows Server. The PRP then determines whether replication is valid to the branch location where the credentials are required. Secondly, Windows Server 2003  or higher domain functional level  is desired so as to avail Kerberos constrained delegation which is vital for all calls that must be impersonated as desired by the caller. Thirdly, a 2003 Windows Server is desired for the forest functional level so as to enable linked-value replication. This is vital in the provision of a high level replication consistency. Finally, it is compulsory to run adprep /rodcprep at least once in the forest so as to update all permissions on all partitions on the DNS application directory. This enables all RODCs that also serve as DNS servers replicate such permissions without failure.