RODC Frequently Asked Questions
Updated: May 1, 2009
Applies To: Windows Server 2008
This section includes frequently asked questions (FAQ) and answers pertaining to read-only 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 it—or the new password is prepopulated on the RODC—and 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 user’s 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 Directory–integrated application?
Yes, RODC supports an Active Directory–integrated 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
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 category—the 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 design—it 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:
By running the repadmin /replicate or repadmin /syncall operations.
By using the Active Directory Sites and Services snap-in. In this case, you can right-click the connection object and click Replicate Now.
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 name—544, 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.
