Authorizations in SAP systems: what admins should look out for
Archive change document management for user and permission management
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.
One way of gaining direct access to downstream systems from the development system and possibly performing unauthorized activities there is to use incorrectly configured interfaces. In principle, interfaces within a transport landscape should be avoided with regard to the criticality of the systems "uphill", i.e. from an "unsafe" to a "safe" system (e.g. E system to Q or P system). However, this cannot always be implemented; for example, such interfaces are needed within the transportation system. Without going too deeply into the subject, however, critical interfaces can be characterized by the following properties. Critical interfaces refer to a critical system and a critical client, contain an interface user with critical authorizations in the target client, contain its deposited password.
Generic access to tables
The call to your implementation of the BAdIs is the last step in the process of storing user data. This applies to all transactions or function blocks that make changes to user data. Therefore, the BAdI is also called during maintenance by the BAPI BAPI_USER_CHANGE. You use this BAPI when you implement a password reset self-service as described in Tip 52, "Reset Passwords by Self-Service." This enables encrypted e-mail delivery of initial passwords within a self-service framework.
In addition to existing authorization objects, you can also create your own authorization objects and select existing authorization fields such as Activity (ACTVT). To the individual fields then, as with ACTVT, the permissible options which are deposited at the field can be specified. Thus, for an own authorization object with the authorization field ACTVT, the activity 01 Add or Replace, 02 Change and 03 Display can be selected and would then be available as a selection in the authorization field in the role maintenance.
For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.
To disable all checks, set the value COARS = 2.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
This extension of the test is provided by the correction in SAP Note 931251.