RODC Password Replication Policy

I have been fortunate enough to be involved in quite a large RODC deployment in a Windows 2008 domain. Even more fortunate is that we are currently upgrading this domain to R2 so I am getting the chance to try out the new powershell 2 AD cmdlets.

I have been looking quite a lot into RODC operations, and the importance of the Password Replication Policy (PRP from now on) component has become increasingly more apparent. My first thoughts of PRP were entirely user based. "It allows users to logon to a remote site when the WAN link is down" was my impression. But, when a user logs on to a domain from a trusted computer, there is 2 parts to the authentication - user AND computer. Therefore it is just as important to add the computer objects to the allow PRP as it is the users. While you are there, add any server that is in the same site as the RODC as they will need to authenticate too. My preferred way of doing this create 3 groups and add them to the PRP policy : all users, all computers (user workstations) and all servers

Creating, populating and adding the groups is going to be specific to each environment, so my only advice is to keep your groups / OU's / other AD objects as uniform as possible as it eases the scripting process.

Now we have our groups in the allow PRP list, how can we check to make sure all the groups are there?

Powershell 2 with an R2 (read-write) domain controller allows us use the new AD cmdlets. First let's see how easy it is to get all the RODC's in the domain :

Get-ADDomainController -filter { isreadonly -eq $true }

now, get the PRP for each RODC

$(Get-ADDomainController -filter { isreadonly -eq $true }) | Get-ADDomainControllerPasswordReplicationPolicy

WOW, that’s what I call a cmdlet! Thank goodness for TAB-completion! This gives us a list of allowed groups for each RODC's. This then needs to be compared to the list of groups that is expected to be there. A scriptable way would be to generate a list based on the RODC name, but as mentioned above, this of course relies on your infrastructure being named in a uniform and predictable manor.

TIP: you can give a group a samAccountName that is different to the group name which then can be used for scripting purposes.

So, in the following script, I read the first 6 characters of the RODC (my identifier) and generate my 3 groups in $list. I then compare the memberships and add any groups that are not present :

#loop round all RODC’s
foreach ($RODC in $(Get-ADDomainController -filter { isreadonly -eq $true })) {

   #get the first 6 characters of the RODC
[string]$sitename = $($RODC.name).substring(0,6)

   #generate the group list
   $list = "$($sitename)-servers","$($sitename)-computers","$($sitecode)-users"

   #extract the samaccountname from all the groups in the PRP of the RODC
   $allowedPolicy = $(Get-ADDomainControllerPasswordReplicationPolicy -id $rodc -allowed) | select "samaccountname"

   #loop round all the groups that were created above
   Foreach ($group in $list) {

      #check to see the $allowedpolicy groups does not include the current group
      If ($($allowedPolicy | % {$_.samaccountname}) -notcontains $group){

         #if it is not part of the list, add it
         Add-ADDomainControllerPasswordReplicationPolicy -identity $RODC -AllowedList $group
      }
   }
}