Set up login locks securely
Controlling file access permissions
Your system has inactive users? This is not only a security risk, as they often use an initial password, but also creates unnecessary licence costs. There will always be inactive users in your SAP system. There may be several reasons for this. For example, they may be management level users that are virtually unused because they are not using the ERP system. It could also be that employees no longer use their SAP user due to a change of position or that outsiders do not work on the SAP system for a while. In any case, you should ensure that these inactive users are either blocked or invalidated. Up to now, you had to select all inactive users with the help of the RSUSR200 report and then manually transfer them into the SU10 transaction to perform the blocking. You can now do this automatically.
Repair defective field list in SU24 suggestion values: This function verifies that all the authorization objects used in the permission proposals are consistent, that is, fit to the authorization object definitions from transaction SU21. If there are no permission fields or if there are too many entries, these data will be corrected in the proposal values.
SAP license optimization
Once you have archived the change documents from the User and Permission Management, you can use a logical index for change document properties to significantly improve performance. First, however, you must ensure that SAP Notes 1648187 and 1704771 are installed in your systems. These notes provide the SUIM_CTRL_CHG_IDX report, which adds key characteristics for change document characteristics of the PFCG and IDENTITY object classes to the SUIM_CHG_IDX table when you have marked the Indices key change documents field. All change documents are indexed (this can lead to a very long run time when the report is first run). Later, the newly added change documents are indexed regularly (e.g. weekly or monthly). To do this, specify the target date in the selection of the report and schedule it as a regular job. Note that you can only create the index until the previous day - otherwise inconsistencies may occur.
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.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Generated authorization profile - Generated in the role administration from the role data.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
You should also always assign custom tables to a table permission group, otherwise they will also be assigned the table permission group &NC&.