Dynamic role assignment at login - Supporter concept

[Former Member]

Dear experts,

our auditors had the idea that all system supporters (not the normal users) have only display authorization. In the case that the supporters need to modify data they have to state a reason and then the login with a special user (via RFC from their user) which is authorized to change data.

The problem from my point of view is now, that since this "special" user is permanently in use by the support users (we have around 60 supporters for different areas) it is very hard now to find who changed it in person (since this user is the same for all). We have the system audit log running for this user, but sometimes the log file is full and the data is lost who did what. Supporting RF transactions doesn't work as well since these transactions check for single logon (which is almost never the case due to parallel usage of this special user).

To cut a long story short, I don't believe in this concept. My "dream" would be the following: On the logon screen of the production system there are 2 radio buttons:

User:

Password:

(x) Display only login

( ) Supporter login - please state the reason for usage in the text box below:

<Text box>

Depending what has been chosen the supporter user should have either display or modify authorizations with his normal user name.

Do you think this is possible? If so, can you give me a hint?

Gunter

[jurjen_heeck]

Since they need permission anyway you could give them display rights for their account and create a reference user with rights to modify data.

Once they've requested access and it's okay-ed you connect the reference user and start monitoring their account. This way they'll do everything under their own name and they will always need a second pair of hands/eyes to get the extra rights. The only thing I do not know is if the addition/deletion of the reference user will show up in the users' change documents. If that's the case your auditors may even become happy.

About modifying the logon screen, I've heard that's the biggest nono possible as any mistake can render your system unusable.......

[Former Member]

Hi Jurjen,

that's an interesting approach. However, we would definitely need to have it automated - we have way to many supporters in the different areas of SAP. As I understood your suggestion somebody has to add this reference user into the the user master (e.g. with SU01) and then notify the supporter. Later this reference user must be removed again manually. Am I correct?

Especially the removal: It should be that with the logoff the authorization is gone (or at least has to specifically selected with the next logon).

Gunter

[jurjen_heeck]

> Later this reference user must be removed again manually. Am I correct?

That would be the case. But if you want to automate stuff, where is your control mechanism? A DIY approach is just as dangerous as giving them the extra rights permanently. I know which box I would tick....

> Especially the removal: It should be that with the logoff the authorization is gone (or at least has to specifically selected with the next logon).

Sounds to mee that you want those people to have two accounts per person, a read-only one and one with extra rights. Why don't you try that in a pilot with 5 persons (2 accts per person) and monitor the usage of the read-only accounts? I think I already know the answer.

Another thing to consider is creating roles with the additional rights in a very specific namespace. Also put your support staff into specific user groups. With that you could delegate role assignment for those roles to some more people and just make sure the end dates are set properly. PFCG_TIME_DEPENDENCY will do the rest.

By the way, I do not have an actual technical solution for your original idea and I am not looking for it either

[morten_nielsen]

Hi

I think that I would create a small workflow for this, that way you can automate and document the entire process.

The steps I would create would be something like:

1. Request Change access (this could be a very simple form, or a complex application depending on your more detailed requirements)

2. Approve Request

3. Create/activate user with the correct authorization for a specific period (could be a user that you monitor through secure audit log).

4. Send logon info to the user

5. Maybe if required - "kick-out" the user if active when the time is up in background (and of course maybe give him a warning first).

This approach will, of course, require some development, but there is quite nice BAPI's that could be used for this.

Another option is of course to take a look at the FireFighter concept in GRC - That's a standard solution, but it might be "overkill" i your scenario.

Regards

Morten Nielsen

[Former Member]

Hi Morten,

GRC is a good hint - I hope that's not what we don't have already, we also call our setup "Firefighter".

Mange julehilsner,

Gunter

[Former Member]

We have these kind of requirements some time wherein the users (customizers generally) require special access in production system. We have a specially designed role for this purpose. We assign this role for a temporary period via our customzied CUA tool, The role assignment has to be approved by the users manager and the role owner. Also, we mention in comments section the exact requirement.

[WolfgangJanzen]

>

> Dear experts,
> 
> our auditors had the idea that all system supporters (not the normal users) have only display authorization. In the case that the supporters need to modify data they have to state a reason and then the login with a special user (via RFC from their user) which is authorized to change data.
> The problem from my point of view is now, that since this "special" user is permanently in use by the support users (we have around 60 supporters for different areas) it is very hard now to find who changed it in person (since this user is the same for all). We have the system audit log running for this user, but sometimes the log file is full and the data is lost who did what. Supporting RF transactions doesn't work as well since these transactions check for single logon (which is almost never the case due to parallel usage of this special user).
> 
> To cut a long story short, I don't believe in this concept.
Well, what you have described sounds very similiar to the "Firefighter" concept of GRC, indeed.
> My "dream" would be the following: On the logon screen of the production system there are 2 radio buttons:
> 
> User:
> Password:
> 
> (x) Display only login
> (  ) Supporter login - please state the reason for usage in the text box below:
> 
> <Text box>
> 
> Depending what has been chosen the supporter user should have either display or modify authorizations with his normal user name.
> 
> Do you think this is possible? If so, can you give me a hint?
> 
> Gunter

Sorry, but I dislike that idea. First of all: there are many logon screens - and you might not be able to modify them all (e.g. the SAPGUI logon screen). Second: that's mixing "authentication" with "authorization" - and in general it's not good to mix different concepts (just as a general "rule of thumb"). Actually, you could simply create two accounts (for each of those users) - one with the "display only" authorization and one with the "supporter" authorizations. I assume that the only reason for not doing so is the license measuring, right?

[Former Member]

We have a self-developed emergency user solution, however it would not completely meet your requirement

But here is a suggestion for yours:

> Wolfgang wrote:

>>Actually, you could simply create two accounts (for each of those users) - one with the "display only" authorization and one with the "supporter" authorizations.

Legend :

"display only" user ID = NORMAL

"supporter" user ID = NORMALX

What you could also do, is create a second ID (NORMALX) in a protected group for each of the folks (NORMAL), but only with the delta authorizations assigned to them (the add on support features, not the basic display authority etc to be able to enter the transactions).

Then set the system up to trust itself for trusted RFC, and assign S_RFCACL allowing the "same user only" to be different, but only for their own "add on" support user (NORMALX). You need to be very restrictive here.

Then disable the password of the NORMALX so that it cannot logon via the SAPGui logon screen.

Then disable the Reference User type check in table PRGN_CUST temporarily and add NORMAL (who must have logged on already) as a reference user for authorization checks to NORMALX (the user ID with the add-on features). Not the other way around (!).

Then, there is a user exit in the SAPGui logon program which you can use with your own coding to check to see whether the user NORMAL has a reference user with an 'X' attribute. If yes, then give them a popup to decide whether they want to proceed with a normal logon or an "emergency" support logon with additional access.

This way, if they create a new session or logon via types other than the SAPGui logon... they should not be able to access the additional authorizations of NORMALX.

But if they choose "Yes"....

 PERFORM user_switch USING it_uname... 

Note that the security audit log has dynamic profiles as well. You could tweak it there as well, so that folks have to "sign off"... so that they don't click "Yes" every time to avoid being hassled about it

Please post your coding if you want to try it and have problems or doubts.

Cheers,

Julius