Summary: Microsoft PFE, Ian Farr, discusses using Windows PowerShell to delegate administrator of RODC. Microsoft Scripting Guy, Ed Wilson, is here. Today we have Honorary Scripting Guy and Microsoft PFE, Ian Farr, back for more words of wisdom… Welcome to the third post in a four part series about securing and managing read-only domain controllers (RODCs). I like to think of this collection of posts as “organic”—they only became a series after the green shoots of the first two posts were already well established! The first post discussed a function that analyses RODC authentication. The function reports on accounts that are authenticated by an RODC that aren’t revealed (that is, the account password or secret is not stored on the RODC). It helps you manage your password replication policies. For the full write up, see Use PowerShell to Work with RODC Accounts. The second post discussed a function that checks whether a user is a member of a high-privileged group. It can be used in conjunction with the first function to see if your RODCs have authenticated high-privileged users. This helps identify and remove a potential means of compromising Active Directory. To read that post, see Use PowerShell to Search Active Directory for High-Privileged Accounts. Today’s post discusses a function that allows you to delegate the administration of an RODC. The function adds a user or a group to the ManagedBy attribute of the computer account for the RODC. This grants the user or group members local administrative privileges on the RODC.

Note  Users delegated as RODC administrators should not be a member of any privileged groups in Active Directory because this negates the protections that an RODC provides. Furthermore, the accounts used for delegated administration should be “secondary logon accounts” that are used only for RODC administration. For example, they should not be accounts that are also used to log on to workstations for typical user activity, such as Internet browsing or reading email. Here’s the function: Set-ADRodcManagedByAttribute Let’s take a look… The function has two parameters: Rodc and Principle. Rodc  This parameter determines the RODC on which the ManagedBy attribute is set. It can accept a value from the pipeline, so we can pipe a list of RODCs into the function. There’s also some parameter validation to ensure that we are dealing with an RODC. If the domain controller object has the IsReadOnly attribute set to True, we know we have an RODC.

[parameter(Mandatory,Position=1,ValueFromPipeline)]

[ValidateScript({(Get-ADDomainController -Identity $_).IsReadOnly})]

[String]$Rodc Principal  This parameter defines the user or group that is added to the ManagedBy attribute. It has to be a DistinguishedName. The parameter validation uses the –Identity parameter of Get-ADObject, which only accepts a distinguished name and will check whether the user or group exists in Active Directory. The ManagedBy attribute should be populated with a domain local group.

[parameter(Mandatory,Position=2)]

[ValidateScript({Get-ADObject -Identity $_})]

[String]$Principal The function has a Begin statement block to perform further validation before each RODC object is processed. In the following script, we check that the object supplied to the Principal parameter is a User or Group object. If it isn’t, we Break out of the function.

     Begin {

        #Get the supplied AD Object

        $ADObject= Get-ADObject -Identity $Principal -ErrorAction SilentlyContinue  

        #Check that $Principal is a user or group

        If (($ADObject.ObjectClass -ne “user”) -and ($ADObject.ObjectClass -ne “group”)) {  

            #Write a message to the host

            Write-Host “$Principal is not a user or group”

            Break

        }  

     }   Next, we enter the Process statement block. We iterate through each RODC that is passed into the function and use the Get-ADComputer and Set-ADObject cmdlets to update the ManagedBy attribute. On the associated computer account object, to our user or group DistinguishedName, the -Replace parameter makes use of a hash table that references our user or group principal.

Process {

#Set the ManagedBy attribute

Get-ADComputer -Identity $Rodc | Set-ADObject -Replace @{ManagedBy = $Principal}

}   Here’s an example of how to use the function:

Get-ADDomainController -Filter {IsReadOnly -eq $True} |

Set-ADRodcManagedByAttribute -Principal “CN=RODC Admins,OU=Groups,DC=Fabrikam,DC=com” In this command, we get all of the RODCs for the current domain and pipe them into the Set-ADRodcManagedByAttribute function. This updates the ManagedBy attribute of each corresponding computer object to the distinguished name of the RODC Admins domain local group. Of course, we could also pipe a specific list of RODCs into the function to meet a particular administrative requirement, or simply run the function by itself against a single RODC. And that’s it. Next time out, I’ll talk about synchronizing our delegated RODCs administrators’ passwords to their respective RODCs. ~Ian Thanks, Ian. Join us tomorrow when Ian returns for the final part of this series. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy