Solved: Access Cleaning in SAP ECC6.0

Former Member · ‎02-28-2015

Hi Experts

I have one requirement where in for essentially every T-codes there is excessive access in SAP. Reason could be many but I am not bothered. My job is to clean such access and make it business specific. For this I have planned two stages:

1. Find out list of Inactive T-codes for last 6 months and block all such T codes. I have tried ST03N but not getting list of Tcodes by user activity, can you people please suggest any report, T codes, program which I can run to see list of not used T codes for last 6 months?

2. Ask Basis to revoke access from all active Tcodes and provide access to only users who are actually using it like for Purchase Tcodes ME21N, ME22N etc provide access only to Purchase and Finance team right now they have access to half the organization. This step depend on first step and I am not getting output in first step.

Please tell if this is correct or anyone of you has better approach then please suggest that, In case anyone of you has done similar exercise please tell me steps of that so that I can replicate for my work.

Regards

Aditya

Colleen · ‎03-06-2015

cleaning up security usually involves going back to basics. If you are finding yourself in this situation you are probably going to find role redesign/build necessary

This sort of cleanup involves understanding your user base. Quite often a large % of users are "base level" access. They might be there for HR and Payroll ESS/MSS or they might have some basic reporting and procurement access (like purchase requisition and goods receipting). In a lot of cases, you need to go back and talk to your Functional Experts and Process Owners to get their view of how business should operate.

I'd be started with reviewing the users and seeing what roles can actually be removed from them. Was there a heap of access creep over time and they have permissions they shouldn't have? Did they have an authorisation error and security solved it by adding an inappropriate role instead of performing role change? Never good when you find a System Support Role assigned to an end user as the Admin didn't understand provisioning rules.

After you clean up the bulk, break it down into groups of users. Focus on the Finance team first - get the Accounts Payable fixed and move onto the next group. It might involve building new roles or putting changes through.

If you think the transaction is not required at all but are not confident,then lock it in SM01. If a user rings up and complains you found out who uses it and can unlocked it straight away (bit of a cheeky solution and it's a follow up from It support who jokingly say 'if we don't know who's server it is, take it down and find out who complains'). From there you can then work with that user base to see who really should have that access.

So in short, break it down to smaller groups and work with your Functional/Process areas to determine what access the group of users should have. Do small bits at a time so you can manage impacts in Production and get it tested.

Also, look at the root cause as to why you found yourself in this situation and see how you can implement process and procedure to avoid it again.

Regards

Colleen

former_member200703 · ‎03-01-2015

Hi

Your approach looks interesting .. but may is suggest, why you do not pick to do such action by authorization matrix?.. meaning to design new rules and assign it to specific users..

Regards

Mahmoud El nady

Former Member · ‎03-04-2015

This message was moderated.

Former Member · ‎03-05-2015

What do you mean by "Ask basis to revoke access to all tcodes not used by the users"? What do you expect from the basis team who administrate the system to invoke such a change and how?

Cheers,

Julius

Colleen · ‎03-06-2015

cleaning up security usually involves going back to basics. If you are finding yourself in this situation you are probably going to find role redesign/build necessary

This sort of cleanup involves understanding your user base. Quite often a large % of users are "base level" access. They might be there for HR and Payroll ESS/MSS or they might have some basic reporting and procurement access (like purchase requisition and goods receipting). In a lot of cases, you need to go back and talk to your Functional Experts and Process Owners to get their view of how business should operate.

I'd be started with reviewing the users and seeing what roles can actually be removed from them. Was there a heap of access creep over time and they have permissions they shouldn't have? Did they have an authorisation error and security solved it by adding an inappropriate role instead of performing role change? Never good when you find a System Support Role assigned to an end user as the Admin didn't understand provisioning rules.

After you clean up the bulk, break it down into groups of users. Focus on the Finance team first - get the Accounts Payable fixed and move onto the next group. It might involve building new roles or putting changes through.

If you think the transaction is not required at all but are not confident,then lock it in SM01. If a user rings up and complains you found out who uses it and can unlocked it straight away (bit of a cheeky solution and it's a follow up from It support who jokingly say 'if we don't know who's server it is, take it down and find out who complains'). From there you can then work with that user base to see who really should have that access.

So in short, break it down to smaller groups and work with your Functional/Process areas to determine what access the group of users should have. Do small bits at a time so you can manage impacts in Production and get it tested.

Also, look at the root cause as to why you found yourself in this situation and see how you can implement process and procedure to avoid it again.

Regards

Colleen

Former Member · ‎03-06-2015

I doubt that the guru easily "found himself" in this dilemma. Usually the mess is old and passed on.

Best option as the first question to ask is when a system consolidation or upgrade is due, and combine the authorization redesign with that, as testing will happen anyway and if you get if right in SU24 then you have about 20 objects you need to be careful of x orgset groups + special requirements carved out of job roles.

You should not create a monster because of stubbornness. You can also mitigate roles themselves or accept risks. Eg. the owner of a company can partner with whom he wants, and complete all deals from A-Z with or without defrauding himself. His or her direct reports as well if they are active in SAP if they do it themselves. Otherwise clerks follow instructions 9 times out of 10 anyway...

-> Controls are more important than creating a "kaput" authorization concept and monster to administrate.

Cheers,

Julius

Colleen · ‎03-09-2015

Hi Julius

I doubt that the guru easily "found himself" in this dilemma. Usually the mess is old and passed on.

true found != caused

SU24 is definitely the best option if you can rely on it. From experience, I've "found" many organisations who get to this point of role mess have not been maintaining SU24 (SU25 never ran and they ignore the PFCG pop-up); roles have been downloaded from other systems and uploaded; manual/changed authorisations. Sometimes, starting again is easiest

Regards

Colleen

Former Member · ‎03-09-2015

Hi Julius

I have run SU24 on quality server and got following output as pasted below. Can you please tell me how to interpret this, I know it's blunt request for expertise at your level but its difficult for me to interpret this one and told same thing to client for sample T-codes. Awaiting your reply.

Former Member · ‎03-09-2015

Hey did you try SUIM for transaction codes under complex criteria.

Colleen · ‎03-10-2015

Hi Aditya

I have run SU24 on quality server and got following output as pasted below.

Why did you run it in QA? Normally, you run in DEV and transport the SU24 (which is a step in SU25) along with your roles?

What can't you interpret? Did you read the SU25 information/help first?

Regards

Colleen

Former Member · ‎03-10-2015

Hi Collen

I have run this on DEV server. I am interpreting this as - 'For T-code AS02 all the auth objects that are marked green are active. My doubt is how can I say to client that for AS02 these x,y,z, etc. objects are not required.

How can I get role level information so I can inform him that for T-code AS02 roles a,b,c etc. are not required.

Ultimately, I need to inform him of some way which he can replicate to revoke excessive access from almost all T-codes.

If I can tell for some sample ones, may be his team can repeat it for all active, important and conflicting T-codes

Regards

Aditya

Colleen · ‎03-10-2015

Hi Aditya

The green/grey status relates to the Check vs Do not Check

The proposal column of Yes mean it will be added to PFCG when important. The ones that count for impacts is the YES values (although some might need to be switched to NO and others on NO switched to YES).

In relation to answering your questions about whether needed or not - that is the challenge. Below is a very good blog by Otto Gold regarding SU24. If SAP consistently managed the SU24s then you can trust the values (mostly) and you'd have your list

Figuring out what proposals are necessary come back to reviewing the transaction (with some functional knowledge and general experience). The activity is not a repetitive tick and click but an analysis of the proposals to determine if they are valid.

For cleanup of SU24, I wrote a comment about Full Proposals, Partial Proposal and Empty Proposal in this thread. How you set this will depend on the transaction/authorisations and your roles.

To limit how much you have to work through - go to AGR_TCODES and extract all your customer roles. This will get you all of the transaction codes in scope for your solution. Hopefully, the number is not too high. You could then break them down to reports/display vs master data vs system transactions and attack them that way. Eventually, you will have to maintain and regenerate the impacted roles (which SU25 will help with).

Regards

Colleen