About Container Deletion Prevention
If you select and delete a container object that has child objects (for example, an Organizational Unit), you perform a bulk deletion.
While bulk deletions are rare, they can be still disruptive operations. To prevent accidental bulk deletion of your directory objects, Active Roles has a Container Deletion Prevention policy that you can configure in your organization.
By default, Active Roles performs bulk deletion on a container in the following way:
-
Active Roles builds a list of all the child objects found in the container.
-
Active Roles starts deleting the listed objects one by one.
-
For every object in the list, Active Roles performs an access check to determine if the user or process that requested the deletion has the required permissions 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 continues the process with the next object in the list.
-
Finally, once all child objects are deleted, Active Roles deletes the container itself. If any child objects are not deleted, Active Roles will not delete the container either.
While the permission check can prevent accidental deletion in many scenarios, administrators with full control over an Organizational Unit in Active Roles can still delete the entire OU with a single delete operation. To prevent this, Active Roles provides the Container Deletion Prevention policy, denying the deletion of non-empty containers.
NOTE: The Container Deletion Prevention policy defines a configurable list of object types as specified by the Active Directory schema (for example, the Organizational Unit object type). If an Active Roles client requests the deletion of a particular container, the Active Roles Administration Service evaluates the request to determine if the type of the container is in the list of the configured policy. If the container type is in the list and the container holds any objects, the Active Roles Administration Service denies the request, preventing the deletion of the container. Because of this, even if you otherwise have permissions to delete containers, first you must delete all objects in the container before deleting the container itself.
For more information on configuring a Container deletion prevention policy, see Configuring a Container Deletion Prevention policy in the Active Roles Administration Guide.
About the Protect container from accidental deletion option
You can also protect Organizational Units against accidental deletion by using the Protect container from accidental deletion option of the Active Roles Console or Web Interface when creating or modifying an OU in your managed Active Directory domains or Active DirectoryLightweight Directory Services (AD LDS) partitions.
This Protect container from accidental deletion option removes the Delete and Delete Subtree permissions on the OU, along with the Delete All Child Objects permission on the parent container of the OU. An OU created with this option cannot be deleted, regardless of whether you use Active Roles or other system-provided Active Directory administration tools, as the option removes the deletion-related permissions by applying the appropriate Access Templates in Active Roles, then replicating the resulting permission entries to Active Directory.
The option to protect existing OUs or other objects from deletion is available on the Properties > Object tab 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. After that, attempting to delete a protected object will result in the operation returning an error, indicating that the object is protected or access is denied.
Protecting objects from deletion this way adds the following Access Template links:
-
On the object to protect, Active Roles adds a link to the Objects - Deny Deletion Access Template for the Everyone group.
-
On the parent container of the object, Active Roles 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, Active Roles 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. However, 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 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: Clearing the Protect object from accidental deletion check box for a specific object removes the Access Template links and ACEs only from that object, leaving the Access Template links and ACEs on the parent container intact. This is because the parent container can hold other objects that are protected from deletion. If the container does not hold any protected objects, you can 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 RolesConsole, which will also delete the corresponding ACE in Active Directory.
TIP: You can 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 RolesConsole 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. As such, Organizational Units created using Active Roles script interfaces will also be protected by default.
About picture management rules
You can use the Active Roles Console or Web Interface to add a picture for a user, group, or contact object.
Using pictures (such as photographs or logos) is generally recommended, as they make it easier to recognize the user, group, or contact in email clients and web applications that can retrieve the picture from Active Directory. When you supply a picture for a user, group or contact via Active Roles, the picture is saved in the thumbnailPhoto attribute of that user, contact, or group in Active Directory.
Active Roles provides a policy to enforce the picture size limits, including maximum and minimum dimensions and the option to resize the picture automatically. When you add a picture to the user, group, or contact, Active Roles checks the dimensions of the picture, and does not apply the picture if it does not meet the policy settings. If automatic picture resizing is enabled, Active Roles reduces the dimensions of the picture as needed by downsampling the original picture.
For more information on viewing or configuring picture management rules, see Configuring picture management rules in the Active Roles Administration Guide.
About policy extension using custom Policy Types
By default, you can configure predefined Policy Types that are installed with Active Roles. These Policy Types are available via the Active Roles Console, and include Policy Types such as Home Folder AutoProvisioning or User Account Deprovisioning. However, you can extend the default list by adding new, custom Policy Types.
Each Policy Type determines:
-
A certain policy action (for example, creating a home folder for a user account).
-
A collection of policy parameters to configure the policy action (for example, parameters that specify the network location where to create home folders).
Active Roles supports creating custom policies based on the Script Execution built-in Policy Type. However, creating and configuring a script policy from scratch can be time-consuming. Custom Policy Types provide a way to mitigate this overhead. Once a custom Policy Type is deployed that points to a particular script, administrators can easily configure and apply policies of that type, having those policies perform the actions determined by the script. The policy script also defines the policy parameters specific to the Policy Type.
Custom Policy Types provide an extensible mechanism for deploying custom policies. This feature is implemented by using the Policy Type object class. You can create Policy Types via the Active Roles Console, with each object representing a specific custom Policy Type.
For more information on changing, exporting or deleting Policy Types, see Creating and managing custom Policy Types in the Active Roles Administration Guide.
