Some RODC-related queries you’ll probably need some day

If you’re in the lucky position to own a domain in 2003+ domain functional level and you have a Server 2008-DC in your hub site, you probably looked at RODCs as a potential feature to use in the future.

For larger organizations or places that implement more than a hand full of RODCs, there’s no good builtin-way of telling what secrets are revealed on RODCs (no automated way – if you, let me know through the comments area below. I’m happy to learn!). As always, that piece of information needs to be stored somewhere in AD and as documentation on RODCs is around, these attributes seem interesting for us:

  • msDS-AuthenticatedAtDC
  • msDS-AuthenticatedToAccountList
  • msDS-RevealedUsers
  • msDS-RevealedDSAs
  • msDS-Reveal-OnDemandGroup
  • msDS-NeverRevealGroup

These are the attributes that have something to do with RODCs and passwords, their caching and what users were logged in.

For the sake of collecting some useful RODC data, we’d first need to know how to pick a RODC from the mass of DCs. For that, I had a look at the RODC’s object and its attributes and compared them to a full DC and its attributes and what I found was a difference in the userAccountControl bitmask. RODCs have an additional bit set which is called “PARTIAL_SECRETS_ACCOUNT” (0×04000000) as in the comments in It’s not well documented, if you ask me. Well, at least it is there, so a query like:

adfind -default -bit -f “&(objectClass=user)(objectCategory=computer)(userAccountControl:AND:=67108864)” dn sAMAccountName

Gives us an output of the RODCs in place:

I haven’t tested the query on many places so I’m not sure whether one could just ommit the &(objectClass=user)(objectCategory=computer) part and leave it with (useraccountControl:…). Since userAccountControl is indexed itself, it wouldn’t hurt to test it alone as a filter.

Anyway, since we have our RODCs now, it’s time to re-fine the query and ask for interesting information, let’s say, “users whose passwords are stored on the RODC(s)”. Here we go:

adfind -default -bit -f “(userAccountControl:AND:=67108864)” msDS-RevealedUsers


So that’s kind of strange. Every user/machine account is referenced five times with a different “ID” front on. Obviously these must be the different “secrets” the RODC stores for these accounts. Another (well, it’s constructed, so you can’t actually use it in a filter, but “ask” for it) attribute, msDS-RevealedList instead of msDS-RevealedUsers has human-readable names (as a “string” rather than binary) for them:

Okay, that’s our list of users whose passwords have been revealed. We pretty much queried for all RODCs now and read their attributes. Another fine solution is to go query for all objects that have their “msDS-RevealedDSAs” attribute set to the RODCs, as in:

adfind -default -f “(msDS-RevealedDSAs=CN=RODCR2,OU=Domain Controllers,DC=contoso,DC=com)” sAMAccountName

or that have the attribute set to anything (depending on what you’re trying to achieve):

adfind -default -f “(msDS-RevealedDSAs=*)” sAMAccountName

I’ve found that while the first option is less pretty to read, the latter is faster to perform. ;) You’ll have to pick your favorite yourself. Let’s go make it a nice output ready for Excel consumption, using the -csv switch and pipe it out to a new *.csv file:

adfind -default -bit -csv -f “(userAccountControl:AND:=67108864)” msDS-RevealedList > revealed-users.csvÂ

The funny thing is that msDS-RevealedList is a multi-valued attribute, so the values are seperated by a semicolon. You’ll first have to use the comma (,) as a delimiter when you import it in Excel and then, after it is imported Excel placed the attribute name in one column and the whole multi-valued junk in another (as a whole!), you’ll have to again let it split the column based on semicolons (use the “Text-to-column” function — that’s what it’s called in Excel 2010 beta). If you’re going down the second query-road, using msDS-RevealedDSAs, you probably have the prettier export right away and don’t have to mess with it in Excel.

Now, maybe you’re interested in a user’s affiliation with RODCs and want to know where it has secrets revealed:

adfind -b “CN=Anna Bings,OU=Stuttgart,DC=contoso,DC=com” msDS-RevealedDSAs

Again, that gets us every RODC an object’s secrets are revealed to five times. msDS-RevealedDSAs is the backlink attribute for msDS-RevealedUsers. So you see there’s a connection :)

As of now, you probably haven’t gained much since this functionality is given through the UI, when choosing a RODC’s computer account’s properties using the “Password Replication Policy” tab. You can do that for a single RODC by hand — but what if you’re dealing with 3, 5…10 RODCs?

The last query is a goodie you might be interested in if you followed Brian Puhl’s blog posting on Life Cycle Management of RODC PRPs ( We’re going find users, whose secrets are allowed to be cached on RODCs but currently aren’t:

adfind -default -f “&(objectClass=user)(!msDS-RevealedDSAs=*)(memberOf=CN=Allowed RODC Password Replication Group,CN=Users,DC=contoso,DC=com)(!msDS-AuthenticatedAtDC=*)” dn

A beast of a command — but apparently working. These users match the following criteria:

  • they have no revealed secrets (their msDS-RevealedDSAs attribute is empty) on RODCs
  • they have a membership in the “Allow Caching” group (Allowed RODC Password Replication Group)
  • no RODC needed to proxy an authentication request to a full-DC to authenticate the user (due to a lack of cached creds -> attribute msDS-AuthenticatedAtDC is empty)

So if you get a list of users in there, that pretty much means that those users are allowed to be cached on RODCs but haven’t yet. Nor did they attempt to log on using on. See, we have used some scripting action and powerful ADFind to build our own (although small) RODC checking system.

2 Comments so far

  1. Christoph on May 6th, 2010

    Auch wenn ein 2008+ Domänenfunktionalitätslevel wirklich cool ist, RODCs kann man doch schon mit 2003 Forestlevel nutzen…

  2. florian on May 7th, 2010

    Yeah, thanks for the hint. I’ve corrected it. Indeed there’s only a 2003 FFL requirement (and that because of LVR).