Musings of a sysadmin
RODC
RODC password replication
0551 days
Read Only Domain controllers in windows server 2008 are designed primarily for use in branch offices (satellite locations with no onsite IT staff and slower links back to HQ).
I have blogged previously about installing an RODC which is a nice straightforward dcpromo with an added tickbox at the end, and the purpose obviously of an RODC is to provide local authentication and if required a local DNS and global catalogue. One thing that is not stored within an RODC is passwords for user accounts which obviously results in WAN traffic when an authentication attempt is made.
However there are two ways in which local users passwords can be stored within the RODC’s db.
One way is to add the users at the branch office to the “allowed RODC password replication group” in a writable domain controller.
The other is to assign objects to the “password replication policy” tab in the RODC’s computer account in AD.
When I say object this can be a group or individual user accounts (although creating and assigning a group for this purpose if clearly easier).
It is quicker and easier to add the user accounts to the allowed RODC password replication policy group in AD however this presents a possible minor issue. By putting users into this group it will replicate the password data to all RODC’s in the domain. This is not a problem if you only have one branch office, but what about if you have more than one say you have 20 or more all over the world, and branch offices can have a decent number of staff in them. This could quickly balloon the Wan traffic in each branch office as they receive all the completely unnecessary password data for the other 19 branch offices in the organisation.
Of course even with a modest residential ADSL line it probably wont bring the connection crashing down around your ears but every meg counts.
So if you have more than one branch office or it seems expansion of the business is on the cards then taking a few extra minutes to set up new groups and assign them specifically to the RODC computer accounts.
Within the RODC’s computer account “PRP” tab you can also add other groups and accounts to the policy and also specify whether the group/user is allowed or denied the password replication policy, as always if a user is a member of several groups then a deny permission always over rides an allow.
Also dont forget that computer accounts also logon to the domain so adding computers to the policy is also a good idea as a prolonged wan outage may well cause issues for the computers if their passwords are not cached as well.
Read Only Domain Controller for Windows Server 2008 R2
0578 days
RODC (Read Only Domain Controller’s) is a great new feature of server 2k8. A nice little light feature as well that does not require a great deal of setting up or babysitting.
RODC’s primary purpose is to provide local caching of the active directory database and DNS if required to remote branch offices. The main reasons for this could be that the link between the branch office and the domain controller at the head office is slow or prone to failures.
To implement a RODC there are several obvious pre-requisits:
Because its read only the RODC will need to be installed in an already established domain so all the fun stuff that goes with it is also required.
A RODC also has a couple of gotcha’s you will need to keep in mind, a RODC has a local administrator account….. Yep thats right it fly’s in he face of everything you know about domain controllers but it does, or at least a domain user or group is elected the local administrator of the RODC only. You can think of an RODC as not actually a full DC but maybe something along the lines of a a member server running a mini DC role. The handy thing with having a local administrator password is that maybe someone at your branch office has been given a little bit of power on the server, maybe they are allowed to reboot it for you if required or check something, They can without any fear of them being able to fiddle with any aspect of the DC service.
To install an RODC you will need to have added the server to the domain already as a member, it does not need to be added to the exact domain that the server will be an RODC for only a domain in the tree.
You would then need to run a DCpromo and follow the prompts as you would normally expect to until you get to the point of clicking the RODC option. You will also then have the choice of including DNS and global catalog as part of the RODC’s role. Now thinking back to the purpose of an RODC which is primarily to provide local authentication to branch office users without the constant game of ping pong across a WAN or some other slow means it sensible to leave DNS and global catalog so that it will be installed on the RODC as well. This will have the added bonus of allowing at least some backup and functionality on the branch site should the WAN link go down, this would leave the branch office at least some form of name resolution and authentication to any other servers or services in the branch site.
By default an RODC will not store password information from AD in its RODC role, this is controlled by 2 policies one allow and one denied. You may decide that it would be a good idea to allow password caching on the RODC for the users based at the branch office so they dont need to hop across the WAN for all authentication requests.
I will post another blog on administering an RODC once the role has been installed.
Recent Comments