Explanation of how IM Reverse Sync Policies work
Article ID: 36558
Updated On:
Products
Issue/Introduction
Question:
I'm attempting to use an IM Reverse Sync Policy to detect group memberships added to AD Accounts outside of the IM Application, and rejecting them does not remove the group membership from the AD Account. What am I doing wrong?
Environment
Release:
Component: IDMGR
Resolution
Follow these steps:
- Ensure that the acquired endpoint has Endpoint Attribute Mappings defined between the account attribute desired and a provisioning user field.
- Run an Explore of the endpoint to retrieve the mapped attributes, and then store them in the Provisioning Repository on the account reference object. The Provisioning Server must have the correct inbound notification configuration to the IM Server because the Explore generates inbound notifications that need to be sent to the IM Server to be processed. The IM Server processes the received inbound notifications, and if there is a matching IM Reverse Sync Policy, then additional work may occur. In this scenario, the IM Server would trigger an outbound request back to the Provisioning Server to modify the AD Account and remove the group membership.
This process flow could have the following potential problem spots:
- The endpoint did not have groupMembership in the Endpoint Attribute Mappings
- An Explore was not performed because the groupMembership was added to the account on the native ADS system
- Inbound Notifications are not enabled in the Provisioning Server or some failure in writing the notifications to the Provisioning Repository’s notify DSA
- Inbound Notifications are suspended in the Provisioning Server and not being sent to IM, or the IM Server cannot be reached, or the wrong IME is configured to receive the notification, or the notification process is stuck retrying a failing “bad” notification, or the notification queue is large and there is a delay in process the notification of interest
- The IM Reverse Sync Policies does not have proper matching value defined
Note: in the case of an AD Account groupmembership the group value would be the IAM Handle format so the values would be something like the following:
ADSGroup=Administrators,ADSContainer=Builtin,EndPoint=My_Endpoint,Namespace=ActiveDirectory,Domain=im,Server=Server
ADSGroup=My_Group,ADSOrgUnit=My_OU,EndPoint=My_Endpoint,Namespace=ActiveDirectory,Domain=im,Server=Server
Additional Information
If using Endpoint Attribute Mappings and/or IM Reverse Sync Policies, consider these important limitations, as these features could introduce additional unexpected problems.
1) Both Endpoint Attribute Mappings and Custom Correlation Rules alter the amount of data retrieved both during an Explore and stored on the account reference object in the Provisioning Repository. This could lead to Explores taking longer and/or needed sizing of the Provisioning Repository.
2) When the Provisioning Server receives a request to view an account, it first retrieves whatever attribute data is stored in the Provisioning Repository. Because Endpoint Attribute Mappings and Custom Correlation Rules alter the stored attributes, these view account requests start to display the information stored on the last Explore rather than the current data on the endpoint, which may be different. This “stale” data is not be refreshed until running the next Explore, as long as the attribute in question is still listed either on the Endpoint Attribute Mappings or Custom Correlation Rules. If the attribute in question is not part of the Endpoint Attribute Mappings or Custom Correlation Rules, then that “stale” data will not be refreshed or removed. This case requires a manual cleanup of the Provisioning Repository (that is, port 20391 connection) to clean up data stored on that previously mapped attribute.
3) Running an Explore operation frequently and/or against endpoints with many objects generate a large volume of inbound notifications in the queue that require processing. The larger the queue, the longer the delay between when an operation that was initiated/completed outside of the IM Server makes it to the IM Server to be processed, and can impact the resources needed by the systems.
4) Running an Update operation pushes the mapped account attribute value currently stored in the Provisioning Repository to its corresponding provisioning user attribute. These provisioning user attribute updates will not be pushed down to other associated accounts as part of this update. Updating the provisioning user generates its own inbound notification sent to the IM Server, triggering a Provisioning Modify User task to update the IM userstore attribute value mapped to this provisioning user attribute.
5) The IM Reverse Sync Policy Reject will undo the account attribute change so that it is back to being what it was prior to the update caused by the Explore. However, the IM Reverse Sync Policy will not undo the provisioning user and IM userstore attribute value if that also has been updated, thus a rejected account value may still persist on the user objects.
6) The default IM task setting for Account Synchronization on most tasks is “Task Completion”. This causes a compare to take place during the SynchronizeAttributesWithAccountsEvent between the IM userstore user and the corresponding provisioning user for the IME mapped attributes. This in turn treats the IM userstore user as the authoritative source, and push that value to the provisioning user, possibly pushing the value down to associated accounts.
The risk of undesired values being passed around could increased if:
- There are delays in the inbound notification processing to synchronize the IM userstore user with the provisioning user
- Their are account values reverted on accounts but not on users.
Please review KB 36216 for a more detailed explanation on the IM Task Settings (User Synchronization and Account Synchronization).
Feedback
