CUA- Deleting user IDs from Child systems

[Former Member]

Is there a possibility of configuring CUA in such a way that user IDs can be created and access can be updated from CUA but deleting user IDs should be taking place only in the child system (Not in all the child systems)?

[jurjen_heeck]

Can you please explain a bit more about your requirement/issue?

[Former Member]

I have posted another question regarding Active Directory connection to CUA. We are trying to automate user administration- especially the terminations. Once a User ID is deleted from AD, it should trigger an event to delete the user ID in CUA and the related child systems. However, we have a requirement from SRM users - not to delete user IDs from SRM. We do not want to disconnect SRM from CUA and yet be able to not delete the userID from SRM though it should be deleted from the other child systems.

[jurjen_heeck]

Interesting. I've seen a similar requirement for a solution manager system linked to a CUA. No automation there but the user administrators aren't allowed to delete users either. The user data linked to the user is needed for readable issue history and other (change) logs.

I do not have a solution but if you search the forums you may find some interesting discussions about pros and cons of deleting userid's. For me the balance has always tipped towards keeping them. Just strip the roles, lock the user, give the account an end date and link it to a special user group to mark it as deleted.

Lets see what others have to say on this one.

Jurjen

[Former Member]

Generally good advice to keep the uniqueness of UIDs over time, also after Elvis has left the building

What you could consider is a CUA RFC user which is not authorized to delete UID's and schedule a purge job for those IDOCs which deleted only them.

However these sorts of "workaround" solutions are not the best advise, to be honest. What happens it someone temporarily assigns SAP_ALL because there is a big problem and authorizations should be excluded as the cause to get it working again?

Also, every time a new child system is added to the CUA you will be flooded.

My advice: Rather change your procedure (as discribed by Jurgen).

What would be interesting to test is whether you are authorized to move a user (change the authorization relevevant group which they currently have) to a group which the CUA user is no long able to subsequently administrate? But theen you will still be hunting down IDOCs from time to time, most likely.

If your shop is big enough to have these systems you have described, then you might want to consider an IdM system to replace your CUA at some time.

If you wish, I will move this thread to the IdM forum.

Cheers,

Julius

ps: Please do not cross-post.

[Former Member]

Hello All,

Thanks for trying to help me.

I found solution to the problem. There are few different ways to achieve the desired results. I've tested thoroughly with each scenario.

1) Assign end users from SRM to a different group in CUA and do not give access to manage users from this group to the batch ID which is going to run Synchronization from LDAP to CUA.

2)Do not give authorization to the batch ID to send Idocs to SRM or what ever system in which you do not want the users to be deleted.

3) Do not give trusted access to the batch ID in child systems .

Any of the above 3 methods will work to achieve the desired result of not deleting/updating users from a particular child system of CUA.

[Former Member]

This might deprive you of using Trusted RFC at all... for other scnearios it can be usefull.

If you have this risk, then I would restrict the ability to delete user's point-blank. This also means that SAP_ALL should be removed from all users who might click in the wrong place and roles with this type of authorization should be cleaned and kept clean.

You do this using object S_USER_VAL to a limited extent. There are also BADI's in PFCG which you can use. The GRC "Risk Terminator" also offers this functionality, with workflow support.

Cheers,

Julius