SAP Role removals - XisInEffect False

Hi forum!

I’m using One Identity Manager 9.1. At the end of the first synchronization of an SAP Environment, I can see that some SAPUSerINSAProle_Delete processes are triggered.
For this SAP Connector I used a custom template I saved from a previous SAP connector configuration. It is a customized version of the Base administration template of SAP Connector. It simply contains some mapping disabled on SAP user and some disabled workflows of synchronization and provisioning.
I checked these Processes and they have been triggered after the user ‘SAP_ZUserInSAPRole’ updated the XIsInEffect field of the objects in SAPUserInSAPRole, setting the field as False.
Only a group of roles have been updated and deleted for a group of user accounts.
I checked these memberships, and the removed ones are ‘redundant’. This happened only for some users. 


Example:
User X has 200 role memberships. 10 single roles have been updated with XIsInEffext = ‘FALSE’ after synchronization.
If I check those single roles, they are part of two different composite roles assigned to User X.
So now user has 200 role memberships in One Identity, 10 of them are ineffective and only 190 role memberships are found in target system due to delete processes.
I checked the Config Parameters:
QER\Structures\Inherite\GroupExclusion = 1. No exclusion is defined in SAP Exclusion tables.
TargetSystem\SAPR3\KeepRedundantProfiles = 1. This means that redundant roles are kept and not removed.

Does anyone ever expirenced such a problem?

Thank you, 

Enrico. 

  • 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

  • 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