Authorization objects have been overwritten after Upgrade

[Former Member]

Hi all,

We have just upgraded our 4.7 system to ECC6 and executed the SU25 TA & steps.

However, we have noticed that some of the values of our aurthorization objects have been updated i.e. overwritten.

For example, ACT has been changed from 01,02,03 by 02....

In some cases, but I need to check deeper, sounds to be the same for the Organization....

1) Do you know why it happened?

2) Do you know why doing the SU25 was not enough?

3) Is there a way to detect all of those authorization objects or roles that have been impacted so that we can do a manual adjustment without going to 3000 single roles.

Thank you for your help & advice.

regard

chris

[Former Member]

Hi Cris,

This has happned when you have upgraded from 4.7 to ECC 6.0.Many new authorization objects were included for better security.

We have to use SU25 for post upgrade activiity for profiles.

No other way we need to manaually do it.This is the hectec job,

Even we have done the same last week.

Thanks & Regards

Gangadhar

[sdipanjan]

I hope you have taken a back up all the old roles as Bulk download and a copy of ARG_1251/2 tables. There are few objects get obsolete, few changed (proposal of field values) in accordance with the New Objects arrived. So you need to check the new objects appeared in those roles where you have noticed these changes. Manually check these roles in PFCG and also compare the values in table TACTZ by checking the new profile content of SAP_NEW.

Regards,

Dipanjan

[Former Member]

> In some cases, but I need to check deeper, sounds to be the same for the Organization....

Please take a look at the SAP Notes in this thread before running the upgrade:

It is added as a sticky-thread now as well.

Cheers,

Julius

[Former Member]

Thank you for your answers & feedback

chris

[Former Member]

I am having a similar problem, but I have yet to find a solution here in the Security Forum.

My client is running an upgrade from 4.7 to ECC 6.0.  I found that maintained authorizations in 4.7 are removed from the roles in 6.0 when the generator suggests new standard authorizations with different authority.  The maintained authorization is not retained (even a display authorization -- and the suggested standard authorization contains display activity and others).  It is the same whether I go into change the role in the basic mode or in the Expert mode to "Read old status and merge with new data" -- the new data isn't merging with the old status.... it is removing the old authorization.

SAP Note 679050 describes my problem perfectly, but my system is on SAP_Basis Release 702.  The Note's solution only covers systems up to 640

I don't like the idea of changing the updated role to manually add every authorization that was removed.  Also, I don't like the idea of using Expert mode "Edit old status" because I am concerned that any future change will just throw all the incomplete suggested authorizations into a role again.

I have been hunting around the site for a solution -- if you know of anything, please let me know.

Thanks,

Ed

[Former Member]

Did you click on the "Accept SAP file" button?

That is anyway a bad idea, but there was also a recent bug which did not only sync the "modified" proposal data back to the new "original" data, but replaced all the customer data with the SAP data if you use that button. CHeck OSS for the note and apply it via SNOTE, or simply avoid that button completely! (I always do).

Do not process step 3!

Go to QAS or PROD and restore the data back into DEV (assuming that you transported it always..). You will probably have to use the "insert and modify" option to upload otherwise you might loose data from the upgrade (not everything is "bad" in the "SAP file"... but it makes sense to take a look at it and not just accept it because some spheres of influence persuade SAP to add excessive proposals to SU22).

Also take note that the SU01 User Group field will be upgraded to an org. level now! Also not sure why SAP did that 😞

Cheers,

Julius

[Former Member]

Hi Julius,

I'm very glad you replied.  I was hoping my inquiry would get your attention.

I'm not sure what you are describing, partly because I was not present when the upgrade was run on the Development system.  I am making a guess that you believe my client either ran a step in the Upgrade they should not have, or else they did not run something they needed to do, and that is causing these problems. 

I am going through the parts of SU25 to try to understand what needs to be done.

Step 1 to fill the customer tables -- the timestamp says was done 9 years ago by DDIC.  I believe that should be done only for the initial upgrade.  Correct me if I am wrong.

>>>>>Did you click on the "Accept SAP file" button?

<<I'm not sure where I would find that.  What transaction/function is that in?  Perhaps it was already executed by the prior Security person.

>>>>>recent bug which did not only sync the "modified" proposal data back to the new "original" data, but replaced all the customer data with the SAP data if you use that button. CHeck OSS for the note and apply it via SNOTE, or simply avoid that button completely!

<<If you have any more details on that OSS Note, I would be very glad to check into it.  I have brought up a lot of Notes, but nothing quite right.

>>>>>Do not process step 3!

<<Remind me where I will find that -- is that in SU25?

>>>>>Go to QAS or PROD and restore the data back into DEV (assuming that you transported it always..). You will probably have to use the "insert and modify" option to upload otherwise you might loose data from the upgrade

<<I will have to get access to QAS to see the status in that system.   I saw something written about the "insert and modify" option and have been trying to find out what that is.

I look forward to your additional input on this so I can steer this project in the right direction.

Regards,

Ed

[OttoGold]

Hi,

I am going through the parts of SU25 to try to understand what needs to be done.
Step 1 to fill the customer tables -- the timestamp says was done 9 years ago by DDIC.  I believe that should be done only for the initial upgrade.  Correct me if I am wrong.

I have never performed an initial upgrade whatever that is. Must be just a funny name for system installation. Correct me if I am wrong.

Check this blog for little more information: http://scn.sap.com/community/security/blog/2012/06/20/su24-related-oss-notes-with-sap-support

especially the section stating:

Do it only once! Do it after the system installation. Do not do it again! Otherwise you delete everything you`ve ever maintained in SU24 customer data and replace it with SAP standard proposals. If you want to disable step 1 completely so you AND NOBODY else can start that step (via the button which is too obvious, you can still do it via the menu, but then there is an extra warning), you can apply OSS note 1691993.
You must also be careful with the upload function in SU24. If you pick the wrong upload option… BOOM! But that is another story (per default there is a button called “Replace Instead of Insert/ Modify” checked. If your selection in the upload is the *, then it drops all the content for every object that fits into the selection. BOOM! For star it drops everything).

Cheers Otto

[Former Member]

Hi Edward,

Edward Puffer wrote:
I am going through the parts of SU25 to try to understand what needs to be done.
Step 1 to fill the customer tables -- the timestamp says was done 9 years ago by DDIC.  I believe that should be done only for the initial upgrade.  Correct me if I am wrong.

This is correct, do not run step 1 again.

Edward Puffer wrote:
>>>>>Did you click on the "Accept SAP file" button?
<<I'm not sure where I would find that.  What transaction/function is that in?  Perhaps it was already executed by the prior Security person.

The "accept rest of sap file" button appears in step 2B from memory - as your client has already done this step you will not know if it was clicked. Basically if you click it you're saying "Ignore any customer specific SU24 updates we've made, just replace them with SAP's proposals". This is not what you want.

Edward Puffer wrote:
 >>>>>Do not process step 3!
<<Remind me where I will find that -- is that in SU25?

Yep - it's the step that transports the customer tables, which in your case are somewhat rogered. So it's best you don't transport them.

Hopefully the last security person transported all SU24 changes they made, so your QA system will have a set of customer data that you can download and upload back into your Dev system.

[Former Member]

Hi Otto,

I am very glad that you saw my question and replied.  I came across your blog yesterday, and I
thought you would have some good insight on the issue I see.

I was most interested in the very same item you have pasted in your note above, regarding the upload function in SU24.  I have been very careful in SU24 and SU25 to not repeat or add onto any errors that have already been made, so I have not yet encountered the button called “Replace Instead of Insert/Modify.” 

I get the feeling that a previous security person may have used this function, and I am seeing the fallout of that.  When I try to modify a role now, I find that authorizations that had been maintained are no longer in the role, and they are replaced by new standard authorizations.
All the literature I have read about this tells me I should see the maintained authorization and the new standard authorization as a suggestion of new content, but I don’t get both – I only get the new one.

In your experience, would using the “Replace Instead of Insert/Modify” result in the problems I am seeing now?  If so, is there any remedy?  If I upload the tables from a clean system (say QA), I believe it will overwrite any role development work done for this upgrade (which might be a good idea, based on other problems we have seen in what was built).  That option is preferable to the other choice – changing every role by referencing the role in the sandbox to make sure I don’t omit any maintained authorizations that had been removed but are needed.

Thanks very much,

Ed

[Former Member]

Hi Will,

Thank you very much for your response.  You confirmed a lot of my concerns that I am using SU25 properly, and not breaking something else while I am trying to fix my problem.  I kept away from Step 1 and Step 3, and now I know that I’m doing the right things in the Section 2 steps.

So that brings me back to my original question – what is causing the maintained authorizations in a role to be removed and replaced with new standard authorizations when I want to make an update?  I think you are proposing a solution that I can work on – to upload the customer data from QA back to DEV.  We did try a download/upload with just one role, but we found that the same problem occurred again.

I would like to be very careful with this -- if there is a clear procedure written for taking the customer data from QA to DEV, please point it out to me.

Thanks very much,

Ed

[Former Member]

Yes, the same thing will happen if you download roles from QA and upload them into Dev - your roles are not the problem here, the problem is with your authorization defaults, so as soon as you edit the role in Dev, the same defaults will be read into the role.

If the previous security admin did not transport the overwritten customer tables, then your QA USOBT_C and USOBX_C tables should contain the old defaults. It is these that you can download from QA and back into Dev.

Check out the download feature in SU24.

[OttoGold]

Hi again,

you`re too polite although I must have sounded a bit harsh... Sorry

I am here with Will - save your data from the test system or maybe go for production data even...

When I am thinking about it now... that means that you will upload A LOT of customer data into the DEV system... that means (unless there is a trick/ workaround) you will face A LOT of clicking with the next upgrade. Or is the system so clever that it will know? I`ve never tried to upload EVERYTHING.

Otto

[Former Member]

Hi Otto,

Thanks for getting back to me again.

Yes, I am looking at USOBT_C and USOBT_X in QA to compare it with DEV.  I can see that the previous security consultant made updates in DEV and they fortunately have not gone to QA yet.  So that is an option to download/upload back to DEV.

One fear -- if the authorization checks in QA have the "Remove Instead of Insert/Modify" active, there seems to be no reason to download/upload this back to DEV.  I have not found that button yet to know what it is set to.

Another fear -- by uploading, we wipe out what the previous security consultant did in DEV so far.  That may be good in order to get the roles in better shape, but now I see I would have to go back and set up all the same authorization checks and understand why they were set up in the first place.

I want to pose one more theory and get your input before going further with the download/upload option.....

First off, do we agree that my problem with losing maintained authorizations when merging roles from 4.7 to 6.0 is caused by the "Remove Instead of Insert/Modify" button?

If so, can I change that setting?  If it were not active, I think I could merge the roles from 4.7 into 6.0 just the way I want.  Is this button unique to every authorization check/object/transaction or is it just one button for the whole system?   I have yet to find this button as I very cautiously look through SU24 and elsewhere in the system.  Can you direct me on where I would find it.  If this setting can be changed, how do I do that, and what are the ramifications?

So let me know if my fears are justified on the dowload/upload option, and whether this other theory would work.

Thanks so much for your help.  The client is happy that I am coming closer to a solution, and I hope to get it sorted out soon.

Regards,

Ed Puffer

[Former Member]

Before you upgrade, you will normally ensure that all transports have been released and imported, unless they were junk. SU24 is not junk and must be kept in sync...

You will have to make the assumption that QAS or PROD has the SU24 values before someone toasted them in DEV (for sure they used the "Accept SAP file" button in 2B otherwise step 1 would not be 9 years old).

So... download the "customer data" only from QAS in SU24.

Upload it into su24 in DEV using the Insert/Modify option (remove the flag!) so that the previous upgrade file remains.

Then... go to table TCODE_MOD for the current release and get the list of transactions which have new SU22 data delivered. Double-check them for anything you are allergic against.

When you next upgrade, do the same --> go to TCODE_MOD and get the tcode list for the new release. Run 2A and then in 2B filter on this list. Those are the real ones with changes which you need to look at carefully.

The rest just "mark all" and then accept the current proposal.

ACHTUNG: Do not click on the "accept SAP file" option. You should normally want to process what is new. Additionally there was a bug about 3 months ago (see  https://service.sap.com/sap/support/notes/1696484 ) in that button which also deleted all the customer su24 entries, not just the new data delivered by SAP.

If you really want to be naive and just click on the "accept SAP file" button, then you MUST apply this SAP note via SNOTE before you upgrade (at least currently - so probably this actually happened more than 3 months ago?)

It realy is best not to give SU25 to anyone (even in DEV) unless they really know what they are doing and are disciplined about trying things, just to see what happens...  (that is what sandboxes are for... 🙂

Cheers,

Julius

[Former Member]

Hi Julius,

Thank you so much for the very thorough instructions.  I am going to review SAP Note 1696484 and all the others related to it, and take it step-by-step to get my system restored.

I think you were responding as I was editing my previous post, as I reviewed Otto's blog some more and saw that the "Replace Instead of Insert/Modify" button wasn't in SU24 but is part of the upload process.  I was getting worried that I would never find a good solution, so your note was a great help to lift my spirits and get me back on track.

If I owned this discussion, there would be several points coming to all of you for your help.  Maybe there's a way to get Chris Douglas back here to offer what he learned and to throw some points around.

I'll let you know how things are going with the upload.  Thanks again,

Ed

[Former Member]

Well you did search first (some folks are very shy of that) hence hijacking this thread...

Next time you can create a new discussion after searching, but consider that generally knowledgable folks will be more interested in a round of beers or a cup of tea than the silly points system...  😉

Cheers,

Julius

[Former Member]

Hi, you knew I'd be back. 

First, I have been playing around in SU24 in the sandbox, and when I save something new, I get this message:

Caution,

You are about to change the composition of the fields filled with authorization default
values, by either:

- Entering values in a previously empty field

- Deleting the values of a previously filled field

It is very likely that this change will lead to the loss of maintained authorizations in the roles that already contain the application in question. The loss of authorizations will take effect the next time the authorization data for the role is merged.

Choose "Cancel" to discard the current change of the authorization default values.

Note: There is no risk if you are changing the content of fields that were already filled. You only need to ensure that at least one authorization default value per field remains.

Could this be the reason for the problems I have seen?  If someone else was doing the authorization checks and removing values, the result would be that maintained authorizations would be removed and replaced with new standard authorizations that needed to be maintained.

[Former Member]

Hi, I have been studying this, and I have found that the error message I saw yesterday definitely speaks to the problem I have been having. 

I created a test role with one transaction, then went into SU24 for that transaction and made a new auth check with display 03.  After I updated that role in PFCG (maintaining the new authorization), I went back to SU24, changed that new auth check by removing 03.

When I went back into the role in expert mode, the maintained authorization was gone and replaced with a new standard authorization with no values.

My concern is that wherever the authorization checks are coming from, their construction is corrupt!  I'm not even sure that the original auth checks are OK -- if they had values that were later taken out, I am concerned that they will cause this error I am seeing.

I'm getting ready to upload the auth check tables from QA back to the Sandbox, but I'm not sure that will solve the problem if there is another cause for this.  Is there some other setting/selection that someone must have clicked on that is now causing this problem?  I still don't have a clear answer on that, and I would love to know.

Thanks,

Ed

[Former Member]

It is fairly straight forward table access (so you can use SE16) but also fairly complex interpretation of single fields of the tables (which makes updates very tricky, such as the upload functions). Particularly the modification dates play an important role, but that is not always obvious at first.

You seem to be a bit new to this SU24 thing... so if I were you I would open a customer message with SAP and report loss of data (you already have the SAP Note) and ask them to help you restore the data in DEV.

If you try it on your own, then much like SU25 itself, it is best to do this for the first time with someone who has done it a few times and felt some of the pain-points and has an instinct for the implications.

For example in the USOBT_CD change doc table you will be able to see the transaction context and the time stamps of the "speed" of the error being caused. It is probably SU26 context (this is just symbolic) and very fast changes to a large number of transactions (as steps 2 might also have prior been run 9 years ago as well...). The new message in PFCG then lured some basis person (?) into SU25 and they got bored after 5 minutes (you can also see that in the change docs as a pattern, if it is the case).

Summary: You need to be brave -> upload from QAS to DEV (should be OK from my gut feeling here). Otherwise you need to find yourself a consulting who has fixed complex messes before and would need to access the system to take a look. Speculation is not a good idea.

Cheers,

Julius

[Former Member]

Hi, I am still plugging away at my problem.

The SAP Note 1696484 has been applied on the sandbox, and I
am happy to report that when I test it (upload a select set of authorization
checks, run the SU25 2-steps, and check my sample role, I see that the
maintained authorizations are retained.

However, now I am seeing just the opposite problem – the old
maintained authorization is there, but the role does not receive the new
proposed standard authorization with more functionality suggested.  I am being careful with all of my steps.  I can repeat the problem by starting fresh
(uploading the original sandbox SU24 settings for the sample group to return to
the original problem, then uploading the SU24 settings from the test system,
then doing SU25 2-steps).  Am I missing a
step, or is something unexpected going on?

-------------------------

I have a second issue.  My other client is doing an Enhancement Pack upgrade from EhP2 to EhP6, and I need to do research on the Security Upgrade steps.

I will be using the “Upgrade Steps for Security Quick Reference” that Julius put together some time ago.  Based on what I see so far, I see a lot of role merge work needs to be done in the development system that is now EhP6.

But when I look at a system that is still on EhP2, I see a lot of role merge work has to be done there also.  A lot of the updates I will need to do on EhP6 are identical to what I see on the EhP2 system.It makes me wonder if the security upgrade was done when systems were upgraded to EhP2.  Is therea way to check an EhP2 system to see if the security upgrade was actually completed?  If it was done, could theSU22 settings be updated later by support packages, thus giving the appearance that roles need to be merged?

[Former Member]

I finally have (or made) the time to give an update, and pass along great thanks for the help I have received.

For my first issue of roles that were missing authorizations during upgrade, I applied SAP Note 1696484 in development, uploaded the authoration checks again, ran the SU25 2-steps again.  Everything worked well.  There are only a few issues coming up during testing, where I find that authorizations have been removed, but I can restore them to their 4.7 level.

Next for this client is to run the SU25 steps on the QA system, as the role updates I made are being tested now.  Any thoughts would be appreciated, but I think I just need to go through the 2-steps.

For my second client's issue, we have completed EhP6 upgrade.  Most security issues were handled by running the SU25 2-steps and deactivating the merge mode for the roles that came up.  A few issues since then where we found new authorization checks (such as some asking for ' ' in B_BUPA_GRP or other objects), but relatively easy to handle with solid effort.

[Former Member]

Hello Experts,

Sorry to open this already closed thread, but the I read through the discussion above which seemed to be similar to the issues that I am facing. If the moderators feel, that a new discussion should be started, I can start a new discussion.

We are in the process of running SU25 after an upgrade to EHP6. We have only run it in Sandbox till now and run into the problem of SAP suggesting new default values for several objects which can create a problem with the maintained values for these objects in our roles.

I can look up USOBT_CD to find out all the tcodes and objects which are impacted but thats a huge list. Is there a simpler way of accomplishing this rather than look at all the impacted roles and the maintained objects under them?

Also, from what I understand the option of loading the SU24 data from QAS will either allow me to keep my old values or use the new SAP values. Does it also address the situation where I would want to keep both my old values and incorporate new data brought in by the upgrade.

Thanks,

Aninda