SAP R/3
Security Upgrades
By : Yvette Smith
table of contents
1. overview 4
2. Security upgrade objectives, Process and approaches 5
2.1. Objectives 5
2.2. Overview of the Security upgrade process 5
2.3. Approaches to convert manual profiles to Activity
Groups: 6
2.3.1. Approach #1: SAP’s standard utility SU25 6
2.3.2. Approach #2: Manual reconstruction of Profiles as
Roles (Activity Groups) 7
3. Items requiring special attention 8
3.1. Authorizations 8
3.2. ‘*’ in S_TCODE 8
3.3. Report Trees 8
3.4. ABAP Query reports 8
3.5. S_RFC 8
3.6. Custom tables and views 9
3.7. User menus versus SAP menu 9
3.8. Re-linking of user master records to profiles 9
3.9. Dual-maintenance 9
3.10. Transport of activity groups 10
3.11. Client copies 10
3.12. SU24 10
3.13. Composite Activity Groups 10
3.14. Central User Administration 10
4. additional tips 12
4.1. OSS and Release Notes 12
4.2. Workplan 12
4.3. Standards and Procedures 12
4.4. Testing 12
4.4.1. Resources for testing 12
4.4.2. Test Plan 13
4.5. Issue Management (tracking and resolution) 13
4.6. Status reporting 14
4.7. Detailed cutover plan 14
4.8. Project team access 14
4.9. Training and new functionality 14
4.10. SU53 15
4.11. Post Go-live 15
5. helpful reports, transactions and tables 16
5.1. Reports and Programs 16
5.2. Transactions 16
5.3. Tables 17
The purpose of
this document is to provide additional information that could be helpful with
SAP Security upgrades, especially pertaining to 4.6C.
This document is
not aimed at replacing the SAP Authorizations Made Easy guidebook’s procedures,
but rather to complement these based on lessons learnt from previous upgrade
projects.
It is focused
mainly on upgrades from 3.1x to 4.6x and covers the
following:
·
Evaluation
of the Security Upgrade approaches;
·
“Gotchas” to watch out for with SAP’s
SU25 utility;
·
Transactions
and authorizations that require special attention; and
·
Helpful
reports, transactions, hints and tables to know.
It is highly
recommended that you review the chapter on upgrades in the Authorizations Made
Easy guide before attempting the security upgrade.
See
There are a couple of objectives for having to upgrade the SAP Security infrastructure:
· Converting manual profiles created via SU02 to activity groups, as SAP recommends the use of Profile Generator (PFCG) for the maintenance of profiles;
· Adding new transactions representing additional functionality to the applicable activity groups;
· Adding the replacement transactions that aim at substituting obsolete or old-version transactions, including the new Enjoy transactions;
· Adjusting the new authorization objects that SAP added for the new release; and
· Ensuring that all existing reports, transactions and authorizations still function as expected in the new release of SAP.
Once the Development system has been upgraded to 4.6, the security team will need to perform the following steps as part of the Security Upgrade:
· Convert Report Trees to Area Menus;
· Review users (via SU01) to check for any new or changed fields on the user masters;
· Convert manual profiles created via SU02 to Activity Groups (See Approaches below);
· Compare SU24 customer settings to new SAP default settings (SU25 steps 2A-2C);
· Determine which new / replacement transactions have to be added to which activity groups (SU25 step 2D);
· Transport the newly-filled tables USOBT_C and USOBX_C that contain the SU24 settings you’ve made (SU25 step 3); and
· Remove user assignments to the manual profiles.
SAP provides an utility for converting Manual Profiles to Activity Groups and to identify the new and replacement transactions that need to be added to each activity group.
You can
access this utility by typing “SU25” in the command box.
If you do decide to use SU25 Step 6 to convert the Manual profiles to activity groups, you will need to watch out for the following “gotchas”:
All activity groups created before SU25 is run, are renamed to T_500yyyyy_previous name.
See
Ranges of transactions are not always added correctly to the newly-created activity groups. Some of the transactions in the middle of the range are occasionally left off. E.g. you have a transaction range of VA01 – VA04 for a specific manual profile. After SU25 conversion, the new Activity Group only contains VA01 and VA04. Transactions VA02 and VA03 were not added.
It is important that a complete download of table UST12 is done prior to running SU25. Once SU25 has been run, a new download of UST12 can be done to identify which transactions have been dropped off.
The missing transaction codes will need to be added manually to the relevant activity group via PFCG.
The output of one of the steps in SU25 is a list of the new replacement transactions (e.g. Enjoy transactions) that need to be added per activity group. E.g. transaction ME21N replaces ME21. The list will identify each activity group that has ME21 where ME21N needs to be added to.
In some cases SU25 does not identify all new transactions to be added.
An alternative approach to SU25 is to manually create an activity group for each manual profile that was created via SU02.
The advantage of this approach is that you won’t have any missing transactions that were “dropped off” with the SU25 conversion.
Several new authorization objects have been added with release 4.6. Care should be taken when adjusting authorizations – carefully review all new defaults that were brought in. These are indicated by a Yellow or Red traffic light in PFCG.
It is highly recommended that you first check the previous settings where new defaults were brought in, before just accepting the new defaults. You can either use the existing 3.1x Production system or the UST12 and/or USOBT_C tables as reference.
It’s recommended that all activity groups containing an ‘*’ in authorization object s_tcode are recreated via PFCG by selecting only those transactions required for that role. Also, if you did previously add transactions to an activity group by manipulating the s_tcode authorization entries, it is recommended that the transactions are pertinently selected/added on the Menu tab. The object s_tcode should be returned to its ‘Standard’ status.
Report
Trees need to be converted to Area Menus using transaction RTTREE_MIGRATION..
Reports created by ABAP Query need to be added either to the activity group (Menu tab) or to an Area menu to ensure an authorization check on s_tcode level.
The use of an authorization object for Remote Function Calls (RFC) was introduced to provide authorization checks for BAPI calls, etc. Authorization object s_rfc provides access based on the Function Group (each RFC belongs to a Function Group). Due to the potential prevalent use of RFC’s within the R/3 system, SAP has provided the ability to change the checks for this object via parameter auth/rfc_authority_check. It is possible to deactivate the checking of this object completely. However it is recommended to rather set the values as required, which makes testing even more important!
Custom views and tables that are customarily maintained via SM30, SM31,etc. will need to be added to an authorization group. This can be done via transaction SE54 or SUCU or by maintaining table TDDAT via SM31.
A decision needs to be made once the first system has been upgrade to 4.6x as to whether the user menus or the SAP menu, or both are to be used.
Most users find the new user menus confusing and unfamiliar due to duplication of transactions, etc. (if a user has more than one activity group and the same transaction appears in several, the transaction will appear multiple times). The majority of upgrades from my experience have opted to use a modified copy of the SAP menu by adding their own area menus (converted report trees).
If you do
not maintain the user masters in the same client as the activity groups, you
will need to establish a strategy for re-linking the users in the QA and
Productive environments when transporting the activity groups as part of the
upgrade cutover. This might also be necessary depending on whether you decided
to rename the Activity groups per
Remember to thoroughly test and document all procedures and CATT scripts prior to the Production cutover.
With most current upgrades, the upgrade process will be tested on a separate environment set aside from the existing landscape. In a lot of cases a dual-landscape will be implemented where the existing landscape is complemented with an additional 4.6x test client(s). The new 4.6x clients usually become part of the permanent landscape once the Production system has been cut over and all changes are then sourced from these ‘new’ Development and/or QA systems.
It is imperative that all interim security-related changes are applied to both sets of systems to ensure that the ‘new’ 4.6x development source system is current with all changes that were made as part of Production support in the ‘old’ version landscape. If not, you will have changes that were taken to Production when it was still on the older release, but are now missing after the switch is made to the 4.6x systems.
It is thus advisable to keep changes during the upgrade project to a minimum.
Changes to activity groups are not automatically recorded in 4.6x. When an activity group needs to be transported, it needs to be explicitly assigned to a change request via PFCG.
SAP recommends that you first complete all the changes to an activity group, before you assign it to a transport request. Once you’ve assigned the activity group to a request, do not make any further changes to it.
You can also do a mass transport of activity groups via PFCG > Environment > Mass Transport.
If you want to transport the deletion of an activity group, you first have to assign the activity group to a transport request before performing the deletion via PFCG.
The profiles used for creating client copies have been changed, especially profile SAP_USER from 4.5 onwards. Activity groups are seen as customizing and the SAP_USER profile copies both user masters and activity groups.
It’s recommended that the client copy profiles are carefully reviewed before the copy is performed.
See
Changes to check indicators that were made via SU24 might have to be redone as part of the upgrade. Ensure that any resulting transport requests are noted and included in the detailed cutover plan.
Check indicator changes done via SU24 will need to be applied for any new and replacement transactions.
Composite activity groups can be built in release 4.6x using individual activity groups. A composite activity group does not contain any authorizations, but is merely a collection of individual activity groups.
Central User Administration (CUA) simplifies user administration,
allowing security administrators to maintain users in a single central client
only. The user masters are then
distributed to other clients using ALE.
It is recommended that CUA is implemented post-upgrade and once the
systems have been stabilized. Carefully
review
See Authorizations Made Easy guide for information on setting up CUA.
See
Review all security-related