About rule-based autoprovisioning and deprovisioning
Active Directory (AD) supports delegating control with fine granularity. However, simply restricting control, access and permissions may not always be a sufficient or effective way of managing the resources of an organization.
Many directory administration processes (such as creating or disabling user accounts, enforcing user name conventions, resetting passwords, and so on) are based on predefined workflows that often share the same procedures. In practice, this means that administrators have to repeatedly perform configuration tasks with similar steps.
To make the management of such administrative tasks easier, Active Roles provides a policy-based administration solution to automate and speed up repeat procedures when administering on-premises, hybrid and Azure cloud-only objects. This approach is represented with Policy Objects, available in the Configuration > Policies > Administration node of the Active Roles Console.
For more information on configuring autoprovisioning and deprovisioning rules, see Configuring rule-based autoprovisioning and deprovisioning in the Active Roles Administration Guide.
Summary of Policy Objects
Each configured Policy Object contains one or more policies, defining either the behavior of the Active Roles system, or the actions that Active Roles performs when certain directory objects are created, modified, or deleted. This way, Active Roles can automate the administrative workflow within the organization.
Policy Objects specify what AD objects to change, how, when, whenever they are created, modified, or deleted. You can also configure policies to have Active Roles accept certain data changes only if they conform to the formatting requirements specified by the policy. This helps maintain control over the data stored in AD, and also keeps network objects in a consistent state with each defined policy.
To offer additional flexibility for configuring policies, Active RolesPolicy Objects can also run customizable scripts before or after running a task. These scripts are handled via the Script Execution Policy Objects.
Example: Use case for setting up a policy
A typical use case for an Active Roles policy is to automate the administration of a new employee. When creating a user account for a new employee, you can create a policy that makes Active Roles automatically perform all of the following steps:
-
Retrieve information from the HR database of the organization.
-
Use the retrieved information as the default data for filling user account properties, such as name, contact information, and so on.
-
Create a home folder and home share for the new user account.
-
Add the user account to all relevant groups within the organization.
-
Create an Exchange mailbox for the user account, and add the mailbox to the relevant distribution lists.
With one or more properly configured Policy Objects, this entire procedure can be performed either automatically, or with minimal manual administrator work. Without policies, it would require time-consuming manual administrative actions each time a new user is administered.
NOTE: Active Roles does not automatically check for changes in directory objects, containers or groups specified for provisioning in the configured Policy Objects. This means that if any changes are made in any directory resources in use in a policy, you must update the impacted policies manually. For example, if a directory group used by a Group Membership AutoProvisioning Policy Group is deleted, the Policy Group must be updated manually to reflect the changes.
Advantages of using Policy Objects
Configuring Policy Objects has the following advantages:
-
They reduce the workload and time needed to perform common administration duties by automating tasks, combining multiple tasks into a single workflow, or even eliminating certain tasks altogether.
-
They offer automated (or largely simplified) workflows for provisioning, reprovisioning and deprovisioning directory objects in the organization.
-
They improve network security.
-
They ensure the consistency of the managed AD objects across the organization.
-
They minimize administration errors.
Types of Policy Objects
To help you configure, organize and apply Policy Objects, they are grouped into two main categories in the Active Roles Console:
-
Provisioning Policy Objects are used to specify provisioning rules, such as:
-
Populating and validating directory data.
-
Creating account resources (such as home folders and mailboxes).
-
Administering access to resources within the organization.
-
Deprovisioning Policy Objects are used to deprovision a selected user or group. Deprovisioning rules can include:
-
Removing user accounts or email addresses.
-
Revoking group and distribution list memberships.
-
Disabling security permissions and application access rights.
Both categories can contain multiple Policy Objects. For more information on configuring these Policy Objects, see the relevant subsections of Policy configuration tasks in the Active RolesAdministration Guide.
Built-in Policy Objects
To help you get started with configuring policy-based administration in your organization, Active Roles includes a set of built-in Policy Objects that offer provisioning and deprovisioning rules to the most typical administrative use cases. To find the built-in Policy Objects, navigate to the following node of the Active Roles Console:
Configuration > Policies > Administration > Builtin
To help you configure Script Execution policies, Active Roles also ships with several built-in Script Modules that you can use to set up your own Script Execution policies. Find these built-in Script Modules in the following node of the Active Roles Console:
Configuration > Script Modules > Builtin
About Provisioning and Deprovisioning Policy Objects
A Policy Object is a collection of administrative policies that specifies the business rules to enforce. A Policy Object includes stored policy procedures and specifications of events that activate each procedure.
A Policy Object associates specific events with its policy procedures, that are either built-in procedures or custom scripts. This provides an easy way to define policy constraints, implement sophisticated validation criteria, synchronize different data sources, and perform a number of administrative tasks as a single batch.
Active Roles enforces business rules by linking Policy Objects to:
-
Active Roles administrative views (known as Managed Units).
-
Active Directory containers, such as Organizational Units.
-
Individual (leaf) directory objects, like user or group objects.
By choosing where to link a Policy Object, you determine the policy scope. For example, if you link a Policy Object to a container, all objects in the container and its sub-containers are normally subject to the Policy Object.
You can link different Policy Objects to different containers to establish container-specific policies. This is required, for example, if each Organizational Unit uses a dedicated Exchange Server to store mailboxes or file server to store home folders.
You can also link a Policy Object to a leaf object, such as a user object. As an example, consider a policy that prohibits changes to group memberships when copying a certain user object.
Policy Objects define the behavior of the system when directory objects are created, modified, moved, or deleted within the policy scope. Policies are enforced regardless of administrative rights of a user performing a management task.
IMPORTANT: Administrative policies configured via Policy Objects affect every user in their scope, even Active Roles Administrators.
For more information on configuring autoprovisioning and deprovisioning rules, see Configuring rule-based autoprovisioning and deprovisioning in the Active Roles Administration Guide.
Policy Object deployment considerations and event handlers
Active Roles enforces policies by applying Policy Objects to promote data integrity throughout the directory. This is done by generating and validating the data entered into the directory. Each Policy Object is basically a container that holds one or more policy entries (also referred to as policies).
There are several types of policy entries that can be configured within a Policy Object. The two major ones are Property Generation and Validation, and Script Execution. Property Generation and Validation policy entries provide a point-and-click interface for creating basic rules for attribute population. Script Execution policy entries enable the use of scripting for a broad range of custom actions that could supplement, extend, or replace the policy types included with Active Roles out of the box.
Just as with Group Policy Objects in Active Directory, the location that Active Roles’ Policy Objects are linked to is critical:
-
Any policies that are intended to affect the entire domain should be included into a Policy Object linked at the domain level. If needed, filtering can be used to exclude specific objects or containers (Organizational Units) from being processed by these policies.
-
If more than one object or containers needs to be excluded from the effect of a domain-wide policy, it is best to include those objects or containers explicitly into a Managed Unit and then apply policy filtering to that Managed Unit by using the Block Inheritance option.
From here, the best way to apply policies is at the top level of the directory tree they will affect. Usually, however policies are only needed to affect certain Organizational Units within the tree. In this case, a Managed Unit is the most effective way to apply the policies. Include the desired Organizational Units explicitly into a Managed Unit, and then link the Policy Object to that Managed Unit.
A policy consists of three major components. These are:
-
A policy entry that defines the policy
-
A Policy Object containing that policy entry
-
A Policy Object link that determines where the policy is applied in the directory
Typically, a single Policy Object includes all the entries for a specific set of policies. It is not efficient to create one entry per Policy Object since this defeats the purpose of having separation between the Policy Object and policy entries.
A policy cannot be filtered for specific sets of administrators. Once applied to a given object or container, a policy will be in effect for every administrator under every condition. This is unless a Script Execution policy is included as a policy entry that utilizes the IEDSEffectivePolicyRequest interface to override the policies determined by other policy entries. This interface is documented in Active Roles SDK.
Script Execution polices are policy entries that utilize scripts written in a scripting language such as Microsoft Windows PowerShell or VBScript. Policy scripts use event handles that are initiated before or after every action that can happen in the directory. See the following table for a list of these handlers.
Table 6: Event handlers
|
onPreCreate |
In a script policy applied to a container; receives control upon a request to create an object in that container. This enables a script to perform custom actions prior to creating an object. |
|
onPostCreate |
In a script policy applied to a container; receives control after a request to create an object in that container is completed. This enables a script to perform custom actions further to creating an object. |
|
onPreDelete |
Receives control upon a request to delete an object. Enables a script to perform custom actions prior to deleting an object. |
|
onPostDelete |
Receives control after a request to delete an object is completed. Enables a script to perform custom actions further to deleting an object. |
|
onPreModify |
Receives control upon a request to start changing object properties. Enables a script to perform custom actions prior to applying changes to an object. |
|
onPostModify |
Receives control after a request to change object properties is completed. Enables a script to perform custom action further to changing an object's property values. |
|
onPreMove |
In a script policy applied to a container, this function receives control upon a request to start moving an object from that container. This enables a script to perform custom actions prior to moving an object. |
|
onPostMove |
In a script policy applied to a container, this function receives control after a request to move an object to that container is completed. This enables a script to perform custom actions further to moving an object. |
|
onPreRename |
Receives control upon a request to start renaming an object. Enables a script to perform custom actions prior to renaming an object. |
|
onPostRename |
Receives control after a request to rename an object is completed. Enables a script to perform custom actions further to renaming an object. |
|
onPreGet |
Receives control upon a request to retrieve object properties. Enables a script to perform custom actions prior to starting the retrieval of an object's property values. |
|
onPostGet |
Receives control after a request to retrieve object properties is completed. Enables a script to perform custom actions following the retrieval of an object's property values. |
|
onPreSearch |
Receives control upon a request to start a search. Enables a script to perform custom actions prior to starting a search. |
|
onPreDeprovision |
Receives control upon a request to run the Deprovision operation. Enables a script to perform custom actions prior to starting the operation. |
|
onDeprovision |
Receives control in the course of processing a request to run the Deprovision operation. Enables the use of a script for customizing the behavior of the operation. |
|
onPostDeprovision |
Receives control after a request to run the Deprovision operation is completed. Enables a script to perform custom actions following the operation. |
|
onPreUnDeprovision |
Receives control upon a request to run the Undo Deprovisioning operation. Enables a script to perform custom actions prior to starting the operation. |
|
onUnDeprovision |
Receives control in the course of processing a request to run the Undo Deprovisioning operation. Enables the use of a script for customizing the behavior of the operation. |
|
onPostUnDeprovision |
Receives control after a request to run the Undo Deprovisioning operation is completed. Enables a script to perform custom actions following the operation. |
|
onPreUnDelete |
Receives control upon a request to run the Undelete operation. Enables a script to perform custom actions prior to starting the operation. |
|
onPostUnDelete |
Receives control after a request to run the Undelete operation is completed. Enables a script to perform custom actions following the operation. |
|
onCheckPropertyValues |
Receives control upon a request to verify and validate the changes that are going to be made to an object. Enables a script to perform custom actions further to normal validity checks on an object. |
|
onGetEffectivePolicy |
Receives control upon a request to retrieve the policy settings that are in effect on a particular object (such as policy constraints on property values). Enables a script to perform custom actions further to retrieval of policy settings. |
|
onInit |
Receives control when the Administration Service retrieves the definition of the script parameters, enabling the script to manifest the name and other characteristics of each parameter. |
|
onFilter |
Boolean-valued function that is evaluated during execution of the onPreSearch event handler, allowing search results to be filtered based on properties of objects returned by the search. |
Basically, when an action happens, Active Roles looks to see if there are any Policy Objects applied that hold Script Execution policies. If so, the policy script is checked to see if it has an event handler for the specific action being performed. The object being acted upon is passed into the event handler for further actions. These event handlers are normally run in the security context of the service account, so even if a user does not have rights to perform the actions outlined in the policy script, it will still run correctly. If any errors occur during the execution of a policy script, the errors can be found in the Active Roles event log for post-action handlers and are displayed to the client for pre-action handlers.
Policy scripts are typically written in a scripting language such as Windows PowerShell or VBScript.
It is also important to note that policy scripts can pick up and take action upon directory changes made natively, as well. To turn on this behavior, you should choose the option that directs in the policy script to handle directory changes reported by the directory synchronization function (select the Handle changes from DirSync control check box on the Script Module tab in the Properties dialog for the policy entry), and use the IEDSRequestParameters interface in a post-action event handler.
Application of provisioning or deprovisioning Policy Objects
Implementing a policy to enforce business rules is a two-phase process where configuring the policy within a Policy Object is only the first step. When you create a new policy, you select a policy type from the available options, then define the options that make up the policy. The second step is to use Active RolesConsole to enforce the policy on the selected areas of the directory.
Active Roles allows enforcing of policies on any type of directory object, whether it is an administrative view (Managed Unit), a directory folder (container) or an individual (leaf) object. Policies are enforced by applying (linking) a Policy Object that holds the policies.
When you apply a Policy Object to a Managed Unit or directory folder, the policies control both the objects as well as the Managed Unit or folder that contain the objects. When you apply a Policy Object to a leaf object, such as a user or group, the policies only control that object. For example, applying a Policy Object to a group does not affect the members of the group.
Objects that are assigned to a Policy Object, that is, the objects controlled by the policies that are defined in that Policy Object, are collectively referred to as the policy scope. For example, if you apply a Policy Object to a Managed Unit, the policy scope is composed of the objects within the Managed Unit.
The policy scope normally includes all objects within the container or Managed Unit to which the Policy Object is applied. However, you might need to exclude individual objects or sub-containers from the policy scope, to prevent certain objects from being affected by policies.
TIP: You can selectively exclude objects or entire containers from the policy scope. You can also block policy inheritance on individual objects or containers, refining the policy scope.
For more information on applying policy objects, see Applying Policy Objects in the Active Roles Administration Guide.
