Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to Restict T code once sap_all is Assigned

Former Member
0 Kudos

How can I restrict tcodes like SUO1, PFCG, SU10 and SUIM to a specific user who has been assigned SAP_ALL and SAP_NEW to him while creating a user through su01.

Help Appreciated.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

SU01 and PFCG are the least of your issues. This user has full access to your IMG, Basis transaction (Like delete a client) not to mention the thousands of SoD's generated. If this is a dev system and is being used to perform configuration for a new implementation, copy the SAP_ALL auth to a new role. restrict access to objects S_USR_GRP, S_DEVELOP, S_TABU_DIS. Deactivate the S_TCODE auth object and then manually enter and only enter the functional transactions required. Again this is not a role anyone should ever have in a production enviroment.

13 REPLIES 13

Former Member
0 Kudos

You cannot.

On the surphase, you can implement CUA to make some of the buttons go away; but ultimately, you cannot if the user has SAP_ALL.

Cheers,

Julius

0 Kudos

Just do not use SAP_ALL but create a role that is restricting to the really needded access.

NO person needs access to SAP_ALL in any SAP System.

The only use for SAP_ALL is for special uid's like DDIC and a company specific emergency uid.

Although i have seen SAP_ALL being used often by lacy Security admin, who were not willing to spend time to create custom roles. Even worse is the situation were management forced the security admin to make use of SAP_ALL as they are ignorant to the possible security breaches that could come form the use of SAP_ALL.

Even in the sandpint system it is dangerous to use SAP_ALL as it usually sits in the same landscape as the prodcution system and thus it is possible to go to the production system via RFC.

0 Kudos

>

> Even in the sandpint system it is dangerous to use SAP_ALL as it usually sits in the same landscape as the prodcution system and thus it is possible to go to the production system via RFC.

You can always assume (and should) that someone trying to break your system has full control over the source of the risk which they already have (be that "their" system, or possibly even one of "yours").

You protect your systems (not only limited to your example of "production") by protecting the target (much, if not even most, of which can be done using authorizations) from the eventuality of the above described scenario materializing.

This involves both increasing the security perimeter to prevent intrusion, and someone wanting to hurdle it would have to make enough "noise" that it can be found (in a timely manner) via monitoring. In some cases even reacted to by the system (sometimes rather violently...).

>

> NO person needs access to SAP_ALL in any SAP System.

and

>

> The only use for SAP_ALL is for special uid's like DDIC and a company specific emergency uid.

There is a bit of a contradiction there, don't you think? Or do you only give DDIC a regenerated SAP_ALL during upgrades?

Cheers,

Julius

Former Member
0 Kudos

If at all u want to authorize SAP_ALL and restrict tcodes one alternative way you can do is create a role ZSAP_ALL in the edit authorization screen got o Edit tab--->Insert Authorizations--


>From Profile and select SAP_ALL profile. Means insert authorizations fron SAP_ALL.

In the new Role ZSAP_ALL edit the field S_TCODE remove the * there and make a selection by selecting all and deselecting the tcodes you want to remove save and generate.

Hope this helps.

<removed_by_moderator>

Regards

0 Kudos

This solution has a big gap, as a large number of really harmfull trx are not limted by S_TCODE, but by authorisation objects. for a "SAVE" solution: not only limit S_TCODE, but limit all S... objects. And if you do not know for certain that the are no harm then simply remove them out of the role.

By the way buy authorisations made easy in there is a full descirption of how this role should be build!

0 Kudos

Actually assigning the tcodes in S_TCODE is not tht harmful as one will hv a option to choose tcode from a drop dn list. I agree tht it will be a time consuming one.

If security aspect is considered it is better to trace the jobs to be performed by a user with asp_all profile put it under authorization trace and create a role according basing on the trace report.

Regards

Former Member
0 Kudos

SU01 and PFCG are the least of your issues. This user has full access to your IMG, Basis transaction (Like delete a client) not to mention the thousands of SoD's generated. If this is a dev system and is being used to perform configuration for a new implementation, copy the SAP_ALL auth to a new role. restrict access to objects S_USR_GRP, S_DEVELOP, S_TABU_DIS. Deactivate the S_TCODE auth object and then manually enter and only enter the functional transactions required. Again this is not a role anyone should ever have in a production enviroment.

Former Member
0 Kudos

Hi Neelima

Are you able to create Profile for as you requested with similar access to sap_all without PFCG , su01 ..

How did you do that ? Pls share with me . I need to create similar also , pls treat it as Urgent .

thanks

Mehul

0 Kudos

well, once you have created that ZSAP_ALL profile as mentioned above, you should exclude the S_USER_* objects (or at least restrict them) and get rid of the PFCG, SU01 etc. transactions in the S_TCODE object.

but as usual you should keep the above posts in mind regarding the flaws of assigning such profiles at all

0 Kudos

There are several ways to gain access to user management based on a copy of SAP_ALL.

The obvious ones which are independent of your setup and implementation are (but not limited to) S_USER*, S_DEVELOP, S_BTCH_NAM...

Less obvious ones, which are dependent on your setup and implementation, could include S_IDOCMONI, S_DATASET, S_ADMI_FCD, S_RFC...

Of course, these objects have fields (often more than one, which interact with each other in sometimes complicated constructs to determine a user's authority to use something). So there might be reasons to give these objects with specific restricted values (although they appear at first to be critical).

If the system performs the correct authority-checks and reacts to them, then there is nothing necessarily wrong with any object (way beyond S_TCODE....), if the user has the correct authorization for the object, and in this case hopefully only ever has this signle role.

At least, that is my take of the topic.

Good luck!

Julius

0 Kudos

>

> Hi Neelima

>

> Are you able to create Profile for as you requested with similar access to sap_all without PFCG , su01 ..

>

> How did you do that ? Pls share with me . I need to create similar also , pls treat it as Urgent .

>

> thanks

> Mehul

Hi Mehul, if this is urgent then I suggest that you use the search for themes around "modify SAP_ALL"

0 Kudos

How to restict su10 by creating zsap_all

0 Kudos

>

> How to restict su10 by creating zsap_all

If you search as I suggested then you will get 3 posts straight away giving some info.

You need to:

Remove the tcode

Remove the relevant S_USER object access

Remove S_DEBUG with Replace

Which will give a superficial restriction over that function