System Users
Identify Executable Transaction Codes
You want to secure access to the application server files? Find out what the S_DATASET and S_PATH authorization objects offer, what limitations are, and what pitfalls are lurking. Access to the application server's files is protected by kernel-built permission checks, similar to how transactions and RFC function blocks are started. SAP's proposed permissions for the S_DATASET authorization object do not provide much help, and S_PATH has virtually no information, because you must activate this authorization object only by customising the SPTH table. Often the permissions to S_DATASET are too generous, the SPTH table is not well maintained and S_PATH is not used at all. Here we show you how these permissions work and how you can restrict them.
The system checks direct access to the contents of tables, for example, with transactions SE16, SM30, or SE16N with authorization checks on a table authorization group, object S_TABU_DIS. If there are no suitable authorizations for the table authorization group, the system checks the name of the table or view, object S_TABU_NAM. When making changes to client-independent tables, the system also checks the authorizations for object S_TABU_CLI. If you have configured line-based authorization checks in Customizing, the system also checks authorization object S_TABU_LIN. Assign tables or views to a table authorization group using transaction SE11 or SE54. You can also define table authorization groups using transaction SE54. If your customer development implements direct access to a table, use the VIEW_AUTHORITY_CHECK function module to perform the authorization check. For more information about generic access to tables, see SAP Note 1434284 Information Published on SAP Site and the online documentation for the authorization objects mentioned above.
Evaluate Permission Traces across Application Servers
The assignment of the SAP_ALL profile is not required for the operation of an SAP system; therefore, a yellow icon will appear for the first check once a user has assigned the profile. For the other six checks on critical base permissions, the yellow icon will be displayed when a client is found on the system and at least one of the following two conditions applies: More than 75 users have the permission checked in this check. More than 10% of all users have the permission checked in this check, but at least 11 users.
We therefore recommend that you schedule a background job on the PFUD transaction, which performs a regular user comparison (see Trick 17, "Schedule PFUD transaction on a regular basis"). By the way, did you know that the auth/tcodes_not_checked profile parameter enables you to disable the transaction startup permissions for the SU53 and SU56 transactions? To do this, enter the value SU53, SU56, or SU53 SU56 for the profile parameter. This means that the end user no longer needs the permissions to run these transaction codes from the S_TCODE authorization object.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
To do this, select the Create Project button ( ) or the (F5) button.
The separation of technical and organizational requirements greatly simplifies role development and modification.