SAP systems: Control user authorizations with a concept
Use application search in transaction SAIS_SEARCH_APPL
First of all, represent your organisation. Map the business processes (if necessary only at the generic level of applications such as MM or CO) across the organisation. On this basis, determine which organisational characteristics (organisational levels, but also cost centres, organisational units, etc.) represent which parts of the organisation. Define (if necessary, only in detail in accounting, otherwise at the level of applications) which functions must necessarily remain separate. If you have a running system, evaluate the use of the last 13 months (see Tip 26, "Use usage data for role definition"). Set up a new system and make sure that processes are always documented to the level of transactions. In such a case, it is also best to collect the business risks directly in the process description.
In order to provide user authorisation support, you often need their information. However, there is also the possibility to view missing permissions centrally for all users. If a user has a permission issue, a ticket is usually displayed at support. However, it is difficult for a support worker to understand permissions errors because they have different permissions and are often missing detailed information about the application where the permission error occurred. In practice, therefore, support staff often help themselves by asking the user to send a screenshot of the transaction SU53. Because this transaction shows the last failed permission check. In many cases, however, the information displayed there is not helpful to the permission administrator. You may have seen that a screenshot from the SU53 transaction shows a missing permission for typical base authorization objects, such as S_ADMI_FCD, S_CTS_ADMI, or S_TRANSLAT, but you know that your check has nothing to do with the actual permissions problem in the application. So you need the opportunity to see for yourself.
Customizing
It must be clarified in advance what constitutes a recognized "emergency" in the first place and which scenarios do not yet justify activating the highly privileged user. In addition, it may only be approved and activated after a justified request and only under the dual control principle. After use, it must be administratively blocked again immediately.
Then you create a subroutine with the same name as the User-Exit definition and programme your customised checks (for example, for specific data constellations or permissions). Include the exit definition (UGALI) via the GGB0 transaction. You will need to call this transaction again to read the programmed exit and select it.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.
However, because the SPTH check is always performed together with the S_DATASET object check, you can use a long-running permission trace to find the paths that are used with filters for the S_DATASET authorization object.
These are mainly found in the folders of the homepage and under GENERIC_OP_LINKS.