Tag Archive: RODC

Attacking and securing a RODC:



How to delegate RODC administration:

from the ADUC, select the RODC computer object, ManagedBy tab (select user of group)


What are the tasks to do to manage a RODC in branch office:







Here are collection of web articles to troubleshoot a RODC:

Introduction: http://technet.microsoft.com/en-us/library/cc732801(WS.10).aspx

Read-Only Domain Controller Planning and Deployment Guide: http://technet.microsoft.com/en-us/library/cc771744(v=ws.10).aspx

AND also: http://technet.microsoft.com/en-us/library/cc754956(WS.10).aspx AND step-by-step: http://technet.microsoft.com/en-us/library/cc772234(v=ws.10).aspx

On branch office with RODC and client computers running XP or W2k3 servers, apply the patches here: http://support.microsoft.com/kb/944043




In French the article from Benoit Sautiere: http://blogcastrepository.com/blogs/benoits/archive/2009/10/19/quelques-subtilit-233-s-autour-du-rodc.aspx

AD DS RODC: http://technet.microsoft.com/en-us/library/cc732801(WS.10).aspx

Montoring – Password Replication Policy Administration: http://technet.microsoft.com/en-us/library/cc753470(WS.10).aspx

Understanding RODC authentication: http://blogs.technet.com/b/askds/archive/2008/01/18/understanding-read-only-domain-controller-authentication.aspx

RODC pre-populating passwords

The two traditional means for pre-populating passwords has some limitations. Currently, using the Active Directory Users and Computers console or the repadmin command does not allow for the usage of security groups.

Because pre-populating passwords one account at a time or in small batches based on organizational units may not be practical, you can use security groups in a scripted manner. For instance, in order to utilize the same security group that authorizes credential caching on a particular RODC, the following may be used:

For /F %%a in (‘”dsquery group dc=mycompany,dc=com -name <Groupname>| dsget group -members”‘) do (Repadmin /rodcpwdrepl <RODCname> <RWDCname> %%a)

Montoring – Password Replication Policy Administration: http://technet.microsoft.com/en-us/library/cc753470(WS.10).aspx

The name “read-only domain controller” implies that its database is read-only, and it is in nearly all situations, except for one group of attributes.

If a user requests a write operation to an RODC, the RODC forwards the request to a read-writable domain controller (RWDC), which then replicates the changes back to the RODC.

If an application tries to write to an RODC, the RODC responds with a referral notifying the application that it needs to write to an RWDC (which will crash some applications that don’t handle referrals).

Now, imagine that you have a branch-location RODC that loses its hub connectivity, so it can’t contact an RWDC, and during this outage, someone tries to hack an account.

With normal connectivity, the BadPwdCount would increment, and, after a password-policy designated number of attempts, the account would lock out.

If the RWDC can’t be contacted, and the RODC can’t write to its database, the BadPwdCount would never increment and the account would never lock out, leaving the RODC vulnerable.

For this reason, an RODC can write logon-count attributes—such as BadPwdCount and LastLogon—to its database, allowing an account to lock out.

Note from the fields: When the WAN is offline, an RODC can authenticate only the users and resources for which it has cached passwords. If you have a strong
requirement that any user must be able to authenticate in the branch office location, you may want to place a writable domain controller at that branch
office location. As an alternative, you can place an RODC at the branch office location and configure the RODC so that all users’ credentials are allowed to
replicate to it. You can then have an automated process in place that caches the credentials of the users, computers, and other resources that are located
in the branch office. This way, you can take advantage of other RODC features.