Features of the SAP authorization concept
Manual authorizations
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 can also monitor security alerts from the Security Audit Log via the Alert Monitoring of your Computing Centre Management System (CCMS). The security warnings generated correspond to the audit classes of the events defined in the Security Audit Log. Many companies also have the requirement to present the events of the Security Audit Log in other applications. This requires evaluation by external programmes, which can be done via the XML Metadata Interchange (XMI) BAPIs. You must follow the XMI interface documentation to configure it. You can also use the RSAU_READ_AUDITLOG_ EXTERNAL sample programme as a template. A description of this programme can be found in SAP Note 539404.
Trace after missing permissions
Authorization object: Authorization objects are groups of authorization fields that control a specific activity. Authorization objects should always be defined in advance with the user group and then relate to a specific action within the system.
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.
However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".
A distinction should be made between SAP's delivery of the SAP_NEW profile and the generation of an SAP_NEW role with a corresponding profile by you as a SAP customer (see also the SAP hint 1711620).
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
Locking and validity of the user account is done through the user administrator and is also valid for other authentication procedures.