Maintain derived roles
Installing and executing ABAP source code via RFC
You can also use the SU53 transaction to centrally view failed permission checks. Open the transaction and go to Permissions > Other Users or F5 to the User Selection menu. Enter the user whose permissions have failed in the field with the same name. In the results list, you can see permissions that have failed for each user, as in our example, the missing permission to display the AGR_1251 table. You can see that more than one authorization object appears in this evaluation.
When you select the row with the parameter transaction you created and click on the Suggest values button, the S_TABU_NAM authorization object is automatically created with the correct suggestion values, i.e. the table name in the transaction SU24. Check these suggestion values by clicking Yes in the S_TABU_NAM column. You will now end up in a view from the transaction SU24 and can check in the tables authorization objects and Permission Proposition Values (for all authorization objects) which changes to the object S_TABU_NAM have been made automatically. For more information and implementation guidance, use SAP Note 1500054. The SAP Note also provides the SUSR_TABLES_WITH_AUTH analysis report, which specifies table permissions for users or individual roles. This report checks at user or single-role level which tables have permissions based on the S_TABU_DIS or S_TABU_NAM authorization objects. The report does not check whether the user has the transaction startup permissions that are also necessary, such as S_TCODE. For example, if you check what table permissions a particular user has based on the S_TABU_DIS authorization object, you will receive information about the table names, the associated table permission group, and the eligible activities. Granting permissions to access tables directly is flexible and useful, and is not recommended unless the mechanism is hammered out by giving the user general table access through generic maintenance tools.
PROGRAM START IN BATCH
Configuration validation gives you an overview of the homogeneity of your system landscape. Typical criteria are operating system versions, kernel patch levels, and the status of specific transport jobs or security settings. The following security settings can be monitored using configuration validation: Gateway settings, profile parameters, security notes, permissions. As part of the comparison, you can define rules that determine whether the configuration is rule-compliant or not. If the configuration meets the defined values in the rule, it will be assigned Conform status. You can then evaluate this status through reporting.
Changes to SAP user data should be uncomplicated and fast. Users can make requests for SAP systems themselves. In exceptional and emergency situations, SAP users should be assigned extended authorizations quickly and for a limited period of time. Simplified assignment and control of exception authorizations in SAP systems is required. You can freely and flexibly determine the duration of these authorization assignments. Decisions can be controlled and monitored across systems. Whether it's recertification of SAP users, vacation requests or birthday wishes: all these things can now be processed and managed centrally in one place.
During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.
A self-service that uses the Business Application Programming Interfaces (BAPIs) can counteract this.
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
Finally, do you want to change the user group for an existing user without having permission for the new user group? In the following section we will show you how to secure your user master data maintenance.