Xiting SAP Security Blog

SU24 Tips & Tricks – Fields which cannot be maintained


The first two blogs dealt with fields which you should and respectively should not maintain as SU24 proposals for roles. The example of SAP standard organizational level fields is already dealt with in blog 2 to introduce fields which you should not maintain in SU24, but that is because you should maintain them in the roles. There are however fields of objects which cannot be maintained in SU24 due to technical restraints or configuration options.

Fields which you cannot maintain in SU24

Example 1: Fields promoted to USORG Organizational levels

If you read the documentation on report PFCG_ORGFIELD_CREATE, then you should also heed the warnings about using it. If you promote a field to an organizational level, then it has consequences for proposals in SU24. The values which already are there will be replaced by the USORG variable. As a result, you will only be able to maintain the field in the roles afterward via PFCG.

This has the disadvantage that all the field values for all the objects which use that field will be the same values within individual roles. So ideally you should only do this to fields which are used by one object only, in which case one can also question the reason for wanting to promote it to an organizational level in the first place.

You must be aware that the existing values in Su24 will be deleted. That makes “going back” quite difficult unless you update all open fields in all roles again. If you have a lot of roles with a lot of maintained values, then it is nearly impossible.

SU24 Fields which cannot be maintained
Performance Assistant

Example 2: Fields of objects which you can globally deactivate in SU25

Via transaction SU25 (Installation and Upgrade tool) you can use step 5 “Deactivate Authorization Object Globally”. This step allows you to switch authority-checks against authorization objects off – completely.

This has its use to simplify your authorization concept for objects which the code checks but you do not ever want to control. This additionally makes the roles smaller and “idiot proof” as the object cannot ever be a source of authorization errors.

Technically what happens is that this global setting for an authorization object will cause all checks against it to be successful – regardless whether the user has authorization or not. Additionally, the object will be deleted from all SU24 proposals for all transactions and will not be included in any roles. You will neither in SU24 nor PFCG be able to maintain it.

Note that “globally” is however still client dependent as a setting. Global means, that it is relevant for all transactions that the check is irrelevant and not for all clients of the system.

Note that some auditors are principally against this option and might recommend that you set RZ10 system parameter auth/object_disabling_active to “No” which disables the mechanism. However, it can also be very useful and by default no object is inactive. You cannot deactivate “BC” or “HR” objects though as these are classed as always necessary and cannot be simplified via SU25.


SU24 Fields which cannot be maintained
Globally deactivated objects in SU25

Example 3: Fields of objects which you can locally deactivate in SU24

In addition to the global deactivation in SU25, you can also locally deactivate an authorization object in SU24. In this case, the same effect happens as with global deactivation, except that it only affects the transaction context for which you have deactivated it.

This is also already widely used in your SAP system for standard transactions. The reason is, that reuse of coding to perform functions is widely in use. In selected cases, the check in those functions is too strict.

For example, posting from a sub-ledger such as goods receipt to the general ledger should not force the user in the warehouse to be able to post directly to the general ledger. Also, in many cases, the authorization concept already is simplified in this way. When specific to a transaction, there is no control requirement for an authorization object which can potentially be checked.


SU24 Fields which cannot be maintained
Locally deactivated objects in SU24

Note that some auditors are principally against this option and might recommend that you set RZ10 system parameter auth/no_check_in_some_cases to “No” which disables the mechanism, doing this will create chaos because:

  • All SAP “no check” indicators will become active but not be in the roles
  • SU24 is client independent
  • SU25 is client dependent
  • RZ11 parameters are not transportable
  • Transaction PFCG will switch to display-only mode
  • Now read this from bottom to top again and consider the consequences…

You cannot deactivate “BC” or “HR” objects though as these are classed as always necessary and cannot be simplified via SU25. We highly recommend not to change the defaults. You can, however, adjust check indicators in SU24 for your purposes and implementation of the control concept you need.

SU24 Fields which cannot be maintained
Additional authorization checks in SE93

Example 4: Field values which do not fulfill the SE93 additional authorization check

When you start a transaction code, the SAP kernel will automatically check authorization for object S_TCODE of that transaction code. However, transaction code start and the execution of the code of that transaction also offers an additional “plausibility” authority-check. You can maintain this check in transaction SE93 for that transaction.

If you try to save a change in SU24 for an authorization proposal which conflicts with that in SE93 (the backend table of these additional checks is TSTCA), then you will get a message that the “Data was automatically corrected.”

You cannot maintain values in SU24 which conflict with these “additional start authorizations” required. As an example, there is no way to enter FB01 in display only mode if you cannot at least create journal entries for some company code. The program will not even start, and SU24 will be automatically corrected back to the minimum which it needs.


Using the tips from these first three blogs you will typically still be at 99% field completion of your roles. However, you now have a better understanding of how to make the initial investment in maintaining SU24 correctly. This results in reducing the maintenance you have to do in the long-run. More tips & tricks on how to do it will follow soon in the next blogs.

Previously in this series:

Julius Bussche

Julius Bussche

Julius has worked with IT applications since he was young, specializing in SAP software back in 1997. His extensive knowledge and pragmatic approach mean that he is highly respected in the SAP Security community, and are also evident in the applications offered by Xiting in its products. His role as development leader means that he is best placed to offer customers the best possible SAP Security solution. His knowledge of SAP projects and direct contact with customers ensure that our applications are constantly moving towards the next innovation.
Julius Bussche