Authorization group changes for Security reason

[Former Member]

In Production sometimes I have to give access to "table" transaction like SM30 in modification.

When the authorization group is restricted to few tables, I can give access.

But some transactions are linked to views with LARGE authorization group like &NC& or VC.

So if I give access in change on S_TABU_DIS in &NC& or VC or others standards authorizations group, I potentially give the change access to others tables, so Ineed to restrict the access to SAP tables...

What do your recommend? What is the SAP best practices on this issue?

--> Change the standard authorization group to a specific one?

OR

--> Create a specific view with a specific authorization group and Create a specific transaction in this view?

Thanks a lot in advance for your answer.

Mélanie

[Colleen]

Hi Melanie

Another option is to avoid granting SM30/SM31/SM34 in Production by building a custom transaction code to access the table or view that skips the SM30 screen. Also, check if such a transaction already exists for the table you want to maintain (table TSTCP contains the parameter defs).

If not, see if you can use S_TABU_NAME instead of S_TABU_DIS (if you search marketplace or SCN you will find notes and information relating to this object). However, you would need to clean up the use of S_TABU_DIS

Regards

Colleen

[Former Member]

Thanks Colleen. It's works for ECC6 version.

But for 4.7 version... ? There are a SAP note to add this authorization object S_TABU_NAM ?

[Colleen]

4.7 is too old for that object. You would need to look at Z transaction code instead so you can avoid granting SM30 (pretty sure but haven't been on a 4.7 system recently to confirm).

[Former Member]

Thanks a lot for your answer Colleen.

SAP has sent to me this OSS Note Number.

1634305 - Advance implementation of authorization concept S_TABU_NAM

I will see if it's ok in my SAP system.

Thanks to all.

Mélanie

[Jelena]

We don't give SM30 authorization to the business users at all and found that using custom transactions that allow for additional authorization checks (e.g. by an organization code) works better for us. I wrote on this a while ago and there are also more recent blogs on SCN on using maintenance views. In some cases we have one program call maintenance view for several Z tables. Although the best approach is to avoid direct table maintenance altogether, I think.

[Former Member]

Hi Melanie,

You can create a customized T-code like ZSM30 where in you can specify authorization fields similar to S_TABU_DIS with an additional field which will have the table name under the customized authorization object linked to this T-code. So whenever a user executes the T-code ZSM30 the logic should work in such a way that it should first check the custmoized Authorization object and see if user has access to work on the particular table and then it checks for the S_TABU_DIS object with the required authorization values. In this way you can restrict the user.

Hope this helps.

Thanks.

Deepak grover