Different logic between two programs: RSUSR002 and RSUSR008_009_NEW

[Former Member]

Dear Experts,

We are currently in the process of auditing user authorization for critical transaction. As we were suggested by the consultant to utilize the std report RSUSR008_009_NEW as a tool to find out users with critical authorizations. We ran RSUSR008_009_NEW and RSUSR002 with the same criteria and found out the differences in results between these reports. Then, we tested and found the below concerns:

1. Program RSUSR008_009_NEW treats '*' as literal while RSUSR002 treats as wildcard

2. If the authorization field is a checkbox, in order to search for full authorization by RSUSR008_009_NEW we need to put '#' e.g. Account Type (KOART) field maintain as '' in one user we need to put '#*' in order to show that user in the RSUSR008_009_NEW report. But, this is not the case for the free text fields e.g. business area, company code, etc.

3. We tested with variant to find users who can change data for company code 'A'. we found that the RSUSR008_009_NEW report shows users who has a ACTVT = '02' but not BUKRS = 'A' but he has another role assigned which contain display ACTVT = '03' and BUKRS = 'A'. However, this user ID shouldn't be shown in the report since ACTVT = '02' and BUKRS = 'A' are not in the same profile or even in the same role.

Questions:

- We wonder if this is a bug in the program or we set something wrong in the variant for RSUSR008_009_NEW?

- Does the program RSUSR008_009_NEW do not care whether the specified critical obj. values are in the same profile or not?

- Which report we can trust?

Please kindly help us. We do really appreciate your answer!

[Former Member]

Hi

Are you sure you want to consider org levels anyway?

Cheers

David

[Former Member]

Dear David,

The reason we limited the company code because we want to audit on this company only.

Brgd,

Warakhun S.

[Former Member]

Hi Warakhuns

I've looked at the entries behind this recently and also to GRC and considering org levels of any kinds can (as already stated) incurheavy ongoing maintenance.

New plants = new values, new plants not advised = one big hole in the SoD report

I would stick to ACTVT for the relevant fields and ask for mitigation docs for the USERS with the cross-overs.

Spent a lot of time with USKRIA - SUKRI(T) and it can work if you can define the 'ruleset' and that is where GRC's ruleset starts to make a little more sense.

SAP does SAP - Other Tools does RAR

Cheers and very good luck!

David

Edited by: David Berry on Jul 15, 2011 10:43 PM

[Former Member]

Which release and SP are you on?

The search patterns were harmonized some time ago, but were originally different.

See SAP notes on the report for the SP dependencies. The main one is in the FAQ sticky thread.

Cheers,

Julius

[Former Member]

Dear Julius,

Thanks for you advice. It's ECC5.0 for SP level I have to check I cannot recall it. As you said both reports have been harmonized, may I know which notes my BASIS should apply? But both reports SAP intended to have the same results to be shown?

Thanks alot!

Warakhun S.

[Former Member]

Dear Experts,

Our SAP component version is ECC5.0 and the SAP_BASIS Release is 640 Level 17. Please advice how do we identify what note no. we need to apply to fix the bug as mentioned.

Thank you very much in advance!

Brgd,

Warakhun S.

[Former Member]

Dear Experts,
> 
> We are currently in the process of auditing user authorization for critical transaction. As we were suggested by the consultant to utilize the std report RSUSR008_009_NEW as a tool to find out users with critical authorizations. We ran RSUSR008_009_NEW and RSUSR002 with the same criteria and found out the differences in results between these reports. Then, we tested and found the below concerns:
> 
> 1. Program RSUSR008_009_NEW treats '*' as literal while RSUSR002 treats as wildcard

I had my own struggle understanding how RSUSR008_009_NEW interprets * and with some assurance i can tell you that it returns whatever value a user has, you could give it a try configuring a * for purchase order release groups and release codes (honestly, i didnt try a * for any other field)

> 3. We tested with variant to find users who can change data for company code 'A'. we found that the RSUSR008_009_NEW report shows users who has a ACTVT = '02' but not BUKRS =  'A' but he has another role assigned which contain display ACTVT = '03' and BUKRS = 'A'. However, this user ID  shouldn't be shown in the report since ACTVT = '02' and BUKRS = 'A' are not in the same profile or even in the same role. 

The output of RSUSR008_009_NEW is dependent on the configuration behind, it depends on the values you define for specific authorization objects.

As an example, If you want to check on users having access to post documents, you would configure the report to check for the object F_KNA1_BUK, now this object has two fields ACTVT and BUKRS, Ideally you would like to check only on the activity and not on the company code (as David mentioned in the above reply), because (1)entering a value for the company code would restrict your search (if you have only a specific comapny code defined) (2) You would have huge configuration & maintenance effort for entering all the company code values when you configure it for the first time and subsequent maintenance effort when new company codes are added (personally i would suggest to refrain from entering values for organizational elements)

> Please kindly help us. We do really appreciate your answer!

Have a look at a similar post on the forum []

Sorry, F_KNA1_BUK was a sissy example for posting documents, it should have been F_BKPF_BUK or something similar

Edited by: Shekar.J on Jul 15, 2011 11:16 AM

[Former Member]

Dear Sherkar,

Thanks alot for your advice!

I have not tried with the PO release group yet, but when I tried with the simple test user created and assigned with the below authorization.

S_TCODE TCD = F-02

F_BKPF_GSB ACTVT = 02

F_BKPF_GSB GSBER = A

and in my RSUSR008_009_NEW variant condition I have the below setting

S_TCODE TCD = F-02

AND

F_BKPF_GSB ACTVT = 02

AND

F_BKPF_GSB GSBER = *

the result show no matching user found when I ran the report. But on the other hand when I change the authorization of the user for field GSBER to '*' and without changing the setting in the variant the report shows my test user.

As of now I still think that the program RSUSR008_009_NEW will seach for full authorization if I specify the '*' in the variant. It also say in SAP HELP as well (http://help.sap.com/saphelp_nw04/helpdata/en/f9/558f40f3b19920e10000000a1550b0/content.htm)

Btw, the reason I limited company code to a specific value becuase of our audit scope. We tested only one company code. But the report RSUSR008_009_NEW shows a few users who got all the specified authorization as in the variant setting except the company code. When I searched the user - role - authorization I found that the company code I am interested is in another role of this user which technically does not allow the user to maintain data under that company code. Below is the criteria I used with 'AND' condition in all fields...

S_TCODE TCD FBD1

F_BKPF_BUK ACTVT 01

F_BKPF_BUK BUKRS 119

F_BKPF_GSB ACTVT 01

F_BKPF_KOA ACTVT 01

With report RSUSR002 I used below criteria

S_TCODE TCD FBD1

F_BKPF_BUK ACTVT 01

F_BKPF_BUK BUKRS 119

F_BKPF_GSB ACTVT 01

F_BKPF_GSB GSBER *

F_BKPF_KOA ACTVT 01

F_BKPF_KOA KOART *

From the thread you mentioned, I do not have the issue with the authorization values defined in range. I also tested and RSUSR008_009_NEW works fine with the defined range values meaning that it can still pick up the user if the values are defined in range. And also for RSUSR002 it can pick up the user if he is assigned with the manual added object

I am still not sure which report is more reliable?? I hope that we can rely on the RSUSR008_009_NEW since it is more effective to use and we need to run the test for hundreds of rules across all company codes in the future.

Thanks so much!

Warakhun S.

[Former Member]

Dear Sherkar, 
> 
> Thanks alot for your advice!
> 
> I have not tried with the PO release group yet, but when I tried with the simple test user created and assigned with the below authorization. 
> 
> S_TCODE       TCD      = F-02
> F_BKPF_GSB ACTVT = 02
> F_BKPF_GSB GSBER = A
> 
> and in my RSUSR008_009_NEW variant condition I have the below setting
> 
> S_TCODE TCD = F-02
> AND
> F_BKPF_GSB ACTVT = 02
> AND
> F_BKPF_GSB GSBER = *
> 
> the result show no matching user found when I ran the report. But on the other hand when I change the authorization of the user for field GSBER to '*' and without changing the setting in the variant the report shows my test user. 
>

the report output of RSUSR_008_009_NEW is correct, If you look at the configuration, you are suggesting that a user should be shown as having a conflcit IF he has S_TCODE=F-02 AND F_BKPF_ACTVT=02 AND F_BKPF_GSBER =*

and for what i understand a * in this field is not interpreted as "any value" it is interpreted as "all".

I learnt it the hardway that a * for the purchase release codes and release groups is not interpreted the same way as explained above, a * there means "any value"

[Former Member]

Dear Sherkar,

Yes, it is correct if we interpret '*' as all authorization.

But our issues are:

1. We do not know what value/symbol we have to put for variant in RSUSR008_009_NEW to have this report shows the same result as RSUSR002 in another word what symbol shold I put in order to search any value for a particular field.

Note: We need to treat '*' as any value becuase of the rule identified by the business side.

2. As a result from the issue above we remove every field which contain value '*' from the variant but then the result almost the same between these two reports only a few users which do not have the company code 119 as we specified in the variant

Original in RSUSR002 and RSUSR008_009_NEW

0001 S_TCODE TCD FBD1 AND

0002 F_BKPF_BUK ACTVT 01 AND

0002 F_BKPF_BUK BUKRS 119 AND

0003 F_BKPF_GSB ACTVT 01 AND

0003 F_BKPF_GSB GSBER * AND

0004 F_BKPF_KOA ACTVT 01 AND

0004 F_BKPF_KOA KOART * AND

After remove fields which contain '*' for RSUSR008_009_NEW and we expect to have the same result as RSUSR002

0001 S_TCODE TCD FBD1 AND

0002 F_BKPF_BUK ACTVT 01 AND

0002 F_BKPF_BUK BUKRS 119 AND

0003 F_BKPF_GSB ACTVT 01 AND

0004 F_BKPF_KOA ACTVT 01 AND

For the first issue I am not sure if RSUSR008_009_NEW report was designed to interpret like that. But why '' does not work with some fields which enable checkboxes since I need to put '#' for those fields if I want full auth. This is probably a program bug.

The second issue is probably a bug also but this is not related to '*'

I have also tried with plant (WERKS) field in our IDES ECC5.0 SL 12 it also treat '*' as literal (full authorization only). Which sap version and SL you use?

Please kindly advice : )

With Best Regards,

Warakhun S.

Edited by: Warakhuns on Jul 18, 2011 11:21 AM

Edited by: Warakhuns on Jul 18, 2011 11:56 AM

Edited by: Warakhuns on Jul 18, 2011 11:57 AM

[Former Member]

There are a couple of things here (1) think of the objective: Is "our" objective to ensure that the ouptut result of both reports looks exactly the same? (OR) (2) Is the interntion, to cross check the output that is generated from one report with the output of the other report?

As mentioned earlier, the purpose of both the reports is different. one report is to check on the authorization objects and the values , the other report (R***008_009) is to check for conflcits within the authorizations to ensure a SOD compliant set-up

*most important, as far as i know SAP does not support help on this report, after the market penetration achieved with GRC, so finding help from that end could be difficult

Now coming to the problem

what was the result of the comparison between the reports after you configured

> 0001	S_TCODE	TCD	FBD1	AND
> 0002	F_BKPF_BUK	ACTVT	01	AND
> 0002	F_BKPF_BUK	BUKRS	119	AND
> 0003	F_BKPF_GSB	ACTVT	01	AND
> 0004	F_BKPF_KOA	ACTVT	01	AND
> 

I will not be surprised if RSUSR****9 _NEW fails with the result, because - if a user has the organizational values for company code defined in a range 118-120, then the report might skip the user, because you have defined an absolute value (119) here in the configuration. So, i again repeat what David mentioned, refrain from configuring for organizational elements for this report.

I wouldnt recommend it but If having the organization element is a absolute necessity for you then, An alterante way to do it would be to use the OR operand

If the configuration is set right with the correct logical groupings, i personally prefer using an OR operand than the AND operand

you could try using a OR operand because logically a posting made in a company code, has to reflect in some business area and would belong to one or the other account type (D,K,S,...) so having a OR operand should be ok and this would give you the flexibility of entering the organization element (be sure you might have to do it a quite a few times) you can enter the BUKRS values 118 OR 119 OR 120 OR......that should give you the results you are looking for

you might also want to have a look at the "Work arounds"post at the top of the Forum

I am working on ECC6.0 Release 7.0 Patch Level 13

Edited by: Shekar.J on Jul 18, 2011 4:32 PM

[Former Member]

Dear Sherkar,

Actually the objective is to compare between two report RSUSR008_009_NEW with the auditor tool (BizRights), but when we ran RSUSR008_009_NEW we noticed the result is incorrect so we ran RSUSR002 to compare. And, that came to the issue. But the result between RSUSER002 and BizRights are the same though.

We know that the intentions of both reports are different. We thought that result from both RSUSR008_009_NEW and RSUSR002 will be the same since user who have the authorization should be able to do so but unfortunately it is not due to some bugs/logics behind each program.

As tested, the RSUSR008_009_NEW also work fine with the defined range value.

We kind of hope to rely on new report instead since it is more efficient to use and we have already been configured hundreds of rules.

I understand that your suggestion on not to limit the company code or put it as [OR] condition for work around solution to give the flexibility on org level values. But still we want to check who can post in one company code '119' since there are some cross company users who can only display and this user will be shown in the report if [OR] operand is used for this case which we want to exclude them.

Thanks alot for your advice,

Warakhun S.