We have faced several incidents where unintended attribute/access values have been provisioned by whatever reason.
We would like to know if there is a way to anticipate provisioning transactions that occur as a result of a refresh. An intermediate step that alerts us to the attributes values that will be modified in the target application’s accounts before they are deployed.
Alternatively, is there a control to block success bulk actions based on a threshold?.
I would isolate the cause for these unwanted provisioning actions first before trying to quarantine updates.
However if quarantining is really your goal, you could implement some gating/alerting logic within BeforeProvisioning rules for affected connectors. Not sure if you’re seeing this in a few different applications only, or across all apps within your environment.
If there’s any additional info you can share, that would be helpful to coming up with the best solution. Would like to understand why these provisioning updates are unintended.
For bulk processes, you can set maximum object limits on task definitions to ensure that a rogue refresh run terminates early if a global rule change attempts to touch every identity in the system at once.
@FJSC25 Is this issue still open? Incase you figured out, please share the details on how did you fix it to help fellow sailors having the similar issue.
Hello @sanjaysutarc , thanks for your reply. The changes that were pushed were attribute synchronization values to target attributes since the logic for a rule changed. However, the customer did not expect such amount of changes in his directory, and we were not able to anticipate all these changes. That is why we would like to have a middle step before a provisioning transaction happens to have a summary of changes that are going to be launched up to the target system. Or a threshold value that force the refresh task to stop when there are so many transactions to the target system…
@FJSC25 I don’t think OOTB we have any option to enforce a limit.
you can attach a workflow to identity refresh task, if you really want to restrict. you can try reading the current provisioning transaction objects for any app and their attributes and if it is beyond, you can throw the exception or modify the plan to remove those attributes.
As per best practices on attribute sync/target mapping - it should be used only after full analysis of the changes/new rules.
This is quite heavy operation as the rule will be evaluated for every identity refreshed with “synchronize attribute” option. So this will add to overall performance of refresh.
Since there is no simulation like with Policies, may be you can run the rule through separate task on all eligible identities and just dump the new values (as suggested by the rule) to output file and then compare them with existing account attribute value.
Pre-analysis is must for any changes like this that might impact whole lot of identity population.
@FJSC25 Could you provide more details on which attributes are being provisioned?
If your goal is to prevent attribute provisioning during an Identity Refresh, you can disable the “Synchronize attributes” option in the task settings. When this option is unchecked, no attribute updates will be provisioned as part of the refresh process.