SAP authorizations: Recommendations for setting up, monitoring and controlling
Encrypt e-mails
For users for which no user type has been defined in the ZBV, either the default user type of the subsidiary system or the user type defined by the local measurement programme (transaction USMM) run is reported in the Contractual User Type column. In this case, no value is reported in the Value column in the control centre. If the user type has been defined via a local run of the surveying programme and this type of user is not stored in the ZBV, you should re-import the licence data for this user from the subsidiary system into the ZBV using the transaction SCUG. If there are users in the daughter systems for which the value in the columns of the Contractual User Type and Value in ZBV Central differ, either the IDoc of the ZBV has not yet been processed, or the user type has been changed locally. In these cases, you should check what the differences are and also correct them.
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.
Customizing
If an authorization system grows too much over the years and there is no structured approach, the result is uncontrolled growth. If companies wait too long with the cleanup, a complete rebuild of the authorization structure or a new concept may make sense. This must be clarified quickly in the event of a cleanup.
Very often the question then arises, does anything have to be prepared for the audit? As a rule, all of the company's own notes from previous years should be retrieved and combed through for information that was noted at the time during the discussions with the IT auditor. The IT auditor's findings and comments that show potential for improvement in IT-relevant processes or system settings are particularly essential. Furthermore, any reports by the auditor from the previous year should also be taken into account, in which deficiencies identified at that time were pointed out.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
For each form of automated derivative of roles, you should first define an organisational matrix that maps the organisational requirements.
Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered.