Understanding “Read Only Domain Controller” authentication

  • Artigo

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):

clip_image002

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”:

clip_image004

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:

clip_image006

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-inand 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.

clip_image008

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:

clip_image010

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:

clip_image012

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:

clip_image014

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

Comments

  • Anonymous
    January 18, 2008
    PingBack from http://susanneurich.wordpress.com/2008/01/18/w2k8-doku-uber-read-only-dcs/

  • Anonymous
    January 18, 2008
    Great post ! You sum up all existing information and show the PROOF of what was said on the RODC. [ sorry but i'm now used to reading incorrect or erroneous statements on the technet or KB articles. I've been in a technical support team for several years. ] My current client was only pondering this question to decide on their RODC implementation in the year to come : "What will be the effect of bringing an RODC in my branch sites with dial-up-like bandwidth ?" You finally bring the answer MS ought to give us in the "corp" documentation... Thanks :)

  • Anonymous
    January 21, 2008
    Hello there. Bob Drake here to discuss how Windows Server 2008 “Read Only Domain Controllers” (RODC’s

  • Anonymous
    February 16, 2008
    Excellent Post! I have one question rearding auhtentication: After the RODC has authenticated a user over the WAN, does it "cache" the authenticated credentials in volatile RAM? So that further requests for the same account can be serviced without contacting a writable DC over the WAN? Thanks Christian

  • Anonymous
    February 18, 2008
    Hey there, Once the users account is cached (local AD Database on the RODC and in RAM if recent enough) the local RODC will and does authenticate the user during subsequent logins and secondary logons (accessing network resources and such). Remember the key here is the user acount is allowed to be cached, and that way the WAN bandwidth is saved.  Once it is cached, the local RODC does it all. ~Bob

  • Anonymous
    April 04, 2008
    Well I am sat in the departure lounge of Aberdeen Scotland Airport after a really interesting and enjoyable

  • Anonymous
    July 13, 2008
    The Read-only Domain Controller is one of the new and most existing features of Windows Server 2008.

  • Anonymous
    January 15, 2009
    My RODC is behind WAN, and still authenticate some amount of users from my domaint but, even if is not in Allowed RODC Password replication Group, just authenticate not save this credentials. How i must tune up my Active Directory to preven users authentication for my locally office in nearest AD controller, not throug WAN to RODC. Thanks for the reply.

  • Anonymous
    January 15, 2009
    Hey Nazarevych, If you are seeing users authenticate to the RODC that are not supposed to be, then most likely the client computers are discovering the RODC through a possible misconfiguration of the site coverage in AD Sites and Services.  If you have the RODC configured to cover those computers' subnet then that could be the reason your users are authenticating to it (RODC) instead of thier local DC. See  "Procedures for Adding a Subnet": http://technet.microsoft.com/en-us/library/bb727051.aspx Check them subnets :)

  • Anonymous
    January 15, 2009
    You may also want to check and see if you need: http://support.microsoft.com/kb/944043 Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients

  • Anonymous
    January 16, 2009
    The comment has been removed

  • Anonymous
    May 28, 2009
    I realize the post is quite old but I do have one question. Do you have to change your current replication topology in Sites & Services for RODC? (we have hub and spoke topology)

  • Anonymous
    May 28, 2009
    No, but you cannot have RODC's replicating with other RODC's, so that will need to be a consideration.

  • Anonymous
    September 20, 2014
    Understanding “Read Only Domain Controller” authentication - Ask the Directory Services Team - Site Home - TechNet Blogs