authorization upgrade

[Former Member]

Hi all,

I have got a question: an upcoming release update from 4.6 to ECC6.0 will of course also affect authorizations.

Can I analyze the affected roles in the system before I execute SU25? and if so, how? Or do I have to wait for the results from that SU25?

It would be great to get an impression of the work that needs to be done before I "press the button".

Thanks for any helpful answer.

[Colleen]

Hi August

for steps 2A and 2B:

you could compare the su22 tables usobt/usobx with the su24 tables usobx _c/usobt_c tables to find the differences. Once you have list of tcodes you can check which roles have them in role menu via agr_tcodes table to get list of roles.

for step 2C have a look at prgn_corr2 to see proposed replacement transactions to see if you need to swap any in your roles

regards

Colleen

[Former Member]

Hi Colleen

thank you very much for your answer. That is already a big help for me.

One main point for the relevant departments in my company is that the upgrade will introduce absolutely no new functions and everything should be as they know it.

Is that realistic? As far as I understand it one of the reasons to do an upgrade is to bring in new functions and security options.

regards

August

[Colleen]

Hi August

I think you need to differentiate between what the company will introduce versus what the system will introduce. 4.6* systems are becoming out of support for customers (extended support, etc ending/ended unless customer has negotiated a special agreement with SAP). Quite a few customers are upgrading their systems to ERP6, however, they are doing treating this as a technical upgrade only. You will probably hear in meetings at work 'this is a technical like for like replacement' - your company's goal is to make zero changes unless absolutely necessary.

Think of it this way - the 4.6* are more than 10 years old. How much do you think technology has changed in that time - SAP is quite different!

From your company's point of view they probably don't intend users to change how they use the system unless SAP has deprecated the functionality. There may be new transactions, programs, approaches to performing the same activity in SAP but they have not considered it. Alternatively, your company may go onto say 'Phase 1 is the technical upgrade' and then 'Phase 2 we'll investigate improvements', etc.

From a security point of view there are still heaps of impacts - beyond SU25. Your company may be minimising the amount of changes to the system and what the user does but that does not mean SAP has not improved or undertaken major change to the programs. With this, there will be differences such as:

• New authorisation checks in program to improve security (such as SM59 transaction having new object S_RFC_ADM);
• New Authorisation objects or changes to some (need to regenerate SAP_ALL and update any project roles)
• SE97  Call Transaction (not sure when introduced but 4.6b system doesn't have it) which will control whether S_TCODE is checked when a CALL TRANSACTION is performed in the program;
• New Transaction Codes and changes to some - for example in security space, SUIM transaction has had changes to the underlying programs and some changes in transaction codes as a result; then there is an improved security trace STAUTHRACE
• Change to general functionality such at transaction SU53 now checking more than 1 last failed auth check
• New System Parameters and also a new concept of Security Policy (SECPOL) so that you can classify users into different groups and assign them password rules
• Improved security on table access with new auth objects S_TABU_DIS*
• Major change and recommendation for ABAP development (really custom programs should be reviewed to check for security improvements).
• SU53/STAUTHTRACE can integrate with PFCG when you build roles

If you have a 4.6 and an ERP6 system to compare to get an idea of the differences also consider differences in table counts for:

• TOBJ (authorisation objects)
• TSTCT (transaction codes - use language EN and exclude Y* and Z* customer codes)

Authorisation impacts to users will be identified via thorough testing of roles

Regards

Colleen

[Former Member]

Hi Colleen,

once again: thank you for your answer. Of course, you are absolutely right. It reminds me of the discussions I had which always went like this: "Yes, I know, we have to do an upgrade, but it has to be done with no effort and users have to have no changes in their GUI, their work functions etc. after the upgrade.

Now another topic has come up (and that is why I asked about how to do an analysis on the number of affected roles). A guy in my company has found out that PANAYA has a tool that does an analysis on the upgrade effort before the upgrade without needing much time for it.

My answer to that was that we will have to execute SU25 and wait for the results.

From your comments I take it that there is a way to do an analysis before the upgrade but that it takes some time. Am I right?

regards

August

[Colleen]

Hi August

You can go through and technically analyse certain impacts to your upgrade - how long it takes will depend on your system and skill set to perform the checks.

3rd party solution usually perform technical checks and will offer other system recommendations. Without knowing what that vendor does it is hard to say, however, they would not be the only vendor out their offering that particular service.

Regards

Colleen

[Former Member]

Hi Colleen,

I suspect that mentioning a 3rd party tool tries to give a little bit of pressure to me to officially minimize my efforts.

As far as I know the tool produces a list like this: " in role 123 add object xy for transaction ABCD"

It also produces a list of obsolete transactions and their replacements.

regrads

August

[Colleen]

Hi

Using a tool to do the analysis for you isn't going to save a heap of time. Think how much time it will take to work with the vendor to install and get up and running. I'm not saying it's not worth doing but this focus on minimising time and pressure might just be shifting numbers around.

If you have never done an upgrade or worked on ERP 6 system/know security technical build quite well (down to data/table level) then you probably will save more time with external assistance whether it's a tool or not

you could analyse your roles wit the table provided via Ms Access if you know how to build queries, etc. Again, effort and time really comes back to your skill set as well.

The other bit is that the vendor may have their own 'best practise' recommendations that are proposed beyond comparing those tables.

Regards

Colleen

[Former Member]

Hi all,

thanks again for the really helpful comments. I have argued with the relevant decision makers in my company. Now they are aware of the fact that there will be a difference in ECC6.0 compared to 4.6.

Their latest idea now is to say that they see the need for changes. So they would like to do a complete redesign of the authorization concept sometime in the future. For now they just would like to "survive" the current release upgrade.

Instead of major and possibly necessary changes in the roles they demand from me a gap report between the authorizations in the roles in the old release and the new release. So they can decide in advance which changes are acceptable to them and which are not.

Am I right that I can sort of simulate these changes using the SU25?

I have a list of roles and can see the menu of the roles via PFCG.

I would like to build an excelsheet which contains roles, transactions and authorization objects.

Any helpful comments are highly appreciated.

Best regards

August

[Colleen]

Hi August

Using SU25 will only help you to a point if you have been maintaining SU24 data consistently. You could take the USOBT and UBOBX tables and compare them to USOBT_C and USOBX_C tables to find differences (which is Steps 2A and 2B without making changes). Once you have the list of tranaction you could then use your AGR_TCODES table for transaction to roles to find impacted roles. That might give you a starting point but there is reliance on consistent maitnenance. If your PFCG roles have heaps of manual objects and S_TCODE you won't get the full picture. Also, if you allow SE38/SA38 then you won't get programs executed directly.

You can then look at PRGN_CORR2 table for replacement transaction codes to see if you need to swap them over.

If they are doing the bare minimum and you anticipate full redesign, I would put more effort and focus into regression testing of functionality with end user roles. This will enable you to identify authorisation issues.

I have been in a few situations where management just want to 'get this over the line' or 'survive'. Good luck holding them to that as they will get through go-live and resoruces (functional and process people) will be re-allocated to next business project and the project closed out (with that the project funding). I hope your situation is better.

Regards

Colleen

Ps I gave some of this information in this thread. SU25 steps in the background have changed a bit since then but still mentions the tables, etc

[Bernhard_SAP]

Hello August,

you won't be able to compare/evaluate the effort for su25 2c before the upgrade. Because first you need the new content of usobx and usobt, which you get by upgrading the system!

Only if you have already an upgraded system, yopu could compare the effort.

But starting in 46x with target to an acutalk release (7.31/7.40) will bring you almost all of your roles in 2c....that is , what the expirience shows.

So take your time for adapting your roles and especially for testing them together with tthe new funcitonality.

b.rgds Bernhard.

[Former Member]

Hello Colleen, hello Bernhard,

thank you so much for your comments.

Actually I am having an already upgraded system available.

@ Colleen: you are absolutely right. I do not think that my management wants to know about the implications and about the consequences of an upgrade: they hope that the only difference will be that the GUI will be in dark blue instead of light blue colours. 😉

Because I am only given 20 days for the upgrade of 550 roles (5 days for analysis, 10 for the doing and 5 for testing) I will have to limit myself to the main tasks.

So my plan is as follows:

1. compare roles with tcodes and their respective authorization objects in the old release with tcodes and their respective authorization objects in the new release. Together with running PRGN_CORR2 that should result in a gap report. Management will then have to approve the changes they want.

2. run SU25 2a - 3

3. testing

Is that realistic or am I completely mad?

Best regards

August.

[Bernhard_SAP]

just found again:

http://wiki.scn.sap.com/wiki/display/Security/Best+Practices+-+How+to+find+TCodes+changed+after+upgr...

which provides also a hint...

I can only suggest to conentrate first on the main t-codes (I mean for your core business applications). Saw also already, that the upgrade was taken as chance to redesign the auth-concept.

Or at least, create new roles for the main business tasks first and assign them. The decision, whether the old roles shall be 'upgraded' then later or if only 'new' roles should be used can be taken quickly, the realization can be spread then ito improtant and not so important tasks.

b.rgds, Bernhard

[Former Member]

Hi all

it has been a while but I thought I'd give you an update.

We have not made real progress with our upgrade.

Instead, my boss has asked me to try a different approach. He plans to have a sandbox system as a copy of the old PRD during the upgrade to evaluate the possible consequences of the upgrade.

My task should now only be to go through the roles, see which objects have changed and only change what is needed to uphold the functionality of the role.

My question is: does that work?

I know that this approach is nowhere near the required security but I kind of have given up to remind people about the need for that.

best regards

August

[Colleen]

Hi August

My task should now only be to go through the roles, see which objects have changed and only change what is needed to uphold the functionality of the role.

The upgrade will not change your custom built roles unless you execute SU25 to make changes to it. I'm not sure if this is what you meant by comparing the roles?

If you have a copy of production and then apply the enhancement packs to DEV you can compare the two systems for transaction code, different SU24, other items I listed above.

Again, how much you can rely on this comparison (e.g. SU24 changes) will partly depend on how consistently your system was maintained.

If you are going to do the bare minimum for security build, I would focus effort on completing the SU25 steps and doing as much regression testing of security as possible. With that effort, you will still more than likely find yourself dealing with incidents in production support for authorisation errors or exposure to too much access if something is not secured properly.

A copy of the system will allow you to prototype and compare differences that you may identify in testing.

I know that this approach is nowhere near the required security but I kind of have given up to remind people about the need for that.

Sadly, that is all to common to give up. It is usually a pre-cursor to saying "I told you so" when the auditor calls out the risk in a report.

Regards

Colleen