Authorization Object S_TABU_NAM

[former_member211709]

Dear Experts,

With refernce to S_TABU_NAM, Is there any possiblity that S_TABU_NAM ovverides S_TABU_DIS in the system

Pls provide some inputs

Regards

Krishna

[Former Member]

Yes, there is an intended possibilityand it works in almost all cases.

But there are a few exceptions.

Is that your question? Which exception did you find and what release SP are you on?

Cheers,

Julius

[former_member211709]

Hi Julius,

We are on Version:ECC 6.0

                     SP : SAP_BASIS& SAP_ABAP:702-SP10

Now our concern is "S_TABU_NAM authorization object should override S_TABU_DIS when users use SE16/SE16N/SE11"

Pl throw some light on the above !

Regards

Krishna.

[Bernhard_SAP]

Krishna Mohan Charugundla wrote:
Now our concern is "S_TABU_NAM authorization object should override S_TABU_DIS when users use SE16/SE16N/SE11"

Hi,

that is exactly what it should do.... if the check for s_tabu_dis fails, S_TABU_NAM is checked....

if that S_TABU_NAM-check is succesful, user will see the table (content).

b.rgds, Bernhard

[Former Member]

Hi Krishna,

What S_TABU_NAM does is providing authorization for tables by table name instead of auth group of that table, for example you have given 03(display) activity for authorization group ZZ in S_TABU_DIS, now there is a table ABC which has auth group ZZ and you need change access to it so we add S_TABU_NAM with 02 activity and give table name as ABC. This way you can protect other tables of that auth group and give access only to the intended data.

[Former Member]

S_TABU_DIS has two fields:

Activity    - to define the kind of access for the table authorization group
Table Authorization group - contains the table authorization group for which the access specified in activity is given

All the tables belong to some authorization group. The tables that does not belong to group are grouped under authorization group &NC&

S_TABU_NAM has two fields :

Activity    -  to define the kind of access for the table Name
Table Name   - Name of the table to which the access specified in activity is given

S_TABU_CLI has one field - CLIIDMAINT which can have value

X  - if client independent tables access is givev
' '- if client independent tables access is not given

When accessing any table via SE16, SE16N, SM30 etc the authorization check for S_TABU_DIS is checked first.

If auth check is successful, access is granted as specified in activity(02 for change and 03 for DIsplay)
If auth check is failed, auth check for S_TABU_NAM is done.

If S_TABU_NAM auth check is success, access is granted as given in activity specified in S_TABU_NAM.
If S_TABU_NAM auth check is failed, access is not granted.

[Colleen]

Hi Krishna

My opinion/view based on comment I made in Otto's blog as well as his overview:

Generally, the S_TABU_DIS is checked first. If the user is not authorised then S_TABU_NAM is checked if a functional module for authority check on table is called.

I have across cases where S_TABU_DIS has been hard-coded instead of calling the authority check for tables. It's still calls authority check but specifies check on object s_TABU_DIS. It means you can't grant S_TABU_NAM instead. Most recently example is with some of the Gateway/Fiori configuration transactions

The other bit (which Otto made mention of) is some of the SE93/TSTCA definitions have S_TABU_DIS in them so you can't get away with s_TABU_NAM only.

Regards

Colleen