RODC Frequently Asked Questions

Updated: May 1, 2009

Applies To: Windows Server 2008
This section includes frequently asked questions (FAQ) and answers pertaining to readonly domain controllers (RODCs). The questions range from general background
information to in-depth technical issues.
What new attributes support the RODC Password Replication Policy?
Password Replication Policy is the mechanism for determining whether a user or
computer's credentials are allowed to replicate from a writable domain controller to an
RODC. The Password Replication Policy is always set on a writable domain controller
running Windows Server 2008.
The following attributes have been added to the Active Directory schema to expedite the
functionality that is required for RODC caching operations:

msDS-Reveal-OnDemandGroup. This attribute points to the distinguished name

(DN) of the Allowed List. The credentials of the members of the Allowed List are
permitted to replicate to the RODC.

msDS-NeverRevealGroup. This attribute points to the distinguished names of

security principals whose credentials are denied replication to the RODC. This
has no impact on the ability of these security principals to authenticate using the
RODC. The RODC never caches the credentials of the members of the Denied
List. A default list of security principals whose credentials are denied replication
to the RODC is provided. This improves the security of RODCs that are deployed
with default settings.
msDS-RevealedList. This attribute is a list of security principals whose current
passwords have been replicated to the RODC.
msDS-AuthenticatedToAccountList. This attribute contains a list of security
principals in the local domain that have authenticated to the RODC. The purpose
of the attribute is to help an administrator determine which computers and users
are using the RODC for logon. This enables the administrator to refine the
Password Replication Policy for the RODC.

How can you clear a password that is cached on an RODC?

There is no mechanism to erase passwords after they are cached on an RODC. If you
want to clear a password that is stored on an RODC, an administrator should reset the
password in the hub site. This way, the password that is cached in the branch will no
longer be valid for accessing any resources in the hub site or other branches. In the
branch that contains the RODC on which the password may have been compromised, the

password will still be valid for authentication purposes until the next replication cycle, at
which time its value that is stored on the RODC will be changed to Null. The new
password will be cached only after the user authenticates with itor the new password is
prepopulated on the RODCand if the PRP has not been changed.
In the event that an RODC is compromised, you should reset the passwords for all
accounts that have cached passwords and then rebuild the RODC.
Can an RODC replicate to other RODCs?
No, an RODC can only replicate from a writable Windows Server 2008 domain
controller. In addition, two RODCs for the same domain in the same site do not share
cached credentials. You can deploy multiple RODCs for the same domain in the same
site, but it can lead to inconsistent logon experiences for users if the WAN to the
writeable domain controller in a hub site is offline. This is because the credentials for a
user might be cached on one RODC but not the other. If the WAN to a writable domain
controller is offline and the user tries to authenticate with an RODC that does not have
the users credentials cached, then the logon attempt will fail.
What operations fail if the WAN is offline, but the RODC is online in the branch
office?
If the RODC cannot connect to a writable domain controller running Windows
Server 2008 in the hub, the following branch office operations fail:

Password changes

Attempts to join a computer to a domain

Computer rename
Authentication attempts for accounts whose credentials are not cached on the
RODC
Group Policy updates that an administrator might attempt by running the
gpupdate /force command

What operations succeed if the WAN is offline, but the RODC is online in the
branch office?
If the RODC cannot connect to a writable domain controller running Windows
Server 2008 in the hub, the following branch office operations succeed:

Authentication and logon attempts, if the credentials for the resource and the
requestor are already cached.

Local RODC server administration performed by a delegated RODC server

administrator.

Will RODC support my Active Directoryintegrated application?

Yes, RODC supports an Active Directoryintegrated application if the application
conforms to the following rules:

If the application performs write operations, it must support referrals (enabled by

default on clients).

The application must tolerate Write outages when the hub is offline.

Does an RODC contain all of the objects and attributes that a writable domain
controller contains?
Yes, an RODC contains all the objects that a writable domain controller contains. If you
compare the LDAP store on a writable domain controller to the LDAP store of an RODC,
they are identical, except that the RODC does not contain all of the credentials or
attributes that are defined in the RODC filtered attribute set.
Why does the RODC not have a relative ID (RID) pool?
All writable domain controllers can allocate RIDs from their respective RID pools to
create security principals as needed. Because an RODC cannot create security principals,
it cannot provide any RIDs, and it is never allocated a RID pool.
Can I list the krbtgt account that is used by each RODC in the domain?
Yes. To list the krbtgt account that is used by each RODC in the domain, type the
following command at a command line, and then press ENTER:
Repadmin /showattr <WritableDcName> <distinguished name of the domain partition>
/subtree /filter:"(&(objectclass=computer)(msDS-Krbtgtlink=*))" /atts:msDSkrbtgtlink
How does the client DNS update referral mechanism work?
Because the DNS server that runs on an RODC cannot directly register client updates, it
has to refer the client to a DNS server that hosts a primary or Active Directory-integrated
copy of the zone file. This server is sometimes referred to as a "writable DNS server."
When a client presents a Find Authoritative Query, which is the precursor to an update
request, the DNS server on the RODC uses the domain controller Locator to find domain
controllers in the closest site.
The RODC then compares the list of domain controllers that is returned with the list of
name server (NS) resource records that it has. The RODC returns to the client the NS
resource record of a writable DNS server that the client can use to perform the update.
The client can then perform its update.

If no domain controller in the closest site matches an entry in the list of NS records for
the zone, the RODC attempts to discover any domain controller in the forest that matches
an entry in the list.
Suppose that a new client is introduced to a site that has a DNS server running only on an
RODC. In this case, the RODC DNS server tries to replicate the DNS record that the
client has tried to update on the writable DNS server. This occurs approximately five
minutes after the RODC provides a response to the original Find Authoritative Query.
If the DNS client on the RODC attempts a DNS update, a writable domain controller
running Windows Server 2008 is returned so that the RODC can perform the update.
Why doesn't the KCC on writable domain controllers try to build connections from
an RODC?
To build the replication topology, the Knowledge Consistency Checker (KCC) examines
the following:

All the sites that contain domain controllers

The directory partitions that each domain controller holds

The cost that is associated with the site links to build a least-cost spanning tree

The KCC determines if there is a domain controller in a site by querying AD DS for

objects of the NTDS-DSA categorythe objectcategory attribute value of the NTDS
Settings object. The NTDS Settings objects for RODCs do not have this object category.
Instead, they support a new objectcategory value named NTDS-DSA-RO.
As a result, the KCCs on writable domain controllers never consider an RODC as part of
the replication topology. This is because the NTDS Settings objects are not returned in
the query.
However, the KCC on an RODC also needs to consider the local domain controller
(itself) to be part of the replication topology to build inbound connection objects. This is
achieved by a minor logic change to the algorithm that the KCC uses on all domain
controllers running Windows Server 2008 that forces it to add the NTDS Settings object
of the local domain controller to the list of potential domain controllers in the topology.
This makes it possible for the KCC on an RODC to add itself to the topology. However,
the KCC on an RODC does not add any other RODCs to the list of domain controllers
that it generates.
How does the KCC build inbound connections locally on an RODC when the RODC
is supposed to be read-only?

An RODC is completely read-only from the perspective of external clients, but it can
internally originate changes for a limited set of objects. It permits replicated write
operations and a limited set of originating write operations.
Both the KCC and the replication engine are special writers on an RODC. The
replication engine performs replicated write operations on an RODC in exactly the same
way as it does on the read-only partitions of a global catalog server that runs
Windows Server 2003. The KCC is permitted to perform originating write operations of
the objects that are required to perform Active Directory replication, such as connection
objects.
Why does an RODC have two inbound connection objects?
This is because File Replication Service (FRS) requires its own pair of connection objects
in order to function correctly.
In previous versions of Windows Server, FRS was able to utilize the existing connection
objects between two domain controllers to support its replication of SYSVOL content.
However, because an RODC only performs inbound replication of Active Directory data,
a reciprocal connection object on the writable replication partner is not needed.
Consequently, the Active Directory Domain Services Installation Wizard generates a
special pair of connection objects to support FRS replication of SYSVOL when you
install an RODC. The FRS connection objects are not required by DFS Replication.
How does RODC connection failover work?
If the bridgehead replication partner of an RODC becomes unavailable, the KCC on the
RODC builds a connection to another partner. By default, this happens after about two
hours, which is the same for a writable domain controller. However, the FRS connection
object on an RODC must use the same target as the connection object that the KCC
generates on the RODC for Active Directory replication. To achieve this, the fromServer
value on the two connections is synchronized.
However, the trigger for changing the fromServer value on the FRS connection object is
not the creation of the new connection; instead, it is the removal of the old connection.
The removal step happens some hours after the new connection object is created.
Consequently, the fromServer value continues to reference the original partner until the
old connection is removed by the KCC.
A side effect of this is that while Active Directory replication works successfully against
the new partner, FRS replication fails during this period. The additional delay is by
designit avoids causing FRS to perform an expensive VVJoin operation against the
new partner, which is unnecessary if the outage of the original partner is only temporary.
How can an administrator delete a connection object locally on an RODC?

The KCC on an RODC will build inbound connection objects for Active Directory
replication. These objects cannot be seen on other writeable domain controllers because
they are not replicated from the RODC.
You cannot use the Active Directory Sites and Services snap-in to remove these
connection objects, but you can use Ldp.exe or Adsiedit.msc. The KCC on the RODC
will then rebuild a connection.
This way, you can trigger redistribution of connection objects across a set of RODCs that
have site links to a single hub site that has multiple bridgehead servers.
How can an administrator trigger replication to an RODC?
You can use the following methods:
1. By running the repadmin /replicate or repadmin /syncall operations.
2. By using the Active Directory Sites and Services snap-in. In this case, you can
right-click the connection object and click Replicate Now.
3. You can use Active Directory Sites and Services on a writable domain controller
to create an inbound replication connection object on any domain controller,
including an RODC, even if no inbound connection exists on the domain
controller.
This is similar to running a repadmin /add operation.
How are writable directory partitions differentiated from read-only directory
partitions?
This comes from an attribute on the directory partition head called instancetype. This is a
bit mask. If bit 3 (0x4) is set, the directory partition is writable. If the bit is not set, the
directory partition is read only.
Why can an RODC only replicate the domain directory partition from a domain
controller running Windows Server 2008 in the same domain?
This is how the filtering of secrets is enforced during inbound replication to an RODC. A
domain controller running Windows Server 2008 is programmed not to send secret
material to an RODC during replication, unless the Password Replication Policy permits
it. Because a domain controller running Windows Server 2003 has no concept of the
Password Replication Policy, it sends all secrets, regardless of whether they are
permitted.
How does the KCC differentiate between domain controllers running
Windows Server 2003 and domain controllers running Windows Server 2008?

The NTDS-DSA object has an msDS-Behavior-Version attribute. A value of 2 indicates

that the domain controller is running Windows Server 2003. A value of 3 indicates that it
is running Windows Server 2008.
Why are built-in groups such as Account Operators and Server Operators specified
separately in the Denied List attribute, but not in the Denied RODC Password
Replication Group?
The Allowed RODC Password Replication Group and the Denied RODC Password
Replication Group are domain local groups. Domain local groups cannot contain built-in
groups.
What actually happens when you add a user to an Administrator Role Separation
role?
The configuration adds entries to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\control\lsa\rodcroles

Name: 544

Data type: REG_MULTI_SZ

Value: S-1-5-21-760266474-1386482297-4237089879-1107

The role is denoted by the entry name544, for example, is the well known RID for the
builtin\administrators group. Then, each value represents the security identifier (SID) of a
user who has been assigned to the role.
How can an administrator determine the closest site for any given site?

Look at the site link costs that appear in Active Directory Sites and Services.
-or-

After an RODC is installed successfully in an Active Directory site, run the nltest
command against the RODC.

The following example shows the command and the results:

C:\>nltest /dsgetdc:rodc /server:rodc-dc-02 /try_next_closest_site /avoidself
DC: \\HUB-DC-01
Address: \\2001:4898:28:4:5e1:903a:7987:eea5
Dom Guid: 00e80237-c5ce-4143-b0b8-cfa5c83a5654

Dom Name: RODC

Forest Name: rodc.nttest.contoso.com
Dc Site Name: Hub
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE
DNS_FOREST CLOSE_SITE FULL_SECRET
The command completed successfully
Why does %logonserver% have the name of a domain controller in my hub site
rather than the RODC in my site?
If your user account password cannot be replicated to the RODC in your site or if the
RODC does not currently have your password, the Kerberos AS_REQ is forwarded to a
hub domain controller that provides your TGT.
The process that updates the environment variables uses the hub domain controller as the
logon server for the environment variable. The %logonserver% environment variable is
not updated for the duration of that logon session, even though the user is forced to
reauthenticate against the RODC.
What relevant RODC event log entries are there?
If an RODC attempts a Replicate Single Object (RSO) operation to cache a password that
the Password Replication Policy prevents from replicating to the RODC, the hub domain
controller that the RODC contacts logs event ID 1699.
The details for event ID 1699 include:
Log Name: Directory Service
Source: NTDS Replication
Date: 5/2/2006 2:37:39 PM
Event ID: 1699
Task Category: Replication
Level: Error
Keywords: Classic
User: RODC\RODC-DC-02$

Computer: HUB-DC-01
Description:
This directory service failed to retrieve the changes requested for the following directory
partition. As a result, it was unable to send change requests to the directory service at the
following network address.
Directory partition:
CN=test10,OU=Branch1,OU=Branches,DC=rodc,DC=nttest,DC=contoso,DC=com
Network address:
c6ef8d14-f015-4cd0-94cc-c7f5c9c834ba._msdcs.rodc.nttest.contoso.com
Extended request code:
7
Additional Data
Error value:
8453 Replication access was denied.
A successful logon logs event ID 4768 on the hub domain controller and on the RODC.
The details of event ID 4768 on the hub domain controller include the following:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 5/2/2006 3:58:05 PM
Event ID: 4768
Task Category: Kerberos Ticket Events
Level: Information
Keywords: Audit Success
User: N/A

Computer: hub-dc-01.rodc.nttest.contoso.com
Description:
Authentication Ticket Request:
Account Name: test10
Supplied Realm Name: RODC
User ID: S-1-5-21-3503915162-2421288034-2003080229-1128
Service Name: krbtgt
Service ID: S-1-5-21-3503915162-2421288034-2003080229-502
Ticket Options: 0x40810010
Result Code: 0x0
Ticket Encryption Type: 0x17
Pre-Authentication Type: 2
Client Address: 2001:4898:28:4:6182:4acd:65c9:283a
Client Port: 55763
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
At the default Event log settings, no replication event shows that the password has
replicated to the RODC.
Password changes are not always "chained" by an RODC. Why?
Some password-change operations, such as a user initiating a password-change request
by pressing Ctrl+Alt+Del, specifically require a writable domain controller. When the
client computer detects that the RODC is not writable, it locates a writable domain
controller instead. Other password-change operations, such as a user's password expiring
and when the user is prompted to change it at logon, do not specifically require a writable
domain controller.

How does a hub domain controller recognize that a request to replicate a password
is coming from an RODC?
The RODC does a bind and calls the "replicate single object" application programming
interface (API). The binding handle shows that it is an RODC account.
Why does an RODC replicate in a cached password both by RSO operation and
normal replication?
When a single object is replicated to the RODC in the branch site, the update sequence
number (USN) and the high-water mark are not updated. As a result, the object is
replicated to the branch site again at a later time.
Does an RODC perform password validation forwarding even when it has a
password for a user?
Yes, in the case where a user presents a password that does not match what the RODC
has stored locally, the RODC will forward the authentication request. The RODC
forwards the request to the writable Windows Server 2008 domain controller that is its
replication partner, which in turn forwards the request to the PDC emulator if required. If
the authentication is validated at the writable Windows Server 2008 domain controller or
the PDC emulator, the RODC will purge the currently stored password and replicate the
new password by RSO operation.
Can you remove the last domain controller in a domain if there are unoccupied (or
disabled) RODC accounts in the domain?
As for all previous versions of Windows Server, it is a requirement that all other domain
controllers have been removed from the domain before you can remove the last domain
controller. For Windows Server 2008, this requirement includes the removal of all
RODCs and the removal of any precreated but unused RODC accounts.