First Installation Procedure
To set up user and role administration for your SAP system:
...
1. See Security in system networks.
2. Get an overview of the various tasks of your staff.
If your company uses various applications, you must liaise with the various departments to decide which roles to define in each department, and which authorizations the staff is to be given. Each workplace should be defined (in writing). The authorization administrators need to know in detail which employees can access which data, call which transactions and programs, and so on.
3. In transaction SU25, choose menu entry 1: Initial Fill of the Customer Tables.
When initially filling the customer tables, the check indicators and authorization values that are preset by SAP are copied to the appropriate customer tables.
Users and user groups are assigned roles, possibly predefined, that contain typical transactions for their work. On the basis of the transactions contained in a role, the role administration tool selects the authorization objects that are checked in the transactions. If a menu has been created for a role, the role administration tool searches for the associated authorizations. These can be supplemented and modified by the administrator.
Depending on how exact the default values are, green (complete authorization), yellow (must be maintained by the authorization administrator), or red (organizational levels need to be maintained) lights appear in the display for the maintenance of the individual roles.
Default values for authorizations are delivered by SAP in the form of the tables USOBX and USOBT. The customer tables USOBX_C and USOBT_C are initially filled with the contents of these tables and can synchronized at each further upgrade.
USOBX |
Defines which authorization checks should occur within a transaction and which authorization checks should be edited in the role administration tool. You determine the authorization checks that can be edited in the role administration tool using check indicators. Only the authorization checks that are assigned the indicator Check with Default Yes (previously “PP”) can be maintained in the role administration tool.
In these tables, Check with Default Yes (previously “PP”), which is used in transaction SU24, corresponds to an X.
Authorization checks can be suppressed despite a programmed authority check command. |
USOBT |
Defines for each transaction and authorization object which default values should be used in the role administration tool for the transaction codes entered in a role menu. |
4. If necessary, adjust the extent of authorization checks before using the role administration tool.
You also use check indicators to control which objects are not to be checked, which appear in the role administration tool and which field values are displayed there for editing before the authorization profiles are generated automatically.
Adjust the authorization checks to be performed for each transaction according to your wishes. To do this, call transaction SU25 and choose point 4: Check Indicators in Transactions (SU24).
You can also globally deactivate authorization objects in the transaction SU25 (item 5). See Reduce extent of authorization checks.
5. To copy the tables to other systems in your system group, choose point 3: Transport Customer Tables.
6. Implement your role administration in accordance with the following model:
At the common level, access to commonly used transactions is created for all users of the system. Examples of contained transactions are: Printing, Online Help, SAP office, and so on. Create one (or more) roles for general activities in your company. Changes to these roles affect all employees. If general activities are part of specific job roles, changes in the general authorizations must be adjusted in all roles.
At the application level, all users of a particular application should be assigned general transactions for this application. This procedure leads to a time saving, as these general application-specific roles usually remain stable even after upgrades. If you need to make changes, you can again make “one change for all”.
At the job role level, you should assign the transactions and authorizations that are required especially for one (or a few) work centers. If roles are used at different organizational levels (for example, in different company codes), you can derive roles and change the appropriate organizational levels for the derived role in a dialog window.
Since both of the lower levels remain largely stable after the authorization administration has been implemented, the work of the authorization administrator will mainly be related to roles at the job role level after the implementation.
More information:
● Organizing Authorization Administration