Important Authorization ObjectsImportant Authorization Objects

SAP delivers ECC 6.0 with more than 3000 authorization objects. Remembering even a tiny fraction of the total number is a daunting task. SAP help provides adequate documentation on the fields and use of most, if not all, the delivered objects. So instead of repeating existing information here, I would just mention a fewof the existing authorization objects and their applications.

Tables Security for tables are controlled through three authorization objects, S_TABU_DIS (based on the table authorization group), S_TABU_CLI (security for client independent tables) and S_TABU_LIN (row level access to tables).

Reports Reports/Executable programs (Executable programs are just one of many different types of programs) can be protected through S_PROGRAM. S_PROGRAM checks if the executing user has access to the program authorization group maintained as a program attribute.

Background Jobs The basic object is S_BTCH_JOB. To administer jobs created by other users, users would also need S_BTCH_ADM. To schedule jobs with the access of another user would require S_BTCH_NAM.

Spools S_ADMI_FCD, S_SPO_ACT, S_SPO_DEVand S_SPO_PAGE. S_SPO_ACT can be used to give access to spools with specific authorization values. S_ADMI_FCD in addition to spools controls access to a lot of system administration/Basis function.

User/Roles A number of authorizations like S_USER_AGR, S_USER_AUT, S_USER_GRP, S_USER_OBJ, S_USER_PRO, S_USER_SAS. You can segregate the access for role administration with that of user administration by use of these objects.

BDC Sessions S_BDC_MONI. Batch Sessions are one of the possible ways of loading data into SAP. Sessions are monitored through the SM35 transaction. S_BDC_MONI allows security on session names and the possible activities (process, lock, delete) on sessions.

ABAP Work Bench Access to ABAP development objects is controlled through S_DEVELOP. Controls are possible on object type, object name, activity, and packages.

You might have noticed that all the above authorization objects begin with S as they deal with System Administration. I have purposely not included authorization belonging to the individual application components like MM, FICO, SD or HR as a discussion of these do nt make sense without discussing the applications themselves. So, we keep these for a later post.

SAP Authorization Objects Tables

Table Name

Description

TOBJ

Authorization Objects

TACT

Activities which can be Protected (Standard activities authorization fields in the system)

TACTZ

Valid activities for each authorization object

TDDAT

Maintenance Areas for Tables

TSTC

SAP Transaction Codes

TPGP

ABAP/4 Authorization Groups

USOBT

Relation transaction > authorization object

USOBX

Check table for table USOBT

USOBT_C

Relation Transaction > Auth. Object (Customer)

USOBX_C

Check Table for Table USOBT_C

User Tables

Table

Description

USR01

User master record (runtime data)

USR02

Logon data

USR03

User address data

USR04

User master authorizations

USR05

User Master Parameter ID

USR06

Additional Data per User

USR07

Object/values of last authorization check that failed

USR08

Table for user menu entries

USR09

Entries for user menus (work areas)

USR10

User master authorization profiles

USR11

User Master Texts for Profiles (USR10)

USR12

User master authorization values

USR13

Short Texts for Authorizations

USR14

Surcharge able Language Versions per User

USR30

Additional Information for User Menu

USH02

Change history for logon data

USH04

Change history for authorizations

USH10

Change history for authorization profiles

USH12

Change history for authorization values

UST04

User masters

UST10C

User master: Composite profiles

UST10S

User master: Single profiles

UST12

User master: Authorizations

Authorization Objects Checked in Role Administration

The role administration functions (and the Profile Generator) check the following authorization objects:

Authorization Object

Description

S_USER_AUT

User master maintenance: Authorizations

This authorization object defines which authorizations the administrator can process. You can use the activities to specify the types of processing (such as creating, deleting, displaying change documents).

S_USER_GRP

User master maintenance: User groups

The authorization object is used in role administration when assigning users to roles and during the user master comparison.

You can divide user administration between several administrators with this authorization object, by assigning only a certain user group to an administrator. You can use the activities to specify the administrators processing types for the group (such as creating, deleting, and archiving).

S_USER_PRO

User master maintenance: Authorization profiles

Profiles are protected with this authorization object. You can use the activities to specify the administrator's processing types for the profile (such as creating, deleting, and archiving).

S_USER_AGR

Authorization system: Check for roles

This authorization object protects roles. The roles combine users into groups to assign various properties to them; in particular, transactions and authorization profiles.

You can use this authorization object together with the authorization objects S_USER_GRP, S_USER_AUT, S_USER_PRO, S_USER_TCD, and S_USER_VAL to set up a distributed user administration.

S_USER_TCD

Authorization system: Transactions in roles

This authorization object determines the transactions that an administrator can assign to a role, and the transactions for which he or she can assign transaction authorization (object S_TCODE).

Note that a user can only maintain ranges of transactions for the S_TCODE authorization object in the Profile Generator if he or she has full authorization for the S_USER_TCD authorization object. Otherwise, he or she can only maintain individual values for the S_TCODE object.

S_USER_VAL

Authorization system: Field values in roles

This authorization object allows the restriction of values that a system administrator can insert or change in a role in the Profile Generator.

This authorization object relates to all field values with the exception of the values for the object S_TCODE.

The authorization to include transactions in a role or to change the transaction start authorization in a role is linked to the authorization object S_USER_TCD.

S_USER_SYS

Authorization object for system assignment in the Central User Administration (CUA).

You can distribute users from a central system to various child systems of a system group. The object S_USER_SYS is used to check the systems to which the user administrator can assign the users. This authorization object is also checked when setting up the CUA.

S_USER_SAS

User master maintenance: System-specific assignments

The authorization object S_USER_SAS is checked in transactions SU01, SU10, PFCG, and PFUD when you assign roles, profiles, and systems to users. It represents a development of the authorization objects S_USER_GRP, S_USER_AGR, S_USER_PRO, and S_USER_SYS, which the system previously checked when users made assignments. If you do not activate the authorization object S_USER_SAS using the Customizing switch, the previously-used authorization objects are checked.

To activate authorization object S_USER_SAS, use transaction SM30 to create the Customizing switch CHECK_S_USER_SAS with the value YES in the table PRGN_CUST. All authorization checks for the objects S_USER_AGR, S_USER_PRO, S_USER_GRP, and S_USER_SYS with the activity assign are replaced by authorization checks for the object S_USER_SAS.

S_USER_ADM

Administration functions for user and authorization administration.

The authorization object S_USER_ADM protects general Customizing and administration tasks for user and authorization administration. It consists solely of the authorization field S_ADM_AREA.

Until now, there was only the fixed value CHKSTDPWD, with which special users (such as SAP*) could be displayed, including their default passwords. SAP extends additional fixed values as required for other general administration functions in the area of user and authorization administration, which are listed in SAP Note 704307.

For more information about the authorization checks, see the system documentation for the authorization objects. To display this documentation, choose Environment ( Authorization Objects ( Display in role administration (transaction PFCG). Expand the corresponding node and choose the I button for the relevant authorization object.

Authorization Checks when Adjusting Derived Roles

You are maintaining the authorization data for a role in the Profile Generator (transaction PFCG, by choosing Change Role on the Authorizations tab page), and want to transfer this data to the derived roles (Authorizations ( Adjust Derived ( Save Derived Roles).

The authorization checks performed here correspond to those that would be performed if you adjusted the derived roles manually. The following checks are performed, in the order in which they are listed:

... 1. Changing a Role

The user requires change authorization for all derived roles (S_USER_AGR, activity 02). To avoid inconsistencies between the derived roles, the process is terminated, if the authorization check fails for at least one role. A list of all roles for which change authorization has not been assigned is displayed first.

2. Saving the Profile names

The system automatically generates profile names for roles to which no profile name has yet been assigned (starting with "T-"). The system then checks whether the role administrator is authorized to save the name (S_USER_PRO, activity 01). The program also only continues in this case, if all checks are successfully performed, because roles with no profile names cannot be correctly saved. The profile and role names for all failed checks are displayed.

3. Removing the Authorizations from the Derived Roles

During the adjustment of derived roles, their authorization data is completely removed and replaced by the data of the original role. Since the authorizations of the derived roles can be maintained individually, the system must check whether the administrator has the required authorizations for S_USER_VAL to be permitted to remove them. If the derived roles also contain manual authorizations for the object S_TCODE, the corresponding rights for S_USER_TCD are also required. If the checks are not successful for all derived roles, the process is terminated after displaying the missing authorizations.

4. Copying the Authorizations from the Original Role

The administrators authorizations for S_USER_VAL and S_USER_TCD are also checked here. Note that full authorization is required in the field AUTH_VALUE of S_USER_VAL for authorization fields that contain ranges of values (see also SAP Note 495282). If the derived role also contains manual authorizations for the object S_TCODE, the corresponding rights for S_USER_TCD are also required. These conditions also apply for point 3. In the case of missing authorizations, a list is again displayed before the process terminates with an error message.

5. Generating the Profiles

If you have chosen the function Generate Derived Roles, you also require the authorization S_USER_AGR with activity 64 for the original role and the derived roles. For structural reasons, it is not possible to adjust derived roles if you do not have authorization to generate the profile of the original role, since this action is performed before the adjustment process. If this is the case, the system displays system message 425 (class S#). Derived roles for which the profiles cannot be generated due to missing authorization are displayed in a list at the end of the adjustment process. The profiles of all other roles are generated. Termination is not required, since the authorization data of the derived roles cannot become inconsistent. After confirming the list, the system displays message 680 (S#) to complete the process. If all profiles have been generated, the system displays the message "Action performed successfully".

You can also use a background job to adjust derived roles. To do this, schedule a variant of the report SUPRN_REGENERATE_DEPENDENT, in the selection screen of which you enter the name of the original role in the field TOP_AGR. To also generate the profile, select the field GEN with an "X", otherwise leave it empty. If authorization checks fail during the run, these are recorded in the job log.

You can adjust the data for all derived roles in a single work step. If there are multiple derived roles for an original role and you want to adjust the authorization data for all derived roles to the data of the original role, we recommend that you use one of the functions listed under 3 or 4, instead of adjusting the roles individually with Transfer Data.

Creating Role Menus

You can create the role menu in the following ways on the Menu tab page, which are explained in more detail below:

Copying Menus

Buttons for menu extension: Copying transactions, reports, other objects, and authorization default values

Additional activities

Other functions

Copying Menus

With these functions, you copy some or all of the menus of other roles.

You can activate the automatic redundancy avoidance for the following activities to ensure that there are no repeated entries in the newly created menu:

For single roles, when reading menus from

The SAP menu

Roles

Area menus

A file

For composite roles, when reading menus from single roles

To do this, make the entry CONDENSE_MENU_PFCGin the Customizing table SSM_CUST with the values "NO" (default value) and "YES". In the role administration tool (transaction PFCG), choose Utilities ( Settings on the detail screen for a role. On the dialog window, set the indicator Menu: Do Not Insert Existing Entries. Standard NO.

You can override these global default settings for specific users. If you select Utilities ( Settings and Copy Menu: Do not insert existing entries, Default: NO/YES on the detail screen of any role (Display or Change Roles), redundancy avoidance is activated. Otherwise, it is not active. Although this setting applies only for this user, it applies for all of the roles for which he or she is editing the menus.

The system uses the short texts of the folder hierarchy and the short text, the transaction code, and the target system of the menu entries o determine redundancies. The system does not investigate menu entries for other objects. We recommend that you display the "Technical Name" so that you can see the effect of the redundancy avoidance. If a number of roles are assigned to a user, it can be useful to continue to use the redundancy avoidance of the Easy Access Menu.

Even if you have removed redundant folder hierarchies in all roles, there can still be redundant submenus in the Easy Access Menu of a user, if roles with wholly or partly identical menus are assigned to the user. In this case, it is useful to keep the redundancy avoidance of the Easy Access Menu active.

From the SAP menu

To copy complete menu branches or parts of menu branches, select these or expand them and select only the subordinate nodes or individual transactions and repots that you want to copy to the menu.

You can also copy submenus using an RFC link if you want to use the menu from another mySAP Workplace component system for example. Specify a target system and choose From SAP menu. You can specify whether you want to copy the menu locally or the menu of the target system of the RFC link. If you choose Remote, you are offered the SAP menu of the target system.

Use the same procedure for the options From other role and From area menu.

From a role

You can use this function to copy a menu structure that is already defined for a role in the same system or from a role delivered by SAP to the role that you are currently editing.

From an area menu

You can copy area menus (SAP Standard and your own) into a role menu. Choose an area menu from the list of menus and copy the transactions you want.

Importing from a file

You can copy menu descriptions from external products to the SAP system if the external product creates a file with the menu definition that can be uploaded into a role. If you want to create this file yourself, see the procedure in SAP Note 389675.

Buttons for Menu Extension

Transaction

You can extend the user menu by directly entering a transaction code.

Report

You can use this function to add reports, transaction variants, or queries in the user menu. You do not need to assign a transaction code to the reports, transaction variants, or queries to be included in advance.

ABAP report

Choose a report and a variant. Set the corresponding indicators to automatically generate a transaction code and to copy the description of the report.

SAP Query

Enter the name of a user group and of a query. If the query has a variant, you can specify it. You can also specify a global query. For more information, see Query work areas.

Transactions with variants

The system administrator can create transaction variants in the SAP system personalization. Transaction variants adjust complex SAP system transactions to customer business processes, by, for example, hiding superfluous information and adding other information such as pushbuttons, text or graphics. You can put a transaction variant call in a user menu by entering the transaction code and variant which you created in the transaction SHD0.

BW report

To include a report from the Business Information Warehouse, enter the ID of the report in the appropriate input field.

ReportWriter, Search, Report

You can use these functions to include application-specific report types in the user menu.

Other

In this case, a system-specific list is displayed, from which you can insert additional objects. Depending on the system, the list may contain additional entries as well as those listed below.

URL (Web address or file)

To enter Internet/intranet links, enter a descriptive text and the Web address. You can enter a file name if the browser can call an application.

Predefined URL from directory

If you want to use some URLs frequently, for example, you can predefine URL objects in the Object Navigator (SE80). To do this, choose a development class and Create ( Other ( URL objects in the context menu in the Object Navigator.

BW WebReport

You can publish queries which were defined in the Business Explorer Analyzer, in the Intranet or Internet with Web Reporting. You can insert the queries in any HTML pages to present them. You can also put various queries in an HTML page and use predefined navigation buttons or graphics to display the data.

For more information, see the documentation for the Business Information Warehouse and the SAP Service Marketplace under service.sap.com/bw ( Documentation ( Documentation Enhancements.

WebSource from Drag&Relate Servlet

Enter a name and a URL which you have defined in the Web Source Editor of the Drag&Relate servlet which is delivered with the mySAP Workplace. URLs that you define in the Web Source Editor allow Drag&Relate between the mySAP Workplace and the World Wide Web.

For more information, see the mySAP Workplace Drag&Relate documentation.

External Mail System

You can integrate a call of a mail system.

Knowledge Warehouse link

Choose the information object type with the input help for the Document field. You go to a selection screen in which you can search for the object in the Knowledge Warehouse.

Authorization Default Value

You can use this function to copy authorization default values for the subsequently listed entries, without this being visible in the SAP Easy Access user menu. This is useful, for example, if your users use a Web browser. In this situation, the Web server accesses the backend system using the relevant user and starts transactions there, for example. Since the users do not access the backend system themselves, however, they also do not require entries for the corresponding actions in their user menus, but rather only the undisplayed authorizations, so that the Web server can start the transaction for them.

You assign, for example, authorization for transaction SE61 with the role that you are editing, but this is not displayed in the SAP Easy Access menu. On the other hand, for example, transaction SE63, which you insert using the Transaction button, is displayed in the SAP Easy Access menu. The entries have different icons so that you can tell them apart while creating the menu.

Transaction

Copies the authorization default values for transactions.

RFC Function

Copies the authorization default values for RFC function modules. Currently, the correct authorization default values for the authorization object S_RFC are automatically copied. You must still add the other authorization values required for the relevant function module.

Service

Copies the authorization default values for services. From a technical point of view, there are two types of services: Repository services (program ID) and external services. All services that are managed in the repository in the SAP system and which have an object catalog entry are combined under repository services. In this case, the input help displays only the services for which there are authorization default values. External services are services that were created outside the SAP system, such as a Java program. In this case, the input help displays only the services for which there are authorization default values in the current SAP system. The names of the external services, which can be any length, are abbreviated to 132 characters in the input help, meaning that there can be identical names.

How to create and assign an Auth Group to a table

Go to SE54, Give the table name and choose authorization group and then click on create/change. You can create an authorization group.Example:You can assign a table to authorization group Z001. (Use transaction SM30 for table TDDAT) A user that wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z001 in the field DICBERCLS (authorization group for ABAP Dictionary objects).

Transporting and Distributing Roles Use

In role administration, you have the following options for transporting roles:

You can download the roles from one system and upload them into another

You can import the role from a remote system using RFC

You can transport the roles with the transport function.

Role upload loads all role data, including authorization data from a file into the SAP system. The user assignments for the role and the generated profiles for the role are exceptions in this case.

Transporting Roles with the Role Transport Function

1. Start the role administration function by choosing Tools ( Administration ( User Maintenance ( Role Administration ( Roles (transaction PFCG).

2. Enter the role to be transported and choose Transport Role.

The Mass Transport of Roles screen appears. You can control the default settings for the options Also transport single roles for composite roles and Also transport generated profiles for roles using Customizing switches (see Role Administration Functions in the section Functions of the Utilities Menu).

You should not change the authorizations profiles of the role after you have included the role in a transport request. If you need to change the profiles or generate them for the first time, transport the entire role again afterwards.

3. In the following dialog box, specify whether the user assignment and the personalization data should also be transported.

If the user assignments are also transported, they will replace the entire user assignment of roles in the target system. To lock a system so that user assignments of roles cannot be imported, enter it in the Customizing table PRGN_CUST using transaction SM30. Add the line USER_REL_IMPORT and the value NO.

If you are using Central User Administration (CUA) with global role assignment, you should not transport the user assignments of a role together with the role. In this case, you can only create user assignments in the central system. You can then send these to the system group that you have defined, if appropriate. If you nevertheless import user assignments for roles into the child systems of the CUA in these circumstances, the central system is not informed about the changes to the user master records. This means that data for the users in the child systems that you have changed in this way is overwritten with the data from the central system during the next distribution. Therefore, the user assignments created locally in the child systems with the role import are deleted.

4. Enter a transport request.

The role is entered in a Customizing request. Use Transaction SE10 to display this.

The authorization profiles are transported along with the roles, unless the profile parameter transport/systemtype is set in this SAP system to value SAP. In this case, only the profiles whose roles are assigned to customer-relevant delivery classes are transported.

You can also use a Customizing entry to prevent authorization profiles from being transported with the roles. In the transport source system, add the entry PROFILE_TRANSPORT with the value NO in table PRGN_CUST. In this case, you must use transaction SUPC (mass generation) or transaction PFCG (generation of profiles for individual roles) to generate the profiles in the target system after the transport.

5. Perform a user master comparison in the target system.

You can create perform a user master comparison in the following ways:

To perform the comparison in the background, schedule the report PFCG_TIME_DEPENDENCY periodically in the background.

To perform the comparison immediately, start report PFCG_TIME_DEPENDENCY.

To perform the comparison immediately, in transaction PFCG, choose Utilities ( Mass Comparison and enter the affected roles in the Role field on the User Master Comparison screen. Then choose Perform User Master Comparison.

Distributing Roles

In role administration, you can distribute roles on the Menu tab page, as long as the target system has a release status of at least SAP Basis 4.6A.

Performing a Mass Generation of Profiles Use

You can use the mass profile generation transaction to determine which roles already have authorization profiles. You can also perform a mass generation of roles or generate the missing role authorization profiles for roles in the background.

Prerequisites

You will need the following authorizations to use Transaction SUPC:

User master maintenance: Authorization Profile (S_USER_PRO)

User master maintenance: Authorizations (S_USER_AUT)

Authorization system: Check for roles (S_USER_AGR)

Procedure

1. In role maintenance (transaction SUPC), choose Utilities ( Mass Generation in the role maintenance (transaction SUPC).

2. Specify the desired selection criteria.

To generate all profiles to be generated automatically (last checkbox), you can further restrict the role selection in the next screen.

Comparing User Master Records Use

The user master record comparison consists of three types of comparison:

The profile comparison

With this, the profiles of time-dependent role assignments are updated.

You cannot set time limits for authorization profiles and their entry in user master records.

The composite roll area

This updates the role assignments defined in composite roles, that is, added or deleted.

The organizational management comparison

This generates the direct role assignments from the indirect role assignments of the organizational management model.

You can also choose the Clean-Ups option to delete invalid, generated profiles, and invalid role assignments.

Procedure

1. Start transaction PFUD.

2. Specify the roles that you want to use for the comparison.

3. Choose one of the following actions:

Schedule or check job for the full comparison

Here you can start report PFCG_TIME_DEPENDENCY by specifying the time when the job is to start. The overview displays the status of background jobs that have already been scheduled.

If you schedule the report PFCG_TIME_DEPENDENCY daily before the start of business as a total comparison and it runs error-free, the authorization profiles in the user master are up-to-date every morning.

If you choose this action, all four processes types are always included, regardless of your selection under Processing Type. To execute only certain processing types of the comparison as a background program (for example, with the aim of improving runtime behavior), choose Perform User Master Comparison and the desired processing types. Then choose Save, to schedule a variant of the program RHAUTUPD_NEW.

Performing the User Master Comparison

With this action, you start the user master comparison in dialog for individual roles. You can select the required processing types (see 4.).

4. If you have selected Perform User Master Comparison, choose one or more of the following processing types:

Profile Comparison: Start the profile comparison immediately after generating or importing profiles. If you are using time-dependent role assignments, we recommend that you schedule this daily as a background job. This compares the authorization profiles with the user master records; that is, profiles that are no longer current are deleted from the user master records and the current profiles are entered in the user master records.

Composite role comparison: Start the composite role comparison if you make changes to a composite role definition (that is, if you add or delete single roles to a composite role) or import a change. Single-role assignments are compared with the composite role assignments for the user. If you add single roles to the composite role, the single roles are assigned to those users that are assigned the composite role. Conversely, if single role assignments are deleted for the users, the single role is removed from the composite role.

HR comparison: Start the HR comparison,if you make changes to your local organizational management model that influence the indirect role assignment or transport these to the system. You can only select this processing type if organizational management is active; that is, if the switch HR_ORG_ACTIVE is set in the table PRGN_CUST to YES.

Clean-Ups: Perform clean-ups when you generate or import profiles. Generated profiles that no longer exist are deleted. Regular clean-ups are particularly important if you transport your roles and profiles frequently, as this helps to solve possible inconsistencies quickly.

You can also select the following options:

Display error messages: All error messages are displayed on the screen in dialog mode.

Replicate local HR assignments in the central system: You can only select this option if you are in a child system of a CUA group and if organizational management is active. This option replicates the role assignments that exist in the child system that originate through relationships in the local organizational management model, for information in the CUA central system. You can display these relationships in the user maintenance (transaction SU01).

Result

Following the comparison the system displays a log that includes any errors that occurred (background processing log for a background job).

Comparing and Adjusting Role Menus Use

You can use this procedure to compare role menus that

Belong to two roles in an SAP System

Belong to two roles in different SAP Systems

Belong to a role and its template

Belong to a newly-delivered role and its previous customer version

Prerequisites

To compare two role menus from different systems, their RFC destinations must be maintained.

Procedure

To compare the role menus, use the display mode by choosing the Compare pushbutton . To adjust the menu of the first role, that is to copy parts of the comparison role menu, choose change mode by choosing Adjust. The procedure describes change mode.

1. In the role maintenance (transaction PFCG), choose Utilities ( Role comparison tool or call transaction ROLE_CMP.

2. Enter the name of the role to be adjusted in the Role input field. Then enter the comparison role in the Comparison role field.

If you specify a single role in the Role field, compare it only to another single role. If you specify a composite role in the Role field, compare it only to a single or composite role contained within it.

3. Choose Adjust.

The Role Comparison screen appears. Until you choose Save or Activate, this screen is the same as the display mode under Role Comparison.

In this example, we compare the role to be compared Role_Compare_1 with the comparison role Role_Compare_2. Two menu entries are red in Role_Compare_1. This means that this role has two extra entries in comparison to the role Role_Compare_2. You can delete these entries by dragging them to the trashcan.

In the menu of the role Role_Compare_2, the entry Business Add-Ins is blue. That is, this entry is not contained in the role menu to be adjusted. You can copy it to the appropriate place in the role menu to be adjusted using Drag&Drop.

You cannot change the black entries.

4. Save your entries. You have created a maintenance version and the initial screen appears again.

On the initial screen of the transaction, you can choose Role ( Delete maintenance vers to discard the changes.

5. Choose Activate to create an active version of the compared role menu.

Preparatory Steps

When you activate the Profile Generator, you permit specified authorization checks to be deactivated. The Profile Generator is active in the standard system (the system profile parameter auth/no_check_in_some_cases is set).

This setting has the following effect:

When a transaction is called, the system always checks to see whether the authorization checks contained within it are to be suppressed.

The authorization Profile Generator is activated. The system displays Authorizations on the initial screen for Transaction PFCG (Role Maintenance).

Perform the following steps in the Implementation Guide (IMG):

...

1. Copy SAP default settings for check indicators and authorization field values

Using Transaction SU25 (step 1), copy the default values delivered by SAP. This is how you import the SAP check indicator default values for the authorization objects within a transaction, and the authorization field values for the Profile Generator into the customer tables (tables USOBX_C and USOBT_C). You can edit these in Transaction SU24.

You can change both configurations to meet your requirements.

To import an upgrade, follow steps 2a to 2d.

It may take a few minutes to copy the SAP defaults into the customer tables.

See the documentation in Transaction SU25.

2. Schedule Background Job for Time Limits

You can set a time limit on the assignment of users to roles. To ensure that these changes are reflected in the user master record during the profile assignment, you need to schedule a background job to make the relevant adjustments daily.

For more information, see Comparing user master record profiles with roles.

To maintain the default check indicator settings, use transaction SU24 (see the following topics). To do this, you require the authorization ABAP Workbench (S_DEVELOP) with the following field values:

ACTVT: 03 (Display) or 02 (Change)

DEVCLASS: any

OBJTYPE

SUSK (Assign transaction ( authorization object in customer systems)

SUSK (Assign transaction ( authorization object in SAP systems)

OBJNAME: Name of the transaction to be edited

P_GROUP: any

You can edit the authorization proposals in the Profile generator.

Transporting Manually-Created Profiles

To transport selected profiles, proceed as follows:

1. Choose Tools Administration ( User maintenance Authorizations and Profiles (Manual Maintenance) ( Edit Profiles Manually (transaction SU02).

2. Create a profile list and then choose Profile Transport.

3. Select the profiles you want to transport or all profiles in the list displayed.

4. Enter the transport request number for each profile or profile group in the dialog box.

5. The system asks whether you want to transport just the profile, or the authorizations it contains as well. You can either transport the profile by itself, or include all of its components in the transport request.

The system also transports the documentation for the profiles and authorizations.

6. When you have finished your selection, you can execute your transport request using the Workbench Organizer.

Transporting Manually-Created Authorizations

1. Choose Tools Administration ( User Maintenance Authorizations and Profiles (Manual Maintenance) ( Edit Profiles Manually (transaction SU03).

The Maintain Authorizations: Object Classes screen appears.

2. Select an object class by double clicking it.

The Object List screen appears.

3. Select the objects to be transported and choose Transport.

Transporting Authorization Objects and Classes

When you create or change authorization object classes in transaction SU21, the system displays a dialog box in which you can enter a change request.

Release this request for the desired target system.

Transporting Check Indicators and Field Values

You can use Transaction SU25 (Step 3) to transport all check indicators and field values.

Note that the transport overwrites all existing check indicators and field values in the target system.

You can use transaction SU24 to maintain individual check indicators. You can use the Workbench Organizer to record your changes. By executing the corresponding transport request, you distribute your check indicators to other systems.

Transporting Templates

All SAP templates are automatically identical in all systems following an upgrade. You cannot change SAP templates.

The Workbench Organizer (transaction SE09) records changes to your own templates.

Transport the request. The objects in the transport request have the following syntax: R3TR SUSV . The system transports the template name (in all languages) as well as the maintained data.

Transport User Tables between Clients

Use report RSCLCCOP to transport user master records, profiles and authorizatons between clients in an R/3 system. Start RSCLCCOP from the target client which the users and authorizations should be copied. Do not use this report if the target client contains some users and authorizations you want to preserve.

First Installation Procedure

To set up user and role administration for your SAP system:

1. Read the Security in System Groups section.

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

Security in System Groups The development system

When the development system is first installed, the users are mainly the project team members, including developers and system administrators. Most users of a newly-installed SAP system initially have the authorization profile SAP_ALL in their user master record, which allows them to perform all tasks in the system. As the project progresses it is necessary to restrict user access. Development system users usually have greater access rights as quality assurance or production system users.

Authorization administrators should make themselves acquainted with the SAP authorization concept in this phase. We recommend that you use SAP_ALL as a template and first define the role or profile _ALL without the superuser authorizations. To do this, proceed as follows:

1. Create a role with Tools ( Administration ( User maintenance ( Roles.

2. Do not enter any transactions, choose the Authorizations tab page and then Change authorization data.

3. Do not copy any templates, but choose Edit ( Add authorization. ( Full authorization.

4. Expand theBasis administration object class.

Here you find the authorizations that are generally regarded as critical.

5. Deactivate all authorizations which begin with User master maintenance or have S_USER_* in the object name, and any others which you regard as critical.

6. Using the role administration tool, generate a new profile and save it under a new name.

You can assign the role that you have just created to the relevant users in user maintenance. See Assigning roles .

This control ensures the integrity and stability of the system.

The Basis authorization objects are documented in the transaction AUTH_DISPLAY_OBJECTS. The authorization objects in the object class Basis - Administration are called S_USER_*. Place the cursor on an authorization object and choose Information.

For more information about Basis system and SAP work area authorizations, see Tools ( AcceleratedSAP ( Customizing ( Edit project and choose the SAP Reference IMG button. Search for the entries User or Authorization to call the authorization sections.

The authorization administrator creates the roles for end users in the development system. These roles are transported to the final test in the quality assurance system before being put in the production system. The user master records are usually created in the production system shortly before it goes live. The roles are assigned to the end users in the production system together with the transported authorization data, as required.

The authorization administrator must know which clients are to be created in the customer systems. Roles are not automatically copied when new clients are created. Since users, roles, authorization profiles and authorizations are client-specific, the client copy administrator must also know which user master records are to be copied.

The quality assurance system

The authorization administrator can start to transport the roles from the development system into the quality assurance system when it has been setup.

For example a member of the FI project team can check the following in the accounts payable accounting with a model user ID:

Whether the user has access to the transactions in the roles assigned to him or her

Whether these transactions correspond to the role defined by the company for the accounts payable accounting

Whether the model user ID has access authorization for certain transactions without permission

The end users can logon in a test environment and simulate production processing to test the user authorizations.

A training client is usually created in the quality assurance system because it contains the newest configuration. Larger installations have a separate training system.

The production system

When the roles and authorization profiles have been completely tested in the quality assurance system and approved by the end users or project team, the roles can be transported into the production system. The user IDs can then be created.

You should never make changes to a production SAP system. You should therefore not assign following authorizations to users in a production system:

Authorizations for the ABAP Workbench (authorization objects ABAP Workbench (S_DEVELOP) and Transport Organizer (S_TRANSPRT))

SAP system operating system command execution authorizations (transaction SM52) (System Authorizations (S_ADMI_FCD) value UNIX).

Authorizations to deactivate authorization checks (transaction AUTH_SWITCH_OBJECTS) with the authorization object S_USER_OBJ.

Setting Up User and Authorization Administrators Use

If you have organized your user administration in a decentralized manner, in which you have distributed the user administration tasks among multiple administrators, you must create these administrators as normal SAP users or assign these tasks to existing users.

The table below shows the tasks that you should assign to individual administrators, tasks that you should not assign, and the templates and roles that we have predefined for these tasks. A role is only available for the user administrator. This has the advantage over a template that the administrator receives a menu that contains all of the important functions for his or her work.

Organization of the User Administrators when using the Role Administration Tool

Administrator

Permitted Tasks

Impermissible Tasks

Templates and Roles

User Administrator

Creating and changing user master records

Changing role data

Template SAP_ADM_US

Role SAP_BC_USER_ADMI

Assigning roles to users

Changing or generating profiles

Assigning profiles beginning with "T" to users

Displaying authorizations and profiles

Using the User Information System

Authorization Data Administrator

Creating and changing roles

Changing users

SAP_ADM_AU

Changing authorization data and transaction selection in roles

Generating profiles

Using the User Information System

Authorization Profile Administrator

Displaying roles and the associated data

Changing users

SAP_ADM_PR

Using transaction PFCG or SUPC to generate the authorizations and profiles that begin with T for roles that have authorization data

Changing role data

Checking roles for the existence of authorization data (transaction SUPC)

Generating authorization profiles with authorization objects that begin with S_USER

Performing a user master comparison (transaction PFUD, Performing a profile comparison of the user master comparison)

Using the User Information System

Prerequisites

You are an administrator with the predefined profile S_A.SYSTEM, with which you can edit users of the group SUPER.

Procedure

1. Create a role for each administrator.

1. a. Enter a name in the Role field in role administration (transaction PFCG) and choose Create Role.

2. b. Do not assign any transactions; instead, choose Change authorization data on the Authorizations tab page.

A dialog box appears asking you to choose a template.

3. c. Choose one of the following templates:

Template

Administrator

SAP_ADM_PR

Authorization profile administrator

SAP_ADM_AU

Authorization data administrator

SAP_ADM_US

User administrator

4. d. Generate an authorization profile in each case.

Use a profile name that does not begin with T, so that the authorization data administrator cannot change his or her own authorizations.

2. On the User tab page, assign the role to the relevant user, that is, to the administrator.

3. Save your entries.

4. So that the user administrators cannot change their own user master records, or those of other administrators, assign them to the group SUPER. This applies if you are using the predefined user administration authorizations.

a. To do this, choose the Logon Data tab page in user administration (transaction SU01).

b. In the User Group for Authorization Check field, enter the value SUPER.

c. Save your entries.

5. If appropriate, restrict the authorizations of the administrators further:

You can use authorization objects S_USER_AGR, S_USER_TCD and S_USER_VAL to further differentiate the roles of the administrators.

For the user administrator, you can restrict the authorization to particular user groups.

For the profile administrator, you can exclude additional authorization objects, for example, for HR data. If you want your generated authorization profiles to begin with a letter other than T, you should inform your profile administrator.

Setting Up the Role Administration Tool

To use the role administration tool, perform the following steps:

...

1. The role administration tool is activated when delivered; that is, the profile parameter auth/no_check_in_some_cases is preset to the value Y. Do not change this setting.

2. Execute transaction SU25.

This copies the SAP check indicator defaults and field values into the customer tables so that you can change them.

You can then use the role administration tool to edit the authorization information for your users.

Password Rules

The following table describes the specifications that are to be followed for passwords. It also shows whether these guidelines are predefined in the system or whether you can change them using profile parameters.

Rule

Notes

The password must be at least 3 characters long

You can change this with profile parameter login/min_password_lng.

The password cannot be more than 40 characters long Until SAP NetWeaver 6.40 (inclusive), passwords could not be more than 8 characters long.

Predefined in SAP system

Until SAP NetWeaver 6.40 (inclusive), all characters of the syntactic character set can be used, that is, all letters and digits, and some special characters. The system does not differentiate between upper- and lower-case.

After SAP NetWeaver 6.40, any Unicode characters can be used, and the system does differentiate between upper- and lower-case.

As of SAP Web AS 6.10, the administrator can define how many digits, letters, and special characters must be contained in new passwords (see profile parameter).

You can change this with profile parameters login/min_password_letters, login/min_password_digits, and login/min_password_specials.

See also: login/password_charset.

The first character may not be an exclamation point (!) or a question mark (?).

Predefined in SAP system

The first three characters may not appear in the same order in the user ID

This rule applies only in systems up to SAP R/3 4.6D.

Predefined in SAP system

The first three characters cannot all be the same.

Predefined in SAP system

None of the first three characters can be a space

This rule applies only in systems up to SAP R/3 4.6D.

Predefined in SAP system

The password may not be in a list of impermissible passwords (table USR40) The list contains character combinations or terms, where the asterisk (*) and question mark (?) can be used as placeholders. Asterisk (*) stands for a character sequence, and the question mark (?) for a single character.

The administrator receives only a warning, if he or she breaks this password rule when assigning passwords in user maintenance.

Can be changed. The default value is that all passwords, except PASS and SAP* are allowed.

The password cannot be PASS or SAP*.

Predefined in SAP system

The password may not be changed to any of a users last x passwords, if the user changes the password himself or herself.

Until SAP NetWeaver 6.40 (inclusive), the password history was fixed to the value 5.

After SAP NetWeaver 6.40, the administrator can set the size of the password history (up to 100 passwords selected by the user).

The administrator can reset a users password to any initial password, therefore also to one of the last x passwords for this user. This is necessary, since the administrator should not know the passwords of the users. The user is prompted to change the initial password at the first interactive logon.

You can change this with the profile parameter login/password_history_size.

The password can only be changed after the old password has been entered correctly.

Up to SAP Web AS 6.10, the user can only change the password during the logon procedure. As of SAP Web AS 6.20, the user can also change the password by choosing System ( User Profile ( Own Data (transaction SU3)

Predefined in SAP system

Users can only change their passwords again after a wait period.

Until SAP NetWeaver 6.40 (inclusive), the wait period was one day. A password changed by a user could only be changed again by that user on the next day.

The system can now reject all password changes during the wait period (unit: days). If the administrator changes the users password, the user must change this initial password the next time he or she logs on, regardless of when he or she last changed his or her password.

System administrators can still change passwords as often as necessary.

You can change this with the profile parameter login/password_change_waittime.

The password must contain at least x lower-case letters.

Until SAP NetWeaver 6.40 (inclusive), the system did not differentiate between upper- and lower-case.

You can change this with profile parameter login/min_password_lowercase.

The password must contain at least x upper-case letters.

Until SAP NetWeaver 6.40 (inclusive), the system did not differentiate between upper- and lower-case.

You can change this with profile parameter login/min_password_uppercase.

At least one character in the new password must be different from the old password.

As of SAP Web AS 6.10, the administrator can specify the minimum number of characters that must be different in the old and new passwords in a profile parameter.

You can change this with profile parameter login/min_password_diff.

The password must comply with the current password rules and must be changed if it does not.

Until SAP NetWeaver 6.40 (inclusive), changed password rules did not apply to old password, but were only evaluated when passwords were changed.

You can activate this with the profile parameter login/password_compliance_to_current_policy.

A productive password (chosen by the user) is valid for a maximum of x days, if it is not used.

Available after SAP NetWeaver 6.40.

You can change this with the profile parameter login/password_max_idle_productive.

An initial password (set by the user administrator) is valid for a maximum of x days, if it is not used. After this period has expired, the password can no longer be used for authentication. The user administrator can reactivate password-based logon by assigning a new initial password.

Available after SAP NetWeaver 6.40.

You can change this with the profile parameter login/password_max_idle_initial.

As of SAP Web AS 6.10, the function module PASSWORD_FORMAL_CHECK can determine whether a string meets the current password rules. The following rules are not evaluated here:

Password may not be changed to any of a users last five passwords

The password can only be changed after the old password has been entered correctly.

A user can change his or her password only once a day.

At least x characters in the new password must be different from the old password.

For an exact description of the sequence and the scope of the check, see the documentation for the function module. You can display this documentation with transaction SE37.

Protecting Special Users

Clients 000, 001 and 066 are created when your SAP System is installed. Two special users are defined in clients 000 and 001. Since these users have standard names and standard passwords, you must secure them against unauthorized use by outsiders who know of their existence.

Note that no special user is created in client 066.

The two special users in the SAP System are as follows:

The SAP System superuser, SAP*

SAP* is the only user in the SAP System that does not require a user master record, but that is instead defined in the system code itself. SAP* has by default the password PASS, as well as unlimited system access authorizations.

When you install your SAP System, a user master record is defined for SAP* with the initial password 06071992 in Clients 000 and 001. The presence of a SAP* user master record deactivates the special properties of SAP*. It has only the password and the authorizations that are specified for it in the user master record.

To secure SAP* against misuse, you should at least change its password from the standard PASS. For security reasons, SAP recommends that you deactivate SAP* and define your own superuser.

The maintenance user for the ABAP Dictionary and software logistics, user DDIC.

The user master record for user DDIC is automatically created in clients 000 and 001 when you install your SAP System. The default password for this user is 19920706. The system code allows user DDIC special privileges for certain operations. For example, DDIC is the only user that is allowed to log on to the SAP System during an upgrade.

To secure DDIC against unauthorized use, you must change the initial password for the user in clients 000 and 001 in your R/3 System.

The user EarlyWatch is delivered in client 066 and is protected using the password SUPPORT. The SAP EarlyWatch experts use this user which should not be deleted. Change the password. This user should only be used for EarlyWatch functions (monitoring and performance).

Upgrade Procedure

After an upgrade, you must make adjustments to the user and role administration. What these are depends on whether you were already using the profile generator in the source release.

In the following, it is assumed that you have not yet used the profile generator, and that you are not upgrading from SAP R/3 3.0F.

If you were already using the profile generator in the last release, read Source Release with the Profile Generator (> SAP R/3 3.0F).

First of all, choose one of the following options:

1. Convert the profiles that you manually created to roles. To do this, choose step 6 in transaction SU25.

This has the advantage that the administrator can assign all of the existing, thoroughly checked profiles to the corresponding roles. You can, however, only create a user menu for the role if the corresponding authorizations for the authorization object S_TCODE are contained in the profile. Additionally, you cannot use the configuration tables (USOBX_C, USOBT_C) in which the predefined authorization values are contained.

If you use transaction SU25 (option 6) to convert profiles into roles, which you then want to derive, ensure that you choose the optimized option to copy the status of the organizational level fields contained in the profiles correctly to the role. You may then have to maintain the values in the organizational level fields, since transaction SU25 collects the field values from all authorization objects including the affected organizational levels. This means that after the migration, every authorization object contains the total of all field values in the profile for this organizational level. This ensures that the uniform status of the organizational levels in all authorization objects is maintained. This is the prerequisite for maintaining the organizational levels using the dialog box Determine Organiz. Levels.

If you are migrating the profiles using the option Identical to Profile, although only the values for the organizational level fields contained in the profile are copied to the role, it is no longer possible to maintain organization levels using the dialog box Determine Organiz. Levels.

2. Carry out a new implementation of the authorization administration using the profile generator.

This has the following advantages:

Customers experiences have made it clear that the time invested in the new implementation of the authorization administration pays off with a large time saving during other maintenance of the user and authorization data.

Your employees can take advantage of user-friendly user menus.

We recommend the second option. In addition to the advantages already mentioned, you can use the three level model for the implementation of roles, as shown in the section First Installation Procedure. A redesign of the authorization administration using the three-level model makes sense in the long term, in that the work time that an authorization administrator must expend for the maintenance of the roles can be significantly reduced.

If you have decided to use the second option (Redesigning the Authorization Administration), read the First Installation Procedure, and the following advice:

Plan the conversion of profiles to roles. Produce a list of transactions and associated profiles for which you want to set up roles. Use the Information System (transaction SUIM). You can download the Information System lists to a Microsoft Excel sheet and use it as the basis for the migration to be performed. Contact the departments and discuss which roles should be provided for which departments.

During the conversion to roles, you can decide if the naming conventions that you used have proved to be useful. If necessary, you can define a different naming convention.

Create the new roles in the development system.

The following procedure may be useful when copying the authorization values from the old profiles:

Open three sessions in the SAP system.

In the first session, start transaction SU02 and choose a profile that you want to convert to a role

In the second session, call transaction PFCG and create the new role there.

In the third session, start the transaction SUIM as a utility for maintaining the authorizations. Choose Authorization Objects ( Authorization Objects by Complex Selection Criteria. Enter the name of an authorization object. You want to know, for example, in which profile the object S_TABU_DIS is used. Choose Where-Used List. Choose the profile for which you want to create a role. Select the profile and choose Expand Subtree. You can now search for the desired authorization object (in this case S_TABU_DIS) and enter the authorization values in the role.

When you have finished the conversion of profiles to roles, call step 2C of transaction SU25.

All roles that are affected by newly added authorization checks and must be correspondingly supplemented. Edit and regenerate their authorization profiles. The system assigns the status Profile comparison required to the affected roles. Step 2C uses a traffic light system to display which roles must be checked after an upgrade. For revised roles, the traffic light is green. For roles that have not yet been revised, the traffic light is red. You can call the report repeatedly without overwriting adjustments that you have already made.

Transaction SU25 would have produced no output for profiles. It makes sense to create the roles beforehand, in order to find out which roles authorization checks have been added for.

Call step 2D to find out if transaction codes have been changed in the new release. You can also download this list to a Microsoft Excel sheet and then remove the old transaction codes during the test phase once the testers are satisfied with the new transactions.

Step 2D uses a traffic light system to display which roles have already been revised after the upgrade. For revised roles, the traffic light is green. For roles that have not yet been revised, the traffic light is red. You can switch the traffic light from red to green by double clicking it. You can call the report repeatedly without overwriting adjustments that you have already made.

In Step 2D, you can use the following pushbuttons to add new transactions to roles or to replace old transactions with new ones:

Manually adjust menu

You can manually replace or add transactions.

Automatically adjust menu

Old transactions are automatically replaced by new ones.

Automatically add menu

You can use this function to add the new transactions to each role. The system checks whether the role already contains each individual transaction. It is only added to the role if this is not the case. In this way, the users can continue using the old transactions until they have had time to learn how to use the new ones.

PAGE

5