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:
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 http://msdn.microsoft.com/en-us/library/ms680832(VS.85).aspx. 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 (http://imav8n.wordpress.com/2009/01/06/life-cycle-management-of-rodc-password-replication-policies/). 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.