We’ve previously covered manipulating NTFS permissions, and in this post we’ll take that basis and apply it to Active Directory.

Marc covered this topic on his old blog, while PowerShell was still in beta (Pre RC2). The approach is basically the same, but you need to utilise psbase in PowerShell 1.0.

So, we want to give our test user bella full control over the Test OU. I would suggest not making permission changes to your AD if you don’t know what you’re doing because things can get nasty very quickly. A bit of useful reading on the subject can be found here and here.

Below is our basic function:

#———————————————————————————————————-
function Add-DSace
#———————————————————————————————————-
{
Param (
$DSobject,
$Identifier,
$DSrights,
$AccessType = “Allow”
)
# GetAccessRules: Explicit ACE’s, Inherited ACE’s, TargetType
$account = New-Object system.security.principal.ntaccount($Identifier)

# Retrieve the SID – as a manual step you can check it’s not empty :)
$sid = $acc.translate([system.security.principal.securityidentifier])
#$sid.ToString()

$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($account, $DSrights, $AccessType)
$DSobject.psbase.get_objectsecurity().AddAccessRule($ace)
$DSobject.psbase.CommitChanges()
}
#———————————————————————————————————-
$root = [adsi]“”
$test = [adsi](“LDAP://ou=Test OU,”+$root.distinguishedName)

Add-DSace $Test “bella” “GenericAll”

Okay, so points of interest then:

Once we’ve created a variable for the OU we want to add an ACE to, we then define our Security Principal. This can be either a user or a group, and we can present this in either SID format or as the account name.

In this example we’re targeting a user. We could have validated the account by retrieving it’s SID, but for this we’re presuming that everything exists and no checking is performed.

There are several constructors available for the ActiveDirectoryAccessRule. You can see what’s available, by looking at the constructors:

# List the constuctors available to this method:
[System.DirectoryServices.ActiveDirectoryAccessRule].GetConstructors() |% {“$_”}

I’ve found this to be a really useful way of discovering the specific requirements for a method. Once you know what types the method is expecting you can then investigate what each element is. In this instance we are utilising the following constructor:

Void .ctor(
System.Security.Principal.IdentityReference,
System.DirectoryServices.ActiveDirectoryRights,
System.Security.AccessControl.AccessControlType)

You can then either look them up on MSDN or feed in some false data, and see if the constructor will provide you with details on what it needs.

Once we have the ACE, the last two lines are where we add the ACE to the Security Descriptor and then commit our changes back to the directory.

As you can see we need to use psbase. This gives us the “raw” view of the object. I find using psbase very difficult. It’s almost a fall back, for when you can’t seem to make it work any other way. At the moment I just put it down as one of PowerShell’s little quirks ;)

Over the next few days we’ll take a closer look at Propagation, Inheritance and Active Directory Extended Rights.