Authorization concept - user administration process
Conclusion and outlook
Structural authorizations have a so-called root object, i.e. a starting point and an associated evaluation path. The organization chart of the company is stored in SAP HCM. This makes it possible to see how which positions are linked to each other. If a specific piece of information about an employee is required, it can be read out via a path. At the end there is a list of objects.
HR authorizations are a very critical issue in many companies. On the one hand, HR administrators should be able to perform their tasks - on the other hand, the protection of employees' personal data must be ensured. Any error in the authorization system falls within the remit of a company's data protection officer.
Full verification of user group permissions when creating the user
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
Especially with large system landscapes and systems that are only sporadically used, users often forget their password.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
When scheduling a job, another user can be stored as the executing user.