I've got
a module that I think can help you with this. If you have PSv3 or higher, look for the link to the 3.0 beta version of the module (v2 *might* work, but I've done zero testing since making major changes since version 2.1, and there are usually v3 or higher
language changes that I accidentally use). Unfortunately, the documentation hasn't been updated since adding AD functionality, but I'll cover some examples below, and I'll be more than happy to answer any questions you may have. The documentation that's present
can still help, it just won't reflect any of the new 3.0 changes (including AD support).
The module can be used as a replacement for the native Get-Acl and Set-Acl commands, or it can be used as a supplement. If you want to use it as a supplement, you can use Add-AccessControlEntry and/or Remove-AccessControl entry directly with the SD object returned
from Get-Acl (via the pipeline). You can also just use New-AccessControlEntry and use the .Add*Rule() and .Remove*Rule() methods on the SD object returned from Get-Acl.
Here are some examples:
# Set up the OU and principal to start since we're going to use multiple commands to do
# the same thing:
$OU = "DC=TestGroup,DC=domain,DC=local"
$PrincipalToAdd = "TestGroup"
# Using native Get-Acl/Set-Acl; module as supplement
$SD = Get-Acl "AD:\$OU"
$SD | Add-AccessControlEntry -Principal $PrincipalToAdd -ActiveDirectoryRights CreateChild, DeleteChild -ObjectAceType computer
$SD | Get-AccessControlEntry -Principal $PrincipalToAdd # To confirm it's in SD (which hasn't been saved)
$SD | Set-Acl # Commit
# Using module to fully replace Get-Acl and Set-Acl:
# You could use Get-SecurityDescriptor and Set-SecurityDescriptor in place of Get-Acl and Set-Acl,
# but you can also just use Add-AccessControlEntry, and it will automatically get and set the SD:
Add-AccessControlEntry -Path $OU -Principal $PrincipalToAdd -ActiveDirectoryRights CreateChild, DeleteChild -ObjectAceType computer
# If you don't use -Force, you'll be prompted before making the change. I've got to tweak the confirmation prompt for AD objects
# since their SDs are HUGE, so you may have to just press Y or N (buttons might not be visible)
Notice that I just typed 'computer' for the ObjectAceType. If you're not sure what the property/propertyset/extended right/validated write/classobject name is that you're looking for, you can actually use wildcards there, and you should get a prompt if
there's more than one object that meets the search criteria. You can also use Get-ADObjectAceGuid. See these examples (running from the ISE is recommended for Get-ADObjectAceGuid b/c of IntelliSense):
# Notice the prompt after submitting this command (PSv3 and higher uses Out-GridView)
New-AccessControlEntry -Principal $PrincipalToAdd -ActiveDirectoryRights CreateChild, DeleteChild -ObjectAceType *computer*
# Using Get-ADObjectGuid helper (type the last part out to see IntelliSense in action):
New-AccessControlEntry -Principal $PrincipalToAdd -ActiveDirectoryRights CreateChild, DeleteChild -ObjectAceType (Get-ADObjectAceGuid -ClassObject computer)
# More IntelliSense examples (type these commands instead of pasting them):
Get-ADObjectAceGuid -PropertySet "[name here]"
Get-ADObjectAceGuid -ValidatedWrite "[name here]"
Get-ADObjectAceGuid -ExtendedRight "[name here]"
# Another Get-ADObjectAceGuid example:
Get-ADObjectAceGuid *pass* -TypesToSearch ClassObject, ExtendedRight, PropertySet
And last, check out the Get-EffectiveAccess function:
# Adding wildcards so that more than just the computer object shows up:
$OU | Get-EffectiveAccess -Principal $PrincipalToAdd -ObjectAceTypes *Computer*
$OU | Get-EffectiveAccess -Principal $PrincipalToAdd -ObjectAceTypes *Computer* -ListAllRights
Again, if you have any questions or suggestions (or if you find any problems), please let me know.