Why Clients don’t (need to) understand the concept of Read-Only Domain Controllers (RODC)

Hi There,

 

just back from TechEd, it’s time for some technical posts. So one of the questions I got very often is what you need in your infrastructure to deploy read-only Domain Controllers. Along with that question goes what Client-Version of the Operating System is needed that they are able to authenticate with an RODC.


What is a RODC?
The Read-Only Domain Controller is a new concept in Windows Server 2008. While a regular Domain Controller allows updates to the domain contents on each DC, an RODC is only receiving updates from Full DCs. He will not take any write requests. He is further not replicating any password or cached secrets. This distinguishes him from a NT4 Backup Domain Controller (BDC), who had all passwords stored locally. Also he is – in every other means – a full domain controller and LDAP-Server, also stores all GPOs in Sysvol. To allow offline operations (when the WAN to the RODC-Site is failing) Administrators are able to configure if certain users passwords are allowed to be cached, by putting them in a group which is in the allow list. There is also a group whos passwords are denied to be cached, even if they are in the allow list. List group contains by default certain administrative accounts, such as domain administrators, enterprise administrators, the operators groups a.s.o.
The RODC is built for the unsecured Branch-Office or for the DMZ/perimeter network, where you are either unable to ensure the physical security of a DC or where the environment is untrusted.

So the first thing you need is to prepare your existing infrastructure. The RODC is a Domain Controller, so you need to update the schema. Further the RODC needs some assistance from a Full-DC, so you need to deploy enough Full-DCs to allow replication to the RODCs. For most environments one Full DC should be sufficient (RODCs only replicate inbound, not outbound, which also increases performance and decreases replication traffic), however I’d always prefer a second one to allow redundancy. To prepare the schema you need to perform the forestprep and domainprep operations (adprep /forestprep and adprep /domainprep), if you want to deploy RODCs you also need to perform a adprep /rodcprep in every domain of the forest to allow a Global Catalog on the RODC. However you do not need a Windows Server 2008 DC in Domains where you don’t want to deploy RODCs. However two: there are other reasons why you should deploy Windows Server 2008 [;)].

But how do RODCs perform certain functions? They can take the role of a Global Catalog server and of a DNS-Server. If a client (member-servers might also be clients to Active Directory, even the domain controller itself – his OS – might be a client to AD) tries to write against an RODC the RODC is using LDAP write referrals to tell the Client that he is supposed to write to a different DC (a Full Windows Server 2008 DC). LDAP referrals have been defined e.g. in RFC 2551 back in 1997, so LDAP-applications should be able to follow them.

And how is a logon performed against the RODC? The user is actually performing the logon against the RODC. The RODC is looking in his local AD to verify whether or not he’s able to verify the users password. If he has no cached copy of the password he is forwarding the request to a full DC. Further he is requesting the full DC to replicate the password down to him, the full DC checks the allow- and deny-lists and decides whether or not to replicate the password down. The full DC further issues a kerberos ticket for the client. The RODC is informed that the client may log on, and the RODC is issuing his own kerberos ticket for the client. All other things of the logon process, such as compiling the token with group membership information and pulling down group policies is done against the RODC. If the user logs on another time, and the password is cached on the RODC, the RODC does not need to contact the full DC and is able to process the logon-request even if the WAN is offline.

The other thing are DNS updates. Clients in the Branch Office (or Remote Office how we prefer to call it nowadays) are supposed to use the local DNS-Server. However they might update their DNS-Records, which is totally acceptable. But if the RODC is not writeable, and DNS is stored in AD, and actually the DNS-Zones on a RODC are not writeable too, how are those updates performed. This answer is actually quite simple. We Windows Admins got spoiled over time, since our DNS-Servers – when the zone is stored in AD – allow updates on any DNS-Server which is also a DC and holds a copy of the AD-integrated Zone. However think back to the concepts of DNS. We always had a single primary DNS-Server who was able to write updates, and multiple secondaries who were just able to answer to queries. Clients who want to write in DNS had to request a SOA (start of authority) Record for the zone they want to write into. Full DCs who are DNS-Servers with an AD-integrated replica of the Zone were always answering with themselves as SOA (the SOA-Record only allows one Server, and there is only one SOA per Zone, as opposed to Nameserver (NS) Records where are multiple per DNS-Zone). RODCs don’t have an SOA for themselves, they hold a SOA which is stating the Name of a Full DC. So that is simple, Clients who want to write into DNS are still (same technology as in the 80th) querying the zone for it’s SOA, and then they are contacting the Server which is stated in the SOA to write the update. But RODCs provide some intelligence as well – if a client was contacting them for the SOA they wait for a moment to allow the client to update his record, then they are requesting a single-object-replication from the Full DC for the Clients DNS-Record so that the DNS-Information at the clients site is updated as soon as possible, while any other site will receive it with the regular replication.

So Clients / Memberservers and other machines should be able to run against RODCs. However, there are certain things which might affect this statement:

  • The Read-only partitial attribute set (RO-PAS): It is possible to define in the schema that certain attributes should not be replicated to RODCs. However the application needs to be aware of this, since those requests are not referred to a full DC.
  • Replication latencies: if an application is performing a write request it will be redirected to a full DC. If the application tries to read that data again before replication occurs, the RODC will still return the old data. If you want to make sure that your applications write against RODCs be aware of this issue, and look for a writeable DC when you perform write/readback-operations or make sure that you are not using write/readback (but stick against the RODC if you only perform read operations, otherwise you will slow down your application since it’s always crossing the WAN).
  • Firewalls: especially in DMZ-Scenarios your clients might not have a connectivity to a full DC, so write referrals will fail. Make sure that you don’t need write requests in those scenarios.
  • WAN-Offline: write operations will also fail in this scenario

I hope I was able to get some lights behind RODCs, theres a lot of more information available online, e.g. look at the following page: Application Compatibility with RODCs

 

Ulf



Leave a Reply

*