Question:
We have nearly 2,000 users and 200 Plants and have about 12,000 old Composite Roles which are now converted into Roles in 4.6c. We are having some performance problems with Transactions pgcg so we have switched to using su01 / su10 and it is much better. The problem is that when we upgraded from 4.ob to 4.6c we assigned the new roles to the users. This was middle of last year. Users therefore have the old composite profiles and the corresponsing new roles. I started last week to clean up the user masters and remove the old composite profiles but have had to stop and reverse things as users were loosing access to some objects. It seems that the profiles converted okay to the new roles for the transactions but it has not given exactly the same access for all objects. What is the best way now to check that they match okay before removing the old ones. I need to do this as there are approx 25,00 old simple profiles that make up the 12,000 old composite ones and I need to remove these also from the system to improve performance. Any help would be appreciated.
Answer:
John A. Jarboe
Guest
Posted: Mon Apr 19, 2004 2:36 pm Post subject:
--------------------------------------------------------------------------------
It would be far easier to create a role for each user than proceed with your actions. 2000 users 12000 COMPOSITE roles??????????????????????????????? WHAT!? Something wrong with this picture....
A conversion does not ensure the new roles will work or that you have bleed through and more access than the user needs. After and upgrade of this sort you MUST open each role and "merge-old and new" and address the New and missing objects in the new version.
Without Org level limitaions you will need 85 to 125 base roles encompasing most all modules including Basis and Security. Corporate controls may require a few others based on their list of SOD's.
Easiest place to start is a list of tcodes and build roles from that.
If you are adept at ABAP you can create a ROLE MERGE utility to convert the roles on a user into a single role and delete all the duplicates. You will then need to analyse the results and adjust the roles and delete the identicle roles. and then analyse for SOD violations
THere is no SIMPLE answer except Keep it Simple.
Answer:
John,
If our Organisation insists ( as it does ) that all users can only see data for their Plant then does that mean that I still have to create somewhere between 85 to 125 Roles per Plant??? If yes then creating a Role per User would be much easier...only 2000 Roles
Answer:
No the 85 to 125 are all encompasing.
However, the base questions are "what is the risk?" , "what is the potential for the ocurrance?" and "How much does it cost to control?" I would suspect these questions were never asked and you are working off a Need-to-know basis rather then Cost-commensuarte-with-risk. Which you may find there is no need to control at the plant level...
But...
The all encompasing roles will be for FI-AR FI-AP, CO , PS, MM, BS, SC, CA, SD, PM.
While the organization WANTs to control on Plant SAP could care less for there is no PLANT control in FI, CO, PS, Parts of MM and PM.
Answer:
John,
Just for clarification. If the Organisation wants to control at Plant / Business Area level, how would I do this then if I do not control it in the roles
Answer:
You are limited to what is controllable by SAP based on the code and the imbedded authorization checks. There are a few configurable checks but basically you cannot control based on the companies whim. There are user exits where you can add custom checks but they may not be where you need them.
Answer:
Thanks for your help John