Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

GRC 10 Conflict for ME23N & ME28

Former Member
0 Kudos

Hi Guys,

I have a question...

In GRC 10 I came across access risk P059 which is associated with PR02 and PR04. I found out that ME23N is hitting S_TCODE auth object and ME28 is hitting M_EINK_FRG which has a value $. Is this a right set up? Would you recommend changing it to * instead? and what would be the solution for ME23N with S_TCODE?

Your suggestion will be highly appreciated.

Thanks

Syed

1 ACCEPTED SOLUTION

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

https://service.sap.com/sap/support/notes/1050832

Basically, all the ME* transactions relied on the same code, so the objects for ME28 might make ME23N a non-display transaction.

That's only true for older releases, though, so you can probably safely take ME23N away from the functions and re-generate the rules.

Frank.

10 REPLIES 10

Former Member
0 Kudos

When it comes to purchasing and organization values it is hard to determine what best fits your business.  Are org values relevant in your rule set?  Have you implemented any sort of release strategy?  Based on these two answers you may find that to not be relevant within your rule set at all.  What do you see as the risk in Displaying a Purchase Order and Releasing one?

0 Kudos

Hi Chris,

Thank you for the output. Unfortunately don't have much info to share with you because I started  this week. I am still under the process of gathering information on both SAP role structure and on GRC side. From what I know, in past we have given * instead of $ for FRGCO  and leave FRGGR empty. Not sure if that's a correct approach.

By looking at below image would you be able to suggest something?

HighPR02PRDME23N08/29/2012 09:39:239S_TCODETCDME23N

HighPR04PRDME28 0M_EINK_FRGFRGCO$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

ME28

0

M_EINK_FRG

FRGCO

$

P059

0005

High

PR04

PRD

0 Kudos

Without knowing the structure of your purchasing within the system and also the companies policy I cannot make a recommendation as there are too many details missing.  When configuring the rule set, what may work for one company, may not for another.  As you find more information, I would be happy to assist.

0 Kudos

Chris - Thank you for your output. I will reach out to you once I get some additional information from the business side. Then only I guess we can tackle this issue.

Thanks

Syed

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

https://service.sap.com/sap/support/notes/1050832

Basically, all the ME* transactions relied on the same code, so the objects for ME28 might make ME23N a non-display transaction.

That's only true for older releases, though, so you can probably safely take ME23N away from the functions and re-generate the rules.

Frank.

Former Member
0 Kudos

Hi Frank,

That will indeed solve my issue related to ME23N. But I am still concern about ME28.

Thank you for your help!

Syed

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

Syed,

why are you concerned about ME28?

In AC5.3 "$" is a wildcard (because "*" looks for the exact character), which means this rule will hit ANY release code. Does that help?

Frank.

Former Member
0 Kudos

Frank are you sure you don't have that backwards?  $ is a wildcard that will look at any single character where * look at any character or string? 

Syed, based on my business processes we have disabled the M_EINK_FRG object in our rule set but that is only after a thorough review of the business process.

Former Member
0 Kudos

It is always enlightening for me to look in usobx_c for no check indicators for the objects which are parts of functions.

For sure there is valid business case for the no checks and in most cases I see the "logistics" events as being the trigger and the corresponding checks... but increasingly I think to myself what value a tcode (action) context has for such an analysis other than to turn it off.

If is is turned on or at the correct location in the coding, you should be concerned about the application object and which tcodes need it and not about the myriad of tcodes, rfc's, webservices and dynpro applications which will reach that check.

Bar TSTCA checks which is also directly tied to the tcode only, the statements should be at the correct locations of the application processing layer.

Or, to put it differently.. I find it very stupid that GRC rules force applications to propose objects and their values just so that GRC knows what they are capable of. The number of open fields and incorrect proposals is increasing as standard values yet the whole spagetti of S_PROGRAM, S_TABU*, S_ARCHIVE, S_DATASET, etc is still not maintained despite it being very easy to work out which parameters are being passed.

We have a lot of success with GRC in our projects if done correctly, but it is also an invitation to do a lot of stupid things which can duck under the radar to turn the traffic lights green.

Classic example is a series of tcode roles, another with the org. level values and.. ohhh well.. ACTVT is here and there... as long as the roles are SOD free. Assignment of the roles is the customer's problem. I am waiting with anticipation for customers to take legal action against such PPT programmer ideas...

Cheers,

Julius

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

A fool with a tool is still a fool.

The biggest advance in customers using GRC Access Control has been that it creates a language that allows the SAP guys to talk to the business guys about authorizations, which was not on their radar before.

The rest is in the implementation - totally agree that working on SoD free roles without making sure that the role assignment process addresses SoD too is pointless.

Frank.