Chat now with support
Chat with Support

Active Roles 7.5.3 - 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 One Identity Starling Two-factor Authentication for Active Roles Managing One Identity Starling Connect 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 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 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: Enabling Federated Authentication Appendix F: Active Roles integration with other One Identity and Quest products Appendix G: Active Roles integration with Duo Appendix H: Active Roles integration with Okta

Report section: Undo Group Object Relocation

Report section: Undo Group Object Relocation
Table 48: Undo Group Object Relocation

Report Item (Success)

Report Item (Failure)

No changes to undo.

Not applicable

The group is moved to its original location.
Former location: name of container
Restored original location: name of container

Failed to move the group to its original location.
Current location: name of container
Failed to move to this location: name of container

Report section: Undo Group Object Permanent Deletion

Report section: Undo Group Object Permanent Deletion
Table 49: Undo Group Object Permanent Deletion

Report Item (Success)

Report Item (Failure)

No changes to undo.

Not applicable

Scheduled deletion of the group is canceled.

Failed to cancel scheduled deletion of the group.
The group is going to be deleted on this date: date

Container Deletion Prevention policy

A bulk deletion may occur in a situation where an administrator selects and deletes a container object, such as an Organizational Unit, that has subordinate objects. Although bulk deletions are rare, they are disruptive events you can guard against by leveraging a new policy—Container Deletion Prevention.

One of the most common bulk deletions is a container deletion, which occurs when Active Roles is used to delete a container object that holds other (subordinate) objects. By default, a container deletion has the following characteristics:

  • First, Active Roles builds a list of all the objects found in the container (subordinate objects), and then starts deleting the listed objects one by one.
  • Then, for every object in the list, Active Roles performs an access check to determine if the user or process that requested the deletion has sufficient rights to delete the object. If the access check allows the deletion, then the object is deleted; otherwise, Active Roles does not delete the object, and proceeds to deletion of a subsequent object in the list.
  • Finally, once all the subordinate objects are deleted, Active Roles deletes the container itself. If any of the subordinate objects are not deleted, the container is not deleted as well.

As a result of this behavior, an administrator who has full control over an organizational unit in Active Roles can accidentally delete the entire organizational unit, with all its contents, within a single operation. To prevent this, Active Roles provides for a certain policy to deny deletion of non-empty containers.

The Container Deletion Prevention policy defines a configurable list of names of object types as specified by the Active Directory schema (for example, the Organizational Unit object type). When an Active Roles client requests the deletion of a particular container, the Administration Service evaluates the request in order to determine whether the type of the container is in the list defined by the policy. If the container type is in the list and the container holds any objects, the Administration Service denies the request, preventing the deletion of the container. In this case, the client prompts to delete all objects held in the container before attempting to delete the container itself.

To configure a Container Deletion Prevention policy

  1. In the console tree, select Configuration | Policies | Administration | Builtin.
  2. In the details pane, double-click Built-in Policy - Container Deletion Prevention.
  3. On the Policies tab, select the policy from the list and then click View/Edit.
  4. On the Types of Containers tab, click Add and use the Select Object Type dialog box to select the type (or types) of container you want to protect, and then click OK.

    For example, you can select the Organizational Unit object type in order to prevent deletion of non-empty organizational units.

  1. Click OK to close the dialog boxes you opened.

The built-in Policy Object you have configured using the above instructions prevents deletion of non-empty containers in any managed domain.

You may not want Active Roles to prevent deletion of non-empty containers that are outside a certain scope (such as a certain domain, organizational unit, or Managed Unit), whereas deletion should be prohibited on the non-empty containers that fall within that particular scope. In this scenario, you need to create and configure a copy of the built-in Policy Object and apply that copy to the scope in question. Then, block the effect of the built-in Policy Object by selecting the Disable all policies included in this Policy Object check box on the Policies tab in the dialog box for managing properties of the Policy Object.

If you only need to allow deletion of non-empty containers within a certain scope, then you can simply block the effect of the built-in Policy Object on the object representing the scope in question. Thus, if you want to allow deletion of organizational units that fall within a certain Managed Unit, you can use the Enforce Policy command on that Managed Unit to display the dialog box for managing policy settings and then select the Blocked check box next to the name of the built-in Policy Object.

Protecting objects from accidental deletion

Another option to guard organizational units against accidental deletion is by using an Active Roles feature that allows you to deny deletion of particular objects. When creating an organizational unit by using Active Roles, you have the option to protect the newly created organizational unit from deletion. You can also use Active Roles to enable this protection on any existing organizational units or other objects in the managed Active Directory domains and Active Directory Lightweight Directory Services (AD LDS) partitions.

On the pages for creating an organizational unit in the Active Roles console or Web Interface, you can select the Protect container from accidental deletion check box. This option removes the Delete and Delete Subtree permissions on the organizational unit and the “Delete All Child Objects” permission on the parent container of the organizational unit. An organizational unit created with this option cannot be deleted, whether using Active Roles or other tools for Active Directory administration, as the deletion-related permissions are removed by applying the appropriate Access Templates in Active Roles and replicating the resulting permission entries to Active Directory.

The option to protect existing organizational units or other objects from deletion is available on the Object tab of the Properties page for an object in the Active Roles console or Web Interface. If you select the Protect object from accidental deletion check box on that tab, Active Roles configures the permission entries on the object in the same way as with the Protect container from accidental deletion option for an organizational unit. When somebody attempts to delete a protected object, the operation returns an error indicating that the object is protected or access is denied.

The option to protect an object from deletion adds the following Access Template links:

  • On the object to protect, adds a link to the Objects - Deny Deletion Access Template for the Everyone group.
  • On the parent container of the object, adds a link to the Objects - Deny Deletion of Child Objects Access Template for the Everyone group. (Active Roles does not add this link if it detects that a link of the same configuration already exists.)

The links are configured to apply the Access Template permission entries not only in Active Roles but also in Active Directory. This adds the following access control entries (ACEs) in Active Directory:

  • On the object to protect, adds explicit Deny ACEs for the Delete and Delete Subtree permissions for the Everyone group.
  • On the parent container of the object, adds an explicit Deny ACE for the “Delete All Child Objects” permission for the “Everyone” group. (Active Roles does not add this ACE if it detects that an ACE of the same configuration already exists.)

If you clear the Protect object from accidental deletion check box for a given object, Active Roles the updates the object to remove the link to the “Objects - Deny Deletion” Access Template in Active Roles along with the explicit Deny ACEs for the “Delete” and “Delete Subtree” permissions for the “Everyone” group in Active Directory. As a result, the object is no longer guarded against deletion. Note that clearing the check box for a particular object removes the Access Template links and ACEs from only that object, leaving the Access Template links and ACEs on the parent container intact. This is because the parent container may hold other objects that are protected from deletion. If the container does not hold any protected objects, you could remove the link to the “Objects - Deny Deletion of Child Objects” Access Template by using the Delegate Control command on that container in the Active Roles console, which will also delete the corresponding ACE in Active Directory.

It is possible to configure Active Roles so that the Protect container from accidental deletion check box will be selected by default on the pages for creating organizational units in the Active Roles console or Web Interface. To enable this behavior within a domain or container, apply the “Built-in Policy - Set Option to Protect OU from Deletion” Policy Object to that domain or container. This Policy Object ensures that organizational units created by Active Roles are protected from deletion regardless of the method used to create them. Thus, organizational units created using Active Roles script interfaces will also be protected by default.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating