SAP Authorizations Making the RESPAREA responsibility the organisational level - SAP Corner

Direkt zum Seiteninhalt
Making the RESPAREA responsibility the organisational level
Existing permissions
If you manage your SAP system landscape via the Central User Administration (ZBV), you must insert SAP Note 1663177 into both the ZBV system and all attached subsidiary systems. In this case, also note that the default user group will be assigned in the daughter systems if no user group has been distributed during the user's installation from the ZBV. In addition, you will receive an error message in the SCUL transaction stating that a user group must be assigned to the user (via the ZBV headquarters). This behaviour is independent of the settings of the distribution parameters for the user group in the SCUM transaction. If you have set the distribution parameters for the user group to Global or Redistribution, the appropriate subsidiary system will reject the changes made to users that do not have a user group in the Central System, and you will receive an error message in the SCUL transaction.

To do this, in the SU24 transaction, open the application you want to customise. To maintain the missing suggestion values, you can start the trace here by clicking on the button Trace. You can of course also use the system trace for permissions via the ST01 or STAUTHRACE transactions. A new window will open. Click here on the Evaluate Trace button and select System Trace (ST01) > Local. In the window that opens you now have the opportunity to restrict the trace to a specific user or to start it directly. To do this, enter a user who will call the application you want to record, and then click Turn on Trace. Now, in a separate mode, you can call and run the application you want to customise. Once you have completed the activities that you need permission checks, i.e. you have finished the trace, you will return to your application in the transaction SU24 and stop the trace by switching off the button trace. To perform the evaluation, click the Evaluate button. To obtain the trace data for each authorization object, select the authorization object you want to customise in the upper-left pane of the Permissions object drop-down list.
Coordinate authorisation management in customer-owned programmes
Here we present different scenarios for the process of resetting passwords. In all scenarios, the user selects the system and the client in which a password is to be reset from a web page. Only systems and clients where this user already exists and assigned a permission should be displayed. An initial password is then generated and sent to the user's email address. Only if a user lock is set by false logins, the user must be unlocked. If an administrator lock is in place, the user should be informed accordingly. Before implementing self-service, consider the password rules set in your systems and the use of security policies. Because these settings allow you to control how passwords are generated in your systems. We recommend that you read the instructions in Tips 4, "Set Password Parameters and Valid Signs for Passwords", and 5, "Define User Security Policy".

As part of the use of a HANA database, you should protect both the execution of HANA database functions as well as the reading or altering access to the data stored in the database by appropriate permission techniques. Essential to the permission technique are database objects such as tables and views - which allow access to the stored data - as well as executable procedures and users. The specific HANA-specific permissions assigned to a user are referred to as privileges in the HANA context.

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.

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.

If you want to know more about SAP authorizations, visit the website

An auditor can usually view the contents of defined tables; However, in order not to give the auditor permission to use the generic table tools, such as the SE16, SM30 transactions, etc.
SAP Corner
Zurück zum Seiteninhalt