지금 지원 담당자와 채팅
지원 담당자와 채팅

Active Roles 8.0 LTS - 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 Microsoft 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 Active Roles Language Pack

About workflow processes

The logic of an automated management process can be implemented by using administrative policies in Active Roles. Yet creating and maintaining complex, multi-step processes in that way can be challenging. Workflows provide a different approach, allowing IT administrators to define a management process graphically. This can be faster than building the process by applying individual policies, and it also makes the process easier to understand, explain, and change.

The figure below shows a workflow process created in the Active Roles console. In this simple example, upon a request to add a user to a certain group, the workflow first checks to see if the group has an owner. If the group has no owner, the requested changes are denied and the workflow is complete; otherwise, the changes are submitted to the group owner for approval. When approval is received, Active Roles applies the changes, adding the user to the group. On the process diagram, this step is referred to as Operation execution. If the owner rejects the changes, the workflow finishes on the previous (approval) step so that the changes are not applied. After the changes are made, the workflow sends an e-mail notification to the person who requested the changes, and then finishes.

Figure 102: Workflow process in Active Roles

In the above example, the workflow manages the process of adding a user to a group according to the rules defined at design time. The rules constitute the workflow definition, and include the activities that occur within the process and the relationships between activities. An activity in a process definition can be a pre-defined function available out of the box, such as a request for approval or a notification of conditions that require user interaction, or it can be a custom function created using script technologies.

A workflow process starts when the requested changes meet the conditions specified in the workflow definition. In the above example, the conditions may set up so that the workflow starts whenever an Active Roles user makes changes to the membership list of a certain group. Once the conditions are fulfilled, the workflow process starts to drive the changes through the workflow definition, performing automated steps and, if necessary, requesting human interaction such as approval.

Workflow processing overview

In Active Roles, directory objects such as users, groups, or computers are managed by the Administration Service. These objects can be created, changed, or deleted through requests made to the Administration Service. Every request initiates an operation to make the requested changes to directory data. For example, a request to create a user or group initiates the Create operation with the target object type set to User or Group, respectively; a request to add users to a group initiates the Modify operation on that group.

Once an operation has been initiated, the Administration Service starts processing the operation. Each operation is represented by a single object, usually referred to as the Request object, which contains all information necessary to perform the operation. Therefore, operation processing takes the form of passing the Request object through a number of phases within the Administration Service.

The operation processing model in Active Roles is composed of four main phases: access check, pre-execution, execution, and post-execution. The Request object passes through these phases in the following order:

  • Access check.  In this phase, the Administration Service checks to see whether the user or system that issued the request has sufficient rights to make the requested changes. If there are insufficient rights, the operation is denied.
  • Pre-execution.  During this phase, the Administration Service first runs the pre-execution workflow activities. These are the activities located in the upper part of the workflow process diagram, above the Operation execution line. A typical example includes Approval activities: It is at this point that approvers can permit or reject the operation.

    Then, after the pre-execution activities are completed so that the operation is not rejected, the Administration Service runs the pre-execution policies. Typical examples of such policies include property generation and validation rules and the functions implementing so-called pre-event handlers in script policies.

  • Execution  In this phase, the Administration Service performs the operation, making the requested changes to directory data. For example, when the creation of a user is requested, the user is actually created during this phase.
  • Post-execution.  During this phase, the Administration Service first runs the post-execution policies. For example, upon creation of a user, the provisioning of a home folder or group memberships for that user occurs at this point. The functions that implement post-event handlers in script policies are also run in this step.

    Finally, after the post-execution polices finish running, the Administration Service runs the post-execution workflow activities. These are the activities located in the lower part of the workflow process diagram, beneath the Operation execution line. A typical example is Notification activities that send out e-mails informing of the operation completion.

The Administration Service runs the workflow activities one by one, in sequential order as shown on the workflow process diagram, until the last activity finishes. If-Else activities can be used to achieve conditional branching in workflows, which makes it possible to switch the sequence of activities depending on the data involved in the request.

At the beginning of the pre-execution phase, the Administration Service determines the workflows to start. The request is compared to all the existing workflow definitions. In order for a workflow to start, the requested operation needs to satisfy the start conditions defined for that workflow. If the start conditions are satisfied, the workflow is matched to the request.

For a workflow that is matched to the request, the Administration Service runs the activities found in that workflow during the corresponding phases of the operation processing. One workflow or multiple workflows can be matched to a single request. In case of multiple workflows, the Administration Service starts each of them one by one, and first runs all the pre-execution activities included in those workflows. Then, during the post-execution phase, the Administration Service runs all the post-execution activities included in those workflows.

If multiple workflows are matched to a single request, then Active Roles uses the edsaWorkflowPriority attribute of the workflow definition object to determine the order in which to execute the workflows. The activities of the workflow with a lower value of that attribute are executed prior to the activities of the workflow with a higher value of that attribute. The workflows with the same priority value are executed in ascending order of workflow names. The edsaWorkflowPriority attribute is set to 500 by default. If the edsaWorkflowPriority attribute is not set, Active Roles assumes that the workflow has the priority value of 500. You can change the value of the edsaWorkflowPriority attribute to ensure that a given workflow takes precedence over other workflows. A lower value of that attribute indicates a higher priority whereas a higher value indicates a lower priority. To view or change the edsaWorkflowPriority attribute, use the Advanced Properties command on the workflow definition object in the Active Roles console.

About start conditions

To deploy a workflow in Active Roles, you create a workflow definition, configure the start conditions for that workflow, and add and configure workflow activities. When configuring workflow start conditions, you specify:

  • A type of operation, such as Create, Rename, Modify or Delete; the workflow is matched to the request only if an operation of that type is requested.
  • A type of object, such as User, Group or Computer; the workflow is matched to the request only if the operation requests changes to an object of that type.
  • For the Modify operation type, a list of object properties; the workflow is matched to the request only if the operation requests changes to any of those properties of an object.
  • The identity of an operation requestor (initiator), such as a user, group, or service; the workflow is matched to the request only if the operation is requested on behalf of that identity.
  • A container, such as an Organizational Unit or Managed Unit; the workflow is matched to the request only if the operation requests changes to, or creation of, an object in that container.
  • (Optional) A filter that defines any additional conditions on entities involved in an operation; the workflow is matched to the request only if the operation satisfies those conditions. If no filter is set, then no additional conditions are in effect.

Upon a request for any operation that meets all the start conditions specified on a workflow, the Administration Service matches the workflow to the request and runs the activities found in the workflow.

 

 

 

Workflow activities overview

Activities are units of work, each of which contributes to the accomplishment of a workflow process. Active Roles offers a default set of activities that provide pre-defined functionality for approval, notification, control flow, and conditions. Scripting can be used to have an activity perform custom functions.

Activities are the primary building blocks for workflows. A workflow is basically a set of activities organized in a process diagram. When you construct a workflow using the Workflows Designer, you drag activities from the activities panel onto the process diagram and then configure them there. The configurable settings common to every activity are:

  • Name.  The name is used to identify the activity on the workflow diagram.
  • Description.  This optional text can be helpful to distinguish the activity. The description is displayed when you point with the mouse to the activity on the process diagram.

The following sections elaborate on the types of activity that are included with Active Roles, and provide information about the configurable settings specific to each activity type.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택