User and role administration of as abap

User and Role Administration of AS ABAP
PDF download from SAP Help Portal:
http://help.sap.com/saphelp_nw70ehp2/helpdata/en/52/671126439b11d1896f0000e8322d00/content.htm
Created on January 27, 2015
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing subtopics.
© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 104

Table of content
1 User and Role Administration of AS ABAP
1.1 AS ABAP Authorization Concept
1.1.1 Organizing Authorization Administration
1.1.2 Assigning Authorizations
1.1.3 From the Programmed Authorization Check to a Role
1.1.3.1 Editing Authorization Default Data (Development System)
1.1.3.2 Editing Authorization Default Data (Customer System)
1.1.3.3 Maintaining Authorizations in SAP Example Roles
1.1.3.4 Maintaining Authorizations in Roles for Productive Use
1.1.3.5 Trace for Authorization Checks
1.1.3.5.1 Maintaining Authorization Default Values Using Trace Evaluation
1.1.3.5.2 Maintaining Authorization Fields Using Trace Evaluation in Trans
1.1.3.5.3 Maintaining Role Menus Using Trace Evaluation in Transaction PFC
1.1.3.5.4 Using the System Trace to Record Authorization Checks (Transacti
1.1.3.6 Glossary
1.2 Configuration of User and Role Administration
1.2.1 First Installation Procedure
1.2.1.1 Setting Up User and Authorization Administrators
1.2.1.1.1 Configuring User Group as Required for User Master Records
1.2.1.1.2 Interaction of Required User Groups and Central User Administrat
1.2.1.1.3 Enabling Movement Activity for S_USER_GRP
1.2.1.2 Setting Up the Role Administration Tool
1.2.1.2.1 Defining the Scope of Authorization Checks
1.2.1.2.1.1 Preparatory Steps
1.2.1.2.1.2 Globally Deactivating Authorization Checks
1.2.1.2.1.3 Reducing Authorization Checks in Applications
1.2.1.2.1.4 Searching for Deactivated Authority Checks
1.2.1.2.1.5 Editing Templates for General Authorizations
1.2.1.2.1.6 Check Indicators
1.2.1.3 Logon and Password Security in the ABAP-System
1.2.1.3.1 Password Rules
1.2.1.3.2 Profile Parameters for Logon and Password (Login Parameters)
1.2.1.3.3 Customizing Switches for Generated Passwords
1.2.1.4 Rules for User Names
1.2.1.5 Protecting Special Users
1.2.1.5.1 Securing User SAP* Against Misuse
1.2.1.5.2 Securing User DDIC Against Misuse
1.2.1.6 Security in System Groups
1.2.2 Role Administration
1.2.2.1 Role Administration Functions
1.2.2.1.1 Changing Standard Roles
1.2.2.1.2 Creating Single Roles
1.2.2.1.2.1 Role Menu
1.2.2.1.2.2 Merge Function for the Authorization Data of PFCG Roles
1.2.2.1.2.3 Editing Predefined Authorizations
1.2.2.1.2.3.1 Symbols and Status Text in Authorization Administration
1.2.2.1.2.3.2 Copying Authorizations From Templates
1.2.2.1.2.4 Assigning Users
1.2.2.1.2.5 Assign MiniApps
1.2.2.1.2.6 Personalization Tab Page
1.2.2.1.3 Creating Derived Roles and Copying Authorizations
1.2.2.1.3.1 Authorization Checks when Adjusting Derived Roles
1.2.2.1.4 Comparing and Adjusting Role Menus
1.2.2.1.5 Creating Composite Roles
1.2.2.1.6 Generating Authorization Profiles
1.2.2.1.6.1 Regenerate the Authorization Profile Following Changes
1.2.2.1.6.2 Performing a Mass Generation of Profiles
1.2.2.1.7 Transporting Authorization Components
1.2.2.1.7.1 Transporting and Distributing Roles
1.2.2.1.7.2 Transporting Manually-Created Profiles
PUBLIC
Page 2 of 104

1.2.2.1.7.3 Transporting Manually-Created Authorizations
1.2.2.1.7.4 Transporting Check Indicators and Field Values
1.2.2.1.7.5 Loading or Storing Check Indicators and Authorization Default Va
1.2.2.1.7.6 Transporting Templates
1.2.2.1.8 Analyzing Authorization Checks
1.2.2.1.8.1 Analyzing Authorizations using the System Trace
1.2.2.1.8.2 Authorization Error Analysis Functions
1.2.2.2 Indirect Role Assignment Using Organizational Management (OM)
1.2.2.2.1 Assigning a Role Indirectly
1.2.2.2.2 Indirect Role Assignment in a System Landscape
1.2.2.2.3 Distribution of the Organizational Management Model
1.2.2.2.3.1 Creating an Organizational Management Distribution Model in the
1.2.2.2.3.2 Generating Partner Profiles of the OM Distribution Model
1.2.2.2.3.3 Creating an Outbound Filter with Customer Exit
1.2.2.2.3.4 Activating Change Pointers
1.2.2.2.3.5 Writing Change Pointers for Infotype 0105
1.2.2.2.3.6 Distributing the Organizational Management Model (Initial Distri
1.2.2.2.3.7 Distributing Changes to the Organizational Management Model
1.2.3 Central User Administration
1.2.3.1 Setting Up Central User Administration
1.2.3.1.1 Creating an Administration User
1.2.3.1.2 Setting Up Logical Systems
1.2.3.1.2.1 Defining/Setting Up a Logical System
1.2.3.1.2.2 Assigning a Logical System to a Client
1.2.3.1.3 System Users and RFC Destinations
1.2.3.1.3.1 Defining Authorizations for System Users
1.2.3.1.3.2 Determining Existing RFC Destinations and System Users
1.2.3.1.3.3 Creating System Users
1.2.3.1.3.4 Creating an RFC Destination for the Target System
1.2.3.1.3.5 System Users and RFC Destinations with Trusted Systems
1.2.3.1.3.6 Creating RFC Destinations for the Target System with a Trusted S
1.2.3.1.3.7 Advantages and Disadvantages of Trusted RFC Destinations
1.2.3.1.4 Creating the Central User Administration
1.2.3.1.5 Setting Up Field Distribution Parameters
1.2.3.1.6 Synchronizing and Distributing Company Addresses
1.2.3.1.7 Synchronizing User Groups
1.2.3.1.8 Transferring Users from New Systems
1.2.3.1.9 Displaying and Processing Distribution Logs
1.2.3.2 Error Analysis
1.2.3.2.1 Checking the Setup of Central User Administration
1.2.3.2.2 Avoiding Termination when Saving the System Landscape
1.2.3.2.3 Creating an ALE Model Including Partner Profiles Manually
1.2.3.2.3.1 Creating the ALE Distribution Model
1.2.3.2.3.2 Generating Partner Profiles
1.2.3.2.3.3 Checking Partner Profiles
1.2.3.2.3.4 Correcting Errors in Partner Profiles
1.2.3.2.3.5 Distributing the Model View
1.2.3.2.3.6 Other Error Sources
1.2.3.3 Activated Background Processing
1.2.3.3.1 Changing Partner Profiles with Active Background Processing
1.2.3.3.2 Creating a Background User
1.2.3.4 Removing Central User Administration
1.2.3.4.1 Removing a Child System from Central User Administration
1.2.3.4.2 Removing Central User Administration Completely
1.2.3.5 Glossary
1.2.3.5.1 Application Link Enabling (ALE)
1.2.3.5.2 ALE Landscape
1.2.3.5.3 ALE Integrated System
1.2.3.5.4 User Master Record
1.2.3.5.5 Authorization
1.2.3.5.6 Authorization Profile
1.2.3.5.7 Background Processing
PUBLIC
Page 3 of 104

1.2.3.5.8 IDoc
1.2.3.5.9 System User
1.2.3.5.10 Logical System
1.2.3.5.11 Partner Profile
1.2.3.5.12 Profile
1.2.3.5.13 Profile Generator
1.2.3.5.14 Remote Function Call (RFC)
1.2.3.5.15 Role
1.2.3.5.16 Child System
1.2.3.5.17 Distribution Model
1.2.3.5.18 Central User Administration (CUA)
1.2.3.5.19 Central System
1.2.4 Central Repository for Personalization Data
1.2.4.1 Use of the Generic Repository
1.2.4.2 Implementing a Dialog
1.2.4.3 Integrating External Tables
1.2.4.4 Registering Personalization Objects
1.2.5 Directory Services
1.2.5.1 LDAP Connector
1.2.5.2 Maintaining the Directory Server
1.2.5.2.1 Configuring the LDAP Connector
1.2.5.2.2 Configuring Connection Data for the Directory Service
1.2.5.2.3 Defining the System User of the Directory Service
1.2.5.3 LDAP Connector Interface
1.2.5.4 Logging On to the Directory Service
1.2.5.5 Calling LDAP Protocol Functions
1.2.5.6 Synchronization of SAP User Administration with an LDAP-Compatib
1.2.5.6.1 Mapping SAP Data Fields to Directory Attributes
PUBLIC
Page 4 of 104

User and Role Administration of AS ABAP
Purpose
You use the user and role administration functions of AS ABAP to administer the users, roles, and authorizations in ABAP systems.
By assigning roles and authorizations, you limit the scope of action of individual users in the system.
Structure
The documentation for the user and role administration of the Application Server ABAP (AS ABAP) consists of the following parts:
● AS ABAP Authorization Concept
This section introduces the authorization components with which the user and role administration work.
● Configuration of User and Role Administration
This section describes setting up all elements of user and role administration.
● Administration of User and Role Administration
This section describes all administration tasks and the exact procedures of user and role administration.
● Reference Documentation for User and Role Administration
This section contains additional information, such as the manual editing of authorization profiles, which is no longer recommended.
● Developer Documentation for User and Role Administration
This section contains information about authorization checks in your own developments.
1.1 AS ABAP Authorization Concept
The ABAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization
concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP system, after he or she has logged on
to the system and authenticated himself or herself.
To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by
authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the
employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles
using the user master record, so that the user can use the appropriate transactions for his or her tasks.
The following graphic shows the authorization components and their relationships.
Explanation of the Graphic
Term Notes
User Master Record These enable the user to log onto the SAP system and allow access to the functions and
objects in it within the limits of the authorization profiles specified in the role. The user
master record contains all information about the corresponding user, including the
authorizations.
Changes only take effect when the user next logs on to the system. Users who are
logged on when the change takes place are not affected in their current session.
Single role Is created with the role administration tool and allows the automatic generation of an
authorization profile. The role contains the authorization data and the logon menu for the
user.
Composite role Consists of any number of single roles.
Generated authorization profile Is generated in role administration from the role data.
Manual authorization profile To minimize the editing effort if you are using authorization profiles, do not usually enter
single authorizations in the user master record, but rather authorizations combined into
PUBLIC
Page 5 of 104

authorization profiles. Changes to the authorization rights take effect for all users whose
user master record contains the profile the next time they log on to the system. Users
who are already logged on are not immediately affected by the changes.
We strongly recommend that you do not assign profiles manually, but rather do so
automatically with the role administration tool.
Composite profile Consists of any number of authorization profiles.
Authorization Definition of an authorization object, that is, a combination of permissible values in each
authorization field of an authorization object.
An authorization enables you to perform a particular activity in the SAP system, based
on a set of authorization object field values.
Authorizations allow you to specify any number of single values or value ranges for a
field of an authorization object. You can also allow all values, or allow an empty field as a
permissible value.
If you change authorizations, all users whose authorization profile contains these
authorizations are affected.
As a system administrator, you can edit authorizations in the following ways:
● You can extend and change the SAP defaults with role administration.
● You can change authorizations manually. These changes take effect for the
relevant users as soon as you activate the authorization.
The programmer of a function decides whether, where and how authorizations are to be
checked. The program determines whether the user has sufficient authorization for a
particular activity. To do this, it compares the field values specified in the program with
the values contained in the authorizations of the user master record.
The line of the authorization is highlighted in yellow.
Authorization object An authorization object groups up to ten fields that are related by AND.
An authorization object allows complex tests of an authorization for multiple conditions.
Authorizations allow users to execute actions within the system. For an authorization
check to be successful, all field values of the authorization object must be appropriately
entered in the user master record.
Authorization objects are divided into classes for comprehensibility. An object class is a
logical combination of authorization objects and corresponds, for example, to an
application (financial accounting, human resources, and so on). The line of the
authorization object class is highlighted in orange.
For information about editing the authorization values, double-click an authorization
object.
The line of the authorization object is highlighted in green.
Authorization field Contains the value that you defined. It is connected to the data elements stored with the
ABAP Dictionary.
The objects (such as authorizations, profiles, user master records, or roles) are assigned per client. For more information about transporting these
objects from one client to another, or from one system to another, see the SAP Library, in the in sections Transporting Authorization Components
and Change and Transport System (BC-CTS).
If you develop your own transactions or programs, you must add authorizations to your developments yourself (see Authorization Checks in Your
Own Developments).
To be able to successfully implement the authorization strategy, you need a reliable authorization plan. To produce a plan, you must first decide which users may
perform which tasks in the SAP system. You then need to assign the authorizations required for these tasks in the SAP system to each user.
The development of a stable and reliable authorization plan is an ongoing process. We recommend that you regularly revise the authorization plan so that it always
meets your requirements. Define standard roles and procedures for creating and assigning roles, profiles, and authorizations.
More information:
● Assigning Authorizations
● Authorization Checks
● Authorization Checks in Your Own Developments
● Authorization Check Scenario
● Role Administration
Organizing Authorization Administration
The authorization system allows you great flexibility in organizing and authorizing the administration of user master records and roles:
● If your company is small and centralized, you can have all administration of user master records and authorization components executed by a single
superuser.
More information on setting up superusers: Protecting Special Users.
● Depending on the size and organization of your company, you should, however, distribute the administration of user master records and authorizations among
multiple administrators, each with limited areas of responsibility. This applies in particular in a decentralized environment, in which different time zones might
apply. This also helps to achieve maximum system security.
Each administrator should only be able to perform certain tasks. By separating these tasks, you make sure that no single superuser has total control over
your user authorizations. You also make sure that more than one person approves all authorizations and profiles. In addition, define standard procedures for
creating and assigning your authorizations.
PUBLIC
Page 6 of 104

Since you can precisely restrict authorizations for user and authorization administration, the administrators do not have to be privileged users in your data
processing organization. You can assign user and authorization administration to ordinary users.
We recommend you use the role administration tools and functions (transaction PFCG) to maintain your roles, authorizations and profiles. These
functions make your job easier by automating certain processes and providing more flexibility in your authorization plan. You can also use the
Central User Administration functions to centrally edit the roles delivered by SAP or your own, new roles, and to assign the roles to any number of
users.
Organization if You Are Using the Role Administration Tool
If you are using the role administration tool (the profile generator), you can distribute the administration tasks within an area (such as a department, cost center, or
other organizational unit) to the following administrator types:
● Authorization data administrator, who creates roles (transaction selection and authorization data), selects transactions, and edits authorization data. However the
authorization data administrator can only save data in the role administration tool, since he or she is not authorized to generate the profile, He or she accepts
the default profile name T_.... when doing this.
● Authorization profile administrator, who checks and approves the data, and generates the authorization profile. To do this, he or she choose → All Roles in
transaction SUPC, and then specifies the abbreviation of the role to be edited. On the following screen, he or she checks the data by choosing Display
Profile .
● User administrator, who edits the user data with the user administration transaction (SU01) and assigns roles to the users. This enters the approved profiles in
the master records of the users.
These administrators of one or more areas are administered by superusers who set up their user master records, profiles, and authorizations. We recommend that
you assign the superuser, the user administrator, and the authorization administrator the SUPER group. If you use the pre-defined user administration
authorizations, this group assignment makes sure that user administrators cannot modify their own user master records or those of other administrators. Only
administrators with the pre-defined profile S_A.SYSTEM can edit users in the group SUPER.
The table in the section Setting Up User and Authorization Administrators shows the tasks that you should assign to individual administrators, tasks that you
should not assign, and the templates that we have predefined for these tasks.
No authorization profile beginning with “T” may contain critical (S_USER* objects) authorization objects.
1.1.2 Assigning Authorizations
Use
A single administrator (superuser) or a group of administrators assign authorizations, depending on the size and organization of your company. By assigning
authorizations, the administrator determines (within the range of possibilities defined by the programmer) which functions a user may execute or which objects he
or she may access.
The following rules apply to the use of placeholders in manual authorizations (transaction SU03) and in roles (transaction PFCG):
■ The asterisk (*) is the only valid placeholder. All placeholders that are familiar from other applications, such as the plus sign (+) are handled as
normal characters.
■ If an authorization value contains additional characters after an asterisk, these are ignored during the authorization check. Example: The value A*B is
interpreted as A*.
Process Flow
As an administrator, you perform the following steps to assign authorizations:
● Editing authorizations for each authorization object
An authorization is the combination of permissible values in each authorization field of an authorization object.
● Generating authorization profiles
Authorizations are grouped in authorization profiles in such a way that the profiles describe work centers, for example, flight reservation clerk .
We recommend that your system administrator automatically sets up authorization profiles using the Profile Generator (see Role Administration). If necessary,
the administrator can also set up an authorization profile manually by choosing Tools → Administration, User maintenance → Profiles (see Creating
and Maintaining Authorizations and Profiles Manually).
● Assigning authorization profiles to a user master record
By assigning the roles, you assign the corresponding authorization profiles (work centers) to a user master record.
Result
When an authorization check takes place, the system compares the values entered by the administrator in the authorization profile with those required by the
program for the user to execute a certain activity.
1.1.3 From the Programmed Authorization Check to a Role
The aim of the process described below is the creation of a role. Roles are a description of the activities for a work center and consist of one or more applications
PUBLIC
Page 7 of 104

(transactions, Web Dynpro applications, and so on). The fundamental elements of the role are the menu and the associated authorizations.
Role Menu
The role's menu is created by an administrator and contains all applications that the user requires for his or her activities. The role menu is an element of the
user menu that is displayed for the use rin SAP GUI, for example, in the SAP Easy Access menu or in the NetWeaver Business Client.
Authorizations of the Role
The administrator assigns corresponding authorizations for the applications contained in the role menu. To do this, the adminsitrator needs to answer the
question of which authorizations are required for a particular application and must therefore be included in the role. SAP developers deliver this knowledge
with the program. It defines which authorization objects are required in an application. It defines default data and specifies the authorization objects for which
the user requires an authorization to execute this application. Developers maintain this default data for each application in transaction SU22, and delivers it.
The Profile Generator combines the default data defined by developers for each application in the role menu with the not-yet-fully-specified role
authorizations. These authorizations might still contain empty fields.
In SAP development systems (profile parameter transport/systemtype='SAP'), the Profile Generator copies the authorization default data from the
SU22 tables. In customer systems (profile parameter transport/systemtype='CUSTOMER'), the customers copy the data delivered by SAP
developers into the customer-specific tables (SU24 data). Customers can adjust the delivered default data to their requirements in these tables. In customer
systems, the authorizations for the role are based on the default data in the customer tables (SU24 data).
Process
The process below describes the steps with which SAP determines the authorizations and default values and delivers them, and how you can change and assign
them.
Sequence of the Process Steps
1. Steps for SAP Developmers
1. SAP developers use, for example, ABAP Workbench to implement an application with authorization checks programmed in.
2. Developers fully test this application.
3. Developers define, in transaction SU22, which authorization objects are required for their application. The authorization trace supports them by permanently
logging authorization checks that occur in an application in development and test systems. More information: Maintaining Authorization Fields Using Trace
Evaluation in Transaction SU22.
Transaction SU22 displays a list of authorization objects that the trace has logged for the selected application. Developers need to classify these objects by
assigning the authorization default status.
No
By setting this authorization default status, developmers inform administrators that a user does not rqeuire an authorization for this object to execute the
core functionality of this application. Do not confuse this with the check indicator for transactions with which the check is deactivated. For more
information about check indicators, refer to Editing Check Indicators for Objects in Editing Authorization Default Data (Development System).
If the administrator adds the application to a role, the Proifile Generator does not place an authorization for this object in the role.
Yes
By setting this default status, developers inform administrators that the user requires an authorization for this object in order to execute the core
functionality of the application. If the administrator adds the application to a role, the Proifile Generator adds an authorization for this object in the role.
The consequence is that the Profile Generator includes an authorization for this authorization object in the role authorizations using the delivered
authorization default values.
The fields of the authorizations are predefined with the proposed values. If you do not specify any values, you can specify Yes, Without Values .
Deliver default values for the fields of the authorization object for which you know which values will be checked in customers' systems. Leave fields
with customer-specific content empty.
PUBLIC
Page 8 of 104

Yes, Without Values
functionality of the application. However, the developers cannot specify any values, since these are only determined in the customer system.
If the administrator adds the application to a role, the Proifile Generator places an empty authorization for this object in the role.
More information: Editing Authorization Default Data.
4. Developers can deliver an SAP example role. An SAP example role is used to map a function or activity description. That is, the menu contains the
applications (transactions, Web Dynpro applications, and so on) that are required for this activity. The Profile Generator then generates authorization for this
role from the SU22 default data. Developers maintain open fields – as far as possible and necessary for this function. Developers leave fields empty that
can only be maintained by the customer.
2. Steps for Authorization Administrators in the Customer System
1. The customer's authorization administrators use transaction SU25 to transfer the authorization data from the SAP tables (SU22 data) to the customer tables
(SU24 data).
For more information, refer to point 3 in Procedure Before First Installation.
2. The authorization administrators edit the SAP authorization data in the customer tables to adjust or extend them in accordance with the customer's needs.
3. The authorization administrator creates a role. He or she has the following options when doing so:
He or she can copy a delivered SAP role (example role) into the customer namespace and then perform the merge process to transfer the updated
customer-specific SU24 data.
He or she can create a new role from the delivered authorization data based on the SU24 data. To do this, he or she includes applications in the role
menu and completely specifies the authorizations of the role by completely filling the fields of the authorization objects.
The role allows the end users access to the system objects required for their activities. The authorization administrator completely specifies all fields of the
role so that there are no longer any empty fields.
4. The authorization administrator assigns the role to the user.
3. Steps for the User
1. The user can execute all of the applications in his or her role menu.
1.1.3.1 Editing Authorization Default Data (Development System)
Developers define, in transaction SU22, which authorization objects are required for their application. Transaction SU22 displays a list of authorization objects that
the trace has logged for the selected application. Developers need to classify these objects by assigning the authorization default status.
Procedure
1. Start the maintenance tool for authorization default data (transaction SU22.
2. Specify the applications for which you want to edit the authorization default data, and choose Execute .
3. To display the assignment of authorization objects to an application, select the application under Selection Result by double-clicking it.
4. The system displays which authorization objects the authorization trace logged in the context of this application.
The displayed list contains, among other things, objects that do not belong to your application, but which were called when testing the application. You
therefore need to classify these objects by setting the default status, to identify those that are relevant for your application.
Manually Adding Authorization Objects
If you want to include additional relevant authorization objects in the list of objects, choose the Object button and then Object Add Authorization Object .
To remove the assignment of a manually-added authorization object, select the line, choose the Object button, and then Object Remove Authorization
Object .
It is not meaningful to remove authorization objects that have been automatically assigned by the authorization trace, since hte system will always reassign these
objects.
Setting the Authorization Default Status of Objects
Authorization objects for which you have not yet maintained an authorization default status do not have an entry in the Status column.
1. To change a default status, select one or more lines on the Authorization Objects tab page, and use the Default button to choose one of the following
statuses:
No
By setting this authorization default status, developmers inform administrators that a user does not rqeuire an authorization for this object to execute the
core functionality of this application. Do not confuse this with the check indicator for transactions with which the check is deactivated. For more
information about check indicators, refer to the section Editing Check Indicators for Objects.
Yes
functionality of the application. If the administrator adds the application to a role, the Proifile Generator adds an authorization for this object in the role.
The consequence is that the Profile Generator includes an authorization for this authorization object in the role authorizations using the delivered
authorization default values.
The fields of the authorizations are predefined with the proposed values. If you do not specify any values, you can specify Yes, Without Values .
Deliver default values for the fields of the authorization object for which you know which values will be checked in customers' systems. Leave fields
with customer-specific content empty.
Yes, Without Values
functionality of the application. However, the developers cannot specify any values, since these are only determined in the customer system.
PUBLIC
Page 9 of 104

Guidelines for Setting the Default Status
Authorization objects that you explicitly check in your own code with AUTHORITY-CHECK usually receive the authorization default status Yes or
Yes, Without Values .
If users cannot use the core function of an application without a particular authorization, you need to assign the default status Yes or Yes, Without
Values for this authorization object.
If an authorization object is specified in transaction SE93 in the definition of a transaction as an additional start authorization check, you need to assign
the authorization default status Yes to this authorization object in transaction SU22. As default values for the field values, set at least the values
entered in transaction SE93.
Basis and HR authorization objects that are checked outside HR or Basis applications usually receive the authorization default status No .
The start authorization check is a special case and affects the authorization objects S_TCODE, S_START, S_RFC, and S_SERVICE. For technical
reasons, transaction SU22 always includes the start authorization object associated with an application (for example, S_TCODE for transactions). You
do not need to set the authorization default status Yes for these authorization objects. Since the Profile Generator automatically inserts a start
authorization for your application into the role, you do not need to enter the name of your application as the authorization default value. Leave the
authorization default status set to No .
Editing Authorization Default Values
You have the following options:
To display authorization objects with the default status Yes , double-click the Yes field. Alternatively, select one or more lines in edit mode, choose the
Default button and then the relevant status.
To start the trace evaluation tool, choose the Evaluate Trace button. The trace evaluation displays the recorded authorization checks including the checked
authorization values. You can copy relevant values.
You can use both the authorization and the system traces for this purpose. You can use both traces either locally or in a remote system. More information:
Maintaining Authorization Default Values Using Trace Evaluation in Transaction SU22 or SU24 or in the system by choosing the information button.
Guidelines for Setting the Default Values
For fields that describe activities or other fixed values, enter the values that the system checks during the authorization check for your application.
For authorization objects that contain the activity field ACTVT, enter only activities that the developer stored as permitted activities in the definition of the
authorization object.
Fields that describe organizational units are automatically filled with a corresponding variable, $VARIABLENNAME, that the system later fills when a role is
created. Leave this variable name unchanged.
Leave fields empty if they are to contain customer-specific data.
If you transfer values into fields that customers should really fill with their Customizing, these fields are not highlighted when maintaining roles, because they
are not empty. Customers will therefore not fill these fields with data that is appropriate for them. These authorizations are unusable for customers. Customers
will only find them cumbersome, particularly for roles with a large number of authorizations.
Never enter the asterisk (*) for full authorization. This is usually incorrect. The customer can easily assign full authorization for empty fields himself or herself
in the profile generator.
Only enter the asterisk (*) for full authorization as an authorization default if a user actually requires full authorization for the application. This is the case, for
example, if the authorization check explicitly checks for the value asterisk (*). If you do not know what values will be checked in customer systems, leave
the field empty. The Profile Generator highlights the empty field for the customer administrator during role maintenance, so that he or she can enter the
suitable value for their purposes. The asterisk (*) for full authorization, on the other hand, means that the field is not empty, and that the Profile Generator
does not highlight it during role maintenance. The customer will leave the full authorization in place, instead of entering discrete authorization values. This
means that the customer unknowingly assigns unnecessarily extensive authorizations.
In the case of authorization object fields that are not used by your application, that the system checks against DUMMY in the ABAP statement AUTHORITY-
CHECK, enter the value ' ' with quotation marks or, for fields with a length of 1, a single quotation mark (').
Never provide empty authorization defaults or default values filled with the asterisk (*) for full authorization for start authorization objects (S_TCODE,
S_START, S_SERVICE, S_RFC). This leads to dangerously extensive authorizations in the customer system. If you are not entirely sure that you need to
deliver an authorization default for one of these objects, assign the authorization default status No .
If you are not able to specify authorization default values for any field of an authorization object (for example, because the authorization object only has
Customizing fields), set the authorization default status to Yes, Without Values instead of Yes . If an authorization administrator includes your application in
a role, the Profile Generator places an authorization for this object in a role, but does not predefine any fields with a default value.
Editing Check Indicators for Objects
In the case of transactions, you can also control the authorization check with check indicators that are set for each authorization object.
1. To change a check indicator, select one or more lines on the Authorization Objects tab page, and use the Check Indicator button to choose one of the
following statuses:
Check
Default check indicator
Do not check
The authorization check for this authorization object is deactivated. The system does not check whether the user has a suitable authorization.
Applies for a particular authorization object for a transaction and means that the authorization check for this object is deactivated for this this
transaction and is therefore always successful. This means that the ABAP statement AUTHORITY-CHECK always returns sy-subrc=0, meaning
that the authorization check has no effect. The check therefore does not determine whether the user has a suitable authorization. Therefore set this
value only in exceptional cases. It is never permissible for Basis and HR authorization objects. If a transaction cannot be used without a
specific authorization, it is usually wrong to assign the check indicator Do Not Check for this authorization object. Instead, leave the check indicator
set to Check , set the authorization default status to Yes , and assign appropriate authorization default values. In this way, the users receive a
suitable authorization if an administrator adds the transaction to a role. If you cannot specify any meaningful authorization default values, set the
authorization default status Yes, Without Values .
Setting the Maintenance Mode for the Application
You can assign a maintenance mode for applications for which all default statuses and field values have been assigned for the authorization objects.
1. To do this, on the Properties tab page, choose one of the following modes in the Maintenance Mode field:
Caution
PUBLIC
Page 10 of 104

Note that if you set the mode I or O , that you do not deliver any default values with this setting. If you make an incorrect setting here, it can cause
problems for the customer when preparing role authorizations.
Empty field (normal maintenance (manual))
A (Automatic maintenance of all authorization objects)
Authorization objects that are newly assigned to the application by the authorization trace automatically receive the status No authorization default
values (previously “check”).
B (Automatic maintenance of only Basis authorization objects)
Basis authorization objects that are newly assigned to the application by the authorization trace automatically receive the status No authorization
default values (previously “check”).
I (irrelevant, application does not require any authorization default values)
It is not possible or meaningful to deliver authorization default data for the application. You therefore do not need to maintain the authorization default
data. This can be the case, for example, for very generic applications, for which the precise business purpose is not determined.
O (obsolete)
The application is obsolete. It is therefore not meaningful to deliver authorization default data for this application and you no longer need to maintain the
authorization default data.
Note
With modes A or B, the trace automatically sets newly-found authorization objects to the default status No . Set these values only for applications that
have already been delivered in several releases with no changes and for which you therefore do not expect significant changes to the authorization
default data.
1.1.3.2 Editing Authorization Default Data (Customer System)
Customers can use transaction SU24 to edit the default data delivered by SAP developers or to maintain default data for applications they have developed
themselves.
It displays a list of the authorization objects for the selected application. For SAP deliveries, it displays the SAP default data, and for customer developments, it
displays an empty list. You can modify the data delivered by SAP. You can also use the procedure below for your own developments.
Procedure
1. Start the maintenance tool for authorization default data (transaction SU24.
2. On the Application tba page, specify the applications for which you want to edit the default data, and choose Execute .
3. To display the assignment of authorization objects to an application, select the application under Selection Result by double-clicking it.
The system displays the authorization data delivered by SAP or the modified by the customer. More information: First Installation Procedure.
Comparing Data with the Data Delivered by SAP
If you have already modified authorization data in transaction SU24, you can compare it with the data delivered by SAP by choosing Compare with SAP Data . In
change mode, you can transfer the SAP default status. If the object is delivered with the authorization default status Yes , and you have maintained it with this
status, you can transfer its authorization default values.
Manually Adding Authorization Objects
If you want to include additional relevant authorization objects in the list of objects, choose the Object button and then Object Add Authorization Object .
To remove the assignment of a manually-added authorization object, select the line, choose the Object button, and then Object Remove Authorization
Object .
Adding Authorization Objects Using the Authorization Trace
You can activate an authorization trace in your system to log authorization checks that are performed by applications. For more information about these traces, refer
to Traces for Authorization Checks. To include objects from the authorization trace in the list, in change mode, choose the Object button and then Add Object
from Trace . You can evaluate the authorization trace from the local system or from a remote system.
Setting the Authorization Default Status of Objects
Authorization objects for which you have not yet maintained an authorization default status do not have an entry in the Status column.
1. To change a default status, select one or more lines on the Authorization Objects tab page, and use the Default button to choose one of the following
statuses.
No
This status indicates that a user does not require an authorization for this object in order to execute the core functionality of this application. Do not
confuse this with the check indicator for transactions with which the check is deactivated. For more information about check indicators, refer to the
section Editing Check Indicators for Objects .
Yes
This status indicates that a user requires an authorization for this object in order to execute the core functionality of this application. If the administrator
adds the application to a role, the Proifile Generator adds an authorization for this object in the role. The consequence is that the Profile Generator
includes an authorization for this authorization object in the role authorizations using the delivered authorization default values. The fields of the
authorizations are predefined with the proposed values. If you do not specify any values, you can specify Yes, Without Values . Deliver default
values for the fields of the authorization object for which you know which values will be checked. Leave fields empty if you can only specify them in
roles.
Yes, Without Values
PUBLIC
Page 11 of 104

This status indicates that a user requires an authorization for this object in order to execute the core functionality of the application. However, the object
contains only fields that can only be filled when specifying the role.
Guidelines for Setting the Default Status
Authorization objects that you explicitly check in your own code with AUTHORITY-CHECK usually receive the authorization default status Yes or
Yes, Without Values .
If users cannot use the core functionality of an application without a particular authorization, you need to assign the default status Yes or Yes,
Without Values for this authorization object.
If an authorization object is specified in transaction SE93 in the definition of a transaction as an additional start authorization check, you need to assign
the authorization default status Yes to this authorization object in transaction SU24. As default values for the field values, set at least the values
entered in transaction SE93.
Basis and HR authorization objects that are checked outside HR or Basis applications usually receive the authorization default status No .
The start authorization check is a special case and affects the authorization objects S_TCODE, S_START, S_RFC, and S_SERVICE. If you transfer
authorization objects from the authorization trace, the start authorization object for an application is also always transferred (that is, for example,
S_TCODE for transactions). You do not need to set the authorization default status Yes for these authorization objects. Since the Profile Generator
automatically inserts a start authorization for your application into the role, you do not need to enter the name of your application as the authorization
default value. Set the authorization default status to No .
Editing Authorization Default Values
To display authorization objects with the default status Yes , double-click the Yes field. Alternatively, select one or more lines in edit mode, choose the
Default button and then the relevant status.
To start the trace evaluation tool, choose the Evaluate Trace button. The trace evaluation displays the recorded authorization checks including the checked
authorization values. You can copy relevant values. You can use both the authorization and the system traces for this purpose. You can use both traces
either locally or in a remote system. More information: Maintaining Authorization Default Values Using Trace Evaluation in Transaction SU22 or SU24 or in the
system by choosing the information button in transaction SU22.
Guidelines for Setting the Default Values
For fields that describe activities or other fixed values, enter the values that the system checks during the authorization check for your application.
For authorization objects that contain the activity field ACTVT, enter only activities that the developer stored as permitted activities in the definition of the
Fields that describe organizational units are automatically filled with a corresponding variable, $VARIABLENNAME, that the system later fills when a role is
created. Leave this variable name unchanged.
Leave fields empty if you only want to fill them when specifying a role.
In the case of authorization object fields that are not used by your application, that the system checks against DUMMY in the ABAP statement AUTHORITY-
CHECK, enter the value ' ' with quotation marks or, for fields with a length of 1, a single quotation mark (').
If you are not able to specify authorization default values for any field of an authorization object (for example, because the authorization object only has
Customizing fields), set the authorization default status to Yes, Without Values instead of Yes . If an authorization administrator includes your application in
a role, the Profile Generator places an authorization for this object in a role, but does not predefine any fields with a default value.
Editing Check Indicators for Objects
In the case of transactions, you can also control the authorization check with check indicators that are set for each authorization object.
1. To change a check indicator, select one or more lines on the Authorization Objects tab page, and use the Check Indicator button to choose one of the
following statuses:
Check
Do not check
The authorization check for this authorization object is deactivated. The system does not check whether the user has a suitable authorization.
Applies for a particular authorization object for a transaction and means that the authorization check for this object is deactivated for this this
transaction and is therefore always successful. This means that the ABAP statement AUTHORITY-CHECK always returns sy-subrc=0, meaning
that the authorization check has no effect. The check therefore does not determine whether the user has a suitable authorization. Therefore set this
value only in exceptional cases. It is never permissible for Basis and HR authorization objects. If a transaction cannot be used without a
specific authorization, it is usually wrong to assign the check indicator Do Not Check for this authorization object. Instead, leave the check indicator
set to Check , set the authorization default status to Yes , and assign appropriate authorization default values. In this way, the users receive a
suitable authorization if an administrator adds the transaction to a role. If you cannot specify any meaningful authorization default values, set the
authorization default status Yes, Without Values .
1.1.3.3 Maintaining Authorizations in SAP Example Roles
SAP development delivers a role that describes an activity in the enterprise, with which the user can perform his or her tasks in the system. The role must fulfill
the following criteria:
For the user to be able to execute the necessary applications (transactions, Web Dynpro applications, and so on), SAP development muts include these in
the role menu.
The role's authorizations are complete enough that the user can execute the core functionality of all applications. This means that the role contains
authorizations for all of the necessary authorization objects. It does not mean that all authorizations are fully specified. Some fields can remain empty for the
customers to fill later with their specific values.
When creating the example role, take the guidelines for segregation of duties into account.
This procedure does not apply to the manual maintenance of roles for technical users.
Procedure
PUBLIC
Page 12 of 104

1. Start transaction PFCG and create a single role. Assign the role to your package. This is necessary for translation.
2. Document the role by entering the following details:
Describe the activiity in a business process for which the role is intended.
Describe the steps of this activity.
3. Include the applications (transactions, Web Dynpro applications, and so on) associated with the activity in the role menu.
4. In change mode, on the Authorizations tab page, choose Change Authorization Data .
The Profile Generator then automatically generates the start authorizations for the applications contained in the menu. The Profile Generator also generates
authorizations from the authorization default values of the contained applications.
For authorization objects with the value Yes , it generates authorizations from the authorization default values.
For authorization objects with the value Yes, Without Values , it generates authorizations without values.
5. Check whether you can maintain additional values, for example, whether the role's purpose means that it requires a more specific specification of the
authorization values than is possible in the authorization default values. This can be the case if the authorization default values were kept general to cover
different functions but the role is for a specific function.
The trace function, which you can call by choosing the Trace button, supports you in maintaining the authorization values.
6. Transfer the authorization data.
7. On the Authorizations tab page, delete the profile name, and choose Save .
8. On the initial screen of transaction PFCG, transport the role by choosing the Transport Role button. Deliver the role from the Customizing client.
Caution
If you want to make further changes to the role menu or the authorization default values later, start the expert mode on the Authorizations tab page. Choose
Read old status and merge with new data .
More Information
More information about creating roles: Creating Single Roles.
1.1.3.4 Maintaining Authorizations in Roles for Productive Use
The role describes the user's activity in the company and contains all applications that the user requires for this activity.
Procedure
1. The authorization administrator creates a role. He or she has the following options when doing so:
He or she can copy a delivered SAP role (example role) into the customer namespace and then perform the merge process to transfer the updated
customer-specific SU24 data.
He or she can create a new role from the delivered authorization data based on the SU24 data. To do this, he or she includes applications in the role
menu and completely specifies the authorizations of the role by completely filling the fields of the authorization objects. The trace function, which you
can call by choosing the Trace button, supports you in maintaining the authorization values. More information: Maintaining Authorization Fields Using
Trace Evaluation in Transaction PFCG.
More information about creating roles: Creating Single Roles.
1.1.3.5 Trace for Authorization Checks
You can use a system trace or an authorization trace to record authorization checks and their values. This function supports you when maintaining authorization
default values (transactions SU22 and SU24) and when maintaining authorization data for roles (transaction PFCG).
The following traces are available:
Authorization trace
Long-term trace that collects data across clients and user-independently and stores it in the database. During the execution of a program, as soon as the
trace finds an authorization check that has not yet been recorded in connection with the current application, it creates a corresponding entry in the trace
database table. This means that you need to test the application as completely as possible to obtain meaningful trace data. To be able to evaluate the trace,
you need to activate it (more information: SAP Note 543164) and execute the significant actions (locally or in the target system).
System trace (transaction ST01 or STAUTHTRACE)
Short-term trace that collects authorization data client-dependently and only on the current application server. More information: Using the System Trace to
Record Authorization Checks (Transaction STAUTHTRACE).
More Information
Maintaining Authorization Default Values Using Trace Evaluation in Transaction SU22 or SU24
Maintaining Authorization Fields Using Trace Evaluation in Transaction PFCG
1.1.3.5.1 Maintaining Authorization Default Values Using Trace
Evaluation in Transaction SU22 or SU24
You are editing authorization default values in a development system with transaction SU22 or in a customer system with transaction SU24.
PUBLIC
Page 13 of 104

Procedure
1. Start the trace evaluation tool by choosing the Trace button.
In the dialog box, the authorization object that you selected in the previous view (by default, the first object for the application) is displayed together with its
default status and values of all of the fields. You can use the arrow keys or the input help to display the other authorization objects for the application.
2. Select the authorization object and the corresponding default status. You can only maintain values if the default status is Yes .
3. To transfer relevant data from a trace for this authorization object, choose the Evaluate Trace button.
You can start the authorization trace either in the current system by choosing Authorization Trace Local or a remote system by choosing
Authorization Trace Target System .
You can start the system trace (transaction ST01 or STAUTHTRACE) either in the current system by choosing System Trace Local or in the
target system by choosing System Trace Target System . Then perform the significant actions for the authorization checks for the object.
For the local system trace, when you choose the Trace button, a dialog box appears, containing buttons with which you can control the trace.
1. To display trace data that exists, choose return, or the Evaluate button.
2. To start the trace, choose Activate Trace .
3. Execute the application as fully as possible in a separate session on the same applicaiton server.
4. Deactivate the trace by choosing Deactivate Trace . Otherwise, it continues to collect data until the trace file overruns.
5. Display the collected trace data by choosing return or the Evaluate button.
In the case of the system trace in a target system, only the Evaluate button is available in the dialog box. Before you can evaluate data for the target
system, you need to start the trace in the target system specified in the RFC destination, execute the application as fully as possible on the same
application server as the one the trace is running on, and then end the trace .
4. To transfer the field values of an authorization object from the trace, select the field or the entire row or column containing the values to be transferred. Then
choose the Apply button.
Additional Functions
You can use the Callpoints button to find the points in the program at which the authorization check is performed with this object, field, and value. The
authorization trace records this combination only once, even if it is included multiple times in different programs.
1.1.3.5.2 Maintaining Authorization Fields Using Trace
Evaluation in Transaction PFCG
You are editing authorizations for a role with transaction PFCG.
Procedure
1. Choose the Trace button.
A dialog box appears, showing the first authorization. You can use the arrow keys or the input help to display the other authorizations for the application.
2. Select the authorization that you want to edit.
You cannot change the start authorization objects with standard authorizations (S_START, S_TCODE, S_SERVICE, S_RFC).
3. To transfer relevant data from a trace for this authorization object, choose the Evaluate Trace button.
You can evaluate the authorization trace, either by choosing Authorization Trace Local to analyze the trace for the current system, or by
choosing Authorization Trace Target System to analyze the trace of a remote system.
You can evaluate the system trace (transaction ST01 or STAUTHTRACE), either by choosing System Trace Local to analyze the trace for the
current system, or by choosing System Trace Target System to analyze the trace of a remote system.
You then start the trace and perform the actions that are relevant for the authorization check for the object.
For the local system trace, a dialog box appears, containing buttons with which you can control the trace.
1. To display trace data that exists, choose return, or the Evaluate button.
2. To start the trace, choose Activate Trace .
4. Deactivate the trace by choosing Deactivate Trace .
5. Display the collected trace data by choosing return or the Evaluate button.
In the case of the system trace in a target system, only the Evaluate button is available in the dialog box. Before you can evaluate data for the target
system, you need to start the trace in the target system specified in the RFC destination, execute the application as fully as possible on the same
application server as the one the trace is running on, and then end the trace. The system, the client, and the server are displayed as a heading
above the trace result.
4. To transfer the field values of an authorization object from the trace, select the field or the entire row or column containing the values to be transferred. Then
choose the Apply button.
Additional Functions
You can use the Callpoints button to find the points in the program at which the authorization check is performed with this object, field, and value. The
authorization trace records this combination only once, even if it is included multiple times in different programs.
1.1.3.5.3 Maintaining Role Menus Using Trace Evaluation in
Transaction PFCG
You can enhance the role menu with applications, which you collect in the system trace (transaction ST01 or STAUTHTRACE). The system trace logs the start
authorization checks which occur when applications are started during the trace. You can import these applications into the role menu.
The system evaluates the following objects:
PUBLIC
Page 14 of 104

S_TCODE
Transactions
S_SERVICE
External services or Web services
S_RFC
Function modules
Note
The system checks function groups first. Only if these authorization checks fail, does the system check function modules. The menu evaluation tool only
evaluates objects from function modules and not from function groups.
Note
The system trace is a short term trace, which is dependent on the server and client, and only collects authorization data on the current application server.
Prerequisites
You have performed the system trace for your applications. Use transaction ST01 or STAUTHTRACE and execute in a separate session the applications, for
which you want to log authorization data.
If the trace for your applications occurred on another application server, you must configure an RFC destination for the target system or application server, to
transfer the trace results to transaction PFCG.
Procedure
1. Edit a role in transaction PFCG.
2. On the Menu tab, choose Copy Menus Import from Trace .
3. Choose the Evaluate Trace pushbutton.
To transfer trace data from the current application server, choose System Trace (ST01) Local .
To transfer trace data from a remote application server or system, choose System Trace (ST01) Target System .
4. Select the trace results by entering the time frame, the user, who conducted the trace, and, if required, the target system.
5. Choose the Evalute pushbutton.
6. Select rows and choose the Transfer pushbutton.
7. Enter the data in the SAP menu.
Choose the appropriate pushbutton.
Add as List
Add as SAP Menu
8. Save your entries.
1.1.3.5.4 Using the System Trace to Record Authorization
Checks (Transaction STAUTHTRACE)
The trace in transaction STAUTHTRACE is the detailed version of the traces available using the trace button in transaction SU22. It works in the same way as the
System Trace (transaction ST01). However, it only evaluates authorization checks.
Procedure
1. If necessary, set Trace Only for User and start the trace by choosing Activate Trace .
The system writes the trace data in the current trace file.
3. Deactivate the trace by choosing Deactivate Trace .
4. You can optionally restrict the results display with the options under Restrictions .
If you choose Filter Duplicate Entries , identical authorization checks (consisting of the same combination of authorization object, fields, and values) that the
trace recorded at two different times are only displayed once.
5. Choose Evaluate .
Result
You can use the standard ALV functions to filter the read trace records in the result list. The following functions are also available:
Display callpoints in ABAP programs
You can use the Callpoints button to find the points in the program at which the authorization check is performed with this object, field, and value.
Display authorization object
Documentation for authorization object
Display user
1.2.3.5 Glossary
PUBLIC
Page 15 of 104

The table below lists the authorization elements that you require when preparing a delivery of authorization default data.
Elements of Authorization Data Maintenance
Element Allowed Values Comment
Authorization Not applicable Manifestation of an authorization object, that is, a
combination of permissible values for each authorization
field of the authorization object. The combination
determines the activities with which a user can access
certain data.
Authorization Object Not applicable An authorization object consists of up to ten authorization
fields, which the system checks with an AND linkage.
Authorization objects are organized in classes. An object
class is a logical combination of authorization objects and
corresponds, for example, to an application (financial
accounting, Human Resources, and so on). You can use
transaction SU21 to edit authorization objects.
Authorization Field Refer to authorization default value Smallest unit in an authorization object. An authorization
field either represents data, such as a key field in a
database table, or activities, such as Read or Create.
Activities are specified as abbreviations, which are stored
in the database table TACT and, for customer-specific
abbreviations, TACTZ.
Authorization default value Any number of single values
Value range
All values
An empty field
Specified value for authorization field.
Authorization default status No
If the administrator adds the application to a role,
the Proifile Generator does not place an
authorization in the role.
Yes
the Proifile Generator places an authorization in the
role.
Yes, Without Values
the Proifile Generator places an empty
authorization in the role.
Note
Since customers need to define this empty
authorization themselves, only choose this
status instead of Yes if you are not able to
specify any meaningful authorization default
values.
If an authorization administrator includes the applicatoin in
the menu when creating or changing the role, the Profile
Generator checks for each object whether it has an
authorization default status. If this is the case, the Profile
Generator includes an authorization in the role.
Check indicator Check
Do not check
The authorization check for this authorization object
is deactivated. The system does not check whether
the user has a suitable authorization.
For transactions, you can also control the authorization
check with check indicators that are set for each
Maintenance mode Empty field (normal maintenance (manual))
A (Automatic maintenance of all authorization
objects)
Authorization objects that are newly assigned to the
application by the authorization trace automatically
receive the status No authorization default values
(previously “check”).
B (Automatic maintenance of only Basis
authorization objects)
Basis authorization objects that are newly assigned
to the application by the authorization trace
automatically receive the status No authorization
default values (previously “check”).
I (irrelevant, application does not require any
authorization default values)
It is not possible or meaningful to deliver
authorization default data for the application. You
therefore do not need to maintain the authorization
default data. This can be the case, for example, for
very generic applications, for which the precise
business purpose is not determined.
O (obsolete)
The application is obsolete. It is therefore not
meaningful to deliver authorization default data for
this application and you no longer need to maintain
the authorization default data.
The Maintenance Mode indicaltor is a special attribute of
an application. You use it to specify how the authorization
default data (SU22 data) of the application is maintained.
PUBLIC
Page 16 of 104

Maintenance status Maintained (green traffic light): The authorization
default data has been maintained.
Unmaintained (red traffic light): The authorization
data for the application has not been maintained, or
there is another priority 1 error. This error occurs,
for example, if Default Status has not yet been
maintained for one or more authorization objects.
Maintaing with Warning (yellow traffic light): Data
has been maintained but there was at least one
priority 2 error during the check.
The maintenance status of applications shows whether the
authorization default data for an application is correctly
maintained.
Configuration of User and Role Administration
The following sections describe how to configure individual elements of user and role administration:
● First Installation Procedure
Before you use an ABAP system productively, you need to fulfill the prerequisites for administering users. In particular, this includes the following tasks:
○ Setting Up User and Authorization Administrators
This section describes how you can divide the user administration tasks among a number of administrators to ensure task separation when assigning
authorizations.
○ Setting Up the Role Administration Tool
In addition to the setting-up of the tool, this section also describes how to handle authorization checks.
○ Logon and Password Security in the ABAP-System
This section contains the password rules, the logon and password profile parameters, and the Customizing switches for generated passwords.
○ Protecting Special Users
This section describes what you can do during the installation to protect users that already exist against misuse.
● Role Administration
This section describes which functions are available to the administrator for role administration, and the indirect assignment of roles using the organizational
structure.
● Central User Administration
This section describes how you can centrally set up and operate user administration for an ABAP system group.
● Central Repository for Personalization Data
This section describes how to set up a central repository for all user- and role-specific data.
● Directory Services
This section describes how to set up an LDAP-compatible directory service and data synchronization between this and the ABAP system.
● Upgrade Procedure
This section describes how to changeover the role administration with the profile generator and general postprocessing when upgrading.
1.2.1 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.
PUBLIC
Page 17 of 104

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
● Protecting Special Users
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
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
PUBLIC
Page 18 of 104

(transaction PFUD, Performing a profile
comparison of the user master comparison)
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.
a. Enter a name in the Role field in role administration (transaction PFCG) and choose Create Role .
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.
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
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.
1.2.1.1.1 Configuring User Group as Required for User Master
Records
Users with no user group for authorization assigned can be changed by any user administrator in the system. It is impossible to segregate responsibilities for
such users. To avoid such situations, make the user group for authorization checks a required entry for new users. With this customizing option, you also define
default user group, which the system automatically enters when you create a user.
This customizing is client-specific.
Prerequisites
You have created a default user group.
You have added the default user group to the authorization roles of the appropriate user administrators.
Procedure
1. Ensure that all existing users in the system have a user group for authorization checks assigned.
Use User Maintenance: Mass Changes (transaction SU10) to find users with an empty Group for Authorization field and assign appropriate groups.
Caution
Once the user group is required, if a user is missing a user group for authorization checks, you cannot change, lock, set the initial password, or even
delete the user.
2. Maintain the USER_GRP_REQUIRED parameter with the name of the default user group in table USR_CUST with Maintain Table Views (transaction SM30).
To assign a user-specific default user group to user administrators, maintain the user parameter S_USER_GRP_DEFAULT for the user administrators.
More Information
SAP Note 1663177 SU01: User group as required entry field
Interaction of Required User Groups and Central User Administration
PUBLIC
Page 19 of 104

1.2.1.1.2 Interaction of Required User Groups and Central User
Administration
You can customize your SAP NetWeaver Application Server ABAP to require user groups for authorization checks for user master records. If the central system of
the Central User Administration (CUA) does not assign user groups, but the child system of the CUA requires user groups, this discrepancy leads to the
behaviors described in the following table.
Reaction of Child System of the CUA When User Groups for Authorization are Required But Not Assigned
Action of Central System of the CUA Reaction of Child System of the CUA
The central system of the CUA tries to create users without user groups in child system
of the CUA.
The child system creates the user and assigns the default user group that is valid for the
RFC user. In addition, the child system returns an error message in Log Display for
Central User Administration (transaction SCUL) stating that the user from the central
system of the CUA must be assigned a user group for authorization checks. This
reaction occurs regardless of how the distribution parameters are maintained for user
groups for authorization checks in transaction SCUM.
The central system of the CUA tries to change users without user groups for
authorization checks in a child system of the CUA and the distribution parameter for user
groups for authorization checks is set to Global or Redistribution.
The child system rejects the changes and returns a corresponding error message in Log
Display for Central User Administration (transaction SCUL).
More Information
Configuring User Group as Required for User Master Records
1.2.1.1.3 Enabling Movement Activity for S_USER_GRP
By default, SAP NetWeaver Application Server ABAP checks the S_USER_GRP authorization object for activity 01 Create when you try to move a user from
one user group for authorization checks to another. To create a distinction between the activity of creating a new user in a user group for authorization checks from
moving a user to a new user group for authorization checks, enable activity 50 Move for S_USER_GRP.
This customizing is client-specific.
Procedure
1. Set the CHECK_MOVE_4_CNG_GRP parameter to YES in the USR_CUST table with Maintain Table Views (transaction SM30).
2. Adjust the authorization roles of the appropriate user administrators.
More Information
SAP Note 1663177 SU01: User group as required entry field
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.
Defining the Scope of Authorization Checks
When SAP system transactions are executed, a large number of Authorization Objects are often checked, since the transaction calls other work areas in the
background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users
having more authorization than they strictly need. It also leads to an increased maintenance workload.
If you are using the Profile Generator, you can reduce the scope of the authorization checks (transaction SU24). When the Profile Generator generates a profile, it
selects all of the authorizations associated with an activity. The generated profiles are not always complete (especially in older releases of the Profile Generator),
meaning that you may have to add authorizations that are not contained in the profiles manually. (This is mainly the case with programs that call other programs,
where the subprogram requires additional authorizations.) To simplify the administrative tasks with the Profile Generator, you could consider reducing the scope of
the authorization checks in cases such as this.
If a user in PA calls a program that in turn calls an HR routine, the user requires the corresponding HR authorizations. If you have not installed the
HR components, you may not want to assign all of the HR authorizations required for the PA report to the PA users. In this case, you can
deactivate the authorization checks for HR authorizations in the PA transactions.
For an authorization check to be executed, it must be included in the source code of a transaction and must not be explicitly exempt from the check.
PUBLIC
Page 20 of 104

You can suppress authorization checks without changing the program code, as check indicators control authorization checks. You also use check indicators to
control which objects appear in the Profile Generator and which field values are displayed there for editing before the authorization profiles are generated
automatically.
SAP supplies defaults for check indicator and authorization field values, which you should copy. You can then edit these copied defaults. You should only do this
once you have defined your company's authorization concept.
You can reduce authorization checks within a transaction or exclude an authorization object globally from the check. More information:
● Preparatory Steps
● Globally Deactivating Authorization Checks
● Reducing Authorization Checks in Transactions
● Editing Templates for General Authorizations
● Comparing Check Indicators and Field Values After a Release Upgrade
Authorization objects from the Basis (S_*) and Human Resource Management applications (P_*, PLOG) cannot be excluded from authorization
checks. The field values for these objects are always checked.
For parameter or variant transactions, you cannot exclude authorization objects from a check directly, only using the authorization objects in
the corresponding transaction.
Advantages of the Restricted Scope of Authorization Checks in SAP Systems
As explained above, by reducing the scope of authorization checks, you simplify the administration tasks connected with the Profile Generator. You should
carefully weigh-up which authorization checks you want to suppress. If you deactivate authorization checks, you permit users to perform tasks for which they are
not explicitly authorized. You should possibly consider reducing the scope of authorization checks in the following cases:
● You do not use the authorization object connected with the authorization check (as in the example above).
● The authorization check for the object S_TCODE still protects the core transaction. (Note, however, that the S_TCODE authorization check only provides very
general protection. This alone is not a reason to suppress an authorization check.)
● You want to avoid permitting all values for all authorization fields in the authorization object.
Instead of assigning the asterisk (*) as the placeholder value, you can suppress authorization checks for specific objects in specific transactions. You can
use a standard authorization check for the same authorization object for other transactions.
If you reduce the scope of authorization checks, you allow users to perform activities without ensuring that the users have the required
authorization. This can have undesired consequences. Consider very carefully before suppressing authorization checks.
1.2.1.2.1.1 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.
Globally Deactivating Authorization Checks
PUBLIC
Page 21 of 104

As of SAP R/3 4.5, you can globally suppress authorization checks for individual authorization objects. If you use this option, the system does not perform any
authorization checks at all for the specified objects. If you are using the Profile Generator, the option significantly reduces authorization maintenance. The Profile
Generator does not enter any authorization data for deactivated authorization checks in profiles. You also do not have to postprocess the authorization data after an
upgrade for transactions for which you have globally deactivated the corresponding authorization objects.
If you suppress authorization checks, you allow users to perform activities without ensuring that the users have the required authorization. This can
have undesired consequences. Consider very carefully before suppressing authorization checks for authorization objects.
To suppress authorization checks for specific authorization objects, set the profile parameter auth/object_disabling_active to the value "Y". You then
select the affected authorization objects using transaction SU25 (or transaction AUTH_SWITCH_OBJECTS). [You deactivate authorization objects in the tree
display by selecting the checkbox to the left of the object. The deactivated authorization objects are then displayed in red. Then activate your settings (only then
are the authorization checks ignored in the system).]
Note that:
· You cannot suppress authorization checks for authorization objects that belong to Basis components or to Human Resources (HR).
· You require authorization for the object S_USER_OBJ to be able to suppress authorization checks for authorization objects. We recommend that you assign the
relevant activities (saving, activating, or transporting) to different administrators.
· If you reactivate previously suppressed authorization checks for authorization objects, you must postprocess the authorization data for the relevant roles.
These authorization objects are not contained in any role. In this case, call transaction PCFG and choose Read old status and compare with the new data on
the tab page Authorizations in expert mode to generate profiles. Maintain missing authorization values and then regenerate the profile.
· When transporting the settings (in transaction AUTH_SWITCH_OBJECTS), for security reasons, the system does not transport the active version of the
settings, but rather the saved version. You need to explicitly activate these in the target system ( Authorization Objects → Activate Data ).
To save or activate deactivated authorization checks for authorization objects, you require authorization for the object S_USER_OBJ. For security
reasons, you should assign the authorizations for saving and for activating deactivated authorizations checks for authorization objects to different
users. It makes sense to deactivate the authorization checks only if at least two people agree on this.
Reducing Authorization Checks in Applications
You can display the authorization objects associated with each application. You can also exclude any of these authorization objects individually from the
authorization check. You should have a thorough knowledge of this application and its context before you start.
To do this, proceed as follows:
1. Start transaction SU24.
2. On the Application tab page, select the type of application, and fill out the other fields displayed depending on your entry in this field.
A result screen appears, with a table on the left that provides an overview of the applications that match your selection criteria.
3. If you double-click one of the applications, a second table is displayed on the right. This table contains the assignment of authorization objects for the selected
application. The check status of the objects is displayed here. For each object, the check status and the status of the authorization default values for the
object are displayed.
The check status of the object shows whether an authorization check takes place using the object in question, if this authorization check takes place within
the selected application. The check status should always be check . Only set do not check in exceptional cases, if the selected application is a
transaction and the authorization object is neither a Basis nor an HR authorization object. If you are not absolutely certain that do not check is correct for your
transaction, leave the check indicator set to check .
4. Set the check indicator to do not check with the Check Indicator button to suppress the check. See the note below regarding parameter transactions.
5. Save your settings.
The default values and the check indicator of an authorization object are important for the role administration tool. These values are only displayed
for changing in the Profile Generator if you have set the check indicator to check with default Yes (previously PP).
If you have set authorization checks for your own applications, you need to enter the authorization objects which you have used into Transaction
SU24 manually and also maintain the check indicators.
For parameter and variant transactions, you cannot exclude authorization objects from a check directly, only using the authorization objects in
the corresponding transaction.
If you want to set the check indicator of parameter Transaction XYZP to Do not check , you need to change the check indicator for the target Transaction
XYZE. You can obtain the name of the actual transaction XYZE in transaction SE93. To do this, specify the name of the parameter transaction there and
choose Display .
If the authorization object for parameter Transaction XYZP is set to P (check) but under the target transaction it is set to check with default Yes
(previously PP ), the field values which have been maintained for XYZE will be proposed in the Profile Generator. If the authorization object is also set to
check with default Yes (previously PP ) in XYZP, the field values maintained for XYZP will be proposed in the Profile Generator, and the entries for
XYZE will be overridden.
When using transaction SU24 for parameter transactions you can only maintain or overwrite the field values of the target transaction.
1.2.1.2.1.4 Searching for Deactivated Authority Checks
Use
Use this procedure for searching for authority checks that have been deactivated using the transaction SU24.
PUBLIC
Page 22 of 104

User and role administration of as abap

User and role administration of as abap

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to User and role administration of as abap

Similar to User and role administration of as abap (20)

User and role administration of as abap