Question:
hi
We have immediate requirement in Authorisation area.
Example- We have 10 users with access to T-codes SE11 and SE 16.We need to restrict only three users to specific Ztables.
Please suggest as how do we do this in Authorization objetcs.
Thanks in advance.
Thanks
Rex
Answer:
Table access is controlled via the S_TABU_DIS object.
Assign each table to an auth grp & then give them only the auth grp(s) they need.
Answer:
Hi, Can u expalin in more detail about ur answer wht u have given so that every one can understand in a better way.
Answer:
locate the table in TDDAT or (V_DDAT) in SE16.
assign the corresponding auth group in S_TABU_DIS
Answer:
Dear Ket,
Here is littel confusion Just to confirm...
My requirement is Three users X.Y,Z should access ZTABLEABC and not other users who have access to this table through SE16.
Now
Please correct if my steps are OK
1.locate the table in TDDAT or (V_DDAT) in SE16.
2.assign the corresponding auth group in S_TABU_DIS
Do I have to Assign this in Three user's Role or rest all users who should be restircted to this table?
Please advice
Dnak ki
Rex
Answer:
add the auth group ONLY to those who must have access and be sure to not have this group in other roles. By assigning ranges without this Auth group. Probably (while it is a customer table) you will not find it in TDDAT and have to create your own group or assign it to an existing group.
Answer:
You can assigne an authorization group to the table using SUCU or SE54.
Do note that the limiting of the access to a tabl eusing S_TABU_DIS is only effective if you do nto liberally assign S_DEVELOP in display mode tot he user base.
You do not need SE16, SE17, or SE11 to view table contents, it just makes it easier ( how to was posted some long time back,,, shold be able to find it using the search).
You can extend the limit of access to the tables by assigning an auth group to the report uesd to display the contents using report RSCSAUTH and not giving out the S_PROGRAM containing the auth group you assign to the report. This will ensure the contents are secure.
_________________
John A. Jarboe
Answer:
I would like to add to John's comment:
We have seen as well the effect that someone could access tables indirectly, bypassing auth. object S_TABU_DIS.
This access is then controlled by object: S_DEVELOP via program: RK_SE16N
These are the steps how to get indirect access:
1. User presses F1 on any field he has access to
2. User presses technical information and double clicks on any dictionary object which takes him to the data dictionary
3. User chooses object "Program", enters RK_SE16N and presses the test button
4. User can query any table without restrictions
So, you have to make sure that you give not full access in auth. object S_DEVELOP (also true for S_PROGRAM?!) in Display mode.
Are there any other SAP loop holes giving indirect access to tables? Does anybody know?
thanks
Gerold
Answer:
I would like to add is there any reason to give (wide) access to S_DEVELOP in production??
Answer:
I would like to add is there any reason to give (wide) access to S_DEVELOP in production??
That is a good question.... Unfortunatly, we also use some TEC Tcodes in production in display mode. e.g. SPRO,...
.. and also SU24 brings in S_DEVELOP; of course this should be verified.
Sometimes SAP gives you a hard time.
Answer:
Ok, you sometimes can not avoid having to give powerfull authorisations, but suggestion: Try to inactivate it and test if the TRX still works. It sometimes does grant sufficient access for normal day to day tasks.
One more very important issue with SE16: if the same user also has DEBUG they can get into the program code and from there CHANGE any data in the tables they can access so one should never give DEBUG on PRD to any user, only in a controlled temporary manner.
Answer:
One more very important issue with SE16: if the same user also has DEBUG they can get into the program code and from there CHANGE any data in the tables they can access so one should never give DEBUG on PRD to any user, only in a controlled temporary manner.
Is this true even if the S_DEVELOP DEBUG is only display?
Answer:
If you place an auth group on the program RK_SE16N using RSCSAUTH and not give that access out then this will stop the access to the table using the report and tcode the report is tied to.
SE16 itself is a report generater and when you enter a table name in SE16 and hit display SAP creates a report the executes the search. Without the auth group on the report SAP creates it can be run from SE38, SA38 and from navigtion via S_DEVELP.
Do normal uses need S_DEVELOP, not really but it does help system analyst to navigate using pull-down SYSTEM->STATUS and double clicking.
IF SU24 brings in S_DEVELOP the tcode may or may not need it. If it does it should be modified in SU24 to eliminate access to Security and basis function module and remove DEBUG, SYSTEM DEBUG and DEBUG with REPLACE.
_________________
John A. Jarboe