0% found this document useful (0 votes)
88 views

Getting Started - Sap Security Pages

This document discusses several key SAP security transactions and concepts. It describes STAUTHTRACE, a new transaction for improved standard security tracing. It also covers SU25 for copying check indicator values between tables during upgrades, SU22 for viewing SAP delivered check indicators, and using SAP Query security with transactions SQ01, SQ02, and SQ03 to control access to queries through assigning users and infosets to query user groups. The document provides examples and screenshots to help explain SAP security configurations and transactions.

Uploaded by

pal singh
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
88 views

Getting Started - Sap Security Pages

This document discusses several key SAP security transactions and concepts. It describes STAUTHTRACE, a new transaction for improved standard security tracing. It also covers SU25 for copying check indicator values between tables during upgrades, SU22 for viewing SAP delivered check indicators, and using SAP Query security with transactions SQ01, SQ02, and SQ03 to control access to queries through assigning users and infosets to query user groups. The document provides examples and screenshots to help explain SAP security configurations and transactions.

Uploaded by

pal singh
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

6/19/2019 Getting Started – Sap Security Pages

SAP SECURITY PAGES


Learn SAP Security & Authorizations Concepts

C AT EG O R Y: G E T T I N G S TA R T E D

Basic Security Concepts

N OV E M B E R 2 2 , 2 0 1 3

STAUTHTRACE

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

J U LY 1 5 , 2 0 1 3

SU25 – A Discussion
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

https://www.sapsecuritypages.com/category/getting-started-with-security/ 1/23
6/19/2019 Getting Started – Sap Security Pages

SU25 activity has potential to reduce the check indicators and roles for a SAP system to
junk!

Continue reading

APRIL 12, 2011

SU25 – Copy Check Indicator Values


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.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 2/23
6/19/2019 Getting Started – Sap Security Pages

SU25 - Initial Screen

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 rst step (1) is to initially ll 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

https://www.sapsecuritypages.com/category/getting-started-with-security/ 3/23
6/19/2019 Getting Started – Sap Security Pages

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.

APRIL 10, 2011

SU22 – SAP Delivered Checks


During installation or an upgrade, SAP delivers a set of default authorization objects which
are checked for each t-code which are de ned 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.

SU22 - Initial Screen

https://www.sapsecuritypages.com/category/getting-started-with-security/ 4/23
6/19/2019 Getting Started – Sap Security Pages

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
eld values proposed by SAP for it as shown below.

SU22 - Check Indicators as delivered by SAP

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

https://www.sapsecuritypages.com/category/getting-started-with-security/ 5/23
6/19/2019 Getting Started – Sap Security Pages

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.

D EC E M B E R 1 5 , 2 0 1 0

SAP Query Security – A Simple Case Study


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 dif cult 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 con gured 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.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 6/23
6/19/2019 Getting Started – Sap Security Pages

SQ01 - Query Maintenance

Queries are not directly de ned on tables but use an intermediate object called an
Infoset. An infoset can be de ned to be a table join or as a logical database and contains
the sum total of data which the query de ned on it can potentially access. SQ02 is the
transaction for infoset maintenance (and display).

https://www.sapsecuritypages.com/category/getting-started-with-security/ 7/23
6/19/2019 Getting Started – Sap Security Pages

SQ02 - Infoset Maintenance

The nal 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.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 8/23
6/19/2019 Getting Started – Sap Security Pages

SQ03 - User Group Maintenance

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 eld
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

https://www.sapsecuritypages.com/category/getting-started-with-security/ 9/23
6/19/2019 Getting Started – Sap Security Pages

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 nal goal for all
security analysts. The only problem is instead of a single authorization object and three
tcodes we are working on thousands!

N OV E M B E R 1 5 , 2 0 1 0

Security Tables
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 pro le assignment

https://www.sapsecuritypages.com/category/getting-started-with-security/ 10/23
6/19/2019 Getting Started – Sap Security Pages

USR05 – Users by user parameters


USR10 – Pro les with authorizations
ARR_1251 – Authorization data for roles
AGR_1252 – Organizational data for roles
AGR_USERS – Roles assigned to users
AGR_PROF – Pro les de ned for roles
AGR_HIER – Menu for a role
AGR_TIME – Change date/time for a role

N OV E M B E R 1 5 , 2 0 1 0

Important Authorization Objects


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 elds 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 speci c 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
https://www.sapsecuritypages.com/category/getting-started-with-security/ 11/23
6/19/2019 Getting Started – Sap Security Pages

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.

N OV E M B E R 6 , 2 0 1 0

Custom Auth Objects


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 de ning completely new
authorization objects. The names of these customer speci c objects should begin with Y
or Z and can be created through the SU21 transaction. If required we can de ne new
authorization elds as well through the transaction SU20.

In the example below, we are set to create a new authorization eld 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 eld “ZBOOLEAN” which takes two possible values ‘X’ and ‘ ‘. The
possible values for a eld are controlled by the de nition of the data element speci ed 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 eld 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 eld we can select the local object (package $TMP)
from the options.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 12/23
6/19/2019 Getting Started – Sap Security Pages

SU20 - Create Field - Initial Screen

https://www.sapsecuritypages.com/category/getting-started-with-security/ 13/23
6/19/2019 Getting Started – Sap Security Pages

SU20 - De ne Authorization Field

Once the authorization eld 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).

https://www.sapsecuritypages.com/category/getting-started-with-security/ 14/23
6/19/2019 Getting Started – Sap Security Pages

SU21 - Create Auth Objects - Initial Screen

We de ne the authorization eld(s) for the new authorization object. Like the SAP
delivered objects we are limited to a maximum of ten elds 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.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 15/23
6/19/2019 Getting Started – Sap Security Pages

SU21 - Create Object

N OV E M B E R 6 , 2 0 1 0

Organizational Levels
“Organizational Levels” (Org Levels) as opposed to authorization elds is another of the
core concepts that we come across while creating roles in PFCG. We can access the
organizational level values de ned for a role by clicking the “org level” button in the main
toolbar within PFCG.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 16/23
6/19/2019 Getting Started – Sap Security Pages

In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing
Group, Sales Org, Division, Plant, etc.

PFCG - Org Levels

In the expanded view of the authorization data in PFCG, the org levels de ned earlier
appear side-by-side with the authorization elds. In fact, all org levels are also
authorization elds but not all auth elds are org levels. For example, the org level Plant
appears as an authorization eld in two objects, M_LFPL_ORG and M_MATE_WRK. On
the other hand the eld 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 eld will
automatically take the same value. Its technically feasible to break an org level, so that

https://www.sapsecuritypages.com/category/getting-started-with-security/ 17/23
6/19/2019 Getting Started – Sap Security Pages

for a particular object, its value is different from its de ned org level value but this defeats
a the purpose of de ning something as an org level.

Another difference between org levels and normal auth elds come to light while deriving
a role from another master role. A normal auth eld 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.

PFCG - Org Levels vs Auth Fields

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
con guring different org levels like company code, controlling area, purchase org, sales
org etc. So its not really the security administrator who de nes the org levels. He can
only use the existing org levels de ned during functional con guration.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 18/23
6/19/2019 Getting Started – Sap Security Pages

SPRO - Enterprise Structure

Its possible to change an authorization eld 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 eld it should only be run after a thorough analysis
of all impacted roles. Also certain auth elds like Activity can never be changed to an org
level.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 19/23
6/19/2019 Getting Started – Sap Security Pages

O C TO B E R 3 0 , 2 0 1 0

User Information System


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 de ned reports from which we can select and
execute the ones needed for our analysis. We can query for users, roles, pro les,
authorizations, authorization objects as well as on the change documents for any of these
objects.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 20/23
6/19/2019 Getting Started – Sap Security Pages

SUIM - Initial Screen

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.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 21/23
6/19/2019 Getting Started – Sap Security Pages

SUIM - Roles by Complex Selection Criteria

The query results show all roles which match the selection criteria.

https://www.sapsecuritypages.com/category/getting-started-with-security/ 22/23
6/19/2019 Getting Started – Sap Security Pages

SUIM - Query Result

https://www.sapsecuritypages.com/category/getting-started-with-security/ 23/23

You might also like