Think back to the days of Windows NT 4.0, when there was one king of the hill, the primary domain controller (PDC), and then any number of subservient princes below that king on the same hill—the backup domain controllers, or BDCs. It was easy to see the flow of information—changes were made to the master copy of the domain security information on the PDC, and from there it flowed outward, unidirectionally, to the BDCs. When AD DS came around, however, this distinction was eliminated, and in practice a domain controller became equal to any other domain controller, without any designation of primary, backup, or so on. (Well, in actuality, some DCs are a little more equal than others when you factor operations master roles into the equation, but that's not relevant to this discussion.) While this new design increased the fault tolerance and distributed deployment capabilities of the operating system, it's somewhat of an issue if a domain controller anywhere on the network pushes corrupt or otherwise incorrect data to other DCs; how would you prevent that? In branch office scenarios, this issue is particularly serious, since the designated administrator in a branch office needs Domain Admin credentials to administer the DC in her office; this actually gives her the right to administer any DC, not just the one she's responsible for looking after. It's not the best security situation.
While this equality of domain controllers is still the case in Windows Server 2008's AD DS implementation, there is now the concept of a read-only domain controller. A read-only domain controller (RODC) is just that—it receives information replicated to it from full domain controllers, but it doesn't permit any changes to be made to its own copy of the directory database, and thus no information can be replicated back to the full DCs in the domain of which it's a member. This is a great win for branch offices whose companies are large enough to have a comprehensive AD DS structure. Now, you don't have to deploy a full-blown domain controller to your remote locations—you can simply place a RODC there. The benefits are significant and include the following:
-
You reduce the risk of someone attacking a branch office location and sending poisoned data throughout the entire AD DS database.
-
The RODC caches only the credentials of users and computers who have authenticated to the RODC and whom the Password Replication Policy allows to have credentials cached, which reduces the possibility that accounts can be cracked from a stolen branch office domain controller.
-
By default, the RODC does not cache domain administrator credentials, so the keys to the kingdom are more fully protected.
-
The Kerberos authentication tickets issued by the RODC will only be valid for systems within its scope, so it can't issue falsified tokens to get nefarious users onto the full network.
-
The RODC is a Server Core-designated role, which means there's hardly any need for administration locally. No GUI also means a smaller attack surface. To set up a read-only domain controller, run DCPROMO and select the option on the Additional Domain Controller Options screen to make your new domain controller a read-only domain controller.
DNS considerations for read-only domain controllers
During the Active Directory Domain Services Installation Wizard, when you're first deploying a RODC, DCPROMO recommends that you install a DNS server locally on the RODC. That server is fed zones from the AD DS infrastructure, and the process will add the RODC's local IP address to the RODC's local DNS client properties, so queries will be directed automatically to the AD-integrated zone on the machine itself.
However, for maximum fault tolerance, if there is only one DNS server and RODC (for instance, if the two services are running on the same machine) at a branch office, Microsoft recommends using the options in your DHCP scope—assuming you are using dynamic IP addresses at your branch office—to include not only the local RODC-based DNS server, but also a DNS server at the main office, where your other AD servers are centrally located. Make sure the local RODC-based DNS server is first on the list, so that only queries that fail to get a response from your local server are directed over the wire to your hub site.
If you have a larger branch office contingent, and you have multiple RODCs deployed at one branch office, you can install a DNS server instance on each RODC. Remember that since RODCs are indeed read-only, any dynamic update requests from your clients have to go directly to a writeable domain controller at your central office. The DNS server instances on RODCs will not attempt to replicate with one another; rather, they will receive all updates directly from the central AD DS infrastructure, so there may indeed be certain times wherein one local RODC has received an updated DNS entry for a client, but another has not. This issue resolves itself (no pun intended) within a replication cycle, but to avoid it, make sure the clients themselves have identical DNS server lists—use DHCP options to assist with this—and only install one DNS server instance per site.
-------------------
Thanks,
Paddy
0 comments:
Post a Comment