Active Roles utilizes role-based delegation for assigning of administrative permissions. The benefits of this model are that a role can be created once and delegated to multiple groups of users that fit that role. If a change is needed, an update to the role will take effect for everyone. These roles are referred to as “Access Templates.”

When doing delegation with Active Roles, you should remember a few rules:

• Active Roles administrators (Active Roles Admins) have full control throughout the system and cannot be denied access anywhere within Active Roles. Everyone else starts with nothing and permissions are added from the ground up.
• Permissions are cumulative, an explicit deny takes precedence over an explicit allow. An explicit allow takes precedence over an inherited deny.
• You should keep your permission model as simple as possible. Sometimes this means giving users all read/write permissions and denying the ability to write a few fields.
• Do not use the default (built-in) Access Templates as they cannot be modified. Instead, copy those Access Templates and move them to a new container. This way all of the Access Templates you are using are stored within a particular structure.

There are three basic types of permissions that can be added to an Access Template:

• First is object access. With this permission type, you can set permissions that affect an object as a whole. For instance: Move; List; Deprovision—all these are object permissions.
• Second is object property access. These are used to control access to individual attributes of an object, such as an object’s description, samAccountName, or homeFolder. With this permission type, you can delegate granular rights over an object. However just because the rights that can be delegated can be granular does not mean that they should. For instance, if a helpdesk operator needs to be able to manage a large set of user properties, it makes more sense to delegate read/write for all properties as this is one permission entry instead of delegating read/write for every individual attribute since each attribute would need to have its own permission entry.
• Third is child object creation/deletion. With this permission type, you can set permissions for creation or deletion of objects. For instance, to set up an Access Template that allows creation of users, you should add a permission entry that applies to the Organizational Unit and Container object classes, and contains a “Create child objects” permission for the User object class.

The following sections give a sample set of the permissions necessary for certain delegation scenarios:

• Delegation of Organizational Unit administration
• Delegation of group administration