Privileges not Grouping when Provisioning to ABAP Systems

[Former Member]

We're using IdM SP5 (7.10.5.0-SQL-2010-05-09).

When we add an ABAP role/privilege to a user in IdM, it starts the ABAP provisioning task, which should provision the user's new role to the ABAP system. What actually happens is that it provisions his whole set of roles to ABAP multiple times (as many times as he has roles).

For example:

Joe Smith has three ABAP privileges. We add a fourth.

Expected result:

SetABAPRole&ProfileForUser runs once and provisions the following role string to the ABAP System: 
EXISTINGROLE1|EXISTINGROLE2|EXISTINGROLE3|NEWROLE1

What actually happens:

SetABAPRole&ProfileForUser runs four times, once for each privilege Joe has, and provisions the exact same role string to the ABAP System each time: 
EXISTINGROLE1|EXISTINGROLE2|EXISTINGROLE3|NEWROLE1

I've tried turning on Assignment Grouping for the repository and it doesn't seem to make any difference. This is really inefficient and causes a lot of problems, as we have many users with 10-20+ ABAP roles, and when they gain or lose a privilege, it provisions them 10-20+ times. Sometimes this happens to large groups of users, and suddenly we have 5000+ provisioning entries queued up when we should really only have 250 (they take between 2-4 seconds for each call)!

Is there something I'm missing here?

[Former Member · Accepted solution]

Hi Adam,

how are you assigning these privileges: using the Web interface or using a script?

I was facing the same problem when I was assigning multiple privileges via a script. When using the Web interface, everything should work fine.

Best regards

Holger

[Former Member · Accepted solution]

If you assign the privilege to MXREF_MX_PRIVILEGE:

The default operation is ADD. In this case the privilege you already have should stay.

Then I think the Task should only runs once (per repository).

[Former Member · Accepted solution]

Holger:

I thought it was via either WebUI or scripts, but the majority of the times it causes issues are during scripted jobs, like doing a mass role addition or removal. I will have to examine this closer to see if it is only during scripted actions that it does this.

It seems relevent to note that this problem appears when we remove one child-role from a role with other child-roles. For example:

MROLE_A contains the following child roles, each of which contain only one privilege:
SROLE_1, SROLE_2, SROLE_3, S_ROLE4

For simplicity, let's say Joe Smith is a member of only one role, MROLE_A.

We remove SROLE_3 from MROLE_A.

Joe loses the MX_AUTOROLE + MX_AUTOPRIVILEGE for SROLE_3, so it triggers the deprovisioning task. I'd expect it to provision only once, but we see the equivilent of the following (these syslog entries may be from custom logging, but should accurately portray what's happening):

SMITHJ - Provisioning ABAP role(s) to repository PRD020: SROLE_1|SROLE_2|SROLE_4
SMITHJ - Provisioning ABAP role(s) to repository PRD020: SROLE_1|SROLE_2|SROLE_4
SMITHJ - Provisioning ABAP role(s) to repository PRD020: SROLE_1|SROLE_2|SROLE_4

As illustrated, the job runs once per role, even though it is sending all three roles through to the ABAP system on the first pass.

In this case, I believe it shouldn't matter whether the action was scripted or via the UI, as it is the built-in Reconcile functionality removing the MX_AUTOPRIVILEGE in both cases.

Christian:

Unfortunately, as I described in my example to Holger, it still runs more than once for each person even for the same repository. They even group up in the system log (they are running all together for each person, not spread out or randomly, which I could see messing with grouping).

I can provide any extra information or run any tests that might possibly help diagnose this issue, as it is quite a serious one for us. Thanks!

[Former Member]

Yes, updating the sap_getRoles script fixed the problem. Make sure you have the latest version of this script, it has a lot of code in it specifically to deal with this issue!

[Former Member]

Hi Adam,

Thank you very much for your help.

I will try the AD solution.

I am still figuring the ABAP one, will let you know if i find something.

Thanks again

[Former Member]

An update to this issue:

We discovered recently that when we did the update to SP5 (and probably any other updates we've done in the past) we thought we applied all of the update packages, but we were never updating the Identity Store tasks that shipped with IdM (like the SAP Provisioning Framework).

Since our provisioning framework is somewhat heavily modified on the AD side and moderately modified on the SAP side we can't safely overwrite them, so I looked through every change manually. It appears that the most significant change was to the script sap_getRoles, which has a lot of code that appears to be dedicated to fixing this very problem. I replaced the old script in our test environment with the new one, and it appears to be working fine without regression, though we haven't really put it through rigorous stress testing yet. Still, I'm hopeful that this has solved the issue! I'll close this question if I am able to verify that it has.

[Former Member]

Hi Adam,

did you find a solution.

I am experiencing the same issue. for me, it happens also when i assign multiple groups in Active Directory.

Tried the grouping options on the repository no success

Thanks in advance

[Former Member]

It used to also do it with AD Privileges as well, but we found a workaround for that. Look in this stored procedure:

dbo.mxi_xvalidate

At the very bottom, we commented out this line:

exec MXI_PRIVILEGEEVENTS @Eid,@Istore,@Objectclass,@Edescription output,@Sta output

You can try that and see if it solves the problem with AD Privileges for you... As far as we can tell, the purpose of that line is to make everything slow and duplicate provisioning calls to fill up the queue faster, eventually taking down the system. It's very good at that, at least.

Unfortunately we couldn't find anything like that for the ABAP privileges. Still having serious issues with this.