Skip to Content

Hi guys,

Here is one good tip, I wanted to share with you 🙂

Each time when I start a new project, I have to create the process, responsible for creating the user accounts into the back-end systems. In order to save some work/time, I have created a custom package responssible for the No Master Process:

  1. Create new custom package (….masterprocess)
  2. In this package create the process responsible for assigning the only privilege
  3. Link this process in each Repository type, then an automatic provisioning, will be triggered in case of assignment when the ONLY is missing:   

 

Hope you like it 🙂

Simona Lincheva

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Chenyang Xiong

    Hi Simona,

    That’s good practice. I also use a similar/same way to handle master privilege.

     

    BTW, how do you handle termination scenario? Do you remove all direct role/privilege assignments when identity is terminated? Some customer prefer to keep the account locked in the system.

     

    I would like to understand how you do it and the rationale behind it?

     

    Thanks,

    Chenyang

     

    (0) 
  2. Simona Lincheva Post author

    Hi  Chenyang,

     

    Thanks for the comment 🙂

    As for your question, depends on the customer (…and on the back-end licensing policy, as for the ABAP systems the only thing you need is to set validity and lock the user 🙂 ).

    Possible scenarios:

    1. lock the account and set validity (in this case you won’t pay for licensing and if the account is activated you have the old access … if needed, in case the old access is not needed you have to remove the old and provide the new one)
    2. remove all access, then lock the account and set validity (again no licensing and in case the account is activated you should assign the new access, but you skip the removal of the old access)

    Note: in case the back-end system is AD, some customers want to move the user accounts into an inactive OU (again keep or remove the access).

    In addition, now we should think about the GDPR :))), here again depending on the company policy we have to maintain the inactive accounts – https://blogs.sap.com/2018/04/23/gdpr-compliance-and-sap-idm/

     

    BR,

    Simona

    (1) 

Leave a Reply