Miscellaneous - Sap Security Pages

6/19/2019 Miscellaneous – Sap Security Pages
SAP SECURITY PAGES

Learn SAP Security & Authorizations Concepts
C AT EG O R Y: M I S C E L L A N EO U S
Miscellaneous Tools
J A N UA RY 2 0 , 2 0 1 4
Mass Changes – eCATT
ECATT, SECATT or CATT has been a popular method with security consultants to
automate various tasks. Its not the only tool used for automation and can be considered
to be another option available in our arsenal. Till date I have purposely refrained from
adding any post about SECATT as almost everything that you can do via SECATT can be
done via LSMW which has been already mentioned on the site. Also, documentation
around SECATT is fairly ubiquitous on the internet and I did not think that adding the same
information here will make any difference. Recently however, I came to use another
feature of the ECATT tool which is not as popular among us security consultants and
which can actually let us do things which couldn’t do as easily before. So here goes the
rst post for the new year…. and Happy New Year 2014 for everyone. May this year be
better than the last.
Continue reading
N OV E M B E R 8 , 2 0 1 3
SE97 and TCDCOUPLES
https://www.sapsecuritypages.com/category/miscellaneous-topics/ 1/22
Its quite common in the SAP world that one transaction calls another via different menu
options. At the code level this is often implemented via the ABAP construct “CALL
TRANSACTION”. We know that to start a transaction from menu or typing via the
command window, a S_TCODE check is performed at the SAP kernel level. However
whether a S_TCODE check is performed for the CALL TRANSACTION statement can be
controlled by us through the SE97 tcode. Its not often that we need to mess with the
SE97 settings but its good to know about the option is available if needed.
Continue reading
J U LY 2 , 2 0 1 2
ABAP Debugger
After nishing the last post on SE16N and DEBUG, I realised that since this site primarily
caters to the aspiring security consultants, some portion of its target audience might be
at all familiar with ABAP debugging at all. The idea behind this post is to acquaint Security
Consultants with the basics of debugging. This is certainly not meant as a guide on how to
debug ABAP code as you would need to be familiar with ABAP syntax to actually debug
code. However, I always consider that knowing ABAP is very helpful for any consultant,
functional, security or basis. So if you have some free time you can always go through
some of the free ABAP tutorials available on the web and the added knowledge would
certainly come in handy the longer you stay with SAP.
Continue reading
JUNE 25, 2012
SE16N and SAP_EDIT
This is a continuation of the many different articles on this blog around security around
tables. However, the articles till now has concentrated on the different methods provided
by SAP to restrict access to tables. Today’s article on the other hand will talk about a
common method of accessing tables, the security implications for this form of access and
how we react as security consultant when faced with requests for this form of access.
Continue reading
JUNE 14, 2012
Database Views For Tables
Few aspects of SAP Security are as well explored by Security Consultants as security for
Tables. SAP already provides a host of objects for controlling access to tables –
S_TABU_DIS for security through table authorization groups, S_TABU_CLI for client
independent tables, S_TABU_LIN for row level security and S_TABU_NAM for security
individual tables. The use of these different authorization objects have been documented
elsewhere on this blog and I would not want to discuss any more of them here. However,
lets take a different approach and think about a way to secure individual elds for a table
or in other words column level security for a table. One of the ways to achieve these is
through the use of database views. Please note that creating database view is not the job
of a security consultant and in all probablity you would not have access to do it in any
system. However its good to know of the option if ever the need arises.
Continue reading
MARCH 27, 2012
SE03 – Objects in Transports

The SE03 transaction (Transport Organizer Tools) is certainly not a security speci c
application. However it provides at least one report which I nd to be invaluable in
managing security transports. Basically the report provides all transports (modi able/
released) which contain a particular role.
We start with the initial screen for SE03 which is really a kind of cockpit to run various
applications for transports.
SE03 - Transport Organizer Tools
We chose the report “Search for Objects in Requests/Tasks” which gets us to the next
screen. To search for roles we need to enter a line with object type ACGR (Activity Group
which is old SAP terminology for role), check the relevant boxes as shown and click the
execute button.
SE03 - Search for Objects in Transports
The output of the report display all transports which contained the affected role.
SE03 - Search for Objects in Transports Report
Though we have just used it for search for roles, we can search for any development
objects like Programs, Tables, Org Criterions to ensure that the latest transports are all
moved to Production or that no unreleased transports for an object remains in the
system.
D EC E M B E R 8 , 2 0 1 1
SAP Tables – S_TABU_LIN

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 con guration
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 rst step is to con gure a Org
Criterion through the SPRO transaction. We can use the org criterions provided by SAP or
create our own criteria. The path for con guring org citeria is shown below.
Line Oriented Authorizations
We chose the rst of the two options, “De ne 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
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 elds 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.
De ne 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.
De ne 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
Once this preliminary con guration 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 eld 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 eld. 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
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.
D EC E M B E R 7 , 2 0 1 1
SAP Tables – S_TABU_NAM

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
As can be seen above, the object has two authorization elds. The rst is activity meant to
restrict access to just display (03) or update (02). The other eld 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.
VIEW_AUTHORITY_CHECK 1
VIEW_AUTHORITY_CHECK 2
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
exibility 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).
APRIL 29, 2011
Transaction & Value Roles

The idea for this post was suggested to me by one of the visitors of this blog, who had put
in a comment around the use of value roles in security design. I though that the question
was general enough to merit its own post instead of a reply to the comment. Let me rst
begin with a confession, though I have worked in a few set ups using this concept, I have
never understood their effectiveness in security design. For me, value role create more
problems than they solve. I agree that my views are colored by the projects that I have
worked on and elsewhere, their use might make a whole lot of design sense. If any of the
visitors have any experience in innovative use of value roles which really simpli ed
security design, please feel free to comment. A healthy discussion on the subject will help
everyone of the readers including myself!
The transaction and value/controller role concept revolves around creation of

separate roles for transactions ( with S_TCODE) and authorization objects with org
level values. The latter are the value roles as the individual values for the org levels are
maintained therein. Elsewhere they are also known as controller roles or enablers, as
they control the nal access to a transaction. The transactional role in addition to
S_TCODE also contain the authorization objects which do not have org level values.
Since the value roles do not have transaction in their menu, the authorization objects are
manually added to them. During assignment, both transaction and value roles need to
be assigned to a user (sometimes via a composite role). There is no hard rule around the
number of transaction or value roles. In a typical scenario, a transaction roles might be
created to map the different jobs de ned in the enterprise. A possible starting point of
such a design will be provided by the user-transaction matrix. After the transaction roles
are set up, a few broad value roles are created with authorization objects needed for a
functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much
lesser than the number of transaction roles and will have all or most of the authorization
objects belonging to the functional area. We can also have separate value roles for
display and update and also different ones for the different ones for the various divisions
in the enterprise.
I believe the initial logic behind adoption of the value/controller roles was reduction in
maintenance effort. For example, instead of maintaining tcodes and authorization
objects in all roles, we just add the tcodes to the single transaction role and the
authorization objects to the value roles. In fact, since SU24 entries are not involved
(authorization objects are manually added to the value roles), value roles will be only be
need to be updated for a new authorization object (i.e. an object not used in the
transactions being already used). Some people might also consider it to be a cleaner
design, to keep the transactions and authorization objects separate.
After knowing the background of value roles, lets explore the problems created by their
use. For me the biggest casualty of the value roles, is the loss of all information
contained in the SU24 entry for the transaction as transactions and the objects
needed for its execution are present in different roles. Without strong documentation
practices, we can often end up with a situation where no one has any idea why a particular
authorization object was added to a value role. A direct result of the above problem, is the
fact that most value roles have more authorizations than are needed for execution of the
transaction present with a user through a transaction role. A further problem arises
because in many cases SAP allows us to jump to different transaction screens by
following navigation options in the menu for a tcode i.e. moving from a display to the
corresponding update transaction. Even though SAP would normally check for update
activity in such a case, a S_TCODE check might not be enforced. Hence, user would get
access to an update transaction through the value role even though transaction role only
allows the display version. There might be many other such cases, where access
present in the value roles might open up extra access with the tcodes present in the
transaction roles. Finally the security testing effort is also increased a great deal as
without the use of SU24 to guide us, the only way to determine the complete access
needed for a tcode is run a trace for each new transaction and check each of the value
roles to ensure that they contain required access.
I have already mentioned my skepticism for the value role concept for security design. In
fact, I am even unwilling to accept the argument about less maintenance effort for value
roles as the same can be realized with a parent-child role based design. However, there is
overwhelming majority of security installations which continue to use value roles. If any
senior security experts are currently reading this post, I would sincerely request their
comments on the same as its extremely probable that I am missing something about the
potential bene ts for value roles.
APRIL 20, 2011
Parent & Derived Roles

The concept of parent and derived roles was introduced by SAP to simplify role
administration tasks. Its specially helpful while mapping security for large enterprises
spread across multiple geographies or divisions. A child role derived from a parent role will
have all attributes (transactions/ authorization object values) same as it parent except the
values of the Organizational Level elds (plant, company code, sales organization). Thus
maintenance is simpli ed as only the org levels need be maintained at the derived role
level. This also ensures that there is no opportunity to make mistakes during authorization
maintenance for the multitude of derived roles and also reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In the
example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the
creation of Sales Orders (transaction VA01) for all company code, sales orgs.
PFCG - De ne Parent Roles
With the parent already de ned we create a child role “Z_CREATE_SO_US” which allows
SO creation for the US companies. We maintain the parent role name as shown below.
PFCG - Derived Roles - De nition
The menu for a derived role can not be individually maintained as all entries are inherited
from the parent.
PFCG - Derived Roles - Menu can not be changed
Now we maintain the org levels values relevant for the child role. In the example below, we
have used a dummy value of @ but in a production system the correct value for org levels
should be used. The other other need not be maintained at this stage. Now we save the
authorization entry for the derived role.
PFCG - Derived Roles - Maintain Org Levels
To populate the rest of the authorization values for the child role, we go into the
authorization maintenance screen for the parent and click the button “push from gl”. This
option pushes the non org level values from the parent to the child role and generates the
pro les for both.
The most critical success factor for a parent-derived role concept is how well, the
different business processes mapped by SAP roles are mirrored across the different
divisions in an enterprise. In other words, a parent-derived role concept will not be very
bene cial in case an enterprise follows different business process in its different
subsidiaries.

Miscellaneous - Sap Security Pages

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Miscellaneous - Sap Security Pages

Uploaded by

Copyright:

Available Formats

6/19/2019 Miscellaneous – Sap Security Pages

SAP SECURITY PAGES

Mass Changes – eCATT

SE97 and TCDCOUPLES

JUNE 25, 2012

SE16N and SAP_EDIT

JUNE 14, 2012

Database Views For Tables

MARCH 27, 2012

SE03 – Objects in Transports

SE03 - Transport Organizer Tools

SE03 - Search for Objects in Transports

SE03 - Search for Objects in Transports Report

SAP Tables – S_TABU_LIN

Line Oriented Authorizations

Create new org criterion

De ne Attribute for Org Criterion

De ne Table for Org Criterion

Activate Org Criterion

Using S_TABU_LIN in roles

SAP Tables – S_TABU_NAM

APRIL 29, 2011

Transaction & Value Roles

The transaction and value/controller role concept revolves around creation of

APRIL 20, 2011

Parent & Derived Roles

PFCG - De ne Parent Roles

PFCG - Derived Roles - De nition

PFCG - Derived Roles - Menu can not be changed

PFCG - Derived Roles - Maintain Org Levels

You might also like