Consolidate user-level role mapping
A complicated role construct
The Security Audit Log can also log customer-specific events in restricted way starting with SAP NetWeaver 7.31. The event definitions DUX, DUY and DUZ are reserved for customers and delivered with a dummy expression. For these events, you can then define individually configurable messages using the RSAU_WRITE_CUSTOMER_EVTS function block. To do this, you must first identify the additional necessary events and define their message texts and variables. Note that you may not change the meaning of the message and the arrangement of the variables later, as this would prevent older log files from being readable. Finally, you must include the new message definitions in your filters (transaction SM19). You will find the corrections and an overview of the required support packages in SAP Note 1941526. Since the use of this functionality requires extensive knowledge about the Security Audit Log, it is important that you also consider the recommendations in SAP Note 1941568 and that you can be supported by a basic consultant.
Make sure that the client-independent tables for logging are always logged when the parameters are not set to OFF. In addition to the parameters listed here, the table itself must also have the table logging hook set; This is usually done with the help of the transaction SE13. The settings are made in development and then transported to the other systems. The SAP standard already provides some tables for logging; For an overview of these tables, see SAP Note 112388 (tables requiring logging). You can evaluate the logging settings of the tables using the RDDPRCHK report or the RDDPRCHK_AUDIT transaction in the SAP system. The selection is made in the start image of the report, e.g. via the table name or the selection of options for logging.
Make mass changes in the table log
Now, if a user attempts to execute a report (for example, by using the KE30 transaction), the user's permissions for that authorization object are checked. Therefore, you must adjust your permission roles accordingly. If the user does not have permission to access the object, his request is rejected. If it has a corresponding permission, the display will be restricted to the permitted area. Access is still allowed for all characteristics or value fields that are not defined as fields of the authorization object.
You have read that it is possible to perform mass activities, such as mass roll-offs, using standard means. This is all too complicated for you, and you are still looking for simple solutions for role maintenance? I'm sure you'll have a look at tools from SAP partners that promise to help. In this context, we would like to give you some more information in this tip. There is a very practical occasion: We have too often found a "broken" authorisation system with SAP customers, caused by the incorrect application of additional programmes. Sometimes, the role content was misaligned and the suggestion values were not neatly maintained, so at some point the permission administrators couldn't figure out what to do. Therefore, you should check very well whether the tool you are considering is actually suitable for your purposes.
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".
The last two columns indicate whether the S_TABU_DIS or S_TABU_NAM authorization objects have suggestion values maintained in the SU24 transaction.
For an overview of the usage data already stored in the system, see the SWNC_COLLECTOR_GET_DIRECTORY function block (GET_DIR_FROM_CLUSTER = X input parameter).