SAP User Authorization Audit and Explanation

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.

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

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)

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.

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.