Managing Access Policies

17 Managing Access Policies

The access policy management feature in Oracle Identity Manager allows you to understand the different features of access policy, create and manage access policy, manage provisioning multiple instances of the same resources via access policy.

It contains the following sections:

17.1 Terminologies Used in Access Policies

Important terminologies used in access policy management are Access Policy Owner, Resource, Account, Account Discriminator, and Application instance.

The following terminologies are associated with access policies:

Access Policy Owner: Access policy owner does not have any special privileges, as access policy configuration UI is available in the Identity Self-Service. Also there are no authorization checks added based on access policy owners in access policy management APIs.
Resource: A resource is a logical entity in Oracle Identity Manager that can be provisioned to a user or an organization in Oracle Identity Manager. For example, Microsoft Active Directory (AD), Microsoft Exchange, SAP, UNIX, and Database is modeled as a resource in Oracle Identity Manager.

Resources are templated definitions that are associated with one or more workflows called Provisioning Process in Oracle Identity Manager, which model the lifecycle management, such as how to provision, revoke, enable, and disable.

Resources also have entities called forms associated with them. Forms represent a collection of attributes associated with the resource. For instance, a form associated with AD server includes attributes such as SAM Account Name, Common Name, and User Principal Name. Forms also contain an attribute of type IT Resource. See the description of IT Resource Type in this section for details on IT resource type.
Account: Accounts are actual instances of a resource that are created and provisioned to a user or organization in Oracle Identity Manager. For example, an e-mail account on an Exchange server is an account (instance) of resource type Exchange.

Accounts have specific values for the attributes of the associated form.
Account Discriminator: Account discriminator is a collection of attributes on a form that uniquely identifies the logical entity on which accounts are created. This term is sometimes loosely referred to as a target. For instance, for an AD server, an account discriminator can be a combination of AD server (an attribute of type IT Resource) and Organization Name.

Attributes are marked as account discriminators by setting the Account Discriminator property of a Form field to True.
Application instance: Application instance is a combination of IT resource instance (target connectivity and connector configuration) and resource object (provisioning mechanism).

17.2 Features of Access Policies

Some of the key features of managing access policy are Direct Provisioning, Revoking or Disabling the Policy, Role Hierarchy, Denying a Resource, Evaluating Policies, Evaluating Policies for Reconciled and Bulk Load-Created Accounts, Access Policy Priority, Access Policy Data, and Provisioning Multiple Instances of the Same Resource via Access Policy.

This section describes the various features offered by the access policy engine in the following sections:

17.2.1 Direct Provisioning

Whenever an access policy is applied, the resources are directly provisioned/denied without any request being generated.

17.2.2 Revoking or Disabling the Policy

You must specify whether a resource in a policy must be revoked or disabled when the policy no longer applies. Based on your selection, the resources are automatically revoked from the users or disabled when the policy no longer applies to the users. Accounts and entitlements can either be revoked or disabled if policy no longer applies.

For each resource associated with an access policy, you must select any one of the following options:

Revoke: Selecting this option revokes the account and the entitlements associated with the access policy when the access policy is no longer applicable.
Disable: Selecting this option disables the account and revokes the entitlements associated with the access policy when the access policy is no longer applicable.
Keep account active if entitlement provisioned outside of Access Policy: Selecting this option keeps the account as active when the user has entitlements provisioned outside of the Access Policies for this resource.

Note:
This option is not selected by default.

When the Revoke option or the Disable option is selected, entitlements are always revoked with the policy no longer applies. If the Disable option is selected, then the entitlements associated with the resource are revoked when the policy no longer applies because the entitlements have been originally granted because of the role grant. The entitlements are added to the resource instance when the role is granted once again.

If two policies have the same resource in the policy definition with one having the Revoke option selected and the other one with the Disable option, then the Disable option takes precedence over the Revoke option. In other words, resources are disabled (and not revoked) when policy no longer applies.

17.2.3 Role Hierarchy

Role Hierarchy support for access policies is available. To enable this feature set the system property XL.AllowRoleHierarchicalPolicyEval value to true. When Role Hierarchy is enabled, access policy engine considers both the direct and indirect roles during Access Policy Evaluation.

17.2.4 Denying a Resource

While creating an access policy, you can select resources to be denied along with resources to be provisioned. If you first select a resource for provisioning and then select the same resource to be denied, then error message saying resource is already added. When same resource is added in two different policies, in one policy if the resource is denied and in the other it is provisioned. And both these policies are applicable to the user, then the resource that is denied takes precedence.

Note:

If a resource is denied by an access policy, then the resource is always denied, even if a different policy provisions it. Denying of resources is irrespective of access policy priority. Even if an access policy with lower priority denies a resource, it takes precedence over an access policy with higher priority.

17.2.5 Evaluating Policies

Access policy evaluation works in the following manner:

After role grant to user or update of policy definition, the users for whom policy evaluation is needed are identified and the entry is updated or added in the USER_PROVISIONING_ATTRS table.
Flag stored in USER_PROVISIONING_ATTRS. POLICY_EVAL_NEEDED is used to determine users for whom policy evaluation is required.
The Evaluate User Policies scheduled job is run to invoke policy evaluation and further actions on accounts. By default, this task is enabled and scheduled to run every 10 minutes. See "Predefined Scheduled Tasks" in the Administering Oracle Identity Governance for information about evaluate user policies scheduled tasks.
The scheduled task picks distinct user records (each record in this table is for distinct user) available in USER_PROVISIONING_ATTRS in the default batch size of 500 using 20 threads, which is 25 records per thread in the ascending order of update date. A JMS message is submitted for each user for access policy evaluation.

Access policy evaluation is shown in Figure 17-1.

Figure 17-1 Access Policy Evaluation

Description of "Figure 17-1 Access Policy Evaluation"

When the policy is created with Retrofit = true and the policy definition is changed by one of the following manner:

When a user is made a part of a role or removed from a role. The policy for the user is evaluated as part of the add or remove operation.
If the retrofit flag is set for the policy. The evaluations can happen in the following scenarios:
- Policy definition is updated. Policies are evaluated for all applicable users.
- A role is added or removed from the policy definition. Policies are evaluated only for roles that is added or removed.
  
  Note:
  
  After the role is applicable to the user, you must run the Evaluate User Policies scheduled job to make access policy applicable.
- A resource is added, removed, or the Revoke or Disable options are changed for the resource.
  
  When you change the Revoke and Disable options from one to the other, the existing resource instances are not re-evaluated immediately. This policy change takes effect only the next time the policy is evaluated by the Evaluate User Policies scheduled task.
- When policy data is updated or deleted. This includes both parent and child form data. Policies are evaluated for all applicable users.

When roles are assigned to or removed from a policy, then users are immediately marked for policy evaluation irrespective of the setting for Retrofit flag. The Retrofit flag can be used only to determine if users need to be marked for policy evaluation for access policy definition changes, which involves:

Priority of the policy changes
Resource associated to policy changes
The the Revoke or Disable options change
Parent or child data changes. In this scenario, if Retrofit is set to false, then users are not marked for policy evaluation although policy definition has changed.

Note:

For managing the evaluation of Access Policy for users in the Disabled status, set the value of the system property XL.DoNotEvaluateAPForDisableUsers. For details, see Default System Properties in Oracle Identity Manager

17.2.6 Evaluating Policies for Reconciled and Bulk Load-Created Accounts

The access policy engine can link access policies to reconciled accounts and to accounts created by the Bulk Load Utility. The access policies are then evaluated using the Evaluate User Policies scheduled job. To enable this feature, ensure the following:

Set the values of XL.AllowAPHarvesting and XL.AllowAPBasedMultipleAccountProvisioning system properties to TRUE.

For more information about these system properties, see and for information about setting the value of a system property, see Creating and Managing System Properties in the Administering Oracle Identity Governance.
Set the retrofit flag to ON for the policy to be linked by selecting Retrofit Access Policy.

For information about the retrofit flag, see Creating Access Policies. For information about updating a policy definition, see Managing Access Policies.
Populate the ITResource field in access policy defaults.

If the ITResource field is not populated, then the provisioning engine cannot determine the application instance to be associated with the account and the account will not be visible in the UI.
Designate a field on the process form as the discriminator field and set the value of the Account Discriminator property to True. Then, populate the access policy defaults for the account discriminator field.

For information about setting the discriminator field, see Enabling Multiple Account Provisioning.

After enabling the feature to link access policies to reconciled accounts and to accounts created by the Bulk Load Utility, the access policy harvesting flow is depicted in Figure 17-2.

Figure 17-2 Access Policy Harvesting Flow

Description of "Figure 17-2 Access Policy Harvesting Flow"

17.2.7 Evaluating Policies for Direct Provisioned and Request Created Accounts

The access policy engine can link access policies to accounts created by request and to accounts that are provisioned directly. To enable these features, perform the steps as in enabling the Reconciled and Bulk Load-Created Accounts feature described in Evaluating Policies for Reconciled and Bulk Load-Created Accounts with the following exceptions:

To enable linking access policies to accounts created by request, set the values of XL.APHarvestRequestAccount, XL.AllowAPHarvesting, and XL.AllowAPBasedMultipleAccountProvisioning system properties to TRUE.
To enable linking access policies to accounts that are provisioned directly, set the values of XL.APHarvestDirectProvisionAccount, XL.AllowAPHarvesting, and XL.AllowAPBasedMultipleAccountProvisioning system properties to TRUE.
To enable updating the account data with the policy defaults for the accounts linked to the access policies, set the values of the XL.APHarvesting.AllowAccountDataUpdate, XL.AllowAPHarvesting, XL.APHarvestRequestAccount, XL.APHarvestDirectProvisionAccount, and XL.AllowAPBasedMultipleAccountProvisioning system properties to TRUE.

For more information about these system properties, see Default System Properties in Oracle Identity Governance.

17.2.8 Access Policy Priority

Policy priority is a numeric field containing a number that is unique for each access policy you create. The lower the number, the higher is the priority of the access policy. For example, if you specify Priority =1, it means that the policy has the highest priority. When you define access policies through Oracle Identity System Administration, the value 1 is always added to the value of the current lowest priority and the resultant value is automatically populated in the Priority field. Changing this value to a different number might result in readjusting the priority of all the other access policies, thus ensuring that the priorities remain consistent. The following actions are associated with the priority number:

If the priority number entered is less than 1, then Oracle Identity Manager will change the value to 1 (highest priority).
If the priority number entered is greater than M, in which M is the current lowest priority, then Oracle Identity Manager will force to specify the value as less than or equal to M+1.
Two access policies cannot have the same priority number. Therefore, assigning an already existing priority number to an access policy will lower the priority by 1 for all policies of lesser priority.

Conflicts can arise from multiple access policies being applied to the same user. Because a single instance of a resource is provisioned to the user through access policies, Oracle Identity Manager uses the highest priority policy data for a parent form. For child forms, Oracle Identity Manager uses cumulative records from all applicable policies.

If there is more than one access policy created for the same resource but granting different sets of entitlements and having different behavior when policy no longer applies, then the access policy with Disable if no longer applies (DLNA) option enabled has the highest priority irrespective of the access policy priorities. For example, if there is an access policy with Revoke if no longer applies (RLNA) option enabled and another policy with DLNA option enabled, then the policy with DLNA option enabled has higher precedence. Irrespective of the order in which the policies are applied, as long as a policy with DLNA option enabled is applied to the user, the account is always disabled when the policy no longer applies.

If a policy with Disable if no longer applies is later converted to Revoke if no longer applies, then existing accounts that are associated with the policy are not updated to RLNA. The change is effective only for accounts to be created in future.

If a policy with RLNA is later converted to DLNA, then the accounts that are already revoked are not impacted. The change is effective only for accounts currently associated with this policy or accounts to be created in the future.

17.2.9 Access Policy Data

There are multiple ways in which process form data is supplied for resources during provisioning. The following is the order of preference built into Oracle Identity Manager:

Default values from the form definition using Oracle Identity Manager Design Console
Prepopulate adapters
Access policy data if resource is provisioned because of a policy
Data updated by Process Task

If a given option is available, then the rest of the options that are at a lower order of preference are overridden. For example, if Option 4 is available, then Options 3, 2, and 1 are ignored.

Note:

When XL.AllowRequestDataToPrepopAdapter system property is set to true, then Pre-populate Adapters data takes precedence over Access Policy data. That is, provisioning access policy data will be overridden with pre-populate adapters data. For more information about this system property, see Default System Properties in Oracle Identity Governance in the Administering Oracle Identity Governance.

17.2.10 Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator

In earlier releases of Oracle Identity Manager, access policies can be used to manage only a single account for a resource object. In other words, if you already have resource provisioned to user (account has been created in the target system) and if another instance of the same resource is to be provisioned to the same user via access policy, then it is not possible in earlier releases of Oracle Identity Manager. To achieve the functionality of provisioning multiple instances of resource to a user, prior to access policy enhancement in Oracle Identity Manager, you must clone the connector that represents the target system in Oracle Identity Manager. Cloning of connector is error prone and need a lot of effort for testing/maintenance of the cloned resources. Access Policy enhancement done for provisioning of multiple instances of resource in Oracle Identity Manager saves the time and effort on cloning connectors.

A target system, such as UNIX server, Active Directory (AD) server, database, SAP, or JD Edwards, is the external system to Oracle Identity Manager that must be provisioned to users in Oracle Identity Manager. The target system is represented by an entity called resource in Oracle Identity Manager. The server on which target system is installed is represented by IT resource in Oracle Identity Manager. And the login credentials provided to user accessing this target system is represented by an account in Oracle Identity Manager. A user can have multiple accounts on a single target system. For example, one account can be a service (administrator) account and another a regular account. Therefore, it is mandatory to have two accounts for a same user in a single target system. In addition, it is possible to have different instances of target system, such as multiple UNIX servers, database servers, and AD servers. As a result, it is required to create accounts on each instance of the target system for the same user. For implementation details, see Creating Separate Accounts for the Same User and Same Resource on a Single Target System.

In Oracle Identity Manager, access policies can provision multiple accounts in the same target system as well as a single account in multiple instance of the same target system. While evaluating access policies and provisioning resources to user, Oracle Identity Manager checks if the resource has already been provisioned to the user or not. This is determined by checking the resource key (OBJ_KEY) of the resource provisioned to user. To have multiple instances to be provisioned through access policy, another criteria called account discriminator along with OBJ_KEY is required to distinguish the multiple instances of the same resource. Therefore, access policy checks the resource key as well as account discriminator to decide if the resource has been provisioned or not.

The account discriminator is a field on a process form (account data) that distinguishes two accounts of the same user, which can be present on the same target system or different target systems. For example:

If user Jane.Doe is to be provisioned two accounts on two different UNIX servers, then IT resource can be used as account discriminator.
If user John.Doe is to be provisioned two accounts on the same database instance, then distinct login IDs can be used as account discriminator.

17.2.11 Access Policy Authorization

The following authorization capabilities related to access policies should be assigned to the user to get the appropriate access to access policies:

Access Policy - Create
Access Policy - Delete
Access Policy - Modify
Access Policy - View/Search

See Managing Administration Roles for information about admin roles and admin role capabilities. See Functional Capabilities for information about the different functional capabilities and their details.

17.3 Creating Access Policies

You can define an access policy for provisioning resources to users who have roles defined in the policy by using the Access Policy page.

Note:

Identity Audit policies (SoD) are not evaluated during the creation of an access policy.
The association of a role to an access policy is done as part of role management and not via the access policy UI.

To create an access policy:

Login to Oracle Identity Self Service.
Click the Manage tab.
Click the Roles and Access Policies box, select Access Policies. The Access Policy page is displayed.
Click Create to open the Create Access Policy page.
Enter information in the required fields indicated with an asterisk (*), such as access policy name and description.

Note:

The following special characters are not allowed in the access policy name:

Semicolon (;)

Hash (#)

Percentage (%)

Equal to (=)

Bar (|)

Plus (+)

Comma (,)

Forward slash (/)

Back slash (\)

Single quote (')

Double quote (")

Less than (<)

Greater than (>)
From the Owner list, select USER or ROLE as the policy owner type. Based on your selection, click the lookup icon and select a user or role as the policy owner.

If you do no select a policy owner type, then the access policy is created with the default policy owner type as USER and the logged in User as Owner.

If you select a policy owner type and do not select a policy owner value, which is USER or ROLE, and click Next, then a validation error is displayed that does not allow you to proceed to the next screen.
Select Retrofit to retrofit this access policy when it is created.

If you set the Retrofit option, then any changes to access policy data will be updated to existing users. For information about assigning access policies to roles, see The Access Policies Tab.

If you do not select this option, then existing role memberships are not taken into consideration.
Enter appropriate Priority Level.
Click Next. The Application page is displayed.
Click Add in the Provisioned Applications panel to select the application instance that needs to be provisioned. Add Application Instance window is displayed.

Select the application instance by using the filter search menu.
- Select the name of the application instance from the results table, and then click Add Selected.
  
  Note:
  
  If a child application is dependent on other application , adding child application instance will automatically add its parent application instance. Removing parent application instance is not permitted as long as child application instance is added. Duplicate Child Form records are not allowed and will be automatically removed on clicking Save.
- The names of the desired application instance to provision appear in the Selected list.
- To unassign the selected application instance, select the application instance in the Selected list and click Remove.
Click Select.
For each application instance listed in the page, select any one of the following options:
- Revoke: Selecting this option revokes the account and the entitlements associated with the access policy when the access policy is no longer applicable.
- Disable: Selecting this option disables the account and revokes the entitlements associated with the access policy when the access policy is no longer applicable.
See Revoking or Disabling the Policy and Evaluating Policies for more information about revoking or disabling accounts and entitlements when access policies no longer apply.
For the selected Application Instance, to provide additional information like parent data and child data, click on the Display name link of the selected application instance. Create Access Policy - General Attributes page opens.

Enter the required information and click Save.
Click Add, from the Denied Applications panel to select the application instance that needs to be denied. Add Application Instance window is displayed.

Select the application instance by using the filter search menu.
- Select the name of the application instance from the results table, and then click Add Selected.
- The names of the desired application instance to deny appear in the Selected list.
- To unassign the selected application instance, select the application instance in the Selected list and click Remove.
Click Finish to create the access policy.

A success message is displayed with the access policy name.

17.4 Managing Access Policies

You can modify information of existing access policies from the Access Policy page.

To manage access policies:

Login to Oracle Identity Self Service.
Click the Manage tab.
Click the Roles and Access Policies box, select Access Policies. The Access Policies page is displayed.
Search for the Access Policy you want to modify. Enter the Name or Description and click Search icon.
Select the Access Policy you want to modify and click Open on the toolbar.
Access Policy page is displayed with three tabs, Attribute, Applications, and Roles. You can modify the Attributes and the Applications details, but Roles information can not be modified.

17.5 Deleting Access Policies

Delete the access policy that are not required or are not in use.

To delete an Access Policy:

Login to Oracle Identity Self Service.
Click the Manage tab.
Click the Roles and Access Policies box, select Access Policies. The Access Policies page is displayed.
Search for the Access Policy you want to delete. Enter the Name or Description and click Search icon.
Select the Access Policy you want to delete and click Delete on the toolbar.

Note:

Access Policy can be deleted only if it is not associated with any Role. Ensure to remove all dependencies before deleting any access policy.

17.6 Provisioning Multiple Instances of the Same Resource via Access Policy

Provisioning multiple instances of the same resource via access policy by using account discriminator involves enabling multiple account provisioning, creating separate accounts for the same user and same resource on a single target system, provisioning multiple instances of a resource to multiple target systems, and limitation of provisioning multiple instances of a resource via access policy.

This section contains the following topics:

17.6.1 Enabling Multiple Account Provisioning

By default, Oracle Identity Manager does not support multiple account provisioning. To enable multiple account provisioning:

Set the value of the XL.AllowAPBasedMultipleAccountProvisioning system property to TRUE. For more information about this system property, see Creating and Managing System Properties in Administering Oracle Identity Governance.

When multiple account provisioning is enabled, you must define the appropriate account discriminator attributes. To do so:

Log in to the Design Console.
Update the process form as follows:
1. Expand Development Tools, and then double-click Form Designer.
2. Search and open the process form.
3. On the Form Designer tab, click Create New Version.
4. In the Create a New Version dialog box, enter a label in the Label field, and then click Save.
5. From the Current Version list, select the version that you created.
6. On the Properties tab, select the field that you want to designate as the discriminator field, and then click Add Property.
7. In the Add Property dialog box, select Account Discriminator as the property name, enter True in the Property Value field, and then click Save.
8. Click Make Version Active, and then click OK.
9. Click Save.

17.6.2 Creating Separate Accounts for the Same User and Same Resource on a Single Target System

Two distinct accounts can be created for the same user and same resource on a single target system via access policy. For example, it is required to create two accounts, a user account and service account on a single AD instance. The Active Directory target system is represented by the AD User resource in Oracle Identity Manager. This is implemented in the following way:

Create a AD User resource.
Create the user, such as JohnD.
In the process form, mark UD_ADUSER_ORGNAME as the discriminator field so that two distinct accounts have different login IDs.
Create two access policies as follows:
- For regular account:
  
  Access policy name: AP1
  
  Associated to role: Role1
  
  Resource to provision: AD User
  
  Process form having Discriminator field: User ID (UD_ADUSER_ORGNAME)
  
  Default value in access policy: Account1
- For service account:
  
  Access policy name: AP2
  
  Associated to role: Role2
  
  Resource to provision: AD User
  
  Process form having Discriminator field: User ID (UD_ADUSER_ORGNAME)
  
  Default value in access policy: Account2
Note:

You must create a prepopulate adapter associated with the process form to generate the values for User ID so that unique values are generated for this field.
Assign Role1 and Role2 to JohnD. Note that you will not see the resource provisioned right after completion of role assignment. You must either wait for the Evaluate User Policies scheduled task to run automatically or you run this scheduled task manually.

When Role1 is assigned to JohnD, the Account1 account is created in the AD User target system via the AP1 access policy. When Role2 is assigned to JohnD, Account2 is created in AD User via AP2. Therefore, two distinct accounts can be created for the same user and same resource on a single target system via access policy.

17.6.3 Provisioning Multiple Instances of a Resource to Multiple Target Systems

The following are the broad-level steps to provision multiple instances of a resource object to multiple target systems via access policy:

Create an IT resource type by using the IT Resources Type Definition Form in the Oracle Identity Manager Design Console. For information about using this form, see IT Resources Type Definition Form in Developing and Customizing Applications for Oracle Identity Governance.
Create multiple IT resource instances of the IT resource type that you created in step 1. For information about creating IT resources, see Creating IT Resources in Administering Oracle Identity Governance.

Here, IT resource instance is the account discriminator. See Provisioning Multiple Instances of the Same Resource via Access Policy by Using Account Discriminator for information about account discriminator.

Note:

Display the process form default for IT Resource. It is mandatory to display it. By doing so, you can successfully provision an application instance via access policy.
Create a process form with a field of type that you created in step 1.
Create a resource object.
Create a process definition, and associate the resource object and process form. For information about creating a process definition, see Creating a Process Definition in Developing and Customizing Applications for Oracle Identity Governance.
Create access policies associating a role and resource object. See Creating Access Policies for details.

17.6.4 Limitation of Provisioning Multiple Instances of a Resource via Access Policy

Provisioning multiple instances of a resource via access policy has the following limitations:

A single access policy cannot provision multiple instances of a resource to a user. Multiple access policies must be created to provision multiple instances of resource. You must create the same number of access policies as that of instances of same resource that is to be provisioned.
If a resource object has a process form that has fields marked as account discriminator fields, then the value of these fields must be specified in any access policy that provisions that resource. Otherwise, issues might be encountered, such as multiple accounts might be provisioned when the policies are evaluated next time.
If a resource object has a process form that has fields marked as account discriminator fields and if you use the access policy engine to provision this resource to one or more users, then the values of the account discriminator fields must remain constant throughout the lifecycle of the account. In other words, the values of the account discriminator fields must not be changed. This is because the access policy engine uses the resource object key and the account discriminator values to decide whether or not to provision a new account to the user.

By modifying account discriminator values, you modify the basis on which the provisioning decision had been taken. and the behavior of the access policy engine cannot be determined. Therefore, it is recommended that you do not modify account discriminator values. And the process form values of the account discriminator fields must not be changed.
If access policies are configured with different account discriminator values, they provision different accounts to the user.

Note:

Account discriminator values that are different only in casing (for example, abc and aBc) are also treated as different values. With this data, two accounts are provisioned to the end user.

17.7 Troubleshooting Issues with Evaluate User Policy Scheduled Job

In some cases, the Evaluate User Policy scheduled task may not trigger, process users, or process only a few users.

Any of the following could be the reasons:

The Evaluate User Policy scheduled task ran, but there are no users marked for policy evaluation.
Users were marked for policy evaluation, however the users are not active.
Policy evaluation was done, however provisioning operations failed.

In this case, the event handlers related to provisioning will be in CANCELLED state. Therefore, no accounts or entitlements are provisioned to the users.
The Evaluate User Policy scheduled task is not triggered due to an issue with the scheduler.

In this case, the scheduler issue needs to be troubleshooted separately.

To identify if the issue is with access policy, provisioning, or scheduler, perform the steps mentioned in the MetaLink note 1563379.1.