Make mass changes in the table log
Risk: historically grown authorizations
In the SU53 you get the entry of the user that is stored there, and this may be old. So it is better to let the user himself display the authorization error via the menu. Maybe you create a small docu for all your users how to display the error and where to send it, so a "Cooking Recipe: How To...". In the SU53 error excerpt, the first thing that is displayed is the authorization that the user is missing. So this object has to be analyzed. In the further part of the error message, the permissions assigned to the user are displayed. This information can be used to classify the user with his role set, where he belongs etc. Finally, in our case 1, we now have the missing authorization and must now clarify whether the user should receive this authorization or not. In addition the specialist department must be contacted, which has to decide whether the user receives the permission! It can happen that the problem reported by the user is not an authorization problem at all. Then the last authorization error is displayed in the SU53 area, which is not the cause of the error at all. Therefore, it is always good to have a screen image of the actual error message sent to you as well. It is not uncommon for developers to issue an authorization error of the type "No authorization for..." from their programs, but they have not checked this with a standard authorization check at all, so that the error is not an actual authorization error.
The Security Audit Log (SAL) has ten different filters in the current releases, which control which events are logged. You can configure these filters via the SM19 transaction. The events are categorised as uncritical, serious or critical.
Limit character set for user ID
In a local table, find an entry for the user ID that you are creating in the SU01 transaction. For example, such a local table might be an Active Directory replication or a mini personnel master set, or you may have another data source that you replicate to your SAP system. Then, fill in the fields of transaction SU01 with the data from the local table.
Do the permissions for a self-developed UI component for the SAP CRM Web Client always have to be maintained manually? Not necessarily - if you define them as suggested values for external services. If you have developed your own UI components in the Customer Name Room in SAP CRM and you want to authorise them via the default process, i.e. create a role menu for a PFCG role using the CRMD_UI_ROLE_PREPARE report, you must do some preliminary work. When you run the report, you will notice that the external services for your own developments are not present and therefore do not appear in the role menu. The only way to qualify your UI components is to manually maintain the UIU_COMP authorization object. However, you can maintain your own UI components as external services with suggestion values in the SU24 transaction and take advantage of this information in PFCG role maintenance.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
In addition to defining permissions for external RFC access through the S_RFC authorization object, it is possible to prevent external calls to function blocks.
This report provides information about which user or single role has the S_TABU_DIS or S_TABU_NAM authorization objects.