Question:
Hi
I am enquiring about the necessary controls to prevent deletion of SAP*and other Superuser Accts?
I know that we should set [ login/no_auto....=1 ]
In addition,
I read that we should assign all superuser accts [ Default eg. SAP*, SAPCPIC ] and customised superuser accts [ For administrators eg. admin123] into the SUPER user group.
Does this mean that only administrators eg.admin123 in this SUPER Group have the rights to delete SAP*? Where can i view the deletion rights of the administrator? Can we take the deletion rights of the administrator away?
Why can we view all users in this SUPER group?
Thank you very much.
Answer:
You can assign SAP* and other powerful users to group SUPER.
I've not seen any problems when assigning them to a different user group either.
Anyone with access to maintain users in the group SUPER will be able to delete or change users in that group. This is controlled by auth S_USER_GRP. Access to CLASS=* will be able to perform the activities listed in their roles/profiles for users in group SUPER
If you want to restrict admin of users in group SUPER then you need to make sure that you restrict access to S_USER_GRP: CLASS=SUPER
You can view users assigned to a group in a number of places. Transaction SUGR is an easy way to see them
Answer:
Thank you AL.
I read that "Users assigned to the SUPER group are not permitted to alter each other's access".
How is this possible? I think of the following controls
I have checked that the SAP* acct does have Auth Obj S_USER_GRP. Access to CLASS=* Activ=*.
This would also mean that SAP* can delete other users in any group including SUPER group.
But i guess we can control this by restricting users from logging into the SAP system using these default superuser accts [eg. SAP*, DDIC ].
Assuming that there are 2 full-time SAP administrators with userids admin-1 and admin-2. We will also assign these admin user-ids to the SUPER group.
To achieve the objective: No user in SUPER cannot alter each other's access, we will not allow both admininstrators to have { S_USER_GRP, ACT=06[DEL] and ACT=02 access }?
Can this work?
Also, what if SAP* is not assigned to any group?
In this senario, who can alter the user master record of SAP*
Thank you again!
Answer:
In addition,
I read that we should list out user-ids with
Authorization Obj: S_USER_AGR, ACT: 01,02,21,22 & TCode: PFCG
Can the above authorization delete or modify accts in a User Group?
Where tcode should i execute to read the fields and activities of an Authorization Obj?
Thank you again!
Answer:
If a user isn't assigned to any user group, all with access to maintain any user group can maintain that user as well! So that is not a good idea. If you want to see the documentation of an object, select the object in PFCG and click F1... Or go through SU03 to find it and click Documentation.
Answer:
Hi Henrik.
I tried PFCG, but can't find any options to select AUthorization Objects here. Did i miss anything here?
Thanks again.
Answer:
I read that "Users assigned to the SUPER group are not permitted to alter each other's access".
How is this possible? I think of the following controls
Is this an audit requirement?
I have checked that the SAP* acct does have Auth Obj S_USER_GRP. Access to CLASS=* Activ=*.
This would also mean that SAP* can delete other users in any group including SUPER group.
Correct. SAP* usually has SAP_ALL and SAP_NEW assigned, giving access to modify all users.
But i guess we can control this by restricting users from logging into the SAP system using these default superuser accts [eg. SAP*, DDIC ].
There are a few things here.
All your standard SAP users should be secured, the dialog ones especially.
DDIC needs the standard password to be changed
SAP* should have password changed, profiles removed and the user locked.
However this doesn't address the requirement above. To do that, no users that you put in group SUPER should have S_USER_GRP: ACTVT=01 or 02 or 05 or 06 CLASS=SUPER. This will mean that you need to check all the roles/profiles assigned to these users and amend or replace with suitable access.
Assuming that there are 2 full-time SAP administrators with userids admin-1 and admin-2. We will also assign these admin user-ids to the SUPER group.
To achieve the objective: No user in SUPER cannot alter each other's access, we will not allow both admininstrators to have { S_USER_GRP, ACT=06[DEL] and ACT=02 access }?
Not sure what you are getting at here. Just put your admin users in a group like ADMIN instead and if they need to be able to amend users in group SUPER then they will be able. Someone has to be able to.
If you need to segregate access admin for your admin people, then you will need to put them in different user groups and make it so admin1 can change the user group that admin2 is in and vice versa.
If you only have 2 administrators then that doesn't appear to be a particularly pragmatic approach and maybe you should look into a mitigating control such as regular monitoring of change logs.
Also, what if SAP* is not assigned to any group?
In this senario, who can alter the user master record of SAP*
Anyone with S_USER_GRP: ACTVT=01,02,05,06 CLASS=<blank>
Answer:
In addition,
I read that we should list out user-ids with
Authorization Obj: S_USER_AGR, ACT: 01,02,21,22 & TCode: PFCG
Can the above authorization delete or modify accts in a User Group?
It depends what you want to change, that is not sufficient to change roles for example. Run an auth trace (ST01) and see how different activities with the user master require different access. If I recall correctly the above access will let you create & change a user master record, but not assign roles or profiles to it.
Where tcode should i execute to read the fields and activities of an Authorization Obj?
I usually use transaction SU21
Answer:
Thank you so far.
"Users assigned to the SUPER group are not permitted to alter each other's access".
Is this an audit requirement?
This is a request from audit to prevent intentional or unintentional deletion or modification of superuser accts, especially SAP*.
We are supposed to explore the possibility of accomodating this request.
Can help?
Answer:
Thank you so far.
"Users assigned to the SUPER group are not permitted to alter each other's access".
Is this an audit requirement?
This is a request from audit to prevent intentional or unintentional deletion or modification of superuser accts, especially SAP*.
We are supposed to explore the possibility of accomodating this request.
Can help?
This is a good example of Audit knowing a little, but not enough.
No-one should be using SAP Standard users, so if you demonstrate that access to them is controlled, then that covers them.
That leaves people with admin access.
Only a very small number of users should have access to user maintenance. In that group, it may be deemed that a subset of those can be responsible for maintaining users in group SUPER. You could legitimately have 2 or 3 admins who can manage superuser accounts and those in group SUPER (don't have to be the same).
Given that those users are trained and responsible administrators, it stands to reason that the risk above is mitigated by virtue of the very small number of users with the access. Furthermore, if you have a load of superusers (e.g. background users etc) it is realistic for there to be a small number of users who can change these users as and when is required.
A belt and braces solution would be to lump all powerful users into group SUPER and have a seperate role that give access to administer users in the group. The assignment of the role to an administrator would be temporary and only with approval of internal audit. Not that practical though.
Answer:
Thank you very much.
This is the most responsive forum i have ever come across.
Answer:
Some things to consider…
By placing powerful Ids in the user group SUPER or something else that designates extreme access you may get an Audit Comment.
The Audit Scenario is:
“You should not easily identify IDs to be targeted. Placing a user in the user group SUPER or other similar designations are a flag to the hacker to target these IDs for access.”
IDs like Security Admin, SAP*, SAPCPIC, DDIC, BATCHADMIN, Basis Admin, etc Generally have consolidated access that an prove damaging to your system. These IDs can be distinguished from others by assigning a user group to these ID but it should not be obvious what they are.
In agreement with AL., Your auditors are looking for low hanging fruit and missing the entire tree. All one needs in a system is an ID with access to user maintenance. SAP* is not needed and while it sounds good to “keep Security Admins from changing SUPER Ids or each others” , they are grossly missing the fact that with ID maintenance anyone can create a SAP* equivalent ID and perform as much if not more damage than SAP*. It is the access to User mainteance in general that is at issue, not nescesarily SAP*. SAP* is bad since there is little accountability.
To add to your mitigating processes you should have a process in place to have the supervisor of the Security Admin people to periodically and randomly monitor ID changes and ensure these changes were authorized and documented, Limiting access to a few is not sufficient and may lead to an Audit Comment.
_________________
John A. Jarboe