You are viewing an earlier version of the admin guide. For the latest version, please visit EmpowerID Admin Guide v7.211.0.0.
Resource Entitlements Overview
- Phillip Hanegan
Resource Entitlements (RETs) or “Provisioning Policies” are one of the most important and useful features of the EmpowerID system. In EmpowerID, Resource Entitlements (RETs) are policies that govern how resources, such as an Active Directory account or an Exchange mailbox, are given to people. These policies are policies that you can write to automate the provisioning, moving, disabling, and de–provisioning of resources for users based on their roles, memberships, and locations within your organization. When RETs are in place, EmpowerID evaluates those policies each time an EmpowerID Person is provisioned or newly assigned to any one of the following EmpowerID actor types:
Business Role and Location
Management Role
Group
Query–Based Collection (Set Group)
RET policies can be targeted directly to individual people as well.
When a RET policy is targeted to one of the above actor types, be that an individual person or a collection of people – such as a Business Role and Location (BRL) combination – any person targeted by the policy receives all of the Resource Entitlements assigned at or above their primary and secondary Business Roles and Locations. When more than one Resource Entitlement of the same type is received, a priority value determines which one the person receives, with lower priority values having higher precedence.
The following image shows the possible targets of a RET policy. When a policy is targeted to a collective actor, such as those depicted below, every person belonging to that actor receives the entitlements specified by the policy. Thus, in the below image, each person belonging to the Help Desk in Customer Services BRL, the Help Desk Technicians group, the Enterprise IT Help Desk Management Role, and the All Users with Help Desk Titles Query–Based Collection would receive an AD user account, an Exchange mailbox, and a home folder.
The image below is only to demonstrate how RETs can be targeted to different actors in EmpowerID. However, as a best practice, a RET like the one depicted below would be assigned to only one actor type at a more global level, such as All Standard Employees in All Business Locations.
Depending on how a particular Resource Entitlement policy is configured, any change occurring to a person's status, such as a change to their Business Role and Location may trigger changes in the user accounts and resources assigned to that person. For example, if your company employs contractors along with standard employees, you could configure RET policies to automatically provision an Active Directory account, a mailbox, and a home folder each time a new employee is onboarded (rather than for each specific actor type as depicted above), but only provision an Active Directory account (within a different OU) and a mailbox for contractors. In the event a contractor becomes a standard employee, or an employee becomes a contractor, these policies could take the appropriate action and do things like move the user accounts for those people to the OU that corresponds to their role as well as provision or de-provision resources accordingly.
This process is dependent on the configuration of the Allow RET Provisioning and Allow RET De–Provisioning settings for the account store containing the user accounts. Accessible from the configuration screen for the account store in Configuration Manager, these settings tell EmpowerID whether RET policies can be applied to the user accounts that have been inventoried from that account store. The function of these settings is as follows:
Allow RET Provisioning – This setting allows or disallows the Resource Entitlement (RET) Inbox process to auto-provision accounts for this domain for users who receive RET policy–assigned user accounts, but have not yet had them provisioned.
Allow RET De–Provisioning – This setting allows or disallows the Resource Entitlement Inbox process to auto de-provision accounts for this domain for users who still have RET policy–assigned user accounts, but no longer receive a policy that grants them a user account in the domain. De–provisioning only occurs if the de-provision action on the Resource Entitlement policy is set to De–Provision.
How the Resource Entitlement Inbox Processes RETs
When resources are provisioned through Resource Entitlement policies, EmpowerID stores the RETID of the policy as a property on the resource. EmpowerID also "claims" existing resources and stamps them with the RETID of the policy that would have led to them being provisioned if they did not already exist. For example, if a person already has a resource, like an Exchange Mailbox, and moves into a role with a RET that calls for anyone in that role to be given a mailbox, EmpowerID will see that the person already has a mailbox and will simply update the ResourceEntitlementID field for that specific mailbox in the EmpowerID Identity Warehouse, stamping it with the RETID assigned to the Resource Entitlement policy. The RETID is then used to track why resources have been provisioned, to determine when they should be moved or de-provisioned, and to identify when a person is lacking resources that should be provisioned. This type of RET reevaluation is performed at runtime in workflows that provision people or change their roles. Additionally, optional background jobs called the "Resource Entitlement Inbox processes" can be used to perform this reevaluation continuously. In the event a particular Resource Entitlement is deleted, any provisioned resources automatically have their RETID set to NULL in the EmpowerID Identity Warehouse and are considered as "normal" resources by EmpowerID. This means these resources will be ignored by the RET Inbox and will remain joined to their Person objects. From that point forward, if a new RET is created it will claim those resources rather than provisioning new ones. These actions are determined by the settings entered for the RET when you create it in EmpowerID.
EmpowerID maintains detailed information about any RETs processed by the Resource Entitlement Inbox processor. Among this information are the Process Status codes, which provide feedback on the current processing status of any resource entitlement. These codes are as follows:
0 – not processed
1 – in progress
2 – completed
3 – error
4 – ignored
RET Settings
The following settings have particular importance for how EmpowerID treats the RET:
On Claim Action – Claiming occurs when EmpowerID discovers a person with a resource that matches a RET to which they are assigned, but the resource is not marked as having been provisioned by a RET. The Claim action marks the resource as a RET-managed resource and triggers the Claim Action specified by the RET policy. All Claim Actions are not implemented for all types of RETs. The On Claim Action drop-down allows you to specify what you want the system to do when a resource entitlement claims a RET. The four options and outcomes are:
Do Nothing – No changes are made.
Move – In the case of user accounts, moves the user object to the OU specified by the RET or as determined through the mapping of OUs to Business Roles and Locations.
Delete and Recreate – In the case of user accounts, deletes and recreates the user.
Register Event – Raises the event specified.
Because RETs require users to have accounts, EmpowerID enables any disabled user accounts it finds during a claim action if that account is linked to an EmpowerID Person meeting the claim condition.
On Transform Action – Transforming occurs when a person with a resource provisioned by one RET policy receives an equivalent RET from a different policy. This typically happens when a person changes their Business Role or Location. The Transform Action marks this resource with the new RET policy number and triggers the Transform Action specified by the new RET policy. All Transform Actions are not implemented for all types of RETs. The four options and outcomes are:
Do Nothing – No changes are made.
Move – In the case of user accounts, moves the user object to the OU specified by the RET or as determined through the mapping of OUs to Business Roles and Locations.
Delete and Recreate – In the case of user accounts, deletes and recreates the user.
Register Event – Raises the event specified.
On Revoke Action – This occurs when a person who received a resource via a RET no longer receives the RET policy, typically due to a change in Business Role or Location.
Do Nothing – No changes are made to the resource.
De-provision – Deletes the resource.
Disable – Disables the resource.
Register Event – Raises the event specified.
Claim Action Workflow Event – This is an optional setting that allows you to enter the name of a predefined EmpowerID event registration. The RET action will "fire" this event which then triggers the initiation of all workflows that subscribe to the event. The only requirement for these event workflows is an input property of the type Resource named "resource" (case sensitive). The RET process will pass in the resource of the Person's RET (Account, Home Folder, Exchange Mailbox, etc.) that triggered the event for further processing by the custom workflow(s). The custom workflows can be used to implement more advanced processes for deprovisioning or other events.
Transform Action Workflow Event – This is an optional setting that allows you to enter the name of a predefined EmpowerID event registration. The RET action will "fire" this event which then triggers the initiation of all workflows that subscribe to the event. The only requirement for these event workflows is an input property of the type Resource named "resource" (case sensitive). The RET process will pass in the resource of the Person's RET (Account, Home Folder, Exchange Mailbox, etc.) that triggered the event for further processing by the custom workflow(s). The custom workflows can be used to implement more advanced processes for deprovisioning or other events.
Revoke Action Workflow Event – This is an optional setting that allows you to enter the name of a predefined EmpowerID event registration. The RET action will "fire" this event which then triggers the initiation of all workflows that subscribe to the event. The only requirement for these event workflows is an input property of the type Resource named "resource" (case sensitive). The RET process will pass in the resource of the Person's RET (Account, Home Folder, Exchange Mailbox, etc.) that triggered the event for further processing by the custom workflow(s). The custom workflows can be used to implement more advanced processes for deprovisioning or other events.
For account provisioning via RETs or in workflow processes, EmpowerID ensures logon name uniqueness automatically by adding a 01, 02, etc., to the end of the generated name when a collision is detected. Naming convention workflow shapes in the creation workflows for the major types of objects (Person, Account, Group) can be completely customized in Workflow Studio. RET provisioning of new accounts is not handled by workflow processes but can still be customized.
Naming Conventions
For account provisioning via RETs or in workflow processes, EmpowerID ensures logon name uniqueness automatically by adding a 01, 02, etc., to the end of the generated name when a collision is detected. Naming convention workflow shapes in the creation workflows for the major types of objects (Person, Account, Group) can be completely customized in Workflow Studio. RET provisioning of new accounts is not handled by workflow processes but can still be customized.
AD/LDAP Account Creation Location Logic
When provisioning users automatically via RET policies into AD or LDAP directories, EmpowerID must determine into which OU a person's account should be provisioned. The default logic is to follow the RBAC mapping for the Location portion of a Person's Business Role and Location to create the account in the Account Store OU mapped to that EmpowerID Location. In some cases, this default logic is not desired and a custom rule should be implemented. For these cases, EmpowerID allows the creation of a plugin in Workflow Studio to handle this unique RET AD/LDAP Account Creation Location logic.
Next Steps
Create Provisioning policies for: