Items requiring special attention

3.1. Authorizations

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.

3.2. ‘*’ in S_TCODE

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.

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 either to the activity group (Menu tab) or to an Area menu to ensure an authorization check on s_tcode level.

3.5. S_RFC

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!

3.6. Custom tables and views

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.

3.7. User menus versus SAP menu

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).

3.8. Re-linking of user master records to profiles

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 OSS note 156196.

Remember to thoroughly test and document all procedures and CATT scripts prior to the Production cutover.

3.9. Dual-maintenance

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.

3.10. Transport of activity groups

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.

3.11. Client copies

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 OSS note 24853 for additional information on client copies.

3.12. SU24

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.

3.13. Composite Activity Groups

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.

3.14. Central User Administration

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 OSS notes and the impact on the existing landscape, client copy procedures, etc. prior to implementing CUA. It is recommended that the upgrade is kept as simple as possible – there are going to be plenty of opportunities to test your problem-solving skills without complicating the setup with new utilities!

See Authorizations Made Easy guide for information on setting up CUA.

See OSS notes 333441 and 159885 for additional information.

No comments:

topics