The SU24 transaction is one of the most important transactions in security. Its used to maintain all the objects that are checked for the execution of a particular transaction. The check indicators as maintained in SU24 are stored in two customer specific tables USOBT_C and USOBX_C. The customer specific tables ensure that the values modified by a customer are not over-written by the SAP proposed values during a future upgrade. We can have a look at the SAP proposed values through the transaction SU22.
Each object can have three different status as given in the screenshot below
- Do not check – These objects are not checked during transaction execution. Authorization objects belong to Basis and HR components can not be marked as Do not checked.
- Check , Yes (Check/Maintain in previous releases) – These objects are checked during transaction execution and also pulled into a role when the transaction is added to a role. We also have an option of maintaining default values of the authorization fields for these objects. For example, in the last post regarding role maintenance, we saw a number of authorizations which were pulled into the role with default values. These authorizations appear with status standard or maintained in role maintenance.
- Check, No (Check in previous releases) – These objects are checked during transaction execution but are not pulled into the role even if the transaction is added to the menu.
Its important to note that the primary check for an authorization object during program execution happens at the code level. So adding a check in Su24 will have no impact to security unless the code is modified as well to include a check for the authorization object. We talk about the mechanism of the authorization check at program level in our next article.
In the last two section, we have looked at both SU22 (SAP delivered check indicators) and SU24 (customer maintenance of check indicators). We have also talked about how SU22 presents data from USOBT and USOBX tables, SU24 present data from the customer tables USOBT_C and USOBX_C tables. The natural question that arises, “if SAP only writes to former set of tables and we only modify the customer tables, how are the customer tables initially filled with data?” Actually, SAP provides a standard transaction SU25 for initially copying over SAP proposed values to the customer tables. We discuss this transaction in our next section.