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

Active Roles 8.1.5 - Administration Guide

Introduction Getting started with Active Roles Configuring rule-based administrative views Configuring role-based administration Rule-based autoprovisioning and deprovisioning
Provisioning Policy Objects Deprovisioning Policy Objects How Policy Objects work Policy Object management tasks Policy configuration tasks
Property Generation and Validation User Logon Name Generation Group Membership AutoProvisioning Exchange Mailbox AutoProvisioning AutoProvisioning in SaaS products OneDrive Provisioning Home Folder AutoProvisioning Script Execution Microsoft 365 and Azure Tenant Selection E-mail Alias Generation 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
Using rule-based and role-based tools for granular administration Workflows
Key workflow features and definitions About workflow processes Workflow processing overview Workflow activities overview Configuring a workflow
Creating a workflow definition for a workflow 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
Approval workflow Email-based approval Automation workflow Activity extensions
Temporal Group Memberships Group Family Dynamic groups Active Roles Reporting Management History Entitlement profile Recycle Bin AD LDS data management One Identity Starling Join and configuration through Active Roles Managing One Identity Starling Connect Configuring linked mailboxes with Exchange Resource Forest Management Configuring remote mailboxes for on-premises users Migrating Active Roles configuration with the Configuration Transfer Wizard Managing Skype for Business Server with Active Roles
About Skype for Business Server User Management Active Directory topologies supported by Skype for Business Server User Management User Management policy for Skype for Business Server User Management Master Account Management policy for Skype for Business Server User Management Access Templates for Skype for Business Server Configuring the Skype for Business Server User Management feature Managing Skype for Business Server users
Exchanging provisioning information with Active Roles SPML Provider Monitoring Active Roles with Management Pack for SCOM Configuring Active Roles for AWS Managed Microsoft AD Azure AD, Microsoft 365, and Exchange Online Management
Configuring Active Roles to manage Hybrid AD objects Unified provisioning policy for Azure M365 Tenant Selection, Microsoft 365 License Selection, Microsoft 365 Roles Selection, and OneDrive provisioning Changes to Active Roles policies for cloud-only Azure objects
Managing the configuration of Active Roles
Connecting to the Administration Service 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 Using regular expressions Administrative Template Configuring federated authentication Communication ports Active Roles and supported Azure environments Integrating Active Roles with other products and services Active Roles Language Pack Active Roles Diagnostic Tools Active Roles Add-on Manager

Restoring a deleted object

For restoring deleted objects you can use the Restore command that is available from:

  • The View or Restore Deleted Objects dialog.

  • A list of search results prepared using the Deleted Objects search category in the Find dialog.

  • A list of objects held in the Deleted Objects container, which is displayed in the details pane when you select the Deleted Objects container in the Console tree.

In the Active Roles Console the command can be found on the shortcut menu, which appears when you right-click a deleted object.

To restore a deleted object

  1. In the View or Restore Deleted Objects dialog, click the deleted object and then click Restore.

    OR

    In a list of search results prepared using the Deleted Objects search category, or in a list of objects held in the Deleted Objects container, right-click the deleted object and click Restore.

  2. Review and, if necessary, change the settings in the Restore Object dialog, and then click OK to start the restore process.

The Restore Object dialog prompts you to choose whether deleted child objects (descendants) of the deleted object should also be restored. The Restore child objects check box is selected by default, which ensures that the Restore command applied on a deleted container object restores the entire contents of the container.

To clarify, consider an example in which an administrator accidentally deletes an Organizational Unit (OU) called Sales_Department that contains a number of user accounts for sales persons along with another OU called Admins that, in turn, contains a user account for an administrative assistant. When applying the Restore command on the Sales_Department OU, with the option to restore child objects, Active Roles performs the following sequence of steps:

  1. Restore the Sales_Department OU.

  2. Restore all the deleted user accounts that were direct children of the Sales_Department OU.

  3. Restore the Admins OU in the Sales_Department OU.

  4. Restore all the deleted user accounts that were direct children of the Admins OU.

If you clear the Restore child objects check box, Active Roles performs only the first step, so the restored Sales_Department OU is empty.

IMPORTANT: When restoring a deleted object, ensure that its parent object is not deleted. You can identify the parent object by viewing properties of the deleted object: the canonical name of the parent object, preceded by the deleted from: label, is displayed beneath the name of the deleted object on the General tab in the Properties dialog. If the parent object is deleted, you need to restore it prior to restoring its children because deleted objects must be restored to a live parent.

Delegating operations on deleted objects

The delegation model based on the Active Roles Access Templates is fully applicable to the administrative tasks specific to deleted objects. A new Access Template called All Objects - View or Restore Deleted Objects makes it easy to delegate the following operations to selected users:

  • Viewing deleted Active Directory objects.

  • Restoring a deleted Active Directory object.

When applied to the Deleted Objects container, the Access Template gives the delegated users the right to view and restore any deleted object. With the Access Template applied to an Organizational Unit (OU) or a Managed Unit (MU), the delegated users are given the right to view and restore only those deleted objects that were located in that OU or MU at the time of deletion.

To delegate the operation of restoring deleted objects

  1. In the Console tree, select Configuration > Access Templates > Active Directory.

  2. In the details pane, right-click All Objects - View or Restore Deleted Objects and click Links.

  3. In the Links dialog, click Add.

  4. Click Next on the Welcome page in the Delegation of Control Wizard.

  5. On the Objects page in the wizard, click Add; then, select the container in which you want to delegate the operation of restoring deleted objects:

    • To delegate restoring only those deleted objects that were in a particular Organizational Unit (OU) or Managed Unit (MU) at the time of deletion, select that OU or MU.

    • To delegate restoring any deleted objects in a particular managed domain, select either the object representing that domain or the Deleted Objects container for that domain.

    • To delegate restoring any deleted objects in any managed domain, select the Active Directory container.

  6. Follow the instructions on the wizard pages to complete the Delegation of Control Wizard.

  7. Click OK to close the Links dialog.

Although it is possible to delegate the operation of restoring deleted objects in any managed domain, OU or MU, a deleted object cannot be restored by using Active Roles unless the object belongs to a managed domain that has Active Directory Recycle Bin enabled. For more information on how to enable Recycle Bin, see Active Directory Recycle Bin Step-by-Step Guide.

Applying policy or workflow rules

In addition to the delegation of administrative tasks, Active Roles provides the ability to establish policy-based control over the process of restoring deleted objects. Policy rules can be used to perform additional verifications or custom script-based actions upon the restoration of deleted objects. Workflow rules can be applied so as to require approval for the restore operation or notify of the restore operation completion via email.

The policy or workflow rules to control the process of restoring or otherwise managing deleted objects can be defined on:

  • The Active Directory node in the Active Roles Console - The rules defined in this way affect all deleted objects in any managed domain that has Recycle Bin enabled.

  • The node representing a domain or the Deleted Objects container for that domain in the Active Roles Console - These rules affect all deleted objects in that domain only.

  • An Organizational Unit (OU) or Managed Unit (MU) that held the object at the time of deletion. Although the deleted object no longer belongs to that OU or MU, Active Roles considers the former location of the object so that the rules applied on that location continue to affect the object after the deletion.

For example, an administrator could create a workflow to require approval for the restoration of any user account that was deleted from a certain Organizational Unit (OU). The workflow definition would contain an appropriate approval rule, and have that OU specified as the target container in the workflow start conditions.

Policy rules are defined by configuring and applying Policy Objects.

To apply a Policy Object to the Deleted Objects container

  1. Right-click the Deleted Objects container and click Enforce Policy.

  2. In the Active Roles Policy dialog, click Add.

  3. In the Select Policy Objects dialog, select the check box next to the Policy Object you want to apply, and then click OK.

  4. Click OK to close the Active Roles Policy dialog.

For more information on configuring and applying Policy Objects, see Applying Policy Objects.

Workflow rules are defined by configuring workflow definitions and specifying the appropriate workflow start conditions.

To apply a workflow to the Deleted Objects container

  1. In the Console tree, select the workflow you want to apply.

    To select a workflow, expand Configuration > Policies > Workflow, and then click the workflow definition object under Workflow in the Console tree.

  2. In the details pane, click Workflow options and start conditions above the workflow process diagram, and then click Configure.

    This displays the Workflow Options and Start Conditions page.

  3. Click Select Operation, select the Restore option, and then click Finish.

    This will cause the workflow to start upon a request to restore a deleted object of the type specified.

  4. Click Add under Initiator Conditions.

  5. On the Add Initiator Condition page, click Browse and select the Deleted Objects container.

    You could select a container other than Deleted Objects. If you do so, the workflow starts only upon the restoration of an object that was deleted from the container you have selected.

  6. Complete configuring workflow start conditions.

For more information about workflows, see Workflows.

AD LDS data management

Active Roles provides the ability to manage directory data in Microsoft Active Directory Lightweight Directory Services (AD LDS), an independent mode of Active Directory formerly known as Active Directory Application Mode (ADAM).

A running copy of the AD LDS directory service is referred to as a service instance (or, simply, instance). To use Active Roles for managing data hosted by the AD LDS directory service, you first need to register the instance that holds the data to manage.

Once an instance has been registered, the Active Roles client interfaces—Console, Web Interface and ADSI Provider—can be used to access, view and modify directory data in the application and configuration partitions found on the instance. The instances registered with Active Roles are referred to as managed AD LDS instances.

To register an AD LDS instance with Active Roles

  1. Open the Active Roles Console.

  2. In the Console tree, expand Configuration > Server Configuration, right-click Managed AD LDS Instances (ADAM), and select New > Managed AD LDS Instance (ADAM) to start the Add Managed AD LDS Instance Wizard.

  3. Follow the instructions on the wizard pages.

  4. On the AD LDS Instance to Register page, specify the server name and port number of the AD LDS instance you want to register with Active Roles.

    In Server, type the fully qualified DNS name (for example, server.company.com) of the computer on which the instance is running. In LDAP port, type the number of the Lightweight Directory Access Protocol (LDAP) communication port in use by the instance (the default communication port for LDAP is 389). You can also click Select to locate and select the AD LDS instance you want to register.

  5. On the Active Roles Credentials page, specify the credentials that Active Roles will use to access the instance.

    If you want each Administration Service to connect to the instance in the security context of its own service account, click The service account information the Administration Service uses to log on. With this option, different Administration Services may have different levels of access to the instance (the service account of one Service may have administrative rights on the instance while the service account of another Service may not). As a result, switching from one Administration Service to another may cause Active Roles to lose access to the instance.

    If you want each Administration Service to connect to the instance using the same user account, click The Windows user account information specified below and type in the user name, password, and domain name. In this way, you specify a so-called override account, thereby causing the access rights of Active Roles on the instance to be determined by the access rights of that user account (rather than by those of the service account of the Administration Service).

  6. On the completion page, click Finish to start the registration process.

The override account you specify in Step 5 must, at a minimum, be a member of the following groups in the AD LDS instance:

  • Instances (CN=Instances,CN=Roles) in the configuration partition.

  • Readers (CN=Readers,CN=Roles) in the configuration partition and in each application partition.

If you choose not to specify an override account, you should add the service account to these groups.

To allow Active Roles full access to the AD LDS instance, add the service account or, if specified, the override account to the following group:

  • Administrators (CN=Administrators,CN=Roles) in the configuration partition

If you add the account to the Administrators group, you don’t need to add it to the Instances or Readers group.

Use the AD LDS ADSI Edit console to add the account to the appropriate groups prior to registering the instance with Active Roles.

After an AD LDS instance is registered, you can view or change its registration settings by using the Properties command on the object representing that instance in the Managed AD LDS Instances (ADAM) container. Thus, you can make changes to the choices that were made in Step 5 of the above procedure.

If you no longer want to manage an AD LDS instance with Active Roles, you can unregister the instance by using the Delete command on the object representing that instance in the Managed AD LDS Instances (ADAM) container. Unregistering an instance only removes the registration information from Active Roles, without making any changes to the directory data within that instance.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택