I've been reading up on Active Directory read-only domain controllers (RODC), new in Server 2008. When I first glanced at them, they looked an awful lot like NDS read-only replicas which have been around since the advent of NetWare 4.0 too many years ago. Novell put r/o replicas into NDS in large part for complete X.500 compliance. However, their real use case was never made clear. The only case I could ever come up with is a kind of disaster-recovery site, where that R/O replica could be promoted to a R/W replica in an emergency. So why was Microsoft finally putting the last X.500 piece in now?
Turns out, it wasn't X.500, it was to solve a somewhat intractable problem with Active Directory domains; the satellite office problem. The Small Business Development Center is a part of the College of Business Education, and actually offices in downtown Bellingham. Before they got a reliable WAN connection to campus, they needed to be able to work when their internet connection was down. What we did was put all of those users into a single OU, made that OU a partition in eDirectory, and gave their NetWare server a copy of that replica. That way, only those security principles were ever at threat, and they could still log in and use resources local to them when their WAN link was down.
The same problem with AD is much trickier to solve, since you can't partition the AD database that way. You really had three options:
A Read-Only Domain Controller is NOT a full copy of the domain; it does not contain any passwords by default. Unlike a R/O NDS replica, users can actually authenticate against it; the server proxies the authentication against a normal DC if it can find one. You can set a password-caching policy to tell it which passwords to keep local copies of, so branch-local users can still log in when the WAN is down. That's... not useless You're still having to keep the entire AD database down there complete with GPO SYSVOL goodness and all those groups, but at least if thieves run off with the RODC they'll only fully compromise local users.
It still isn't as robust as how eDirectory handles it, but at least it's a lot better than it used to be. Especially if politics prevent you from being able to declare a new domain.
Turns out, it wasn't X.500, it was to solve a somewhat intractable problem with Active Directory domains; the satellite office problem. The Small Business Development Center is a part of the College of Business Education, and actually offices in downtown Bellingham. Before they got a reliable WAN connection to campus, they needed to be able to work when their internet connection was down. What we did was put all of those users into a single OU, made that OU a partition in eDirectory, and gave their NetWare server a copy of that replica. That way, only those security principles were ever at threat, and they could still log in and use resources local to them when their WAN link was down.
The same problem with AD is much trickier to solve, since you can't partition the AD database that way. You really had three options:
- Tell the users to live with the outage.
- Put a Domain Controller down there.
- Declare the site a new Domain in the forest and put Domain Controllers down there.
A Read-Only Domain Controller is NOT a full copy of the domain; it does not contain any passwords by default. Unlike a R/O NDS replica, users can actually authenticate against it; the server proxies the authentication against a normal DC if it can find one. You can set a password-caching policy to tell it which passwords to keep local copies of, so branch-local users can still log in when the WAN is down. That's... not useless You're still having to keep the entire AD database down there complete with GPO SYSVOL goodness and all those groups, but at least if thieves run off with the RODC they'll only fully compromise local users.
It still isn't as robust as how eDirectory handles it, but at least it's a lot better than it used to be. Especially if politics prevent you from being able to declare a new domain.