Reset passwords using self service
Law-critical authorizations
In compliance with the minimum principle and the separation of functions, the roles used must be defined, along with specifications for their naming, structure and use. Close attention should also be paid to the application and allocation process in order to prevent authorization conflicts, which arise primarily as a result of employees' changing or expanding areas of responsibility.
No more users can be created, maintained or deleted without the assignment of a valid user group. If a user group is not assigned when a user is created, the user is automatically assigned the default user group. Before you set the USER_GRP_REQUIRED switch, a user group must have been assigned to each existing user and the administrators must have the permissions for the default user group. When creating a new user, the default user group will be used as pre-occupancy; this user group can be overridden by setting another user group in the S_USER_GRP_DEFAULT user parameter for each user administrator. The customising switch requires a valid user group, because it is used as the default user group. If a valid user group has not been entered in the customising switch, the user group is nevertheless a mandatory field. This will lead to errors in automated user creation.
Maintenance Status
When you select the row with the parameter transaction you created and click on the Suggest values button, the S_TABU_NAM authorization object is automatically created with the correct suggestion values, i.e. the table name in the transaction SU24. Check these suggestion values by clicking Yes in the S_TABU_NAM column. You will now end up in a view from the transaction SU24 and can check in the tables authorization objects and Permission Proposition Values (for all authorization objects) which changes to the object S_TABU_NAM have been made automatically. For more information and implementation guidance, use SAP Note 1500054. The SAP Note also provides the SUSR_TABLES_WITH_AUTH analysis report, which specifies table permissions for users or individual roles. This report checks at user or single-role level which tables have permissions based on the S_TABU_DIS or S_TABU_NAM authorization objects. The report does not check whether the user has the transaction startup permissions that are also necessary, such as S_TCODE. For example, if you check what table permissions a particular user has based on the S_TABU_DIS authorization object, you will receive information about the table names, the associated table permission group, and the eligible activities. Granting permissions to access tables directly is flexible and useful, and is not recommended unless the mechanism is hammered out by giving the user general table access through generic maintenance tools.
This advanced functionality of the transaction SU53 is delivered via a patch. Please refer to SAP Note 1671117 for more information on the required support packages and technical background. Unsuccessful permission checks are now written to a ring buffer of the application server's Shared Memories. This will allow you to view failed permission checks in Web Dynpro applications or other user interfaces, which was not previously possible. Depending on the size of the ring buffer and system usage, up to 100 failed permissions checks per user can be displayed for the last three hours. The size of the ring buffer is calculated from the number of defined work processes. By default, 100 permission checks can be saved per workprocess. You can adjust this size using the auth/su53_buffer_entries profile parameter.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
These two values summarise the access types of the S_DATASET authorization object.
In addition, authorization concepts ensure that employees do not create beautiful balances and thus cause damage to stakeholders and tax authorities.