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 achieve SPRO display access without assigning SM30

Former Member
0 Kudos

We removed transaction access to SM30 to all users to avoid audit issues. But now no one can display/change SPRO activities(most of them).

Is there any way to achieve both (not giving the users access to SM30 transaction yet allowing them to use SPRO for display/change purposes)?

Thank you

4 REPLIES 4

Former Member
0 Kudos

This is caused by the fact that SM30 (and in some cases SM31) are used as the core transactions for the customizing views which call it with parameter values, from the various SPRO parameter transactions.

There are a few options available to you. The most secure one is to give them access to SM30 with the correct access to use it (objects S_TABU_CLI, S_TABU_DIS, S_TABU_LIN).

If this is not good enough or implementable for you, then you can list the transactions from SPRO in SE97 and define them as "couples" for SPRO - but you can be fairly certain that the user with the relevant S_TABU* authority will access that which they are authorized for without SM30...

Perhaps your auditors will accept a strategy to restrict all customizing access to broad display only if an authorization group is maintained, and then concentrate on defining the correct roles with change access properly => result is everyone in customizing can see what's going on, but only authorized roles can make changes where they are allowed.

It helps to have a concept for the S_TABU_DIS change access which is (client independently) matched to S_PROGRAM (no "display" activity is possible...)

May I venture a guess that your next question will be how to restrict the user to SPRO tcodes only and how to create the SPRO display all role?

This has been discussed here a number of times already (see the FAQ sticky thread at the top), but there is no golden rule - only some better and some worse designed solutions.

Cheers,

Julius

0 Kudos

Thank you Julius, I will have our security administrator take a look at the options you provided. If it works, I will come back and share it with you and others. If not, I will still come back with more questions:)

Former Member
0 Kudos

Even though we did not get it solved, I think we got a direction. Looks like it is a lot of work.

0 Kudos

At the end of the day, you need to understand the segregation of logical systems using the client (MANDT) and the development landscape using the change authority - and restricting the display authority as far as you can (from a strategic perspective...) in systems with productive data.

This requires some discipline, but you can also be pragmatic...

You might also want to take a look at [symbolic tables|https://forums.sdn.sap.com/search.jspa?threadID=&q=SM31ANDsymbolic&objID=f208&dateRange=all&numResults=15&rankBy=10001] as opposed to [symbolic groups of tables|https://forums.sdn.sap.com/search.jspa?threadID=&q=NCANDsymbolic&objID=f208&dateRange=all&numResults=15&rankBy=10001] ...

Cheers,

Julius