Recently we looked at Extended-Rights in Active directory, and today we’ll complete our series of posts on permissions in AD with a post on Control Access Rights, also known as Specific Rights.
Control Access Rights are similar to Standard Rights in the permissions applied, however it is applied to a specific object, or property set. This property is also represented by a system.guid like we have previously seen with Extended Rights.
In this case however the GUID is the schemaIDGUID attribute on the object located in the Schema partition. Provided the Common Name (cn) is known of the object needed the function below will retrieve the GUID in question:
$dse = [adsi](“LDAP://RootDSE”)
#———————————————————————————————————-
function get-SchemaGUID
#———————————————————————————————————-
{
Param (
$DSobject
)
$guid = $null
$obj = [adsi](“LDAP://cn=”+$DSobject+”,”+$dse.schemaNamingContext)
[system.guid]$guid = $obj.schemaIDGUID[0]
return $guid.ToString()
}
#———————————————————————————————————-
get-schemaguid “computer”
Once we have the GUID for the object or Property Set, we can then start thinking about our ACE. For Control Access Rights there are two types of scenarios, and hence two constructors available. We would use the following constructor when delegating the ability to create and delete computer objects in the computers container, for example.
Void .ctor(
Void .ctor(
System.Security.Principal.IdentityReference,
System.DirectoryServices.ActiveDirectoryRights,
System.Security.AccessControl.AccessControlType,
System.Guid,
System.DirectoryServices.ActiveDirectorySecurityInheritance)
The ACE can be further controlled by specificing the type of object that may inherit the ACE. In that scenario you would use the following constructor:
Void .ctor(
System.Security.Principal.IdentityReference,
System.DirectoryServices.ActiveDirectoryRights,
System.Security.AccessControl.AccessControlType,
System.Guid,
System.DirectoryServices.ActiveDirectorySecurityInheritance,
System.Guid)
As you can see with two GUID’s in the syntax it becomes much easier to get things in the wrong order and in turn get an unexpected result.
MSDN has a clearer description of the constructors, and you can see that the GUID’s are for different objects.
So, armed with the GUID of the object, and the rest of the of our information we can go about setting the Control Access Right.
$root = [adsi]“”
$test = [adsi](“LDAP://ou=Test OU,”+$root.distinguishedName)
$account = New-Object System.Security.Principal.NTAccount(“bella”)
$inherit = [System.DirectoryServices.ActiveDirectorySecurityInheritance]“All”
$rights = “CreateChild, DeleteChild”
$gplink = “f30e3bbe-9ff0-11d1-b603-0000f80367c1″
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($acc, $rights, “Allow”, $gplink, $Inherit)
$test.psbase.get_objectSecurity().AddAccessRule($ace)
$test.psbase.CommitChanges()
The above example gives the Bella account the rights to link Group Policy objects in the Test OU, and any sub OU’s (due to the inheritances flag).
Now we’ve covered the three types of permissions within the Active Directory, you should be able to apply any combination of permissions you need to organise the delegation model within your environment.
It makes me smile when I think back to the old NT4 days! ;)
[Updated:] The paragraph describing InheritedObjectTypes was rewritten to try and clarify the difference between the constructors.