This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP_ALL modified role

Darryl Griffiths
Have you got a SAP Development system where the developers insist they have SAP_ALL, but you know this is just wrong.

Well, here’s a neat solution that removes certain authorisations like user admin in SU01 and adjusting auditing (SM19), RFC admin (SM59) etc.

Using transaction PFCG, create a new single role.
Add a description and save the role.
On the Authorisations tab generate a new profile and then edit the authorisations “Change Authorization Data“.
Do not select any Templates.
From the “Authorizations” screen, select “Edit -> Insert Authorization(s) -> from profile…“.
On the popup, enter profile “SAP_ALL”.

Now adjust the profile as required.
I usually adjust the following authorisation objects:

S_ADMI_FCD – BTCH, FONT, SM21, SP01
S_OSS1_CTL – 16
S_USER_AGR – 03, 08
S_USER_AUT – 03, 08
S_USER_GRP – 03, 08
S_USER_OBJ – [NO AUTH]
S_USER_PRO – 03, 08
S_USER_SAS – [NO AUTH]
S_USER_SYS – 03
s_XMB_ACT – [DEPENDS ON USAGE OF XI/PI]
S_TRANSPRT – [CREATE TASKS, SEPARATE ROLE FOR CREATE TRANSPORTS]
S_IDOCPART – 03
S_IDOCPORT – 03
S_SCD0 – 08, 12

You can then save and assign the role to the developers.

2 thoughts on SAP_ALL modified role

  1. Great controls are set!

    You left S_DEVELOP in probably with object type and activity * which means DEBUG with change. Then they just bypass any authorization check in a second.

    You need to remove more than that…

    Reply

  2. Hi,

    First, many thanks for taking the time to comment.

    Of course, you're absolutely right! By leaving S_DEVELOP with the defaults, the developers could potentially work around any authorisation checks.

    This post is specifically about creating a SAP_ALL type role in a Development system, so I've tried to be flexible by enabling DEBUG for the developers.
    It's a tricky balance.
    My thoughts are that by leaving S_DEVELOP with defaults, you could counter this hole, by applying comprehensive auditing (SM19).

    Also, any variables changed during debug, are logged to the system log. So you should ensure that you keep any eye on the system log too.

    But, as you point out, you could just lock down S_DEVELOP and provide a known process for the developers to request access adhoc.

    Regards,

    Darryl

    Reply

Add Your Comment

* Indicates Required Field

Your email address will not be published.

*