SAP Role removals - XisInEffect False

Hi Enrico,

the parameter TargetSystem\SAPR3\KeepRedundantProfiles has always the value "1", interesting setting is activate/deactivated. By default this parameter is not active and single profile memberships will be deleted if they are involved in composite profiles or role memberships.

regards,

   Tino

Hi Tino, 

thank you for your relply.

As far as i know that confg param is active by default. It's active and i never disabled it.

Another strange fact is that this behaviour started only after a couple of Synchronizations. 

This is happening only for specific users because I can see that also other users have 'redundacy' in their roles, but no role has been removed for them. 

Enrico

Hi Enrico,

had the single role assignments exactly the same date range as the composite role assignment has?

regards,

 Tino

Yes, 

They have the same valid from and valid until dates. 

But other redundancies not removed have the same valid from and valid until as their 'parent role' membership

Enrico. 

Hi Enrico,

I guess the recalculation of redundant profiles will be triggered at a real change of the SAPUser only. So you will possibly see this behavior in following synchronizations again.

regards,

 Tino

I think so. 

The last time it happened, in DBQueue there were some SAP 'Summarize currently effective memeberships' task for those users, probably the ones that have been updated during that sync. 

What i cannot understand is why, considering that the parameter TargetSystem\SAPR3\KeepRedundantProfiles is checked and it clearly says Active.

Enrico

Hi Enrico,

there is an exception from the rule: redundant profile / role  memberships having a composite profile / role membership using the exact valid from/valid until values will be removed. No matter how the configuration parameter is set .

This behavior is by design and explicit implemented as a product feature. The reason is a bug in SAP GUI which allows the creation of this kind of duplicate memberships.

regards,

   Tino

Hello Tino,

following the logic of the product, such redundant memberships get cleared by OIM (also in SAP) but it makes the whole even worse as OIM will recalculate and assign the single role permissions back to the user as soon as he/she looses the corresponding composite role membership making it even less transparent of why it happens.

Best Regards,

Alexey

Hello Tino,

following the logic of the product, such redundant memberships get cleared by OIM (also in SAP) but it makes the whole even worse as OIM will recalculate and assign the single role permissions back to the user as soon as he/she looses the corresponding composite role membership making it even less transparent of why it happens.

Best Regards,

Alexey

Hi Alexey,

the meaning behind the reassignment is this: in SAP you can create the constellation composite role + associated single role only if you first assign the single role to the user, then save it and add the composite role afterwards. Even if the composite role has the same validity period, the editor in the SAP GUI will not remove the single role (we think this is a bug, but it is reality). If you later remove the composite role again, the membership of the single role remains. So OneIM adds the membership of the single role again if the composite role has been removed.

Thus the result is the same as in SAP, which may well be intentional.

Regards,

   Tino

Hi Tino,

you say you assume, the redundant single role assignments (having same validity dates) must be manually added assignments in SAP.

I do think it must be something different (may be some sort of an another bug in SAP).

It is actually not that important how they did appear in SAP, the bottom line they are there.

The whole point would be, the functioning of OIM in this case is not transparent and this particular behavior is not described in documentation in any way.

I believe, it is a common understanding that when you newly connect an SAP client to OIM you clearly do not expect that OIM immediately starts to manage anything in this SAP system and deprovision assignments (even if they are somewhat redundant) and later may start provision old assignments back to SAP. This is nothing any of us expects currently from the tool (at least me not).

It would be not that critical if it at least it would be explained, described and emphasized in detail in documentation.

And even worse, the documentation clearly states the opposite by saying "Ist der Parameter aktiviert, bleiben Einzelrollen oder Profile des Benutzers, die bereits Bestandteil von Sammelrollen des Benutzers sind, erhalten." (you did explain what the difference in reality is between the activated and deactivated parameter but this is nothing what documentation says).

Best Regards,

Alexey 

Hi Alexey and Tino,

I agree with Alexey's opinion.

Right now I cannot synch or preform any operation on these accounts to avoid the removal of SAP Roles and probably this isn't a behaviour the customer wants to be applied to SAP roles.

This Behaviour should be at least documented or configurable and not a default behaviour.

Is there any way to customize this behaviour and avoid this removals?

Probably setting up a condition in delete opertion of SAPUserINSAPRole Workflow or Generatingcondition of remove process would work. Someting like XISInEffect = 1 would perform the deletetion on target system only for effective memberships that are removed in One Identity. But, at every Synchronization or provisioning operation (for example user update or role assimgent to a user) this behaviour would be triggered again. This behaviour should be stopped in DBQueue tasks and Stored Procedures.

Regards,

Enrico

Hi Enrico,

I do not think you can easily change this behavior to what you would like it to be, i.e. by simply adding a GenCondition etc. (next sync, at least in v9.1, will very probably set it back to 1, etc.).

XIsInEffect and the default behavior are too fundamental to do such workarounds, I could think.

Unless it will be changed in the product (what I think will not happen as it is a product feature), I could think it is a better approach to live with it (and to communicate about the behavior at SAP colleagues before connection).

Best Regards,

Alexey