How to work with S_TABU_DIS

[Former Member]

Hi All

I've never worked with S_TABU_DIS. Now I've a situation where I have to give a user an access to a particular table. I know S_TABU_DIS has two fields "ACTVT" and "DICBERCLS", how and where I need to add this authorization object to accomplish my above task. I would appreciate your response.

Thanks

[Former Member]

First. Have you challenged the user as to why he absolutely has to look directly in the table?

Second. You cannot really give access to only one table. You will give access to a group of tables. You can see the table groups in TDDAT. If you need to give access to this particular table, you would have to assign it to a new table group.

Third. You can provide the access through fx. SE16.

Personally I would not recommend this though

[Former Member]

Hi Mr. Blaster,

You wrote: <i>"Personally I would not recommend this though :-)"</i>

What is wrong with SE16 / SM30 / SE16N etc (or any other which is not more critical than having no authorizations for the system) if the user has the correct authorizations for S_TABU_DIS?

Cheers,

Julius

[Former Member]

Hi Julius,

Yes I know what you mean, and technically I do not totally disagree.

As a general rule though, I am personally against giving access to direct table access to end users. Sometimes I would give access to SM30, but it is still difficult to control.

Sure you can assign a particular table (fx. PA0001) to a customer specific auth.group (ZX) and then the access is only given to this one table. But as an security consultant, you lose control over the access since you rely not on the particular table name, but the auth.group, so when another table is assigned to ZX, then this would also be accessible without you changing the role. Perhaps it is okay, but then again, perhaps it is not.

I have always fought against giving access to SE16 to end users, and has so far won the battle.

But perhaps I should give out SE16, without S_TABU_DIS, just to fight the auditors

[Former Member]

Good points. As an ex-auditor, I have some limitations in the practical application of my security ideas...

So it seams that the more tables there are to be maintained (in production) or displayed directly, the less feasible it becomes to use the security of s_tabu_dis and you have to rely on (lets say 100) maintenance view generating transaction codes and leave s_tabu_dis open.

I can live with that, but what I don't understand is how maintaining some table auth-groups on 100 tables (inserting multiple lines at a time into SUCU and the role) can be more effort than creating 100 transactions (each on their own) which call SM30 anyway?

PS: If you want to fight the auditors, maintain the tables from a different client.

Cheers,

Julius

[Former Member]

You can also use tcode SE54. You can select the table or auth group. For example, table VBAK has auth group VA. Enter in S_TABU_DIS the access to auth group VA and the role will be able to access table VA through either SE16 or SM30/SM31.

[Former Member]

An alternate option to SE54 is transaction SUCU. It is a maintenance view to TDDAT field CLASS. It enables table authorization group maintenance for tables (only) and checks also the required authorizations for the assigned table group (only).

SE54 checks more (e.g. S_DEVELOP 03 at transaction start) and might be adding many more authorizations than you want the user to have (assuming the security administrator doesnt have something stronger anyway...) Take a look at your SU24 settings to see the difference which achieves exactly the same.

S_TABU_DIS also goes hand-in-hand with S_TABU_CLI as the authorization group concept of tables is client independent (TDDAT is client independent even if TBRG is not...).

I have observed that sometimes S_TABU_CLI is misunderstood. It is not an all or nothing authorization for client independent tables - the user still needs the S_TABU_DIS activity and auth group of TDDAT-CLASS to maintain client independent tables, assuming that the user has the correct authorizations (e.g. S_TABU_DIS when required) and is limited to correct functinality to display or maintain tables (e.g. SM30, SUCU etc).

I approach any transaction with S_DEVELOP 03 as an additional authorization check at transaction start (visible in SE93) with caution / or delight.

[Former Member]

hello Imran,

S_TABU_DIS is the authorization object which allows access for table entries. The activity filed determines the kind of action a user can make on table entries (create,display,change etc.). Secondly the field DICBERCLS makes use of the authorization group assigned to tha table. You can check for it in table maintenence generator. Once you give access for one authorization group then then the user will have same access for all tables belonging to that group. I hope this answers your query.

Please award points accordingly.

regards.

Ruchit.

[Former Member]

Hello Imran,

To add further you need to add this authorization object in an appropriate role already assigned to the concerned user or you can create a new role for this throgh PFCG. Check for the role which has SM30/SE16 transactions aleady present in it and is assigned to the user. In case of new role add these transactions and then you will find this authorization object coming on its own with in the role.

regards.

Ruchit.

[Former Member]

Hi Juluis,

I guess Master blaster is pretty much correct from his perspective in not giving access to SE16 to users because it gives access to data outside one!s own organizational unit. User can see data for other company codes/plants etc. S_tabu_lin doesnot work for se16 unless you change se16 code for it.

Your views are also correct Infact SE16 should be allowed to consultants but not really to end users. We use a custom report instaed of se16 making use of s_tabu_lin.Unfortunately auditors are very strict about these thing.

regards.

Ruchit.

[Former Member]

Hi Juluis,

The custom transactions for tables or SM30 view is a valid approach since it actually will test for s_tabu_lin.Infact this is what is done a lot of times. But then you can,t have this approach for standard SAP tables for which there is not table maintainence generator maintained or for certain tables for which you donot want to create maintainence view.

Also normally the authorization group maintainence can be done in SE11 at the time of table creation so there is not too much of extra effort involved using SUCU.

regards.

Ruchit.

[Former Member]

Hi Ruchit,

I agree with you, primarily because there is little difference between a customer maintenance view transaction and SM30 (the main difference is an additional transaction code).

<auditor_hat>

As an auditor I would look for:

a) The table authorization concept should be auditable.

b) The system tables should be secure for the users.

c) I would try to break the concept as an adventurous user and provide some surprises in the audit report.

In practice these are:

a) It is much easier to know that SM30 works correctly and audit the assigned tables of the authorization groups, than to spend hours sifting through Z* transactions and SUIM because security claims that it works.

b) Just one of many little mistakes in the role design and the user will bypass all your transaction code security and maintain (or display) any table which they have S_TABU_DIS authorizations for anyway.

c) An auditor could find (at the very least) one surprise and would recommend that you use S_TABU_DIS anyway. These audit reports will create work for the security administrator every time they get audited... hmmmm...

SAPs standard tables are also a part of the table authorization concept and if there is a good reason to do so you can even change the delivery class of the table to make it maintainable and a more secure fit to your concept.

Regarding SE11, as an auditor I would say that developers create tables in SE11, and, security administrators maintain the table authorization concept in SUCU and PFCG.

</auditor_hat>

Yes, it is a pain and thank goodness the auditors are so stupid!

)

Cheers,

Julius

[Former Member]

Hello,

As a Security Officer rookie I need your help.

I am trying to give an access to a non-standard table (through SM30) to one end-user.

Here is what I have made:

- <b>SE54</b> => created a new Authorizathion group called: Z000 (access to specific tables)

- <b>SUCU</b> => Assigned the new table to that Z000

- <b>PFCG</b> => New role dedicated especially to this end-user with :

Table Maintenance (via standard tools such as SM30) = S_TABU_DIS

ACTVT 02,03

DICBERCLS Z000

And then, I have assigned the end-user to this role.

The problem is he has an access to other tables as well.

I have tried lots of things but no success.

Thanks in advance to enlighten me.

Julien

[dhorions]

I suggest you take away the new role from that user and let him check if he can still access all these tables.

If so, use transaction SUIM to look for roles that contain the object S_TABU_DIS with less restrictive values.

[Former Member]

I have already tried this. And of course, he has no access to SM30 (and therefore no access to any tables).

[dhorions]

The fact that he has no access to sm30 does not mean that he has no S_TABU_DIS authorization.

It's quite possible he has S_TABU_DIS for all authorization classes, but cannot access tables because he does not have S_TCODE for sm30.

So you better check suim to look for all occurences of S_TABU_DIS for this user.

[Former Member]

How stupid I am, you are totally right. I forgot to check that! there are plenty of role with this object and value *

OMG!

Thanks a lot.

[former_member287386]

Hi guys,

i would very appreciate your advices to my situation: i'm a PM for a small project where we have promised to deliver to our division customer an interface monitoring via SolMan. Frankly, we monitor idcos running between two sap systems via BPM functionality in SolMan.

The prerequisites for the end user (working in Solman) from the authorizations perspective were that he needs a role for BPO workcenter and another one where in the object BPM_DETAIL would be specified authorizations for one of the managed systems where the idocs arrive in order to see detailed message/status of failed idocs.

Now, after component ST-A/PI version 01N was released, the auth.logic for BPMon has changed significantly.

All described in note 784752, v43!. Shortly the main consequence is the user needs S_TABU_DIS, ACTVT=03 with 'SS'auth.group in the managed system. Ofcourse, the basis admin for the monitoring system will not grant the object for my end user.

Now what? I don't need transactions SE16/SE16N/SM30/...but this doesn't help because for the T_CODE we don't apply any general security ban here. Many users may use SE16 with S_TABU_NAM for Z*tables.

ANY HELP APPRECIATED, THANKS IN ADVANCE!

miguell

[Former Member]

HI,

1) IN SE54, select radio button authorization group and click on CREATE/CHANGE.

2) Create authorization group.

3) Now we want to assign a table to newly created authorization group.

4) Go to SE54, select radio button ASSIGN AUTHORIZATIUON GROUP and click on create/change

5) Select check box TABLES NAME.

6) Now, change the authorization group of the table in AUTHORIZATION from old i.e. previous auth group to newly created authorization group.

Note:

A table will be assigned to particular authorization group only. When we try to assign this table into another authorization group, it will be moved to newly created authorization group.

Regards,

VInod.