Lost in the noise over the release of the beta 3 build of Windows Server 2008 was this gem: the read-only domain controller, or RODC.
Created especially for branch offices or other environments where the physical security of the server cannot be guaranteed, or where applications must run on the domain controller as well, the RODC allows the domain admin to deploy a domain controller that hosts a read-only replica of the domain database. In other words, replication is unidirectional from the from the main DC(s) to the remote sites.
Prior to Windows Server 2008, remote users attempting to authenticate with a domain controller had to cross a WAN link in order to do so. The RODC allows for
Deploying a DC to the remote site was a way to mitigate this issue, but brought with it attendant problems, the least of which was the integrity of the physical server.
From TechNet:
What does the RODC do?
· Locally originating changes cannot be made to the replica stored on the RODC. Changes are instead made on a writable domain controller, and replicated downstream to the RODC, preventing made at branch locations from being committed immediately, potentially polluting or corrupting the forest via replication, thus eliminating one avenue of attack.
· Local applications that request read access to the domain directory information can obtain access directly from the RODC, while Lightweight Directory Access Protocol (LDAP) applications that request write access receive an LDAP referral response. This referral response directs them to a writable domain controller, normally in a hub site.
The RODC’s authentication sequence is as follows:
· The first time an account attempts to authenticate to an RODC, the RODC sends the request to a writable domain controller at the hub site. If the authentication is successful, the RODC also requests a copy of the appropriate credentials. The writable domain controller recognizes that the request is coming from an RODC and consults the Password Replication Policy that’s in effect for that RODC.
· The Password Replication Policy determines if the credentials are allowed to be replicated and stored on the RODC. If so, a writable domain controller sends the credentials to the RODC, and the RODC caches them, as shown in the sidebar “How a Read-Only Domain Controller Works.”
· After the credentials are cached on the RODC, the next time that user attempts to log on, the request can be directly serviced by the RODC until the credentials change. When a TGT is signed with the RODC’s own krbtgt account, krbtgt, the RODC recognizes that it has a cached copy of the credentials. If another DC has signed the TGT, the RODC will forward requests to a writable domain controller.
Note: By limiting credential caching only to users who have authenticated to the RODC, the potential exposure of credentials by a compromise of the RODC is also limited.
By default, no user passwords will be cached on an RODC, but that’s not necessarily the most efficient scenario. Normally, only a few domain users need to have credentials cached on any given RODC, compared with the total number of users in a domain. You can use the Password Replication Policy to specify which groups of users can even be considered for caching. For example, by limiting RODC caching to only users who are frequently at that branch office, or by preventing the caching of high-value credentials, such as administrators, you can reduce the potential exposure.
This is one aspect of Windows Server 2008 I think will benefit multiple-location administrators the most.
A step-by-step guide is here
Are you testing Windows Server and see a use for a RODC? Tell us here or email me at john.obeto@absolutevista.com.
Visit Microsoft Subnet for more opinons and news. http://www.networkworld.comhttps://www.networkworld.com//subnets/microsoft/
