Automatic role assignment

[Former Member]

Hi Security experts,

in our organization there are some default roles which need to be assigned to all and every user created in our SAP systems. Currently our servicedesk does it manually but like every manual process someone sometime misses it and then it becomes a pain. is there a way to automatically assign some roles to any user which gets created in the system.

i know a complicated way is to do some kind of development where when the program for user creation gets triggered, we can insert a code to assign the default roles. Want to find out if there is a simpler process.

Yogesh

[former_member195397]

Hi Yogesh,

You can create an reference user assign the default role and other values (e.g. parameter setting, company address etc.) You can use ref user to copy user all time. (by the way ref user can use used in different way not for copy users) I suggest you this since ref user is not included require any license fee.

Arul

[Bernhard_SAP]

Hello Yogish,

there is a undocumented user exit, which is reached before saving a user in SU01.

In this exit you could call the BAPI_USER_ACTGROUPS_ASSIGN to assign the required roles(I suggest to trigger that assignement in batch then, to avoid lock situations).

callstack of the exit:

6 SAPLPRGN_EXIT_EXAMPLES FUNCTION PRGN_EXIT_USERS_TRANSFER <<<thats the exit

5 SAPLPRGN_EXCHANGE FUNCTION PRGN_USER_ASSIGNMENT_CHANGE

4 SAPLSUU4 FUNCTION SUSR_USER_AGR_BUFFER_TO_DB

3 SAPLSUU0 FORM SAVE

2 SAPLSUU0 FUNCTION SUSR_USER_MAINT_WITH_DIALOG

1 SAPMSUU0 EVENT START-OF-SELECTION

To activate the exit you need to create an entry in table ssm_cust:

(SSM_CUST-ID) | (SSM_CUST-PATH)

Z_USERS_TRANSFER | PRGN_EXIT_USERS_TRANSFER (=example FM from SAP; you can enter any FM you like here to be triggered, for instance your Z-FM to trigger the a.m. bapi.

The exit is reached about at line 485 of PRGN_USER_ASSIGNMENT_CHANGE. If you have a look at the coding there, the implementation will be logical for you....

b.rgds, Bernhard

[Former Member]

I really like Bernhard's recommendation.

An option I have often seen is changing the user creation process to make the service desk copy a template user that is already assigned the roles. They then update as required. If they follow the process, they will never miss allocating those other roles.

[Former Member]

Hi All,

thanks a lot for your inputs. Bernhard's recommendation seems to be very useful and i will try that. Adding to what we have here is that we have almost 8 Abap stack applications in our environment and we use CUA for user management. So using a template user etc may not be feasible. We are looking for a solution where role assignment automatically happens for any user created whatever way it is created.

i will see how we can fit Bernhard's recommendation in our setup. Another way i was thinking was to run a background job which check for missing default roles and assigns them. But this may be a security challenge.

Yogesh

[Former Member]

> missing default roles

If the default role(s) exist in all systems and are the same, then you can also consider encapsulating the role(s) into one reference user (not to be mistaken for a template user) and assign this reference user at the time of creation already.

The user BAPI for creating (or changing) users offers the option of adding one reference user for additional authorizations at the time of creation already. You can avoid the problem with locks on roles this way and the BAPI takes care of all the LUW aspects in the same commit at the end ( at the latest.. ).

Additional advantage is that with huge numbers of users, you have a performance gain in that the user buffer is only loaded once for the reference user and available to all others it is assigned to.

Downside is that you can only have one reference user assigned at one ponit in time - but this is probably a good thing...

IMO a "common role" for all users only makes sense if you ensure that the role is truely "watertight" and the same objects (which will by proposed by other transactions!) are not making it obsolete anyway.

If you add too much access to this common role it will make you lazy when building other roles; you should be carefull of this when expecting those roles to work correctly or wonder when restrictions to them don't work, because it is very difficult to restrict a role assigned to all users with a diversity of other roles.

Cheers,

Julius

[Bernhard_SAP]

>

 ....... and we use CUA for user management.

In that case, you can trigger a workflow or batchjob for that additional assignement(s) in the central system, as if CUA is active, an event is triggered upon saving the user.

b.rgds, Bernhard

[Former Member]

Hi Julius,

I've tried your recommendation. Here is what I did:

1. Created a user called REFUSER (as a reference user) with the common role, which should be assigned to all the users.

2. Checked the BAPI - BAPI_USER_ACTGROUPS_ASSIGN.

But, I didn't find any option to include a Activity Group.

Can you provide a more step by step approach to achieve this?

Rgds,

Raghu

[Former Member]

It is initially a change to the user's master record with only an indirect assignment to the roles (aka activity groups).

So, what you are looking for is BAPI_USER_CHANGE.

It will then subsequently make the same checks as assigning the roles and profiles directly, but doesn't actually do it. This must already have been done to the REFUSER itself.

Note that you can only assign one reference user at one ponit in time, and cannot cascade the reference users for referenence users. So, there is no "enabler" user option, incase that was going to be your next question

Cheers and nice to see you back again,

Julius

[Former Member]

Hi Raghu,

You can assign the reference user (with the common role assignments) when you are using BAPI_USER_CREATE1 or BAPI_USER_CHANGE

[Former Member]

Hi

Sorry if I'm picking up a slightly old thread here, I've used reference users during mass swap of roles to users in end markets which worked fine but I did get some worrying emails from the users saying purchase order and sales order prints had defaulted to the reference user ID during the removal/assignment period.

Maybe this was something that had been caused by system config - not sure.

I do like the option of using this REF user (the performance issue mentioned is a real plus which I hadn't thought about) but would a REFUSER name on a document sent/emailed to a customer or vendor be an issue? edit - presumption being printing is in the common role - edit

I think the postings do really show the real dialog user in SAP but just from a purchasing/sales point of view I wondered about this...

Cheers

David

Edited by: David Berry on Oct 16, 2010 3:40 PM

[Former Member]

This is illogical but still possible if the developer tried to determine the intended user's authority from a workflow or batch processing unit of work via the check FOR USER abc, which already had a refetence user xyz.

This means you can cascade the reference user authorizations one user further but not all three at the same time. If the program found the refuser to be authorized and returned that user's name back to the program then I would class it as a programming error to overwrite the name of the user being checked against by that of their own authorizations (which is what a reference user is).

Which tcode did this happen in?

Cheers,

Julius

[Former Member]

Hi Julius

This came for VA01 and VL01N but that's as much as I could gather from them unfortunately (end users and manager's frantic emails were all I had to work from) before I deleted the REF user link in SU01.

I would still use it for mass maintenance of role assignments - better than no access at all if they are being LSMW'd but it may be that the printing issue in a base role doesn't matter if at these tcode levels and not SP02?

Cheers

David

[Former Member]

Hmmm... I have seen this sort of thing in background processing and RFC (for example, see [SAP Note 999004 - user switches in RFC debugging|https://service.sap.com/sap/support/notes/999004] and [User switch in inbound LUW|https://service.sap.com/sap/support/notes/926261] for some infos) but this is a programming error.

In custom code I have once seen a construct where instead of checking the authority of a user to perform a task, the program determined the user's authority to automatically perform tasks they were authorized for. The refuser wasn't considered initially.

Another possibility is that the refuser had sufficient auths to initiate LUW's for the dialog user in their own context, but these were not sufficient to complete them. When you removed the refuser, the FOR USER auth check failed and the task was handed back to the background processing.

Sometimes, less is more...

These are nice examples (albeit complicated ones) why maintaining SU24 is at best a developer task (it also makes S_DEVELOP authority-checks...) and building roles should ideally be done together with the developer or good documentation to rely on.

At the time of creating programs, the developer knows most about how it works and what it restricts. This also means that security folks can influence the coding and simplify the concept (for example to use existing authorizations with the same semantics already in place for the users).

Cheers,

Julius

[Former Member]

This message was moderated.

[former_member80629]

Hi:

If you have your HR org model setup with all users being linked to a position, you could try assigning the default role on top of the org via PO10.

Thanks.

[Former Member]

@ Yogesh: Are you still with us?

Based on your subsequent post I suspect that David and myself are on the right track here with our discussion, and not wandering off from the original topic?

Cheers,

Julius