Active Roles utilizes role-based delegation for assigning administrative permissions. The advantage of this model is 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 known in Active Roles as Access Templates.
When doing delegation with Active Roles, consider the following:
-
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. You must adhere to the following permission precedence. The permission on top has the highest precedence:
-
Explicit Deny
-
Explicit Allow
-
Inherited Deny
-
Inherited Allow
-
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:
-
Object access: With this permission type, you can set permissions that affect an object as a whole. For example, Move, List and Deprovision are object permissions.
-
Object property access: These are used to control access to individual attributes of an object, such as the object 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.
-
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:
The following table lists a sample set of permission entries for a scenario of delegating administration duties for Organizational Units:
Table 2: Permission entries for delegating administration of Organizational Units
|
Domain |
Object Access |
Allow List |
|
Domain |
Object Property Access |
Allow Read All Properties |
|
Domain |
Object Property Access |
Allow Write LDAP Server (permission to change Operational Domain Controller) |
|
Organizational Unit |
Object Access |
Allow List |
|
Organizational Unit |
Object Property Access |
Allow Read All Properties |
|
Organizational Unit |
Child Object Creation/Deletion |
Allow Create/Delete Users |
|
User |
Object Access |
Allow List |
|
User |
Object Property Access |
Allow Read/Write All Properties |
|
User |
Object Property Access |
Deny Write Employee ID |
This set of permission entries has several important characteristics:
-
It allows access to the Domain and the Organizational Unit object classes. This is because without access to the domain and the Organizational Units a delegated administrator cannot see the users beneath. This access must include the List and Read All Properties permissions.
-
It gives a delegated administrator the ability to create and delete user objects. This permission applies to the Organizational Unit object class.
-
It gives a delegated administrator the ability to see (List) users and modify any property except Employee ID.
The following table lists a sample set of permission entries for a scenario of delegating administration of groups:
Table 3: Permission entries for delegating administration of groups
|
Domain |
Object Access |
Allow List |
|
Domain |
Object Property Access |
Allow Read All Properties |
|
Domain |
Object Property Access |
Allow Write LDAP Server (permission to change Operational Domain Controller) |
|
Organizational Unit |
Object Access |
Allow List |
|
Organizational Unit |
Object Property Access |
Allow Read All Properties |
|
Organizational Unit |
Child Object Creation/Deletion |
Allow Create/Delete Groups |
|
Group |
Object Access |
Allow List |
|
Group |
Object Property Access |
Allow Read All Properties |
|
Group |
Object Property Access |
Allow Write Members |
|
User |
Object Access |
Allow List |
|
User |
Object Property Access |
Allow Read All Properties |
This set of permission entries has several important characteristics:
-
It allows access to the Domain and the Organizational Unit object classes. This is because without access to the domain and the Organizational Units a delegated administrator cannot see the groups and users beneath. This access should always include the List and Read All Properties permissions.
-
It gives a delegated administrator the ability to create and delete group objects. This permission applies to the Organizational Unit object class.
-
It gives a delegated administrator the ability to see (List) groups, view any property of a group (Read All Properties), and add or remove members from a group (Write Members).
-
It gives a delegated administrator the ability to see (List) users and view any property of a user (Read All Properties). This is necessary for a delegated administrator to add users to a group.
For your delegation model to work correctly, you need to determine whether you have a functional or hosted environment.
