Restrictions to SE16 impacts Standard Transactions that uses de same objects

[former_member1329783]

Will the configuration made to restrict access to tables through SE16 or SE16N will impact the standard (transaction) functionality that uses de same object?

[Monsores]

Hi Talita.

Nut sure if I understood correctly, but it seems you are asking if restricting table EKKO (PO header) in SE16N will cause problems in ME21N (PO creation), for example.

In this case, the answer is no. The authorization objects checked by SE16N are not the same checked by other tcodes (ME21N, in the example above).

Regards,

Marcelo Monsores

[former_member279014]

I agree with this answer.

The S_TABU_* auth objects that are called by SE16/SE16N/SM30 are only ever reused (to my knowledge) in very table-centric situations such as SAP Query, IMG Config, and similar.

As a good security practice, endusers in Prod should not have much (if any) direct table access, esp. if the data therein is considered "sensitive," even for viewing. And with access to change any table data, they could really foul things up. So as a SAP Sec Admin, I would only be providing this sort of table access when users have shown that they need it to accomplish something required.

Now, it is always possible that a custom program was written in such a way as to directly use or indirectly trigger these S_TABU_* authorization calls. Such concerns can be addressed by getting info from your developers and/or going to lower systems (preferably) and tracing run-throughs of transactions/code with tcode STAUTHTRACE.

But "except for exceptions," typical endusers running typical SAP productivity transactions will "almost never" trigger calls to these table auth objects (in my 24-years of experience).

[HammerM]

Hi Talita

If you're talking about restricting access through Authorisation Roles using Authorisation Objects, and all users with SE16N or SE16 have the exact same Role containing those restrictions, then yes all users will have the same restriction.

But if an admin user also has an additional Role on top with wider access to tables, then the Authorisation Objects for that admin user will get combined together and therefore give cumulative wider access to just the admin user.

Hope that helps

Mark