SU24 Tips & Tricks – Fields you should maintain
When you create a role in the profile generator (PFCG) and add objects via the role menu, the SAP system automatically merges authorization proposals from transaction SU24 into the role. How accurate and complete these proposals are, depends on how well you have maintained them in SU24. Our experience has demonstrated that a well-maintained proposals database results in more robust roles for end-users and less role maintenance effort in the long-run.
When you edit a role in PFCG, you may have seen a button that SAP labeled “Expert Mode.” You can find more information about “Expert Mode” in the SAP Note 113290. However, it is important to understand that SAP calls it “Expert Mode” for a reason: when faced with requirements to change authorizations with a role in mind, the expert methodology of doing this is to determine which transaction require change and maintain SU24 for that transaction accordingly. But the role will not know about this and other roles which can also benefit from the authorization proposal due to having the same transaction in the role will not either.
The question of when and how to maintain SU24 is often complex, and some security administrators even consider it an art form to create elegant authorization concepts with a complete where-used-list that requires minimal role maintenance work via PFCG.
If you carefully maintain SU24, all roles can profit from the proposals. And if you maintain all roles via the menu or the organizational field levels, you can simultaneously decrease your workload and increase role quality by approximately 90%.
Table of Contents
Fields you should always maintain
There are fields of objects which uniquely belong to applications – not only limited to transaction codes but also RFC-enabled function modules, Web Dynpro applications, web servers and all other types of modern application types available in SU24. For the sake of simplicity, we use transactions as examples going forward.
If the transaction is uniquely destined for a specific field value (e.g., transaction FB03 needs only field ACTVT with value ’03’) or if pre-defined parameters are passed to it (e.g., transaction XT30 needs only S_PROGRAM, field P_GROUP, and value ‘TRZ’) then there is no reason not to add the field value to SU24. Leaving a proposal field open in SU24 creates redundant work as you will have to maintain the value later in the role anyway.
Such examples of field values no-brainers because and they belong in SU24 if you use the respective transaction in a role. Not adding such proposals increases the risk of adding more authorizations than needed in the role and thereby over-authorizing the user for important object fields.
Example 1: ACTVT and other activities
One of the most crucial fields is ACTVT. Thousands of applications with SU24 contexts use it, and it is incredibly easy to maintain. But there are additional fields that also control the “activity type” via authorization objects, but they may not be called ACTVT. Some examples include:
- ACO_ACT_S
- ACTION
- AUTHC
- CO_ACTION
- FBTCH
- SPOACTION
- BTCUNAME
Tip: you can find more such field types and also monitor them via the Xiting Role Profiler‘s Activity Watchdogs.
Example 2: P_GROUP and other parameters
There are also essential fields of authorization objects in roles which do not control an activity type directly. By passing these fields as a fixed parameter from the calling applications to the target transaction, and the same field is authorization relevant – such as the program group on an executable program (Object S_PROGRAM). The parameter transaction, which needs nothing more nor nothing less, is the best example of such behavior.
Table TSTCP (parameter transactions definitions) contains more than 20 thousand transactions. The primary object needs these passing parameters as authorization values. Several other tables such as TSTCP and TDDAT and many other application types pass fixed parameters that you should always maintain in SU24. Xiting’s Role Profiler can help to identify the following important objects:
- S_PROGNAM
- S_TABU_DIS
- S_TABU_NAM
- S_TABU_CLI
- S_NUMBER
- S_MASSMAIN
- S_ARCHIVE
- K_KA_RPT
Tip: you can find more such object types and also monitor them via the Xiting Role Profiler‘s SU24 Optimization Reports.
Example 3: Difficult to find fields and Custom Code
There are other important fields of authorization objects in roles that are difficult to find. To assist with finding such fields, you can leverage code scanning programs, execute the program or transaction manually, or rely on experience from previous projects.
The manual approach involves a user account that has only one role including the transaction you want to test. Upon execution of that transaction, you can then leverage logging and trace data to record all authority checks and field values. As you can imagine, that is not a scalable approach.
Xiting offers a much more efficient and automated approach via its Role Profiler and ABAP Alchemist, both part of the Xiting Authorizations Management Suite (XAMS).
Xiting Role Profiler – SU24 Whitelist Optimizer
Based on project experience from the past decade, we have documented all must-have SU24 proposals that most SAP systems are missing and added them to a customizable list in the XAMS. That way, you can quickly and automatically add those known missing proposals to your SU24 based on the transaction context.
Xiting ABAP Alchemist – SU24 Optimizer
For all unknown transactions (particularly Z* custom code) you can use the Xiting ABAP Alchemist to scan your custom ABAP code in a development system, without requiring a trace of the execution to find all authority checks and related SU24 proposals. You can then quickly transfer the most obvious ones to SU24 with a mouse-click.
Xiting Times – Simulation mode
For some check values, it is quite easy to build a role that is over 90% complete via the menu, and based on a sufficiently optimized SU24. But some values might need an execution of the transaction to reach the check and reveal its values. To assist with that, Xiting has introduced a feature called Productive Test Simulation (PTS), which offers the capability to simulate the authority-checks of new roles while users work with their old authorization/roles in the production environment. That way you can not only identify missing fields in your new roles, but you also get to understand the transactional context.
Previously in this series:
