Use Custom Permissions
Reset passwords using self service
Alternatively, you can maintain this information from the SE93 transaction by selecting a transaction first. You will then be presented with the list of all transactions that can be called from this transaction by using the Tools > Called Transaction Permission menu path. The implementation of SAP Note 1870622 provides a feature enhancement for the SE97 transaction. Among other things, there is the new button Modification Synchronisation. So far, changes in the SE97 transaction have been overwritten by inserting support packages or upgrades. With the modification comparison it is now possible to match your changes with the default values.
The case that the user buffer is not up to date is very rare. The auth/new_buffering profile parameter sets the value 4 to immediately update the permissions, i.e. changes to the user root or roles or profiles, and write them to the USRBF2 database table without requiring a new login. This value is set by default. The fact that the buffer is not up-to-date is recognised by the fact that existing permissions that are not in the buffer are marked in the transaction SU56 with the note "In the root data but not in the user buffer".
Even more critical is the assignment of the comprehensive SAP® standard profile SAP_ALL, which contains almost all rights in the system. Therefore, it should be assigned to a so-called emergency user at most. The handling of the emergency user should also be specified in the authorization concept, which should be documented in writing. In any case, the activities of the emergency user should be logged and checked regularly. Therefore, it is essential in preparation for the annual audit to check the current, as well as the historical, assignments of SAP_ALL. It is therefore not sufficient to simply quickly remove the SAP_ALL profile from users in the run-up to the annual audit. It must also be proven that the SAP_ALL profile was not briefly assigned for a few days over the audit period. If SAP_ALL assignments did occur, ideally these have already been documented and checked. If this is not the case, it is essential to create documentation that cannot be changed, in which it is proven why the assignment was necessary and that the user has not carried out any critical actions beyond this (filing and review of logging).
The authorization objects are attached by analogy to the forecast and item-based reports. The authorization objects of the item-based reports are checked in addition to the authorization objects for the information system when the report is selected. There is a trick in maintaining the CO-PA-specific authorization objects, because a once selected result area is set for the entire session of your login. This is of course hindering the maintenance of authorization objects for different result areas. Therefore, simply change the result area in the Customising window using the following path: Controlling > Income and market segment accounting > Structures > Set result area.
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.
For example, in an authorization object for a company code, if the user is to be given the option of using company code 1000 in display mode only (i.e. read only), but company code 2000 in "change" and "display" mode, the object is defined accordingly with two instances.
Each of your actions leads to the use of runtime versions of the corresponding objects.