Emergency user concept
Unclear objectives and lack of definition of own security standards
Do you need to integrate the S_TABU_NAM authorization object into your existing permission concept? In this tip, we show you the steps that are necessary to do this - from maintaining the suggestion values to an overview of the eligible tables. You have added the S_TABU_NAM authorization object to your permission concept, so that users can access the tables not only through the S_TABU_DIS authorization object, but also through S_TABU_NAM. This directly regulates access to the tables via table permission groups or, if access is not allowed through table permission groups, via the table permission (see Tip 73, "Use table editing authorization objects"). Do you want to identify the tables or created parameter transactions that allow access to only specific tables to maintain SU24 for these suggested values in the transaction? This makes it easier to maintain PFCG roles. Furthermore, a tool would be useful to give you an overview of the tables for which a user is entitled.
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.
Essential authorizations and parameters in the SAP® environment
In principle, the SAP_NEW permission should not be granted in the production system. The Profiles tab displays the generated profiles in the user master record that are associated with a specific user. Here you can also assign manually created permission profiles from the transaction SU02 - even without direct role mapping. In principle, the recommendation is to use the profile generator (transaction PFCG) to generate authorisation profiles automatically. Special caution is taken when you enter generated permission profiles directly on the Profiles tab, as these assignments will be deleted by matching user assignments with the transaction PFUD if no entry is on the Roles tab for the assignment. You have probably assigned SAP_ALL and SAP_NEW to users for whom there should be no restrictions in the SAP system. But what are these two profiles different from each other and why are they necessary?
It is easier to specify the programme name in the PROGRAM field because the maximum value of 40 characters is the limit for programme names in the SAP NetWeaver application server ABAP. If it is a function block or a Web application, you can obtain the programme name by using the System Trace for Permissions (transaction ST01 or transaction STAUTHTRACE). In the SPTH table, you can define access rights for paths and whether you want to perform an additional permission check on the S_PATH object.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
These vulnerabilities can, in the worst case scenario, open the door to external and internal intruders.
Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD).