SU24 Tips & Tricks – Fields which should not be maintained

by

There are fields of objects which uniquely belong to applications which are dealt with in the 1st blog of the series. The complete opposite exists as well for fields that have no place in SU24 proposals. They are role specific, or SU24 proposals are an overkill of maintenance. Related content: Which fields should be maintained.

Fields which should not be maintained in SU24

Example 1: USORG Organizational fields

The best example of explaining this is defining fields as organizational field levels for PFCG. These fields exist in SAP table USORG, and you cannot maintain them in SU24. The SU24 application does not even offer the option to maintain them. SU24 will also respect custom fields which you promote to organizational levels. Some notable examples are:

  • BUKRS – Company code
  • WERKS – Plant
  • EKORG – Purchasing Organization
Data Browser Table USORG in SE16

Why they do not and cannot belong in SU24 proposals is because you should maintain them in the roles themselves. Objects using these fields will have at least one additional field (mostly ACTVT) which should have a fixed value set proposed. Please see also the first blog of the series. You must make the decision about the values in the roles based on your organizational structure (see transaction EC01) and requirements for grouping of organizational sets (see transaction /XITING/ORG).

Note of caution (while on the topic) if you promote a field to an organizational level status: you must consider that all authorizations of this field within the same role will have the same field values regardless of the object. Many fields are however not appropriate for organizational levels if they do not have a real organizational flavor, so be careful. Do not use it if you cannot uniquely at a role level map it to an organizational unit which you want to build roles for and have checked that the same field name will not negatively impact other authorization objects which you do not want to restrict or restrict differently.

Example 2: Fields which you want full access for or don’t care about

These should be handled with the same principles as organizational levels (must maintain them in the roles) except that you could maintain them in the roles – but don’t!

SAP has several thousand menus (and therefore SU24) applications, authorization objects and authorization field combinations and you will grow a long beard faster than what you can maintain them all in PFCG for all your roles…  🙂

The art of maintaining SU24 is to do it in such a way that all fields you care you maintain. All fields you do not care about are open so that you do not have to maintain anything in SU24 for them. There are simply too many of them. Then in the role, you can simply cascade a full access value (*) to all open fields:

Change Role Authorizations in PFCG

As a corollary to this, you must have a high degree of confidence in what you have maintained in SU24 as proposals and that the important fields are complete in SU24. Otherwise, you might unintentionally transfer full authorization to a field you want to control for that authorization instance in the role!

Tip: Use the XAMS Role Profiler Watchdogs to check roles for functional capability in case you missed something! You can also use it to check roles based on their names that they have nothing more and nothing less than you intended for them.

Example3: Fields you want specific values for in the roles for the same transaction

You should try to keep these to a minimum. There are many tricks in SU24 maintenance which I will deal with in this blog series. Here the guru level understanding of SU24 starts…

Some transactions appear to be multi-activity capable, and there is only one transaction for all the activity types. A bad example which is hard to control is PFCG. A good example is SU01 because it has alternatives.

PFCG: this is the only transaction to enter the display, change or delete activities for roles and even user assignments. There is no alternative. You should leave the important ACTVT fields open in SU24 and make the decision in the role whether it is display, change, or delete, etc. So leave the ACTVT fields open in SU24 and make your decision in the roles which values to enter. Note that SAP proposes all values, so an open field for decision in the role is better than a changed authorization. As future maintenance of the role will then always from the full value set back into the role again and make its maintenance error prone.

SU01: This is not the only transaction for displaying users. There are lots of alternatives depending on your requirements. You can also leave the ACTVT fields open in SU24, but a better option is to authorize the user for transaction SU01D and SUIM with display access as they should be doing their display work there. Further tricks to deal with users who are used to using SU01 in display mode will follow in the blog about SU24 “friends” and how the XAMS software will automatically create such roles for you.

Change Transaction SU01D in SU24

Conclusion

Using the tips from these first two blogs, you will typically be able to build a role to 99% field completion. Achievable by making the initial investment in maintaining SU24 correctly for fields which you should maintain and fields which you should not. 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