Once a custom policy type has been deployed, an Active Roles administrator can add a policy of that type to a Policy Object. This is accomplished by selecting the policy type in the wizard that creates a new Policy Object or in the wizard that adds a policy to an existing Policy Object.
Which wizards to use, depends upon the policy type category:
-
For a policy type of the Provisioning category, a policy of that type can be added only to a Provisioning Policy Object.
-
For a policy type of the Deprovisioning category, a policy of that type can be added only to a Deprovisioning Policy Object.
To configure a policy of a custom policy type
-
Follow the steps in the wizard for creating a new Policy Object or in the wizard for adding a policy to an existing Policy Object.
For example, if the policy type is of the Provisioning category, you could use the New Provisioning Policy Object Wizard opened by the New > Provisioning Policy command on a container under Configuration/Policies/Administration in the Active Roles Console.
-
On the Policy to Configure page in the wizard, click the type of the policy you want.
The Policy to Configure page lists the custom policy types together with the pre-defined Active Roles policy types. Each custom policy type is identified by the display name of the respective Policy Type object.
The custom policy types are organized in a tree-like structure that reflects the existing hierarchy of the Policy Type containers. For example, if a Policy Type container is created to hold a particular Policy Type object, the container also appears on the wizard page, so you may need to expand the container to view or select the policy type.
-
On the Policy Parameters page, set parameter values for the policy: Click the name of a parameter in the list, and then click Edit.
Parameters control the behavior of the policy. When Active Roles executes the policy, it passes the parameter values to the policy script. The actions performed by the script, and the results of those actions, depend upon the parameter values.
Clicking Edit displays a page where you can add, remove or select a value or values for the selected parameter. For each parameter, the policy script defines the name of the parameter and other characteristics, such as a description, a list of acceptable values, the default value, and whether a value is required. If a list of acceptable values is defined, then you can only select values from that list.
-
Follow the wizard pages to complete the wizard.
You can delete a Policy Type object when you no longer need to add policies of the type represented by that object.
Before you delete a Policy Type object, consider the following:
-
You can delete a Policy Type object only if no policies of the respective policy type exist in any Policy Object. Examine each Policy Object and remove the policies of that type, if any, from the Policy Object before deleting the Policy Type object.
-
Deleting a Policy Type object permanently deletes it from the Active Roles database. If you want to use this policy type again, you should export the Policy Type object to an XML file before deleting the object.
-
Deleting a Policy Type object does not delete the Script Module associated with that object. This is because the Script Module may be used by other policies. If the Script Module is no longer needed, it can be deleted separately.
To delete a Policy Type object
Using rule-based and role-based tools for granular administration
Although you can cover many administration scenarios with the exclusive use of either rule-based Managed Units (MUs) or role-based Access Templates (ATs), combining MUs and ATs in your administration workflow provides additional flexibility to achieve the highest level of granularity.
This is useful if you want to ensure that certain management resources (for example, departmental administrators or helpdesk agents) can access and administer only a specific set of resources (for example, the resources of a specific department or geography, or specific resource types within a department only).
The following example use cases demonstrate how to configure and delegate such high-granularity permissions to:
NOTE: Active Roles Console supports managing the following Azure AD resources with Managed Units:
However, Managed Units do not support any Azure mailbox types and dynamic distribution groups.
|
|
CAUTION: Hazard of data loss!
The combined AT and MU configurations described in these example scenarios are meant to delegate granular access for roles like departmental administrators or helpdesk agents.
Do not delegate such granular permissions to:
Otherwise, you can lose access to the Azure AD resources in the scope of the configured granular access. |
This scenario describes how to use the Managed Units (MUs) and Access Templates (ATs) of the Active Roles Console together to configure Azure group administration permissions with high granularity. In this example, the MUs and ATs are used to deny the read access of a group of helpdesk users to a specific Azure Microsoft 365 (M365) group. You can achieve this by:
-
Configuring an MU containing the M365 group that the helpdesk users should not access. For more information on this procedure, see Configuring a Managed Unit to hide specific Microsoft 365 groups.
-
Configuring an AT to deny access to that M365 group for the helpdesk users. For more information on this procedure, see Configuring an Access Template to hide Microsoft 365 Groups.
Prerequisites
To configure this example scenario, your organization must meet the following requirements:
-
To create MUs and ATs in the Active Roles Console, use an Active Roles Administration Service account. For more information, see Configuring the Administration Service account in the Active Roles Installation Guide.
-
The organization must already have one or more Azure tenants configured and consented for use with Active Roles. For more information, see Configuring a new Azure tenant and consenting Active Roles as an Azure application.
-
To ensure that the Helpdesk group receiving the granular read permission can still read other Azure groups, they must have the built-in Azure Microsoft365 Groups - Read All Attribute AT (or a custom AT based on this built-in AT) applied to them, with the affected Object being the Azure tenant of the managed Azure AD resources. For more information on how to apply an AT, see Applying Access Templates.
-
The users receiving the configured permissions must be on-premises or hybrid Active Directory users. You cannot delegate the configured granular permission to cloud-only Azure users.
