Even if key users (department users/application support) do not have to develop their own authorization objects and cooperation with SAP Basis is always advantageous, there are often technical questions such as "Which users have authorization to evaluate a specific cost center or internal order?
Analyze user buffer SU56
Roles are assigned according to the function of employees in the company and their validity is limited depending on the task. Removing role assignments manually in user master kits is very tedious. We'll show you how it's easier. Over time, users of your SAP system have accumulated many roles in the user master set. These roles have different validity periods. Some roles have already expired, and other roles may be assigned multiple times, because a user might perform multiple roles in the organisation, some of which have the same roles. Now you are looking for an easy way to delete role assignments that have expired or to remove multiple role assignments.
With the introduction of security policy, it is now possible to define your own security policy for System or Service users. This way you can ensure that backward-compatible passwords are still used for these users. This eliminates the reason that password rules were not valid for System/Service type users; Therefore, the rules for the content of passwords now apply to users of these types. Password change rules are still not valid for System or Service type users. If you are using security policy in your system, you can use the RSUSR_SECPOL_USAGE report to get an overview of how security policy is assigned to users. This report can be found in the User Information System (transaction SUIM). In addition, the user information system reports have added selected security policies to the user selection. This change was provided through a support package; For details, see SAP Note 1611173.
Authorization concept - recertification process
The SAP_NEW profile is basically designed to bridge the release differences in eligibility checks after an upgrade and ensure that the established business processes remain executable after an upgrade. The SAP_NEW permission should only be assigned temporarily and only in emergencies in a productive SAP system after an upgrade.
The authorization check for the authorization objects PS_RMPSORG and PS_RMPSOEH runs as follows following a user entry: The system determines the organizational unit to which the user is assigned. Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy. The system determines the set (M1) of all organizational objects that are assigned to these organizational units. The system determines the organizational unit to which the object to be processed is assigned (corresponds to the lead organizational unit in the attributes of the object to be processed). Starting from this lead organizational unit, the system creates a list of all organizational units that are superior to the determined organizational unit within the hierarchy. The system determines the set (M2) of all organizational objects assigned to these organizational units. The system forms the intersection (from M1 and M2) of the matching organizational objects of the user and the object to be processed. The system determines the organizational levels that match for the user and the object being processed. Once a matching organizational level is found, the system performs the authorization check for the other fields of the authorization object (e.g., type of object or activity); if the system cannot determine a common organizational level, processing is rejected. If the user is allowed to perform the requested activity, processing is allowed; otherwise, the system rejects processing.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
This behaviour is independent of the settings of the distribution parameters for the user group in the SCUM transaction.
To maintain the suggestion values, you can use both the System Trace data for permissions from the ST01 or STAUTHTRACE transaction and the data from the permission trace in the SU24 transaction (see Tip 39, "Maintain suggestion values using trace evaluations").