how to restrict without role

[Former Member]

Hi to every one,

i want to know one of our user having sap_all &sap_new profile.

so that is super user .

if i want to restrict for some tcode like sm12,sm04,st02and etc.

without assigning any role ....

means if i create role then it will not be the solution because user eant all authorization except sm12 ,sm04 and st02.

so guide me what should be the way to do so.

Regards

Dik

[jurjen_heeck]

Read the sticky thread and/or use the search.

[Former Member]

first of all take away SAP_ALL as there is NO Reason anyone should have this,

secondly discuss with user what access is really needed and creat a role or roles for that.

Never trust a user that can not tell you what transactions he/she needs for their job!

[Former Member]

Hello,

Any roles which have * authorization can easily over write other restrictions. My suggestion is remove e these type of roles from user profile and give access to necessary tcode only.

Regards,

Geetha

[Former Member]

>

> Hi to every one,
> i want to know one of our user having sap_all &sap_new profile.
> so that is super user .
> if i want to restrict for some tcode like sm12,sm04,st02and etc.
> without assigning any role ....
> means if i create role then it will not be the solution because user eant all authorization except sm12 ,sm04 and st02.
> so guide me what should be the way to do so.
> Regards
> Dik

If I understand your question completely you need a role with access to SAP_All but want to remove few t-codes like SM12, SM04 etc.

Well this can be done but roles like these are clumsy. Anyway here is one way.

1> Create a role and do not add anything in the menu tab. Straight away go to Authorization tab and select the SAP template for SAP_ALL.

2> It will insert all Authorizations to the role. Now search for S_TCODE. Notice it is added manually.

3> It will have * in TCD field, which means access to all t-code. Now instead of * you can select the range like 0-9* , A* - N, etc ....as good practise you do not give S, O*, PFCG etc .....or you want it to be more granular like no access to SM12 then check the t-code before SM12 and after SM12. Give the range excluding SM12.

[Former Member]

I assume that you are being sarcastic as your other posts seem okay...

The user could just give themselves the real SAP_ALL or any other role back again... or skip the tcode check in the debugger... or create a new transaction which does exactly the same... or simply find a standard one which does exactly the same... or access an untold number of transactions which have menu options which are exactly the same... or test development objects which do exactly the same, or... or... or....

Another bugger with roles such as these, is that when they are mixed with other roles which are built correctly to control the access of the user when using a certain set of application area transactions (which is different to just starting them...) then you have a whole set of different authorization concepts in the system assigned to the same users.

As a single point of failure, together with a whole set of different programming techniques (including bad ones equivalent to the authorization aspect here of ranging tcodes but leaving other objects open), I would rank this amongst the top loosers.

People who "sell" such solutions under the banner of "security" are incompetent and create a mess for others to fix after they have gone, and SAP_ALL has moved on as well (with SP and releases) as it is regenerated from the new SAP_NEW...

Cheers,

Julius

[Former Member]

Well I know roles like these are clumsy and it is never a good practise to have a role with SAP_ALL and never something like this in Production and however you try to limit it..there may be a way to take advantage of this role.

So lets try to minimize the access to roles like this because sometimes in dev system functional consultants ask for roles like this.

"The user could just give themselves the real SAP_ALL or any other role back again"... -> Let us remove SU01, SU10, PFCG ....or better lets us remove SU* and PFCG from this role. So that user do cannot give themselves anyother role or t-code. Also remove S_USER* object

or skip the tcode check in the debugger... or create a new transaction which does exactly the same... ->

Let us remove all SE* t-codes like SE38, SE93 ..also SA* .....also remove S_DEVELOP with object type DEBUG, PROG etc ..restrict S_ADMI_FCD, S_SPO_ADMIN, S_BTCH_ADM etc and other S authorization object

"Another bugger with roles such as these, is that when they are mixed with other roles which are built correctly to control the access of the user when using a certain set of application area transactions (which is different to just starting them...) " --> Right..so we do not give this role with any other role...lets create a id for it ..something like a super user id and add this role to it. And give it only in the cases when you have approval for it.

" SAP_ALL has moved on as well (with SP and releases) as it is regenerated from the new SAP_NEW..." -> This role is created from SAP_ALL as template ...I am not sure it means when SAP_ALL changes this custom role will change itself. The Role is created and until you change it yourself, it should not change automatically.

[Former Member]

Do that (blanket exclusion of S_* objects etc) and then they cannot do their work either regardless of the transaction. They will end up with SAP_ALL again, or disappear into the workaround-world.

The best way to do it is to choose the correct entry points (commonly understood to be "Transactions") to start an application and choose the powerfull ones for powerfull users, but then give the user the correct authority to use those transactions correctly (which is different to just starting them) and train them well so that they know what is sustainable and what is not (even if they theoretically have the access to code rubbish, or create defunct roles...).

That would be my 2 cents to the discussion, and I raise anyone who wants to lock transations in SM01 another 2 cents...

Cheers,

Julius

[Former Member]

In the ideal situation as a security consultant, you would like to get the t-codes from whomever needs it. That is the best way to go ..but lets face it, there are times when the users will ( most of the times the Basis guys and functional consultants ) not be clear enough about the requirements. As a security consultant I would prefer to get the t-codes from these guys for sanctity of roles, but at times somebody has to budge.

We faced a situation where the functional consultants wanted to display all their configurations in the production at the time of cutover phase of the project and basically they wanted SPRO display for their MM and SD modules which for me is not a clear enough requirement. There are lot many t-codes under the sun for these modules and they were reluctant in answering what exactly they need. Their view was under SPRO there are so many t-codes..it is not possible to tell you everything.

So we had to resort to create something like SPRO display role having just actvt 03 ..which for me was really a taxing task, but a situation like cutover are times, when talking about rational thinking to your boss...does not impress him ...he needs result so that there is no delay in golive and pursuing on my t-codes demand was not going well

Again blanket exclusion of S_* objects is never acceptable.. you have to restrict them...something like S_tabu_dis should not have 02 capability with * Auth group if you want to protect your client specific table, S_BTCH_ADM should not be Y if you are not batch admin, S_TRANSPRT should not have DELE value, S_ADMI_FCD should not have SP01, SPAR, SPAD if you are not spool admin etc ...

[Former Member]

Fair enough. In reality there are such requirements particularly during "intensive care" times such as Go-live, but the bugger is still that there might be an application in there which is only checking S_TCODE and other seemingly harmless authorizations, but infact can make changes. I don't think that you will find them all, so the user hopefully won't either.

Such a role (ranged tcodes and objects restricted to "display" type of activities and other action related fields) should however not be assigned to a user with another role in which the tcode or some setting in one if them is being relied upon to prevent access (e.g. changes) which the objects would otherwise permit (e.g. customizing and developer roles transported through to production).

Looking at the question, it is the latter case we are dealing with here, which is in my opinion a greater evil than the one you have described above...

Cheers,

Julius

[Former Member]

>

>

> Such a role (ranged tcodes and objects restricted to "display" type of activities and other action related fields) should however not be assigned to a user with another role in which the tcode or some setting in one if them is being relied upon to prevent access (e.g. changes) which the objects would otherwise permit (e.g. customizing and developer roles transported through to production).

>

>

I completely agree !!

[Former Member]

Hi,

Can you please brief me that point

*3> It will have * in TCD field, which means access to all t-code. Now instead of * you can select the range like 0-9* , A* - N, etc ....as good practise you do not give S, O, PFCG etc .....or you want it to be more granular like no access to SM12 then check the t-code before SM12 and after SM12. Give the range excluding SM12

In TCD field there is only * means all authorization .

exactly

but i want to restrict some tocode....

so what will be the next step .

[Former Member]

Hi,

I would suggest to do one of the following in your scenario:

1. Create a new single role with all necessary transactions (from SAP_ALL) only.

Note: In this case expect few questions from the auditors!!

2. Create a new role by copying SAP_ALL and remove the transactions which you would like to restrict.

Hope this helps.

Manoj Chintawar

[Former Member]

Dear,

But how can i perform that task ..

means how to remove other t-codes in sap_all.

regards

dik

[Former Member]

I think Manoj is joking with you...

[Former Member]

Guys

the whole question is a joke!

first of all the question is how to restict Whithout role, so the answer is simply YOU CANNOT!

secondly all other answers and responses lead to one conclusion the person who asked this has no experience what so ever with roles and building of roles, so please attend a security course with SAP!

Or read authorisations made easy available form Amazon.com.

In that book there is a complete description of how to build a role called Company_all from the SAP_ALL profile and how to restrict that to your own needs!