Replacing computers in your domain?

I generally think of replacing computers in a domain in three steps:

• Prestage The Computer Accounts
• Delegate Permissions for a vendor account which can create/delete computer object.
  • An important caveat is that since we are prestaging the computer objects we also need to delegate the permission to reset a machines password.
• Test Domain join and Verify GPO’s

Prestaging The Computer Accounts

Assuming the psv (Pipe Separated Values, since Distinguished names use commas) looks like:

c1-WIN10|"OU=Workstations,DC=Impossible,DC=Chicken"  
c2-WIN10|"OU=Workstations,DC=Impossible,DC=Chicken"  
c3-WIN10|"OU=Workstations,DC=Impossible,DC=Chicken"   
c4-WIN10|"OU=Workstations,DC=Impossible,DC=Chicken"  

We can use the script below to create all of the computer objects in the psv, and then move them to an Organizational Unit where a GPO is applied.

<# Prestaging prodeploy: https://blog.thecloudguy.online/2020/06/pre-stage-compuer-accounts-in-active.html
Run this script with:
. .\prestage.ps1; Invoke-Prestage -Csv "C:\Users\$env:username\Desktop\test-list.txt"
#>

function Invoke-Prestage {
    param(
     [Parameter(Mandatory)]
     [string]$Csv
    )
    $computer_objects =  Import-Csv -Delimiter '|' -Path $Csv -Header SAM,DN
    foreach ($computer in $computer_objects) 
    {
        write-host "$computer.SAM  $computer.DN"
        New-ADComputer -Name  $computer.SAM -SamAccountName $computer.SAM
        Get-ADComputer $computer.SAM | Move-ADObject -TargetPath $computer.DN
    }
}

Delegate Permissions

Remember how we needed to delegate permissions to create child/delete computers objects as well as reset machine passwords? Before I explain how I accomplished this there’s a couple things I want to address.

• What is our high level goal here?
• Can we solve this class of problem rather just than this instance?
• What is the concept of delegating permissions?

Let’s begin.

What is our high level goal here?

We would like to create permissions for an account in our Domain to accomplish a task on our behalf while adhering to the concept of least privilege.

Can we solve this class of problem rather just than this instance?

We are system administrators so we work with computers right?
Well ideally because we have administrative rights to the comptuer it should be working for us.
How can we make it work for us? Through scripts of course.
So if we can come up with a script to accomplish the task at hand then we can solve the class of problem in any domain at any job. To me thats incentive enough.
The other approach would be to use the Active Directory RSAT tools Users and Computers module, find the OU we are interested in modifying, click buttons until the wizard is complete, do this again next time. This is how you work with the computer instead of make the computer work for you…

What is the concept of delegating permissions?

Well this started a long journey of browsing Microsofts Active Directory Schema documentation. The Microsofts Active Directory Schema documentation is probably some of the most important documentation related to Active Directory because it contains infomation on how to identify … everything using Globally Unique Identifiers(GUID), so it’s pretty crucial to us identifying specific delegated permissions.
So are what delegating permissions in Active Directory? When you delegate a permission to an object you grant it the ability to do something that it would not normally have the permission to do. It follows then from that high level definition that a delegated permission in Active Directory is a modification to an objects ACL. So what are the permissions we need?

• Create and Delete Computer objects
• Reset password GUID

This is the script I ended up using, which is a modified version this.

$OrganizationalUnit = "OU=Servers,OU=SP02,OU=Delivery,$rootDN"
$ServiceUserName = "account_name"
$Group = Get-ADuser -Identity $ServiceUserName
$GroupSID = [System.Security.Principal.SecurityIdentifier] $Group.SID
$Identity = [System.Security.Principal.IdentityReference] $GroupSID
$ACL = Get-Acl -Path $OrganizationalUnit
$Computers = [GUID]"bf967a86-0de6-11d0-a285-00aa003049e2"
$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$RuleCreateAndDeleteComputer = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($Identity, "CreateChild, DeleteChild", "Allow", $Computers, "All")
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($Identity, "ExtendedRight", "Allow", $ResetPassword, "Descendents", $Computers)
$ACL.AddAccessRule($RuleCreateAndDeleteComputer)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OrganizationalUnit -AclObject $ACL

As my wife says, Voila!

Test Domain join and Verify GPO’s

So at this point, Assuming you have a windows VM handy try to join the vm to your domain using the vendor account we delegated permissions to!