Chat now with support
Chat with Support

Active Roles 7.6.2 - Administration Guide

Introduction About Active Roles Getting Started Rule-based Administrative Views Role-based Administration
Access Templates as administrative roles Access Template management tasks Examples of use Deployment considerations Windows claims-based Access Rules
Rule-based AutoProvisioning and Deprovisioning
About Policy Objects Policy Object management tasks Policy configuration tasks
Property Generation and Validation User Logon Name Generation Group Membership AutoProvisioning E-mail Alias Generation Exchange Mailbox AutoProvisioning AutoProvisioning for SaaS products OneDrive Provisioning Home Folder AutoProvisioning Script Execution Office 365 and Azure Tenant Selection User Account Deprovisioning Office 365 Licenses Retention Group Membership Removal Exchange Mailbox Deprovisioning Home Folder Deprovisioning User Account Relocation User Account Permanent Deletion Group Object Deprovisioning Group Object Relocation Group Object Permanent Deletion Notification Distribution Report Distribution
Deployment considerations Checking for policy compliance Deprovisioning users or groups Restoring deprovisioned users or groups Container Deletion Prevention policy Picture management rules Policy extensions
Workflows
Understanding workflow Workflow activities overview Configuring a workflow
Creating a workflow definition Configuring workflow start conditions Configuring workflow parameters Adding activities to a workflow Configuring an Approval activity Configuring a Notification activity Configuring a Script activity Configuring an If-Else activity Configuring a Stop/Break activity Configuring an Add Report Section activity Configuring a Search activity Configuring CRUD activities Configuring a Save Object Properties activity Configuring a Modify Requested Changes activity Enabling or disabling an activity Enabling or disabling a workflow Using the initialization script
Example: Approval workflow E-mail based approval Automation workflow Activity extensions
Temporal Group Memberships Group Family Dynamic Groups Active Roles Reporting Management History
Understanding Management History Management History configuration Viewing change history
Workflow activity report sections Policy report items Active Roles internal policy report items
Examining user activity
Entitlement Profile Recycle Bin AD LDS Data Management One Identity Starling Management Managing One Identity Starling Connect Configuring linked mailboxes with Exchange Resource Forest Management Configuring remote mailboxes for on-premises users Azure AD, Office 365, and Exchange Online management
Configuring Active Roles to manage hybrid AD objects Managing Hybrid AD Users Unified provisioning policy for Azure O365 Tenant Selection, Office 365 License Selection, and Office 365 Roles Selection, and OneDrive provisioning Office 365 roles management for hybrid environment users Managing Office 365 Contacts Managing Hybrid AD Groups Managing Office 365 Groups Managing Azure Security Groups Managing cloud-only distribution groups Managing cloud-only Azure users Managing cloud-only Azure guest users Managing cloud-only Azure contacts Changes to Active Roles policies for cloud-only Azure objects Managing room mailboxes Managing cloud-only shared mailboxes
Managing Configuration of Active Roles
Connecting to the Administration Service Adding and removing managed domains Using unmanaged domains Evaluating product usage Creating and using virtual attributes Examining client sessions Monitoring performance Customizing the console Using Configuration Center Changing the Active Roles Admin account Enabling or disabling diagnostic logs Active Roles Log Viewer
SQL Server Replication Appendix A: Using regular expressions Appendix B: Administrative Template Appendix C: Communication ports Appendix D: Active Roles and supported Azure environments Appendix E: Active Roles integration with other One Identity and Quest products Appendix F: Active Roles integration with Duo Appendix G: Active Roles integration with Okta

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:

  1. Prepare a Self-Administration Access Template that defines the appropriate permissions on user accounts.
  2. 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:

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating