Role assignments not set in ABAP but IdM indicates OK status

[Former Member]

Hi,

We went live with IDM 7.2 SP8 last month. We have started to see issues with Business Role assignments in target systems. Generally, BR assignments are parsed to respective privileges and assigned correctly. Sometimes privileges in one target will get assigned but not in another target. Occassionally assigning privileges to one target does not get through either. In all cases the IdM assignment is marked as 'OK', but when we check the backend the assignment is not there. Log entries don't show any jobs triggered for the target that failed to update (and consequently there is no log entries in that target either). But why would IdM mark the specific privilege as 'OK' status -- it should either remain 'Pending' or 'Failed' but certainly not 'OK'.

This effect is inconsistent -- it works correctly at times and fails at others -- increasingly more failures. There is nothing different about the users or environment. We see this in ECC, BW, GTS, etc. We have 36 prd and non-prd systems linked systems. Initially we thought this only affected prd systems as BR's only have prd privileges and the PRD targets are load-balanced. For non-prd systems the assignments are direct privileges, not BRs, and they are not load-balaced. We are now seeing this in behavior in all environments for BR's or direct privilege assignments, in prd and non-prd targets.

Since BR's have appovers we cannot remove BR's and re-assign in production. So for non-prd targets we have removed the privileges, those that indicated 'OK' but did not get set in the target, and reapplied -- the privileges get deleted successfully without any corresponding job being triggered and then when we re-add it the assignment goes into 'OK' status without any job being triggered.

When we tried assigning another user the same privileges it went through fine to the target and IDM marked 'OK' -- exactly as it is supposed to work (non-prod privileges have no approvals).

We are not able to re-produce this in our DEV environment -- the targets are non-load balanced. The assignments work consistently, both BR's and privileges.

Has anyone seen such behavior by IdM?

Thanks for your thoughts.

Ashok

[Former Member · Accepted solution]

Hi Ashok,

On the backend side, check with SUIM a change doc on the provisioned user, filter on IDM communication user, and see if there is an add operation followed by a remove operation of the assignments ?

If so, this problem is already known by SAP, note 1736724, but used to appear on much earlier versions then yours (< 7.2 sp04).

Fadoua

[Former Member · Accepted solution]

Hi,

Thanks for the suggestion. But ours was a different problem.

The issue was with a faulty reconciliation job that had been fixed. But it had done its damage before the fix and this caused the inconsistent behavior.

During the reconciliation job (to update changed and add new backend roles in IDM) various task trigger attributes get disabled and then re-enabled after the import. These disabled triggers did not get re-enabled for the privileges on some systems. And the reconciliation job was also delta enabled, so only new privileges, after the initial load, should have been impacted. But impact to many privileges -- all privileges of some target systems -- misled our investigation. The timing of the reconciliation job executions kind of added to the confusion and inconsistencies during the initial setup. But we finally tracked this down and wrote a custom job to fix the triggers for only the affected privileges. Assignments to all systems started to function successfully as expected.

Best regards,

Ashok

[Steffi_Warnecke · Accepted solution]

Hello Ashok,

if that is the solution, that please mark your post as the correct answer and therefor close the thread. This way others can find the solution more easily if they have the same issue.

Thanks!

Regards,

Steffi.

[Former Member · Accepted solution]

Done -- this is confirmed over the last few weeks after I implemented the solution.

[ganesh_s7 · Accepted solution]

Had Similar situation due to Reconciliation job being stuck in 'Running' status mid-way