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 restrict basis related tcodes from profile SAP_ALL

Former Member
0 Kudos

Hi Experts,

i am new security moduel. I want to restrict basis related t.codes from SAP_ALL but all other module tcode must be excute by Users.

please help me to sort out.

WR,

PHB

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

  It is not possible to edit profile SAP_ALL. The best idea is, you can copy and create the role according to your need. If you want to check this profile, you can open T-code SU02 and check.

Thanks

Varun

10 REPLIES 10

former_member215981
Active Participant
0 Kudos

Hello,

SAP_ALL is complete authorization. It is not possible to exclude

values from SAP_ALL.

Workaround: pfcg create role (w/o menu)-y<authorization tab

change->chooes sap_all draft from popup .

then after authoriaztions are inserted, deactivate S_TCODE=*

Enter instead intervals, which do not cover the basis tcodes.

Best Regards,

Yong Luo

0 Kudos

Hi,

I would not suggest to import SAP_ALL and then start removing authorizations. It's really hard to get it right. It's quite easy that you forget something that allows user to bypass restriction. For example if user can execute reports using SE38 or SA38 (normally you don't call these basis transactions) then in many case a user can execute program directly instead of executing transaction. In security it's always better to start from zero and add additional authorizations. Also figuring out all basis transactions is quite tricky. Hence I would suggest to get list of transactions that needs to be accessible to user and then build a proper role. It will be more work but it will pay off.

Cheers

magexposito
Active Participant
0 Kudos

Hello Prabaharan,

Is there any reason why you want to do this? If you want to assign a SAP_ALL profile to an end user let me say you should never do this. Instead of that you should create the proper roles with the transactions that the user should execute and assign that roles to the users. Modifying the SAP_ALL profile is not the best idea at all.

Best regards.

Former Member
0 Kudos

you are not suppose to edit or change the profile SAP_ALL. if you want to restrict the basis access.. create a role and assign authorization except basis.

Former Member
0 Kudos

Hi,

  It is not possible to edit profile SAP_ALL. The best idea is, you can copy and create the role according to your need. If you want to check this profile, you can open T-code SU02 and check.

Thanks

Varun

Former Member
0 Kudos

Hi PHB

all previous answers are correct so i try to process your question in a different way

Why dont you create a new role and then you add in the authorisation profile with button "selection criteria" all authorisations except the one from BC_A , BC_C and BC_Z

This will not be perfect because sap is based on BC (God bless basis )so you will need to add some necessary basis authorisations but it will be best solution for you i believe

Good luck

a

Former Member
0 Kudos

Hi

You are building 'the wrong way around'/'in reverse' etc. To build a role you need to know what the unit needs to use, they need to provide that information. Then you build a role with minimal access and take it from there.

Thick skin and a good sense of humour required from that point on.

Or you give wide access, have a coffee break and move onto the next job 🙂

Kind regards

David

Edit - Martin already covered this aspect - sorry

Former Member
0 Kudos

I can't imagine there is a person within the organization that needs All authorizations (with or without BASIC transactions). This will result in tons of risks (a.o. Segregation of Duty conflicts). Your internal auditor will not be happy with this.

Maybe a better solution is to create a firefight solutions?

0 Kudos

Hi

We still do not know if this is for DEV or PRD. If DEV then let them provide the transactions, define the application components for each (for approvals) and build with minimal access as possible in an established system. For PRD -FF/EAM is realistic but, again, they need to define the transactions required. Then the testing to confirm access is suitable, mitigate any criticals in whatever GRC has been adopted. Still need to define a PRD normal access set of roles in the meantime...

Let's see what the poster has to contribute - that would be interesting 🙂

Kind regards

David

Former Member
0 Kudos

This message was moderated.