SAP User Authorization Audit and
Explanation
Oct 2, 2017 | SAP | 0
How user authorization works in SAP. How users are given access to
TCode. What are authorization objects? How to audit user authorization?
How to extract users having access to particular TCode?
How authorization works in SAP?
After a user is created, in order to give authorization to users, in a typical
scenario, a user will be assigned to a role. That’s all. Once the user is
assigned to a role, he gets all the authorizations which are specified in the
role. Let’s get technical now.
If a user wants authorization to create, say a Purchase Order [TCode –
ME21N], we first need to assign the TCode to a Role. This is done through
TCode PFCG. In a small organization, users will directly be added to this
role and thus the user will get authorization to create Purchase Order (i.e.
ME21N).
Continuing with above example, if the organization wants to restrict the
users to create Purchase Order for a particular plant, we need to specify
the authorization object for which the user will have access to. For
instance – there are 2 users – Mr A and Mr B. We want to give Mr A rights
to create PO for Plant X and Mr B rights to create PO for Plant Y. We shall
create 2 roles, one for Mr A where we will specify Plant X and another role
for Mr B where we will specify Plant Y.
In a practical scenario, Mr A and Mr B will need many authorizations other
than just creating PO. For Example, view material master (TCode MM03)
and View Vendor Balance (TCode FBL3N).
Thus, looking at the above scenario, we can safely conclude if we have
many users and many plants, this is bound to get complicated and we
may end up creating thousands of roles. To overcome this problem, SAP
has the concept of Master Roles and Derived Roles.
Continuing with above example, (now with Master and Derived Role), we
shall create a Master role for all the users who need access to create
Purchase Order. Then we will move forward to creating a derived role for
each plant for which we need to restrict access. In our example, we shall
create a Master role with access to PO (ME21N), Material (MM03) and
Vendor Balance (FBL3N). Then for this Master role, create 2 Derived roles.
For Plant X, we shall specify under authorization Object our Plant X.
Similarly another role for Plant Y. Once these roles are set up, we shall
assign the role of Plant X to Mr A and role of Plant Y to Mr B. This will give
both the users (Mr A and Mr B) access to ME21N, MM03, FBL3N and
restrict PO creation (Me21N) to only respective plants.
It’s SAP. Things are complicated. Take a deep breath 🙂
Now let’s say you want to give rights of creating a Goods Receipt (GR) to
these sample users and also want to restrict Goods Receipt by a plant, we
will need to create another set of Roles for this. We can then assign users
to these roles. But SAP has a better functionality for this. It’s called
“Composite Roles”. Composite Roles are nothing but a group of Roles.
Thus instead of assigning users to the Roles, we created for PO and GR,
we create a Composite Role and then assign users to these Composite
Roles.
Thus we have 4 terminologies for “Roles” – Master Role, Derived Role,
Composite Role, Simple Role. Master or Derived role are both Simple
Roles. Simple role simply means roles with Authorizations. When someone
just uses the word ‘Role’, he is referring to Simple Role. Groups of Simple
roles is called as Composite Role.
Composite Role vs Simple Role
Creating composite roles makes sense if some of your employees need
authorizations for several roles. Instead of adding each user separately to
each role required, you can set up a composite role and assign the users
to that group. Composite roles consist of single roles. Users who are
assigned a composite role are automatically assigned the associated
single roles. Composite roles do not themselves contain authorization
data. Only Single Roles contain authorization data.
Master Roles Vs Derived Roles
Master Roles are created with Transactions, Authorization Objects and
with all organizational level management. Derived Roles are created with
organizational level management and Transactions and Authorization
Object copied from Master Role.
Now let’s talk about more technicalities of assigning Authorization to
Roles. The best way to assign Authorization to Roles is through TCode
PFCG. When we assign the Authorization to Roles, PFCG automatically
creates “Profiles” for this assignment.
Let’s take another deep breath. Again 🙂
Yes, Roles and Profiles are separate things. Newcomers in the field of the
System Audit often use these words interchangeably. These 2 words are
completely different and cannot be used interchangeably.
Continuing with the discussion about Roles and Profiles. When we add
authorizations to Roles, PFCG is creating Profiles for it and then adding the
profiles to the roles. Thus technically we are adding Authorization to
Profile and then Profile to Role.
Here comes the most important paragraph, which ties all the above
discussion.
Remember, the first para I mentioned the words “in a typical scenario”,
this is because the best strategy is to assign authorization to users
through PFCG. What I mean when I say “assign authorization” is adding
Transaction Code to the role via the SAP menu. This will trigger automatic
“Authorization Objects” to be assigned to Profile and Profile assigned to
Roles. Technically, one or more profiles are “generated” for each role.
Also, when assigning roles to users we explicitly also assign the generated
profiles to the user master.
Creating a Role
To understand how Roles are created, let’s create a Role using PFCG. We
will also see which Tables are updated when a role is created.
Open PFCG. We can see here that we have the option to create either a
Single Role or Composite Role.
Entering Role Name as “Z_ADI_TEST01”
When we click on “Single Role” button, we are taken to “Create Role”
Screen. Entering the Description.
On the Menu Tab, we can see there are no Transactions.
On the Authorization Tab, we can see there is No Profile and Status is No
Authorization Data exists.
Let’s Add our Tcode. For Demonstration, I am adding a TCode – SE16,
which is to view data of Tables in SAP.
Let’s save this and Exit from PFCG. After Exiting from PFCG, we open our
role, but instead of Editing it, let’s view the Role.
We can see that just by adding a TCode to the Menu, there is no
assignment of Authorization.
Let’s Exit and Open the Role in Edit Mode. Coming to the Authorization
Tab, we next click on “Change Authorization Data”
When we go to the Authorizations, this time, we can see 2 lines of
Authorizations added to the Role.
When we click the back button, SAP shows us the status of the Role. Let’s
click on “Save” Button. This will create a profile for the Role.
After saving the default Profile Name which was created for us by sap, we
can expand the Authorizations. This is how it looks.
I have Turned on the Technical Names (through Utilities Menu)
Let’s discuss this in dept.
There are 2 Authorization Objects assigned by SAP automatically. Shown
with Green Background. The objects are – S_TCODE and S_TABU_DIS.
These objects actually give the rights to perform an operation in SAP.
Under the object on 2nd node, we can see there are in total 3 Fields. One
Filed for Auth Object S_TCODE called – TCD and Two Filed for Auth Object
S_TABU_DIS called – ACTVT and DICBRCLS. By using Fields we can restrict
user’s rights. As in our
What do these auth object and fields signify?
First, users get rights to use TCode “SE16”, just right to open TCode is not
enough to execute the TCode. We must also give users rights to perform
operations. This is provided through another Auth Object S_TABU_DIS.
ACTVT Filed has value “03”. This signifies, users will only have rights to
Display Table and not Edit Table. DICBRCLS Field is not filled in by SAP in
our scenario, this Field can be used to restrict the class of Tables for which
users have access.
Tables were Updated after Role Creation.
Table – AGR_TCODES
This Table stores all the Menus which were assigned to the Role. As we
added only “SE16” to the Menu, we can observe there is only one entry in
the table.
However, we cannot rely on this table for finding the list of TCodes
assigned to a particular Role as TCodes can be assigned to the Role
without assigning them to Menu. This is done by manually editing the
Authorization Data in Role.
Table – AGR_1251
This Table stores all the Authorization Objects, Field Name, Field Value.
This is a very important table for auditing user Access.
Table – AGR_PROF
This Table stores all the Profile assigned to Role. As mentioned earlier,
there can be more than one profile for a Role.
