SAP Security Upgrade White Paper

Pagina 1

SAP R/3 Security Upgrades

By : Yvette Smith

TABLE OF CONTENTS

1. 2.

OVERVIEW SECURITY UPGRADE OBJECTIVES, PROCESS AND APPROACHES

4 5

2.1. OBJECTIVES 5 5 2.2. OVERVIEW OF THE SECURITY UPGRADE PROCESS 2.3. APPROACHES TO CONVERT MANUAL PROFILES TO ACTIVITY GROUPS: 6 2.3.1. APPROACH #1: SAPS STANDARD UTILITY SU25 6 2.3.2. APPROACH #2: MANUAL RECONSTRUCTION OF PROFILES AS ROLES (ACTIVITY GROUPS) 7 3. ITEMS REQUIRING SPECIAL ATTENTION 8

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 2

3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. 4.

AUTHORIZATIONS * IN S_TCODE REPORT TREES ABAP QUERY REPORTS S_RFC CUSTOM TABLES AND VIEWS USER MENUS VERSUS SAP MENU RE-LINKING OF USER MASTER RECORDS TO PROFILES DUAL-MAINTENANCE TRANSPORT OF ACTIVITY GROUPS CLIENT COPIES SU24 COMPOSITE ACTIVITY GROUPS CENTRAL USER ADMINISTRATION

9 9 10 10 10 10 10 12 12 12 12 12 12 13 13 14 14 14 14 15 15 16 16 16 17

8 8 8 8 8 9 9

ADDITIONAL TIPS OSS AND RELEASE NOTES WORKPLAN STANDARDS AND PROCEDURES TESTING RESOURCES FOR TESTING TEST PLAN ISSUE MANAGEMENT (TRACKING AND RESOLUTION) STATUS REPORTING DETAILED CUTOVER PLAN PROJECT TEAM ACCESS TRAINING AND NEW FUNCTIONALITY SU53 POST GO-LIVE

4.1. 4.2. 4.3. 4.4. 4.4.1. 4.4.2. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11. 5. 5.1. 5.2. 5.3.

HELPFUL REPORTS, TRANSACTIONS AND TABLES REPORTS AND PROGRAMS TRANSACTIONS TABLES

1.

OVERVIEW

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 3

The purpose of this document is to provide additionalinformationthat could be helpful with SAP Security upgrades, especially pertaining to 4.6C. Thisdocumentis not aimed at replacingthe SAP AuthorizationsMade Easy guidebooks procedures, but rather to complementthese 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 SAPs SU25 utility; Transactions and authorizations that require special attention; and Helpful reports, transactions, hints and tables to know. It is highlyrecommendedthat you review the chapter on upgrades in the Authorizations Made Easy guide before attempting the security upgrade. See OSS note 39267 for information obtainingthe Guide,or visitSAPLabs websiteat: on http://wwwtech.saplabs.com/guidebooks/

SECURITY 2. APPROACHES 2.1. Objectives

UPGRADE

OBJECTIVES,

PROCESS

AND

There are a couple of objectives for having to upgrade the SAP Security infrastructure: Convertingmanualprofilescreated via SU02 to activitygroups, as SAP recommends the use of Profile Generator (PFCG) for the maintenance of profiles; Adding new transactions representing additional functionalityto the applicable activity groups; Addingthe replacementtransactionsthat aim at substituting obsolete or old-version transactions, including the new Enjoy transactions; Adjustingthe new authorizationobjects that SAP added for the new release; and

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 4

Ensuringthat all existingreports, transactions and authorizationsstill function as expected in the new release of SAP. 2.2. Overview of the Security upgrade process

Once the Developmentsystemhas been upgraded to 4.6, the securityteam willneed to perform the following steps as part of the Security Upgrade: Convert Report Trees to Area Menus; Reviewusers (via SU01) to check for any new or changed fieldson the user masters; Convert manual profiles created via SU02 to ActivityGroups (See Approaches below); Compare SU24 customersettings to new SAP defaultsettings( SU25 steps 2A-2C); Determinewhich new / replacementtransactionshave to be added to which activity groups (SU25 step 2D); Transport the newly-filledtables USOBT_C and USOBX_C that contain the SU24 settings youve made (SU25 step 3); and Remove user assignments to the manual profiles. 2.3. Approaches to convert manual profiles to Activity Groups: 2.3.1. Approach #1: SAPs standard utility SU25 SAP provides an utilityfor convertingManual Profiles to ActivityGroups and to identifythe new and replacementtransactionsthat 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 convertthe Manualprofilesto activitygroups, you will need to watch out for the following gotchas: name) All activity groups created T_500yyyyy_previous name. Naming convention (T_500yyyyy_previous before SU25 is run, are renamed to

See OSSnote 156196 for additional informationand procedures to rename the activity groups back to their original names using program ZPRGN_COPY_T_RY_ARGS. Carefullyreviewinformation regardingthe loss of links between profiles and user master records.

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 5

Transaction Ranges Ranges of transactionsare not always added correctly to the newly-created activity groups. Some of the transactionsin the middleof the range are occasionallyleft off. E.g. you have a transactionrange of VA01 VA04 for a specificmanualprofile. After SU25 conversion, the new ActivityGroup 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 missingtransactioncodes willneed to be added manually the relevantactivity to group via PFCG. Missed new transactions The output of one of the steps in SU25 is a listof the new replacementtransactions (e.g. Enjoy transactions)that need to be added per activitygroup. E.g. transaction ME21N replaces ME21. The list willidentifyeach activitygroup that has ME21 where ME21N needs to be added to. In some cases SU25 does not identify all new transactions to be added. 2.3.2. Approach #2: Manual reconstruction of Profiles as Roles (Activity Groups) An alternativeapproach to SU25 is to manuallycreate an activitygroup for each manual profile that was created via SU02. The advantageof this approach is that you wont have any missingtransactionsthat were dropped off with the SU25 conversion.

3. ITEMS REQUIRING SPECIAL ATTENTION 3.1. Authorizations Severalnew authorization objects have been added withrelease 4.6. Care shouldbe taken when adjustingauthorizations carefullyreview all new defaultsthat were brought in. These are indicated by a Yellow or Red traffic light in PFCG. It is highlyrecommended that you first check the previous settings where new defaultswere broughtin,before just acceptingthe new defaults. You can eitheruse the existing3.1x Production system or the UST12 and/or USOBT_C tables as reference. 3.2. * in S_TCODE

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 6

Its recommendedthat all activitygroups containingan * in authorizationobject s_tcode are recreated via PFCG by selectingonly those transactionsrequired for that role. Also, if you did previouslyadd transactions to an activity group by manipulatingthe 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. 3.3. Report Trees Report Trees need to be converted to Area Menus using transaction RTTREE_MIGRATION.. 3.4. ABAP Query reports Reports created by ABAP Query need to be added eitherto the activitygroup (Menu tab) or to an Area menu to ensure an authorization check on s_tcodelevel. 3.5. S_RFC The use of an authorization object for RemoteFunctionCalls(RFC) was introduced to provide authorizationchecks for BAPI calls, etc. Authorizationobject s_rfc provides access based on the Function Group (each RFC belongs to a Function Group). Due to the potentialprevalentuse of RFCs withinthe 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 recommendedto rather set the valuesas required, which makes testing even more important! 3.6. Custom tables and views Customviewsand tables that are customarilymaintainedvia SM30, SM31 ,etc. will need to be added to an authorization group. Thiscan be done via transactionSE54 or SUCU or by maintaining table TDDAT via SM31. 3.7. User menus versus SAP menu A decisionneeds to be made once the firstsystem has been upgrade to whether the user menus or the SAP menu, or both are to be used. 4.6x as to

Most users findthe new user menusconfusingand unfamiliar ue to duplicationof d transactions, etc. (if a user has more than one activity group and the same transaction appears in several, the transaction will appear multipletimes). The majorityof upgrades from myexperiencehave opted to use a modifiedcopy of the SAP menu by adding their own area menus (converted report trees). 3.8. Re-linking of user master records to profiles

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 7

If you do not maintainthe user masters inthe same clientas the activitygroups, you willneed to establisha strategy for re-linkingthe users in the QA and Productive environmentswhen transportingthe activitygroups as part of the upgrade cutover. This might also be necessary depending on whether you decided to rename the Activity groups per OSS note 156196. Rememberto thoroughlytest and documentallprocedures and CATT scriptsprior to the Production cutover. 3.9. Dual-maintenance With most current upgrades, the upgrade process will be tested on a separate environment et aside fromthe existinglandscape.In a lot of cases a dual-landscape s 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 permanentlandscape once the Productionsystem has been cut over and all changes are then sourced from these new Development and/or QA systems. It is imperativethat all interimsecurity-relatedchanges are applied to both sets of systems to ensure that the new 4.6x developmentsource system is current with all changesthat were made as part of Productionsupport in the old versionlandscape. If not, you willhave changes that were taken to Productionwhen it was stillon 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. 3.10. Transport of activity groups Changes to activitygroups are not automaticallyrecorded in 4.6x. When an activity group needs to be transported, it needs to be explicitlyassignedto a change request via PFCG. SAP recommendsthat you firstcompleteallthe changes to an activitygroup, before you assign it to a transport request. Once youve assigned the activitygroup to a request, do not make any further changes to it. You can also do a mass transportof activitygroups viaPFCG > Environment Mass > Transport. If you want to transport the deletionof an activitygroup, you firsthave to assignthe activity group to a transport request before performing the deletion via PFCG. 3.11. Client copies The profilesused for creatingclientcopies have been changed, especiallyprofile SAP_USER from 4.5 onwards. Activitygroups are seen as customizingand the SAP_USER profile copies both user masters and activity groups.

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 8

Its recommended that the client copy profiles are carefullyreviewed before the copy is performed. See OSSnote 24853 for additional information on client copies. 3.12. SU24 Changes to check indicatorsthat were made via SU24 mighthave to be redone as part of the upgrade. Ensure that any resultingtransport requests are noted and included in the detailed cutover plan. Check indicatorchanges done via SU24 willneed to be applied for any new and replacement transactions. 3.13. Composite Activity Groups Composite activitygroups can be built in release 4.6x using individualactivity groups. A composite activitygroup does not contain any authorizations,but is merely a collection of individual activity groups. 3.14. Central User Administration Central User Administration(CUA) simplifies user administration,allowing securityadministratorsto maintainusers in a singlecentral client only. The user masters are then distributedto other clients using ALE. It is recommended that CUA is implementedpost-upgrade and once the systems have been stabilized. Carefullyreview OSS notes and the impact on the existinglandscape, client copy procedures, etc. prior to implementing UA. C It is recommendedthat the upgrade is kept as simpleas possible there are goingto be plentyof opportunitiesto test your problem-solving skills without complicating the setup with new utilities! See Authorizations Made Easy guide for information on setting up CUA. See OSSnotes 333441 and 159885 for additional information.

4. ADDITIONAL TIPS 4.1. OSS and Release Notes

Review all security-related OSS and Release notes related to upgrades and to the release youll be upgradingto, prior to the upgrade. Its useful to review these before you define your workplan, in case you have to cater for any unforeseen issues or changes. 4.2. Workplan

Giventhe amountof work and numberof steps involvedin the securityupgrade, it is recommendedthat a detailed Workplan is defined at the startup of the upgrade

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 9

project. Key milestones from the security workplan should be integrated and tracked as part of the overall Upgrade Plan. Clear ownership of activities,includingconversionof Report Trees, needs to be established. This function is often perform by the Development team. 4.3. Standards and Procedures

Naming conventions and standard procedures should be established before the manual profiles are reconstructed as activitygroups. Each team member should know how the new activitygroups should be named to ensure consistency.Other standard practices for the construction of the activity groups should include: Transactionsare added via the Menu tab and not by manipulating s_tcode. Ideally, no end users should have access to SE38, SA38, SE16 nor SE17. Remember to keep Internal Audit involved where decisions need to be made regardingthe segregationof job functionsor changes to current authorizations are requested or brought in with new authorization objects / defaults. 4.4. Testing 4.4.1. Resources for testing Enough resources should be allocated to the security upgrade process as each activitygroup and profile will require work to some degree or the other. It is importantthat key users and functional esources are involvedintestingthe activity r groups and that this effort is catered for in the Upgrade Project plan. Clear ownership of each activity group should be established not only for testing purposes, but also for ongoing support and approval of changes. Ideally, the ownershipand approval of changes shouldreside withdifferentresources (i.e. the person requestingthe additionof a transactionor authorizationshould not be the same person responsible for approving the request). 4.4.2. Test Plan The securityteam shouldalso establishtestingobjectives(whethereach transaction beingused in Production should be tested, whether each activitygroup should be tested with a representative ID, etc.). A detailed test plan should then be establishedbased on the approach, to ensure each person responsible for testing knows what s/he should be testing,what the objective(s)of the test is and how to report the status of each test. Both positive (user can do his/her job functions) and negative (user cant perform any unauthorized functions) testing should be performed.

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 10

The Reverse BusinessEngineering(RBE) tool is very usefulin identifying which transactionsare actuallybeingusingin Production. Thiscan assistwithfocusingon which transactions to test. The importance of testing all used transactions individually and as part of roletesting cannot be stressed enough. TEST,TEST,TEST! Everymenuoption,button, icon and availablefunctionsfor all criticaltransactions need to be checked and tested. There are some instanceswhere iconsare grayed out or dont even appear for certainusers, due to limitedauthorizations. The onlyway these type of issues can be identified, is through thorough testing. 4.5. Issue Management (tracking and resolution)

Due to the number of users potentiallyimpacted by issues / changes to a single activitygroup, a perception can quicklybe created that the securityupgrade was unsuccessful or the cause of many post GoLive issues. It is therefore recommendedthat an issues log is establishedto track and ensure resolution of issues. The log should ideally also contain a description of the resolution, to aid with similar problems on other activity groups. Thislog willbe helpfulduringthe entire upgrade process, especiallywhere more than one resource is working the same set of activitygroups, so set it up at the beginning upgrade project! You can also use thisfor a lessonslearntdocument of for the next upgrade. 4.6. Status reporting

The security upgrade forms an integral part of the overall upgrade given the sensitivityand frustration security issues could cause. It is important that key milestonesfor the securityupgrade are tracked and reported on to ensure a smooth and on-time cutover. 4.7. Detailed cutover plan

The detailed cutover plan differs from the overall security workplan, in that the detailed plan outlinesthe exact steps to be taken during each systems upgrade itself. This should include: Transport request numbers, Download of security tables prior to the upgrade, especially UST12, USOBT_C and USOBX_C, A backup and restore plan, (e.g. temporary group of activity groups for critical functions),

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 11

The relinking of user master records, with details on any CATT scripts, etc. that might be used, User comparison, etc. The securityteam needs to ensurethat enoughtimeis allocatedfor each actionitem and that this time is built into the overall cutover plan. The project manager is usuallyexpected to givean indicationto end users and key stakeholdersas to when the Productivesystem willbe unavailableduring its cutover to the new release. This downtime should thus incorporate time required to perform user master comparisons, unlocking of IDs and all other action items. 4.8. Project team access

The SAP_NEW profile can temporarilybe assigned to project team members to provide interimaccess to the new authorization objects. This provides the security team the opportunityto convert and adjust the IS teams activitygroups. It also eliminatesfrustrationon the functionalteams side when configuring and testing new transactions, etc. 4.9. Training and new functionality

Some support team members(e.g. Help Desk membersresponsiblefor reset of user passwords, etc.) might require training and/or documentation on the changed screens of SU01, etc. It is recommendedthat a basic Navigation& Settingstrainingmoduleis created for all SAP users and should cover the use of Favorites, etc. The securityteam should also review ProfileGenerator in detail, as several new functions have been added (e.g. download/upload of activity groups, etc.). Remember to review all the different icons, menu options and settings on the authorizations tab, etc. Lastly,if your company/ project does use HR as related to security(activitygroups and users assignedto positions/ jobs), ensure that you become acquaintedwiththe new enjoy transactions, e.g. PPOMW. 4.10. SU53

A new functionwith SU53 is the abilityto display another users SU53 results. (Click on the other user button and enter the persons SAP ID). 4.11. Post Go-live

Remember to establish a support roster, includingafter hours for critical batch processes, to ensure security-related issues are resolved in a timely fashion.

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 12

Dumps should be checked regularly (Objects s_rfcand s_c_funct like making appearances in dumps) for any authorizations-related issues. TransactionST22 can be used to review dumps for that day and the previous day. Avoid transporting activity groups at peak times, as the generation of activity groups can cause momentarilyloss of authorizations. Its recommended that a roster for activitygroup transport and mass user comparisonbe reviewedwiththe project manager prior to the upgrade. Exceptions should be handled on an individual asis and the potentialimpact identified,based on number and type of b users, batch jobs in progress, etc. And, dont forgetto keep on trackingallissuesand documenting resolutionsfor the future reference.

5. HELPFUL REPORTS, TRANSACTIONS AND TABLES 5.1. Reports and Programs Menus RTTREE_MIGRATION:Conversionof Report Trees to Area PFCG_TIME_DEPENDENCY: user master comparison

(background)

RSUSR* reports (use SE38 and do a possible-valueslist for RSUSR* to see all available security reports), including: criteria v RSUSR002 displayusers accordingto complexsearch

v RSUSR010 Transactions that can be executed by users, with Profile or Authorization criteria v RSUSR070 Activity groups by complex search

v RSUSR100 Changes made to user masters v RSUSR101 Changes made to Profiles v RSUSR102 Changes made to Authorizations v RSUSR200 Users according to logon date and password change, locked users. 5.2. Transactions SUIM : various handy reports SU10 : Mass user changes

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003

SAP Security Upgrade White Paper

Pagina 13

PFCG: Profile Generator PFUD: User master comparison SU01: User master maintenance ST01: System trace ST22: ABAP dumps SUCU / SE54: Maintain authorization groups for tables / views plan relationships relationships PPOMW: Enjoy transactionto maintainthe HR organizational PO10: Expert maintenanceof Organizational nitsand related U PO13: Expert maintenance of Positions and related tcodes are beingused

STAT:System statistics,including which by which users 5.3. Tables

Table UST12 UST04 AGR_USERS USOBT_C USR02 AGR_TCODES USH02 USH04 USR40 USR41 Use Authorizations and Tcodes per Profile

Assignment of users to Profiles Assignment of roles to users Authorizations associated with a transaction Last logon date, locked IDs Assignment of roles to Tcodes (4.6 tcodes) Change history for users (e.g. who last changed users via SU01) Display history of who made changes to which User Ids Non-permitted passwords Users with logon information (multiple logons)

GOOD LUCK!

http://www.sapgenie.com/basis/Security%20upgrade%20white%20paper.htm

16:09:44 30-1-2003