Scenario 2: Implementing Self-administration
This scenario shows how to use an Access Template that allows users to modify certain portions of their personal information in Active Directory.
The Active Roles Web Interface provides the Site for Self-Administration to manage user accounts. The site displays users their personal information, such as the first and last names, address information, phone numbers, and other data. By default, Web Interface users are only authorized to view their personal information. To enable the users to also modify their personal information, you must give them additional permissions.
Suppose you need to authorize the users in the Sales organizational unit to perform self-administration. To implement this scenario, you should perform the following steps:
- Prepare a Self-Administration Access Template that defines the appropriate permissions on user accounts.
- Apply the Self-Administration Access Template to the Sales organizational unit, selecting the Self object as a Trustee.
As a result of these steps, users from the Sales organizational unit are authorized to perform self-management tasks on their personal accounts. The Self-Administration Access Template determines what data the users are permitted to modify. Users can manage their personal information via the Site for Self-Administration. For information about the Site for Self-Administration, refer to the Active Roles Web Interface User Guide.
The following sections elaborate on the steps involved in this scenario.
Step 1: Preparing a self-administration Access Template
For the purposes of this scenario, you can use the predefined Access Template Self - Account Management, located in the folder Configuration/Access Templates/User Self-management. 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.
Step 2: Applying the self-administration Access Template
You can apply the Access Template using the Delegation of Control wizard.
First, you start the wizard on the Sales organizational unit: right-click the organizational unit, click Delegate Control, and then, in the Active Roles Security window, click the Add button.
Next, on the Users or Groups page of the wizard, click the Add button. In the Select Objects window, select the Self object, as shown in the following figure, click Add, and then click OK.
Figure 36: 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.
Deployment considerations
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:
