Object S_BTCH_ADM (batch administration authorization)
Permissions with status
A universally applicable template for a reliable and functioning authorization concept does not exist due to the individuality and the different processes within each company. Therefore, the structures of the company and the relevant processes must be analyzed in detail during the creation process. Some core elements of the authorization concept to be created can be defined in advance. These include the overarching goal, the legal framework, a naming convention, clarification of responsibilities and process flows for both user and authorization management, and the addition of special authorizations. Only with clearly defined responsibilities can the effectiveness of a concept be guaranteed.
The same applies to the concept of data ownership. Here, a person takes responsibility for the data of a certain scope (e.g., SAP system X or system landscape Y) and looks after it as if it were his own precious possession. He or she conscientiously answers questions such as "May data be changed / viewed / deleted?", "How is action taken in the event of a data leak?", "Who may access the data and how, and what may be done with it?".
In-house role maintenance
Note that the SAP_NEW_ individual profiles should be retained themselves, so that at any given time, traceability is ensured as to which release and which permission was added. For more information, see SAP Notes 20534, 28175, and 28186. SAP Note 1711620 provides the functionality of an SAP_NEW role that replaces the SAP_NEW profile. If you have added this note, the profile will no longer be used. Instead, you can generate your PFCG role SAP_NEW by using the REGENERATE_SAP_NEW report. When you call the report, in the source and target release selections, type in the appropriate fields, and the role is created for that release difference.
How to maintain security policies and map them to your users is described in Tip 5, "Defining User Security Policy." You need a separate security policy for administrators to implement this tip, which is often useful for other reasons. In this security policy, you then set the policy attribute SERVER_LOGON_PRIVILEGE to 1. For example, you can also include the DISABLE_PASSWORD_LOGON policy attribute setting, because administrators often want to be able to log in with a password on the system.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
I prefer to have the user run the transaction until the error message "No authorization...", then use the menu to display the error, and send me a screen shot of the first page of output.
Not uncommon are subsequent requirements from the area of compliance (SOX or similar) or the increased need for protection.