sap security - level 1

SAP Security – Level 1

BASIC TERMINOLOGIES

USER SETTINGS

ROLE MAINTENANCE – BASICS

ROLE MAINTENANCE – ADVANCE TOPICS

PROFILE PARAMETERS, SPECIAL USERS AND CRITICAL

AUTHORIZATIONS

CONTROLLING USER AND ROLE ADMINISTRATION

TROUBLESHOOTING AND ADMINISTRATION AIDS

TRANSPORTING AUTHORIZATION COMPONENTS

CONFIGURING ROLE MAINTENANCE TOOLS

PFCG INSTALLATION AND UPGRADE

ORGANIZATIONAL MANAGEMENT

SECURITY IN PROJECTS

Table of Contents

BASIC TERMINOLOGIESLesson 1

Introduction to SAP Security

Obligation

Ensuring liability and legal obligation towards stakeholders and shareholders including validation

PrivacyProtection of data against unauthorized access

IntegrityData integrity needs to be granted at all time

AuthorizationUsers should only be able to perform their designated tasks

AuthenticationOnly legitimate users should be able to access the system

Security measures at different levels of the system architecture

Level

Presentation

Communication

Web Connection

Application

Database

Operating System

Component

UI

Network

ITS

Application modules

Datastores

UNIX, Windows etc.

Measures

Access control. Authentication etc.

Packet filtering, encryption, SNC, SSL etc.

Certificates, SSO etc.

Authentication, Authorization etc.

Access control, Backup

Access control

Basic Terminologies

• Application data is protected from unauthorized access using authorizations.• Authorizations are bundled into profiles which are assigned in the form of

roles to the user master record.• Roles are defined by an administrator to map business scenarios.• Business scenarios are made up of a group of activities which are

represented in the form of transactions within the roles.• A user may have access to a single scenario or several scenarios depending

on the way the business flow is structured within the organization.• Similarly. A business scenario can be split into several roles depending upon

the complexity of the business process.• Splitting of roles is also important to segregate the duties amongst the

employees of an organization and thereby having more players to accomplish a business process end to end. This reduces the risk of malpractices within the company.

Elements of an SAP authorization concept

Authorization Class• To

logically group authorization objects e.g. Master Data, Finance etc.

Authorization Object• Each

authorization object is a combination of authorization fields.

Authorization Field and Value• The

permissible values for the fields constitute the authorization.

Authorizations• An

authorization allows you to carry out an task based on a set of field values in an authorization object.

Authorization Profile• Authori

zations are contained within the profiles.

Role• Roles

are nothing but a container for authorization profiles.

User Master Record• Used for

logging on to SAP systems and grants restricted access to functions and objects of the SAP system based on authorization profiles.

Authorizations, Objects, Fields and Values

Materials Management : Purchasing MM_E

Purchasing group in Purchase Order : M_BEST_EKG

Activity (ACTVT) = 01, 02,

03

Purchasing Group (EKGRP)

= 001, 002

Purchasing Organization in Purchase Order :

M_BEST_EKO

Activity (ACTVT) = 01, 02,

03

Purchasing Organization (EKORG) = 1000, 2000

Authorization Class

Authorization Objects

Authorization Fields and Values

Authorizations Instance and Profile

T-D5984503

M_MATE_BUK

Activity : 01, 02,

Company Code : 1000

Activity : 03, Company

Code : 2000

M_MATE_VKO

Activity : 03 Sales Org : 1000 Dist. Ch. : TR

Authorization Profile(s)

Authorization Object(s)

Authorization Instance(s)

Roles and User Menu

• A role can be assigned to any number of users.

• Through the role, you also assign the authorizations that users need to access the transactions, reports, and so on contained in the menu.

• This user menu appears when the user to which the authorization profile was assigned logs on to the SAP system.

• A user menu consists of the role menus of the assigned roles. It contains the activities that are required by a group of users for their work area.

FavoritesUser Menu for Subramaniam

BP - Maintain Business Partner PFCG - Role Maintenance SU01 – User Maintenance SA38 – ABAP Reporting SE16 – Data Browser SM30 – Call View Maintenance

Tips – Regarding User and SAP Menu

• Table SSM_CUST, view "Set Values for the Session Manager / Profile Generator“– Control of the removal of redundant transactions with

redundancy avoidance• DELETE_DOUBLE_TCODES, YES/NO

– Sorting the user menu with redundancy avoidance • SORT_USER_MENU, YES/NO

– Switch to turn the user menu on or off • ALL_USER_MENUS_OFF, YES/NO

• Table USERS_SSM– Switch the user menu and/or the SAP menu on or off as

required.• ALL_USER_MENUS_OFF , YES/NO

Sequence of Authorization Checks

Display Dialog Transaction

SM59

SRCX

RFC Destinations

SAPMCRFC

100

S_RFC_ADM

Transaction Code

Package

Transaction Text

Program

Screen Number

Authorization Object

Values

Fields Values

ACTVT

ICF_VALUE

RFCDEST

RFCTYPE

ABAP Program Authorization Checks (authority-check Statement)

• Authorization checks in programs are performed using the ABAP command authority-check.

• For example if a user tries to edit a table in SM30 the system first checks if the users has the relevant authorization for the object S_TABU_DIS, actvt : 02 and dibercls (authorization group in table TDDAT). If this check fails the system would check if the user has display authorization for the table.

authority-check object 'S_TABU_DIS'"check by class id 'ACTVT' field act_level id 'DICBERCLS' field w_tddat-cclass. if sy-subrc <> 0. "not allowed if act_level = '02'. authority-check object 'S_TABU_DIS' "check by class id 'ACTVT' field '03' id 'DICBERCLS' field w_tddat-cclass. if sy-subrc = 0. act_level = '03'. p_action = 'S'. message w114(tb). "only show allowed else. message e115(tb). "no upd auth endif. "sy-subrc from 2nd auth_check else. "act_level <> 02 MESSAGE e116(tb). "no show auth endif. endif.

USER SETTINGSLesson 2

User Settings

• A user master record is a must for every user to access the system. The record also stores information used for authentication. E.g. Password

• User master records are client specific.• A user id is a 12 character identifier for an

SAP user.

Authorizations for User Administrator

•Authorization to create a user master and assign them to a particular group.•Authorization to display/Maintain users in a particular group.

S_USER_GRP

•Authorization to assign/remove profiles to or from the user master.

S_USER_PRO

•Authorization to assign / remove roles to or from the user master.

S_USER_AGR

User Master Record

Address• The data on this tab is used to identify the user. It gives details like first and

last name, telephone, email, address, department etc.• Last name is a mandatory field on the address tab.

Logon data

• Specify an Alias to alternatively identify a user using a 40 character string.• Assignment of a user group, user type and validity period for the user.• Set Initial password.• Accounting number and cost center to settle accounts for the system usage

by the user.

Defaults

• Assignment of a start menu• Logon language, Date format and Decimal notation• Assignment of an output device (SAP Printer)• Time zone assignment based on the user’s location.

Parameters• Parameter ids are entered here to fill default values from memory.• Example Parameter id BUK can be used to pre-fill SAP transactions with

company code value wherever referenced.

P200USER

24.08.2011

Address Logon Data Defaults Parameters

User

Last Changed

Roles • Assign roles and set validity dates for the roles.

Profiles

• Manually created profiles are assigned here. System Generated profiles are automatically assigned on this tab on assignment of roles

Personalization

• Personal settings available in both role as well as user maintenance.

• Controls the programs differently at user or role level e.g. Workflow in SRM

License Data

• Used to determine the user category for license measurement.

• SAP license measurement program uses this information to derive the payment applicable for the installation

User Master Record

P200USER

24.08.2011

Roles Profiles Personalization License Data

User

Last Changed

User Type• Interactive Users• Initial and Productive passwords expire for these users based on system

parameter settings.• By default multiple dialog logons are not allowed for these users.• Users can change their passwords themselves.

Dialog (A)• Interactive Users• These users are not subject to password expiry.• Multiple logons are permitted for these users.• Only a user admin can change the password.

Service (S)• User type for background processing and communication within a system.• Dialog logon not allowed.• These users are not subject to password expiry.• Multiple logons are permitted for these users.• Only a user admin can change the password

System (B)• User type for dialog free communication between systems (RFC,

Workflow, TMS, Batch processing etc)• Initial and Productive passwords expire for these users based on system

parameter settings.

Communication (C)

• Cannot be used for dialog logon.• Used for assigning additional privileges to dialog users in addition to

those available via assignment of roles.• Reference user is assigned on the roles tab.

Reference (L)

System Users

• System users (called CPIC users in older releases) are required for the internal communication of the systems. To increase the security of your system landscape, when you are creating system users, assign only greatly restricted authorizations, combined in special roles to the system users.

• In principle, one user ID (such as SAPCPIC) would be sufficient, and you could use it for all system users. However, with this situation, it would be practically impossible to change the password of the system users, or simply to keep it secret, as there can be multiple utilizing RFC destinations.

• So that you must only change the password of the relevant system user in one place when you are changing the password later, use a separate system user for each RFC destination. This means that there are as many system users in your system landscape as there are RFC destinations.

• No license fees apply to these system users.

Additional Features

• Transaction SU10 can be used to maintain the user master for a large number of users at once.

• You can display change documents for users by navigating to environment -> display changes.

• User master record is stored in USR* tables.• Table USR02 is used to display logon data for the user

and it also stores some change logs like last logon date for the user.

• Change logs for the user are stored in USH* tables.• To effectively utilize the memory space occupied by the

tables in the database, the table data can be archived.

ROLE MAINTENANCE - BASICS

Lesson 3

Role Maintenance - Basics

• Transaction PFCG

Create Role

Add Transactions in the menu

Automatically generate d authorization data for post processing

Maintain authorizations and generate profile

Assign the generated profile to users via role

Role• Roles are authorization containers that represent a specific part of an employee’s job. The role itself is

composed of different functions of the employee, which again is the sum of certain tasks inside these functions.

• Example: The job of a user is Head of the purchase dept. In his job he has different roles, such as being a buyer. One of the functions of the buyer is to create purchase orders.

– Job: Head of the purchase dept.– Role: Buyer– Function: Create Purchase Order (Referred to as a Transaction in SAP).

• A user may have more than one role. The above user may also be responsible for maintaining the master data relevant for purchasing.

• He may also be responsible for vendor evaluation and rating.• With roles you can implement menus which the users can work with after logging on to the system.• If integrated with organizational management, roles can be assigned to jobs, positions and organizational

units.

SAP_CO_PC_JOB_SALESORDER

Display Sales Orders

Description Menu Authorizations User

Role

Description

Role Documentation

Role Maintenance - Views

• There are three types of role maintenance views.• Simple Maintenance : Allows only menu and user maintenance.• Basic Maintenance : Access all role maintenance functionalities

and assignment to users• Complete View : For Organizational Management is used in

Personnel Planning and Development

Goto Utilities(M) Environment System Help

Settings

Transactions in Roles Shift + F9

Settings

Simple maintenance (Workplace menu maintenance)Basic maintenance (menus, profiles, other objects)Complete view (Organizational Management and workflow)

View

• If they are to be used in a role reports should always have a transaction code

• The transaction code can be automatically generated by the system or specified by the administrator

• If you assign a new transaction code although a transaction code has already been created for this report (for example, for another role), the system displays a message that informs you about the situation and If necessary, you can choose between the new and the old T codes.

Reports assignment in Roles

Report type ABAP ReportSAP QueryTransaction with Variant BW Report

Transaction Code for Reports

ABAP Report

RSUSR402Report

Variant

Skip selection screen

GUI Support

SAPGUI for Windows

SAPGUI for Java

SAPGUI for HTML

Generate AutomaticallyZTESTREPTransaction Code

A transaction code already exists for the report enteredDo you want to adopt the old transaction code?

Create Transaction Code

Transfer Recreate Cancel

Designing and Structuring the Role Menu• Add/delete Transactions and Reports• Copy Menus from other roles• BW reports and Queries can also be added using the report button• Web links and Document links can be added using the other button.• Create/Delete , Rename Folders and Create hierarchies.• You can distribute the role to a target system using RFC.

Description Menu Authorizations User MiniApps

Transaction Report Other

Authorization Default

Delete

Role Menu

User Maintenance BP - Maintain Business Partner PFCG - Role Maintenance SU01 – User Maintenance SA38 – ABAP Reporting SE16 – Data Browser SM30 – Call View Maintenance

Target System

CT1CLNT010Dest.

Distribute

Copy Menus

From SAP Menu

From Other Role

From Area Menu

Import from file

Maintain Authorizations

• PFCG automatically proposes the authorizations with default values in some cases based on the transactions added in the role menu.

• The authorization objects display Yellow or Green Traffic Lights based on whether the authorization data has been maintained completely or partially.

• The authorization objects for Organizational values are displayed in Red traffic lights instead of Yellow if not maintained with values.

Change role: AuthorizationsSelection Criteria Manually Open Changed Maintained Org. Levels

SAP_BC_BASIS_ADMIN System Administrator

Manually Cross Application Authorization Objects

Maintained Basis Administration

Maintained User Master Maintenance: User Groups


* Activity 03,08

* User Group in user master maintenanc

AAAB

BC_A

S_USER_GRP

T_YA67011010

ACTVT

CLASS

Generate Authorizations

• Finally once the authorizations are maintained they need to be generated to take effect.• On generation all the maintained authorizations are collected into a profile.• Since a profile can only hold a limited number of authorizations (150) , One role may

have several profiles. PFCG divides and creates these profiles automatically.• You can recognize these profiles from the fact that their names are identical for the first

10 characters, and an appended number starting with 1-99.• They are also known as sequential profiles.

Note : AGR_PROF only lists the main profile but does not list the automatically generated profiles in the role.







* Activity 03,08


ADMIN

AAAB

BC_A

S_USER_GRP

T_YA67011010

ACTVT

CLASS

Assign Profile Name for Generated Authorization Profile

T-12345678Profile name

Text Profile for role SAP_BC_BASIS_ADMIN

You can change the default profile name here

User Assignment

• User tab page in PFCG is used to assign the roles to the users.

• The validity dates can be set to a limited period of time if required.

• User master comparison is done to fill up the authorization buffer tables (USRBF2) and also to make to the time dependant authorizations effective.

• There are three ways of performing a user master comparison:

– For an individual role on the users tab.– You can do it in mass for a large number

of roles using transaction PFUD– You can schedule a background job to

run every day during the non-working hours for the program pfcg_time_dependency

Description Menu Authorizations User MiniApps

Organizational Mgmt.

User Comparison

User Assignments

User ID User Name From To In

TCRUSE Tom Cruise 21.10.2010 22.05.2012

NKDMAN Nicole Kidman 21.02.2011 31.12.9999 C

Info object

Customizing auth

Settings

Display Changes

Optimize User AssignmentSettings: Role maintenance

Utilities System

Automatic User Master Adjustment when Saving Role

Menu: Do Not Insert Existing Entries. Standard: No

ROLE MAINTENANCE – ADVANCE TOPICS

Lesson 4

Role Maintenance – Advanced Topics

• One of the important challenges for an security consultant is to design the roles to map the organizational requirements.

• A wrong decision in designing the roles may lead to huge efforts during maintenance mode, longer cycle times in decision making and realization of role changes leading to frustration amongst the user community.

• There are a variety of options and flexibility offered in PFCG for designing the roles.• Composite, Derived, Customizing and Reference Roles are advanced role types

which could meet the challenging design requirements.Roles

Customizing

Composite

Reference and Derived

..............

Customizing Roles

• When building roles for the project team and especially for the functional consultants it possible to restrict their access to the specific project views of the IMG project.

• Customizing roles can be built in PFCG by inserting customizing authorization from Utilities > Customizing Auth.

Info object

Customizing auth

Settings

Display Changes

Utilities System

Optimize User Assignment

Description Menu Au

Transaction Report

Authorization Default

Role Menu

Customizing Authorizations

Status: You have not assigned any Customizing objects

Add

Insert Customizing Activities

IMG project

IMG project view

Select IMG Project

Project Title

STEEL Steel IMG

TEST IMGTEST

Composite Roles

Production Manager Role

Order Creator

Role

Production Reporting

and Display Role

Requirements

Planning Role

Shop Supervisor Role

Man-hours Accounting

Production Reporting

and Display Role

Work Center Planner

Role

Composite roles are just role containers, they do not have any authorizations of their own

Composite Roles and User Assignments

Single Role 1Composite Role A•User1•User2•User 3

Composite Role B•User4

Limitations of a composite role

• They are simply containers and do not carry any authorizations themselves.

• If you want to restrict a particular authorization for a composite role, you have to ensure that every role within the composite role is restricted. This may not be desirable always and may make the roles very rigid to maintain.

• If you decide to extend the authorization of a single role, then all the roles it is assigned will get affected which may also not be always desirable.

• Implementations which use composite roles to separate the transaction role and the organization values, break the link between the role and SU24. Such roles are very difficult to maintain.

• Also in above case a removal of a transaction from role does not ensure removal of all its related objects from the organizational role.

• Transporting such roles is also very tricky because in such cases the entire composite role needs to be transported and not just the single role which has been modified.

• As a result such roles may also result in blocking the transport routes and causing over taker issues.

Composite Role A

Common Transaction Role

E.g. ME21nCreate Purchase Order

Org Values Role AE.g. $EKORG :

1000

Building Menus for Composite Roles

• If you assign a user the single roles directly rather than through a composite role, then the menu from the single roles appear repeatedly for the same folder path.

• Although composite roles do not contain authorizations of their own they can be used to read the menus from the contained single roles using the “Read Menu” button on the menu tab.

• If a single role was added or removed from the composite role then a comparison needs to be done again to read the menus of each role.

• Here you have the option to only update the composite role with the delta changes or to do complete update of the composite role menu.

• Chose Re-import to discard your settings and re-structure your composite role menu.• Chose merge to only do an delta update to the roles.

Delete

Role Menu

User Maintenance BP - Maintain Business Partner PFCG - Role Maintenance SU01 – User Maintenance SA38 – ABAP Reporting SE16 – Data Browser SM30 – Call View Maintenance

Copy Menus

Read Menu

Description Roles Menu User

There are two ways you can create the menu structure of the composite role: You can either recreate the menu completely, or you can merge it with the menu of the single roles.

Do you want to recreate the composite role completely or merge the existing data with the menu data from the single roles?

Settings: Role maintenance

Re-import Merge Cancel

Reference and Derived Roles

• In today’s world companies are striving towards harmonizing the business processes globally across various regions.

• Although this is a very idealistic approach but the derived roles concept fits best where companies have such harmonized processes.

• The concept is that there is a Reference(d) role which transfers it’s menu (structure plus transactions) and authorizations to the Derived role.

• Only the organizational values are maintained in the derived roles.

Reference Role

Derived Role 1

CoCode:1000

Derived Role 2

CoCode:1100

Derived Role 3

CoCode:2000

Derived Role 4

CoCode:4000

Reference and Derived Roles

• Derived roles reference to already existing roles and these roles should not be in SAP namespace.

• The menu is maintained in the imparting role only. Changes have an immediate effect on all inheriting roles.

• Thus unlike the composite roles, the derived role has the complete filled menu of the referenced role immediately after the referencing role is entered and the role is saved.

• The inheritance relationship can be canceled, but the previously inheriting role is then handled like a normal role. The cancellation of the relationship cannot be undone.

Role Menu

User Maintenance BP - Maintain Business Partner PFCG - Role Maintenance

Description Menu Authorizations

ZDB_AIO_AP_CLERK

Dubai Accounts Payable Clerk

Role

Description

Description Menu Authorizations

ZDB_AIO_AP_CLERK

Dubai Accounts Payable Clerk

Transaction Inheritance

Z00_AIO_AP_CLERKDerive from Role

AP Clerk Global

Role

Description

Delete Inheritance Relationship

Implementing Organization Field Values Directly (SAP Note 314513)

• Authorization data of organizational levels is usually maintained in the Profile Generator in the "Define organizational levels" dialog box. However, you can also maintain individual organizational level fields in each authorization via the "Implement field values" dialog box. If you do so, the organizational levels, however, lose their special status and are then treated as normal authorization fields with the following practical consequences:

Individual maintenance of an organizational field using the "MaintainField Values" dialog box makes the following change for this field inthis authorization:

o Value maintenance using the dialog box "Define Organizational Levels" no longer changes the value.

o When adjusting derived roles, the authorization value is overwritten

You can reset the new status of the organizational field in thisauthorization by deleting the field content using the delete icon nextto the field name.

Do you want to maintain the organizational level field individually?

- The maintenance via the "Define organizational levels" dialog box no longer changes the authorization values.- As of Release 4.6B: When adjusting the authorization data of derived roles, the system overwrites the authorization values in the derived roles.

Information

PFCG: Traffic Lights• Traffic lights help in giving an overview of the of the current maintenance status of

the authorizations.– Green : All fields have been filled with values– Yellow : At least one field which is not an organizational level field for which data has not

been proposed or maintained– Red : At least one field which is an organizational level field for which data has not been

proposed or maintained







* Activity 03,08


AAAB

BC_A

S_USER_GRP

T_YA67011010

ACTVT

CLASS

PFCG: Important IconsGives an list of transactions entered in the role menu

which proposed the authorization object

To deactivate an authorization object

Merge multiple authorization objects

Reactivate authorization object

Delete field contents or inactive authorization objects.

Edit field contents of an authorization object

Allow full authorization to the field of an authorization object

Copy authorization object

PFCG : Maintenance Status

• The authorization has not been changed since it was included in the role during the merge process. It contains only authorization default values that are defined in transaction SU24.

Standard

• The authorization originates from a standard authorization, in which at least one empty authorization field was filled.Maintained

• The authorization default values were changed in at least one field.Changed

• The authorization does not originate from the authorization default values defined in SU24, but is included using the menu function "Edit" -> "Insert authorization" (six options) or by migrating a profile that was created manually (transaction SU25, step 6.).

Manually

Each authorization contained in a role is identified by one of four different maintenance statuses, which are defined as follows:

PFCG : Update StatusAfter each merge process, the update status is specified in addition to the maintenance status. There are three possible statuses with the following meanings:

•The authorization already existed before the merge process. There were no changes to field valuesOld•The authorization already existed before the merge process. However, the merge process led to changes in the field values.

Updated

•The authorization was added with the last merge process New

Standard : Active & Inactive

Active

An active standard authorization is always

displayed if no authorizations with the

status "Maintained" (active or inactive) or "Standard

inactive" exist for the same authorization object.

Inactive

If an inactive standard authorization consists of the default values of several menu transactions, and one or more of the transactions involved are deleted from the role menu, the Profile Generator automatically removes

the respective default values from the inactive authorization.

The inactive standard authorization is deleted if there is a maintained authorization

whose standard values contain the values of the inactive standard authorization.

An inactive standard authorization disappears if a menu transaction no longer exists whose authorization default values are contained in the inactive authorization.

Maintained : Active & Inactive

If there is at least one authorization default value, whose default values differ from the maintained authorization, but has at least the same fields filled with default values, then the maintained authorization remains and is given the status “Maintained new”, a new standard authorization object is also added.

If the maintained authorization contains the merged default values of several menu transactions, and one or more of the transactions involved is deleted from the menu, the Profile Generator automatically removes the respective default values from the maintained authorization.

Combining Authorizations

• If several authorizations exist for one authorization object, the Profile Generator checks whether the status and content of the combination allow two or more authorizations to be merged. Automatic compression allows optimal display of the authorization list, and prevents unnecessary data from being saved in the role and the generated profile.

• Automatic combining during the merge process is only possible on authorizations with the status "Standard" and "Maintained".

• Changed and manual authorizations can be merged if they share an identical active status.

• If this pre-requisite is fulfilled then two authorizations can be combined in the following cases:

• For all fields, one authorization is contained in the other.• The values of both authorizations differ in exactly one field, and are otherwise identical.

• There are also exceptions to the above:• An authorization that contains empty fields cannot be combined with another

authorization in which at least one of these fields is filled. • An authorization that contains fields with total authorization (*) cannot be merged with

another authorization, in which at least one of these fields does not indicate a total authorization.

Deactivating Authorizations

It is useful for two reasons to deactivate the unwanted standard authorizations:1. No unnecessary authorization data is transferred to the profile that

belongs to the role because deactivated authorizations are ignored during profile generation.

2. The same standard authorization is not added again during the next merge process

What is special about S_TCODE?

Due to the dependency of the content of the role menu, the authorization object S_TCODE is of particular significance and is subject to special rules:

1. Authorizations for S_TCODE can exist only in the maintenance status "Standard" or "Manually".

2. To ensure that the menu and the authorization data of a role correspond, you cannot change the standard authorization for S_TCODE. This does not include the deactivation function

PROFILE PARAMETERS, SPECIAL USERS AND CRITICAL AUTHORIZATIONS

Lesson 5

Password Rules and Profile Parameters for System Logon

• A well defined security policy is a must for a every organization. One of the key features for the security policy is the password rules which control unauthorized access to the SAP systems.

• There are a quite a few security profile parameters which govern the security settings for the system.

• When setting password rules one must differentiate between rules that are pre-defined in the system and the rules that are configured by the customer.

Predefined SAP System Rules

•Must be at least six characters long (by default)• Must not begin with ? or !� � � � �• Must not be pass� � �• The new password must differ from the old one by at least 1 �character•Users may not change their password themselves more than once a day.•Case sensitive•Cannot be same as user id, one character at least must be different.•First three characters must not be the same or a space character

Customer Defined

• Customers can control the password rules in two ways:– System profile parameters to determine the min. length or frequency of change etc for

passwords– An illegal passwords table USR40 to bar the users from using some well known strings

or characters in their password. For e.g. Company name, City name etc. Here you can define strings using wildcards like ? For a single character or * for a character string.

Parameter NameUser-Defined Value

System Default Value

Parameter Name Comment

login/min_password_diff 1 1min. number of chars which differ between old and new password

login/min_password_digits 0 0 min. number of digits in passwords

login/min_password_letters 0 0 min. number of letters in passwords

login/min_password_lng 8 6 6 Minimum Password Length

login/min_password_lowercase 0 0 minimum number of lower-case characters in passwords

login/min_password_specials 0 0 min. number of special characters in passwords

login/min_password_uppercase 0 0 minimum number of upper-case characters in passwords

login/password_expiration_time 60 0 0 Dates until password must be changed

login/password_history_size 10 5 5 Number of records to be stored in the password history

login/password_logon_usergroup users of this group can still logon with passwords

login/password_max_idle_initial 15 0 0maximum #days a password (set by the admin) can be unused (idle)

login/password_max_idle_productive 60 0 0maximum #days a password (set by the user) can be unused (idle)

Special Users

• Special Users are the users which are predefined in the SAP systems with well known names and passwords.

• As a result they should be protected from unauthorized access.

• There are two types of special users: those created by installing the SAP system and those created when you copy clients.

• 000, 001 and 066 clients are created automatically during an SAP installation.

Special Users : SAP*

• SAP* is defined in the SAP system code and does not require a user master record.• It has got unlimited access to the system and the default password is pass.• During installation the user master record for SAP* is created in client 000 and 001 with initial password

as 06071992, The installation can proceed only after the admin has reset the password for the user.• This master record created in the system for SAP* deactivates the special authorizations for the user

and now only the assigned authorizations to the user would apply.• Creation of user master record for SAP* is one way of preventing unauthorized access with the user.• If you delete the user master record for SAP*, then the standard user defined in system code becomes

active with default password “PASS”.– The user now has complete authorization.– The standard password “PASS” cannot be changed.

login/no_automatic_user_sapstar

Control of the automatic login user SAP*

Logon

1

1

1

Short description

Appl. area

Default value

Profile value

Current value

Param. Name

Special Users : DDIC and EarlyWatch

DDIC

•DDIC is responsible for maintaining the ABAP dictionary and the software logistics.•Certain authorizations (access) for the user DDIC are predefined in the system code.•DDIC is the only user which can logon to the SAP system during installation of a new release.•Similar to SAP* DDIC is created during the installation of client 000 and 001 with initial password as 19920706.•Installation cannot proceed unless admin changes the password to a new one.

EarlyWatch

•This user is delivered in client 066 with default password as “SUPPORT”•Early Watch experts at SAP use this user to logon to the customer systems.•Do not delete or change the password for the user.•The user should be used only Early Watch functions by SAP personnel such as monitoring of system performance.

Special Authorization Objects

• In the following sections we shall have a look at some authorization objects which are frequently called when executing reports, transactions and queries with an aim to understand its usefulness and purpose.

S_TCODE (Authorization Check for Transaction Start)

• For every transaction that is executed from the menu tree, favorites or from the command field, a check is performed by the kernel for the transaction against the authorization object S_TCODE for the field TCD.

• For example if a user executes a transaction MIGO, the system will only allow to proceed further if he has the authorization for the transaction in object S_TCODE.

• There are however exceptions to the above rule:– Transactions that are called from another program or transaction using statement

“CALL TRANSACTION”– Report Transactions which are started using SUBMIT action from SA38 are

checked against authorization object S_PROGRAM.– Parameter transactions that eventually call core transaction codes (Table

TSTCP). Core transactions are not protected by S_TCODE.

List of Called Transactions Add Tcode Delete Tcode

Calling Transaction : FS00Description: GL account master record maintenance

Exce. Called Tcode Transaction TextCheck Ind

Message Type

FB01 Post Document YES

FD01 Create Customer (Accounting) YES

FSP0 G/L acct master record in chrt/accts YES

FSS0 G/L account master record in co code YES

KA01 Create Cost Element

KA02 Change Cost Element

KP65 Create Cost Planning Layout YES

TextCheck Indicator for Checking S_TCODE in CALL TRANSACTION

UseThe check indicator determines whether a transaction start authorization check (that is, an authorization check against the object S_TCODE with the transaction code of the called transaction, and additional authorization checks entered in transaction SE93 for the transaction, if appropriate) is to be performed when the ABAP statement CALL TRANSACTION is run.You can enter the following values:Yes: An authorization check is performed when the ABAP statement CALL TRANSACTION is runNo: No authorization check is performedSPACE (empty): One of the above check indicators is yet to be set. In the current release, no authorization check is performed.

S_TABU_DIS (Table Maintenance Authorization)

• S_TABU_DIS controls which tables the user can display or maintain in table maintenance transactions SM30, SM31 or Data Browser SE16. Tables are assigned to authorization groups (DIBERCLS). Tables to group assignments are defined in table TDDAT.

• Tables which are not assigned to any authorization groups are by default assigned the dummy authorization group &NC&

• The assignment of this authorization group (&NC&) is not useful with regard to a conclusive authorization concept and should be avoided.

• You can use transaction SE54 to create customer-specific table authorization groups and assign both customer-specific and standard SAP tables.

• If your table maintenance authorization is based on S_TABU_DIS only then In the productive environment, the generic table access tools (SE16N, SE16, SE17, SM30, SM31, and SM34) must be treated as particularly security-relevant transactions. For detailed access to tables with generic maintenance tools, use parameter transactions that specify both the view or table to be maintained and the permitted activity, and that skip the initial screen of the transaction. If these transactions do not yet exist for the relevant purpose, you can create them in the customer or partner namespace.

S_TABU_NAM (Granular Table Maintenance Authorization)

• S_TABU_NAM is not generally available in SAP ERP Package, it can be defined and activated after applying relevant SAP notes (1481950).

• With this object, the system checks the view names or table names directly so that an exact authorization check is possible. In the module VIEW_AUTHORITY_CHECK, the system checks S_TABU_NAM only if the authorization check on S_TABU_DIS was unsuccessful.

• This procedure enables both the retention of the previous table access concept and the superposed use of both authorization objects.

• If you use authorization objects S_TABU_DIS and S_TABU_NAM in parallel, the advantages of a group-based authorization check can be combined with the possibility of a very finely granulated authorization assignment.

• Users with a large scope of functions for a department can be authorized as far as possible using S_TABU_DIS, but only very extensive table authorization groups or particularly sensitive areas are assigned in a table-specific manner using the object S_TABU_NAM.

• Advantage here is that particularly extensive or critical authorization groups do not have to be assigned to users. In principle, authorization groups with tables that are classified as critical should not be assigned.

S_TABU_CLI (Cross-Client Table Maintenance)

• Authorization object S_TABU_CLI: Grants authorization to maintain cross-client tables with the standard table maintenance transaction (SM31), extended table maintenance transaction (SM30), and the Data Browser (SE16), and also in the Customizing system.

• It also acts as an additional security measure for cross-client tables and enhances the general table maintenance authorization S_TABU_DIS.

• CLIIDMAINT: If identifier X or * is set, cross-client tables can be maintained.

S_TABU_LIN (Field Level Authorization Restrictions)

• Through the introduction of organization criteria concept in combination with object S_TABU_LIN, it is possible to restrict a user's access rights to specific fields of a table.

• A possible use for S_TABU_LIN would be to display and to change content for only a certain work area, such as a country or a plant.

• The table key fields/row are defined and linked to organizational criterion in customizing.

• Once the defined organization criterion is activated it is not possible to display or maintain contents in the table which has been linked to it in customizing without authorization to object S_TABU_LIN for the table key field value.

ZCOMPANY

Company Code

COMPANY

Company Code

ZORGTABLE

Table FieldsCOMPANY

ZCOMPANY

Organizational Crit.

Org. Crit. name

Attribute

Name

View/table

Field Name

Domain

S_PROGRAM (ABAP Program Run Check)

• Programs like tables are protected against unauthorized access using authorization groups.

• Authorization group is stored in program attributes.• Program authorization groups can be maintained using report RSCSAUTH• The following activities are controlled:

– SUBMIT : To start a program execution– BTCSUBMIT : Schedule a program as a background job.– VARIANT : To create and execute a program as a variant.

Serialization Using Object Types: Consistency Check

Attributes

Title

Authorization Group

Package

ABAP: Program Attributes RBDSERCHECK Display

Type

Application BASIS

S_ALE

SALE

Executable Program

CONTROLLING USER AND ROLE ADMINISTRATION

Lesson 6

Controlling User and Role Administration

• A security administrator responsible for user and access management in an organization would frequently use transactions SU01 and PFCG for maintaining users and roles respectively.

• Some of the important tasks of a security administrator are:– Create and maintain users– Lock/unlock users and reset passwords – Create and maintain roles – Maintain the transaction in menu and authorization data– Generation of profiles– Assign roles and profiles to users– Transport roles– Monitoring of system access etc.

Important authorization Objects in User and Role Administration

• This object controls the user groups for which the administrator is allowed to maintain users and the allowed activities.

• If all users are monitored and assigned to an appropriate user group, this object can be used to decentralize the user administration activities.

S_USER_GRP (Users Groups)

• Role names for which the administrator is allowed to perform activities.• If the roles are created in proper naming conventions then this object can be used to

decentralize the role administration tasks.

S_USER_AGR (Role Check)

• Authorization object to control which transactions an administrator is allowed to include within a role.

• This object can be used to prevent administrators from assigning critical transactions to job roles.

S_USER_TCD (Transactions in Roles)

• This object controls the field values that an administrator may enter in the roles for an authorization object and related fields.

S_USER_VAL ( Field Values in Roles)

• This object controls the profiles that can be maintained or assigned by an administrator.• Similar to roles it is important this object can be used for decentralized administration if

controlled by proper naming conventions.

S_USER_PRO ( Authorization Profile)

• Controlling the authorization objects and authorization names for which an administrator is allowed access.

• To prevent critical authorizations from being created within the roles.

S_USER_AUT (Authorizations)

Decentralized User and Role Administration

Single Control• User Administration

and • Authorization

Administration and• Profile generation by

one administrator• For smaller

organizations where there are not many users

Dual Control• User Administration

and• Role Administration

are separate activities• Done by separate

teams• To bring in tight control

on administration activities

Treble Control• User Administration

and • Authorization

Administration and• Profile generation are

done by separate team of administrator(s)

• Maximum control and very tight security framework.

Dual &Treble Control

• Creates the user master records, profiles and authorizations for the administrators

• Creates roles, selects transactions and maintains authorizations.

• Saves the authorization data but does not generate the profile

• Reviews the role and authorizations maintained by the role administrator. Cannot add/remove transactions or change the role authorization data.

• Generates the profile

• Creates users, Assigns the roles and Profiles

• Lock and Unlock Users• Cannot create or change the

roles

Super User Role Administrator

Profile AdministratorUser Administrator

Sample Use Case

• Authorizations for user administrators are decentralized based on location. A administrator role authorizations for India has to be set up such that he can

– Create, change, display, display change documents, lock/unlock users

– Assign roles and profiles to users– Display roles and profiles and their change documents

• Naming Convention for India User Group : INDUSER Roles : Composite Roles – Z.IN* and Single Roles – ZIN*

Z.IND_USER_ADMIN India User Administrator


Maintained Authorizations: Role Check

Maintained Authorizations: Role Check

* Activity 01.02,03,08,22

* Role Name Z.IN*, ZIN*

BC_A

S_USER_GRP

T_YA67011010

ACTVT

CLASS



* Activity 01.02,03,08,22


INDUSER

S_USER_GRP

T_YA67011010

ACTVT

CLASS

TROUBLESHOOTING AND ADMINISTRATION AIDS

Lesson 7

Troubleshooting and Administration Aids

• SAP provides tools like SU53 and ST01 for troubleshooting and finding missing authorizations for users.

• There are plenty of administration reports which aid in evaluation functions.

Authorization Failure

Authorization Error Analysis

: SU53

Authorization Trace :

ST01

• RSUSR002 : Users by complex selection criteria• RSUSR008 : By critical combinations of authorizations at transaction start• RSUSR008_009_NEW : List of users with critical authorizations• RSUSR020 : Profiles by complex selection criteria• RSUSR030 : Authorizations by complex selection criteria• RSUSR040 : Authorization objects by complex selection criteria• RSUSR070 : Roles by complex selection criteria• RSUSR100 : Change Documents for Users• RSUSR101 : Change Documents for Profiles

Authorization Error Analysis – SU53

A user tries to make

changes to a

vendor master record

and faces an authoriz

ation error.

The user types

/nSU53 in the

command field and

takes a screensh

ot of missing authoriz

ation data.

User sends

the screenshot to the authoriza

tion administrator for

troubleshooting and

resolution.

T00080021Vendor

Plant

Vendor Account Changes: Initial Screen

Purch Org. 1000

No authorization for changing vendors in purch. Org. 1000

Authorization object M_LFM1_EKO

Authorization Field ACTVT

Authorization Field EKORG

Authorization check failed

02

1000User’s authorization Data USER01

Authorization object M_LFM1_EKO

Authorization T-C01001045689

Profile T-C0100104

Role Z_MASTER_DATA Master Data Admin

Authorization Field ACTVT

Authorization Field EKORG

02,03,08

2000

Authorization Trace – ST01

• An experienced security consultant can judge by plainly looking at an SU53 screen as to whether it is pointing towards the correct missing object or not.

• If there are a series of authorization failures when executing a transaction code SU53 may only point you to the last failed check (which may be unimportant or intentionally suppressed for the user).

• ST01 is the tool that consultants should rely upon under circumstances where SU53 analysis is incorrect. ST01 provides quite accurate results for authorization checks. It lists down the complete story for the authorization checks for users in a system when turned on.

System TraceChange Trace Trace off

Trace switched on (main switch on)Trace Status

Analysis

Trace Components

Authorization Check

Kernel FunctionsGeneral Kernel

SQL Trace

Table Buffer Trace

RFC CallsLock Operations

General Filters

X

System Trace: Filter

Process number

USER01User

Transaction

Program

Client 010 User USER01 Transaction MK04

Work Process 0 PID Date 16.10.2011 Start 07:03:00 Finish 07:03:09

Block Version 1248 No of Records 3 File version 1

hh:mm:ss Type Object Text

07:03:01

07:03:09

AUTH

AUTH

AUTH

F_LFA1_APP RC=0

F_LFA1_GEB RC=0

M_LFM1_EKO RC=4

APPKZ=M; ACTVT=08

ACTVT=08;

EKORG=1000:ACTVT=08;

07:03:03

Improvements in ST01 – Note 1373111

When activating the authorization trace and/or when evaluating the

authorization checks, you can specify that you want to trace only failed authorization checks. Since only incorrect authorization checks are recorded, the performance loss

is slight and the search for messages is made easier in

transaction ST01.

The system stores additional information for each authorization

check in the authorization trace like user name for which an authorization check was

made ,Within which transaction the authorization check was made and

Additional information about the reason why the authorization check

was successful or not.

Information System – Administration Aids

• Once you have identified the missing authorization object, it does not necessarily mean that you start modifying the user’s job roles.

• You can try to find alternative solutions like existing roles with the required authorizations which can be assigned to the user without granting too much extra access.

• There are several useful reports from the user information system available which aid in deriving these solutions.

• These reports help an administrator to gain an overview of the users in the system and many other related facts.

• The transactions listed in the screenshot on the left can be called as executable reports starting with RSUSR* which can be called from SA38.

• A complete list of these useful transactions can be found in the user information system SUIM which is one place from which you can branch and jump to individual reports.

Transaction Text

S_BCE_68001400 Users According to Complex Criteria

S_BCE_68001401 Critical Combinations of Auth.

S_BCE_68001402 With Unsuccessful Logons

S_BCE_68001403 With Critical Authorizations

S_BCE_68001404 Profiles by Contained Profiles

S_BCE_68001405 Profiles by Authorization Name

S_BCE_68001406 Profiles by Values

S_BCE_68001407 Profiles by Changes

S_BCE_68001408 Profiles by Roles

S_BCE_68001409 Profiles According to Complex Crit.

S_BCE_68001410 Auth. Objects According to Complex




S_BCE_68001414 Auth. According to Complex Criteria

S_BCE_68001415 Authorizations by Values

S_BCE_68001416 Authorizations by Changes

S_BCE_68001417 Auth. According to Complex Criteria

S_BCE_68001418 Roles by Role Name

S_BCE_68001419 Roles by User Assignment

S_BCE_68001420 Roles by Transaction Assignment

S_BCE_68001421 Roles by Profile Assignment

S_BCE_68001422 Roles by Authorization Object

S_BCE_68001423 Roles by Authorization Values

S_BCE_68001424 Roles by Change Data

S_BCE_68001425 Roles by Complex Criteria

System Audit Information

• As of release 4.6C there is a special role concept used for SAP System auditing which was previously done using AIS (Audit Information System) transaction SECR.

• Roles:– SAP_AUDITOR (AIS - Audit

Information System)– SAP_AUDITOR_TAX (AIS - Tax

Audit)

• With the role concept the flow and quality of the checks has improved considerably.

System Audits e.g. Tables, Authorizations

etc.

Business Audits e.g. account closing, assets,

inventories etc.

External and Internal Audits

Tax Audits

TRANSPORTING AUTHORIZATION COMPONENTS

Lesson 8

Transporting Authorization Components

Copy User Master Records to other clients.

Transporting Roles

Transporting SU24 check indicators

Transporting in a CUA implemented landscape

Transporting Roles

Upload/Download Roles

•Normally it is only possible to exchange data with transport requests between SAP systems with the same release status. For example, if roles have to be exchanged across releases, this can be done by downloading or uploading roles.•When you download the data, it is all stored in a local file, with the exception of the generated authorization profiles and the user assignments.•After an upload, the role might have to be edited and generated. •You can save multiple roles in a local file at the same time by choosing Utilities → Mass download.

Transporting Users

There is no transport mechanism for user master records. You can copy user master records either using a client copy or use

central user administration and use it to distribute the user master records of the central system to the child systems.

Local Client Copy: Copy data to a new client of the same system. Data is not

transported through network or OS. (SCCL)

Client Copy between Systems: 1) Client Transport (SCC8) 2)

Remote Client Copy

Client Copy – Copy a Client

Schedule Background Start immediately

Target Client

Selected Profile

Description

Source Client

010 Customizing

SAP_UCUS

Customizing and User Master

000 SAP AG Konzern

Client Copy – Copy a Client

Schedule Background Start immediately

Target Client

Selected Profile

Description

Source Dest.

010 Customizing

SAP_UCUS

Customizing and User Master

000 SAP AG KonzernSystem Name

Transporting Check Indicators

•The customer tables USOBX_C and USOBT_C which are adjusted as per customer needs can be transported as a whole with all settings of check indicators, status and field values in step 3 of SU25.•It is also possible to maintain values for individual transactions in SU24.•In both cases, a transport request is transported and distributed to other SAP systems in the context of the Transport Management System.• During the transport, all of the check indicators and field values in

the target system are replaced, and steps 2a-2d cannot be used.

CONFIGURING ROLE MAINTENANCE TOOLS

Lesson 9

Configuring Role Maintenance Tools

• Configure the role maintenance tools to reduce efforts during role maintenance in PFCG.

• Role maintenance uses default values shipped by SAP which affects how PFCG operates as well as how security checks are carried out during runtime.

• If the default values shipped by SAP do not meet your needs the tools can be configured so that you do not end up making multiple changes to authorizations within roles.Tran

saction

Code

USOB* tables (SU24)

proposal delivered <

80% default by

SAP. Customer values to be set.

Authorization

Object (PFCG- Authoriz

ation Maintenance)

PFCG & SU24: How it works? Benefits?

When a transaction is added to the PFCG menu the system reads tables (USOBX_C) to know which authorization objects need to be added and maintained for the transaction.

These tables can be accessed, read and maintained using transaction code SU24

SU24 also proposes in some cases default values ((USOBT_C) for the authorization objects which further eases role maintenance.

The more accurately SU24 is maintained more accurate are the maintained authorizations in the roles. This also means lesser efforts for role maintenance.

If a security administrator is often inserting authorizations manually or often modifying default SAP authorizations, there is an opportunity to use SU24 to better manage authorizations within the roles.

When to use SU24?

To link authorization objects to transaction codes.

To correct the incorrectly proposed default values

Allowing blank fields for objects if the roles would want to use the object

differently.

For Custom transactions.

Adjusting SU24

Check Indicator Proposal

Object User Name Check Ind. FlagSt

K_CSKS_SET CO-CCA Cost Center Groups Check NO

K_KEKO CO-PC Product Costing Check NO

M_ANFR_BSA Document Type in RFQ Check NO

M_ANFR_EKG Purchasing Group in RFQ Check NO

Field Values Object Object

CheckDo Not Check

Set Status “Yes”

Set Status “No”

Set Status “New UnMaintained”

Object Field Name From

M_BEST_BSA ACTVT 01

M_BEST_BSA ACTVT 02

M_BEST_BSA ACTVT 03

M_BEST_BSA BSART

Change To

ME21NTransaction Code

Name Authorization ObjectAuthorization Fld.

Authorization Value

Authorization Value

Changed by

Modification Date

Modification Time MODIFIED

MB03 M_MSEG_BMB ACTVT 03 SAP 30.08.2004 14:29:40 MB03 M_MSEG_BMB BWART SAP 30.08.2004 14:29:40 MB03 M_MSEG_LGO ACTVT 03 SMITHJ 17.09.2005 15:33:40 XMB03 M_MSEG_LGO BWART SMITHJ 17.09.2005 15:33:40 XMB03 M_MSEG_LGO LGORT SMITHJ 17.09.2005 15:33:40 X

Start transaction SU24

Enter the transaction code for the affected value and execute.

Choose Change field values.

In the Proposal column update the

values for the authorization object you want to change.

Authorization Checks

• To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.

• The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:– Starting SAP transactions

(authorization object S_TCODE)– Starting reports (authorization

object S_PROGRAM)– Calling RFC function modules

(authorization object S_RFC)– Table maintenance with generic

tools (S_TABU_DIS)

Authority-Check at Program Level

Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the

program, to check whether users have the appropriate authorization and whether these authorizations are

suitably defined; that is, whether the user administrator has assigned the values required for the fields by the

programmer. In this way, you can also protect transactions that are called indirectly by other

programs.

AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the

authorization object specified in the AUTHORITY-CHECK. If one of the

authorizations found matches the required values, the check is successful.

Authorization Checks: Starting SAP Transaction

When a user starts a transaction, the system performs the following checks:

• The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.

• The system then checks whether the user has authorization to start the transaction.*• The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user

must have an authorization with a value for the selected transaction code.• If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also

requires the suitable defined authorization object (TSTA, table TSTCA).**• The system checks whether the transaction code is assigned an authorization object. If so, a check is made

that the user has authorization for this authorization object.***

Authorization Checks: Starting Reports

You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH).

You can, for example, assign all PA* reports to an authorization group for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this group.

Authorization assignments for reports are overwritten during an upgrade. After an upgrade, you must therefore restore your customer-specific report authorizations

As of Release 3.0, SA38 is replaced by the report

trees which contain reports (as well as variants and

stored lists). In each case, the reports are allocated to

nodes of a report tree. Other than the standard

SAP reports, the tree can also contain customer-

specific reports. This can be maintained in

Customizing. In the report tree, every node can have its own authorization group

or inherit one from its predecessor. In this case,

when branching to the contents of a node (that is,

the reports), an authorization check is run and cancelled if necessary

(object S_PROGRAM, value SUBMIT).

Authorization Checks: RFC calls/Table Maintenance

Calling RFC Functi

on Modul

es

When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system.This check uses the name of the function group to which the function module belongsYou can deactivate this check with parameter auth/rfc_authority_check.

Assignment

of Authorization Group

s to tables

You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16)A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments.The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Reducing Scope of Authorization Checks

• In addition to use transaction SU24 to display default field values, you can also use it to reduce authorization checks at runtime.

• This has the effect of not performing an authorization check on a specific authorization object.

• You should be careful when deciding which authorization checks to suppress. By suppressing authorization checks, you allow users to perform tasks for which they are not explicitly allowed.

• For an authorization check to be executed, it must be included in the source code of a transaction and must not be explicitly exempt from the check.

• You can suppress authorization checks without changing the program code, as check indicators control authorization checks.

Business Case

• When SAP System transactions are executed, a large number of Authorization Objects are often checked, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload.

Reducing Scope of Authorization Checks

• The authorization check indicator defines whether or not the authorization check for this object is performed during the execution of the transaction. Possible values are "Check" and "Do Not Check“

• From an auditor's perspective, if you find an authorization check has been disabled, just ensure that disabling meets with the company policy.

Do Not Check

• The authorization check is not performed (more precisely: it always returns sy-subrc=0) when the transaction is run. Not that, for technical reasons, this value can only be set for transactions, and not for Basis or HR authorization objects. Only set this value if you know the implications of doing so.

Check

• The authorization check takes place as normal. This is the default value. Only change this value if you have good reasons for doing so.




K_KEKO CO-PC Product Costing Check YS



CheckDo Not Check


PFCG INSTALLATION AND UPGRADELesson 10

PFCG Installation and Upgrade

• Before the Profile Generator can be used, you must activate it in the system and link it with default tables for the delivered SAP transaction codes.

• Since release 4.6 the profile generator is already activated. This means that you do not have to set the system parameter in the instance profile : auth/no_check_in_some_cases=Y

• This is set as default and you only need to verify the same in transaction RZ11 or run the report RSPARAM.

Auth/no_check_in_some_cases

Activation of the Profile Generator

Authentication

Y

Y

Y

Short description

Appl. area

Default value

Profile value

Current value

Tables USOBX_C and USOBT_C

• When the administrator adds a transaction to a role the profile generator selects and proposes the authorization objects that are checked and maintained in profile generator for this transaction.

• Tables USOBX_C and USOBT_C control the behavior of the Profile Generator after the transaction has been selected. After a new installation, these tables are empty and must be filled with values before the Profile Generator is used for the first time.

• SAP delivers the tables USOBX and USOBT. These tables are filled with default values and are used for the initial fill of the customer tables USOBX_C and USOBT_C. After the initial fill, you can modify the customer tables, and therefore the behavior of the Profile Generator, if required.

• Table USOBX defines which authorization checks are to be performed within a transaction and which are not (despite programmed authority-check command).This table also determines which authorization checks are maintained in the Profile Generator.

• Table USOBT defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator.

Tables USOBX_C and USOBT_C

ME21N TR M_BANF_EKO SAP 30.08.2010 13:00:00 X

ME21N TR M_BANF_WRK SAP 30.08.2010 13:00:00 X

ME21N TR M_BEST_BSA SAP 30.08.2010 13:00:00 Y

ME21N TR M_BEST_EKG SAP 30.08.2010 13:00:00 Y

ME21N TR M_BEST_EKO SAP 30.08.2010 13:00:00 Y

ME21N TR M_BEST_WRK SAP 30.08.2010 13:00:00 Y

ME21N TR M_EINF_EKO SAP 30.08.2010 13:00:00 X

ME21N TR M_EINF_FRG DDIC 01.02.2011 15:03:00 X

ME21N TR M_INFO_MCD SAP 30.08.2010 13:00:00 X

ME21N TR M_IS_KENNZ SAP 30.08.2010 13:00:00 X

ME21N TR M_MATE_CHG SAP 30.08.2010 13:00:00 X

Checkfl Short Description

N No authorization check

Authorization check takes place

Not maintained

Authorization check takes place, default values in USOBT Not maintained

X

UY

USOBX_C

ME21N TR M_BEST_BSA ACTVT 01 SAP

ME21N TR M_BEST_BSA ACTVT 02 DDIC



ME21N TR M_BEST_BSA ACTVT 09 SAP

ME21N TR M_BEST_BSA BSART SAP

ME21N TR M_BEST_EKG ACTVT 01 SAP

ME21N TR M_BEST_EKG ACTVT 02 DDIC




ME21N TR M_BEST_EKG EKGRP $EKGRP SAP


USOBT_C

SU24 – Check Indicators

• After the customer tables USOBX_C and USOBT_C have been filled, you can maintain them to adjust the behavior of the Profile Generator and the authorization checks to be performed for each transaction. The tables are maintained in transaction SU24.

• This transaction displays the check indicators of a transaction. Check indicators determine if an authorization check will run within the transaction or not.




K_KEKO CO-PC Product Costing Check NO


M_ANFR_EKG Purchasing Group in RFQ Check NO


CheckDo Not Check

Set Status “Yes”

Set Status “No”

Set Status “New UnMaintained”

Object Field Name From

M_BEST_BSA ACTVT 01

M_BEST_BSA ACTVT 02

M_BEST_BSA ACTVT 03

M_BEST_BSA BSART

Change To


SU24 – Maintenance Status

• The behavior of objects is no longer governed solely by the check indicator (as was the situation before SAP NetWeaver 2004s); instead, the maintenance status of the authorization object is also considered.

• The maintenance status of an authorization object shows whether authorization default data has been correctly maintained for the object.

• Possible values are:

– "Maintained" (green traffic light).– "Unmaintained" (red traffic light).– "maintained with warning" (yellow traffic light).– "Do not check" (gray traffic light).

Object Object DescriptionSt

A_A_VIEW

A_S_ANLKL

A_S_KOSTL

C_STUE_BER

Asset View

Asset Master Record Maint. (Ccode/Asset Class)

Asset Master Record Maint. (Ccode/Cost Center)

CS BOM Authorizations

SU24 – Proposal Status

• The proposal status of an authorization object defines whether or not an authorization default value for the object is to be added in the profile generator to the authorizations of the role when the application is added to a role. Possible values are "Yes" or "No".

• "Yes". An authorization default value with the stored authorization field values is added to the role. The field values should also be maintained - as far as possible, and as long as this is useful.

• "No". No authorization default value is added to the role.• ' '. Initial value. This value shows that the application

developer responsible has not yet decided whether "Yes" or "No" is to be set here.

Security Upgrade

• What do you need to do if you perform an upgrade?

– Migration of report trees– Check of Profile Generator

activation– Upgrade of the roles and

default tables (SU25, steps 2A-2D)

– Conversion of manually created profiles to roles if necessary (SU25, step 6)SAP Web AS

6.20•The Global User Manager was deactivated (see SAP Note 433941).•Additional system parameter login/password_change_for_SSO (for logon with Single Sign-On) specifies whether the user must change his or her password.

SAP Web AS 6.10

•Additional system parameters for logon•Generation and deactivation of passwords•Synchronization of the SAP database with an LDAP directory

Source release < SAP R/3 4.6B

•You have to migrate customer-defined report trees because the data structure of report trees changed internally (transaction RTTREE_MIGRATION). � �The report is automatically assigned a transaction code.•New fields in user administration

Installing the Profile generator

Post-process the Settings After Upgrading to a Higher Release

Transport Conn.

Adjust the Authorization Checks (Optional)

Create Roles from Manually – Created Profiles

1. Initially Fill the Customer Tables

2A.. Preparation: Compare with SAP values2B. Compare Affected Transactions

2C. Roles to Be Checked2D. Display Changed Transaction Codes

3.. Transport the Customer Tables

4. Check indicator (Transaction SU24)5. Deactivate Authorization Object Globally

6. Copy Data from Old Profiles

Upgrade - Scenarios

• There are always two possibilities:– Source release did not use PFCG

• PG needs to be activated.

– Source release used PFCG (>3.1G)• USOBX_C and USOBT_C needs to be updated.• Roles need to be updated.

• If you are using PG for the first time:– You can start building your roles using PG– Convert the manual profiles into roles using

step 6 of SU25.

Upgrade – Source release > 3.1GInstalling the Profile generator

Post-process the Settings After Upgrading to a Higher Release

Transport Conn.

Adjust the Authorization Checks (Optional)

Create Roles from Manually – Created Profiles

1. Initially Fill the Customer Tables

2A.. Preparation: Compare with SAP values2B. Compare Affected Transactions

2C. Roles to Be Checked2D. Display Changed Transaction Codes

3.. Transport the Customer Tables

4. Check indicator (Transaction SU24)5. Deactivate Authorization Object Globally

6. Copy Data from Old Profiles

• The USOB* tables and the roles both need to be updated to the latest version.

• Transaction SU25, steps 2A to 2D.

– 2A: Executes the Profile Generator comparison program. Compares the new tables USOBX and USOBT with USOBX_C and USOBT_C.

– 2B: Adds any new transactions/updates to tables USOBX_C and USOBT_C.

– 2C: Updates the existing roles and flags all roles with new authorization objects.

– 2D: Displays all roles for which there are changed transaction codes.

Upgrade Profile : SAP_NEW• The profile SAP_NEW is delivered with

every new release and contains authorizations for all new checks in existing transactions.

• The SAP_NEW profile guarantees backward compatibility of the authorizations if a new release or an update or authorization checks introduces checks for previously unprotected functions.

• Composite profile to bridge the differences in releases in the case of new or changed authorization checks for existing functions, so that your users can continue to work as normal.

• If there are a large number of roles to be modified due to an upgrade then you can buy time to process these roles later by assigning users SAP_NEW on a temporary basis provided it is allowed as per the organizations security policy.

• The SAP_NEW composite profile consists of single profiles for all old releases of SAP.

SAP_NEWProfile

Comp profileTexts in User Master

New authorization checksText

Consisting of Profiles

Profile TextSAP_NEW_21C Authorizations for new objects added Rel. 2.1CSAP_NEW_21D Authorizations for New Objects Added Rel. 2.1DSAP_NEW_22A Authorizations for New Objects Added Rel. 2.2ASAP_NEW_30A Authorizations for New Objects Rel. 3.0ASAP_NEW_30B Authorizations for New Objects Rel. 3.0BSAP_NEW_30C Authorizations for New Objects in Release 3.0CSAP_NEW_30D Authorizations for new objects in Release 3.0DSAP_NEW_30E Authorizations for New Objects in Release 3.0ESAP_NEW_30F Authorizations for new objects in Release 3.0FSAP_NEW_31G Authorizations for New Objects in Release 3.1GSAP_NEW_40A Authorizations for New Objects in Release 4.0A

ActiveStatus

DDICChanged by

ORGANIZATIONAL MANAGEMENT

Lesson 11

Organizational Management

• Overtime people change positions, departments and collect authorizations for their new areas of work. If the user administrator forgets to remove the authorizations for the user’s older departments or positions then the user keeps on receiving more authorizations.

Purchasing Depart

ment

•Operational Purchaser•Master Data Manager

Acco

unting Depart

ment

•Operational Purchaser•Master Data Manager - Purchasing•Accounting Clerk•Master Data Manager - Accounting

Warehous

e

•Operational Purchaser•Master Data Manager - Purchasing•Accounting Clerk•Master Data Manager - Accounting•Warehouse Manager•Inventory Manager

Buyer Accounts Clerk

Warehouse Manager

Position based authorization management

• If the roles are now assigned to the objects of the organizational plan, such as positions, the employees, who are indirectly assigned to these positions through the organizational plan, can inherit the roles.

• Advantage: As soon as an employee changes position, he or she also loses the corresponding authorizations (since these depend not on the user, but on the position).

• Create roles based on organizational objects, such as positions in your organization. For example: Sales manager, accountant, and secretary.

• Assign the roles to your organizational plan. Users then inherit the authorizations (indirectly) in accordance with their position in the organizational plan.

Purchasin

g Departm

ent

•Operational Purchaser•Master Data Manager

Accountin

g Department

•Accounting Clerk•Master Data Manager - Accounting

Warehouse

•Warehouse Manager•Inventory Manager

BuyerAccounts Clerk

Warehouse Manager

Holder(s)

Holder(s)

Holder(s)

Organizational Plan

• An organizational plan represents a functional organization and reporting structures between positions in an enterprise.

• Organizational Management’s object-oriented design provides you with a number of organizational objects with which you create organizational plans.

• At the center of an organizational plan are organizational units(departments, for example) arranged in a hierarchy that mirrors the structure of your enterprise. Other organizational units such as positions(sales administrator, for example) depict your enterprise’s reporting structure. Objects such as jobs, tasks, and work centers are the building blocks of your organizational plan.

• By relating objects via relationships, you create a network that mirrors your organizational and reporting structures.

Organizational Plan

Organization Unit B

Position2

Job

Task

Work Center

Position1

Job

Task

Work Center

Organization Unit A

Position1

Job

Task

Work Center

In addition to this, you can create relationships to objects from other components (cost center, employee or R/3 User, for example).

Organizational Management in SAP

• PPOCE : Create Organization and Staffing

• PPOME : Change Organization and Staffing

• PPOSE : Display Create Organization and Staffing

• In the simple maintenance mode, You work in three main windows. Each window covers specific maintenance activities:• The Organizational Structure window

allows you to build up and maintain the organizational structure for your organizational plan.

• The Staff Assignments window allows you to identify the fundamental staffing details required for an organizational plan.

• The Task Profile window allows you to assign roles to jobs, positions, organizational units, and holders of positions (users). Workflow Tasks are also assigned at this level, however, these are not related to authorizations.

Organizational Structure/Change

Org. Unit

Search Term

Structure Search

Plan version 01 Current plan

Department 2510/000/000

Department Marketing

Department Finance

Department Logistics

Staff Assignments/Change

Org. Unit

Search Term

Structure Search


Department Marketing (Org Unit)

Sales Mgr – Marketing (Position)

Lisa Kudrow (Person/user)

Task Profile/Change

Org. Unit

Structure Search


Department Marketing (Org Unit)

Change invoice status (Task)

Change stat. of confirmation (Task)

Search Term

Position Job

UserEmployee (Role)

Infosys Technologies Limited

Bangalore DC, Pune DC, Hyderabad DC etc.

HR Manager, Delivery Manager, etc.

HR Manager ES, Delivery Manager ES etc.

Manager resources, Create Projects etc.

John Smith, Lisa Norman etc.

Steps in Organizational Management

Create a root organization unit

Create subordinate organization units

Create Jobs

Create Positions

Assign Tasks

Assign Holder

Role Maintenance - PFCG

• To be able to assign components of your organizational plan, you must select the “Complete View” when entering PFCG.

• By choosing the Organizational Mgmt button on the user tab, you jump to the screen Role: Change Agent Assignment The Indirect User Assignments that have already been maintained are displayed here.

• Here you can use positions to assign users to a role(such as SALESMANAGER). By choosing Create assignment, you can also define the following relationships:

• Role / Organizational unit• Role / Position• Role/User

View

Complete view (Organizational Management and workflow

Settings

Simple maintenance (Workplace menu maintenance)Basic maintenance (menus, profiles, other objects)

Role: Change Agent Assignment

Indirect user assignments ok

AG /SAP/EMPLOYEE

C 50004150 Sales Manager

S 50004151 Sales Manager - Marketing

EMPLOYEE

CP 50003346 Lisa Kudrow

O 90000755 Department Marketing

S 50004151 Sales Manager - Marketing

CP 50003346 Lisa Kudrow

Role

Job

Position

Person

Org. Unit

Position

Person

SECURITY IN PROJECTSLesson 12

Implementation Methodology

Project Preparation

Blueprint

Final Preparation

Go-Live

• Every company or every project follows a implementation methodology which can be more or less divided in five distinct phases.

• Project Preparation: Forming the team and assembling the resources required for project implementation.

• Blueprint: Determine the business requirements and formulate a visual representation of the as-is business process to be mapped in SAP.

• Realization: This is phase where the business requirements are implemented in the system through configurations and development.

• Final preparation: Testing of the interfaces and modules, Training of the users, move changes to production, Fine tuning and soft configuration of the production system etc.

• Go-Live & Support: Release of system access to users, Enhancements and Bug-Fixes.

Preparation

• Form an authorizations team• Define roles for the team members• Clarify the scope,processes etc.• Train the team if required.

Blueprint

• Analyze the business process with the project team• Determine the various roles and activities within the roles.• Prepare a list of the roles for the business process and list the actvities for each role.• Determine an ideal design for the job roles• Determine an naming convention for the roles.

Realization

• Implement the job roles in the system as per the agreed design.• Implement a user management concept.

Final Preparation

• Authorization tests both positive and negative.• Train the users on the user management process• Creation of the production users list with assignment of job roles.• Create the users in the production system.

Go-Live and Support

• Release system access for production use to the trained users.• Record the authorization issues and enhancements• Fix the issues and realize the enhancements as per agreed change management procedures.

Authorization Project Methodology

Blueprint Phase

• The blueprint phase for the authorizations may start only after the business blueprint is done.

• This is because the authorizations can be analyzed and conceptualized only after the business processes are documented.

• The main steps during this phase are:– Analyze the business process with the project team– Determine the various job roles and activities to be included within the roles.– Prepare a list of the roles for the business process and list the activities for

each role.– Determine an ideal design for the job roles– Determine an naming convention for the roles.

• The Process Master List is a document which forms a basis for this phase. It documents all the activities that are performed during a business process. These activities are mapped with SAP transactions in this list.

• This list should be ready and signed off to start working on the job roles.• The authorizations team along with the business process owners would work on

grouping these activities to form the job roles.

Activity Group Process Group ActivityPrimary Transaction Codes (mandatory for SAP activities)

System Type(for Activities only)

A-LM059_LXX LM Determine Putaway Location

MB1B/MIGO SAP R/3

A-AP001_LXX AP Requisitioner checks SAP for Vendor Existence

FK03 SAP R/3

A-AP002_LXX AP Request to create/change Vendor Master Data

N/A Manual

A-AP003_LXX AP Purchasing Complete Vendor Creation Form for AP

N/A Manual

A-AP004_LXX AP Terms of Payment request

N/A Manual

A-AP010_LXX AP Maintain Vendor Master

FK01, FK02, XK01, XK02 SAP R/3

Process Master and Authorizations List

User

Buyer

Stock Procurement

Purchase Order

Contracts

Scheduling Agreements

Consumption Procurement

Purchase Order

Contracts

Scheduling Agreements

Master

Data Maintenan

ce

Supplier

Records

Source Lists

Vendor Master

Info Records

User Master record Job Roles Group of activities Activities

Authorizations Concept in SAP

Role design approach

• Derived roles are only helpful initially for small roles (or individual tasks) which truly are exactly the same (except for the org or other element of a common object). If you are planning some major acquisitions and diversity in your production locations and sales organizations, then derived roles might be an option for a "Just One Company Code" system, but your business areas and other org elements will be forced to some extent to have the same business processes or your roles will provide too much access for the others when one of them wants something special. You will become inflexible and over time the differences will destroy your concept very easily.

• One would want to create a common set of roles which contains the required org level authorizations for the various roles and then create a second set of roles for the functions in the different business areas and add the differentiated org elements to them. Make sure that the transaction you select actually also use these. What you have is a transactional role containing all the transactions & auth objects. You then create a separate role with manually added auth objects that contain all the auth objects that are relevant for restriction. You then disable those objects in the transactional role. This way you have 2 roles, one providing transactional content & the other providing all your restrictions.

– One of the perceived benefits is that you only have 1 role containing restriction data and this can be applied to all users. You then give them different transactional roles depending on what transactions they need etc.

– Downsides to this are:Increased complexity: It can be a steep learning curve for a new administrator in the company.Reduced security: Security is based on 2 levels, S_TCODE & object level. If you are creating a single value role (or even a few of them) they are going to contain more auth objects than are needed for the respective transactional roles. SOD analysis: It makes analysis and reporting at role level more complex. Breaking SAP security setup: When you take this approach you may be breaking the link between PFCG and SU24.

• Also we have to decide whether we have one single role with all the transactions or break them up into smaller roles. They have their Pros and Cons as mentioned below:

– It might be desirable for users to only have one role (in addition to a "common role for all users"). This way SoD analysis can concentrate on analyzing authorizations within single role designs, without the added complexity of doing role to role comparisons

– Smaller roles can be used across multiple functions thus limiting the total number of roles can have a dramatic impact on the total maintenance effort. When designed the right way.

– A big role (per position) is avoiding redundancy of transactions in various smaller roles where they could easily have different values on object level.

Naming Convention

• It is important to assign a unique identifier to the roles through a flexible and standardized naming convention.

• There are 30 characters available to define the role name.• One of the best approaches to use the elements like region (e.g.

US,GB,DE etc.), application module(e.g. FI,MM etc.) and business process(e.g. FRAP, OPMA etc.) in the role names.

• Role names should be flexible and extensible so that they do not lose their significance on addition or removal of transactions within them.

• Naming conventions also help in segregating the role and user administration tasks.

• The role names are not language dependant and should not begin with SAP.

• It is also important that you align the naming conventions with that of the project.

Role Documents

• You have finalized upon the below criteria:• Number of job roles to be created• The transactions to be included in each job role• Design approach for the job roles• Naming convention for the job roles• Now you can start to create job role documents to identify and describe each role

both technically as well as functionally.• The document should cover the following aspects of the role:• Role name and Description• Transactions that are included in the role• Business relevance of the role through a brief description of its functionality.• Critical authorizations included within the role• Organizational values and other restrictions within the role• Role documents are very useful for the business process owners to understand the

job roles that are being built and to suggest any modifications if necessary before they are implemented in the system.

• A formal sign off by the business owners and project managers on these documents is recommended.

Realization Phase

• Start building the job roles in the system as per the role documents.

• Informal screening of the roles by the functional team is recommended during this phase to ensure that the authorizations are being set as desired.

• Prepare test users per role/per module.• Changes to the transactions within the role and addition /

removal of job roles in the list is expected during this phase.

• Define the test scripts for testing the authorizations in the next phase.

Testing• The test scenarios

should include both positive and negative tests for the individual roles.

• Any deviation from what has been defined in tests should be documented and corrected appropriately.

• If it is a deviation due to system errors then it should be re-tested after the correction.

Training• The super users should be

trained on the roles set up and the user management process to be followed in the production operations.

• Systems like SRM, SCM , Solution Manager etc need a business partner and in some cases organizational assignments for users.

• These are also aspects and parts of complete user access management and super users should be properly trained on these aspects as well.

User Management• Check and confirm the

user – role assignment list.

• Create the users in the production system based on the list .

• Assign the roles to the users as per the user-role matrix.

• Tools like CATT can be used when there are a large number of users to be created.

Final Preparation

Go-Live and Support

Release system access for production use to the trained users.

Record the authorization issues and enhancement requests.

Fix the issues and realize the enhancements as per agreed change management procedures.

Develop/Adopt a strategic user administration solution.

System Handover

sap security - level 1

Documents

job roles

form of roles

purchase order

purchase requisition

business scenarios

splitting of roles

sap security level

detailed user authorizations