SAP authorizations: Recommendations for setting up, monitoring and controlling
Reset passwords using self service
After the functional specification has been removed, the implementation can begin: To do this, first create your custom authorization object and implement the permission check provided. The next step is to maintain the SU24 transaction proposal values for the respective customer transaction. To do this, call your custom-created transaction and assign the necessary authorization objects either manually by using the Object button, or use the Permissions or System Trace to assign the permissions (see Tip 40, "Using the Permissions Trace to Determine Custom Permissions Proposal Values"). You must leave the authorization objects used in the customer's own coding. For each authorization object, you can maintain field values that appear as suggestion values in the respective roles. Now all the roles concerned must be adapted. If the mixing mode for the transaction PFCG is set to On (see tip 38, "Use transactions SU22 and SU24 correctly"), all PFCG roles assigned to the transaction in the role menu will be recognised and can be remixed via the transaction SUPC. If the customer's transaction is not yet in the PFCG rolls, it will be added here and the respective PFCG role will be remixed.
S_PROJECT authorization object: The S_PROJECT authorization object enables you to work with customising projects. You can modify, view or delete projects, maintain status information, project documentation, and perform project evaluations.
Initial passwords for standard users are extremely risky because they are published. Make sure that this vulnerability does not exist in your system landscape. An SAP system is always shipped with certain standard users or they are automatically set up for the transport management system, for example. These default users use initial passwords that are well known. Close this vulnerability by changing the passwords and protecting the default users from unauthorised use. In this tip we will show you how you can clarify the status of your standard users' passwords and give you recommendations on the settings of your profile parameters.
If you want to export the movement data of the productive system to a development system, you should first export user master records and the permission proposal values and archive the complete change documents. After importing, you can then delete the imported change documents, in analogy to the client copy, and then reload and index the original change documents of the development system. The activities described here require administrative permissions for the change documents (S_SCD0 and S_ARCHIVE) and, if applicable, for the table logs (S_TABU_DIS or S_TABU_NAM and S_ARCHIVE). These permissions should be considered critical, and you should assign them to a small circle.
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.
For the application identifier (defined in the TBE11 table), see the TPCPROGS table.
In the SAP standard, there is no universally applicable way to automate the mass maintenance of role derivations.