Changing the parameters for the RSUSR008

Question: My company is asking that we run a report quarterly using the tcode S_BCE_68001401 to run the RSUSR008 (“Critical Combinations of Auth” report).

I have noticed that in our DEV 100 system we have, I'm guessing the delivered parameters, but in our PRD system they have been changed.

How should this best be maintained? Continue to change it in PRD when updates are needed? Or, change it in DEV 100 and transport it up through the systems?

Also what are the pitfalls of using this report, how reliable is it?

Answer:
RSUSR009 is the beter report but both are meaningless unless you configure the table correctly. It is possible but the output required close scruteny to have menaing. But it is better than none. In 4.7 there is a combo RSUSR008 and RSUSR009 that uses variables to evaluate business processes based on auth objects combos and not just tcode.

You can maintain in DEv, or PRD but better to do it in DEV so you can test in developement and transport.

Answer:
Thanks John,

What tcode uses the RSUSR009 program? Also does it use the same table SUKRI?

Answer:
Maintaining table SUKRI properly is the most highly skilled task in all of SAP security administration. You can become an expert security administrator before you'll be a good SUKRI maintainer. And woe unto Basis folks and ex-programmers who take this one on. You will need to have a mastery of business processes. Doing it properly also means that it should be done for every implementation. Don't take anyone's canned garbage.

Which brings me to all the segregation of duties compliance tools out there. They may be slick programs but in the end they all depend on the quality of the definitional database. Their "SUKRI" as it were. Since these must be customized for every implementation and no one is going to pay for that you'll get a lot of garbage reports and if you try to comply you'll just tie your end users into knots. They will be sharing user ids quicker than you can say johny jehosaphat.

The best strategy is to implement a small set of roles, develop a policy on role administration and manage segregation of duties on a role to role basis.

I think most modules can be run with 3-5 base roles. If your enterprise has a lot of business units then derive roles from the base roles where required.


Design right and you can really ease your compliance burden.
_________________
bwSecurity

Answer:
Now I have another question. Why is it that only certain user groups are being picked up when I run my report. I have users in certain groups according to location and user type. For just the regular end users, it is not picking up that user group. Is this maintained in a separate table when running the RSUSR008 report?

Answer:
The report is reading the groups in USR02-CLASS to group the users in the output. The regular users without group should also be listed?

Answer:
ARRRRGGGH This is driving me crazy

Still having a problem. All my users are in a user group, one or another, but the report is only chosing the same six out of twentyfive groups.

I need to know where to go to change the values for USR02-CLASS so that it will read all user groups. Or is this an ABAP thing? Or what do I have to do. I don't want to use the RSUSR002 program instead and have to add each critical tcode combo one at a time. That would really suck.

Answer:
ARRRRGGGH This is driving me crazy

... add each critical tcode combo one at a time. That would really suck.

I am not having the same problem here in 46C or 47.



Maybe, the users are not appearing on the list outputs because they don't have the SOD conflict you have configured to search for?



Answer:
I would suspect your rules you are using for the report and not the user groups of the IDs. You can change the user groups in SU01 or SU10. I would not be surprised if you end up with the same users as a results of your report even after you change the user groups.