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”. Continue reading “STAUTHTRACE”
There is already a post in this blog which talks about the SU25 transaction. However while recently working on a upgrade, it occurred to me that the information presented was too broad and might not answer a lot of the doubts that a security analyst might face when actually tasked to complete the full post SU25 execution. I do not claim that this post will answer all the question but it does go into more depth about the thinking that should go into the post upgrade activities. This is all the more important as when done wrong, the SU25 activity has potential to reduce the check indicators and roles for a SAP system to junk! Continue reading “SU25 – A Discussion”
The SU25 transaction is needed during the initial installation of SAP and during each subsequent upgrade. Its main utility is to copy the SAP provided check indicator defaults from the USOBT and USOBX tables to the corresponding customer tables, USOBT_C and USOBX_C. These two sets of tables are needed so that the customer changes are not over-written by SAP delivered values during a future upgrade. The initial screen of the tcode is shown below.
As can be noted, the SU25 transaction is organized as a sequence of actions which need to be executed in order during installation/upgrade depending on requirement. For example, the first step (1) is to initially fill the customer tables (USOBT_C and USOBX_C) is ONLY executed during initial installation of SAP. Executing this step during a future upgrade will over-write all customer changes to check indicators.
The next set of steps compare the customer values with SAP delivered values. We have the option of accepting one or more of SAP proposed values while keeping the customer values for the rest of the objects. Since any change to check indicators for a transaction will impact all roles with it, a change during SU25 should be thorough analyzed and backed up by rigorous testing of the affected transaction.
The SU25 initial screen also has options to transport the new values for the customer tables, modify and generate roles which are affected by changes made for check indicators or even branch to SU24. Its also a good practice to document all changes performed during SU25 to help in future decision making around security.
During installation or an upgrade, SAP delivers a set of default authorization objects which are checked for each t-code which are defined in the system. These default values delivered from SAP are stored in two tables, USOBT and USOBX. The delivered check indicators for a tcode can be displayed through the SU22 transaction the initial screen of which is shown below.
On clicking the execute button we are taken to the next screen which display the delivered values for the check indicators. We can even select an object and display the field values proposed by SAP for it as shown below.
Three unique combination of values are possible for each of the objects maintained in SU22.
- Check Ind – Do not check, Proposal – No – The authorization object is not checked during the execution of the tcode. Checks for objects for the Basis and HR classes can never be switched off through this option.
- Check Ind – Check, Proposal – No – The check for the authorization object depends on the ABAP code of the program which is being executed. In case an authority-check ABAP statement is present in the code for the object, the object would need to be present in the user buffer for a successful execution. However, since proposal is No, SAP doesn’t pull the object during authorization maintenance in PFCG if the tcode is added to the role. Typically these objects will not be checked during standard execution of the tcode but might be checked while following some of the many navigation options that are present inside a tcode.
- Check Ind – Check, Proposal -Yes – The authorization object is checked ( through ABAP) during the execution of the tcode and is proposed (pulled into role) during authorization maintenance in PFCG.
Many a time, we need to change the SAP delivered values for the check indicators. This is done through the SU24 transaction which we will discuss in our next articles. The SAP defaults in SU22 sould never be manually changed by a customer. The SU22 values are only modifed by SAP (automatically) during initial installation or during a service pack upgrade.
The SAP Query component in R/3 provides a way of generating simple reports without any actual coding. From this standpoint, it is similar to the Quickviewer (transaction – SQVI) but more powerful and correspondingly a little more difficult to master. A full description of this great tool is beyond the scope of this article. Instead, my intention is to concentrate almost entirely on the security features for SAP Query and demonstrate how we can use the basic concepts of security to segregate a process chain into clear roles and responsibilities. This is the basic job of an security analyst during the all important phase of security design.
Queries are reports which can be configured by mostly drag and drop operations though a graphical editor to retrieve data from the data dictionary tables. The SAP Query component consists of three main transaction – SQ01, SQ02 and SQ03. SQ01 is the transaction for Query maintenance. It allows us to create, update, delete, display or execute queries.
Queries are not directly defined on tables but use an intermediate object called an Infoset. An infoset can be defined to be a table join or as a logical database and contains the sum total of data which the query defined on it can potentially access. SQ02 is the transaction for infoset maintenance (and display).
The final link in the chain is SQ03 – the transaction for maintenance of query user groups. Unlike many other SAP components ( and like many other ones), security for SAP Queries is not entirely controlled through roles and authorizations. To access a query, an user and and the infoset for the query must be assigned to the same query user group. Please note that the user group for queries is in no way related to the user groups maintained as part of the user master record.
So now, that we have had a brief introduction to the SAP Query transactions, lets turn to the problem of securing this application. Security for the SAP Query application is controlled through the authorization object S_QUERY. The object as the single field Activity (ACTVT) with only three possible values, 2 (change), 23 (maintain) and 67 (translate). Of these activity 2 is needed to change queries, infosets, user groups while 23 is needed for maintaining user group assignment. Also access to SQ02 or SQ03 is not possible without access to 23. Finally, a person with 23 can actually access queries belonging to other user groups without having use SQ03. Its important to note that unlike most other authorization objects, S_QUERY doesn’t have activity 03 ( display) as S_QUERY is not checked during display or execution of queries. Other than S_QUERY a user would also require some form of basic access like S_TABU_DIS for checking access to the actual data retrieved from the tables, access to change layouts (S_ALV_LAYO), exporting retrieved data to excel (S_GUI), etc. In a typical enterprise we might want to segregate access to SAP query to three distinct business roles
- Query Executor – These are the reporting users who will be responsible for actually running the queries and interpreting the results. These are normally business users and are not expected to update/change queries.
- Query Creator – These are the power users who have the business knowledge to actually design/create queries and subsequently change them depending on user requirements. They might also need to maintain Infosets.They should also be able to execute the queries to check that the designed queries output correct data. However, since the query executor is still a business user, as security administrator we would not want to give them the responsibility of assigning user groups and control who gets what!
- Query Administrators – These are the support personnel who are responsible for maintaining the user group mapping. These users would not be maintaining query design even executing queries.
With the above requirements in mind, let us design three roles for the three separate classes of people.
- Query Executor – Need access to SQ01 but not S_QUERY. Also should have access to data they are trying to retrieve (S_TABU_DIS).
- Query Creator – Access to SQ01 and SQ02 as well as S_QUERY (both activities 02 and 23). Should also have access to table data through S_TABU_DIS. Should not have access to SQ03.
- Query Administrator – Access to SQ03 as well as S_QUERY(both activities 02 and 23). No need for access to table data.
Thus we have successfully mapped business roles to SAP roles. This is the final goal for all security analysts. The only problem is instead of a single authorization object and three tcodes we are working on thousands!
The names of most Security tables begin with USR, AGR or UST. Here are a few of the most common ones
- USR02 – Users with logon data
- USR04 – Users by authorization profile assignment
- USR05 – Users by user parameters
- USR10 – Profiles with authorizations
- ARR_1251 – Authorization data for roles
- AGR_1252 – Organizational data for roles
- AGR_USERS – Roles assigned to users
- AGR_PROF – Profiles defined for roles
- AGR_HIER – Menu for a role
- AGR_TIME – Change date/time for a role
SAP delivers ECC 6.0 with more than 3000 authorization objects. Remembering even a tiny fraction of the total number is a daunting task. SAP help provides adequate documentation on the fields and use of most, if not all, the delivered objects. So instead of repeating existing information here, I would just mention a few of the existing authorization objects and their applications.
- Tables – Security for tables are controlled through three authorization objects, S_TABU_DIS (based on the table authorization group), S_TABU_CLI (security for client independent tables) and S_TABU_LIN (row level access to tables).
- Reports – Reports/Executable programs (Executable programs are just one of many different types of programs) can be protected through S_PROGRAM. S_PROGRAM checks if the executing user has access to the program authorization group maintained as a program attribute.
- Background Jobs – The basic object is S_BTCH_JOB. To administer jobs created by other users, users would also need S_BTCH_ADM. To schedule jobs with the access of another user would require S_BTCH_NAM.
- Spools – S_ADMI_FCD, S_SPO_ACT, S_SPO_DEVand S_SPO_PAGE. S_SPO_ACT can be used to give access to spools with specific authorization values. S_ADMI_FCD in addition to spools controls access to a lot of system administration/Basis function.
- User/Roles – A number of authorizations like S_USER_AGR, S_USER_AUT, S_USER_GRP, S_USER_OBJ, S_USER_PRO, S_USER_SAS. You can segregate the access for role administration with that of user administration by use of these objects.
- BDC Sessions – S_BDC_MONI. Batch Sessions are one of the possible ways of loading data intoSAP. Sessions are monitored through the SM35 transaction. S_BDC_MONI allows security on session names and the possible activites (process, lock, delete) on sessions.
- ABAP Work Bench – Access to ABAP development objects is controlled through S_DEVELOP. Controls are possible on object type, object name, activity, packages.
You might have noticed that all the above authorization objects begin with S as they deal with System Administration. I have purposely not included authorization belonging to the individual application components like MM, FICO, SD or HR as a discussion of these do nt make sense without discussing the applications themselves. So, we keep these for a later post.
Often a security administrator comes across requirements where the existing authorization objects delivered by SAP is not enough. Mostly these come during custom developments through completely new programs or enhancements to existing SAP programs. In such situations, SAP provides us with the option of defining completely new authorization objects. The names of these customer specific objects should begin with Y or Z and can be created through the SU21 transaction. If required we can define new authorization fields as well through the transaction SU20.
In the example below, we are set to create a new authorization field and use it in a new authorization object. First we go into Su20 and select the create option from the toolbar. We create a new field “ZBOOLEAN” which takes two possible values ‘X’ and ‘ ‘. The possible values for a field are controlled by the definition of the data element specified in the ABAP dictionary, in this case which is BOOLE_D. We might create our own data elements as well through SE11 transaction. On saving the new field we are prompted for a package for our new development. Packages are dictionary objects to group similar objects for transporting across development, quality assurance and production systems. We if do not plan to transport the new field we can select the local object (package $TMP) from the options.
Once the authorization field is created, its time to include it in a custom authorization object through Su21. We select the authorization class of the object and select the crate option. (Su21 also allows us to create our own authorization classes. Its a good practice to create at least one Z or Y authorization class to include our custom authorization objects).
We define the authorization field(s) for the new authorization object. Like the SAP delivered objects we are limited to a maximum of ten fields for custom objects as well. We should create some object documentation as well for future reference. On saving the new object we are again prompted for a package and we have the option of specifying a particular package or creating the new development as a local object. Typically at this point, the security administrator will contact the ABAP programmer to include a check for the new object in his code.
“Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG.
In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.
In the expanded view of the authorization data in PFCG, the org levels defined earlier appear side-by-side with the authorization fields. In fact, all org levels are also authorization fields but not all auth fields are org levels. For example, the org level Plant appears as an authorization field in two objects, M_LFPL_ORG and M_MATE_WRK. On the other hand the field Activity is not an org level. Once we maintain a particular value for an org level in a role, all authorization objects using the same org level as a field will automatically take the same value. Its technically feasible to break an org level, so that for a particular object, its value is different from its defined org level value but this defeats a the purpose of defining something as an org level.
Another difference between org levels and normal auth fields come to light while deriving a role from another master role. A normal auth field will be inherited by the child role with the same value as maintained in the parent but an org level can be maintained in the individual child roles.
Organizational Levels in most cases are intrinsically linked to the enterprise structure of an organization and largely determined during the customizing steps for the SAP systems. The below screen-shot from the SPRO transaction shows the options for configuring different org levels like company code, controlling area, purchase org, sales org etc. So its not really the security administrator who defines the org levels. He can only use the existing org levels defined during functional configuration.
Its possible to change an authorization field to an org level for the purpose of security by executing the program PFCG_ORGFIELD_CREATE. However, since this program impacts all roles which contain the org field it should only be run after a thorough analysis of all impacted roles. Also certain auth fields like Activity can never be changed to an org level.
The User Information System (transaction SUIM) is a set of reports on user-authorization data which allows security administrators to query on authorization data . SUIM is all the more important since standard table maintenance transactions like SE16 are restricted from many users in productive systems.
The initial SUIM screen shows us all the defined reports from which we can select and execute the ones needed for our analysis. We can query for users, roles, profiles, authorizations, authorization objects as well as on the change documents for any of these objects.
We take an example report, “Roles by Complex Selection Criteria” and search for roles with access to the transa ction SU01 and the authorization object S_USER_GRP.
The query results show all roles which match the selection criteria.