Recently I came across an article, where someone claimed about a RODC (Read Only Domain Controller) limitation for the amount of 1500 cache-able passwords. I couldn’t believe that, as there’s no technical reason for having a limitation at this point; every User-, Computer- or Service- account and a password for each object.
One of the major benefits of a RODC is that object passwords are not stored on the server by default. For each server, objects can selective be allowed (or denied) to cache their passwords. The GUI setup can be found in the servers properties tab Password Replication Policy (PRP) of the domain controllers computer object in Active Directory Users and Computers. The allow entries referred to as Allow List are stored in the computer object attribute field msDS-RevealOnDemandGroup. And that’s the point where the limitation comes from; the size of the attribute field.
This setting is only the policy which defines cacheable allowed objects. At this time no passwords are cached. The RODC keeps the password, if allowed, after the first password exchange with the AD object has taken place. Alternatively we’re able to push passwords for allowed objects to the specific RODC.
For testing I created some users and added 2000 directly to the allow list. No GUI error.
repadmin /rodcrepl
Error: Replication access was denied. (8453)
But by prepopulate a specific users passwords an error occurs. After removing 1000 Accounts from the allowed list and having 1000 left, the error disappears and the prepopulating process works for the single objects.
and now?
A best practice is to take the user as well as the computer objects to an group and set the group to the allowed or denied list. This shrinks the msDS-RevealOnDemandGroup attribte field to a an absolute minimized size. This way more than 1500 objects can be added to the allowed list and prepopulated.
delete cached passwords
It seems Microsoft has forgotten to implement a function for deleting cached passwords in a RODC. You can remove objects from the allowed list, but passwords are still cached. For now the only workaround I see, is either to change the objects password or to delete the object from Active Directory.
tested on Windows Server 2012R2 Environment, Domain Level 2012
