Question:
Hi,
My user wants to limit the authorization to view certain SAP tables to certain group of people. Eg. Only Purchasing department personnel are allowed to view EKKO, EKPO, EKET etc and only MM personnel can view MARA, MARC and MARD, etc. The existing SE17 transaction uses authorization group. The problem lies when a table is on the same authorization group but the people that will access this table belongs to different roles. How can I limit the accces?
I have created a dialogue transaction that mimicks SE17 but I don't know how I can limit displaying table contents per role.
Please help and thanks in advance.
Miles
Answer:
What you need to do is create transactions that read these tables. Then you can put any type of restriction you desire
Answer:
assign the tables to a custom authorization group of your choosing.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Thanks for the replies Guest and Gary.
In my program, the users are allowed to enter the table name itself just like SE16 or SE17. So for example, both MARA and EKPO belong to the same authorization group, even if I created different transaction codes for each role, a person in Purchasing Depratment will still be able to display the table just by putting the table name, eg. MARA. Though in theory, he is only allowed to view Purchasing tables hence he is only given the Purch transaction code.
If I create a custom authorization group each, for example for MARA, etc and EKPO, etc., will it affect the existing authorization profiles? Can a table be assigned to 2 or more authorization groups?
Apologies for so many questions, I'm an ABAPer and not so so familiar with authorization.
And lastly, I am using auth-object S_TABU_DIS in my program.
Thanks,
Miles
Answer:
I am thinking this post will help you think it through. If not. I suggest you read the documentation on S_TABU_DIS and the online help for Auth Groups and tables. The objective you are wanting is not difficult. First of all avoid using SE16 and it sounds like you have set it up to use a transaction code instead which is good, then the next step is to define the tables to be assigned an auth group that will meet your needs. Auth Groups are very flexible. Most of the time the auth groups are not being checked so you do not have to worry about breaking something when you assign a custom group to a table. Hope this info I recently posted on my site helps.
Consider using SM30 or SM31 when a user must have direct access to tables. It is more secure because a maintenance interface must exist for the table in order to view the table in SM30 or Sm31. You cannot look at Any table.
Or you can create a custom transaction that goes into SE16 and then into the table.
SE93 > enter custom transaction name > Create > Description in short text field > select transaction with parameters > enter text of your choice in the Transaction text field > enter SE16 in the transaction field > select skip initial screen > save your new transaction code.
Local object in lower part of screen you will see default values name of screen field value select teh name of screen field, . F4 and choose DATABROWSE-TABLENAME enter the name of the table in the value field you are giving access to.
Save > local object
now test it by entering in the transaction code, it should skip past SE16 and give the same access to the table as though the user had used SE16.
You could use this method if protecting by S_TABU_DIS and auth groups was not a good solution for you.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Proper solution proposed by Gary,
but when the user enters the new transaction, gets the result and presses the 'back' button, he will enter the SE16 trnasaction where he can enter all tables (from the given authorization groups)
This problem seems not be solved in 46C.
_________________
Kind Regards/Vriendelijke groeten/Amicalement,
Wim
Answer:
There is an OSS note and hot pack to fix the SE16 problem, but ther eis nothing wrong with SE16 if you control it corretly, ie change the auth group on the table SUCU or SE54
Answer:
Hi
The note John is talking about is 583282
Regards
Morten
Answer:
One more option: if you have a limited number of tables, then you can create a query, generate a program and assign a program to a Tcode instead of giving SE16.
Answer:
Did you check "skip first screen" when you create your transaction parameter?
I am using the transaction parameter to limit access to table since 4.0 without any problem.
You can also change the authorization group of any tables even standard SAP tables to another authorization group. The table TDATT is delivered as customer not sap...
I hope it helps
_________________
Vince
SAP Security Specialist
Identity Management
Answer:
Create a custom auth object as copy of S_TABU_DIS with extra field for Table Name.
You can then restrict on specific 'table name' via new custom object