Authorization Object S_TABU_DIS (Table Maintenance)

Definition
Authorization object that enables authorization checks for displaying or editing table content. This object controls access though standard table maintenance functions (transaction SM31), extended table maintenance functions (transaction SM30), or the Data Browser. This includes access through the Customizing system.

Use
With this authorization object you can, for example, restrict access just to data in table entries defined in this object; even if the user who wants to access the data has authorization for transaction SE16 (and therefore for all ABAP Dictionary objects). In this way, you can prevent system administrators from accessing application data. Once you implement this authorization object, only those table entries can be modified or displayed that have been given the appropriate authorization in S_TABU_DIS.

Structure
The object consists of the following fields:
Authorization Field Long Text

DICBERCLS ACTVT

Authorization group Activity

Further Information About the Fields

The DICBERCLS field contains the authorization for tables according to the authorization classes in table TDDAT. Here, you specify the names of the permitted classes. Table classes are defined in the table TBRG. The ACTVT field contains the permitted operations. It can take the following values: 02:Change (add, modify, or delete table entries) 03: Display table content

Integration
If you want to protect cross-client tables, you can add the authorization object S_TABU_CLI to the general table maintenance authorization with S_TABU_DIS. If you want to implement more detailed table maintenance authorizations (for example, if you want to protect country-specific data records in tables with data from more than one country (such as T510A)), then you can use the authorization object S_TABU_LIN.

Edit SAP tables: Your SAP Security Admins nightmare: &sap_edit

Updated - It does not matter what access you have for table editing (S_TABU_DIS). Just use the command &SAP_EDIT in the command field in SAP and off you go: you can edit table content directly. This works if you have debug with changes access for object S_DEVELOP, but S_TABU_DIS is ignored as well as the system settings regarding changes. If you use this function for transaction, master data or other tables that cannot be changed with SM30, you can cause quiet some damage. So, use with caution and this is NOT a Best Practice by all means, but to educate you on a little documented feature: Step 1: Use transaction UASE16N, SE16N or transaction N (yes, there is a transaction called just N) and enter a table of your choice, for example SKA1 G/L Account Master (Chart of Accounts)

2) In the command field enter &SAP_EDIT and press enter. The maintenance indicator in SE16N will switch on.

3) Limit the search of your data or execute for all values and you will see, that the table entries can be edited:

If you limit the users access not to have access to S_DEVELOP with change activities for object type DEBUG, this function will not be possible (tested on ECC5) If you want to allow this function, you can audit who changed data via SE16N by browsing the following tables; SE16N_CD_KEY : Change Documents Header SE16N_CD_DATA : Change Documents Data You can also run report RKSE16N_CD via SE38 (or create a custom transaction for it for ease of use). We recommend to apply SAP Note 1420281 CO-OM tools: SE16N: Deactivating &SAP_EDIT. SAP will deliver this correction with Support Package 17 and Support Package 18 (Release 600). This note deactivates the SAP Support function &SAP_EDIT completely for SE16N Please make sure no users have access to transaction UASE16N as the users may use it as alternative. Please leave a comment if you have tried this out: SAP note 1446530 enables one to use again the SE16n edit function on a case to case basis. As an authorization check it uses S_ADMI_FCD with field DBA. But wait, there is more. If your developers have access to SE38, SE80, SE37 and other development transactions, they may want to trick you by using SE37 and executing function module SE16N_INTERFACE with the options I_TAB, I_EDIT and I_SAPEDIT activated and still maintain tables. The good thing is, that these changes are recorded and can be viewed with report RKSE16N_CD, the bad thing is that it may be already too late if the users changes financial data or any other tables that are not supposed to be maintained via SE16 type of transactions. For starters, you should not give any development transactions to anyone outside the development environments and only allow SE37 etc. to be used via emergency procedures as once development access is granted, the users have the keys to the kingdom.

Now, if you still want to give access to development transactions, you need to lock them down. For the Function Module SE16N_INTERFACE, you need to exclude activity 16 and Object name SE16N for object S_DEVELOP. This post will be updated continuously due to the several issues with this function.

The authorization object is S_TABU_DIS and the transaction is SM30 or SM31. First check the table to see what authorization group has been assigned (SE55). When creating the authorization for S_TABU_DIS, use this group and the activity code (03 = display only), (02 = change), (01 = add) that is appropriate. REMEMBER - this will give the user authorization to EVERY table in the authorization group. There is no way to restrict it to just one table unless you change the authorization groups. Julie Julie McAfee Top

Does that mean

by ak4sap on Mon Oct 21, 2002 10:48 am Does that mean that we have to give access to SM30? And as far as I know, it is a restricted table! Is there a way around that? AK ak4sap Top

by Julie McAfee on Mon Oct 21, 2002 12:58 pm You either give the user SM30 or SM31 or create a new "Z" parameter transaction that will run SM30 for a specific table only. I'm not sure what you mean by a restricted table. Do you mean an IMG/config table? Let me know what table you want your users to see and what level (display/update) of authority you want them to have. Julie Julie McAfee Top

by Guest on Tue Oct 22, 2002 6:45 am If they just need to display a table, you can give them SE16 instead of SM30 or SM31. Steve Guest Top

by Lyell on Thu Oct 24, 2002 2:26 pm Use Transaction SE93 to create your own t-code. Give them access to SE16 with the parameter of the table-name - make sure you select "skip initial screen". This way they can view just thr table specified. Lyell

Top

by JoolsG on Tue Oct 29, 2002 1:51 am Hi, Alternatively, you could create a query, (if on 4.6), rather than give access to se16. You could then give them access to transaction SQ01, (query). When you create the user group, you assign the users as required, and also whether they can display only, or display/change the query. Thanks J JoolsG Top

by John A. Jarboe on Tue Oct 29, 2002 8:02 am The problem with Query is if not structured correclyt there is no authority check on accessing the table and assigning a user to ONE user group in SAP QUERY gives them access to ALL queries. The best solution is to either create a parameterized tocde executing SM30 directed to the table ( see tcode OB52), which you will still need to give S_TABU_DIS to the user. There is nothing wrong with assigning SM30, SM31 or SE16 to users as long as you give display access to the table. you can change the auth group to the table using SUCU or SE54. Most all critical tables using SM30 are "lockled " in production be the client setting so evel if you slip up and give Change the table is protected by the System Setting. John A. Jarboe Top

by pdfernandez on Fri Nov 08, 2002 4:28 pm Hi AK, You should do what Lyell said...but don't forget the correct values for S_TABU_DIS. Don't use SM30 to read tables. Many transactions need S_TABU_DIS with ACTVT 02...and, if the user has SM30....it may be dangerous. Regards. Pablo pdfernandez Posts: 2 Joined: Fri Nov 08, 2002 4:09 pm Top

by John A. Jarboe on Mon Nov 11, 2002 8:57 am SAP defaults SM30 to read if you do not have change access to the table. SM30 does NOT require change access to get to the table if the table has been generated to be viewed or changed in SM30.