RODC Trick: Remove a User’s Password from a RODC without forcing the user to change her password

TechNet (RODC FAQ) states:

How can you clear a password that is cached on an RODC?

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, an administrator should reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the branch that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be changed to Null. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed.

In the event that an RODC is compromised, you should reset the passwords for all accounts that have cached passwords and then rebuild the RODC.

I disagree.
There is a way to do this. It may not be the officially “supported method”, but there definitely is a way to remove a user’s password from a RODC.

Why would you want to do this? Say that an executive travels to a field site and an admin adds her account to the RODC Password Allow group. This means the executive’s password is cached on the RODC at that site upon successful logon. You realize that the RODC has stored the executive’s password (oops!) and you have the same security concerns about the site that led you to only deploy a RODC there. You want to wipe the password from the RODC, but don’t want the executive to have to change her password. What to do?

Check the RODC computer object and see that the executive (Jane Executive in this example) shows up in the list of security principals with their passwords stored on the RODC (msDS-RevealedList).

The LDAP Modify Operation “RODCPurgeAccount” causes the RODC to NULL the cached secrets of a specified security principal (User or Computer).

Here’s a (likely unsupported) way to do it.

Open LDP on a writable DC and connect to the RODC on port 389 (LDAP) or 636 (LDAPS). Bind to the server (ensure you have Domain Admin credentials). Select Modify (operation) from the drop down and set the following:

DN: [blank]
Edit Entry Attribute: RODCPurgeAccount
Values: CN=Jane Executive,OU=Executives,DC=metcorp,DC=org [Account DN]
Click Replace
Click Enter
Click Run.

You should see the Modify is Successful.

Check the RODC computer object and see that the executive (Jane Executive in this example) is NOT in the list of security principals with their passwords stored on the RODC.

Security concern: the executive’s password was stored on the RODC during some period of time which means it was committed to the AD database (in memory & on disk). The correct way to ensure the executive’s password is not available is to have her change it (when WAS the last time she changed her password?) since this will invalidate any cached passwords floating around the network.

(Visited 6,462 times, 4 visits today)