SU2X_CHECK_CONSISTENCY & SU24_AUTO_REPAIR
Customise Permissions After Upgrade
Due to the changed suggestion values in the SU24 transaction, you must now perform step 2c (roles to verify) to update all roles affected by the changed proposal values. Role changes are only customised! You will get a list that shows all the roles you need to edit. If you have more than one client to maintain roles, you must also do this in the other client.
Don't simplify your entitlement concept before you know all the requirements, but first ask yourself what you need to achieve. So first analyse the processes (if possible also technically) and then create a concept. Many of the authorisation concepts we found in customers were not suitable to meet the requirements. Some of these were "grown" permission concepts (i.e., requests were repeatedly added) or purchased permission concepts. Many of these concepts had in common that they had been oversimplified, not simply. A nice example is permission concepts that summarise all organisational levels in value roles or organisational roles. There are few examples, such as the role manager of the industry solution SAP for Defence and Security, in which the result of a value role concept is still useful and appropriate for the user. The assumption that you "sometimes" separate all the authorization objects that contain an organisational level is simple, but not useful. We have not found the simplification that only a user without permissions can definitely not have illegal permissions. However, there was always the case that users had far too many permissions and the system was therefore not compliant.
Customise SAP_ALL Profile Contents
Despite progressive use of web interfaces in the S/4HANA context, batch processing for mass data is still required. However, our experience from customer projects shows that only very few authorization administrators know how to correctly authorize the scenarios. SAP OSS Note 101146 provides a good overview here. In this blog post, we would like to summarize the context for practical use.
We recommend you to transport all these changes. Basically, you should always make changes to organisation levels on your development system and then transport them. If you use multiple clients, you should note that the organisation levels and the proposed permissions are client-independent data, whereas the roles and profiles in question are client-dependent. If you are using more than one client, you must also run the PFCG_ORGFIELD_ROLES report in the other mandates to determine the roles that the new organisation level will contain. With the help of this report, you must then rearrange all the roles listed in the Status column: Orgebene in Role are indicated in red. You can select these roles and then use the Reduce in Roles button to adjust them to the new organisation level.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
In such a case, it is also best to collect the business risks directly in the process description.
We introduce these services and describe how they help you gain an overview of the security of your operational concept.