Make sense in maintaining proposal values
Reference User
Here, too, it is possible to create security and an overview with the help of tools for HR authorizations. The tool creates a clear overview of which data certain users are allowed to access in the SAP system. Based on this, it is possible to develop automatic checks that run in the background and regularly monitor whether changes to authorizations have created critical gaps in HR.
The password lock is not suitable to prevent the login to the system, because it does not prevent the login via single sign-on. Learn how to safely lock the system logon. The SAP system distinguishes several reasons for blocking. Therefore, sometimes there is confusion when a user is still able to log on to the system, e.g. via Single Sign-on (SSO), despite the password lock. We explain the differences between locking passwords, locking and validity of user accounts, and validity of assigned permissions in the following.
Making the RESPAREA responsibility the organisational level
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.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
System users are also intended for anonymous access. They are used in technical operations that require a user, such as batch runs or RFC connections. With them, therefore, no dialogue login is possible on the SAP system, but only the login via RFC call. Multiple logins are always possible for a system user, and the password modification rules (see also the explanation under "Service Users") do not apply. The password of a system user always has the status Productive and can only be changed by the user administrator.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
The first line defines that access to all files is forbidden unless other settings have been made for them in the other lines.
For example, you can assign transactions and Web Dynpro applications to the individual and collection roles in a defined menu structure in the Role menu.