Compare 2 users roles assignment

Question: Hi,

For some time, I looking for the right way to compare 2 users roles assignment. i.e. What roles is missing user FOO to have exactly the same roles as user BAR

bonus: What is the best way to assign all the roles of user FOO to user BAR. i.e. to have 2 users with the same roles.

Redge

Answer:
In tcode SUIM there is a report to compare users / roles and selected output.

The best way to make user BAR have the same access as user FOO is to have 1 (one) role with the access and assign it to each of them once in tcode SU01 and ensure that this is the only role they have.

That should work.

Tarr
_________________
Try Search
Else SAPNet
Otherwise It was designed not to work.
____________________

Answer:
redge76,
Unfortunately, the report in SUIM lists the comparison at the object level, which is a shame - after drilling in on objects that the report considers different you often find some combination of the same access, just organized from different authorizations. It's a real pain, truly.

I'm looking forward to SAP providing a standard report like you're describing, but in the meantime, we created a program to read in the AGR_USERS tables for a couple users, and lay out the role assignments side by side showing where the role assignment gaps are - it's been a timesaver.

Regards,
Vincent

Answer:
Yes that's the solution I just found and used. I took the output of a selection in AGR_USERS for my 2 users, exported in excel, filtered duplicate lines and copy/pasted the result in the profile of the user in SU01.

By the way, I had to copy/paste 57 roles in the profile of the user. But in SU01/roles you can't paste more than 10 (or so) roles at a time. You have to paste 10 lines, hit enter, paste another 10 lines, hit enter .... Is there a way to do this more easily

Redge

Answer:
Two absurd extremes.

1. Giving everyone one role is a fruitcake idea. No enterprise is so well organized that you can have a limited number of roles and only assign one role per person. In Greek mythology they have a story of Procrustes. He had an iron bed that he invited all his guests to sleep in. If they didn't fit he stretched them or cut of their legs as the situation demanded. One role per person is a Procrustean bed.

2. The other absurdity is so many roles per use that you can't compare it by inspection. This is truly bad role architecture.

Answer:
Procrustes wouldn't get too many contract opportunities either way - some clients despite any rational efforts would consider it Procrustean not allowing in their design to have significant levels of granularity in their security and that's what you face at many large organizations with multiple business unit/business line organizational structures, along with granular segregation of duties limitations.

Answer:
The simplest way to make one user to have the exact access as another is to change the configuration in SU01 to allow reference user ID to be of any type ( or cereate a Reference use for job 1 and assign the reference user to all job 1 users) and then enter the "just Like ID" in the reference user field in SU01. No report, no download, excel gymnastics, not cut-and-paste, and not really recommended but it is the simplest.

Answer:
Procrustes wouldn't get too many contract opportunities either way - some clients despite any rational efforts would consider it Procrustean not allowing in their design to have significant levels of granularity in their security and that's what you face at many large organizations with multiple business unit/business line organizational structures, along with granular segregation of duties limitations.

This is where good role design, good naming conventions, use of derived roles and discipline come into play. But it also requires security staff who can talk to auditors because they know controls not just SAP.

In my experience auditors are extremely this generalists. They are afraid of experts so if an expert can talk to them convincingly they will back down. But if the security department is a bunch of switch clickers who don't understand the applications the auditors win. They also win when the SAP management won't let the experts talk to them.

Answer:
Procrustes wouldn't get too many contract opportunities either way - some clients despite any rational efforts would consider it Procrustean not allowing in their design to have significant levels of granularity in their security and that's what you face at many large organizations with multiple business unit/business line organizational structures, along with granular segregation of duties limitations.

This is where good role design, good naming conventions, use of derived roles and discipline come into play. But it also requires security staff who can talk to auditors because they know controls not just SAP.

In my experience auditors are extremely this generalists. They are afraid of experts so if an expert can talk to them convincingly they will back down. But if the security department is a bunch of switch clickers who don't understand the applications the auditors win. They also win when the SAP management won't let the experts talk to them.

All hail the guest (except for the bit on derived roles...)!

Worst case scenario is security management are lazy &§$%"?ß´s and only know copy and paste (with limitations...) and PowerPoint "programming" and the security staff are denied access to information to actually make it happen in the system.

They are protecting their own incompetent +*/$%&´s.

The developers sometimes also have a stake in the pie.

Audiot

Answer:
Derived roles are great if you have even a half ounce of discipline regardless of what our esteemed Dr. Jarboe thinks.

Answer:
Derived roles are great if you have even a half ounce of discipline regardless of what our esteemed Dr. Jarboe thinks. It is not the developer's discipline in question it is those that follow... You may have a pation, inteligence, and discipline to understand what you are doing, it is the people that follow you and inherit a system that will not out live the developer... It also does not follow the Keep it simple rule...

Answer:
I agree.

John´s approach solves a root cause problem.

One of the symptoms of not addressing the "systems should outlive their creators" problem which develops over time, is that you have a complicated concept created by technically competent people who forever secure their jobs (they think), and you have technically incompetent management who are blocking change requests, upgrades and vacation leave requests and few other things aswell.
_________________

No comments:

topics