EHP 7 - Recommended Security Approach?

[chrissap]

This is my first experience with an Enhancement Pack implementation, so please forgive me if my questions are very basic. Our company implemented EHP 5 and is now moving to EHP 7 for ECC and I was not involved with EHP 5, but was informed that we did not run SU25.

My first question is whether or not it is recommended to run SU25 for EHPs? I've searched SCN and Google and cannot seem to find the right guidance yet. I understand that after an 'upgrade', it is recommended, but can someone please shed some light on whether or not an EHP should prompt running SU25 in our systems?

If not is not necessary, what is the recommended Security approach to an EHP installation to ensure our roles and profiles are updated appropriately?

I've searched through the EHP 7 release notes and forums, but still cannot find the guidance to give me peace of mind. Hoping the Security gurus here can at least give me a push in the right direction.

Thanks for your help,
Chris

[Colleen]

Hi Chris

You want to run SU25 when there has been a change in the Basis Release Level. I covered off a technical summary in the following thread:

These are the key things i consider for EHP and upgrades:

• possible checks on custom code (most likely covered through testing)
• new authorisation objects
  • regeneration of SAP_ALL
  • update any non-production project roles, etc that may need the access
• possible new transaction codes (normally each functional area will need to review their areas with SAP Notes providing details. Step 2D(?) in SU25 does a replacement transaction mapping but that assumes SAP maintained the PRGN_CORR2 table. This is useful is a transaction has become obsolete.
• have a search to see if there is new security functionality (for example, security policies were created in a recent release)
• ensure that the security roles are adequately tested as part of project so users do not have authorisation issues in Production

If your system landscape is complex (e.g. two non-production streams for production support vs project) you will need to ensure a process to dual maintain security roles for the different version, etc. May not be an issue for you but it is another thing to consider.

Depending on how old your system is, sometimes enhancement packs and upgrades is an opportunity to overhaul security.

Regards

Colleen

[Former Member]

It depends on how broken the roles are and which design you had before.

If your roles are intact, then searching for Su25 here on SCN is normally all that is needed.

Doing an Su25 upgrade is very dependent on the state of the roles before hand.

If all goes well and was in sync before, your can upgrade your systems in 1 day and combine authorization tests with integration / functional tests without any problems.

If the roles are toasted from the start or you took the bait of implementing value roles, then you will need to start a project and man a helpdesk permanently....

Cheers,

Julius

[Colleen]

Agree - I've only executed SU24 once as I've been stuck rebuilding the roles due to poor build and ongoing maintenance

What do you mean by "value roles"?

[Former Member]

Yes, depending on the status of the roles before the upgrade, an upgrade is an opportunity to start over.

This can also be done very efficiently if you know what you are doing and leverage Su24 correctly.

My personal record is 4 days to upgrade and completely replace the authorization concept...

Cheers,

Julius

[Colleen]

oops! I meant SU25 once but hoping my meaning was implied

[chrissap]

Thanks for all your responses. I checked with our Basis team and we are not implementing any new Business Functions during this upgrade, so I'm not sure that running SU25 is a requirement at this point.

The business is not expecting any new functionality from this EHP.

With how we heavily utilize SU24 and since we have thousands of differences from our last EHP install still between SU22 and SU24, I dont think I want to intruduce the risk of running SU25 at this point.

We will still want to ensure:

1. SAP_ALL and SAP_NEW profiles are generated

2. SUPC validates all roles still in Green traffic light status

3. full regression test cycle with end users, which may very well bring up authorization errors that we can resolve via SU24

What are your thoughts on this plan? Please be candid

[Former Member]

With EHP7 you will have a few new objects and SAP did add more checks (and proposals) so I can still recommend running SU25.

Also with EHP7 you will have the possibility to run a repair report for inconsistent SU24 data and set date / time stamps for the last change -> this means that when you upgrade and you have maintained SU24 but SAP is not delivering anything new for it, then you no longer need to process it in step 2B.

At the very least you should run step 2a to make the popup go away and that will anyway introduce new proposals which you have not touched in SU24. That typically explains most of the work needed in 2c. So you might as well run 2b and get it behind you (mass accepting of your values is easy - just dont click on the "accept SAP file" button!

Cheers,

Julius

[Colleen]

HI Chris

As another consideration (may not apply to you) - if you have a SAP GRC component you need to run SU25 in the connected systems. There is integrated functionality for rule sets and role management that leverages SU24. Role build via GRC will fail is SU25 has not been executed.

I dont think I want to intruduce the risk of running SU25 at this point

next time you do EHPs or upgrade you will then be in the situation of, 'we haven't run it the past two times so I don't think I want to introduce the risk of running SU24 at this point'.

Step 2A will only update transactions that you have not yet modified. Your impact is if these transactions are used in any of your roles. You could look at all your transactions in menu (via AGR_TCODES) and compare against the USOBT* to see if you have any not modified before executing this step.

Step 2B will show you the differences for you to work your way through where you have made changes to SU24. If yours are highly customised you could ignore these ones. Although, at a minimum it might be worth identifying new auth objects and checking for them (compare TOBJ tables between Prod and Dev to locate them and then include those ones in SU24).

Regards

Colleen

[Former Member]

ps: see SAP note 1599128 for infos about the timestamp and only having to process "touched" deltas with each upgrade and not everything.

Cheers,

Julius

[chrissap]

Hi Julius,

I ran through step 2a, which was easy. Now I am on to step 2b, but the options seem to be different than what I was expecting after reading your comments.

I have 'Manual Comparison', 'Complete Transfer' and 'Set Status Checked'.

If I dont want to accept any changes from SU22, do I select all and then choose 'Set Status Checked'? You warn of the 'accept SAP file' button, but I dont see that anywhere.

Thanks for your time.

[Former Member]

I also used the new "Expert options" on 7.40 for the first time today.

Steer well clear of the "Complete transfer" button. That is "accept SAP file" in the old 2b. Choose "transfer manually" to continue in 2b as before.

Then if you know what you have done and impact on the roles, you can sail through 2c.

Cheers (and special thanks to Bernhard Hochreiter who also helped me with the new mode today).

Julius

[chrissap]

Hi Julius,

I'm curious about your experience with the Expert Options in 7.40. Can you go into more detail on how you used it in your scenario?

Thanks,

Chris

[Former Member]

You must read the notes related to SAP Note 440231 and execute the programs mentioned there as well as apply the correction notes (depending on which release you have already migrated to - step 2A is no longer executed as XPRA event in the upgrade transports -> that is why you get the popup in PFCG.

Your main focus should be to update the timestamps (or reorg them) as SAP previously only focused on the "modifier" user name and did no always anonymize it in SU22. You just need to get that behind you to accept it in Su24, and then you only need to process new proposals from SAP and deltas going forward.

Important! You must however avoid the "Accept SAP File" (in 2B) or "Automatically adjust SAP proposals" (in the expert mode). If you have maintained Su24 and are running Su25 for the first time then it will wipe a lot of your work away ad 2C will be very read.

Personally I have my own application to simulate the affect of the upgrade steps on the roles for projects (SAP has something similar as of 7.40 in the expert mode).

The big trick is to know what you are doing in 2B, and simulate the affect after 2A, then you can surf through 2C as you know what will happen (if the roles ok already before the upgrade  - you must check that before you upgrade otherwise you mix the two of them (out of date merges in older roles and upgrade proposals in 2C).

I developed my own tools for these simulations on my own projects.

Cheers,

Julius

[Former Member]

Hi Julius ,

We are doing upgrade from EHP6 to EHP 7 . While running 2b option we by mistake clicked on Complete transfer. Can you please let us know  what needs to be done to correct it and  what will the impact .

Thanks for your help .

[Former Member]

You are lucky...  with EHP6 there is already a SU24 comparison tool in the target (prod or qas) system. See report SU24*COMPARE* (F4).

Basically you must find the affected list of tcodes, download from the target system and upload into DEV again.

If you reset the timestamps, then you might even be able to run SU25 2B again to get the status right for the next upgrade (not yet tried though myself).

Thinking about it, perhaps step 1 and 2B SAP file button should be protected by an S_ADMI_FCD check (step 1 is already greyed out and moved to the menu, but 2B "accept SAP file" is effectively the same and equally tempting).

Cheers,

Julius

[Former Member]

Hi Julius ,

We are doing upgrade from EHP6 to EHP 7, similar to above case and while executing SU25 step 2b, we got the below screenshot and by mistake clicked on Complete transfer. So does it transfer SAP values only for below 6 transaction or all the SAP transactions?

Thanks

[Former Member]

That is the same as "Accept SAP file", but in the new expert mode.

IF you maintained something in SU24, and IF the timestamps are newer than something which SAP subsequently provided SU22 data for, then you loose your work.

You have either not repaired the timestamps or you have not done much in SU24 since EHP6 which is now also affected by EHP7.

Cheers,

Julius

[Former Member]

Thanks for the reply !!!

When I executed the SU25 2b I got only 6 transaction but I can see lots of transaction are customized by us earlier in SU24? Do you know what went wrong?

Also I have selected both the boxes "Selection Includes SAP standard Application" and "Selection includes Customer and Partner Application" in Step 2a.

[former_member202471]

Hi Chris,

I'd suggest you to review my post in the Security blog:

There you'll find some remarks and the relevant notes for this case...

Hope this helps.

Regards,

Felipe Fonseca

[pmuschick]

If you just want to compare the hard coded changes to the changes from SAP you could also compare the customizing tables via an RFC call and transaction OY19. Compare the relevant tables after the upgrade in the dev / sandbox system to the prod system in the old state.

a sample procedure would be:

OY19 - USOBT on EHP7    to    USOBT_C on "old" system

The relevant tables are: USOBT (SAP proposals) USOBX (SAP check values) USOBT_C and USOBX_C are the customer equivalents.

If you are using proposals for org.levels - see notes 727536 and 1624104.

The listed modifications are the changes done by SAP. Good security developers will set a filter on the changes objects and know the impact on their security concept.

- This is basically step 2b in SU25 but without starting the whole process. Above advises are to be considered too but sometime a simple comparison between the hard facts is more transparent than the SU25 tool by SAP.