For the purposes of this scenario, you can use the predefined Access Template Self - Account Management, located in the Configuration > Access Templates > User Self-management container. This Access Template specifies the necessary permissions to view a basic set of user properties and modify telephone numbers.
If you want to add or remove permissions from the Self - Account Management Access Template, you need to first create a copy of that Access Template and then modify and apply the copy.
This scenario assumes that you apply the predefined Access Template Self - Account Management.
You can apply the Access Template using the Delegation of Control Wizard.
First, you start the wizard on the Sales Organization Unit (OU): right-click the OU, click Delegate Control, and then, in the Active Roles Security window, click Add.
Next, on the Users or Groups page of the wizard, click Add. In the Select Objects window, select the Self object, as shown in the following figure, click Add, and then click OK.
Figure 37: Access Template – Self administration
Next, on the Access Templates page of the wizard, expand Access Templates > User Self-management and select the check box next to Self - Account Management.
Click Next and accept the default settings in the wizard. On the completion page, click Finish. Finally, click OK to close the Active Roles Security window.
For more information about the Delegation of Control Wizard, see Applying Access Templates earlier in this chapter.
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, an explicit deny takes precedence over an explicit allow. An explicit allow takes precedence over an inherited deny.
-
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 10: 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.