13.2 Built-in Policy

Built-in policies are implemented when you install the Administration server. When you work with these policies, you may encounter the following terms:

Policy scope: Defines the objects or properties to which DRA applies the policy. For example, some policies allow you to apply a policy to specific AAs in specific ActiveViews. Some policies let you choose from different classes of objects, such as user accounts or groups.
Global policies: Enforce policy rules on all objects of the specified class or type in the managed domains. Global policies do not let you limit the scope of the objects to which the policy applies.
Policy relationship: Defines whether the policy applies jointly or by itself. To establish a policy relationship, define two or more rules that apply to the same action, and choose the member of a policy group option. If the operation parameters or property matches any of the rules, the operation succeeds.

13.2.1 Understanding Built-in Policies

Built-in policies provide business rules to address common security and data integrity issues. These policies are part of the default security model, allowing you to integrate DRA security features into your existing enterprise configuration.

DRA provides two ways to enforce policy. You can create custom policies or choose from several built-in policies. Built-in policies make it easy to apply policy without having to develop custom scripts. If you need to implement a custom policy, you can adapt an existing built-in policy to fit your needs. Most policies allow you to modify the error message text, rename the policy, add a description, and specify how to apply the policy.

A number of built-in policies are enabled when you install DRA. The following policies are implemented by default. If you do not want to enforce these policies, you can disable them or delete them.

Policy Name	Default Value	Description
$ComputerNameLengthPolicy	64 15 (pre-Windows 2000)	Limits the number of characters in the computer name or the pre‑Windows 2000 computer name
$GroupNameLengthPolicy	64 20 (pre-Windows 2000)	Limits the number of characters in the group name or the pre-Windows 2000 group name
$GroupSizePolicy	5000	Limits the number of members in a group
$NameUniquenessPolicy	None	Ensures pre-Windows 2000 and CN names are unique in all managed domains
$SpecialGroupsPolicy	None	Prevents unchecked escalation of powers in the environment.
$UCPowerConflictPolicy	None	Prevents escalation of power by making User Clone and User Create powers mutually exclusive
$UPNUniquenessPolicy	None	Ensures UPN names are unique in all managed domains
$UserNameLengthPolicy	64 20 (down-level logon name)	Limits the number of characters in the user logon name or the down-level logon name

13.2.2 Available Policies

DRA provides several polices you can customize for your security model.

NOTE:You can create a policy that requires an entry for a property that is not currently available from the DRA user interfaces. If an entry is required by policy and the user interface does not provide a field to enter the value, such as a department for new user account, you will not be able to create or manage the object. To avoid this issue, configure policies that require only those properties that can be accessed from the user interfaces.

Create a Custom Policy

Allows you to link a script or executable to a DRA or Exchange operation. Custom policies let you validate any operations you choose.

Enforce a Maximum Name Length

Allows you to globally enforce maximum name length for user accounts, groups, OUs, contacts, or computers.

The policy checks the name container (common name, or cn) and the pre-Windows 2000 name (user logon name).

Enforce Maximum Number of Group Members

Allows you to globally enforce limits on the number of members in a group.

Enforce Unique Pre-Windows 2000 Account Names

Verifies that a pre-Windows 2000 name is unique across all managed domains. In Microsoft Windows domains, pre-Windows 2000 names must be unique within a domain. This global policy enforces this rule across all managed domains.

Enforce unique User Principal Names (UPNs)

Verifies that a user principal name (UPN) is unique across all managed domains. In Microsoft Windows domains, UPNs must be unique within a domain. This policy enforces this rule across all managed domains. Because this is a global policy, DRA provides the policy name, description, and policy relationship.

Limit actions on members of special groups

Prevents you from managing members of an administrator group unless you are a member of that administrator group. This global policy is enabled by default.

When you limit actions on members of the administrator groups, the Create Policy Wizard does not require additional information. You can specify a custom error message. Because this is a global policy, DRA provides the policy name, description, and policy relationship.

Prevent AAs from Creating and Cloning Users in Same AV

Prevents possible escalation of powers. When this policy is enabled, you can either create user accounts or clone user accounts, but you cannot have both powers. This global policy ensures that you cannot create and clone user accounts in the same ActiveView.

This policy does not require additional information.

Set Naming Convention Policy

Allows you to establish naming conventions that apply to specific AAs, ActiveViews, and classes of objects, such as user account or groups.

You can also specify the exact names monitored by this policy.

Create a Policy to Validate a Specific Property

Allows you to create a policy to validate any property of an OU or an account object. You can specify a default value, a property format mask, and valid values and ranges.

Use this policy to enforce data integrity by validating particular entry fields when you create, clone, or modify properties of specific objects. This policy provides tremendous flexibility and power to validate entries, provide default entries, and limit entry choices for various property fields. By using this policy, you can require that a correct entry be made before the task is completed, thereby maintaining data integrity across your managed domains.

For example, assume you have three departments: Manufacturing, Sales, and Administration. You can limit the entries DRA will accept to just these three values. You can also use this policy to enforce proper telephone number formats, supply a range of valid data, or require an entry for the email address field. To specify multiple format masks for a telephone number, such as (123)456 7890 as well as 456 7890, define the property format mask as (###)### ####,### ####.

Create Policy to Enforce Office 365 Licenses

Allows you to create a policy to assign Office 365 licenses based on Active Directory group membership. This policy also enforces the removal of Office 365 licenses when a member is removed from the relevant Active Directory group.

If a user who is not synced to the cloud is added to the Active Directory group, the user will be synced before an Office 365 license is assigned to the user.

During the creation of the policy you can specify several properties and settings, such as the name of the policy and the wording of the error message that appears when an AA attempts an action that violates this policy.

By default, policies that you create to enforce Office 365 licenses will not be applied when changes are made outside of DRA unless you also enable the License update schedule on the tenant properties page.

IMPORTANT:The setting below, which is configurable per tenant, was added to the Tenant Properties configuration in the DRA 9.2.1.4 patch update. This setting is used for DRA Office 365 license policies to configure how license assignments will be enforced:

Ensure only licenses assigned by DRA policies are enabled on accounts. All other licenses will be removed.

When this setting is enabled, the DRA license enforcement will ensure that only licenses assigned through DRA policies are provisioned to accounts (licenses assigned outside of DRA will be removed from the accounts assigned to the license policy). When this setting is disabled (default), DRA license enforcement will only ensure that the specific licenses you have included in your O365 polices are provisioned to accounts (when an account is unassigned from a license policy, only the licenses assigned by that policy will be de-provisioned).

13.2.3 Using Built-in Policy

Because built-in policy is part of the default security model, you can use these policies to enforce your current security model or modify them to better meet your needs. You can change the name, rule settings, scope, policy relationship, and error message of several built-in policies. You can enable or disable each built-in policy.

You can also easily create new policies.