I don't have much experience with RODCs yet. However, I already see some of the downsides of this new kind of domain controller:
- Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- If you add RODCs to your network, you certainly increase the complexity. RODCs simply work differently than DCs, which means that new kind of problems might come up.
- Administrators need to invest time to learn how to manage RODCs.
- Some third party products will not work together with RODCs.
- An RODC usually needs a writeable domain controller to work properly. For example, users can't change passwords, computers can't join the domain, accounts whose passwords haven't been cached can't logon, and Group Policy doesn't work properly if no writable RODC is available. This means that an RODC doesn't provide the same failure safety like a writeable DC.
Don't underestimate the first two points. At first, I thought, it can't be too difficult installing an RODC. After all, it is just a DC with reduced functionality, i.e. with only unidirectional replication. However, it took me more time than expected to set up a test environment.
My RODC had two network cards, one was in the same sub network as the writeable DC, and the other network card was connected to the same sub network as my clients. Most things worked fine. However, I wasn't able to authenticate against the RODC if the writeable DC was offline. In theory, this should work if the user's password is cached on the RODC. Even though I could see that the password was cached, I always got this error message: The trust relationship between this workstation and the primary domain failed. However, if the writeable DC was online, I had no problems logging on to the RODC.
Maybe my configuration was not correct or maybe there was a bug involved. I didn't try too long to solve this problem, since Windows Server 2008 is still beta. But this example shows how new kind of problems can arise. With two writable DCs I wouldn't have to invest extra time. Time is money. Maybe it makes more sense to invest this money in a better physical protection of the servers in your branch offices.
There are certainly environments where it makes sense to work with RODCs. Big companies with Active Directory specialists probably won't be afraid of the increased complexity. However, since bandwidth gets cheaper almost every day, it is probably only a matter of time until domain controllers in branch offices will not be necessary anymore. So maybe it is a bit late for this new technology.
Subscribe to 4sysops newsletter!
But wait! Is this really new technology? Do you remember the BDCs (backup domain controllers) in Windows NT? When Windows 2000 came out most admins were quite happy that they didn't need these DCs with limited capabilities anymore.
I believe your problem was that you used a multi homed domain controller.
See KB272294.
One of the biggest advantages of the RODC is that you can give administrator access to it, without giving any domain specific privileges.
Thanks for the tip! I think your guess is right. It might be a problem related to multihomed DCs. I tried this feature with an RODC having just one network card and it worked there.
The reason you could not logon when the writable DC is down is probably because this DC is also the GC. You could give the RODC the role of GC. In that case you should be able to logon to the RODC with the writable DC offline.
I am still facing the issue. I am having simple LAb environment with A RWDC, RODC, a client machine and two Domain Users A and B (all at single site). Both RWDC and RODC have DNS and GC. Client machine and User A are set to ave password cached but not User B. After Reboot of Client and User A login, I see the account info being Cached on RODC but when trying to login with User A or B from client machine, when RWDC is Offiline, I get the message “The trust relationship between this workstation and the primary domain failed”. No Fancy stuff, No Multihomed DC etc.
Please share your thoughts.
The error does not point to the user account, but to the computer account. So if the client pc-account cannot be verified it has not been able to verify any user account in the AD.
It looks to me that you also have to cache the pc-account, but it’s a wild guess.
Is that even possible? I don’t have a virtual environment at hand right now.
Roel,
yes, of course. The computer account must also be cached, and it can easily be configured to do so. It’s just that in dsa.msc, the default search DOES NOT include computer accounts.