Explaining IM Task Settings (User Synchronization and Account Synchronization)

Products

• CA Identity Manager
• CA Identity Governance
• CA Identity Portal

Issue/Introduction

There are configuration settings either on a task level or for the entire environment/installation which will alter product execution. While there are no set recommendations, understanding these settings will aid in trying to determine how best to configure the application for the environment that it is running in.

 

Background:  

IM Tasks contain settings for User Synchronization and Account Synchronization. These settings will control when Identity Policies are evaluated as well as when and how IM will perform outbound requests to the Provisioning Server. In addition there are other settings which can aid in serializing some requests from the IM Server to the Provisioning Server.

 

 

Environment

Release: 14.4
Component: IDMGR

Cause

User Synchronization (default value on most tasks is OnTaskCompletion)

The User Synchronization setting only impacts Identity Policy evaluations so the setting really should be thought of as the "Identity Policy Evaluation" setting instead.

Resolution

On Task Completion - The SynchronizeUserEvent will occur after all primary and secondary events are completed but before the SynchronizeAttributesWithAccountsEvent (if there is one)

• On Every Event - The SynchronizeUserEvent will occur after each primary and secondary event completes
• Off - The SynchronizeUserEvent will not occur at all
• For performance reasons the User Synchronization task setting should really only be set to either On Task Completion if the task needs to evaluate Identity Policies or set to Off if it does not need to evaluate Identity Policies. Note that the IM Environment could have a Recursion Level other than 1 set in the IM Management Console under IME->Advanced Settings->Identity Policies which could lead to even more SynchronizeUserEvent being triggered.

Account Synchronization (default value on most tasks is OnTaskCompletion)

The Account Synchronization setting only impacts the outbound synchronization to the Provisioning Server so the setting really should be thought of as the "Provisioning Outbound Synchronization" setting instead. There is no right value to set this to.

• On Task Completion- The IM Server will write all of the updates to the IM userstore during each event but will not write out to the Provisioning Server during those events. The exception to this is with the assignment of Provisioning Roles where the AssignProvisioningRoleEvent, RemoveProvisioningRoleEvent, and AccumulatedProvisioningRolesEvent will send a modify to the Provisioning Server to update the Provisioning global user but will not include the eTSyncUsers=1 or eTSyncDelete=1 flags so the Provisioning Global User gets the role change but does not take any action on accounts. Assignment of a Provisioning Role to an IM User will still trigger the request to the Provisioning Server to create the Provisioning Global User but this is done as an aside from any specific event execution and happens prior to the completion of the task. When all of the primary/secondary events are complete (and after any SynchronizeUserEvent or PX Policy generated secondary events) then the SynchronizeAttributesWithAccountsEvent will occur which will do the following:

 

• 1) Compare the IM user with the Provisioning Global User to see which attributes that are defined in the IME attribute mappings are out-of-sync and add those userstore values to the changeset of what attribute values were submitted as part of the task
• 2) Resend the current IM user's %ENABLED_STATE% value to the Provisioning Global User's eTIMEnabledState attribute and also trigger the updating of the Provisioning Global User's eTSuspended attribute
• 3) Re-send the Provisioning Role changes to the Provisioning Global User again but this time include the eTForceSync flag and the eTSyncUsers/eTSyncDelete flag in order to actually trigger account creates/deletes (this is the very last thing done by the task)

Note: If the IM user store is not the authoritative source of data then the compare that is done that will augment the change-set along with the resending of the %ENABLED_STATE% could update the Provisioning Global Users (and associated accounts) unexpectedly which could be a bad thing. Also attempting to use PX Policies to further manipulate newly created accounts is not possible since those accounts would be created after the secondary events generated by the PX Policies.

• On Every Event - There will be no SynchronizeAttributesWithAccountsEvent so the above items will not occur. Instead the IM Server will write out to the Provisioning Server during the execution of each primary and secondary event. The assignment of Provisioning Roles where the AssignProvisioningRoleEvent, RemoveProvisioningRoleEvent, and AccumulatedProvisioningRolesEvent execute will send a modify to the Provisioning Server to update the Provisioning global user and will include the eTSyncUsers=1 or eTSyncDelete=1 flags so the accounts will be created/deleted at that time and not be the very last thing done by the task which allows for PX Policies of type=SubmittedTask on TaskCompletion to read/modify those accounts. The Provisioning Global User status (and associated accounts) will not have its Status updated unless such an update was part of the submitted task changeset.

Note: If there are many PX Policies configured to execute then there will be many more secondary events generated and this setting will lead to much more concurrent transactions to the Provisioning Server which could be a bad thing.

• Off - In some cases you may not need any outbound traffic to occur to the Provisioning Server such as in the processing of inbound notifications by the Provisioning Create User task and Provisioning Modify User task in which case the Account Synchronization task setting should be set to Off. 

 

 

 

Additional Information

Other settings which will impact the outbound requests from the IM Server to the Provisioning Server include:

Accumulated Provisioning Roles (default value is not enabled)

By default every Provisioning Role change issued by the IM Server to the Provisioning Server will be sent in a separate transaction via the AssignProvisioningRoleEvent and RemoveProvisioningRoleEvent. This allows for separate workflows to be configured for each role change, however this can also lead to concurrency problems if there are two transactions that are attempting to act on the same endpoint/account. In the IM Management Console under the IME->Advanced Settings->Provisioning the "Enable Accumulation of Provisioning Role Membership Events" setting can be enabled which will change the event into AccumulatedProvisioningRolesEvent and group the Assign Provisioning Roles together and group the Remove Provisioning Roles together. This will help prevent the concurrency problems but will lead to a loss of separate workflow functionality.

Allow Concurrent Modification on Same Global User (default value is Yes)

By default the Provisioning Server will allow multiple incoming modify requests to a Provisioning Global User to be completed concurrently which could lead to race conditions. There is a setting in the Provisioning Manager under System->Domain Configuration->Identity Manager Server->Allow Concurrent Modifications on Same Global User that can be set to No to help serialize these incoming requests. This should be set to No in most cases with the only exception being if there are any custom Provisioning Program Exits in place that are accessing the Provisioning Global User.