There’s a thread going around on the ActiveDir mailing list, around whether or not to manage the passwords of machine accounts the same way you manage user accounts. In general, our approach to the problem has always been to view machine accounts as equivalent to user accounts, because at the end of the day a computer has the same rights on the network that an “authenticated user” would have. Since we’re considering them the same, then the process for managing the Password Replication Policy (the definition of which passwords can be replicated to each RODC) should be the same for both machine accounts and users. This is easy enough to say, but turns out to be pretty difficult to implement. Even more so when you don’t necessarily know “where” (on the network) a user or machine may be at any given time.
This post is meant to give some insight into one way to manage the lifecycle of passwords which are cached on an RODC. You can see that the process is somewhat complicated, and there aren’t any products that I’m aware of which do this automagically, so we’re all on our own when it comes to implementing, but at least this gives you some ideas for what you might want to try to do.
To start, remember that there are 6 attributes that are relevant in this case to RODC’s and passwords:
msDS-Reveal-OnDemandGroup – Accounts who are allowed to be cached on the RODC
msDS-NeverRevealGroup – Accounts which are not allowed to be cached on the RODC
msDS-AuthenticatedAtDC – List of RODCs through which a user has successfully authenticated to a full DC
msDS-AuthenticatedToAccountList – List of accounts who have successfully authenticated to a full DC through the RODC
msDS-RevealedUsers – For an RODC, Identifies the users (and computers) whose secrets have been replicated
msDS-RevealedDSAs – For a user, identifies which RODC’s hold that user’s secrets
The goal of life cycle management of the PRP, is to allow a password to be cached on an RODC when a user (or machine) is known to be in a site, and then remove that account from the PRP when they are no longer in the site. Also, remember that we don’t necessarily need to have the password pre-cached before a user/machine is in a site, because the WAN link is likely to be up when they first attempt to logon.
(for the rest of this post, assume that when I say “machine” or “user”, that I mean BOTH machine and user accounts)
To start with, we know that before a user logs on in a site for the first time, the AuthenticatedAt attribute does not contain the user account, the user is not on the allowed to reveal list for that RODC, and the password is not cached (revealed). In other words:
After the first login at the site, the state of the attributes changes so that:
AuthenticatedTo: User is now on the list
Because we know the user is in the site, we want to perform 3 actions:
1. Add their account to the Allow list in the PRP
2. “Replicate with secrets” their account to the RODC to cache their password
3. Clear the account out of the authenticatedAt list
We know that when a user changes their password, the password is cleared from the cache on the RODC’s, so it’s no longer revealed, however they are still in the Allowed list therefore it will be recached on their next logon. The only thing we need to remember, is that during that next logon attempt, the user will be added to the RODC’s AuthenticatedTo list again. This happens because the user attempted to logon on via his local RODC, but the password wasn’t cached. So we know that periodically we’ll still end up with users who are in the AuthenticatedTo list and who are already on the Allow list AND who have re-cached their passwords. That’s ok, just clear them out of AuthenticatedAt again and carry on.
The final case that we’re looking for though, is the case where users have moved out of the site, or machines have been decomm’d, or similar. We can find these people, by looking for the cases where users do not have their passwords revealed (they haven’t been cached), and they haven’t been authenticatedTo, but who are still on the Allow list inside the PRP. These are the users who are allowed to be cached, but aren’t, and therefore should be removed.
By removing them from the Allow list, you’ll end up right back where we started, with:
Each of the phases of the life cycle need to have an environment appropriate delay of some number of days. Especially when removing from the PRP, otherwise you’ll continue on the vicious cycle every time someone takes a vacation and their password expires. Of course, maybe in your environment, you WANT to remove them from the PRP. Fortunately it’s AD replication, which generally speaking lends itself well to replicating changes.
Confusing? Probably a bit. Here’s the (not so) pretty picture that I put together when I presented this at the Directory Experts Conference last year. Hopefully this helps visualize it a bit:
The point of this post is that while it may be challenging, there are Active Directory attributes on each RODC which give all of the information required to manage the password replication policy. Now, this is somewhat intensive, especially as it needs to be performed for each RODC, which makes scaling a challenge when you have an environment like MSIT with 100+ RODC’s. Using tools like MIIS or ILM will definitely make things easier.
Clear as mud right?
<edited 10:30pm: I originally put AuthetnicatedAt as the attribute on the RODC to look at, when that is the user attribute. Corrected to be AuthenticatedTo>