Understanding “Read Only Domain Controller” authentication

First published on TechNet on Jan 18, 2008

Hello there. Bob Drake here to discuss how Windows Server 2008 “Read Only Domain Controllers” (RODC’s) authenticate users differently from the way Windows Server 2003 and Windows Server 2008 standard domain controllers do. The “ Read Only Domain Controller ” is new to Windows Server 2008 and allows for the installation of a domain controller to accommodate common scenarios where users are authenticating over a wide area network (WAN) or there is a physical security concern for the domain controller, such as installations at branch office locations. Another new feature to Windows Server 2008 RODC’s is “ Password Replication Policy ” and depending on how they are configured determines how an RODC authenticates a user.

To understand the authentication difference between a standard domain controller and an RODC, we need to review the “ How interactive Logon works ” and “ Kerberos authentication ” TechNet articles. In the section Domain Login (How interactive logon works article), a user’s credentials are received by Winlogon and passed to the LSA (local security authority) which negotiates Kerberos and contacts the domain controller. The domain controller then returns the logon success to the local computers LSA which generates the user’s access token . The Kerberos authentication is seen in the following diagram (taken from the Kerberos authentication article):

To see the authentication on the wire, we would need to install a network capture application such as Netmon3.1 (or Wireshark , Ethereal , Packetyzer ). In the following network trace, we see a client machine authenticate to a domain controller and is granted access with the “KRB_AS_REP” and “KRB_TGS_REP”:

Now let’s take a look at the “ Password Replication Policies ” and how they affect the RODC authentication behavior. With the installation of an RODC, there are four new attributes and two built-in groups to support RODC 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 that 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 helps ensure that RODCs are secure by default.


• msDS-RevealedList. This attribute is a list of security principals whose passwords have ever 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.
  
  ------------------


• Allowed RODC Password Replication Group. This group is added to the msDS-Reveal-OnDemandGroup.


• Denied RODC Password Replication Group. This group is added to the msDS-NeverRevealGroup.

Note: The “Allowed RODC Password Replication Group” has no members by default, and the “Denied RODC Password Replication Group” contains all the ‘VIP’ accounts (Enterprise Administrators, Cert Publishers, Schema Administrators, Etc). As with most things, Deny always trumps Allow.

Using the commands for “ Repadmin.exe ” (this is built into Windows Server 2008) an administrator can modify the Password Replication Policy groups. To view the current PRP for a specified user:

Repadmin /prp view <RODC> {<List_Name >|<User>}

The following shows the settings for the groups on the RODC through several commands:

Awesome information here! We can see who is on the allowed list (msDS-RevealOnDemand), who is on the deny list (msDS-NeverRevealGroup), who is actually revealed (msDS-RevealedList) and who actually has authenticated to the RODC (msDS-AuthenticatedToAccountlist).

The configuration of a Password Replication Policy is pretty straight forward. Open Active Directory Users and Computers snap-in and select the RODC in the Domain Controllers organizational unit. On the “Password Replication Policy” tab, there are the two groups: “Allowed RODC Password Replication Group” and “Denied RODC Password Replication Group”. A user can be added to either of the desired groups.

Another really cool feature is the “Prepopulate the password cache for an RODC” button. This button (pictured) allows an administrator to pre-add users that will be authenticating to the RODC.

An administrator could also use the “ Repadmin ” utility to populate the password cache with the following command:

Repadmin /rodcpwdrepl [DSA_LIST] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished name> <User2 Distinguished Name>…].

The following shows the user “Ned Pyle” being added to the password cache using Repadmin:

So how does this affect the RODC? When a user authenticates to an RODC a check is performed to see if the password is cached. If the password is cached, the RODC will authenticate the user account locally. If the user’s password is not cached, then the RODC forwards the authentication request to a writable Windows Server 2008 Domain Controller which in turn authenticates the account and passes the authenticated request back to the RODC. Once the user account is authenticated, the RODC makes another request for the replication of the user’s password in a unidirectional replication providing the account has been configured to allow replication.

This finally brings us to seeing the difference in authentication. For the following NetMon 3.1 trace, I have configured a user account whose password has been denied replication to the RODC. The user authenticates to the RODC ( 2k3DOM2k8DC2 ) and the RODC forwards the request to the writable domain controller ( 2k3DOM2k8DC ). We see the extra traffic since the user’s password has not been cached:

For the last trace I have allowed the user password to be cached by configuring the Password Replication Policy. The user authentication is the same as above, with the exception to what the RODC does after authenticating the user. Now see the RODC make the request for the user’s password to be replicated, but in subsequent logins the password replication request would not be seen since it has been cached:

Note : If the Wide Area Network (WAN) is down and the user account and password has NOT been cached, then the user account will fail to authenticate.

To wrap it up, when a user account is not cached, the RODC forwards the authentication to a writable Domain Controller which does the authentication. If the Users password is allowed to be cached, then the RODC will pull that through a replication request. Once the user has been authenticated, and their password has been cached, any subsequent login can then be handled by the RODC alone. Some people may see an increase in Wide Area Network (WAN) traffic with the introduction to an RODC, but after caching user passwords there should be a significant reduction in traffic and a more secure environment. In my next blog I will discuss how account lockout thresholds affect this process and what Administrators might run into with them.

-Bob Drake