SU25 UPG ENHP : how to find modified roles?

[Former Member]

Hi All,

our old contractors has executed during July month some steps of the trx SU25 after we have upgraded the EnhP on the Sandbox. Most probably

he executed the following steps:

a. step 2B. compare affected transactions

b. step 2C. Roles to be checked

c. Check indicator (Trx SU24)

We haven't any evidence of this activity and there aren't any transport generated. Now if we start the previous steps of the SU25 there aren't any output, all seems correct, but is it true?

Which is the best way to find all the roles that were modified? Infact we have found a lot of roles with open authorizations (yellow status). How can we proceed in order to do all the necessary adjustments?

Thanks

Bob

[Colleen]

Hi Bob

SU25 screen or table PRGN_STAT will show the last date the job was executed. Also, for the Step 2A entry for preparing table you will see if it's been run when the release number is same as current release.

Steps 2A automatically updates SU24 (USOBT_C and USOBX_C) where SAP via SU22 (USOBT and USOBX) has made a change but the customer has never maintained the transaction/application in SU24. I find the "prepares tables" is misleading as it is actually making changes to SU24 and not putting them in a transport for you to easily identify. If the contract ran this step you will see their User Id against changes in the USOBT_C/USOBX_C and USOBT_CD and USOBX_CD tables.  This step will not require a transport.

Step 2B will show the rest of the transactions/applications where SAP did make a change in their SU22 but the customer has also maintained. In this case, the customer has to review each transaction and decide if they want to adopt SAP proposals. SU24 is embedded within the SU25 screen - if you make a change and press save you will be prompted to add this to a transport. Again, refer to same tables in SU24 for identifying changes. You should be able to rerun this step and see any transactions left to maintain (not sure if relying on PRGN_STAT timestamp).

For Step 2C, this relies on execution dates in the PRGN_STAT table. If you have rerun Step 2A you may no longer see impacted roles. The roles appear in this list if a transaction in Step 2A or 2B exists in the role menu. If you re-ran Step 2A you can either modify PRGN_STAT table and back date the data or execute program SU2X_COMPARE_ROLES_WITH_DEFLTS and back date to when contract left.

For the yellow authorisation status - AGR_FLAGS gets a setting for FORCE_MIX to identify the roles needs to be adjusted. If the contract ran SU25 their Id will most likely appear against that Id and most likely give you the full list.

As far as the SU24 goes - that link calls transaction SU24 and not other action is taken. It's just to provide a cockpit to maintain. Don't worry if the contractor clicked that link.

Message was edited by: Colleen Lee incomplete sentence -  I find the "prepares tables" added:->is misleading as it is actually making changes to SU24 and not putting them in a transport for you to easily identify.

[Former Member]

Hello Colleen,

thank you very much for your helpfull explanation. When we launch the program SU2X_COMPARE_ROLES_WITH_DEFLTS we find 106 roles with red traffic light. Double clicking on them we go to PFCG where we find some authorization object in yellow status. If we compare this role with the role on the source system (ECC without upgrade) we can find that the values of the authorization objects are changed. How can we do to restore automatically for all these authorization objects the original values?

Thanks

Bob

[Colleen]

Hi Bob

I don't believe you can as the changes may be due to SU24 changes brought in by Step 2A and Step 2B

There is no magic button (that I'm aware off) for PFCG "undo". You can either look at change documents for the role to see what was done or if you want to mass fix your sandpits roles and not treat this as a testing/prototyping exercise then download the the roles from DEV and upload.

Regards

Colleen

[Former Member]

Hi Colleen,

in your opinion can we restore the situation by SU25 step3 from QA (not yet upgarded)? In your opinion could be sufficient to transport afterwards the usobx_c and uosbt_c table content from QA to our upgraded DEV system? Obviously after the transport we don't run SU25 step 2a and 2b.

Thank you very much for your collaboration.

Bob

[Colleen]

Hi Bob

I'm not really in a position to provide advise without knowing your system-landscape and what the strategy was for your upgrade as well as security role build.

I read your posts as a contractor did this in Sandpit system but your latest response mentions Dev and QA. I assumed that there was prototyping/testing of upgrade approach. If you are trying to perform a quick fix of Sandpit you can export Development System roles and re-import (or download roles from QA system). This will quickly restore sandpit roles. If you were using Sandpit to test your approach, then download/upload to replace will spoil that.

However, if it a situation where the contractor ran SU25 in a Sandpit client on a Development System then you do have some issues with Development as Steps 2A and 2B are client independent.

How you should be going about this (from a general point of view:)

1. Run SU25 Steps 2A-D and Step 3 in your master configuration client in your development system
2. Via Step 2C you will fix all roles that had SU24 updates from Steps 2A and 2B
3. Step 3 will allow you to transport the entire SU24 definitions - which include USOBX_C and USOBT_C as well as some other tables
4. If you for some reason have roles build directly in other clients in development box (e.g unit testing) you will need to log in to each client and fix them directly as Steps 2C and 2D are client dependent
5. All roles in your QA system should be transported from Development. Therefore, after the upgrade on QA your security transports should move the changes and you do not run SU25 in QA

Those steps are a very high level. I'm not sure what your background is but based on the questions you have, it seems your site would benefit from a SAP Security Consultant with upgrade expereince coming in and helping you to devise a strategy and document a process to use for Upgrades/Enhancements packs.

[Former Member]

Hi Colleen,

thank you very much for your appreciated collaboration. We are not using a sandpit client on DEV but a Sandbox system (which is a copy of DEV) on which we have upgraded the ENHPs. This Sandbox system will be the future DEV system when the ugrade will be completed. If we export Development System roles and re-import (or download roles from QA system) on Sandbox my question is : what will happen when we do the upgrade on QAS? It will be sufficient to not execute the SU25 on QAS in order to assure alignment with the Sandbox?

Warm Regards

Bob

[Colleen]

Hi Bob

You will only execute SU25 in Development. So straight up - make the decision now if Sandpit is now your Development system. That is will the new-Sandpit-to-later-become-Development be the system where transports are released for your upgrade?

Whichever system has the transports released, you need to complete the SU25 steps 2A-2D and transport SU24 date for Step 3. In addition, you then need to create a mass transport via PFCG for every role you maintained in Step 2C or Step 2D.

As far as QA system goes, once Basis have completed upgrade steps, security is then fixed by importing the two transports you created (the SU25 Step 3 and mass PFCG). This will import your development changes for the upgrade. So yes - you will not execute SU25 in QAS.

You may need to check any SAP* roles that were patched in the upgrade if you are using any of them and possibly generate the profile via SUPC

Hope that clarified the QAS part but I think you need to think through what you are doing with fixing/completing what the previous contractor did and deciding if Sandpit is now Dev or not.

Regards

Colleen

[Former Member]

Hello Colleen,

yes Sandipit is now DEV and on Sandpit we are doing all the necessary adjustments (abap code, tables, user exits, roles and so on) that are inserted in the CRs. These CRs will be later transported on QAS when it will be upgraded.

Let me know if your previous approach has to be modified.

Thanks a lot

Bob

[Colleen]

Hi Bob

If Sandpit System had SU25 completed for Steps 2A to 2D then you will need to check each role is completed and profile generated as well as run Step 3 to transport all of SU24

If you are stuck with what your previous contractor did and chose to download dev roles and mass upload to sandpit: you will need to run Step 2C via the report to find all the roles that need to be manually adjusted. These are the roles where Step 2A or 2B changed the SU24 for transactions in the role menu.

I can't really offer any more advise without knowing what your system looks like.

Good luck and hope you have your approach now.

[Former Member]

Hello Colleen,

First of all thank you very much for sharing the SAP Security Upgrade Strategy. Its really helpful.

I am currently performing SAP Seucirty Upgrade activity from ECC EHP3 to EHP6 (in Sandbox as of now) and have some doubts with this tool.

1> Executed SU25 -> Step 2A: My understanding is that generally 2A does not throw amy output on the screen. It executes and displays a message at the bottom of the screen, that 2A is completed.

However this time, 2A generated a huge list and displayed a result on the screen. The output is as attached. It says:

Applications to be compared: abc

Applications with changed default values: pqr

Apllciations to be compared manually: xyz

Issue: Does it say that SAP has changed the SAP proposed values for SAP std tcodes in new release on its own?

2> Executed Step 2B ->

     Issue: I did not receive any SAP Standard tcode in the output of SU25 Step 2B. Ideally I should receive all those SAP transactions which have been changed from SAP defaults (of old release) in new release. Let me know whether my assumption is correct.

     How I came to this conlcusion: I found that few of the SAP standard tcodes were changed from SAP default proposals in the earlier release.
                                                                                        
     For your information:
       When entered in SU25 screen for the first time in the Sandbox system (upgraded from ECC6 EHP3 to EHP6), I had a message on screen requesting me to confirm whether SAP NOTE 440231 was checked from my side. I had a look at this note & informed my Basis team to implement the child notes available and applicable to this sandbox, which they implemented beforehand.

Please can you have a look at the above and advise me what can be the best solution in such case? Also appreciate if you can let me know the pre-requisites which we need to follow before we start the upgrade activity?

Thanks,

Sunny Doshi

[Colleen]

Hi Sunny

You are correct - Step 2A does actually show a result screen. I can't remember why I said it didn't but I checked my notes and I too had that screen (for 731 release)

Applications with changed default values: pqr

those should be the SAP standard values that the customer has never changed and SAP did modify

I did not receive any SAP Standard tcode in the output of SU25 Step 2B. Ideally I should receive all those SAP transactions which have been changed from SAP defaults (of old release) in new release. Let me know whether my assumption is correct.

Although they had been changed, had SAP made any recent changes to them (i.e customer maintained them, then SAP modified SU22?)

Regards

Colleen

[Former Member]

aHi Colleen,

What I understand from your feedback:

1. For those SAP std tcodes (available in old & new release) which were kept similar to SAP defaults and SAP has now changed their defaults in new release, are auto changed in Step 2A by SAP.

2. I checked all those SAP std tcodes, for some tcodes I found that SAP changed their defaults compared to previous release alongwith custom change made to those tcodes; however there are still 3 std tcodes which were changed in previous release with no SAP defaults change in new release; and they did not show up in Step 2B.

3. As per my analysis, SAP took the new SAP defaults + custom change in Step 2B as I manually changed the SU24 for such tcodes, wherever required.

4. Also, step 2C listed the roles; which were added / removed with auth obj (as per 2A & 2B), I noticed the same while merging the roles.

Also let me know whether my below assumption is correct:

a. I shall execute Su25 -> Step 3 (after i finish 2a to 2d); this step will carry complete (and not the only changes made in 2A, 2B) table data USOBX_C + USOBT_C and move to further tiers. This will help to remove the message from QA/PRD 'If you have already used the Profile Generator in a previous Release,you should use transaction SU25 (steps 2A to 2C) to transfer the new.....'

b. Step 2B threw list of Z tcodes (in Red status), I changed them to green (checked) and while saving it ask me the TR no. So is there a need to move this TR as well or Step 3 is good enough?

My solution: first do with Step 3, if correct changes are available in next tier then do not move 2B TR.

c. Appreciate if you can share the test phase strategy for this upgrade i.e. regression test with functional team / business performing test for all business scenarios / test cases.

Thanks,

Sunny Doshi

[Colleen]

Hi Sunny

there are still 3 std tcodes which were changed in previous release with no SAP defaults change in new release; and they did not show up in Step 2B. 

They will only appear in Step 2B if both you and SAP made changes to the transaction since the last time you ran SU25

. I shall execute Su25 -> Step 3 (after i finish 2a to 2d); this step will carry complete (and not the only changes made in 2A, 2B) table data USOBX_C + USOBT_C and move to further tiers.

Step 3 is to bundle a transport of SU24. It will transport entire tables. You can complete this after Step 2B if you wish to as 2A and 2B update SU24. However, you may prefer to finish all of Step 2 incase you manually go to SU24 to make additional changes as you are fixing your roles (i.e. you may find an issue with your own build and choose to rectify it)

Step 3 transports: USOBT_C; USOBX_C; PRGN_STAT; USOBT_TSTMP; and USOBX_TSTMP. The *TSTMP tables in latest release replace the TCODE_MOD and USOB_MOD tables and are used to determine what was updated.

This will help to remove the message from QA/PRD 'If you have already used the Profile Generator in a previous Release,you should use transaction SU25 (steps 2A to 2C) to transfer the new.....'

Yes - as that setting is driven by a value in table PRGN_CUST for STAT_GRP=001 and (STEP_NR= 001 or 002) to see if either entry has the value in field RELEASE as the same value as current system release. If the RELEASE value is less the message will appear. By transporting the table in Step 3 it clears this issues across all your systems.

So is there a need to move this TR as well or Step 3 is good enough?
My solution: first do with Step 3, if correct changes are available in next tier then do not move 2B TR.

Am not quite sure why custom transaction codes appeared in SU25 - someone else might be able to offer an opinion here. However, running Step 3 just helps you create a transport. It will not change the flag settings in the tables that determine output in any of Step 2. You can come in and run Step 3 whenever you want to retransport all of SU24 across your landscape (tiers)

c. Appreciate if you can share the test phase strategy for this upgrade i.e. regression test with functional team / business performing test for all business scenarios / test cases.

This one is something you will need to discuss with your project on what they believe adequate testing is. You need to look at what roles are impacted and what the change to the access was. At the end of the day how does your site test security?

Regards

Colleen

[Former Member]

Thank you Colleen.

I guess that such issues might have popped up as sandbox (new release) is a copy of test system (old release).

I will trouble you while performing this activity in actual Dev system

Regards,

Sunny Doshi

[Former Member]

Hi Sunny/Colleen,

Although its quite late to reply on this old thread, but since I am facing the same issue I would like to know more about how you resolved it.

I am working on an upgrade project from ECC6 EHP4 yo ECC6 EHP 6. I have executed SU25 2A and 2 B till date. But to my surprise I see all the Z tcodes listed in SU25 2B. Isn't this strange? This is the same issue which you have mentioned in this thread.

Also I get a similar detailed report in 2A step, while in my past project we never received any outputs in 2A. Also this report shows few tcodes where the customization was done in the previous release i.e EHP4 but in EHP 6 there was no update done. Ideally I should see these kid of tcodes in SU25 2B where I should see my customization done in the previous version and I have an option to keep it or overwrite it with the SAP default. Is my understanding correct?

I hope that the logic of 2A and 2B steps are not changed in EHP6. Let me know your experience on this.

[Former Member]

Hello Akshay,

Please find below the details:

1> SU25 -> Step 2A: This protocol in step 2A is a new feature in EHP6 and was requested by many customers (to have a printable result....). It is just for documentation of / if changes performed.

2> SU25 -> Step 2B: Your understanding of 2B is correct.

Please refer SAP note: 1539556 - Administration of authorization default values - Symptom [A] as according to some of our Security experts its an issue with the modification flags. Just have a look at this symptom and see if you can get something out of it.

Frankly speaking, I was not able to correlate this symptom with our Step 2B output.

My Solution: Raise OSS with SAP, provide them with the system access and let them confirm the issue. I have already raised OSS but waiting for their response. If you happen to get their response, please share.

We can ofcourse repair such indescrepancies manually, however better to confirm from SAP as to why SU25 is behaving weird for 2B output.

3> Are you performing this security upgrade on Sandbox initially? If yes, is it a copy of your test/live system?

Thanks,

Sunny Doshi

[Former Member]

Hi Sunny,

Yes, current system is a copy of production and its available for few days only. We have to do our analysis and then we will start with the upgrade in dev.

I guess this is the same case for you. Did you encounter the same issue in the upgraded dev environment too??

[Former Member]

Also did you run : SU24_AUTO_REPAIR before upgrade as suggested by other experts in different threads.

[Former Member]

Hello,

1. I have not began with SU25 activities for the DEV tier as of now.

2. Just to repeat, raise OSS message with SAP and let them confirm what's wrong, if any.

3. Just confirm SU24 changes made to the standard SAP tcodes in old release are in sync across your landscape (i.e. DEV, QA,PRD).

Thanks,

Sunny Doshi

[Colleen]

Yes, current system is a copy of production and its available for few days only. We have to do our analysis and then we will start with the upgrade in dev.

with the changes in SU25 date/time stamps are used to identified if a transaction was updated. i can't remember all the tables of top of head but SU25 is typically ran in Development and resulting PFCG and SU24 changes are transported to production

If you are using a copy of production to test you aren't really testing your approach and your data may vary. Maybe one of the security experts can join in here.

I would have thought you'd take a copy of you DEV environment as a sandpit as this is development work you are testing?

Regards

Colleen

[vandana_maini]

Hi Colleen,

Thanks a lot for such an awesome explanation for the technical upgrade.

I have another question related to the Security Upgrade.

My customer had a list of roles which are known as emergency roles and they suggested to replace the new open authorizations as * and for other roles, they suggested to deactivate the new open authorizations. But due to some miscommunication, I had started fixing the roles in vice-versa way. Although not all roles are fixed but 135 are already fixed in this manner..

Please suggest whether the original state of the roles can be reverted back in this case.

What I have learnt from this blog is that we cannot revert back the changes we have done. But I want to know that if I download the roles from the Production(Non-upgraded) system to the DEV box and re-run step 2C, whether the original state can be acheived for the roles I have already modified.

This a very urgent issue. Quick responses will be greatly appreciated.

Thanks in advance,

Vandana

[Former Member]

Hi

the issue with su25 2b output, is it resolved, if yes can you please help me with the solution

Thanks

Surya

[Colleen]

Assuming prod version was most current (no outstanding transport to migrate) and you have approval you should be able to technically do this

if the role doesn't appear in step 2c use pfcg expert mode. - merge option. Step 2c is about maintaining those su24 changes in the role

regards

Colleen