Authorization Groups (BRGRU)
Authorization Groups allow us to secure access to various entities in the SAP landscape. The most common application of authorization groups is to secure tables but they can also be used to secure other objects like customers, vendors, accounts or materials. In fact authorization groups are represented by the authorization field BRGRU and they form part of quite a few authorization objects. However lets start our discussion with the example of table authorization groups. Table authorization groups are created through the SE54 transaction shown below.
To secure access to tables/views through authorization groups, we need to assign it an authorization group. We have the choice of using any of the existing authorization groups or create a new one for our table. Both these activities can be completed through the SE54 transaction as shown below.
Note that the figure above shows the existing auth-groups created in the system. The entry “S_TABU_DIS” appears at top of the screen as this is the auth groups assigned to the table needs to be maintained for the S_TABU_DIS object with the correct activity (02 – change, 03 – display, etc) in the users’ role to complete the process of securing table access. Another point to remember is the fact that a table without any auth group maintained for it, is considered to be linked to the &NC& auth-group. So for these tables, &NC& need to be maintained in S_TABU_DIS.
Now that we are done with the use of auth groups for securing table access, lets check out their use in securing other SAP applications. To better understand the subsequent use of auth groups lets start with a display of the BRGRU field (which represents them in authorization objects) in SU20. You will note that the BRGRU field has a length of 4 and has a check table TBRG. The TBRG table is the central repository of auth groups defined in the system. When creating new groups through the SE54 transaction, we are actually accessing this table filtered for S_TABU_DIS.
To create auth groups for use in other objects, we need to directly access the TBRG table. We can use SM30, SM31 or SE16 for creating new entries. The figure below shows this table being maintained through SM30. We create entries for the F_LFA1_BEK object which is used to secure access to vendor master records.
Now to secure vendors through the created auth groups, we need to update the vendor master (transaction FK02) as shown below with the same and maintain the same values in the F_LFA1_BEK object in the users’ roles.
Similarly auth groups can be maintained for customers as well through the XD02 transaction as shown below. In this case the TBRG entries are for the F_KNA1_BED object.
Hi Aninda,
Could you please explain authorisation group further and it can be used with some more explanation, i was not able to understand the concept completely.
Tnanks in Advance!!!!
Vivek
hi Aninda,
Is there a risk of not having a authorization group assigned? (&NC&) Or doest the tabel also needs priveledges to S_TABU_DIS /S_TABU_NAM (value 2) before the can edit the table?
Looking forward to your reply. Thanks in advance.
Kind regards,
Stefan
Hi Stefan,
Its a best practice to maintain an authgroup for tables. I don’t remember whats the auth group on the TBRG table but it will certainly be checked when you try to maintain it. Due to the introduction of the S_TABU_NAM object securing individual tables are now easire than they were with S_TABU_DIS.
Thanks,
Aninda
Hi Aninda,
If u understand you correctly, so every table that hasnt got a authgroup (&NC&) should be checked (manualy) if there havent been granted access rights for S_TABU_DIS or S_TABU_NAM? (especially with custom tables that contain confidential information)
Thanks for sharing your knowledge.
Kind regards,
Stefan
Hi Aninda;
I know this post is a little old, but any way I have a doubt about that. We have some tables in a production system wich havent assigned an uth group these are Z tables; the question is. How we could remediate the problem since the auditors needs a solution for that.Tahnk you in advance.
Hi Marcos,
You can just go ahead and assign auth groups for them. Also when you try to look up tables with no explicit auth groups, the system actually checks if you have access to the auth group &NC&. If you can make sure that no one has access to this group, auditors would be happy I think.
Thanks,
Aninda
Very good post and helped me clarifying concept of auth groups.
Hi Admin I didnt understood this complete para graph (The entry “S_TABU_DIS” appears at top of the screen as this is the auth groups assigned to the table needs to be maintained for the S_TABU_DIS object with the correct activity (02 – change, 03 – display, etc) in the users’ role to complete the process of securing table access)
Can you please eloborate if you have time please.
Thanks
Hi Aninda,
Please let me know the difference between S_TABU_DIS & S_TABU_NAM.
Thanks
hari
I have talked about these objects in other posts on this blog. In general S_TABU_DIS allows you to restrict table access via table authorization groups while S_TABU_NAM allows you to restrcit at the individual table level.