Deletion of change documents
Perform Risk Analysis with the Critical Permissions Report
In particular, you can derive valuable information about customer transactions, since experience has shown that not all transactions are used. In this context, it is important to mention that you should only use the usage data logged and extracted from the SAP system for the optimisation of SAP role concepts. This information may only be used with the involvement of a co-determination body of your organisation, since this information can of course also be derived from individual users for performance control purposes. However, experience has shown that the use of these data with an early involvement of the institutions of codetermination and the definition of earmarks is uncritical.
Don't simplify your entitlement concept before you know all the requirements, but first ask yourself what you need to achieve. So first analyse the processes (if possible also technically) and then create a concept. Many of the authorisation concepts we found in customers were not suitable to meet the requirements. Some of these were "grown" permission concepts (i.e., requests were repeatedly added) or purchased permission concepts. Many of these concepts had in common that they had been oversimplified, not simply. A nice example is permission concepts that summarise all organisational levels in value roles or organisational roles. There are few examples, such as the role manager of the industry solution SAP for Defence and Security, in which the result of a value role concept is still useful and appropriate for the user. The assumption that you "sometimes" separate all the authorization objects that contain an organisational level is simple, but not useful. We have not found the simplification that only a user without permissions can definitely not have illegal permissions. However, there was always the case that users had far too many permissions and the system was therefore not compliant.
SAP S/4HANA® migration audit
TMSADM: The user TMSADM serves the communication between SAP systems in the transport management system and is automatically created in the client 000 when they are configured. TMSADM only has the permissions to access the common transport directory, view in the change and transport management system, and the necessary RFC permissions. Safeguard measures: Change the user's passwords in each client. There is the report TMS_UPDATE_PWD_OF_TMSADM, which you have to start in the client 000. This is only possible if you have administrator privileges on all systems in the landscape and the password rules of the systems are compatible. After the report has been successfully passed, all TMSADM users of the landscape in the client 000 and their destinations have the same new password.
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.
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 short description of the customising switch refers to the relevant and current SAP references.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
In the SAP standard, the name of a generated profile is composed as follows, for example, if the System ID is ADG: T-AG#####.