SU24 – Maintain Check Indicators

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.

SU24 - Initial Screen

SU24 – Initial Screen

Each object can have three different status as given in the screenshot below

SU24 - check indicators

SU24 – check indicators

  • 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.

Roles & Authorizations

Access to SAP system are assigned to users through roles maintained in their user master. In this article, we explore how access to the SAP system is extended to users through roles. We also talk about the related concepts of authorization objects and authorizations.

The transaction to create/maintain roles is PFCG. Lets create a role in PFCG and try to understand the various options available to us therein. We name the new role “ZTEST_HR_ACCESS” and click the “Single Role” button. (Note that you can follow any naming convention for your roles as long as they do not begin with SAP or /).

Role Maintenance (PFCG) - initial screen

Role Maintenance (PFCG) – initial screen

Inside, PFCG, there are again a number of tabs which need to be filled with data as part of the role creation process. We start with maintaining role name and description. There is also the option of specifying a parent role as shown in the diagram below. A child role inherits all tcodes and authorizations from its parent except the organizational levels (we will discuss org levels in a later article). The Long text field might be used as an audit log to track the background behind creating the new role.

PFCG - Role Description

PFCG – Role Description

In the menu tab, we maintain the tcodes that the role will have access to. In addition to tcodes, we can also add reports, queries and URL. There are lots of options to build the menu of a role. You can copy from an existing area menu defined in SAP, copy from another role or import from a text file.

PFCG - Menu

PFCG – Menu

Once we have maintained the menu for the role, we go into the Authorization tab. We have an option of generating a profile name or following our own naming convention. I would suggest following a naming conventions of our own (even though I have used the generated profile name in the example) as the profile name can help in subsequent reporting on authorizations. We save the new profile and click either of the two highlighted buttons, Change Authorization Data & Expert mode for profile generation to get into authorization data maintenance.

PFCG - Authorization Tab

PFCG – Authorization Tab

The next screen is for maintenance of authorization data. The different color codes define distinct security specific objects/concepts. Lets discuss these below

  • Blue LineRole – In our case its the new role which we have just created “ZTEST_HR_ACCESS”.
  • Pink Line – Authorization Class – These group Authorization Objects which protect similar application components.
  • Green Line – Authorization Object – Though called an object, an authorization object is more akin to an OOP class. Its a template or structure with a number of fields each of which needs to filled up with appropriate data to allow access.
  • Yellow Line -Authorization – This is an unique instance of an authorization object with values specified for its different fields. Carrying the OOP analogy forward, an authorization is actually similar to an object.
  • Off-white Line – Authorization Field – These are the unique fields within each authorization object. Different authorization objects will have different sets of authorization fields.

To understand how security works at the application level, we take the example of the S_TCODE object. To start a transaction, a user needs this authorization object in his user buffer with the the transaction maintained as a field value. In the example below, a user with the new role would be able to start transactions PA30, PA40 and SU53. However, starting a transaction is only the first level of check, any number of different authorization objects can be checked at each step of the transaction. These checks are for presence of individual authorizations in the user buffer.

During role maintenance, we maintain all the open field values (marked by yellow triangles) so all authorizations become green. Once finished we generate the role, by clicking the button with the a circle and red and white quadrants. This final step is the most important step in the entire process as this creates one or more authorization profiles for the role. It is actually the authorization profiles present the user buffer that give access to SAP applications. The role is just helps in easier maintenance of authorization profile. Even now, its technically feasible to directly modify authorization profiles but is strongly discouraged from SAP. Once generated, the role can be assigned through PFCG itself or through SU01.

PFCG - Role Authorization Data

PFCG – Role Authorization Data

In the next article, we discuss the link between transactions and authorization objects. This will in turn help us to understand how the authorization objects are pulled into the role during maintenance.

User Master Record

A valid user master record must exist for all users accessing the SAP system. The user master is accessed through the transaction SU01 (there is a separate version of the tcode, SU01D for display).

SU01 - User Maintenance

SU01 – User Maintenance

There are a number of tabs for maintainining different data for the users. Some of the more important tabs with the data they contain are given below.

  • Address – First, Last Names, Department, Email, Telephone, Language
User Maintenance - Address Data

User Maintenance – Address Data

  • Logon Data – Password, User Group, User Type, Validity
User Maintenance - Logon Data

User Maintenance – Logon Data

  • Parameters – User Parameters
User Maintenance - Parameters

User Maintenance – Parameters

  • Roles – These give access to the differenet function with the SAP system
User Maintenance - Roles

User Maintenance – Roles

  • Profiles – Lists the profiles corresponding to the role entries
User Maintenance - Profiles

User Maintenance – Profiles

  • License Data – License type for user. This field is evaluated as part of license audits.
User Maintenance - License Data

LSMW – Mass User Creation

LSMW stands for Legacy System Migration WorkBench. Originally it was a tool supplied by SAP to migrate data from a legacy system to SAP. However, as we will see in this article, it can be used to upload almost any data into SAP. In the present case, we will be creating a lsmw script to create a bunch of user ids, a job which is common for any security administrator. Since lsmw is based on sap BDC (batch-data-communication sessions) we would have to first create a recording to store the entire sequence of actions involved in creating a user, read the user data for a set of users from a data file and use the read data to create a session for user creation. At the final step we would run the session to actually create the users. Though I have taken the example of user creation, by no means should it be assumed that this is the only application of lsmw in security. As long as you can create a recording for a sequence of repetitive actions, lsmw can step in and lighten your load.

To start LSMW we use the transaction “lsmw”. We start create a project, subproject and object as shown below.

lsmw - create project

lsmw – create project

Once the project is created we are greeted with the lsmw main screen showing a set of actions needed to create the complete script. Depending on the nature of the script and the data all or some of these option need to be updated.

lsmw - main screen

lsmw – main screen

Step 1 – We start by maintain the object attributes. The most important attribute which needs to be specified is the name of the recording which will be used to create the BDC session. A recording is basically a set of actions that the script will replicate during executing. We can create a recording from following the menu options in the same screen. In the present case, we create a recoding for the SU01 transaction and fill up the various input fields needed to create a user.

lsmw - maintain object attributes

lsmw – maintain object attributes

Step 2 – We create a source structure to store the data needed for the script. This will store the user attributes needed by the script.

lsmw - display source structure

lsmw – display source structure

Step 3 – Next we maintain the data fields in the source structure. In the present case, I have only used the data fields – system id, last name, first name, department, email, user group and password. Nothing is really stopping you from using more or less fields. Note that unless all users use the same roles, it would be difficult to incorporate role addition into the same script.

lsmw - source fields

lsmw – source fields

Step 4 – Next we maintain the structure relations. Since we defined only one structure in our script, we accept the default values suggested and click save. This single data structure is used as the data source for the recording that is used to create each user.

lsmw - maintain structure

lsmw – maintain structure

Step 4: Maintain field mapping between the data structure and the fields used in the recording.

lsmw - map structure fields

lsmw – map structure fields

Step 5: In the next screen we can define our own fixed values, translations or routines to be used in the script. In the present script, these options are left unused.

lsmw - conversion routines

lsmw – conversion routines

Step 6: In the next screen we define the path and format of the input files which would actually store the legacy data meant to be loaded by the script. We have used a csv file in the local machine as our data source.

lsmw - specify input files

lsmw – specify input files

Step 7: Next we assign the data from the file to any of the structures used in the script. The present script uses a single file and a single data structure. So we just accept the default values suggested.

lsmw - assign files

lsmw – assign files

Step 8: Next we import the data from the source file

lsmw - import data from file

lsmw – import data from file

Step 9: On clicking execute we get the next screen displaying details about the data read. The input file in our case had 33 records for creation of 33 users.

lsmw - show details for import data

lsmw – show details for import data

Step 10: We can display the read data to verify that input data has been correctly imported into the script.

lsmw - display imported data

lsmw – display imported data

Step 11: The next 2 steps are converting imported data and displaying the converted data for verification. Since, we use imported data without change, these options remain unused for our script. Finally we generate the BDC session for our recording and using the imported data from the source file. Once the BDC session has been successfully generated we use the last screen option in lsmw or transaction SM35 to execute the session. If the recording is without errors and the data is correct, executing of the session will create the 33 users whose attributes were originally provided in the source file.

lsmw - generate BDC session

lsmw – generate BDC session

LSMW is very similar to creating a recording through transaction SHDB, generating an ABAP report for the recoding and modifying the generated code to read a source file and use the data to generate a BDC session. A seasoned ABAP developer might prefer this method as custom code provides a greater degree of flexibilty to answer complicated user requirements. However, custom code invariably results in greater maintenance and testing effort. So finally which method you end up following will probably depend on your own special requirements.


We have already looked at the other SAP authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI, S_TABU_NAM. We end our discussion on table security with the one remaining object – S_TABU_LIN used for Line Oriented Authorizations. This object can be used to provide row level access control when accessing tables through standard tcodes like SM30 and SM31. I have purposely kept the discussion about this object for the last as its the most complicated to use by far and needs configuration changes in addition to role updates. Also note that S_TABU_LIN is always checked in addition, and not in place of, the check for S_TABU_DIS.

To use S_TABU_LIN in our authorization concept, the first step is to configure a Org Criterion through the SPRO transaction. We can use the org criterions provided by SAP or create our own criteria. The path for configuring org citeria is shown below.

Line Oriented Authorizations

Line Oriented Authorizations

We chose the first of the two options, “Define Org Citeria”. We create a new org citerion called ZMOLGA. The check box, Table-ind should remain unchecked as the new org criteria would only be checked for tables maintained by us and not all tables.

Create new org criterion

Create new org criterion

With the new org criteria selected in the screen, we double click the attributes option. This screen allows us to create the attribute for the org criteria. Further we can set the attribute to be the 1st to 8th attribute. The 1st to 8th attribute are actually the authorization fields present in S_TABU_LIN. Though in the present example we will just create a single attribute and set it as the 1st attribute, SAP allows us to create 7 other attributes for the same criterion.

Define Attribute for Org Criterion

Define Attribute for Org Criterion

Finally with the attribute created we just need to set the tables/views which will be checked for the org criteria. We use the view V_T510F_B in our example. Currently SAP only allows us to enter one table or view per attribute. The direct result of this limitation is that we need to create a new org criterion for each table we want to secure through S_TABU_LIN.

Define Table for Org Criterion

Define Table for Org Criterion

We can now save our entries. The system will prompt for a transport request to contain the changed objects. We have now successfully created an org criterion. However, we still need to activate it before S_TABU_LIN and the org criterion will be checked during table access. Activating the criterion is simple. We just check the box and save our entries.

Activate Org Criterion

Activate Org Criterion

Once this preliminary configuration is done, we are free to use S_TABU_LIN in our roles to secure tables based on the Org criterion. Since our criterion ZMOLGA is based on the MOLGA field of the view V_T510F_B, we can actually restrict access to only certain rows of the table depending on the value of the MOLGA field. For example the authorization below will allow the user with this role to change rows for the V_T510F_B view when MOLGA value equals 10.

Using S_TABU_LIN in roles

Using S_TABU_LIN in roles

It is important to remember that S_TABU_LIN will only be checked for the standard SAP table maintenance transactions. Thus if we have some custom code accessing tables, row level security is not going to work for them. Off course nothing is stopping the developer in adding a authority-check statement for S_TABU_LIN in this case.


As security consultants, we are often asked to secure or grant access to SAP tables. So most of us are already aware of the authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI and S_TABU_LIN. Out of this, S_TABU_DIS is the one that is needed for all tables. S_TABU_DIS secures tables on the basis of activity (02, 03) and authorization group for the table. S_TABU_CLI is needed when a user needs access to maintain client independent tables. S_TABU_LIN is meant for Line Oriented Authorizations which allows us to authorize indivdual rows of a table. However, till now security for tables was based on the authorization groups. The limitation with authorization groups is the lack of granular security on individual tables. Once a user has access a particular table authorization group, the user can access all tables linked to the authorization group. Technically it is has always been possible to create a new authorization group and link the offending table. But this soluation came with its own problems, specially when adopted for standard tables. For example a lot of tables are accessed to by standard tcodes. Changing authorizations groups for such tables can potentially impact the functioning of tcodes calling them. Also, the new authorization groups might be overwritten by SAP service packs so this becomes a recurring check for upcoming upgrades. Fortunately SAP in its latest service packs has come up with a new authorization objects for securinf tables, S_TABU_NAM. S_TABU_NAM promises to overcome the limitation of the current S_TABU_DIS object.

S_TABU_NAM - Fields

S_TABU_NAM – Fields

As can be seen above, the object has two authorization fields. The first is activity meant to restrict access to just display (03) or update (02). The other field TABLE takes the actual name of the table and allows us to restrict/provide access to individual tables overridding access for authorization groups.

I am copying the relevant SAP code section from the standard function module VIEW_AUHTORITY_CHECK. This FM is called by all standard table access transactions like SE16, SE16N, SM30, SM31, SM34, etc.





As you can see from the code above, VIEW_AUTHORITY_CHECK has a initial check for S_TABU_DIS. Only when the S_TABU_DIS check fails, is the new object S_TABU_NAM checked. So all the existing checks and the security roles built around them need not be updated as a result of the new object. It just provides us with an additional layer of flexibility for building our checks for tables. An example scenario might be to give display access to all tables with authorization group SC but restrict write access to just the T77UA (which shares the same auth group).


Maybe I am being cynical here, but I would still say that its very rare that SAP comes up with something that reduces the daily drudgery we go through as security consultants. Today I discovered something from my colleagues that is really one of the best things I have seen in a very long time. SAP has come up with a new and improved version of the standard security trace ST01. The new transaction can be launched by using the tcode “STAUTHTRACE”. The start screen for it is shown below.

STAUTHTRACE - Start Screen

STAUTHTRACE – Start Screen

As you can see from the opening screen itself, STAUTHTRACE allows us to start a trace for multiple app servers from a single screen. Most of us work on systems which have multiple app servers. Navigating to each server, starting a trace on each of them, checking which server the user accessed and finally switching off the trace in all servers is a royal pain. This is how the window looks once we try to start the trace on mutiple servers. Since the screenshots are from a development box, only one server is shown on screen but it does show all the app servers that are part of the system.

STAUTHTRACE - Trace on multiple app servers from a single screen

STAUTHTRACE – Trace on multiple app servers from a single screen

To start a trace we can filter on the user or trace all users in the system and click the activate trace button. At this point we would ask the user whom we are trying to trace to start with the problem transactions and once the error has been reproduced, we would deactivate the trace using the corresponding button from the toolbar or menu.

To view the authorization log we enter appropriate selection criteria in the “Restriction for Evaluation” section and click the execute button. A typical authorization log would be something like the one shown below

STAUTHTRACE - Authorization Trace Details

STAUTHTRACE – Authorization Trace Details

As you can see, the tabular format of the log is so much better than the old trace file. We can easily filter the results based on return codes or copy the entire log to an excel file for further analysis. However to my mind the killer feature of this new trace is the ability to drill down to the ABAP code where the actual authority-check statement is getting executed. To drilldown, you need to double click on one of the rows or to select a row and then follow the menu path Goto > Display Callpoints in ABAP Program. Following these steps in the above log allowed me to directly jump to the following piece of code where a custom authorization object was being checked in an enahncement.

STAUTHTRACE - Navigate to ABAP code

STAUTHTRACE – Navigate to ABAP code

Since I just found out about the transaction today, I am still exploring its various features. But even if I don’t find anything more, I would be very happy with the whatever I have discovered till now.