Sap security-administration

ABC Corp Corporation

SAP R/3 Security

SAP R/3 Security Administration
Standard Operating Procedures

Page 1

of 59


SAP R/3 Security

1. OBJECTIVE...........................................................................................................................................................................5
2. ABC CORP SAP R/3 SECURITY STRATEGY................................................................................................................5
3. SCOPE.....................................................................................................................................................................................5
4. APPROVAL PROCESS........................................................................................................................................................5
5. SECURING SAP CLIENTS AND SYSTEMS....................................................................................................................6
5.1 CLIENT OWNERSHIP.................................................................................................................................................... 6
5.2 DEVELOPMENT ROLE DEFINITIONS............................................................................................................................. 6
Security Administrator..........................................................................................................................................................6
Basis Administrator..............................................................................................................................................................6
ABAP/4 Developer................................................................................................................................................................6
Functional User ...................................................................................................................................................................7
Client Independent Configurator.........................................................................................................................................7
Client Dependent Configurator............................................................................................................................................7
Configurator.........................................................................................................................................................................7
5.3 SYSTEM SECURITY..................................................................................................................................................... 7
Sandbox.................................................................................................................................................................................7
Development (Dev2 010, 100)..............................................................................................................................................7
Training.................................................................................................................................................................................8
Integration............................................................................................................................................................................8
Production.............................................................................................................................................................................9
5.4 THE TRANSPORT SYSTEM........................................................................................................................................... 9
6. USER GROUP SECURITY...............................................................................................................................................11
7. NAMING CONVENTIONS................................................................................................................................................12
7.1 SAP R/3 PROFILE GENERATOR ACTIVITY GROUPS....................................................................................................12
7.2 -.............................................................................................................................................................................. 13
Authorizations.....................................................................................................................................................................13
Single profiles.....................................................................................................................................................................13
Composite Profiles..............................................................................................................................................................14
8. SAP SECURITY ORGANIZATION.................................................................................................................................15
9. SAP ACCESS AUTHORIZATION/PROCESS (UNDER DEVELOPMENT).............................................................16
9.1 ..............................................................................................................................................................................................16
9.2 ...............................................................................................................................................................................................16
9.3 ADMINISTRATIVE PROCEDURES FOR SAP ACCESS..........................................................................................16
THIS ITEM IS ON THE SECURITY TEAMS TO DO LIST.............................................................................................17
10. ABC CORP SAP R/3 SECURITY ACCESS FORM ....................................................................................................18
11. LOG-ON PARAMETER ADMINISTRATION.............................................................................................................19
12. USER MASTER RECORDS............................................................................................................................................20
12.1 CREATING A USER MASTER RECORD...................................................................................................................... 20
12.2 ADDRESS............................................................................................................................................................... 20
12.3 LOGON DATA......................................................................................................................................................... 21
Page 2

of 59


SAP R/3 Security

Initial Password..................................................................................................................................................................21
User Group.........................................................................................................................................................................21
Valid From/Valid To...........................................................................................................................................................21
12.4 DEFAULTS.............................................................................................................................................................. 22
Output Device.....................................................................................................................................................................22
Print Controller Functions.................................................................................................................................................22
Decimal Notation................................................................................................................................................................22
Date Format........................................................................................................................................................................22
12.5TASK PROFILE.......................................................................................................................................................... 22
12.6PROFILES................................................................................................................................................................. 22
12.7 USER PARAMETERS................................................................................................................................................ 23
13. PASSWORD ADMINISTRATION...................................................................................................................................24
13.1
13.2
13.3
13.4

DEFAULT PASSWORD REQUIREMENTS..................................................................................................................... 24
SYSTEM PASSWORD PARAMETERS........................................................................................................................... 24
PASSWORD CHANGES............................................................................................................................................. 24
IMPERMISSIBLE PASSWORDS................................................................................................................................... 24

14. SAP SYSTEM SUPPLIED SUPER USER(S).................................................................................................................26
14.1 SAP*...................................................................................................................................................................... 26
14.2 DDIC (DATA DICTIONARY)..................................................................................................................................... 26
15. HELP DESK PROCEDURES..........................................................................................................................................27
15.1 RESETTING USER PASSWORDS................................................................................................................................. 27
15.2 UNLOCKING USER IDS............................................................................................................................................. 27
15.3 RESOLVING ACCESS ISSUES/PROBLEMS................................................................................................................... 27
16. SECURITY CHANGE CONTROL.................................................................................................................................29
16.1 CREATING/MAINTAINING ACTIVITY GROUPS........................................................................................................... 29
16.2 CREATING NEW DEVELOPMENT ROLES................................................................................................................... 29
DETAILED STEPS/INSTRUCTIONS...................................................................................................................................30
16.3UPDATING DEVELOPMENT ROLES (EXCEPT GENERAL USER).....................................................................32
IMPORTANT – THE NUMBER OF CLIENTS WHERE THE TRANSPORT NEEDS TO BE APPLIED MAY
HAVE CHANGED SINCE THE CREATION OF THESE PROCEDURES. REVIEW THE SYSTEM/CLIENT
LANDSCAPE TO ENSURE THAT ALL CLIENTS ARE PROPERLY UPDATED. 16.4 UPDATING GENERAL
USER DEVELOPMENT ROLE.............................................................................................................................................34
16.5 CREATING/MAINTAINING AUTHORIZATIONS AND PROFILES.....................................................................................36
16.6 TRANSPORTING ACTIVITY GROUPS ....................................................................................................................36
16.7 MAINTAINING USER TO ACTIVITY GROUP RELATIONSHIPS......................................................................................39
16.8 AUTHORIZING /VALIDATING CHANGES................................................................................................................... 39
17. SECURITY FOR NEW ABAP/4 PROGRAMS ............................................................................................................40
17.1 ASSIGNING AUTHORIZATION GROUPS..................................................................................................................... 40
17.2 CONFIGURING AUTHORITY CHECKS........................................................................................................................ 40
18. SECURITY FOR NEW SAP TABLES ..........................................................................................................................41
18.1 EXISTING SAP TABLES........................................................................................................................................... 41
Page 3

of 59


SAP R/3 Security

18.2 NEW SAP TABLES.................................................................................................................................................. 41
19. SECURITY FOR NEW SAP TRANSACTIONS .........................................................................................................42
19.1 CONFIGURE THE TRANSACTION TO MEET S_TCODE REQUIREMENTS.....................................................................42
19.2 IDENTIFY AND CONFIGURE CHECK OBJECT SECURITY (TRANSACTION SE93 AND TABLE TSTCA)............................42
20. SAP R/3 INTERNET SECURITY....................................................................................................................................43
21. APPLICATION LINK ENABLING (ALE) ...................................................................................................................44
22. BATCH/JOB SCHEDULING SECURITY.....................................................................................................................45
22.1 ON-LINE/SCHEDULED PROGRAMS............................................................................................................................ 45
22.2 BATCH INPUT SESSIONS.......................................................................................................................................... 46
23. OUTPUT/SPOOL SECURITY.........................................................................................................................................47
24. SECURITY MONITORING ACTIVITIES....................................................................................................................48
24.1 ADDITIONAL SECURITY MONITORING REPORTS....................................................................................................... 52
24.2 SENSITIVE SECURITY MONITORING PROGRAMS........................................................................................................ 52
25. INSTALLING NEW RELEASES....................................................................................................................................54
APPENDIX A – ALE SYSTEM IDENTIFIERS....................................................................................................................55
APPENDIX B – THREAD LEADERS...................................................................................................................................56
APPENDIX C - GLOSSARY...................................................................................................................................................57

Page 4

of 59


Overview

1. Objective
To ensure that SAP R/3 security provides an efficient and effective structure for ensuring the
integrity, accuracy, and availability of the information within SAP.
2. ABC Corp SAP R/3 Security Strategy
ABC Corp SAP R/3 security will be implemented through the definition of security roles. Security
roles will represent jobs/positions. Each job/position will represent a logical grouping of SAP R/3
transactions required for that job/position to carry out defined business activities and responsibilities.
User access will be controlled through the assignment of roles to users. Additionally, responsibilities
will be assigned to restrict organizational access. For example, the position ‘Material Manager’ will
be restricted to each plant, preventing users from creating/maintaining inventory outside of their plant
location.
3. Scope
This document contains SAP R/3 Security Development and Administration procedures. As the SAP
R/3 projects are executed, this document will require review and enhancement. The document
includes the following topics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Objectives
SAP R/3 Security Strategy
Definitions
System and Client Security
User Group Strategy
Naming conventions
SAP Security Organization
Requesting SAP access
Security Parameter Administration
User administration
Password administration
Security administration structure
Manual security administration
Help Desk Procedures
Security Change Control
Security Monitoring
Release Impact on Security

4. Approval Process
Standard operating procedures must be properly reviewed and approved prior to production
implementation. SAP R/3 Security Administration procedures require a two-level approval process:
SAP IT Infrastructure team and Business Process Team or Business partner .
At this point, the Director responsible for SAP Infrastructure will conduct the first level of approval.
IT management includes two positions, the Director and Vice President of Information Technology.
Page 5

of 59

ABC Corp

Client and System Security Strategy

5. Securing SAP Clients and Systems
Security administration for SAP will be based on the client and system structure for ABC Corp.
There are five basic systems used to support SAP: Sandbox, Development, Training, Integration/QA
and Production. While this system landscape may grow over time, SAP application security will use
this baseline model. Clients are defined within each system and the number of clients defined to a
system can vary. The client and system structure requires security administration to not only consider
the security requirements for the system, but also include client specific security requirements. And,
the requirements at the client level can vary within the same system.
The primary concern for securing clients and systems is restricting ABAP/4, Basis, Configuration,
Functional, Security and Table access based on the definition and use of each client and system. This
access will be administered through the definition of development roles and production Job roles.
The design and administration of these roles will be controlled using the SAP R/3 Profile Generator.
5.1 Client Ownership
As each client is created, an ‘owner’ is appointed by the Basis team. The owner will have the
final authorization or rejection capability for all access requests. Any questions or potential
security risks regarding a request or modification of user access will be directed to the client
owner.
The Basis team will be responsible for administering and maintaining client ownership
assignments. Periodically, the Security Administrator will meet with the Basis Administrator to
review and update client ownership.
5.2 Development Role Definitions
The purpose of the development roles to restrict SAP_ALL and provide the Administrators and
Development Teams only with the access needed to completed their job responsibilities.
Security Administrator
These users have the ability to design and configure authorizations, profiles, and users within the
SAP systems and clients. These users will also have full access to client dependent and
independent tables and with limited access to basis and security administration transactions.
Basis Administrator
These users have the ability to support all Basis Administration functions except functional
configuration and security administration. Additionally, Basis Administrators require and will
have access to ABAP/4 programming, database management system, operating system, tables
and all Basis Administration related transactions.
ABAP/4 Developer
These users will have the ability to develop and maintain ABAP/4 programs, screens, menus and
transactions. Additionally, they will have access to the Workbench Organizer and ABAP/4 Data
Dictionary, which is required in order to execute development activities.

Page 6

of 59

ABC Corp


Functional User
These users have full functional access except for the following:
 Basis Administration
 Security Administration
 Oracle Database
 Client Independent Tables
 Corrections and Transport System
Client Independent Configurator
This specific user will have access to configure client independent tables. This access, when
granted for a client in a system, will allow the user to make changes that impact all clients for
that particular system. The authorization object S_TABU_CLI grants the specific security for
this role. This access should be limited to key project team members.
Client Dependent Configurator
Users with this access will be able to change SAP data via the transaction SM31. The role will
require a combination of S_TCODE for SM31 and access to the authorization object
S_TABU_DIS. Granting table access should be limited to the proper authorization group.
Granting ‘*’ access to the table authorization group will allow users to maintain all tables defined
in SAP, including Basis and Security related tables.
Configurator
Users will be able to access SAP’s Implementation Management Guide (IMG). Access to the
IMG is required in order to configure SAP functionality. Configuration access will require a
combination of access to the IMG and client dependent table configuration.
5.3 System Security
Sandbox
The Sandbox system is primarily used for self-training and user exploration. Typically, the
Sandbox system and clients will contain these types of users:
 Security Administrator
 Basis Administrator
 Functional User
 ABAP/4 Developer
 Client Independent Configurator (if necessary)
 Client Dependent Configurator
 Configurator
The Correction and Transport (CTS) function will be turned off in the Sandbox system. Client
independent configuration access will be allowed if there are no other clients that will be
impacted by the change. Table access will be granted but should be limited in the event that
additional controlled clients are installed on the Sandbox system.
Development (Dev2 010, 100)
The Development system is used to develop and configure an operational version of the SAP R/3
system. The Development system is the first area where functional configuration and ABAP/4
Page 7

of 59

ABC Corp


development takes place. The use of change control and detailed security roles in client 100 will
be required to ensure that all changes are properly authorized and the development process is
properly controlled.
The Development system will have the following types of users:
• Basis Administrator
• Security Administrator
• ABAP/4 Developer
• Configurator
• Client Dependent Configurator
• Client Independent Configurator (As required)
• Functional User
• Help Desk
Additionally, corrections and transport (CTS) will be turned on and users, based on their role
within the project, will be given specific CTS permissions. Permissions will be segregated into
the following categories:
•
•
•
•

Maintain and Release Tasks
Create and Delete Tasks
Create, Maintain and Release Requests
Release Requests

Users may be assigned one or more of the aforementioned permissions. To ensure proper
change control, the ability to create a task and release requests should be segregated.
IMPORTANT: The establishment of CTS security and how it is administered will be dependent
on how the system landscape is setup.
Training
The SAP R/3 InfoDB Training system is used at ABC Corp. The system will be used in a
classroom setting that will consist of ABC Corp class participants and instructors from ABC
Corp and SAP.
The Training client is a pre-configured client from SAP. SAP has customized the system objects
including creating user master records and profiles. For security purposes, the pre-configured
user master records will be used for granting class participant access. User master records will
need to be configured for the instructors, security administrators, and system administrators. In
addition, a profile for changing passwords and unlocking users will be created.
Integration
This system is a controlled environment for process and integration testing. Configuration
access, including both client dependent and independent table access should be prohibited. While
there may be multiple clients within this system, each client should adhere to the same limitations
and restrictions.
Page 8

of 59

ABC Corp


The Integration system will have three types of users:
• Basis Administrators
• Security Administrators
• Functional Users
• Help Desk
Production
This system will be the production environment for all SAP R/3 production clients. While the
production system landscape for ABC Corp will change over time, the security strategy will
remain constant for all production clients.
The production system will have three types of users:
• Basis Administrators
• Security Administrators
• Production Users
• Help Desk
The Security Administrators will only perform the following security related activities in the
Production environment.
•
•
•
•
•

Create/Change/Delete Users
Re-generate Activity Groups
Assign/Change/Remove Activity Groups
Re-set Password
Lock/Unlock Users

Changes to activity groups, authorizations and profiles will be processed in the Development
system and migrated to Production using the Transport System.
5.4 The Transport System
SAP has its own self-contained change control mechanism, Transport system. This mechanism
controls the changing and updating of information that includes: tables, process configuration,
ABAP/4 programs, screens, menus and SAP Security. The structure of the Transport System
(CTS) is critical when addressing how SAP security will be developed and administered.
CTS is used to migrate changes within a controlled and secured manner, across the entire
system landscape. CTS controls the flow of changes between Development, Integration/QA
and Production systems. It ensures that all changes are properly authorized and tested prior to
being implemented in Production.
To facilitate the use of the transport system and ensure the integrity of SAP application security,
the following procedures should be followed when designing and administering SAP security
with the SAP R/3 Profile Generator.
Page 9

of 59

ABC Corp


1. Design all activity groups centrally. It is recommended that a ‘Security’ client be used as a
central repository for security configuration.
2. Production Security Administration should originate in the ‘Security Configuration’ client
(150) and be transported into Production. Security Administration includes the creation or
enhancement of activity groups.
3. When the Basis team is creating new clients or systems, coordinate the copying of user
master data and activity groups. SAP categorizes activity groups as configuration within
the HR module while user master data and manual security are considered general table
data. To ensure that all security information is copied, the Basis Administrator must copy
the user master data and configuration data from the originating client.
4. Setup a new development class for all Security Administration activities, including both
manual and SAP R/3 Profile Generator initiated work.
5. Use the same change request number from the initial creation of the activity group through
to the point of the initial generation.
6. When changing existing activity groups, use the same change request number throughout
the modification process.
7. Coordinate transports of activity groups with the Basis Administrators, these particular
transports can affect system response time.
8. Setup a transport layer that allows complete migration from the ‘Security Configuration’
client to all other systems and clients.
9. 10. Do not create and generate activity groups outside of the central security client. SAP uses a
standard numbering scheme that can conflict when transporting activity groups between
multiple clients.

Page 10

of 59

ABC Corp

User Group Security

6. User Group Security
User and security administration can be segregated and decentralized through the use of user groups.
User groups are logical groupings of users that provide a mechanism for allowing sub- or remote
Security Administrators access to maintain a limited group of users. For example, users for the
AGFA are defined to the user group AGFA. Then, we grant the Local Security Administrator (LSA)
access to create, change and delete users in the user group AGFA. The following are guidelines for
the use of ‘User Groups’ for the aforementioned baseline SAP system landscape.
Sandbox/Development System(s)
Role
Basis Administrator
Functional
ABAP/4 Developer
Configurator
Client Dependent
Client Independent
SAP* and DDIC
Help Desk

User Group
Super
Super
Super
Super
Super
Super
Super
SUPER
Help Desk

Integration/QA System
Role
Basis Administrator
Functional User
SAP* and DDIC
Help Desk

User Group
Super
Super
TBD
SUPER
Help Desk

Training System
Role
Basis Administrator
Functional User/ Class Participants
SAP* and DDIC
Help Desk

User Group
Super
Super
TBD
SUPER
Help Desk

Production System
Role
Basis Administrator
Production User/Role
SAP* and DDIC
Help Desk

User Group
Super
Super
TBD*
SUPER
Help Desk

* The structure for the production user groups will be determined in the future.

Page 11

of 59

ABC Corp

Naming Conventions

7. Naming Conventions
A standard naming convention is used to develop security activity groups, authorizations and profiles.
This standard facilitates the process of identifying access privileges.
SAP uses a standard naming convention for its own system objects and has reserved name ranges for
customer objects (i.e. customized profiles, authorizations and authorization objects). SAP requires
the first character of a custom security activity group, authorization, profile and object, start with a
“Y” or “Z”. In addition, an underscore “_” is not allowed to be used in the second character
position. Following the SAP recommended naming conventions helps to ensure that customized
objects are independent of the SAP supplied objects and will not be overwritten during the import of
a new SAP releases/upgrades.
7.1 SAP R/3 Profile Generator Activity Groups
The naming standards for the SAP R/3 Profile Generator will allow you to identify if it is a
development or production activity group, the module, the ABC Corp division it was designed
for, and the business role it pertains to.
NOTE: The names used for the activity group technical name and text description will be
identical to the names used for the corresponding generated profile’s technical name and text
description. Detemine Activity Group Naming Standards (Site Location)
•

•
•

1st character –
- “Z” to represent a custom developed activity group only to be used in
development systems.
- “Y” to represent a custom developed activity group used in production only.
Detail and master activity groups will start with “Y”.
2nd & 3rd character – Alpha numeric to represent the module the activity group was
designed for. See appendix A for a list of modules
character – Represents the division for which this role/ activity group will exist in.
•

•

4th to 7th characters - A four digit random number generated by the Role Definition form.
Each role will be uniquely identified and tracked using this random number. For example, if
when creating the Role Definition form for the Cell Culture Accounts Payable Clerk the
form randomly generated the number 0001, then the name would be “ZOC0001__.

•

May not be necessary with the implementation of responsibilities

IMPORTANT: All ten characters must be used in the name. If all characters are not used,
the SAP R/3 Profile Generator will automatically fill the remaining spaces with underscores
“_”. This automated process of filling in missing characters could make it very difficult to
administer and audit security.

Page 12

of 59

ABC Corp

Naming Conventions

Text Description: The description is to be used to further identify profiles. The first eight
characters are restricted to the convention described below. How to use the description to
further define the profiles:
• 1st to 4th Characters – Hierarchical identifier (Company Code, Plant, Sales Org,
Warehouse, etc.). Note: Use “_ALL” for Master Role.
• 5th Character – Dash Separator
• 6th Character – Space (before beginning the free form text)
• Remainder – Free form text to be used for the Role description. Note: The free form
text should begin with the ABC Corp division
Example: For a “Warehouse Receiving” role in the Consumer Care division the
following roles could be created: (assume that the random number from
the Role Definition form is “0049”)
May be replaced by responsibilities
7.2 In general, the naming standards for manual authorizations will not be used for security at ABC
Corp. However, these standards will allow you to identify whether it is a composite profile (job
role), a simple profile (transaction in a role), or an authorization assigned to a profile. In
addition, the naming standard includes the job role and which division the authorizations is for,
the SAP application area of the profile, and whether the privileges granted by the profile include
read or write access.
Authorizations
• 1st character - "Z" to represent an in-house customized authorization.
• 2nd character - Single character representing the application type (i.e. "S" for system,
"F" for Financial, "V" for Sales & Distribution, and "M" for Manufacturing [see
Technical Name of the object for standards]).
• 3rd character - "/" to represent an authorization.
• 4th to 12th characters - These 9 digits should be customized to represent the
function being given access to. Underscores can be used to separate the characters in
two strings. For example, the authorization “YF/CRT_CO_01” represents the
authorization for access to post customer invoices.
• Short Text - The short text of an authorization should start with the object name, and
then a description of the type of authorization represented. For example, an
authorization for object F_BKPF_BLA that has assigned activity values of 01, 02, 03,
08 (create, change, display, display change documents) and an authorization group DR
(authorization group for document type DR - Customer Invoices) should have the
following short text: “F_BKPF_BLA: Auth. to maintain customer invoices”.
Single profiles
• 1st character - “Z” to represent an in-house designed profile.
• 2nd character - Single character representing the application type (i.e. "S" for system,
"F" for Financial, "V" for Sales & Distribution, and "M" for Manufacturing [see
Technical Name of the object for standards]).
• 3rd character - "_" to represent a single profile.
Page 13

of 59

ABC Corp

Naming Conventions

•
•
•
•

4th to 7th characters - These 4 characters should represent the transaction being
given access. For example, the profile ZF_FB01_999 will represent complete access
to the transaction FB01.
8th character - “_” to show a break between the transaction and type of access.
9th to 12th characters - These 4 characters should be used to document the
organizational access being granted for that transaction. This access should follow the
specific naming conventions documents for the ABC Corp division.
Single profile text - The text of a profile should start with the transaction being
granted access and then contain text describing the type of access (i.e. Maintain
Accntg Doc’s for Company Code xxx) “FB01: Access to maintain A/R documents
for company xx”.

Composite Profiles
• 1st character - "Z" to represent an in-house customized profiles.
• 2nd and 3rd characters - Two characters representing the module for the role.
Human Resources composite profiles will start with “HR”, and Basis will start with
“BS”. Each business group will have a unique two-character identifier. Please note
that the only naming convention constraint for SAP security implementation is an "_"
in the second character position.
• 3rd character - ":" to represent a composite profile.
4th to 12th characters - These 9 digits should be customized to represent the role being
defined. Underscores should be used to separate versions of the role.

Page 14

of 59

ABC Corp

Security Organization

8. SAP Security Organization
SAP security administration will be segregated into threetwo functions: development,user
administration,Help Desk. Development functions consist of maintaining activity groups, establishing
system parameters, monitoring clients and systems and basis security. User administration functions
include maintaining users, assigning or changing user access, unlocking users and resetting
passwords. Help Desk Functions will include unlocking users and resetting passwords. Development
activities will be centrally handled. Additionally, user administration for Basis and Security
administrators will be processed through the central SAP security administration function.

Page 15

of 59

ABC Corp

Access/Administrative Procedures

9. SAP Access Authorization/Process (Under Development)
A generic drop down form in the SEA DB has been setup. The SEA DB will be used as the central
point for sending/processing ‘SAP Access . All SEA Security Administrators have access to the SEA
DB should follow these procedures.
9.1
If e-mails are directly sent to the PSI Security Administrators, please follow these steps:
1. Process the approved access request form as intended.
2. After completing the request, forward the original e-mail including the attached request
form to SAP Access.
3. Go into SAP Access, open the e-mail message, enter the date completed, completed by
information and a brief description of actions completed.
4. File the completed and updated message in the appropriate folder.
9.2
After receiving the approved request form, process the request as intended. Upon completion of
the request, send an e-mail to SAP Access with the following information:












User name
Project/Thread
Process Team
Date Received
Date Completed
Completed By
Brief Description of Actions Taken
User Type Requested
Approver’s Name
System Name
Client Number

After sending the e-mail to SAP Access, open the e-mail and file it in the appropriate folder.
9.3 Administrative Procedures for SAP Access
1. Add the SEA DBo your Lotus Notes Desktop – you will only need to do this once.
2. Each morning, open the SEA DBand leave it open. This will allow everyone to be notified
when new requests are received.
3. For requests that you process (i.e. those for your Project/Thread), once the request is
processed move the request to the respective FOLDER. Folders are listed in the SAP Access
desktop.
4. IMPORTANT – The only requests that should be processed are those still listed in the ‘In
Box’.

Page 16

of 59

ABC Corp

Access/Administrative Procedures

5. IMPORTANT – Under no circumstance should any message be deleted. All messages must
be retained and stored in the appropriate folder.
PLEASE REFER TO LOTUS NOTES EPN FOR THE CURRENT PROCEDURES
FOR REQUESTING ACCESS TO SAP SYSTEMS.
EPN > Engagement Library > Reference Documents > Program Level > Process and
Systems Integrity > Forms/Templates: SAP Access Form

THIS ITEM IS ON THE SECURITY TEAMS TO DO LIST

Page 17

of 59

ABC Corp

SAP Access Form

10. ABC Corp SAP R/3 Security Access Form
Please refer to Lotus Notes EPN for the current SAP Security Access Form.
Select Engagement Library > Reference Documents > Program Level > Process and Systems
Integrity > Forms/Templates: SAP Access Form

Page 18

of 59

ABC Corp

Log-on Parameters

11. Log-on Parameter Administration
As the Basis team creates new systems and clients, there are specific system profile parameters that
must be set in order to facilitate a controlled SAP environment. The system profile parameters
should be properly established for all SAP systems.
SAP
Supplied
Default
Value

SAP System Profile Parameter

Description

login/min_password_lng
login/password_expiration_time
Login/fails_to_session_end

Minimum password length for user password
Number of days between forced password change.
Number of invalid logon attempts allowed before the
SAP GUI is disconnected.

Login/fails_to_user_lock

Number of invalid logon attempts within a day
before the user id is automatically locked by the
system.
Time, in seconds, that SAPGUI is automatically
disconnected because of in-activity.

rdisp/gui_auto_logout

Auth/test_mode
Auth/system_access_check_off
Auth/no_check_in_some_cases
Login/ext_security
Auth/rfc_authority_check
Login/failed_user_auto_unlock
Login/no_automatic_user_sapstar
Auth/no_check_on_tcode
Auth/auth_number_in_userbuffer
Auth/authorization_trace
Auth/check_value_write_on

Switch to report RSUSR400 for authority check
Switch off automatic authority check
Special authorization checks turned off by customer
Security access controlled by external software.
Permission for remote function calls from within
ABAP programs
Disable system function for automatic unlock of
users at midnight.
Disable ability to logon as SAP* with PASS of
password when SAP* deleted.
Disable check of S_TCODE on non-basis
transactions.
Number of authorizations allowed in the user buffer.
Every trace will be logged once in table USOBX
Write value for SU53 security
checking/authorization failure.

HAVE YET TO MODIFY ALL PARAMETERS IN ALL INSTANCES

Page 19

of 59

ABC
Corp
Value

3
0

3
90

3

3

12

5

0
N
N
N
N
0

30
minutes
N
N
Y
N
1

0

1

0

1

N

N

800
N
Y

1000
N
Y

ABC Corp

User Master Standards

12. User Master Records
The user master record contains all master data for the user in the R/3 System. This includes user
address, logon data, defaults, task profiles, profiles, and parameters. User master records are client
specific; therefore, you need to maintain individual user master records for each of the clients in the
R/3 Systems.
Additionally, the user address, defaults, and parameters can be updated when the user master record
is created or by the user. The Security Administrator can add the information as the user master
records are created, since SAP automatically displays the screens to format this information. Or
users can update the information as SAP automatically provides users with access to change their
own address, defaults, and parameters. “Maintaining users” is protected by authorization object
S_USER_GRP.
12.1 Creating a User Master Record
ABC Corp uses a version of SAP that utilizes the profile generator; therefore, creating user
accounts is accomplished via the SU01 and PFCG transaction screens (“User Maintenance:
Initial Screen” and “Edit Activity Group,” respectively). The “User Maintenance Initial
Screen” is comprised of six tabs, or subscreens:
1. Address
2. Logon Data
3. Defaults
4. Task Profile
5. Profiles
6. Parameters
Presented in order of which tab the field appears, the following list of fields are required to be
populated when creating a user master record on any client or system. While some of the
fields are not set-up as required fields by SAP, the following are ABC Corp guidelines for
which fields should be completed and with what type of information they should be populated.
12.2 Address
This information is used by the Security Administrator to identify the location and name of the
person attached to the concern wide identifier. This information is also used to authenticate
user password resets.

Page 20

of 59

ABC Corp


The following fields within the Address tab is required for ABC Corp.
Required Fields
Form of Address
Last Name

Information Required
Mr. or Ms
User’s Full Name –
Last Name, First Name
Complete phone number, including area code
or country code.
Country of user’s ABC Corp location.
User’s sub-department (e.g. Accounts
Payable, Order Management, etc.)
ABC Corp’s building identifier (e.g. INSERT
B&D EXAMPLES, etc.)
Complete phone number, including area code
or country code.

First Name
Country for Format
Department
Building
Telephone No.

12.3 Logon Data
Initial Password
Each user must have an initial password in order for them to log into the system. This
password is assigned here. The system prompts the administrator to type it in twice in order
to minimize typing errors.
User Group
All users must be assigned to a pre-defined user group (reference Section 6, User Group
Security). This field allows the administrator to categorize the users within groups. This
categorization allows the administration functions to have separation of duties. For example,
if the user is in the “SUPER” group, the only security administrator capable of maintenance
must have access to that specific user group.
Valid From/Valid To
These two fields are used to define the timeframe an SAP account should be active. The
“valid to” field must be used for temporary and contract employees. Additionally, when an
employee is terminated or no longer needs SAP access, the “valid to” field should be used.
In order to maintain accurate historical data, user accounts should never be deleted – they
should be inactivated via the “valid to” field.

Page 21

of 59

ABC Corp


User Type
SAP uses the user type field to determine what type of processing the user will need. There
are four types of users and each type will define if the user needs interactive, batch,
background, or external processing.
User Type
Dialog
BDC
Background
CPIC
(CPI-S Interface)

Description
Default user type used for functional system users.
Enables the user to process batch input sessions.
Allows users to process background jobs.
Allows users to make external CPI-C calls from
within SAP to external programs.

12.4 Defaults
Output Device
This area will display all printers that are available to that particular user. All users should be
given a default printer based on their location and naming convention. Access to printers is
controlled by S_SPO_DEV and all users require access to this authorization object in order to
print SAP documents and reports.
Print Controller Functions
The “Print Immediately” and “Delete After Output” buttons should be enabled.
Decimal Notation
The decimal notation for ABC Corp should be set to “point” to conform with the US
monetary formats.
Date Format
The standard date format for ABC Corp should be set to MM/DD/YYYY.
12.5 Task Profile
Information for these fields should not be added from this screen. The profile generator
(Transaction PFCG) should be used to assign access. Once the PFCG is used to assign access
to users, fields within this screen are populated with the user’s profile information.
12.6 Profiles
Information for these fields should not be added from this screen. The profile generator
(Transaction PFCG) should be used to assign access. Once the PFCG is used to assign access
to users, fields within this screen are populated with the user’s profile information.
In the event that manual security is used, which should be limited to the sandbox and
development systems, this is where the manual profile are added/deleted for a user.

Page 22

of 59

ABC Corp


.
12.7 User Parameters
This tab does not contain any required fields. Users may choose to update these fields at their
own discretion. The user parameter tab allows users to manage certain key fields by
automatically defaulting information into those fields. Therefore, any time a user encounters
these fields in other transactions throughout the SAP client, the field will automatically have a
default value equal to what has been assigned in this parameter default screen. The
“parameters” column contains any parameter identifications (PIDs) selected for this user. (A
list of PIDs can be viewed by clicking on a box to the left of the parameters column and
subsequently clicking on the down arrow.)

Page 23

of 59

ABC Corp

Password Administration

13. Password Administration
SAP provides two ways to administer user passwords for an R/3 system and client. SAP has specific
default procedures that cannot be changed and parameters in the system DEFAULT.PFL file that
can be tailored for each system. The setting of parameters in the DEFAULT.PFL file will affect all
clients in that particular system.
13.1 Default Password Requirements
The following are default requirements within SAP that cannot be changed:
• First character may not be ! or ?
• First 3 characters may not appear in the same sequence in the user ID
• First 3 characters may not be identical
• Space character not allowed within first 3 characters
• Password may not be PASS or SAP* (* meaning any string of character(s))
• Passwords are not case sensitive
• A user can change their password only once a day
• Passwords may not be changed to any of the user’s last five passwords
13.2 System Password Parameters
Please refer to Section 11 – Log-on Parameter Administration.
13.3 Password Changes
If a user forgets their password, the user must call the Help Desktor to request a password
reset. The security Administrator will reset the password and forward it to the user’s
voicemail. When the user logs on, SAP immediately prompts the user to change the
password. A user who is logged on when you change the password is not affected by the
change until they log off and then on again.
Users are also allowed to change their own passwords. Most users are only allowed to
change their passwords once per day. However, Security and Basis Administrators can
change passwords as often as they desire.
13.4 Impermissible Passwords
SAP provides a standard mechanism that allows the establishment of invalid passwords for a
particular instance. USR40 is a client independent table that is used to log all prohibited
passwords.
The table is manually maintained and should be consistently maintained across all projects and
systems. It is recommended that this table be used for all projects and systems. The following
is a list of recommended values for the table USR40.
BD*
DTCG*
Jan*
June*

PARA*
Delo*
Feb*
July*

NY*
DTLL*
Marc*
Augus*
Page 24

of 59

NETS*
GIANTS
April*
Sept*

MONEY
GOD
May*
Oct*

ABC Corp

Password Administration

Nov*
YANK*
CASH

Dec*
NewY*

Abc*
Knick*

123*
Aspir*

JETS
NEED*

Note: Each system should be analyzed and the list expanded as deemed necessary.

Page 25

of 59

ABC Corp

SAP Supplied User Standards

14. SAP System Supplied Super User(s)
The SAP R/3 system has two users that come with every SAP system. The two standard super users
are SAP* and DDIC. The SAP Security Administrator should strictly secure these two users. The
Basis and Security Administrators will be the only users who know and have access to these two
users.
14.1 SAP*
SAP* is the user that is setup in every client install or copy. Because this user is written into the
SAP code, it is also the only user that does not have a user master record. It comes standard in
every system, and has a predefined password of 06071992. This user also has complete access
to the entire SAP R/3 system.
The unlimited access of SAP* should be immediately secured by the SAP Security
Administrator. SAP* access should be eliminated and reassigned to a secured user. The
following are a list of steps to mitigate the risk of SAP*:
1. Change the password.
2. Create a user master record for SAP*.
3. Turn off the special privileges of SAP* by changing the parameter loginno_automatic_user_sap* to a value greater than 0. This is changed in the common default
profile, DEFAULT.PFL.
4. Create a separate user named SAP_ALL to replace SAP* and limit access to only those
who need it.
5. Delete all profiles from the SAP* profile list so it has no authorizations.
6. Ensure SAP* and SAP_ALL are assigned to the user group SUPER.
14.2 DDIC (data dictionary)
User DDIC is a SAP supplied identifier that comes standard with every system. Unlike SAP*,
this user has a defined user master record. The default password for logging into DDIC is
19920706. DDIC has special privileges relating to the data dictionary in SAP and it’s the only
user allowed to log in during a system upgrade. Therefore, this user must be secured against
misuse or unauthorized access. The following are a list of steps to mitigate the risk of user
DDIC:
1. Change the password. (It is recommended that it be changed bi-weekly).
2. Ensure DDIC is assigned to the user group SUPER.

Page 26

of 59

ABC Corp


15. Help Desk Procedures
The ABC Corp SAP Help Desk will assist in performing three key activities:
•
•
•

Resetting User Passwords
Unlocking Users Due to Invalid Password Attempts
Resolving Access Issues/Problems

The Help Desk users will not be authorized to change any security configuration or assignment of
security to users.
15.1 Resetting User Passwords
Help Desk personnel will be given access to all SAP clients and systems. The individuals will
have access to reset passwords for all users, except those attached to the groups SUPER, Basis
and Security.
IMPORTANT: Only the Security Administrators and SAP* will have the ability to reset
passwords for users in-groups SUPER, Basis and Security.
15.2 Unlocking User Ids
Help Desk personnel will be given access to all SAP clients and systems to unlock users. They
will be limited to those users not assigned to the user groups SUPER, Basis and Security.
Additionally, procedures will state that Help Desk should only unlock users that have been
locked due to invalid logon attempts. Only the Security Administrator can unlock users that
have been locked by administrators. And, the SAP system profile parameter that automatically
unlocks users at mid-night will be disabled.
IMPORTANT: Only the Security Administrator and SAP* will be allowed to unlock users
assigned to user groups SUPER, Basis and Security.
15.3 Resolving Access Issues/Problems
In the event that a user contacts the Help Desk for a security issue, the Help Desk personnel
will follow these steps in order to efficiently and effectively process the users request.
1) Have the users execute transaction SU53 (type this in the command box).
2) Have the user print the screen as it appears, selecting the print icon on the screen. The user
has the option of printing at their location or printing it directly to the Help Desk.
3) If printed at their location, fax the printout to the Help Desk or to the Security
Administrator. The Help Desk should have the fax number for the Security Administrator.
4) The Help Desk will also record the user id , user name, system and client where the
processing error occurred. The system and client information can be obtained at the bottom
of the users SAP screen or by executing SYSTEM > STATUS.
Page 27

of 59

ABC Corp


5) The Help Desk will then forward the call to the appropriate Security Administrator for
resolution.

Page 28

of 59

ABC Corp


16. Security Change Control
As theproject goes through the process of designing and administering SAP security, changes to
activity groups, profiles and authorizations should follow a standard change control process.
16.1 Creating/Maintaining Activity Groups
All activity groups should be created and maintained in the central security client for each
project. Centralized processing and administration of activity groups ensure that all activity
groups are synchronized across the entire system landscape for a project.
Several key activities must be completed when creating/changing an activity group
• For new activity groups, identify an owner to establish authorization and approval.
• Identify the transaction(s) to be added, changed or removed.
• Create the master activity group and identify the potential hierarchy elements.
• When necessary, work with the activity group owner to determine the hierarchy segregation.
• Identify which users should have this activity group.
• Generate the master and detailed activity group in the security configuration master client.
• Release and transport the associated requests to all systems and clients.
• Go to the clients and create the necessary relationships between the users and new activity
group.
For production activity groups, the activity group must be tested in the integration test system
and approved by the role owner. Roles will not be migrated into the production system without
proper testing and authorization by the role owner.
IMPORTANT: When using a security configuration master client, all transports related to
activity groups should be applied to all clients within that system and transported to all
subsequent systems and clients.
16.2 Creating New Development Roles
Activity groups used for granting access to the Development system and clients is centrally
designed and configured in client 150. In the situation where new development activity
groups/roles (e.g. General User, ABAP Developer, etc.) need to be created, all security
configuration for new activity groups must originate in client 150.
New activity groups will be properly documented using the ‘Role Definition’ forms. The
Security Administrator receiving the inquiry will process new activity group configuration. The
following summarizes the steps to be followed for creating a new activity group:
1. Create a Role Definition form for the new activity group, documenting the transactions and/or
authorization objects.
2. Create the new activity group in DV2 Thread Development, client 150.
3. Transport the new activity group across the DV2 client landscape.
Page 29

of 59

ABC Corp


4. Re-generate the activity group.

Detailed Steps/Instructions
The following detailed steps identify the specific actions to be completed, persons
responsible for the activities, clients affected and timing when creating a new activity group.
1. Create a Role Definition form for the new activity group, documenting the
transactions and/or authorization objects.
All activity groups, both development and production, must be properly documented.
Work the person making the inquiry/request to define the new activity group. At a
minimum, the definition must identify the transactions.
Additionally, a role owner must be identified for the new activity group. The role owner
is responsible for validating any changes to the activity group once it has been configured
and implemented.
IMPORTANT – The Role Definition form is an attachment to the FastTrack Task
‘Design Application Security’.
UNABLE TO FIND THIS FORM IN FASTTRACK, WILL CONTINUE
RESEARCHING
2. Create the new activity group in DV2, client 150.
Using the Role Definition form, configure the new activity group in client 150.
IMPORTANT – All new activity groups must be configured in client 150 and transported
to other clients, ensuring that the object number used by SAP is identical across all clients.
Follow these standard steps for creating and generating an activity group:
1. Create the activity group.
2. Document the name properly.
3. Select the transactions from the company menu.
4. Complete the authorization profile.
5. Generate the activity group using the proper naming convention (See SAP Security
Administration Standard Operating Procedures).
6. Update the tracking and testing information on the Role Definition form.
Additionally, refer to R/3 Authorizations Made Easy for assistance in using the
Profile Generator.
3. Transport the new activity group across the DV2 client landscape.
The new activity group(s) must be copied to the other clients in the Development system.
Using the Profile Generator, create a transport for the new activity group. The following
steps should be followed when transporting an activity group:
Page 30

of 59

ABC Corp


1. From within the Profile Generator, click on the ‘Transport’ icon. SAP will
automatically create the transport task and request number.
2. Execute transaction SE10 – Customizing Workbench.
3. View the ‘Customizing Requests’ for your User Id.
4. Drill down into the Transport Request until the subsequent task numbers are all
displayed.
5. Single click on the appropriate task. With the cursor positioned on the desired task,
click the ‘Release’ button on the menu bar.
6. Complete the proper documentation requirements for new security transports.
7. If more than one underlying task exist for the request, repeat Steps 5 & 6 until all
tasks have been released.
8. Once all tasks have been released, single click on the request number and then click on
the ‘Release’ button on the menu bar.
9. Select the ‘Release and Transport’ option, this will take the existing request and create
a transport file.
10. After SAP releasing the request, review the transport log to validate that the transport
processed successfully.
11. For valid, successful transport, prepare an E-Mail to “EMAIL ACCOUNT NAME
TBD” in Lotus Notes. This message will be used to notify the Basis Team of the need
to transport the activity group to other clients in the DV2 system. The message
should include the transport number, clients to be impacted, timing requirements and
brief description of the transport request.
Additionally, refer to Chapter 11 in ‘R/3 Authorizations Made Easy’ for assistance in creating
and releasing transports.
4. Regenerate the activity group
Once the Basis Team has successfully applied to transport to the other clients in the
Development system, the new activity group must be re-generated.
IMPORTANT – The activity group is client dependent, it must be re-generated in
all of the clients where the transport was applied.

After regenerating the new activity group(s), the user buffers must be reset to activate the
changes.
From the SAP Main Menu:
Tools > Administration > User Maintenance > Users
Following this menu path takes you to the Sub-Menu for user administration. Select
Environment > Mass Changes > Reset All User Buffers
IMPORTANT – Check the message at the bottom of the screen after resetting the user
buffers. If an error occurs, contact the Basis Administrators.
Page 31

of 59

ABC Corp


16.3 Updating Development Roles (except General User)
 The PSI Security Administrator will process changes to the development roles, including the
Configuration, CTS and ABAP/4 Developer.
IMPORTANT - Changes to the Basis Administrator and Security Administrator roles will be
processes by the SAP Central Security Administrator
Changes to the development roles will follow these five steps:
1.
2.
3.
4.
5.
6.

Record the change in the ‘Development Role Update Log’ (TBD)
Add the appropriate transaction(s) or authorization object(s) to the affected activity groups
Re-generate the activity group(s)
Reset user buffers
Discuss change(s) with other PSI Security Administrators
Update the activity group in client 150

IMPORTANT – If time permits, changes to development roles should originate in DV2 client
150 and be transported to the appropriate systems and clients.
The following detailed steps identify the specific actions to be completed, persons responsible for
the activities, affected clients and timing.
1. Record the change in the ‘Development Role Update Log’ (Excel Spreadsheet)
All changes, additions or deletions, must be logged. The log is used to validate and
coordinate the over update and re-generation of the configuration activity groups.











Update the log with the following information
Date of Change
Role Changed
Team/Person Requesting Changes
Description of Change
Transaction (added or deleted)
Authorization Object (added or deleted)
PSI Security Administrator Processing Change
Date Applied to Client 150
Transport Number (optional)

2. Add the appropriate transaction(s) or authorization object(s)

Page 32

of 59

ABC Corp


The affected development roles should be updated in all clients. At the time of creating these
procedures, changes should be applied to the Pre-configuration Sandbox and 010
Configuration Master.
Using the Profile Generator (transaction PFCG), perform the necessary updates to the
appropriate configuration activity group(s).
IMPORTANT – Review the System/Client landscape to ensure that all clients are being
properly updated.
3. Re-generate the affected activity group
The activity group(s) must be regenerated in all-appropriate clients.

4. Reset User Buffers
After re-generating the modified activity group(s), the user buffers must be reset to
activate the changes.
From the SAP Main Menu:
Tools > Administration > User Maintenance > Users
5. Update the affected activity group in client 150
Once the changes to the development roles have been applied to all other clients, the
modifications must be applied to client 150.
IMPORTANT – Client 150 is the security configuration master. Changes not applied to
client 150 may be overwritten in other clients with subsequent transports.
Final updates to the development role(s) should follow these steps. Steps 3 through 5 are
optional, these steps are only required if the activity group needs to be applied to other
clients.
1. Open the ‘TBD Log.XLS’ and add the appropriate information for logging that the
change was applied to client 150.
2. Re-generate the activity group.
3. If necessary, create a transport for the modified activity group, releasing the request to a
transport. Also, record the transport number on the ‘Development Role Update Log’.
4. If necessary, contact the CTS Administrator to have the transport applied to clients 003
and 010.
5. If necessary, after the transport has been applied, log on to each client (003 and 010)
and re-generate the activity group(s).
Page 33

of 59

ABC Corp


IMPORTANT – The number of clients where the transport needs to be applied may
have changed since the creation of these procedures. Review the System/Client
landscape to ensure that all clients are properly updated. 16.4 Updating General User
Development Role
There are four separate configuration teams using the P3 Thread Development System (DV2).
The General User role is being used and assigned by/to all four teams. Changes to all
development roles must originate in the ‘Security Configuration Client (client 150).
The size of the General User role, including number of transaction, authorizations and profiles
requires that changes be handled in a manner to ensure that changes are easily applied to clients
and users.
All changes to the General User role will follow five steps:
1. Record the change in the ‘General User Update Log’ (Excel Spreadsheet)
2. Add the appropriate transaction(s) or authorization object(s) to the SAMPLETBD activity
group
3. Re-generate SAMPLETBD
4. Reset User Buffers
5. Coordinate scheduling of TBD update and re-generation
IMPORTANT – If time permits, changes to development roles should originate in client 150 and
be transported to subsequent systems and clients.
The following detailed steps identify the specific actions to be completed, persons responsible for
the activities, affected clients and timing.
1. Record the change in the ‘General User Update Log’ (Excel Spreadsheet)
All changes, additions or deletions must be logged. The log is used to validate and coordinate
the over update and re-generation of the General User role.
An Excel spreadsheet is stored on











TBD
Update the log with the following information:
Date of Change
Role Changed
Team/Person Requesting Changes
Description of Change
Transaction (added or deleted)
Authorization Object (added or deleted)
PSI Security Administrator Processing Change
Date Applied to Client 150
Transport Number

Page 34

of 59

ABC Corp


2. Add the appropriate transaction(s) or authorization object(s) to the SAMPLE activity
group
SAMPLE must be updated in two clients: DV1 010 and DV2 010 Configuration Master.
Using the Profile Generator (transaction PFCG), perform the necessary updates to the
SAMPLE activity group.
IMPORTANT – At the time of creating these procedures, only DV1 010 and DV2 010
required use and updating of SAMPLE. Review the System/Client landscape to ensure that
all clients are being properly updated.
3. Regenerate SAMPLE
The activity group must be re-generated in all appropriate clients.
IMPORTANT – Only the activity group SAMPLE should be re-generated. This is the only
modified activity group.
4. Rest User Buffers
After re-generating the SAMPLE activity group, the user buffers must be reset to activate the
changes.
From the SAP Main Menu: Tools > Administration > User Maintenance > Users
5. Coordinate scheduling of YDXXGENUSR update and re-generation
Changes logged in the ‘General User Update Log’ will be processed at the end of each day in
client 150. The Chemical PSI Security Administrator will process all changes to General User
activity group in client 150.
Final updates to the YDXXGENUSR activity group will follow these 7 steps:
1. Open the ‘General User Update Log.XLS’ and make the changes to YDXXGENUSR
2. Update the log to reflect the date of processing the change and who completed the
change.
3. Regenerate the activity group.
4. Create a transport for YDXXGENUSR, releasing the request to a transport. Also, record
the transport number on the ‘General User Update Log’. (See Procedures for Transports
and Documentation).
5. Contact the CTS Administrator to have the transport applied to clients 003 and 010.
6. After the transport has been applied, log on to each client (003 and 010) and re-generate
the YDXXGENUSR activity group.
7. Finally, removed the transaction(s) and/or authorization object(s) from the SAMPLE
activity group in clients 003 and 010. And, re-generate SAMPLE in each client.
Page 35

of 59

ABC Corp


IMPORTANT – The number of clients where the transport needs to be applied may have
changed since the creation of these procedures. Review the System/Client landscape to ensure
that all clients are properly updated.
16.5 Creating/Maintaining Authorizations and Profiles
In general, manual authorizations and profiles will not be used at ABC Corp. Security
development and administration will be handled through the use of the SAP R/3 Profile
Generator. The following guidelines should be followed for manual SAP security development.
•
•
•
•
•
•
•
•

Identify an owner to establish authorization and approval levels.
Identify the authorization object or profile that requires change or creation.
Create or change the necessary authorizations or the profile.
When necessary, work with the role owner to determine the hierarchy segregation.
Identify which users or profiles should have the new access. Review the users that may
already have the profile name attached to their user.
When the necessary changes have been made to the profiles, (e.g. adding new authorizations
or creating a new profile to support the request) transport the profile.
Release and transport the associated requests to all clients.
Go to the clients and create the necessary relationships between the users and new profile, if
necessary.

Note: If adding or changing an authorization that is incorporated in an existing profile, the user
must log-off and log-on after the new access has been assigned for the update to be applied.

16.6 Transporting Activity Groups
Each activity group must first be created in the DV2 Development system, client 150. The
activity groups will be propagated to other systems and clients using the Transport Management
System (TMS). In version 4.0B, TMS has replaced the Correction and Transport System (CTS).
The terms CTS and TMS are synonymous.
As activity groups are created and setup for transporting, each transport should be properly
documented and the Basis Team notified. The following summarizes the steps to be followed for
transporting activity groups from client 150 to other systems and clients:
1.
2.
3.
4.
5.
6.

Identify the activity group(s) to be transported.
Identify the systems and clients to be updated.
Create and document the transport for the activity group(s).
Release the transport in SAP.
Contact the Basis Team.
Re-generate the activity group(s).

Page 36

of 59

ABC Corp


IMPORTANT – Prior to creating and applying the transport, verify the settings for table T77TR
in all destination clients. Two entries should exist, T 1001 A007 and T 100 B007. These
entries will prohibit the transporting of relationships.
The following detailed steps identify the specific actions to be completed when transporting
activity groups.
IMPORTANT – Additional information regarding the screens and transactions used to transport
activity groups is available in Chapter 11 of “R/3 System Authorizations Made Easy”.
1. Identify the activity group(s) to be transported.
Based on your recent activity group modifications or configurations, identify the activity
groups that need to be transported.
It is recommended that you group the activity groups into a single transport. But, be aware of
the size of the activity groups. DO NOT TRANSPORT GENERAL USER WITH ANY
OTHER ACTIVITY GROUPS.
Additionally, please consider the number of users, systems and clients affected by the transport.
All of this information should be considered when determining the grouping structure of activity
group(s) to transport.
2. Identify the systems and clients to be updated.
Identify the systems and clients where the transport should be applied. All security related
transports should originate from DV2 Development system, client 150.
At a minimum, transports should be applied to DV2 client 010 (development), U3Q client 010
(Integration) and U3P client 010 (Production).
IMPORTANT – At the time of creating these procedures, U3Q and U3P have not been
installed. These systems represent the Integration System and Production system. Client 010
is the number for the Development Configuration Master client. This number may change
based on the system/client landscape.
3. Create and document the transport for the activity group(s).
Using the Profile Generator, create the transport for the identified activity groups.
If transporting more than one activity group, use the same transport number created for the
first activity group.
For example, if transporting activity groups YDXXTEST1 and YDXXTEST2. SAP will
create a transport number DV2K9000011 for the first activity group. When transporting the
Page 37

of 59

ABC Corp


second activity group, either select or type the transport number assigned to the first activity
group.
Additionally, refer to Chapter 11 in ‘R/3 Authorizations Made Easy’ for assistance in creating
and releasing transports for multiple activity groups.
IMPORTANT – All security related transport must be properly logged in document.
??????????????
Update the log with the following information
 Date Transport Created
 Transport Number
 Description of Transport
 Activity Group Affected
 Originating System and Client
 Destination System and Client
 Processed by (PSI)
 Transport Validated Working in Destination
4. Release the transport in SAP.
Once the transport has been successfully created, the transport must go through the proper
release through the Transport Management System (TMS).
SAP categorizes activity groups as Customizing, execute transaction
SE10 – Customizing Organizer. Display the transports listed under your /User Name.
SAP groups the transport information into a task and request. In order to transport the
activity group, all tasks associated with the request must be properly released. Once all tasks
have been released, the request can be released.
When the request is released, the activity groups have been transported. Contact the Basis
Team.
5. Contact the Basis Team.
The Basis Team will perform the actual application of the transport to the destination
system(s) and client(s).
Prepare an e-mail, addressed to “P3 SAP Basis Team”. The e-mail should contain the
following information:







Transport Number
Systems where the transport should be applied (e.g. DV2)
Clients that the transport should be applied to (e.g. 003, 010)
Description of the change
Timing requirements: Urgent, please apply immediately, end-of-day, etc
Your phone number

Additionally, copy (CC:) the other PSI Security Administrator to make them aware of the
transport.
Page 38

of 59

ABC Corp


6. Re-generate the activity group(s).
For each client identified in Step 2, log on to the client and re-generate the activity group(s)
applied by the transport.
Additionally, if there are any users logged on during the re-generation, the User Buffers
should be reset.
IMPORTANT – Each PSI Security Administrator is responsible for re-generating the activity
groups that they have transported.
16.7 Maintaining User to Activity Group Relationships
When using the SAP R/3 Profile Generator, all access permissions should be assigned using
either the PFCG transaction or the SU01 transaction.
The process of creating relationships should be handled within each client. When the relationship
is created within PFCG there is a possibility that a ‘Change Request’ will be created. In the
event that a change request is generated, once the relationship has been created, the request
should be deleted from the Customizing Organizer.
The System, Client or Role owner must properly authorize all changes to user relationships.
16.8 Authorizing /Validating Changes
All changes to security should be properly authorized. The following table indicates the
necessary level of authorization for SAP Security Administration activities:
Type of Activity
Creating New User
Creating New Activity Group
Changing Existing User Access
Changing Existing Activity Group
Migration to Other Clients/Instances

Page 39

Required Level of Authorization
Thread Leader/Client Owner
Thread Leader/Client Owner/Role Owner
Thread Leader/Client Owner
Thread Leader/Client Owner/Role Owner
Destination Client/System Owners

of 59

ABC Corp

SAP Table Security

17. Security for New ABAP/4 Programs
As stated in the ABAP Development Guidelines, all new ABAP/4 programs will be attached to a
transaction code. And, access to transaction SA38 and SE38 will be restricted to ABAP
Development team members only. New programs will follow the same guidelines for securing new
SAP transactions (see prior section for requirements). In the event that a program is created for
batch processing only, the following security requirements must be configured. Consult with the
SAP Security Administrator when configuring ABAP/4 program security.
For all batch programs which will not be secured by a transaction, there are two security
requirements: assigning authorization groups and configuring authority checks.
17.1 Assigning Authorization Groups
1. Identify the group of people or area that should have access to this program.
2. Determine if there is an existing authorization group that meets the criteria. If not, create
that authorization group in table TBRG.
3. Enter the ABAP program ‘attributes’ in edit mode (SE38).
4. Type in the authorization group name in the field ‘Auth Group’.
5. Create and release the transport request and migrate the program change across the entire
system.
6. Work with the SAP Security Administrator to identify the role or position that should be
able to execute the program. The Security Administrator will develop the necessary
activity group to enable the identified users to submit/execute the program.
7. If this program should be scheduled for over-night batch processing, contact the Basis and
Security Administrator. Both parties should be involved in defining the batch security
requirements.
17.2 Configuring Authority Checks
1. Evaluate the need to create new authorization objects or use existing objects.
2. If necessary, work with the Security Administrator to create new authorization objects and
associate them with an existing object class.
3. Identify the values necessary to execute the program and configure the appropriate
authority checks in the ABAP/4 program.
4. Identify the position or role that should have access to execute this program. The Security
Administrator will develop the necessary activity group to enable the identified users to
submit/execute the program.
5. Review the authority check, authorization object and required values with the SAP
Security Administrator.
IMPORTANT: All ABAP/4 programs defined for batch execution must be assigned to an
authorization group and contain at a minimum, one authority check. All programs should be
subject to a program walkthrough to ensure program security has been properly configured before
migrating to Integration Testing or Production.

Page 40

of 59

ABC Corp

SAP Table Security

18. Security for New SAP Tables
The ability to display and maintain table level data should be closely managed and granted on
exception basis. There are three SAP transactions that provide primary access to view and maintain
SAP table data: SE16, SE17 and SM31. Transactions SE16 and SE17 provide display only access
while transaction SM31 provides direct table update capabilities.
IMPORTANT: Update access to transaction SM31 will only be granted in the Development
system and master configuration client.
The following are guidelines for securing table access. The SAP Security Administrator should be
consulted when configuring and granting table level access.
18.1 Existing SAP Tables
Display access will be granted based on configuration and functional requirements.
Authorization Groups control table access and all table access will be explicitly granted based
on authorization groups using the authorization object S_TABU_DIS.
18.2 New SAP Tables
All new tables must be secured with an authorization group. A table that does not have an
authorization group assigned to it can be modified by any user with access to S_TABU_DIS
with values of ‘02’ and ‘blank/spaces’ in fields activity or authorization group. The SAP
Security Administrator should be consulted when securing new SAP tables.
The following are steps that must be completed to properly secure a new SAP table:
1. Identify the table or view name to be secured.
2. Determine if there is an existing authorization group attached to similar tables that the new
table should be grouped with?
3. For new authorization groups, first create the authorization group name in table TDDAT.
4. Once the authorization group name is created, assign the authorization group to the table
name using transaction SM31 and maintain the table TDDAT.
5. When maintaining the table TDDAT, be careful, this is a client independent table.
6. Once the authorization group has been applied, transport the change request to all
subsequent clients and systems.
IMPORTANT: While granting access to tables is controlled by the two objects S_TABU_DIS
and S_TABU_CLI, the users must also be granted access to the necessary transactions using the
object S_TCODE.

Page 41

of 59

ABC Corp

Transaction Security

19. Security for New SAP Transactions
Transactions developed to support the SAP implementation must be secured. There are two security
requirements for all customized SAP transactions:
19.1 Configure the Transaction to Meet S_TCODE Requirements
The following steps should be followed when creating a new transaction:
•
•
•

Define the transaction code in SAP using transaction SE93.
Contact the SAP Security Administrator and let them know the new transaction code.
The SAP Security Administrator will secure the new transaction.

19.2 Identify and Configure Check Object Security (transaction SE93 and table TSTCA).
The following steps should be followed when defining a check object:
• Review the existing authorization objects to determine the ability to use an SAP supplied
authorization object.
• If necessary, create the new authorization object. New objects must be defined in table
TOBJ. Work with the SAP Security Administrator to create new authorization objects.
• Define the authorization values required to execute the transaction. Each authorization
object can have up to ten fields. In defining the check object, a value must be specified for
at least one field.
• Execute transaction SE93 to create the check object.
• Enter the new transaction code and click on the ‘Maintain’ icon. SAP will display a screen
that shows the transaction code, program name, screen number and check object. The
check object field may be blank for new transactions.
• Enter the authorization object selected to be the check object.
• Enter the authorization values for the check object. Click on the value button for the check
object, SAP will display a pop-up screen with the fields defined to the selected authorization
object. Enter the values in the required fields. Values can be entered in one or all of the
fields.
IMPORTANT: In defining and configuring custom transaction security requirements, the ABAP/4
Developer should work with the SAP Security Administrator to properly define and configure the
security requirements.

Page 42

of 59

ABC Corp

Internet Security

20. SAP R/3 Internet Security
Internet functionality within SAP is processed through the Internet Transaction Server (ITS). SAP
has implemented specific security requirements for Internet users and functionality.
The following are guidelines for administering and configuring Internet access.
1. The object S_USER_WWW should only be assigned to the Security Administrator responsible
for creating Internet users.
2. The functional and system owner should properly approve Internet user access.
3. The BAPI name should be explicitly defined on the Internet Transaction Server and within the
destination client.
IMPORTANT: The Competency Center and Basis Administration teams should be consulted when
configuring Internet access and users. How the Internet functionality is enabled at the HTML level
will impact the security requirements.

Page 43

of 59

ABC Corp

ALE Security

21. Application Link Enabling (ALE)
ALE security can be broken down into three areas: development, administration and execution. The
project’s functional teams and the Competency Center conduct the development of the ALE
functionality. The Basis Administration and Communications team will handle the administration of
ALE and the underlying EDI functionality.
The execution of ALE functionality is dependent on how SAP has been configured. The Process
Teams will be responsible for working with the Competency Center and IT Team to properly
configure and test ALE processing. Access to ALE functionality will be dependent on the
development role and project. The following are guidelines for the type of access and which role
will have it.
1. The Competency Center and project teams will be responsible for developing and testing ALE
functionality. Their roles as configurators will provide them with the necessary access to
configure and test ALE processing.
2. The Basis Administration, Competency Center and Communications teams will setup and verify
the execution of ALE functions. These roles will provide them with the necessary access to
process the technical configuration and execution of ALE processing.
3. User access will be controlled by the production role assigned to that user. ALE functionality is
enabled at the SAP transaction/process level. Production roles will grant access to
transactions/processes and ALE processing will be controlled through the configuration of the
transactions/processes.
IMPORTANT: The Competency Center and Basis Administration team should be consulted when
gathering ALE security requirements.

Page 44

of 59

ABC Corp

Batch/Job Scheduling Security

22. Batch/Job Scheduling Security
SAP provides several options for submitting and administering batch processing. Programs can be
scheduled, submitted on-line or interactively executed in batch mode. Each method has distinct
security requirements that must be implemented.
The following are guidelines and standard operating procedures that must be implemented for new
batch programs.
22.1 On-line/Scheduled Programs
These programs are defined as ABAP/4 programs that are submitted for batch processing.
Scheduled programs are submitted to be executed in background, based on specific criteria
(e.g. time, predecessor, and date). On-line programs are immediately executed when
submitted by the user or programmer.
There are three transactions needed to submit programs: SE38, SA38 and SM36. There are
similar security requirements for each transaction, including:
1. An authorization for the object S_TCODE that explicitly defines the transaction value.
2. An authorization for the object S_PROGRAM with the activity of submit, btcsubmit or
variant and the authorization group assigned to the program.
IMPORTANT: Access to SE38 and SA38 should be restricted to the ABAP Development
Team only. Requests for these transactions should be directed to the Client Owner.
Additionally, all users should have access to transaction SM36; this is the generic screen for
defining jobs for batch processing. SAP treats users as administrators for batch jobs that they
submit.
The following are security guidelines for submitting batch programs.
1. Users must be explicitly granted submit or btcsubmit privilege.
2. The value of ‘*’ will not be used for the authorization group in the object S_PROGRAM.
3. The Basis Administration team are the only users with batch administration access
(S_BTCH_ADM).
4. If the program requires additional authorizations, which are not assigned to the user, a
background user must be used.
5. When necessary, users are explicitly given access to background users (S_BTCH_NAM).
6. For all scheduled jobs, a background user must be assigned to the program for submission.

Page 45

of 59

ABC Corp

Batch/Job Scheduling Security

22.2 Batch Input Sessions
Batch input sessions are similar to on-line batch programs but provide interactive capabilities.
Programs submitted through batch input processing allow the submitter/user to view the
screens being executed by the batch input session. Users must be given explicit access to the
session name and actions to be executed.
The following are security guidelines for batch input processing:
1. Users should only be given access to session names that begin with their (e.g.
MOAXC*).
2. Actions should be restricted to the sessions submitted by that particular user.
3. The values ‘*’ should not be used for either the session name or action.
The establishment and administration of batch input security should be coordinated with the
ABAP/4 Development and Functional Teams, as they are typical users of the batch input
processing functionality.

Page 46

of 59

ABC Corp

Output/Spool Security

23. Output/Spool Security
SAP requires that users be given explicit access to printers and spools. The authorization object
S_SPO_DEV controls access to these resources. Both printers and output spools are defined to the
SAP client by the Basis Administration team.
The following are security guidelines for output/spool access:
1. The ability to create, maintain and delete spool and printer information will be limited to the
Basis Administration team only.
2. User access will be restricted to specific device names.
3. Access to protected spool requests, which are secured by the object S_SPO_ACT, will require
explicit definition of the action and spool request name.
IMPORTANT: The security requirements for printers and spool requests should be coordinated
with the Basis Administration and Functional Teams. Users may be permitted unrestricted access in
the Sandbox and Development systems, but print and spool access will be restricted in the
Integration and Production systems.

Page 47

of 59

ABC Corp

Security Monitoring

24. Security Monitoring Activities
SAP supplies a series of reporting tools and ABAP/4 programs that provide detailed analysis and
monitoring of SAP security at the client and system level. The monitoring reports can be accessed
via the following transaction codes:
Transaction Code
SA38
SE38
SUIM

Screen Name
ABAP: Execute Program
ABAP Editor: Initial Screen
Display Report Tree

Transactions SA38 and SE38 require use of the report name (as listed on the following table).
Transaction SUIM leads the user through the repository information report tree.
The following procedures are standard security monitoring activities. In addition to performing
these tasks, the results of the monitoring procedure should be documented and retained in order to
provide a useful audit trail.

Page 48

of 59

ABC Corp
No.
1

Objective
Ensure invalid login
attempts are properly
reviewed.

2

Ensure changes to
passwords are properly
authorized.

3

Ensure SAP System Profile
Parameters are properly
configured based on ABC
Corp Standard Operating
Procedures.

4

Ensure changes to SAP
security are properly
approved.

5

Ensure security access is
properly restricted.

6

Ensure SAP supplied
SAP* and DDIC are
properly secured.

7

Ensure access to security

Security Monitoring

Monitoring Procedure
The report lists for each client within the system, all users
with invalid login attempts and those users locked either
by Security Administrators or too many invalid password
attempts. Review the report to identify any
inconsistencies or patterns.
Review password change documents for key users,
including SAP*, DDIC, Basis and Security
Administrators. The ability to reset passwords should be
limited to Basis and Security Administrators, and Help
Desk users. (Choose header data and passwords for
desired userids.)
For each system, review the key security related system
profile parameters. The parameter values should be
configured according to the recommended values in
Section 11 – Logon Parameter Administration in the SAP
R/3 Security Administration Standard Operating
Procedures. Additionally, these parameters should be
consistently set for all SAP systems. Refer to Section 11
Log-on Parameter Administration.
For selected key users, including Basis and Security
Administrators, execute the report and review change
history. Review the date of changes and who made the
changes. Changes should be limited to other Basis or
Security Administrators.
Review the users that have access to “change” within the
authorization objects S_USER_GRP, S_USER_AUT and
S_USER_PRO. Access to “change” within these objects
should be limited to Security Administration team
members. The Basis team should have the ability to reset
passwords for all user groups except SUPER and Security.
The ability to display can be given to any user.
Review the report and verify that the passwords for SAP*
and DDIC have been changed for all clients. The report
shows all of the clients defined to the system. SAP* and
DDIC passwords should be consistently maintained on all
clients. (Choose header data and passwords for desired
userids.)
Check for transactional access to security administration.
Page 49

of 59

Report or
Transaction
RSUSR006

Recommended
Frequency
Daily

RSUSR100

Weekly

RSPARAM

Bi-weekly

RSUSR100
RSUSR101
RSUSR102

Bi-weekly

RSUSR040
How to
efficiently
accomplish
this task is
questionable
.

Bi-weekly

RSUSR100

RSUSR002

Monthly

Monthly

System

Client

Completed By
(Who/Date)

Sap security-administration

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Sap security-administration

Ähnlich wie Sap security-administration (20)

Mehr von nanda nanda

Mehr von nanda nanda (14)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Sap security-administration