Centrally review failed authorisation checks in transaction SU53
Permissions checks
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.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
Configuration validation uses the CCDB's configuration data to reconcile settings. To do this, you define your customer-specific security settings technically in a target system. This contains the specifications for the configuration of SAP systems. You can also define a target system based on the settings of an existing system and adapt it to your requirements. Then you compare the settings of your SAP systems with this target system on a daily basis and get an overview of the deviations. Since there may of course be different security requirements for the systems in your landscape (e.g. development and production systems), you can define different target systems with the appropriate settings. You then start the comparison with a target system for the relevant systems. Alternatively, you can compare to an actual system; For example, this is a useful function in the context of a roll-out.
Permission implementation
This approach makes authorization management considerably more efficient, since functional changes do not have a global impact on the entire authorization structure. This ensures the quality of authorizations in the long term. Authorizations in SAP systems enable users to access the applications relevant to their activities. To ensure that processes are mapped securely and correctly, SAP authorizations must be regularly checked and reworked.
Upgrades also require that the eligibility roles be revised. In this context, you can use the SAP_NEW profile for support. During an upgrade, changes and enhancements to permissions checks are included in SAP NetWeaver AS ABAP. In order for users to continue to perform their previous actions in the SAP system as usual, you as the permission administrator must revise or add to the authorisation expressions within the framework of the established permission concept. Basically, you use the transaction SU25 for this purpose. For the transition period, you can use the SAP_NEW permission until the permission concept is up to date on the new release. Since the handling of SAP_NEW is not always transparent and the question arises, for example, when the profile should be assigned and when not, we explain the background here.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
The authorizations required for table access via database tools depend on the respective system configuration and should be verified via an authorization trace (transaction STAUTHTRACE), if necessary.
If the email is marked as confidential, it can only be viewed by the sender or the creator of the email.