Skip to main content

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
      }
   }
}

Comments

  1. Erk, I hope your domain controllers aren't Core....http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2009/09/24/some-server-core-domain-controllers-heading-for-a-dead-end-street.aspx

    ReplyDelete
  2. Only the RODC's, which are in the process of being upgraded to R2! Interesting situation though, as all the dependancies required to run AD cmdlets, PS remoting etc are becoming available for other OS's you would naturally think that it would be all systems go. But, in a 'most secure' configuration for AD's using server core, this would put a spanner in the works until a complete OS upgrade was possible.

    ReplyDelete

Post a Comment

Popular posts from this blog

Enable Powershell Remoting (WinRM) via Group Policy

I have been doing some testing on enabling WinRM via group policy, being that WinRM is the service that Powershell v2 sets up it remoting capabilities. Here are the GPO settings that you need to configure WinRM .... set the winrm service to auto start Computer Configuration \ Policies \ Windows Settings \ Security Settings \ System Services Windows Remote Management (WS-Management)  set Startup Mode to Automatic start the service incorporated in to the above - you may need a restart. create a winrm listener Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service / Allow automatic configuration of listeners IPv4 filter: * * is listen on all addresses, or if you only want a particular IP address to respond use an iprange eg 10.1.1.1-10.1.1.254 - don't forget that this IP range has to be valid for all hosts that fall in the scope of the GPO you are creating.  You can use 10.1.1.1 -

Assigning Permissions - AGDLP

AGDLP It seems I have been mildly distracted away from the title of this blog site.   It does say AD Admin, but I seem to have been taken away by file system stuff.   I have to say, it has all been worthwhile, but it’s probably time I got back to the real heart of what I do. There are probably a million permission assigning advice pages, but I thought I would put another one out there after referring to AGDLP in my last post. So, what is this all about – AGDLP.   Well, it is something I learned in my MCSE 2003 studies and has become ingrained into my ideals since.   As a contractor, I get to move job often.   This enables me to forge opinions on how to configure things in a domain, and more importantly how NOT to configure things. AGDLP is definitely on the to do list…for anyone in any size domain or forest, as it follows some very basic principals.   I will explain these whilst I go through what AGDPL stands for. A A is for account.   It is the securit

PowerShell 3 behavioural change

It's taken me way too long to get into PowerShell 3, I guess opportunity hasn't shown it's self until now and so, here, my V3 journey begins. I was asked to debug a script that would run fine in PS v2 and not in v3.  The issue was a that a variable length was being checked and was failing in v3.  This is why... In v2 if a variable is undefined , this test returns false PS C:\windows\system32> $var.length -eq 0 False In v3 the same test returns true.... PS C:\windows\system32> $var.length -eq 0 True Not a biggie, but as in this case, a script has broken so something to consider! cheers Adam