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: 

Restrict SE16 for some tables

Former Member
0 Kudos

I wanted to give access to users to SE16, but i want them to access on the some Z*Tables and Standard tables (BSID,BSAD ...).

I tried to create a Group of Authorization with the tables in SE54 to insert in S_TABU_DIS, but I didn't get because some tables already had their defined groups.

What do I make?

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Francisco,

You can use the search function on this topic. SE16, S_TABU_DIS has been discussed many a times. Probably, you will find an answer in the search itself.

Just to start....

Access to SE16 is never recommended in a production system. Giving access to SE16 would give a lot behind the scenes.....

for. Example.... you may assign authorization groups to all the tables you want to restrict to. However, there might be a case that that authorization group is also assigned to many other tables ( like you are facing in this situation. Some tables are already assigned to auth groups. That auth group may be assigned to other tables as well)

In turn you are giving access to those tables as well. Also, S_TABU_DIS maybe present in another role assigned to the user, which may give them access to more additional auth groups/tables.

To ensure good security and a best practice in a production system, you can consider creating custom tcodes for display access for each of the tables. Then you dont have to worry about giving SE16. Although, you might still want to go ahead and secure the custom tables by assigning them auth groups as a good practice.

Hope this helps

Thank you

Abhishek

2 REPLIES 2

Former Member
0 Kudos

Hi Francisco,

You can use the search function on this topic. SE16, S_TABU_DIS has been discussed many a times. Probably, you will find an answer in the search itself.

Just to start....

Access to SE16 is never recommended in a production system. Giving access to SE16 would give a lot behind the scenes.....

for. Example.... you may assign authorization groups to all the tables you want to restrict to. However, there might be a case that that authorization group is also assigned to many other tables ( like you are facing in this situation. Some tables are already assigned to auth groups. That auth group may be assigned to other tables as well)

In turn you are giving access to those tables as well. Also, S_TABU_DIS maybe present in another role assigned to the user, which may give them access to more additional auth groups/tables.

To ensure good security and a best practice in a production system, you can consider creating custom tcodes for display access for each of the tables. Then you dont have to worry about giving SE16. Although, you might still want to go ahead and secure the custom tables by assigning them auth groups as a good practice.

Hope this helps

Thank you

Abhishek

Former Member
0 Kudos

Hi,

Adding to the above post,

When providing direct access to the table , use transaction sm30 /sm31 as a maintainence interface is must

for the table in order to view table in sm30 /sm31. This ensures

that you cannot look at any table in sm30 /sm31 ;the table must have an interface created specifically for sm30 /sm31.

But still if se16 is required ,It is better to create a custom tx code such as ZSE16_TABLENAME that will ,instead of taking directly to table ,customized tx will take to se16 and then directly into table.

Regards,

Ajit