Post EHP7 upgrade "issues" (or things I just don't understand)

[chrissap]

Hello Security Gurus,

I've run through SU25 post EHP7 implementation and have found the following inconsistencies within my roles now that i cannot find any info on in other posts, forgive me if the information is already out there.

Issue #1: In our ECC system, we have a number of Transactions with S_RFC as a checked object in this form:

     ACTVT: 16

     RFC_NAME:

     RFC_TYPE:

               Leaving the RFC_NAME and RFC_TYPE blank so we can adjust in PFCG in read and merge mode. After the upgrade, when I read and                merge, I lose all entries we 'maintained' for S_RFC object. Does anyone know if this object no longer allows maintenance in PFCG and                what the reasons for this may be? Is there a workaround to keep it as is in the old system?

Issue #2: We have 2 Transactions: RBDAPP01 & RSEOUT00, which in our original ECC system brought in objects: S_DEVELOP, S_DATASET AND S_PROGRAM. However, in the upgraded EHP7, when I do a read and merge, I lose all those values. When I look in USOBT_C in the original system, I DO NOT see the objects S_DEVELOP, S_DATASET AND S_PROGRAM, but they are indeed listed in PFCG.

     My question is: If SU24 does NOT contain a check for an authorization object, is there any other way that object can be automatically added in PFCG in the Expert Mode for Profile Generation - Read old status and merge with new data? Images below are to illustrate this issue:

In PFCG after doing a Read and Merge:

In USOBT_C, as you can see S_DATASET isn't associated to RBDAPP01:

Thanks for your time,
Chris

[Colleen]

Hi Chris

For issue 2 - not sure on workings of EHP7 but the S_DEVELOP, etc would have been brought in due to the SE93 definition RBDAPP01 of using transaction SE38

PFCG would look at the values for both RBDAPP01 and SE38 (see PFCG overview screen shot below)

What is the definition in EHP7 for transaction RBDAPP01?

Regards

Colleen

Ps - Issue 1 with S_RFC - I heard back on release 731 via a friend with access to SAP Security developer that they did something with S_RFC to force maintenance via SU24 for defaulting the values. I suspect one of the more knowledgeable regular SCN security guys will have information on this. The quote I got ws "If you have this object in usobt_c with either an empty or full authorisation value defined it will AUTOMATICALLY remove it from the role when you generate the profile... They did it to close security breach from jumping system". Possilby there is a SAP note in Marketplace mentioning this.

PPS - think this is the note regarding S_RFC implication if partially maintained in SU24 1749485 - PFCG: Problems when updating start authorizations

Message was edited by: Colleen Lee Added S_RFC comment

[Former Member]

You must read and apply the notes related to sap note 440231 before performing SU25 (particularly ones related to loss of data). You must do that!

You must never (ever!) click on the button "Accept SAP file" in step 2b! Probably you did that... In the new expert mode it has a new title - avoid it like the plague and choose manual adjustement mode and navigate back to step 2B.

An open field proposal for RFC_NAME makes no sense so you should actually report it to SAP. Was it in an SD role? Note: If you had added the function modules to the menu then you would not have this problem.

If a parameter tcode dont have own proposals, then they inherit the proposal of the parameterized tcode. But SA38 is a bad choice - should have been START_REPORT.. so you should report that to SAP as well actually.

Cheers,

Julius

[Colleen]

But SA38 is a bad choice - should have been START_REPORT.. so you should report that to SAP as well actually.

I am wondering if SAP recognized that and fixed the transactions like RBDAPP01 in EHP7 so they don't use SE38/SA83 anymore? I'm not on EHP7 to confirm - my screen shot is EHP6.

Cheers

Colleen

[Former Member]

There are still some legacy tcodes used as parameters.

SE38 makes very little sense as it calls AUTHORITY_CHECK_TCODE on itself in the submitted program. SA38 is still in the easy access menu navigation and titled "ABAP reporting" so is harder to replace with alternatives as you dont know how many are actually using it and the navigation path.

But it can be done and works fine if you can work out who might be authorized for it and compare it to who is actually using it - then you know who you need to provide a better alternative for than using SA38 with backspace to find the favourites from memory IDs.

Cheers,

Julius

[Colleen]

But you also confirm it when you revoke the access and see who complains (after sufficient warning to get their house in order and get custom transactions built). As an interim, move the SA38 to a firefighter/emergency access setup as temporary access

I constantly lose the battle to restrict SE16/SM30/31/34 and SE38/SE37/SA38/etc from Production systems. It won't stop me from trying and educating functional to get their access requirements in for support users.

Regards

Colleen

[mvoros]

Yep, in EHP7 transaction RBDAPP01 uses SA39 instead of SE38. SA39 does not require S_PROGRAM.

Cheers