S4H - 876 Authorization Concept Template - SAP S4HANA Cloud, Private Edition

SAP Customer
Authorization Concept Template

SAP S/4HANA Cloud, private edition
V.1.0 - May 1, 2021
DOCUMENT HISTORY
Version Date Change

1.0 2021.05.01 Initial Version
SAP Customer - Authorization Concept Template for SAP S/4HANA Cloud, private edition Page 1 of 65
TABLE OF CONTENTS
1. OBJECTIVES.....................................................................................................................................................5
1.1. OBJECTIVES OF AN AUTHORIZATION CONCEPT.............................................................................................5
1.2. OUT OF SCOPE................................................................................................................................................5
1.3. TARGET GROUPS............................................................................................................................................5
1.4. PHILOSOPHY OF AN AUTHORIZATION CONCEPT............................................................................................6
2. COMPONENTS OF AN AUTHORIZATION CONCEPT............................................................................7
2.1. AUTHORIZATIONS...........................................................................................................................................7
2.2. AUTHORIZATION OBJECT...............................................................................................................................7
2.3. OBJECT CLASS................................................................................................................................................8
2.4. AUTHORIZATION PROFILE..............................................................................................................................8
2.5. APPLICATIONS................................................................................................................................................8
2.5.1. Transaction (S_TCODE)........................................................................................................................8
2.5.2. OData Service (S_SERVICE).................................................................................................................8
2.5.3. Web Dynpro Application (S_START).....................................................................................................8
2.5.4. Remote Function Call (S_RFC).............................................................................................................9
2.6. FIORI SPECIFIC COMPONENTS (FRONT-END).................................................................................................9
2.6.1. Fiori Launchpad (FLP) Catalog............................................................................................................9
2.7. SINGLE ROLES................................................................................................................................................9
2.8. COMPOSITE ROLES.........................................................................................................................................9
2.9. USER MASTER RECORD...............................................................................................................................10
3. STRUCTURE OF THE SAP SYSTEM LANDSCAPE.................................................................................10
3.1. THE 3 TIER SYSTEM LANDSCAPE.................................................................................................................10
3.2. FRONT-END & BACK-END SERVER DEFINITION..........................................................................................10
3.3. DIFFERENT AUTHORIZATIONS IN THE 3-TIER SYSTEM LANDSCAPE............................................................11
4. GUIDELINES FOR SETTING-UP AUTHORIZATIONS...........................................................................12
5. LIMITS OF AN AUTHORIZATION CONCEPT........................................................................................13

5.1. AUTHORIZATION CHECK AND AUTHORIZATION TRACE..............................................................................13
5.2. ADDITIONAL IMPLEMENTATION OF AUTHORIZATION CHECKS IN CUSTOMER APPLICATIONS...................14
5.3. ADDITIONAL IMPLEMENTATION OF AUTHORIZATION CHECKS IN SAP STANDARD APPLICATIONS............14
6. NAMING CONVENTIONS FOR AUTHORIZATION ENTITIES............................................................15
6.1. NAMING CONVENTIONS FOR THE USER ID (FOR INTERNAL AND EXTERNAL USERS).................................15
6.2. NAMING CONVENTIONS FOR USER GROUPS................................................................................................16
6.3. NAMING CONVENTIONS FOR COMPOSITE ROLES.........................................................................................17
6.4. NAMING CONVENTIONS FOR SINGLE ROLES................................................................................................18
6.5. NAMING CONVENTION OF AUTHORIZATION PROFILES................................................................................20
6.6. NAMING CONVENTIONS FOR CUSTOMERS APPLICATIONS...........................................................................21
6.7. NAMING CONVENTIONS FOR CUSTOMER TABLES OR AUTHORIZATION GROUPS........................................22
7. CRITICAL AUTHORIZATIONS AND SYSTEM FUNCTIONS...............................................................23
7.1 ACCESS TO SAP STANDARD ROLES AND PROFILES.....................................................................................23
7.2. SAP STANDARD USERS................................................................................................................................23
7.3. CRITICAL FUNCTIONS...................................................................................................................................24
7.3.1. Restrictions of Application Execute Authorizations.............................................................................25
7.3.2. Generic Table Access...........................................................................................................................25
7.3.3. Analysis (Report) Authorizations.........................................................................................................26
7.3.4. Download of Data................................................................................................................................27
7.3.5. Spool and Print Out Control................................................................................................................27
7.3.6. Background Processing........................................................................................................................28
7.3.7. Development Authorizations................................................................................................................28
7.3.8. Customizing Authorizations.................................................................................................................28
7.3.9. System and Client Settings...................................................................................................................29
8. RESPONSIBLE PERSONS FOR THE IMPLEMENTATION OF AN AUTHORIZATION CONCEPT
.................................................................................................................................................................................30
8.1. USER ADMINISTRATION (CREATION AND MAINTENANCE OF USERS)...........................................................30
8.2. AUTHORIZATION ADMINISTRATION (MAINTENANCE OF SINGLE AND COMPOSITE ROLES)........................31
8.3. AUTHORIZATION COORDINATION (SPECIFICATION OF THE DEPARTMENT AUTHORIZATION REQUIREMENTS)
............................................................................................................................................................................31
8.4. DATA OWNER...............................................................................................................................................31
9. GUIDELINES FOR USER MASTER RECORDS........................................................................................32
9.1. USER TYPES.................................................................................................................................................32
9.1.1. Dialog Users (Type Dialog).................................................................................................................32
9.1.2. System Users (Type System).................................................................................................................32
9.1.3. Communication Users (Type Communication)....................................................................................32
9.1.4. Service Users (Type Service)................................................................................................................33
9.1.5. Reference Users (Type Reference).......................................................................................................33
9.2. TRAINEES.....................................................................................................................................................33
9.3. EXTERNAL USERS........................................................................................................................................34
9.4. EMERGENCY USER SAPRES.......................................................................................................................34
10. SYSTEM PARAMETER SETTINGS & SECURITY POLICIES............................................................35
10.1. PARAMETERS TO CONTROL THE LOGIN AND PASSWORD PROTECTION.....................................................35
10.1.1. Password Rules..................................................................................................................................35
10.1.1.1. Overview of the SAP standard Rules for Passwords.......................................................................35
10.1.1.2. Password Length.............................................................................................................................35
10.1.1.3. Minimum Number of Digits in Passwords......................................................................................36
10.1.1.4. Minimum Number of Letters in Passwords.....................................................................................36
10.1.1.5. Minimum Number of Lowercase Letters in Passwords...................................................................36
10.1.1.6. Minimum Number of Capital Letters in Passwords........................................................................36
10.1.1.7. Minimum Number of Special Characters in Passwords.................................................................37
10.1.2. Password Changes.............................................................................................................................37
10.1.2.1. Number of Different Characters: Old/New Password....................................................................37
10.1.2.2. Size of Password History.................................................................................................................37
10.1.2.3. Password Must Be Compliant With Current Password Rules........................................................38
10.1.2.4. Password Change Obligation for Single Sign-On (SSO)................................................................38
10.1.3. Logon Restriction...............................................................................................................................38
10.1.3.1. Password Validity Period................................................................................................................38
10.1.3.2. Waiting Time Between Two Password Changes.............................................................................39
10.1.3.3 Password Validity Period of Unused Initial Passwords..................................................................39
10.1.3.4. Validity Period of Unused Productive Passwords (Manual Logon)...............................................39
10.1.3.5. Password Lock................................................................................................................................40
10.1.3.6. Automatic Unlocking of Users........................................................................................................40
10.1.3.7. Restricted Logon to the SAP NetWeaver Application Server..........................................................40
10.1.4. SAP GUI Rules...................................................................................................................................41
10.1.4.1. Multiple Logon................................................................................................................................41
10.1.4.2. Exception Users for the Multiple Logon Lock................................................................................41
10.1.4.3. Logon Failures................................................................................................................................41
10.1.4.4. Automatic Logout............................................................................................................................41
10.1.5. Others.................................................................................................................................................42
10.1.5.1. Define the Properties of SAP*........................................................................................................42
10.1.5.2. Activation of the Security Audit Log...............................................................................................42
10.1.5.3. Define the Character Set Used for Passwords................................................................................43
10.1.5.4. Downward Compatibility of Passwords..........................................................................................44
10.1.5.5. System Standard Clients..................................................................................................................45
10.1.5.6. Possible Logon Languages..............................................................................................................45
10.1.5.7. Standard Logon Language..............................................................................................................45
10.2. PARAMETERS TO CONTROL AUTHORIZATION CHECKS..............................................................................46
10.2.1. Deactivation of Authorization Checks................................................................................................46
10.2.2. Updating the Table USOBX...............................................................................................................46
10.2.3. Authorization Checks SU53 and SU56...............................................................................................46
10.2.4. Number of SU53 Shared Buffer Entries per Work Process...............................................................47
10.2.5. Switching off Authorization Checks for Authorization Objects.........................................................47
10.2.6. Authorization Check at RFC..............................................................................................................47
10.2.7. User-Specific Long-Term Authorization Trace..................................................................................48
10.2.8. Controls the Authority Check During Call Transaction....................................................................48
10.2.9. Logging of Data Changes in Tables...................................................................................................49
10.2.10. Alternative Language for Missing Descriptions in the Login Language.........................................50
10.3. SECURITY POLICY......................................................................................................................................51
10.3.1. Security Policy Attributes...................................................................................................................51
10.3.2. Definition of Security Policy Attributes.............................................................................................51
10.3.2.1. Security Policy Attributes for the Definition of Password Rules Dependencies.......................................51
10.3.2.1.1. Check for Use “Prohibited Passwords”.................................................................................................52
10.3.2.1.2. Minimum Password Length...................................................................................................................52
10.3.2.1.3. Minimum Number of Characters in Passwords.....................................................................................52
10.3.2.1.4. Minimum Number of Letters in Passwords...........................................................................................53
10.3.2.1.5. Minimum Number of Lower-Case Letters in Passwords......................................................................53
10.3.2.1.6. Minimum Number of Capital Letters in Passwords..............................................................................53
10.3.2.1.7. Minimum Number of Special Characters in Passwords........................................................................54
10.3.2.2. Security Policy Attribute for the Definition of Password Changes...............................................................54
10.3.2.2.1. Number of Different Characters when Changing..................................................................................54
10.3.2.2.2. Size of the Password History.................................................................................................................55
10.3.2.2.3. Password Change after Rule Changes...................................................................................................55
10.3.2.2.4. Password Change Requirement for Single Sign-On logins...................................................................56
10.3.2.2.5. Interval Regularly, Password Changes..................................................................................................56
10.3.2.2.6. Minimum Waiting Time for Password Change.....................................................................................57
10.3.2.3. Security Policy Attributes for the Definition of Registration Restrictions.................................................57
10.3.2.3.1. Validity of Unused Initial Passwords....................................................................................................57
10.3.2.3.2. Validity of Unused Productive Passwords............................................................................................58
10.3.2.3.3. Maximum Number of Failed Login Attempts.......................................................................................58
10.3.2.3.4. Automatic Unlocking of Users..............................................................................................................59
10.3.2.3.5. Disable Password Logon.......................................................................................................................59
10.3.2.3.6. Disable Ticket Logon............................................................................................................................60
10.3.2.3.7. Restricted Logon to the SAP NetWeaver Application Server...............................................................60
10.3.3. Conversion Table Security Policy Attribute – System Parameters....................................................61
11. EMERGENCY PLAN....................................................................................................................................62
11.1. EMERGENCY USER.....................................................................................................................................62
11.2. AUDITING OF THE EMERGENCY USER........................................................................................................62
12. AUTHORIZATION CONTROLLING........................................................................................................63
12.1. CHANGE HISTORY.......................................................................................................................................63
12.2. LOCKING INACTIVE USERS.........................................................................................................................63
12.3. REVIEW OF AUTHORIZATIONS BY THE LINES OF BUSINESS.......................................................................64
12.4. Review of the Authorization Concept.......................................................................................................64
1. OBJECTIVES
1.1. Objectives of An Authorization Concept

An authorization concept serves to protect the data of the company as some special
legal and technical requirements must be observed. The principal for an authorization
concept is derived from the requirements of commercial law. For example, in Ger-
many, companies must comply with §§238, 239 and 257 of the German Commercial
Code (HGB) and §§140ff AO (German Fiscal Code). The legal requirements outlined
in the section of these codes state that companies have a bookkeeping obligation,
the obligation to keep records, and the obligation to retain documents relevant to
bookkeeping. Note, further details on the guidance for proper bookkeeping can be
found in the Generally Accepted Accounting Principles (GAAP).
Therefore, an authorization concept created for a company that operates in Germany
must take these legal requirements outlined in the HGB and German Fiscal Code
into consideration.
Overall, an authorization concept should support the correctness, completeness, and

traceability of data within a company, in addition, ensure the verifiability and availabil-
ity of the data and protect it from misuse and manipulation. Therefore, there are
some risks that must be considered when creating an authorization concept.
First, since personal data is used when using SAP systems, compliance with the
General Data Protection Regulation (GDPR) must be ensured.
Second, the SAP Systems of a company contain a large proportion of the company's
intellectual property, therefore, it is necessary to identify the inherent risks of using
the systems and to mitigate these risks with principals and controls outlined in the au-
thorization concept. Some inherent risks that should be considered, for example, are:
- Financial losses due to error, mistake or negligence

- Fraud and other commercial crimes through data manipulation
- Economic espionage
Finally, when complying with the requirements described above, it is important to en-
sure the productivity of the company by providing the required authorizations to the
users.
1.2. Out of Scope

All objects on the Front-End Server (Gateway) that do not belong to the ABAP autho-
rization system, such as Fiori Launchpad, the customer-specific adaptation of Fiori
Catalogs, etc., are not described within this Authorization Concept document.
1.3. Target Groups

The target group of an authorization concept is the management board of XYZ Enter-
prise, the internal auditors, the works council, the data protection officer, the data
owners and the responsible employees for the implementation of the authorization
concept. (See chapter 8)
1.4. Philosophy of an Authorization Concept
An authorization concept for a company is organized by role-based tasks and func-
tions. Meaning, the guiding principal in an authorization concept is that each User
gets exactly the authorization that they need for their daily business, while ensuring
that there is a segregation of duties.
The Data Owners are responsible for the data (see chapter 8.4). Data Owners are
represented by the responsible persons of each department. They instruct the Autho-
rization Coordinators of their department with the protection of their data (see chapter
8.3.).
The Authorization Coordinators support the Authorization Administrators by the cre-

ation of the roles and assign the final roles to the Users. In this way, a decentralized
assignment of roles by the business areas and a central creation and maintenance of
roles by the Authorization Administrators is realized. Section 8.2 contains additional
information related to Authorization Administrators.
2. COMPONENTS OF AN AUTHORIZATION CONCEPT
The following picture shows the different components of an Authorization Concept
2.1. Authorizations
An authorization is the permission to perform a certain action in an SAP System
based on a set of values for the individual fields of an Authorization object.
When you create an application, you specify where, how, or whether authorizations
should be checked by the system. The program uses the appropriate syntax to deter-
mine whether the user has enough authorization for a particular activity by comparing
the field values for the Authorization Object specified in the program with the values
contained in the authorizations in that user’s User Master Record.
An authorization can be used to restrict any number of single values or value ranges
for a field or allow all values.
2.2. Authorization Object

To execute an application in an SAP System, several authorizations may be re-
quired. The resulting interdependencies, therefore, can become very complex. In or-
der to offer a clear and easy to handle authorization concept for a company, the SAP
Authorization Concept was implemented utilizing Authorization Objects.
Authorization Objects enable complex checks of an authorization, bound to several

conditions, which allow a user to perform an action. An Authorization Object can con-
tain up to 10 Authorization Fields, which are checked by an AND logic relation.
However, for an authorization check to run successfully, all field values of the Autho-
rization Object must be maintained accordingly in the User Master Record.
2.3. Object Class
An Object Class is a collection of special Authorization Objects. In other words, Au-
thorization Objects are divided into classes. An Object Class usually corresponds to
an application area (for example, FI - Financial Accounting, MM – Materials Manage-
ment, HR – Human Resources, etc.).
2.4. Authorization Profile

Authorizations for users are not assigned directly to roles, rather they are assigned to
Authorization Profiles.
The maintenance effort is very high if individual authorizations are entered into the
User Master Record. Instead, authorizations can be combined into Authorization Pro-
files to help with maintenance efficiency. The benefit is that changes to access rights
take effect for all users who have the same Authorization Profile entered in their User
Master record.
2.5. Applications
In principle, authorization checks are controlled via Authorization Objects. The rela-
tionship between the respective application and the authorizations required for exe-
cution is shown in the tables provided for this purpose (USOBX_C and USOBT_C).
These can be individually adjusted/extended by the customer via Transaction SU24.
Below, the start Authorization Object for the different application types is described.
2.5.1. Transaction (S_TCODE)

Transactions are used to map functionalities in an SAP system. This can range from
simply calling up a table to starting complex processes.
When a Transaction is started, the Authorization Object S_TCODE is checked.
2.5.2. OData Service (S_SERVICE)

OData Services are technical objects of Fiori applications. For each Fiori application
there is at least one corresponding OData Service on the Front-End Server (type
IWSG) and one on the Back-End Server (type IWSV).
In terms of authorizations, OData Services are treated in the same way as Transac-
tions. When an OData Service is called, the Authorization Object S_SERVICE is
checked.
2.5.3. Web Dynpro Application (S_START)

Web Dynpro ABAP or Web Dynpro for ABAP (WD4A, WDA) is SAP's standard UI
technology for developing Web applications in the ABAP environment. It consists of a
runtime environment and a graphical development environment with special Web
Dynpro tools that are integrated into the ABAP development environment.
When starting Web Dynpro applications, the Authorization Object S_START is
checked.
2.5.4. Remote Function Call (S_RFC)
The communication between applications of different systems in the SAP environ-
ment can include both the connection between SAP systems and between SAP and
non-SAP systems. The Remote Function Call (RFC) is the SAP standard interface
for implementing this communication. The RFC calls a function to be executed in a
remote system.
When RFC Function Modules are started, the Authorization Object S_RFC is
checked.
2.6. Fiori Specific Components (Front-End)

The entities delivered by SAP are divided into technical entities and business entities.
In the next section the different entities for Fiori Launchpad are described.
2.6.1. Fiori Launchpad (FLP) Catalog

There are two types of FLP Catalogs: Technical Catalogs and Business Catalogs.
Technical Catalog
A Technical Catalog is a compilation of all apps in a functional area such as SD –
Sales and Distribution, MM – Materials Management, FI - Finance. It serves as a
repository which the customer can use to create role-based or user-based content.
Business Catalog
A Business Catalog is a collection of different applications from one area. It serves as
a template for customer-specific catalogs. For example, Asset Accounting.
Customer-specific Business Catalogs are required for the creation of Single Roles on
the Front-End System and the corresponding roles in the Back-End System.
They contain all necessary application/authorization information (IWSG (Front-End)
and IWSV (Back-End)).
2.7. Single Roles

Single Roles are collections of activities that allow a user to participate in one or
more business scenarios of an organization. The Transactions, Reports, or Web-
Based Applications contained in the Single Roles are accessed via user menus.
In the XYZ Enterprise, users are usually not assigned Single Roles, but only Com-
posite Roles. This is because generally Composite Roles correspond to workplaces/
positions while Single Roles correspond to application packages.
2.8. Composite Roles

A Composite Role covers all functionalities of a specific workplace. A Composite
Role is built up of Single Roles from different Modules – such as MM, SD, FI, etc.
By combining Single Roles, the respective menus of the Single Roles can be com-
pressed into one menu. Thus, redundant entries are deleted when the menus are
compressed.
2.9. User Master Record
A user can only log on to the system if a User Master Record exists for them. The
Composite Roles assigned in the master record give the user sufficient, although lim-
ited, access to the functions of the SAP System to perform their tasks.
It is possible to assign Composite (and Single) Roles to users for a limited time only.
This functionality is useful, for example, for temporary activities such as inventory ac-
tivities that should only be allowed for a limited time.
3. STRUCTURE OF THE SAP SYSTEM LANDSCAPE
3.1. The 3 Tier System Landscape

XYZ Enterprise uses a 3 Tier System Landscape within the meaning of SAP.
The systems are described in detail:
Area Development Quality Assurance Production

System System System
S/4HANA Cloud E11 CLNT 100 K11 CLNT 100 C11 CLNT 100
BI E11 CLNT 200 K11 CLNT 200 C11 CLNT 200
HCM E11 CLNT 100 K11 CLNT 100 C11 CLNT 100
3.2. Front-End & Back-End Server Definition
Front-End Server (Gateway Server)

The Fiori Applications introduced with SAP S/4HANA are started via a User Interface (UI) lo-
cated on the Gateway; this UI is called Fiori Launchpad. The definition and creation of Fiori
Catalogs also takes place in Fiori Launchpad.
The Front-End Server does not have to be operated as a Stand-Alone System but can be run
on the Application Server (Back-End Server) as an embedded Gateway. Default, all SAP S/
4HANA Cloud, private edition is run on an Application Server with embedded Gateways.
Back-End Server (Application Server)

The basis for most SAP S/4HANA Back-End Servers are SAP NetWeaver Application
Servers. The SAP NetWeaver Application Server controls communications between the
ABAP programs being executed, the database being used and the Front-End presentation
applications. This Server represents the Application Layer, where the tools and Web services
run and where the Application Server capabilities are used to support seamless application,
data, and system integration.
3.3. Different authorizations in the 3-Tier System Landscape
Each system in a 3-Tier Landscape has a different and specific purpose, and as a
result, there are different authorization concepts for each.
 Development System
The purpose of the Development System is to carry out the customizing and
development for the entire System Landscape. Therefore, extensive
authorizations are required for users in this system including customizing and
development authorization. Other characteristics of an authorization concept
for a Development System include:
o Roles are always created, or changed, in the Development System and
then distributed to the Quality and Production Systems via the
Transport System application.
o Custom reports (ABAP) must be programmed with all relevant
authorization checks.
o Custom tables must be assigned to the respective Authorization
Groups.
 Quality System (Q-System)

The Quality System serves to test the developments and customizing settings
carried out and transported from the Development System. For testing pur-
poses, users executing the testing are assigned the same roles as in the Pro-
duction System so testing can be performed under real conditions. Generic
Test User-Ids can also be created and used for test execution under real con-
ditions as the actual testing team members may not include every position us-
ing the Production System. Since the Quality System usually contains the
same data as the Production System, the same rules apply here as are ap-
plied in the Production System.
 Production System (P-System)

The Production System runs all the in-scope business processes of the
company. Roles are assigned as employees need them to perform their daily
activities. Normally, external consultants do not receive any authorizations to
the Production System. Any exceptions must be approved by the proper
customer’s responsible persons. An example of an exception is settings that
can only be made in the Production System or errors that cannot be traced in
the Quality System. These authorizations, for the exceptions, must be granted
for only for a limited period of time and explicitly documented. Another
example would be access to the Production System during the production
cutover. External consultants would have temporary production authorization
for cutover activities such as number range configuration, master data
conversion execution, z-table population and other such cutover tasks.
4. GUIDELINES FOR SETTING-UP AUTHORIZATIONS
Authorization maintenance takes place exclusively via the Profile Generator
(Transaction PFCG).
Roles (both Single and Composite Roles) are created and changed by the System
Administrator, from IT, according to the requirements of the responsible person from
the business department. Thus, the System Administrator is also the Authorization
Administrator for all Modules.
The person in charge of the Line of Business is the Authorization Coordinator for
their area. The Authorization Coordinator has the decision-making authority over the
functional composition of the Single and Composite Roles (and thus also access to
the data and associated business processes) of their area.
A Composite Role should be set up in such a way that it corresponds to a single

workplace. If an employee is responsible to perform tasks for several workplaces,
several Composite Roles can be assigned to their User Master Record. The
assignment of the Composite Role to the department/module can be seen from the
role name (see chapter 6.3 Naming Convention for Composite Roles for examples).
Composite Roles are formed by Single Roles. In addition to Single Roles from their
own department, Single Roles from other departments can also be used. Before
using Single Roles from other departments, the Authorization Coordinator of this
department must be contacted to obtain approval for the use of these Single Roles
by the other department.
When creating Single Roles, achieving a high degree of reusability should be taken
into consideration. For this purpose, function blocks of applications, which are
required in different Composite Roles, should be created. For example, it is advisable
to create a general display Single Role (Display Role) for most business departments
per module, in which all non-critical display applications of the module are included.
Therefore, this Single Role can then be reused in each Composite Role of the
department.
When adding applications to roles, it should always be checked whether data is

modified or only displayed when the application is executed. The applications are
then added to the Modify or Display Roles according to their functionality. The “type”
of the role can be read from its name (see chapter 6.4 Naming Convention for Single
Roles for further information).
When creating Single Roles, the corresponding menu is displayed when the
application is added. This functionality allows users to have User Menus tailored to
their activities. In addition, this functionality simplifies the navigation for the user as
they only see the applications that they have authorizations for and that are relevant.
Self-created applications must be integrated into the Role Menus in a logical position.
Manually adding Authorization Objects in Single Roles is generally not allowed

except for very specific situations such as cost center authorizations (see section
6.4).
Therefore, missing Authorization Objects are added to the requesting application with
Transaction SU24 (Maintenance of Assignments of Authorization Objects to
Transactions) and can be included in the Single Roles.
5. LIMITS OF AN AUTHORIZATION CONCEPT

Following the authorization concept’s guiding principal of only allowing users to ac-
cess the applications and data they need to perform their job, the implementation of
Authorization Checks within an application, or a report, should be used to limit a
user’s activities and to protect data. If Authorization Checks are missing in standard,
or self-created, applications or reports (ABAP Programs), the data that is processed
in these applications cannot be protected later with Authorization Objects.
An Authorization Trace is the best way to determine which Authorization Objects are
checked with which values when a process (with one or more applications) is exe-
cuted.
Please note that the Authorization Concept will not prevent users who are entrusted with the
authorization to use the system from causing damage due to human error or to wilful destruc-
tion.
5.1. Authorization Check and Authorization Trace

There are two different tools to perform authorization traces and to analyze autho-
rization issues.
The first tool that can be used is Transaction SU53. Transaction SU53 displays a
maximum of 100 failed authorization checks for each user in an SAP System that has
the default system parameter settings (system parameter “auth/su53_buffer_entries”
= 100). However, this tool only displays the failed authorization checks for the last
three hours. If there is a high number of active users and a high amount of failed au-
thorization checks, the number of checks and the period that is covered for a user
may be smaller.
Transaction SU53 also provides an initial overview of failed authorization checks, be-
cause every user has authorization to perform this transaction.
Another tool that can be used to determine authorization issues is an Authorization

Trace. With an Authorization Trace it is possible to get a very detailed analysis of all
the authorization checks using transaction STAUTHTRACE. This transaction reports
all authorization checks for a specific user in the background (including the used au-
thorization fields and field values).
The Authorization Trace result will clearly show which authorization objects and fields
were checked during the end to end process. If, for example, during the Authorization
Trace, the results show that there was no authorization check of the company code
executed, then there is no authorization company code restriction possible to protect
the company code data.
It should be noted, for General Data Protection Regulation (GDPR) compliance, the
Authorization Trace function should not be used without the knowledge and permis-
sion of the user being traced.
5.2. Additional Implementation of Authorization Checks in Customer
Applications
Authorization Checks should cover most of the business processes, however, if it is
determined that insufficient Authorization Checks are present in self-created applica-
tions, these must be supplemented by the developers of the application.
To do this, the required authorization checks on the corresponding Authorization Ob-
jects, and the required Authorization Fields, must be built into the coding of the appli-
cation.
5.3. Additional Implementation of Authorization Checks in SAP Standard Appli-

cations
If further Authorization Checks for SAP Standard applications are needed, there are
different possibilities available to install an adequate authorization protection after-
wards.
1. Creation of a Customer Incident to SAP

If it is determined that there is insufficient authorization protection at a certain
point in an application, then SAP Support should be checked to determine if
there is an existing SAP Note available to address this issue. If there is no
SAP Note already documented in the SAP Support Portal, the responsible em-
ployee should open a Customer Incident to SAP.
Generally, if the reported authorization issue is a generic error in the program
code, it is solved by SAP. However, if the authorization issue is an individual
security requirement of the XYZ Enterprise, the Authorization Check must be
implemented using one of the other options.
2. Using a User Exit

One option to install adequate authorization protection if there is an individual
security requirement is to use User Exits, which are defined by SAP for many
application interfaces. Among other things, User Exits can be used to extend
Authorization Checks. With the use of User Exits, it is possible to implement
additional Authorization Checks to individually protect the data being accessed
by the applications.
3. The Creation of Application Variants

Another option is to use Application Variants. These variants can be used to
hide fields, checkboxes and radio buttons which are presented in the standard
application and which allow complete access to the function of the application.
Hiding these application selection attributes results in limiting the use of the
application by a user.
4. Modification of SAP Standard Applications

A last option to be selected, only after all other options are exhausted, is to
install the required authorization checks directly into the SAP Standard
Applications and to modify them. However, modifying standard applications
creates the risk because these applications will not be supported by SAP.
Choosing this option should not be underestimated and all the associated
risks should be considered.
6. NAMING CONVENTIONS FOR AUTHORIZATION ENTITIES
To allow for easier solution adoption and enablement for the authorization concept,
Naming Conventions for the authorization concepts is required. The names should
be as descriptive as possible to simplify, for example, the intuitive assignment of
roles to activities and their maintenance.
6.1. Naming Conventions for the User ID (for Internal and External Users)
For the Naming Conventions for the User ID, the User-ID's should be the same
across all applications.
New User-ID's are created company-wide according to the following guideline:
The first digit of the ID is the first letter of the user’s first name and the remain-
ing digits are the user’s complete last name.
However, there are the following exceptions:
1. If the name exceeds the length of the input field, the last name is truncated.
In case of double names, the second letter of the first name is added. Um-
lauts are converted to 7-bit ASCII characters (e.g., ä=ae)
2. For external users, like consultants, the first four digits are used to specify
the external user, (EXT_), followed by the first character of the first name
and the other digits for the last name (the last name is truncated).
Examples:
Simone Mustermann User ID: SMUSTERMANN
Sabine Mustermann User ID: SAMUSTERMANN
Udo Brockhäger User ID: UBROCKHAEGER
6.2. Naming Conventions for User Groups
Once the assignment of SAP users to User Groups is complete, the user mainte-
nance can be distributed to different Authorization Coordinators. The User Adminis-
trator assigns specific User Group authorizations to each Authorization Coordinator.
After being assigned a User Group, the Authorization Coordinator can only maintain
the user of their User Group (assign or revoke roles, password change, user lock/un-
lock).
The User Group maintenance is done with the transaction SUGR. This transaction
can only be maintained by the User Administration. The name of the User Group is
as follows:
 The first 4 digits start with the company code in which the users nor-
mally work
 The fifth digit serves as a separator (_).
 The remaining digits, 6-12, serve as a description, and must be chosen
to be as meaningful as possible.
In the case of external users, the user group entered in the user master record is the
department that is responsible for the authorizations of the respective external user.
For example, SAP consultants are assigned to the IT user group and auditors to the
finance user group.
Note the User groups = max. 12 characters.
0 0 0 1 __ A B T E I L U
Company code indicators (4 digits)
0001 XYZ
0002 ABC
0003 BCD
0004 CDE
Separator (1 digit)
Department indicators (max. 7 digits)
In addition, subsequent user groups are created for global special users:
XXXX_SUPER Use for emergency users, SAPADM, SAPRES,

SAP standard user
XXXX_SYS Use for background user
XXXX_TEST Use for test user
XXXX_TRAINEE Use for trainees or apprentices
6.3. Naming Conventions for Composite Roles
The Naming Conventions for Composite Roles follows these principles:
 Each composite role begins with the character Y.
 The character in the second position indicates the target system for which the
role was developed. For example, the character P stands for the Production
System.
 The character 3-5 are a company identification (it could be enhanced by two
country letters like US, DE to specify a country).
 This is followed by two or three digits, for characters 6-8, for the identification
of the module, for which the role has been created.
 Finally, If the workplace includes no separation, the remaining digits after the
separator (_) are for the description of the Composite Role. If a separation, for
example, at company code or plant level is present, this is described at the
end of the Composite Role and separated from general description through a
separator (_), for example _BUKRS0001 (company code 0001).
Note, the Composite Role description = max. 30 digits.
Y P XYZ CO _ CONTROLLER _ BUKRS000

Role indicator (1 digit)
Y Composite Role
System indicator (1 digit)
P Production system
Q Test system
D Development system
Company indicator (3 digits)
XYZ
Module indicator (2 to 3 digits)
BC Base
CO Controlling
FI Financial Accounting
HCM Payroll
LE Warehousing
MM Material Management
PM Maintenance
XX Across Modules
Separator (1 digit)
Description (max. 21 digits)
e. g. Controller
Separator (opt. 1 digit)
Differentiating indicator (optional)
BUKRS000 Company code 0001
1
6.4. Naming Conventions for Single Roles
For the naming conventions for Single Roles, every Single Role begins with the letter
Z. An exception for this principle is the special Single Roles that may also be as-
signed to users directly, for example, cost center roles. For the second character, a
letter to indicate the target system for which the role was developed is used; for ex-
ample, the letter P indicates the Production System. For the character in the third to
the fifth place the company identification (it could be enhanced by two country letters
like US, DE to specify a country) is used. These characters are then followed by two
or three digits for the identification of the module, which indicates the area the in-
serted applications belong to. Finally, the Single Roles description follows the sepa-
rator (_). The description should make it simple for a user to easily identify the func-
tionality (max. 19 digits).
If the authorizations of a Single Role include differentiation by values (authorization

for a specific cost center for example) then this will be identified accordingly in the
Single Role description. If a Single Role includes the entire functionality, however, it
receives the identifier MASTER. The differentiated Single Role has the same identi-
fier as the Master Role except with the difference in the description - for example
CC400501 for cost center 400501 instead of MASTER. The differentiated Single
Role only includes Authorization Objects that include authorizations to be differenti-
ated (for example only Authorization Objects with cost center Authorization Fields).
These Authorization Objects must be inactivated in the Master Role.
At the end of the Single Role name the type of the added applications is described.
This end descriptor identifies whether the added applications are purely display appli-
cations with only display authorizations (D = display) or if they are modify applications
with display and modify authorizations (M = modify). Modify include all other data
changing activities, for example, create, block, delete. You are not allowed to add
display applications to modify Single Roles.
Example: ZPXYZCO_CONTROLLER_MASTER_D (27 digits)

XPXYZCO_CONTROLLER_CC400501_D (29 digits)
Authorization for display the cost center 400501
Note, Single Role descriptions = max. 30 digits.
Z P XYZ CO _ CONTROLLER _ MASTER _ M
Role indicator (1 digit)
Z Single Role
X Special Single Role
System indicator (1 digit)
P Production system
Q Test system
D Development system
XYZ

BC Base
CO Controlling
FI Financial accounting
HCM Payroll
LE Warehousing
PM Maintenance
XX Across Modules
Separator (1 digit)
Description (max. 21 digits)
e.g. Controller
Separator (opt. 1 digit)
Differentiation indicator (optional)
MASTER Master role (to differentiated
ctsects
obj. have to be inactivated)
CC400501 Cost Center 400501
Separator (1 digit)
Task indicator (1 digit)
Specification of task activities
D Display authorizations
M Modify authorizations
6.5. Naming Convention of Authorization Profiles
Each Authorization Profile begins with the letter Z (an exception to this are the pro-
files of special Single Roles which begin with X). Followed by the three-digit company
identification. Subsequently, the two-digit or three-digit identification of the module.
The assignment of each module results from the Single Role to which the Authoriza-
tion Profile belongs. The following is a two- or three-digit numbering.
The belonging activity indicator “D” or “M” represents activities (Display or Modify)
from the profile.
Example:
Name of the Single Role: ZPXYZCO_CONTROLLER_MASTER_D
Name of the authorization profile: ZXYZCO000D
Name of the profile = max. 10 characters
Z XYZ CO 001 D
Profile indicator (1 digit)
Z Authorization profile
XYZ

BC Base
CO Controlling
FI Financial account
LE Warehousing
PM Maintenance
XX Across Modules
Profile numbering (2 to 3 digits)
Activity indicator (1 digit)

)Specify of activities
D Display authorizations
M Modify authorizations
6.6. Naming Conventions for Customers Applications
The naming convention for self-created applications is for the development of new
applications as well as for the conversion of reports to applications.
Internally generated applications are created with Z or Y depending on the further

use. The second through fourth character is used to indicator the module to which
the new created application should belong to. After the delimiter indicator (_) a de-
scription of the application it is to be found. It could consist of the report name, for ex-
ample, which serves as a basis for the new application (max. 15 digits).
Name of application = max. 20 digits
Z BC __ DESCRIPTION
Application indicator (1 digit)
Y ?
Z ?
BC Basis
CO Controlling
FI Finance Accounting
HCM Payroll
LE Warehousing
PM Maintenance
XX Across Modules
Delimiter indicator (1 digit)
Application description (15 to 16 digits)
e.g. the name of the report, that is the basis of the
application als
application: Grundlage für die neue
ZBC_RSUSR002
6.7. Naming Conventions for Customer Tables or Authorization Groups
The naming convention for self-created tables is the same as for self-created applica-
tions (see chapter 6.6.). During the creation of the tables make sure to assign them
to the appropriate Authorization Groups. Tables that are not assigned to an Autho-
rization Group will be assigned to the group &NC& automatically by system (&NC& =
no authorization group). The consequence is that the critical authorization object
S_TABU_DIS (table maintenance) will need then change authorizations, for example,
for the authorization group &NC&. With these authorizations assigned a user would
be able to get change access to thousands of tables. To eliminate this risk, it is nec-
essary to avoid the assignment of authorizations with authorization group &NC&.
Authorization group name = max. 4 characters
Z CO X
Application indicator (1 digit)
Z Customer´s name space
Module indicator (2 digits)
BC Base
CO Controlling
FI Financial accounting
HC Payroll
LE Warehousing
PM Maintenance
XX Across Modules
Criticality indicator (1 digit)
X General
C Critical
A Administrator
7. CRITICAL AUTHORIZATIONS AND SYSTEM FUNCTIONS
7.1 Access to SAP Standard Roles and Profiles

In general, XYZ Enterprise users may not be assigned SAP standard roles and pro-
files, such as SAP_ALL or SAP_NEW.
However, the roles, profiles and authorizations delivered by SAP are kept in the sys-
tems.
7.2. SAP Standard Users

The SAP Standard Users SAP*, DDIC and SAPCPIC are only to be used in an emer-
gency or for certain system activities by SAP Enterprise Cloud Service (ECS) in client
000.
The passwords of these SAP-Users must be changed and needs to be locked.
The use of SAP Standard Users is not allowed by SAP S/4HANA Cloud, private edi-
tion costumers!
SAP*:
The User SAP* has SAP_ALL-Authorizations assigned. Even if the user is deleted, it
is possible to log in with the standard password, so this user represents a major se-
curity gap. Therefore, the super rights of this User must be withdrawn via the System
Parameters.
 The SAP* User needs to be locked.

 Standard password needs to be changed.
 Withdraw all authorization of SAP*.
 Assignment made to the User Group (XXXX_SUPER).
 System Parameters settings for SAP* need to be changed (see chapter
10.1.5.1).
DDIC:
The DDIC User has full privileges to manage the repository. During the Installation
and Release-Change Operation the DDIC user is the only one who can make
changes in the Data Dictionary. Only the DDIC user is permitted to make these kinds
of installation and upgrade activities. This means that, for example, activities like the
creation of custom developments with this user are forbidden.
 The DDIC User needs to be locked in all systems (if necessary, the user can
be unlocked by the User Administrator).
 Assignment made to the user group (XXXX_SUPER).
SAPCPIC:
The SAPCPIC User will be created during system installation and will be used in
ABAP-programs and for EDI utilization. Default privileges are limited to RFC-ac-
cesses.
 The SAPCPIC User needs to be locked.

7.3. Critical Functions
In the SAP System the following functions are identified as critical and therefore they
either should not be assigned or should only be assigned on a very limited basis in
the Quality or Production Systems:
 System-, Basis- and HCM authorizations

 ABAP-Workbench (SE80)
 SAP Query (SQ01, SQ02, SQ03)
 Quick Viewer (SQVI)
 Batch-Input (SM35)
 Table display and maintenance (SE16, SE16N, SE17, SM30, SM31, SM34)
 Database utility (SE14)
 Transaction to execute programs (SA38, SE38)
 Table logging setting (SE11)
 Create Transactions (SE93)
 Display and maintenance of RFC Destinations (SM59)
 Client management (SCC1 – SCC9, SCCL)
 Maintenance of system parameter profiles (RZ10)
 Maintenance of system parameters (RZ11, RZ12)
 CCMS Monitoring (RZ20)
 TCODE management (lock/unlock) (SM01)
 Management of user modes (SM04)/(AL08)
 Select and delete lock entries (SM12)
 Update requests (SM13)
 Deletion Security Audit Log protocols (SM18)
 Configuration Security Audit Log (RSAU_CONFIG)
 Analyze Security Audit Log (RSAU_READ_LOG)
 Analyze SYS Log (SM21)
 Application server display/change (SM51)
 Workflow management (SM50) / (SM66)
 Transport management system (STMS)
 Maintenance Change document objects (SCDO)
 Archive Administration (SARA)
 Analyze user activities (STAD, ST03N)
 Database Administration (DB2)
7.3.1. Restrictions of Application Execute Authorizations
Four Authorization Objects are part of the group Application Execute Authorizations.
S_TCODE Transaction execute authorization

S_SERVICE oData-Service (Fiori Application) execute authorization
S_START Webdynpro execute authorization
S_RFC RFC Function Call execute authorization
The respective Authorization Object determines whether a user can execute certain
applications or not. All applications a user needs for their daily work must be regis-
tered in one of these Authorization Objects (depending on the application type). Full
authorizations using a wildcard e.g. „*“ are not allowed for any of these Authorization
Objects. In general, the assignment of system applications and of basis modules to
Users should be very limited in the Production System (in contrast to developers in
the Development Systems).
7.3.2. Generic Table Access

Table access (SAP and Customer tables) needs to be protected against unautho-
rized access. The table access will be controlled by application authorizations, table
authorization groups and/or table names:
Application authorizations
Table access is possible using various applications in the system. There are applica-
tions which makes it possible to maintain direct table values (Transactions SM30,
SM31), applications which display table structures (Transactions SE11, SE12) and
applications which display table values (Transactions SE16, SE16N and SE17).
Applications which allow a maintenance of table values need to be assigned in a very

restricted manner whereby the direct assignment of all the previously mentioned ap-
plications should be avoided. For any direct table access, so called Parameter Trans-
actions must be created, which give access to only one particular table (Transaction
SE93).
To get table access two Authorization Checks must be successfully passed.

The first Authorization Check is when a Transaction is executed and uses Authoriza-
tion Object S_TCODE.
The second Authorization Check is on Authorization Object S_TABU_DIS or if the
check is not successful on Authorization Object S_TABU_NAM.
Authorization Object S_TABU_DIS

All tables are assigned to Authorization Groups by default. The assignment will hap-
pen via transaction STDDAT. Users who want to access certain tables need autho-
rization for the relevant Authorization Group of the Authorization Object
S_TABU_DIS. Self-developed tables also need to be assigned to an Authorization
Group. The use of Authorization Group &NC& (no Authorization Group) while techni-
cally possible, is not allowed when implementing the guidance of this Authorization
Concept. After the introduction of the Authorization Object S_TABU_NAM, using
S_TABU_DIS to control the table access should be avoided.
Authorization Object S_TABU_NAM
To give access to particular tables the Authorization Object was invented. The Autho-
rization Administrator enters into the Authorization Field “TABLE” the table names of
the tables to which the user needs to have access.
7.3.3. Analysis (Report) Authorizations

Reporting is an important function in the SAP system. These Reports/Analyses can
be performed with various tools. In this case, it is important to ensure that the infor-
mation is only made available to the Users authorized to view the data.
ABAP/4 Programs
When starting up reports with the applications SE38 and SA38 the system does not
check the authorizations to a large extent. The Authorization Check of the Authoriza-
tion Object S_PROGRAM (which is a standard planning practice) will only run if the
report is assigned to an Authorization Group. As this applies to only a small number
of reports it will be possible for a user to execute almost any report if they have au-
thorization to start applications SE38 or SA38. The assignment of application autho-
rizations SE38 and SA38 is extremely critical because those reports make it possible
to create, change or delete data.
For this reason, for each required ABAP/4 program, Report Transactions must be
created with transaction SE93 (Maintain Transaction). This will ensure that the User
only has access to specific reporting/analysis programs.
Report Writer / Report Painter

When using Report Writer or Report Painter, the development takes place exclu-
sively in the Development System. The protection and execution control of those re-
ports are realized with their own report specific Authorization Objects and self-de-
fined Authorization Groups. In the Production System, only the report execution and
display are allowed.
SAP-Query / Quick Viewer / InfoSet-Query

With the help of SAP-Queries or Quick Viewer (SQVI/SQ01/SQ02/SQ03) it is possi-
ble to create simple reports (with Info-Sets) from tables and databases.
The Query tasks that a user can do are controlled by the Authorization Object
S_QUERY.
In the Production System, the assignment of S_QUERY should be very limited and
generally only to Administrators.
The following activities are allowed:
Activity 23 (maintain Queries user assignment)
Activity 67 (translate)
Activity 02 (create and change queries) is therefore forbidden in Production Systems.
Queries will be created and changed by Administrators at Development systems and

transported to the Quality and Productive systems, where they will be assigned with
transaction SQ00 to users.
Data Browser
Data-Browser Transactions (for example SE16, SE16N, SE16J, SE17) are standard
tools which makes it possible to view tables and their content. It is possible to display
table content and all table field values with their text field values. From the table con-
tent, the User also can also find references to the associated check table contents.
If the users have the Authorization Object S_GUI (with activity 61) assigned, they can
download the displayed table content to their PC’s via the download function.
The access to tables is protected by the Authorization Object S_TABU_DIS. If the

authority check fails, the Authorization Object S_TABU_NAM will also be checked.
If direct table access is required Parameter Transactions must be created with trans-
action SE93 (Maintain Transaction).
7.3.4. Download of Data

Using the menu path „System -> List -> Save -> Save”, it is possible to save reports
on a local data medium and to process them with programs like Excel and Word. The
authorization to download is provided by the Authorization Object S_GUI (activity 61).
Those users who are authorized to access certain data have the responsibility to
comply with all requirements for handling sensitive data. Those data handling re-
quirements also apply to the usage of SAP-Office functions.
In addition to data downloading, it is also possible to make data extracts using

screenshots and/or using spool requests.
7.3.5. Spool and Print Out Control

Reports to be printed will be transferred to the spool system. There are two possibili-
ties:
1) To send the report directly to the printer
2) To redirect the report as a spool request for a later print out.
In the Quality and Production Systems, it must be ensured that Users only have ac-
cess to their own spool requests. If spool requests are more than 30 days old and
have also been processed, they will be deleted by the SAP-Basis team.
7.3.6. Background Processing
The Batch-Input technique is a method to transfer and/or process data of sequential
databases. The Batch-Input program (transaction controlled) creates a Batch-Input
map. These maps can be processed either in the foreground or in the background.
During a map’s processing run, dialog entries (online transactions) are simulated.
When the map runs in the foreground, the authorizations of the user executing the
foreground run are checked. During the background run, the authorizations of the
user who created the map are checked. Each respective user needs authorizations
for all the embedded applications as well as the authorizations for transaction SM35
and the Authorization Object S_BDC_MONI.
In general, the Batch Input authorization rights need to be limited to specific map
names and to specific areas of responsibility. In addition, it should be noted that there
is a possibility to change the input values when executing in the foreground. That
needs to be considered when creating these authorizations for the online mode.
These authorizations should be assigned in a very limited fashion. This is done via
the Authorization Objects S_BTCH_JOB, S_BTCH_NAM and S_BTCH_ADM.
7.3.7. Development Authorizations

During the development of applications and reports, it must be ensured that the data
is protected through proper authorization checks. ABAP Development will take place
only in the Development System. Generally, it is not allowed for authorizations to
change ABAP code to be assigned in the Production System. Due to the system sta-
tus it shouldn’t be possible to have a new installation or to have a change of reposi-
tory objects in the Production System (SCC4). Debugging in the Production System
should only be allowed in display mode, therefore change authorization for the Au-
thorization Field OBJTYPE with Value “Debug” of the Authorization Object S_DE-
VELOP is not allowed in the Production System. Development authorizations are
managed by the S_DEVELOP object.
7.3.8. Customizing Authorizations

In general IMG Customizing activities will be performed exclusively in the Develop-
ment System and afterwards will be transported through the system landscape to the
Quality System and Production System.
Except for the maintenance of current settings (e.g. open/close accounting periods,
maintain currency tables, number range assignments) there are no Customizing pos-
sibilities in the Production System – due to the system status settings (transaction
SCC4: no changes to repository / cross-client customizing objects). For those set-
tings, there are specific Customizing Transactions in the system. Only selected users
can change those settings in the Production System.
7.3.9. System and Client Settings
System authorizations means those functions which are not application-specific, but
which help to manage the Basis functions.
Because of this, it is necessary to set up specifications for the protection of the Pro-
duction System. If there is no protection for the Production System against changes
to customizing and repository objects during its operation, then it is possible that in-
consistencies will occur within the system landscape. Therefore, the Production Sys-
tem needs to be protected against all direct modifications to customizing and/or
repository objects (transaction SCC4). This authorization control is based on table
“T000”. The access to this table should only be allowed to SAP Enterprise Cloud Ser-
vice (ECS). The table “T000” will be assigned to an Authorization Group which is only
available to SAP-Basis. Change history of table changes are required to ensure com-
pliance with audits of the Production system.
7.3.10. File Access

With ABAP statements, it is possible to use operating system files as input and/or
output files. Due to insufficient protection, access to sensitive data is therefore possi-
ble. For this reason, the file access authorizations will be limited as far as it is techni-
cally possible so that the Business User does not have access to system files. This
access is controlled by the S_DATASET Authorization Object.
7.3.11. System Controlling/System authorizations

For the SAP-Basis team, Authorizations need to be restricted to their required activi-
ties. The Authorization Object S_ADMI_FCD (in interaction with other Authorization
Objects) manages the access to several essential SAP Basis functions: e.g. network
administration, process administration, client modification, booking administration,
cross-client spool-administration, lock and unlock applications, etc.
8. RESPONSIBLE PERSONS FOR THE IMPLEMENTATION OF AN
AUTHORIZATION CONCEPT
Not only is the company’s IT department responsible for the Authorization Concept
implementation, but also, all the respective departments are responsible for the im-
plementation of and the compliance with the Authorization Concept.
First and foremost, the respective Data Owner is responsible for the protection of and
compliance with the legal requirements. The Authorization Administrators are respon-
sible for the implementation of the requirements regarding the Role structure and of
the assignment of authorizations according to the specifications of the business de-
partment. The User creation is carried out exclusively by the User Administrators in
the IT department. This division of tasks to different organizations withing the com-
pany ensures a separation of duties in the authorization system.
In the following sections, the tasks of the individual functional areas in the authoriza-
tion system are explained.
8.1. User Administration (creation and maintenance of users)

The tasks of a User Administrator are to create, maintain and delete the User Master
Records.
The User Administrator has the following tasks and authorizations in the overview:
 Create and change user.
 Display authorizations and profiles.
 Start of the User Information System.
 Assign Users to Roles for:
o All IT and System Users.

o In exception cases: Users of the departments after a written request.
The following tasks are not allowed:

 Role changes (authorization changes).
 Change or generate profiles.
 Execute User Master Comparison.
8.2. Authorization Administration (Maintenance of Single and Composite Roles)
The tasks of the Authorization Administrators are to create, maintain and delete Sin-
gle and Composite Roles. They have no authorization to change User master
records or to assign Composite Roles.
The Authorization Administrator has the following tasks and authorizations:

 Create and change Roles.
 Change the selection of applications or the authorization data in Single Roles.
 Start the User Information System.
 Generate profiles.
 Transport of Roles through the system landscapes.
 Execute User Master Comparisons.

 Change user master records.
8.3. Authorization Coordination (Specification of the department authorization

requirements)
The Authorization Coordinator assigns the Composite Roles or special Single Roles
to the users within their area of responsibility. They are authorized to assign only
Composite and/or special Single Roles of their department.
Authorization Coordinators are responsible for the protection of the company’s data
in their responsibility area. Therefore, they create the Composite and Single Roles for
their department in cooperation with the Authorization Administrators. The Authoriza-
tion Coordinator will be appointed by a manager of the respective department.
The Authorization Coordinator has the following tasks and authorizations in the over-
view:
 Specification of the role content of their department.
 User requirements.
 Display authorizations and profiles.
 Role assignment of their Composite Roles to users of their department.
 Start of the User Information System.
 Execute User Master Comparison.
 Maintain User Parameters.

 Create and change user (Exception: Assignment of Composite and special
Single Roles).
 Role changes (authorization changes).
 Change, assign or generate profiles.
8.4. Data Owner

Data Owners are responsible for the data protection of their department. This task is
overseen by the manager of the respective department. Special tasks such as the
authorization assignment (i.e. which user has what access rights to the data of the
department) will be delegated by the Data Owner to the Authorization Coordinators.
9. Guidelines for User Master Records
9.1. User Types
9.1.1. Dialog Users (Type Dialog)

Users who logon to SAP Systems always belong to the Dialog User group.
The login takes place by using Single Sign On. Users who have the possibility to per-
form a dialog login without using Single Sign On will be checked regarding expired /
initial passwords and offered the possibility to change their password. Multiple dialog
logons are locked for Business Users (for exception see chapter 10.1.4.2).
The System Parameter for the password’s validity period must be set to 90 days
(chapter 10.1.2. password validity period).
For security compliance reasons, it is not allowed to share your Dialog User with
other Users.
9.1.2. System Users (Type System)

System Users (Batch Users) will be used for a dialog-free communication and/or for
background processing within a system (for RFC or CPIC service user).
A dialog logon is not possible.
During the logon procedures, Users of this type are excluded from the password va-
lidity period check. Passwords of System Users don’t expire. Only User Administra-
tors can change them via transaction SU01. System Users will be assigned to the
user group XXX_SYS (Background User).
9.1.3. Communication Users (Type Communication)

Communication Users (e.g. RFC, ALE-User) will be used for a dialog-free communi-
cation between the Systems (for different applications e.g. ALE, Workflow, TMS,
CUA).
A dialog logon is not possible.
During login, a check will start regarding expired / initial passwords. Passwords of
Communication Users expire. Their password can only be changed by User Adminis-
trators (transaction SU01). Due to this fact, the communication at the XYZ enterprise
only happens via technical users of the User Type System User. The User Type
Communication User is accordingly not allowed (see also SAP Note 622464).
9.1.4. Service Users (Type Service)
Service Users will be used for anonymous system accesses via an ITS-Service.
Users of the Type Service User are dialog users and are part of an anonymous,
larger user group. Generally, only very restricted authorizations should be assigned.
After an individual authentication, it is possible to carry on a starting anonymous ses-

sion with a Service User as a personalized session with a Dialog User.
During login, there won´t be a check regarding expired / initial passwords.
Only the User Administrator has the possibility to change the password. A multiple lo-
gin is permitted. Due to the requirements described in chapter 9.1.1, the use of Ser-
vice Users is not allowed at the moment.
9.1.5. Reference Users (Type Reference)

Reference Users are like Service Users in general and are not personalized users. It
is not possible to logon with a Reference User. The Reference Users only serve for
the assignment of additional authorizations. Reference Users, for example, are used
to provide identical basic authorization to Users.
Reference Users will be added in the “Roles” tab of transaction SU01 for the specific
User Master Records (or for mass change with SU10). It is only possible to assign
one Reference User per User Master Record.
An evaluation over all applications which were assigned to the User can be done by
the call up of report RSUSR100N.
9.2. Trainees
Trainees will work during their training period in many departments. Many of their
tasks will be done with the support of SAP Systems. For those activities, it is neces-
sary to assign to the trainee the corresponding authorizations, which are relevant for
the department in which the trainee currently works.
To avoid having the trainees get more and more authorizations (while passing
through all departments which are relevant for the training) the following rules must
be considered:
 When hiring, a separate User Master Record must be created for each
trainee. The necessary data can be obtained from the personnel department
for trainees, as for all other SAP Dialog Users (see chapter 9.1.1. Dialog
User). The creation of anonymous users for trainees is prohibited.
 The authorizations required for the respective training sections must be dis-
cussed and created together with the responsible departments.
 In coordination with the personnel department (or the training management),

the Composite Roles for the respective training phases are to be assigned on
a long-term basis. For this purpose, the validity periods of the Composite
Roles are maintained for the required SAP systems in the Roles tab of the
user master record.
9.3. External Users
External Users include all Users who are not members of the XYZ Enterprise, such
as consultants, auditors, etc.
The application for User Master Record and for authorizations is done through the
same procedure as for all other Users. A restrictive assignment of authorizations
must be ensured.
Generally, there is no SAP_ALL or SAP_NEW assignment to External Users. Also,
only in exceptional cases are External Users assigned authorizations in Production
Systems.
For User creation the following points must be considered:
 The username must be created according to the naming convention.

 The name of the contact person must be entered into the field “Function” in
the “Address” tab.
 The “Department” field in the “Address” tab the requesting department must
be entered.
 Assignment of the User Group according to the Naming Convention in the “Lo-
gon Data” tab must be made (see chapter 6.2).
 Maintenance of the validity period of the User Master Record in “Logon Data”
tab according to the planned duration of use must be completed.
 Maintenance of the validity period of the Composite Roles in the “Roles” tab
according to the planned duration of use must be completed.
9.4. Emergency User SAPRES

In emergency cases the user SAPRES will be used (see chapter 11.1. Emergency
User). The SAPRES User can be used in all clients exclusively by SAP-Basis (excep-
tion client 000).
This User is an exception to the rule set up in chapter 9.1.1 Dialog User that no
anonymous Users are allowed on the SAP Systems.
The User is assigned to the User Group “SUPER”. The reason for the use of the
Emergency User must be documented. The password is only known to SAP Basis.
The User has the authorization profile “SAP_ALL” assigned.
10. System Parameter settings & Security Policies
In SAP Systems, System Parameters are used to set basic settings for User and for
authorization administration. These parameters are explained below. The values of
the parameters can be checked using the report RSPARAM or transaction RSPF-
PAR. Transactions RZ10 (Administration of Instance Profiles) and RZ11 (Mainte-
nance of System Parameters) are available for parameter administration. The main-
tenance of the parameters is carried out exclusively by the Basis department.
Unlike the System Parameters, which apply across users and clients, Security Poli-
cies (transaction SECPOL) are assigned directly to User Master Records via transac-
tion SU01. This means that it is now possible to set the parameters individually. Most
of the System Parameters that control password rules and logon behavior are set by
the Security Policies. Only for User Master Records which do not have an assigned
Security Policy will the previous System Parameters remain effective.
10.1. Parameters to Control the Login and Password Protection

Logon and password protection in the SAP System are mainly controlled by config-
urable system parameters. To activate the settings, the system must be restarted.
10.1.1. Password Rules
10.1.1.1. Overview of the SAP standard Rules for Passwords
The following supplementary rules for passwords are preset in the system by default:
 First character must not be „!“ or „?“
 The first three characters must not be identical
 Passwords listed in the table USR40 "Illegal passwords" cannot be used.
10.1.1.2. Password Length

Parameter: login/min_password_lng
The parameter defines the minimum length of a password. The smallest permissible
value is 3, the highest value 40. The maximum value that can be set depends on the
Parameter: login/password_downwards_compatibility - Downwards compatibility of
passwords (see chapter 10.1.5.4.).
SAP-Standard: 10 (Minimum password length= 10 characters)
XYZ Enterprise: 10 (Minimum password length= 10 characters)
10.1.1.3. Minimum Number of Digits in Passwords
Parameter: login/min_password_digits
This parameter determines the minimum number of digits (0-9) that must be included
in the password. It is effective both when assigning new passwords and when chang-
ing or resetting passwords.
SAP-Standard: 1 (One minimum number of digits required)
XYZ Enterprise: 1 (One minimum number of digits required)
10.1.1.4. Minimum Number of Letters in Passwords

Parameter: login/min_password_letters
This parameter determines the minimum number of letters (a-z, A-Z) that must be in-
cluded in the password. It is effective when assigning new passwords as well as
when changing or resetting passwords.
SAP-Standard: 1 (One minimum number of ASCII-letter required)
XYZ Enterprise: 1 (One minimum number of ASCII-letter required)
10.1.1.5. Minimum Number of Lowercase Letters in Passwords

Parameter: login/min_password_lowercase
This parameter determines how large the minimum number of lowercase letters (a-z)
must be in the password.
This parameter is checked both when assigning new passwords and when resetting
passwords.
Exception: If the system parameter login/password_downwards_compatibility is set

to the value 5, no check takes place.
SAP-Standard: 1 (Lowercase letter required in password)
XYZ Enterprise: 1 (Lowercase letter required in password)
10.1.1.6. Minimum Number of Capital Letters in Passwords

Parameter: login/min_password_uppercase
This parameter determines how large the minimum number of capital letters (A-Z) in
the password must be.
This parameter is checked both when assigning new passwords and when resetting
passwords.
Exception: If the system parameter login/password_downwards_compatibility is set

to the value 5, no check takes place.
SAP-Standard: 1 (Capital letter required in password)
XYZ Enterprise: 1 (Capital letter required in password)
10.1.1.7. Minimum Number of Special Characters in Passwords
Parameter: login/min_password_specials
This parameter determines the minimum number of special characters that must be
included in the password. It is effective when assigning new passwords as well as
when changing or resetting passwords.
As special characters are considered all characters, which neither

- neither numbers (0-9),
- nor the ASCII-letters A-Z/a-z
This includes national special characters and Unicode characters (if

is a Unicode system) as well as the ASCII characters:
!"@ $%&/()=?'`*+~#-_.,;:{[]}\<> .
The possible special characters also depend on the parameter settings of the param-
eter:
login/password_charset (see chapter 10.1.5.3.)
login/password_downwards_compatibility (see chapter 10.1.5.4.)
SAP-Standard: 1 (One special character required)
XYZ Enterprise: 1 (One special character required)
10.1.2. Password Changes
10.1.2.1. Number of Different Characters: Old/New Password

Parameter: login/min_password_diff
This parameter allows the administrator to specify the minimum number of characters
in which a new password must differ from the old password when the user changes
their password. This parameter does not work when resetting passwords (-> Initial
password).
SAP-Standard: 1
XYZ Enterprise: 1
10.1.2.2. Size of Password History

Parameter: login/password_history_size
This parameter controls the size of the password history. It stores a number of pass-
words determined by the parameter value. The password history is evaluated when a
user chooses a new password: the system rejects the (re-)use of passwords stored
in the password history.
Only passwords chosen by the user (in the course of a previous password change)
are stored in the password history. Passwords assigned by the administrator are not
stored in the password history. When passwords are set by the administrator, there is
no check.
SAP-Standard: 5 (The last 5 passwords are stored)
XYZ Enterprise: 5 (The last 5 passwords are stored)
10.1.2.3. Password Must Be Compliant With Current Password Rules
Parameter: login/password_compliance_to_current_policy
This parameter can be used to control whether, for example, after a change of pass-
word rules, the new policies are checked directly at the next logon or only at the next
password change.
If the parameter is set to the value 1 and it is determined at logon that the current
password does not comply with the currently valid rules, the user is prompted to
change their password.
Value 0: No password check at logon

Value 1: Verifies the password at each login
Exception: Users of type SERVICE and SYSTEM.

SAP-Standard: 1 (Verifies the password at each login)
XYZ Enterprise: 1 (Verifies the password at each login)
10.1.2.4. Password Change Obligation for Single Sign-On (SSO)

Parameter: login/password_change_for_SSO
For non-password-based logon variants (SSO: SNC, X.509, PAS, logon ticket) it was
not checked until now whether the user has a password which would have to be
changed (possible reasons: password is initial or expired).
With this parameter the desired system behavior can be defined as follows:
Value 0: Password change requirement is ignored (=> downward compatible)
Value 1: Popup with selection 2 or 3 (user decides, default)
Value 2: password change dialog only (input: old & new password)
Value 3: Disable password (automatic, no popup)
SAP-Standard: 1 (Popup with selection 2 or 3)
XYZ Enterprise: 1 (Popup with selection 2 or 3)
10.1.3. Logon Restriction
10.1.3.1. Password Validity Period

Parameter: login/password_expiration_time
This parameter controls how long a password remains valid. After the validity period
has expired, a new password must be assigned by the user. The value can be cho-
sen arbitrarily.
Due to the use of Single Sign-On (SSO) it is possible that this parameter has no
practical use.
SAP-Standard: 182 (Days validity period)
XYZ Enterprise: 182 (Days validity period)
10.1.3.2. Waiting Time Between Two Password Changes
Parameter: login/password_change_waittime
This parameter can be used to define the time span (measured in days) after which a
user can change their productive password again.
Only password changes by the user are controlled by this parameter.
If the password is set to a new value by an administrator (initial password), the user
must change the password at the next logon (productive password).
Exception: Users of type SERVICE and SYSTEM.
SAP-Standard: 1 (One password change per day is possible)
XYZ Enterprise: 1 (One password change per day is possible)
10.1.3.3 Password Validity Period of Unused Initial Passwords

Parameter: login/password_max_idle_initial
If the user administrator creates a new User Master Record or sets the password of
an existing User Master Record to a new value, the user must change this so-called
initial password at the next login (to ensure that the password is known only to the
user himself).
With this parameter the maximum time span between the time of password setting or
password reset, and the first login can be defined. After this time period expires, the
message "The initial password has expired" is displayed and the logon is rejected.
Accordingly, a system parameter value of 0 would mean that the initial password
would be valid indefinitely.
Exception: Users of type SERVICE and SYSTEM. Password is valid immediately and
for an unlimited time and can only be changed by the User Administrator (see chap-
ter 9.1.).
SAP-Standard: 7 (Initial password is 7 days valid)
XYZ Enterprise: 7 (Initial password is 7 days valid)
10.1.3.4. Validity Period of Unused Productive Passwords (Manual Logon)

Parameter: login/password_max_idle_productive
If the user changes the password, a so-called productive password is created.

With this parameter you can set the maximum time span in which a user has to log in
manually with their productive password.
A logon with Single Sign On is not considered a manual logon with the productive
password and therefore does not reset the counter.
After this period has expired, the message "The initial password has expired" is dis-
played and the application is rejected. In this case only the User Administrator can
change the password.
SAP-Standard: 90 (Productive password is 90 days valid)
XYZ Enterprise: 90 (Productive password is 90 days valid)
10.1.3.5. Password Lock
Parameter: login/fails_to_user_lock
This parameter determines how many times the user can enter an incorrect pass-
word before the system blocks further password login attempts for that user.
This does not affect the use of Single Sign On techniques.
Possible values are 1 to 99 inclusive.
SAP-Standard: 3 (Trials)
XYZ Enterprise: 3 (Trials)
10.1.3.6. Automatic Unlocking of Users

Parameter: login/failed_user_auto_unlock
This parameter is used to control whether the password lock should be valid only on
the same day it was set (thus limiting the lock to a maximum of 24 hours). Possible
values are 1 (automatic unlocking) and 0 (unlocking required by the User Administra-
tor).
SAP-Standard: 0
XYZ Enterprise: 0
10.1.3.7. Restricted Logon to the SAP NetWeaver Application Server

Parameter: login/server_logon_restriction
This parameter allows to prevent users from logging on to the Application Server.
The User Administrator determines whether all users should be blocked or only a
certain User Group can logon.
It is also possible to allow only those users who have a specific security policy setting
to logon. Already logged in users are not affected.
Restricted logon is useful if users are to be locked out during system maintenance.
Allowed Values:
Value=0 All users can log on to the system (default)
Value=1 Only certain users should access the system.
Value=2 No user should access the system.
Value=3 The external access of users to the system should be restricted
Value=4 The external access of users to the system should be prevented
If the values 1 and 3 are given, the Security Policy Attribute server_logon_privilege
with the value =1 must be assigned to the respective users via an appropriate Secu-
rity Policy to ensure logon (see also 10.3.2.3.7.)
SAP-Standard: 0
XYZ Enterprise: 0
10.1.4. SAP GUI Rules
10.1.4.1. Multiple Logon

Parameter: login/disable_multi_gui_login
The parameter controls whether a user may log on to the SAP system more than
once. By default, multiple logons to the system are allowed (value = 0). It is recom-
mended to prohibit multiple logons (value = 1). A user cannot log on to the system
more than once. However, it is still possible to open multiple sessions on one com-
puter.
SAP-Standard: 0
XYZ Enterprise: 0
10.1.4.2. Exception Users for the Multiple Logon Lock

Parameter: login/multi_login_users
If the parameter Multiple logon (chapter 10.1.4.1.) has been set to the value 1 and
thus multiple logon has been deactivated in general, this parameter can be used to
name users (e.g. administrators) who can log on to the system more than once. The
usernames must be listed separated by commas (","). Spaces between the user-
names are not allowed.
SAP-Standard:
XYZ Enterprise:
10.1.4.3. Logon Failures

Parameter: login/fails_to_session_end
This parameter determines how often the user can enter an incorrect password be-
fore the system disconnects the GUI connection. The parameter value should be
smaller than the value of the password lock parameter login/fails_to_user_lock
(chapter 10.1.3.5.)
Possible values are 1 to 99 inclusive.
SAP-Standard: 3 (Trials)
XYZ Enterprise: 3 (Trials)
10.1.4.4. Automatic Logout

Parameter: rdisp/gui_auto_logout
This parameter can be used to trigger an automatic logoff of a user if they have not
performed any activities on the system for a longer period of time. However, this will
abort all current work of the user. This can lead to the loss of data that has not yet
been saved. The parameter is to be filled with a value in seconds, where the value 0
stands for a deactivation of the automatic logout. It is recommended to use a pass-
word-protected screen saver with an activation time of 15 minutes instead of auto-
matic logout.
SAP-Standard: 0
XYZ Enterprise: 0
10.1.5. Others
10.1.5.1. Define the Properties of SAP*

Parameter: login/no_automatic_user_sapstar
This parameter can be used to define the properties of the standard user SAP*.
If the value "0" is set for this parameter, it is possible to perform a new logon with
SAP* and initial password PASS if the user master record of user SAP* is deleted
(chapter 7.2).
SAP* then has the following properties:

 The user has all authorizations, since no authorization checks are performed.
 The default password PASS cannot be changed.
It is recommended to withdraw the special rights from the standard user (value=1)
and to change the standard password.
SAP-Standard: 1 (Automatic user SAP* is permitted)
XYZ Enterprise: 1 (Automatic user SAP* is deactivated)
10.1.5.2. Activation of the Security Audit Log

Parameter: rsau/enable
With this parameter the Security Audit Log can be activated (value=1).
By default, the Security Audit Log is deactivated (value=0).
From the point of view of auditing the Security Audit Log should be active. The users
to be monitored and the activities to be monitored must be maintained in the audit
profile (transaction RSAU_CONFIG). The evaluation of the Security Audit Log is
done via transaction RSAU_READ_LOG. The maximum size of the Security Audit
Log is defined by the parameter rsau/max_diskspace/local and should be at least
1.000.000
SAP-Standard: 0
XYZ Enterprise: 1
10.1.5.3. Define the Character Set Used for Passwords
Parameter: login/password_charset
Requirement: The parameter is only checked if the system parameter login/pass-

word_downwards_compatibility is set to the value 5. Otherwise the system behaves
as if the parameter is set to the value 2.
This parameter determines the set of characters which may be used to compose a
password:
Value 0: The password may only contain numbers, letters and the following 32
ASCII) special characters exist: !"@ $%&/()=?'`*+~#-_.,;:{[]}\<>|
Value 1: The password may consist of any characters, including national special
characters (e.g. from ISO Latin-1, 8859-1), but all characters that are not in the
above (with login/password_charset = 0) quantity, are mapped to the same (special)
character and are therefore not distinguished. This value is the default value (down-
ward compatible).
Value 2: The password may consist of arbitrary characters; it is internally entered into
the Unicode format UTF-8 converted. If you do not have a Unicode-compatible sys-
tem, but you should note that not all characters may be set can be entered on the lo-
gin screen (restriction due to codepage given by the system language => see SAP
Note 735356).
The system parameter should therefore only be set to the value 2, if it can be en-
sured that all the systems involved can handle the new Support password encoding
SAP-Standard: 1 (Using of any character, incl. special characters)
XYZ Enterprise: 1 (Using of any character, incl. special characters)
10.1.5.4. Downward Compatibility of Passwords
Parameter: login/password_downwards_compatibility
As of Basis Release (SAP_BASIS) 7.0, the system supports 40 character (previously

8) long passwords. Since this release, the password check also distinguishes be-
tween upper- and lower-case letters (previously: automatic conversion to upper case
letters).
The password changes described above are not backwards compatible.

For older releases, parameter settings can be selected which generate passwords
with downwardly incompatible hash values.
If this system is operated together with other systems, for example with a Central
User Administration (CUA), which only supports downward compatible password
hash values, this must be considered when selecting the parameter value (default
value = 1):
Value 0: no downward compatibility; system creates only new (downward incompati-

ble) Password hash values. If no systems of older releases are connected this pa-
rameter setting is considered the most secure setting of SAP recommended.
Value 1: System internally generates additional downward compatible password

hash values but does not evaluate them when logging in with a password (on its own
System) off. This setting is required if this system is used as the central system a
central user administration is used and also older systems are used releases which
only support backward compatible password hash values, are connected to the sys-
tem network.
Value 2: System generates internally additional downward compatible password

hash values and evaluates these, if a registration is made using downward incompat-
ible password failed to check if the login with the downward compatible password
(truncated after 8 characters and converted to upper case) would have been ac-
cepted. This is logged in the syslog; the login fails (detection of downward incompati-
bility problems).
Value 3: System behavior as for parameter value 2, except that the login is consid-
ered successful (bypassing downward incompatibility problems).
Value 4: System behavior as for parameter value 3, except that no syslog logging is
performed.
Value 5: System only issues downward compatible password hash values. The pa-
rameter setting has the effect that passwords are no longer searched for large- and
lower case. This parameter setting should therefore be avoided wherever possible.
SAP-Standard: 0
XYZ Enterprise: 0
10.1.5.5. System Standard Clients
Parameter: login/system_client
This system parameter determines which client is suggested as the system default
client when logging on.
The suggested system standard client can be overwritten by the user.
SAP-Standard: 000 (Client 000 is the system standard client)
XYZ Enterprise: 100 (Client 100 is the system standard client)
10.1.5.6. Possible Logon Languages

Parameter: zcsa/installed_languages
This parameter defines the languages for which a login to the application server is al-
lowed. For example, to allow users to log on in German and French, the parameter
setting DF is required. Possible parameter values are all language abbreviations.
SAP-Standard: DE (Logon language: German and English)
XYZ Enterprise: DE (Logon language: German and English)
10.1.5.7. Standard Logon Language

Parameter: zcsa/system_language
This parameter defines the default logon language for an Application Server.
This parameter setting also defines the language of the logon screen.
The default logon language must be contained in the parameter "Possible logon lan-
guages" zcsa/installed_languages (Chapter 10.1.5.6.).
SAP-Standard: D (Standard logon language: German)
XYZ Enterprise: D (Standard logon language: German)
10.2. Parameters to control Authorization Checks
10.2.1. Deactivation of Authorization Checks

Parameter: auth/no_check_in_some_cases
This parameter can be used to suppress authorization checks. The authorization

checks performed by SAP can be overridden (deactivated) using Transaction SU24.
This assumes that the parameter is set to "Y" to deactivate authorization checks.
SAP-Standard: Y
XYZ Enterprise: Y
10.2.2. Updating the Table USOBX

Parameter: auth/authorization_trace
This parameter controls whether the table USOBX is updated. This table contains the
combination of transactions and authorization objects that are validated during a
transaction. The table is delivered by SAP, so that updating the table in a production
system is not recommended. In addition, updating the table results in high perfor-
mance losses.
SAP-Standard: N (There is no updating of the table)
XYZ Enterprise: N (There is no updating of the table)
10.2.3. Authorization Checks SU53 and SU56

Parameter: auth/tcodes_not_checked
This parameter can be used to make transactions available for analysis purposes.
Transactions SU53 and SU56 are used to analyze failed authorization checks. In
case of a user buffer overflow, the authorizations for these transactions can be lost.
Therefore, it is useful to exclude these two analysis transactions from the authoriza-
tion check using the named parameter.
SAP-Standard:
XYZ Enterprise: “SU53 SU56“
10.2.4. Number of SU53 Shared Buffer Entries per Work Process
Parameter: auth/su53_buffer_entries
This parameter specifies the number of available storage locations in shared memory
for failed authorization checks that can be displayed with transaction SU53.
The parameter is multiplied by the number of work processes defined by the rdisp/
wp_no... parameters.
The result is the number of available storage locations.
The following values are allowed:

Integers from 0, limited by available shared memory.
Value 0 deactivates the ring buffer in shared memory.
In this case, as previously, only the last failed authorization check is.
SU53 can then only be used in SAP GUI logons, not in Web Dynpro applications.
SAP-Standard: 100
XYZ Enterprise: 100
10.2.5. Switching off Authorization Checks for Authorization Objects

Parameter: auth/object_disabling_active
This parameter controls whether the authorization check can be switched off global-ly
for individual objects using the AUTH_SWITCH_OBJECTS transaction.
If the value is set to "Y" or not at all, the authorization check can be switched off. The
security of system use is impaired by switching off the authorization check. There-
fore, it is absolutely necessary to set the parameter to the value N.
SAP-Standard: N
XYZ Enterprise: N
10.2.6. Authorization Check at RFC

Parameter: auth/rfc_authority_check
This parameter determines whether authorization checks are made against the au-
thorization object S_RFC with regard to Remote Function Call (RFC).
For more information, see SAP Note 2216306.
SAP-Standard: 1
XYZ Enterprise: 1 (Authorization check for RFC is active)
10.2.7. User-Specific Long-Term Authorization Trace
Parameter: auth/auth_user_trace
This long-term trace collects client- and user-specific authorization data and stores it
in the database.
During the execution of a program, each authorization check is recorded with the
name and type of the running application, the program location, the authorization ob-
ject, the checked authorization values and the result exactly once per user with the
first timestamp.
The trace database table supports the maintenance of authorization default values
and authorizations, especially for users with special tasks or special authorization ob-
jects, e.g. for communication users in RFC scenarios.
The parameter auth/auth_user_trace can have the following values:

•N: Trace disabled (default)
•Y: Trace activated
•F: Trace activated with filter (SAP Note 2220030). The filters for the recording are
set in transaction STUSERTRACE. Application type, user and authorization objects
can be used as filters. This allows you to examine special scenarios. At least one fil-
ter must be set, otherwise no recording is performed. The data volume and thus the
influence on performance is significantly lower compared to Y.
•Space: Trace deactivated (like N).
Caution:
Activation of the authorization trace without a filter can result in high performance
losses!
SAP-Standard: N
XYZ Enterprise: N
10.2.8. Controls the Authority Check During Call Transaction

Parameter: auth/check/calltransaction
This parameter controls whether during Call Transaction an implicit authorization

check should be performed on the authorization object S_TCODE using the transac-
tion code of the called transaction.
The parameter auth/check/calltransaction can have the following values:

•0: No authorization check is performed.
•1: An authorization check will always be performed.
•2: The authorization check will be performed if the OKFLAG field has the value "Y"
in Table TCDCOUPLES for the calling/called pair. If it has the value "N", or if the field
is not filled at all or an entry is missing, no check will be performed.
•3: Like 2, but if the OKFLAG field is not filled or if a record is missing, a check will be
performed.
The TCDCOUPLES table is only taken into consideration during Call Transaction
without the addition "WITH / WITHOUT AUTHORITY-CHECK".
SAP-Standard: 2
XYZ Enterprise: 2
10.2.9. Logging of Data Changes in Tables
Parameter: rec/client
With this parameter the table logging can be switched on or off client-specifically. De-
pending on the setting of this parameter, the change operations on certain tables
(these must be marked accordingly in the technical settings of the data dictionary us-
ing transaction SE13) are either not logged at all, only in certain clients or in all
clients.
Since tables are to be regarded as outsourced program parts, the table changes of
certain tables must be logged and stored for a period of time. For example, in Ger-
many at least 10 years in accordance with §257 HGB.
SAP Note 112388 contains a list of all tables that are subject to mandatory logging in
accordance with the FI audit guidelines of the DSAG Working Group for Auditing,
Germany.
For these reasons it is recommended to activate logging on the production systems
for all clients (except 000). The logs can be displayed and evaluated using transac-
tion SCU3 (report RSVTPROT). In table DD09L you can see for which tables the log
indicator is set. You can archive the log database using transaction SARA.
Further information can be found in SAP Note 1916.
Possible settings are:

OFF Table logging is switched off, it does not log any change operations,
even if for certain tables the table logging is stored in the Data Dic-
tionary was activated.
ALL Table logging is active for all clients, i.e. all change operations are
logged on tables which are marked accordingly in the Data Dictio-
nary.
Client specific Table logging is only active for the listed clients. A maximum of 10
different clients can be specified.
SAP-Standard: ALL
XYZ Enterprise: 000, 100 (client-specific allocation)
10.2.10. Alternative Language for Missing Descriptions in the Login Language
Parameter: zcsa/second_language
If descriptions are not available in the logon language, the system checks whether a
description is available in the "alternative language".
This parameter setting is used, for example, in the User Information System (transac-
tion SUIM) if role descriptions are missing.
Role descriptions of roles created by authorization administrators - those who have
logged on with the logon language German - are displayed without the parameter,
only for users who have the logon language German. For example, users who have
logged on with the English or French logon language cannot see the role descrip-
tions. This changes when the parameter is set to the value D for German. From this
point on the system checks if there are matching texts in the " alternative language"
for the missing texts in the logon language and displays them.
For international projects, it is recommended that the role descriptions be prepared in

English under German registration and that German be chosen as the "substitute lan-
guage". This way all users will get the same role descriptions with little translation ef-
fort.
The set parameter value should differ from the value of the parameter Default Logon
Language
The set parameter value should differ from the parameter standard registration lan-
guage value zcsa/system_language (chapter 10.1.5.7.).
SAP-Standard: E (alternative-language: English)
XYZ Enterprise: E (alternative-language: English)
10.3. Security Policy
A security policy is a collection of security policy attributes, and their values.

It replaces the behavior definition by system parameters once a security policy has
been assigned to the user master record. From then on, the security policy attributes
determine the desired behavior. System parameter values are therefore only relevant
for those user master records that have not been assigned a security policy.
System parameters that are not replaced by a security policy attribute retain their
function.
10.3.1. Security Policy Attributes
Each security policy has a number of security policy attributes that can be used to
control the following behavior:
 Password Rules
 Password Changes
 Logon Restrictions
The individual security attributes can also be described directly by selecting an at-
tribute and then calling the input help in the system.
10.3.2. Definition of Security Policy Attributes
10.3.2.1. Security Policy Attributes for the Definition of Password Rules

Dependencies
The sum of the values of the following security policy attributes must not exceed the maxi-
mum password length
(40 respectively 8, if login/password_downwards_compatibility = 5):
 MIN_PASSWORD_DIGITS
 MIN_PASSWORD_LETTERS respectively the sum of:
MIN_PASSWORD_LOWERCASE and MIN_PASSWORD_UPPERCASE
 MIN_PASSWORD_SPECIALS
10.3.2.1.1. Check for Use “Prohibited Passwords”
Security Policy Attribute: CHECK_PASSWORD_BLACKLIST
When new passwords are assigned (by the administrator) or when a password is
changed (by the user), the password rules are checked.
One part of the password rules is the check whether the password is in a negative list
("prohibited passwords"). This security policy attribute can be used to specify whether
such a check should be performed.
Value = 0, no evaluation of the “forbidden passwords” list

Value = 1, table USR40, “forbidden password” will be evaluated
When a password is assigned by the administrator, only a warning is displayed when

the password is found in the negative list; the administrator can ignore this warning.
There are no equivalent system parameters for this Security Policy Attribute.
SAP standard: 1 (evaluation of "prohibited passwords is performed)
10.3.2.1.2. Minimum Password Length

Security Policy Attribute: MIN_PASSWORD_LENGTH
This Security Policy Attribute determines the minimum length of a password.

It is effective when assigning new passwords as well as when changing or resetting
existing passwords.
Allowed value range: 3 – 40

(if the system parameter login/password_downwards_compatibility was set to the
value 5, the permissible value range is: 3 - 8)
This Security Policy Attribute replace the System Parameter:

login/min_password_lng (see chapter 10.1.1.2.).
SAP-Standard: 10 (Minimum password length= 10 characters)
10.3.2.1.3. Minimum Number of Characters in Passwords

Security Policy Attribute: MIN_PASSWORD_DIGITS
This Security Policy Attribute determines the minimum number of digits (0-9) that
must be included in a password.
It is effective both when creating new passwords and when changing or resetting ex-
isting passwords.
Allowed value range: 0 - 40


login/min_password_digits (see chapter 10.1.1.3.).
SAP-Standard: 1 (One minimum number of digits required)
10.3.2.1.4. Minimum Number of Letters in Passwords
Security Policy Attribute: MIN_PASSWORD_LETTERS
This Security Policy Attribute determines the minimum number of ASCII letters (A-Z
and a-z) that must be included in a password.
It is effective when creating new passwords, changing or resetting existing pass-
words.


login/min_password_letters (see chapter 10.1.1.4.).
SAP-Standard: 1 (One minimum number of ASCII-letter required)
10.3.2.1.5. Minimum Number of Lower-Case Letters in Passwords

Security Policy Attribute: MIN_PASSWORD_LOWERCASE
This Security Policy Attribute determines the minimum number of ASCII lowercase
letters (a - z) that must be included in a password.
words.


login/min_password_lowercase (see chapter 10.1.1.5.).
SAP-Standard: 1 (Lowercase letter required in password)
10.3.2.1.6. Minimum Number of Capital Letters in Passwords

Security Policy Attribute: MIN_PASSWORD_UPPERCASE
This Security Policy Attribute determines the minimum number of ASCII capital let-
ters (A - Z) that must be included in a password.
words.


login/min_password_uppercase (see chapter 10.1.1.6.).
SAP-Standard: 1 (Capital letter required in password)
10.3.2.1.7. Minimum Number of Special Characters in Passwords
Security Policy Attribute: MIN_PASSWORD_SPECIALS
This Security Policy Attribute determines the minimum number of special characters
that must be included in a password.
Special characters are all characters that are neither digits (0-9) nor ASCII letters (A-
Z or a-z).
This includes national special characters and Unicode characters (if it is a Unicode
system) as well as the ASCII characters:
!"@ $%&/()=?'`*+~#-_.,;:{[]}\<>|
words.


login/min_password_specials (see chapter 10.1.1.7.).
SAP-Standard: 1 (One special character required)
10.3.2.2. Security Policy Attribute for the Definition of Password Changes
10.3.2.2.1. Number of Different Characters when Changing

Security Policy Attribute: MIN_PASSWORD_DIFFERENCE
If a user wants to change their password (or was prompted by the system to change
their password), they must enter both the current password and the new password.
The presence of both passwords as plain text information allows to check in how
many characters both differ.
The number of different characters is calculated as follows:
Both character strings are brought to maximum coverage (by rotation) (search for
longest common character string). The number of characters that differ (in some
places) is the number of characters that are searched for.

value 5, the Allowed value range is: 1 - 8)

login/min_password_diff (see chapter 10.1.2.1.).
SAP-Standard: 1 (1 character must be different)
10.3.2.2.2. Size of the Password History
Security Policy Attribute: PASSWORD_HISTORY_SIZE
This Security Policy Attribute specifies the size of the password history.
The password history is evaluated when a user chooses a new password. The sys-
tem rejects the (re-)use of passwords stored in the password history. Only passwords
chosen by the user (in the course of a previous password change) are stored in the
password history.
Passwords assigned by the administrator are not stored in the password history.
When setting passwords by the administrator, there is no check whether the new
password to be set has been used by the user before; otherwise the administrator
would get knowledge of the user's old password.

login/password_history_size (see chapter 10.1.2.2.).
SAP-Standard: 5 (The last five passwords are saved)
10.3.2.2.3. Password Change after Rule Changes

Security Policy Attribute: PASSWORD_COMPLIANCE_TO_CURRENT_POLICY
This security policy attribute can be used to control whether the system should check
whether the password used for a password-based logon complies with the current
password rules and whether, if necessary, the user should be prompted to change
the password.
Users of the type 'SERVICE' and 'SYSTEM' are in principle exempt from the pass-
word change obligation and therefore not affected by this regulation.
0 = No verification takes place.

1 = There is a check whether the current password complies with the new rule
corresponds.

login/password_compliance_to_current_policy (see chapter 10.1.2.3.).
SAP-Standard: 1 (Verifies the password at each login)
10.3.2.2.4. Password Change Requirement for Single Sign-On logins
Security Policy Attribute: PASSWORD_CHANGE_FOR_SSO
When using password-based login, the system checks whether the user's password
needs to be changed (e.g. because the password is initial or has expired).
For non-password-based logon procedures (Single Sign-On (SSO), e.g. using X.509
certificate, logon ticket, SNC, SAML, etc.) it was not checked until now whether the
user has a password which he/she would have to change.
This security policy attribute can be used to define the desired system behavior:
0 = Password change requirement is ignored (downward compatible)
1 = User decides: Change or Delete (default setting)
2 = User must change the password
3 = The password is automatically deleted

login/password_change_for_SSO (see chapter 10.1.2.4.).
SAP-Standard: 1 (User decides: Change or Delete)
10.3.2.2.5. Interval Regularly, Password Changes

Security Policy Attribute: PASSWORD_CHANGE_INTERVAL
This security policy attribute determines whether and after how many days (since the
last password change) the user will be prompted to change the password again.
Users of the type SERVICE and SYSTEM are not affected by this rule; they will
never be prompted to change their password.
If the value is set to 0 the password will not expire and therefore the user will not be
asked to change the Production password.
Allowed value range: 0 - 1000 (specify in days)

login/password_expiration_time (see chapter 10.1.3.1.).
SAP-Standard: 182 (Days validity period)
10.3.2.2.6. Minimum Waiting Time for Password Change
Security Policy Attribute: MIN_PASSWORD_CHANGE_WAITTIME
This security policy attribute can be used to specify the time span (measured in days)
after which a user can change their password again. Only password changes initi-
ated by the user are considered.
If the password is set to a new value by an administrator, the user must change the
password the next time they log on (except for SERVICE and SYSTEM users).
If the password change is forced by the system (e.g. after a specified period of time
or if a password change is required due to stricter password rules), the password can
also be changed immediately.
Allowed value range: 1 - 1000 (specification in days)

login/password_change_waittime (see chapter 10.1.3.2.).
SAP-Standard: 1 (One day waiting time for password changes)
10.3.2.3. Security Policy Attributes for the Definition of Registration

Restrictions
10.3.2.3.1. Validity of Unused Initial Passwords

Security Policy Attribute: MAX_PASSWORD_IDLE_INITIAL
If the User Administrator creates a new user account or sets the password of an ex-
isting user account to a new value, the user must change this so-called initial pass-
word at the next logon.
This Security Policy Attribute can be used to specify the maximum time span be-
tween the time of the password (reset) and the next login with the initial password.
After this time period has expired, the message "The initial password has expired" is
displayed and the logon is rejected.
Allowed value range: 0 - 24000 (specification in days)

If the value 0 is assigned, initial passwords are valid indefinitely.

login/password_max_idle_initial (see chapter 10.1.3.3.).
SAP-Standard: 7 (Initial password is 7 days valid)
10.3.2.3.2. Validity of Unused Productive Passwords
Security Policy Attribute: MAX_PASSWORD_IDLE_PRODUCTIVE
If the user changes the password (but not if the password is set by the User Adminis-
trator), a so-called Productive Password is created. This password can be changed
again by the user at the earliest after a definable waiting period.
This Security Policy Attribute can be used to specify the maximum time span
between the time of the last password change and the next logon with this password.
After this time period expires, the message "Password has not been used for a long
time and is therefore deactivated" is displayed and the logon is rejected.
Allowed value range: 0 - 24000 (specified in days)

If the value 0 is assigned, productive passwords are valid for an unlimited time.
Dependencies
The PASSWORD_CHANGE_INTERVAL Security Policy Attribute specifies the time
period after which the system prompts the user to change their password. It is recom-
mended to set PASSWORD_CHANGE_INTERVAL to a value less than the value of
this Security Policy Attribute (MAX_PASSWORD_IDLE_PRODUCTIVE).

login/password_max_idle_productive (see chapter 10.1.3.4.).
SAP-Standard: 90 (Productive password is 90 days valid)
10.3.2.3.3. Maximum Number of Failed Login Attempts

Security Policy Attribute: MAX_FAILED_PASSWORD_LOGON_ATTEMPTS
Passwords can be guessed, so it is necessary to limit the number of failed password

login attempts. A password lock is set after the upper limit defined by this security
policy attribute is exceeded.

login/fails_to_user_lock (see chapter 10.1.3.5.).
SAP-Standard: 3 (Lockout after 3 failed login attempts)
10.3.2.3.4. Automatic Unlocking of Users
Security Policy Attribute: PASSWORD_LOCK_EXPIRATION
After exceeding a definable upper limit, a password lock is set. Normally, a password
lock remains in effect indefinitely and must be manually released. However, it is also
possible to set a maximum validity period for password locks.
Allowed values:
0 = Password lock must be explicitly released
1 = Password lock is valid for a maximum of 24 hours (automatic unlocking)

login/failed_user_auto_unlock (see chapter 10.1.3.6.).
SAP-Standard: 0 (Password lock must be removed)
10.3.2.3.5. Disable Password Logon

Security Policy Attribute: DISABLE_PASSWORD_LOGON
This Security Policy Attribute can be used to prevent users from logging on to the
system with a password.
Allowed values:
0 = Password logon is allowed (if possible)
1 = Password login is disabled (i.e. is not possible)

login/disable_password_logon und login/password_logon_usergroup
SAP-Standard: 0 (Password login allowed (if possible))
10.3.2.3.6. Disable Ticket Logon
Security Policy Attribute: DISABLE_TICKET_LOGON
This Security Policy Attribute can be used to prevent a user log on to the system us-
ing a logon ticket or an authentication assertion ticket.
Allowed values:
0 = Ticket logon is allowed (if possible)
1 = Logon tickets are rejected (authentication assertion tickets are not affected)
2 = Both logon tickets and authentication assertion tickets are rejected
Dependencies
Whether a user can log on to the system using a logon ticket or an authentication as-
sertion ticket also depends on other factors:
 System Parameter login/accept_sso2_ticket must be set to the value 1
 Trust relationship with the ticket-issuing system must be established
 The ticket must be received within the validity period

There is no equivalent System Parameter for this Security Policy Attribute.
SAP-Standard: 0 (Ticket logon is allowed (if possible))
10.3.2.3.7. Restricted Logon to the SAP NetWeaver Application Server

Security Policy Attribute: SERVER_LOGON_PRIVILEGE
This Security Policy Attribute is only relevant if the value of the corresponding Sys-
temp Parameter (SERVER_LOGON_RESTRICTION - see 10.1.3.7) is set to 1 or 3.
In these cases only users who have assigned this attribute with the value 1 have ac-
cess to the system. By default, no privilege is assigned (i.e.: value = 0).
SAP-Standard: 0 (Ticket logon is allowed (if possible))
10.3.3. Conversion Table Security Policy Attribute – System Parameters
Password Rules Definition
Security Policy Attribute Description Standard Replaced System Parameters

CHECK_PASSWORD_BLACKLIST Check of password-Blacklist (1) 1 n/a
MIN_PASSWORD_LENGTH Minimum length of passwords 10 login/min_password_lng
MIN_PASSWORD_DIGITS Minimum number of numbers 1 login/min_password_digits
MIN_PASSWORD_LETTERS Minimum number of letters 1 login/min_password_letters
MIN_PASSWORD_LOWERCASE Minimum number of lower cases 1 login/min_password_lowercase
MIN_PASSWORD_UPPERCASE Minimum number of upper cases 1 login/min_password_uppercase
MIN_PASSWORD_SPECIALS Minimum number of special characters 1 login/min_password_specials
User behavior regarding password changes definition

MIN_PASSWORD_DIFFERENCE No. of Different Chars When Changing 1 login/min_password_diff
PASSWORD_HISTORY_SIZE Size of password history 5 login/password_history_size
PASSWORD_COMPLIANCE_TO_CURRENT_POL-
Password changing after tightening the rules 1 login/password_compliance_to_current_policy
ICY
Obligation to change the password while
PASSWORD_CHANGE_FOR_SSO 1 login/password_change_for_SSO
SSO-logon
PASSWORD_CHANGE_INTERVAL Interval of periodical password changing 182 login/password_expiration_time
Minimum waiting time while password
MIN_PASSWORD_CHANGE_WAITTIME 1 login/password_change_waittime
changing
Login restrictions definition

MAX_PASSWORD_IDLE_PRODUCTIVE Validity of not using Production passwords 90 login/password_max_idle_productive
MAX_PASSWORD_IDLE_INITIAL Validity of not using initial passwords 7 login/password_max_idle_initial
MAX_FAILED_PASSWORD_LOGON_ATTEMPTS Maximum number of failed logins 3 login/fails_to_user_lock
PASSWORD_LOCK_EXPIRATION Automatic unlocking of users 0 login/failed_user_auto_unlock
DISABLE_PASSWORD_LOGON Prevent password login 0 login/disable_password_logon (2)
DISABLE_TICKET_LOGON Prevent ticket login 0 n/a
SERVER_LOGON_PRIVILEGE Restricted Application Server logon 0 n/a
1 Table USR40
2 In this context, the system parameter login/password_logon_usergroup must also be observed
11. Emergency plan
In the event of serious errors in the Productive SAP environment, which cannot be
corrected with the defined authorizations of the individual departments and/or cannot
be reproduced in the SAP Development or Quality Systems, the Emergency Concept
may be activated by skilled persons.
The Emergency Concept may also be activated if the Productive SAP system is not
available and no company SAP Basis employee is available for troubleshooting
within an acceptable time, whereby support from a skilled third party is required (ex-
ternal consultant, SAP, etc.). These third-party users must have extensive authoriza-
tions in the SAP system.
11.1. Emergency User

For situations that cannot be resolved across modules or that occur outside normal
business hours, there is also the Emergency User SAPRES (see chapter 9.5.
SAPRES). The user SAPRES has full authorization (profiles SAP_ALL and
SAP_NEW) and is added to the user group SUPER and monitored via the Security
Audit Log (see also chapter 10.1.5.2. Activating the Security Audit Log). The user
SAPRES is set up on all systems and their clients (exception client 000).
11.2. Auditing of the Emergency User

Due to the extensive authorizations of the Emergency User, it is absolutely neces-
sary to monitor the use of the software and to document its contents. The documen-
tation must prove which activities have been carried out on the system by the Emer-
gency User or holder of the Emergency Roles. The Security Audit Log serves this
purpose. The logs serve to ensure traceability and must be kept in written form for a
period of at least 10 years (§ 257 HGB). After use, the logs must be printed out and
archived by the system administrator or a person authorized by him.
The transactions RSAU_CONFIG (Configure Security Audit Log) and

RSAU_READ_LOG (Read Security Audit Log) are used to monitor the Emergency
User (see also point 10.1.5.2.).
12. Authorization Controlling
12.1. Change history

Change histories show direct changes to a user master record, role or authorization.
Indirect changes are also displayed, such as changes to other authorization elements
that refer to the element for which the change history is to be created.
For example, the change history for a user master record contains not only direct
changes to the master record, but also changes to the profiles and authorizations
stored in the User Master Record.
To display a list of changes to user master records, roles and authorizations, use the
information system:
Tools > Administration > User Maintenance > Info System > Change Documents >
For Roles, For Authorizations, For Role Assignment, User > For Users
The system logs the following changes:
 Authorization changes for a user
Changes are logged for the fields User Password, User Type, User
Group, Validity Period and Profile.
 Role changes
The changes, for example, to added authorizations in a single role or
deleted user assignments are logged.
 Authorization changes
Changes in the authorization values and thus the characteristics of indi-
vidual fields, which essentially control the access rights, are logged.
For all analysis, the time period for which the change history is to be displayed can
be defined.
12.2. Locking inactive users

Users who have not logged on to the system for more than 90 days will be locked by
the user administrator.
12.3. Review of authorizations by the Lines of Business
The Segregation of Duties in user creation, role creation and authorization assign-
ment give the department an important task in checking the assigned authorizations.
The following questions are the focus of attention:
 Which data do the users within their own area access?

 Which users of other departments access the data of the department?
For this purpose, an authorization review must be carried out at least once a year by
the Authorization Coordinator. The authorization review serves to check whether only
authorized users have access to the respective data.
In particular, the following points should be checked:
 Which users were currently assigned to the respective department (user

group)?
 Which Composite Roles are assigned to these users?
 Which users from other departments have Single Roles in the area to be
checked?
12.4. Review of the Authorization Concept

The customer’s IT department is responsible for checking the implementation of the
described Authorization Concept.
In order to be able to guarantee the security and thus the quality of the Authorization
Concept in the long term, it is essential to regularly check the SAP systems for com-
pliance with the described specifications.
Compliance with the specifications is the prerequisite for protecting the stored data
and for meeting the requirements of the various audit authorities (e.g. External Audi-
tors, Internal Auditors, Data Protection Officer).
The following issues should be reviewed regularly (at least twice a year):
1. Assignment of illegal roles on the production system (roles created for the de-
velopment or test systems have been assigned to users in the production sys-
tem, recognizable by the abbreviation ZD*, ZQ*, YD* or YQ*).
Check using transaction SUIM or PFCG.
Action: Immediate deletion of the roles.
2. Non-compliance with naming conventions, e.g. for generated authorization

pro-files (T*) or roles (see Chapter 6 Naming Conventions).
Check using transaction SUIM.
Action: Correct the wrong names using PFCG.
3. Manual assignment of Authorization Objects to Single Roles.

Check using table AGR_1251 or a Transaction to be created for this purpose.
Action: Maintain the check indicators with transaction SU24.
4. Missing assignment of self-created tables to Authorization Groups.
Check using Transaction SE54.
Action: Maintain the assignment to the Authorization Groups using transaction
SE54 (authorization group &nc&).
5. Verification of the self-created Transactions for sufficient implementation of

authorization checks.
Check by analyzing the source code of the Transactions.
Action: Implement sufficient authorization checks (Authority Check).
6. Verification the self-created Transactions for maintenance of the required

Check Indicators.
Check using Transaction SU24.
Action: Determine the authorization by means of Authorization Trace (STAU-
THTRACE) and enter the Check Indicators by SU24.
7. Checking the systems for compliance with the System Parameters described
in chapter 10.
Check Report RSPARAM.
Action: Adjust the System Parameters to the guidelines.
8. Checking the Production Systems for the assignment of the Authorization Ob-
ject S_QUERY with Activity 02 (see chapter 7.3.3).
Action: Execute the Report S_BCE_68001422 (Roles by Authorization Val-
ues).
www.sap.com/contactsap
© 2021 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 or an SAP affiliate company.
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 or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company 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.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality
are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.

S4H - 876 Authorization Concept Template - SAP S4HANA Cloud, Private Edition

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

S4H - 876 Authorization Concept Template - SAP S4HANA Cloud, Private Edition

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S4H - 876 Authorization Concept Template - SAP S4HANA Cloud, Private Edition

Uploaded by

Copyright:

Available Formats

SAP Customer

Authorization Concept Template

Version Date Change

5. LIMITS OF AN AUTHORIZATION CONCEPT........................................................................................13

1.1. Objectives of An Authorization Concept

Overall, an authorization concept should support the correctness, completeness, and

- Financial losses due to error, mistake or negligence

1.2. Out of Scope

1.3. Target Groups

The Authorization Coordinators support the Authorization Administrators by the cre-

2.2. Authorization Object

Authorization Objects enable complex checks of an authorization, bound to several

2.4. Authorization Profile

2.5.1. Transaction (S_TCODE)

2.5.2. OData Service (S_SERVICE)

2.5.3. Web Dynpro Application (S_START)

2.6. Fiori Specific Components (Front-End)

2.6.1. Fiori Launchpad (FLP) Catalog

2.7. Single Roles

2.8. Composite Roles

3. STRUCTURE OF THE SAP SYSTEM LANDSCAPE

3.1. The 3 Tier System Landscape

The systems are described in detail:

Area Development Quality Assurance Production

3.2. Front-End & Back-End Server Definition

Front-End Server (Gateway Server)

Back-End Server (Application Server)

 Quality System (Q-System)

 Production System (P-System)

A Composite Role should be set up in such a way that it corresponds to a single

When adding applications to roles, it should always be checked whether data is

Manually adding Authorization Objects in Single Roles is generally not allowed

5. LIMITS OF AN AUTHORIZATION CONCEPT

5.1. Authorization Check and Authorization Trace

Another tool that can be used to determine authorization issues is an Authorization

5.3. Additional Implementation of Authorization Checks in SAP Standard Appli-

1. Creation of a Customer Incident to SAP

2. Using a User Exit

3. The Creation of Application Variants

4. Modification of SAP Standard Applications

However, there are the following exceptions:

Note the User groups = max. 12 characters.

XXXX_SUPER Use for emergency users, SAPADM, SAPRES,

Note, the Composite Role description = max. 30 digits.

Y P XYZ CO _ CONTROLLER _ BUKRS000

If the authorizations of a Single Role include differentiation by values (authorization

Example: ZPXYZCO_CONTROLLER_MASTER_D (27 digits)

Note, Single Role descriptions = max. 30 digits.

Module indicator (2 to 3 digits)

Name of the profile = max. 10 characters

Module indicator (2 to 3 digits)

Activity indicator (1 digit)

Internally generated applications are created with Z or Y depending on the further

Name of application = max. 20 digits

Authorization group name = max. 4 characters

7.1 Access to SAP Standard Roles and Profiles

7.2. SAP Standard Users