Map roles through organisational management
Do not assign SAP_NEW
The change management process in the SAP® environment can be quite complex. Since program changes are usually transported into the production system, which can potentially have an impact on the annual financial statements, the audit of the process is an essential part of the annual financial statement audit. For this reason, it must be ensured that the process documentation is up-to-date and complete. It must also be ensured that appropriate classifications are defined for various types of change. This is because the process may subsequently differ for each classification. For example, the extent of the test and release steps varies depending on the criticality of the change, and they may even be shortened considerably for low-risk changes. However, it is crucial to justify this in a comprehensible manner. In the change management process, a sufficient test and release phase should be set up by the responsible department. This process step must also be documented in a comprehensible manner, even if it is not always easy to obtain the necessary evidence from the departments. In this process in particular, it is crucial that a clear dual control principle is established, which ensures that the developer is not also the person who ultimately carries out the transport into the productive environment. In preparation, the documentation should therefore be checked for completeness and up-to-dateness and, in a further step, whether the process defined in it has also been followed throughout the year.
After you have determined the data for the website, you must now generate the initial password and send it by e-mail and unlock the user if necessary. There are also different solutions - we describe a possible course of action. You can generate a password using the GENERATE_PWD import parameter of the BAPI BAPI_USER_CHANGE. The generated password is then set as the initial password and must be changed at the next login by the user. You must also set the PASSWORDX import parameter to display a password change. The generated password is returned using the export parameter GENERATED_PASSWORD. This is required if you want to call the BAPI BAPI_USER_CHANGE from a central system (e.g. from the ZBV) and send the relevant e-mail from that system. You should never save this password, but include it directly in your application in an email. Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD). Even if you find the email address in the AD, we advise you not to send the email from there. To avoid the password being unnecessarily transferred, it is better to initiate the despatch within your central SAPS system. In addition, we strongly advise you to send the emails encrypted with the initial passwords. To do this, the implementation of your self-service must set the encryption flag when creating the email. We describe details about the encryption of emails and an alternative sending of the initial password directly from the affected SAP system in Tip 98, "Encrypt emails".
Concept for in-house developments
Due to the complexity of an SAP® authorization concept, it is necessary that all essential aspects are set down in a written documented authorization concept. This should describe the essential processes, but also how to handle the assignment of authorizations via roles. In particular, the nomenclature of specially created roles must be clearly defined. It should therefore be checked whether all changes since the last audit have been documented in the written authorization concept. After all, this document serves the auditor as a template for the so-called target/actual comparison. This means that the auditor compares the document with the actual status in the SAP® system for the main topics relevant to the audit. Any discrepancy can lead to a finding that must be avoided.
For performance reasons, the SAP kernel checks whether a user is authorised in the permission buffer. However, only profiles and no roles are loaded into the permission buffer. Calling the SU56 transaction will cause you to parse the permission buffer, first displaying your own user's permission buffer. A pop-up window to change the user or authorization object will appear from the Other User/Permissions Object (F5) menu path. Here you can select the user you want to analyse in the corresponding field. The Permissions > Reset User Buffer path allows you to reload the permission buffer for the displayed user.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Over the button field maintenance also own-developed authorization fields can be created to either a certain data element is assigned or also search assistance or check tables are deposited.
Before doing so, all index entries must be deleted; This can lead to a long run of the report.