• Home
    Blog Home This is where you can find all the blog posts throughout the site.
  • Tags
    Tags Displays a list of tags that have been used in the blog.

Support Package Upgrade: How to Update SAP Authorization Roles, Part 2

  • Font size: Larger Smaller
  • Hits: 6987
  • 0 Comments
  • Print

The first part of this blog was published a few weeks ago. We talked about the steps needed to maintain your company's authorizations when you implement SAP support packages, and you need to replace T-Codes. This blog will continue on through the final steps.

iStock_000015527840XSmall.jpeg

Here’s a quick recap of the previous post: In certain SAP support package upgrades, some T-Codes get replaced with others. When this happens, and you need to replace T-Code A with T-Code B, some steps are required. The normal procedure goes like this:

1. Update user authorizations so they match the T-Code changes

1a. Identify who really used the old T-Codes
1b. Update user roles and authorizations according to actual usage

2. Update the relevant GRC rules and add the new T-Codes

Step 1a was described in detail in our former blog post: Part 1: Support Package Upgrade: How to Update SAP Authorization Roles. This blog will detail the additional required steps.

Step 1b: Update user roles and authorizations according to actual usage

You might think that the main task here is quite simple – just replace T-Code A with T-Code B in all authorization roles, and that’s it. Well, if you make sure to remember that there might be some changes in authorization objects too, this will do the trick, but it’s definitely not simple. You have to compare all the authorization objects that are used by T-Code A to the authorization objects that are used by T-Code B and see that they match. If not, when you take off T-Code A, you will have to replace the corresponding authorization objects of T-Code A with those in T-Code B as seen in the diagram below:Replace_TCode_in_Role_SAP_Authorizations.jpg

You can see that although some objects may remain the same (marked A2), some objects should be replaced (let’s hope that the authorization fields are at least the same), some objects are added for new functionality, and some are deleted. As we said, not a simple task at all.

However, there are two tricks that can make the task easier for you:

1. Having a matrix of “Who’s doing what” like the one that we presented in our former blog post: Identify who really used the old T-Codes. A matrix will allow you to focus only on the relevant users, which will often not be so many. Normally, the percentage of use is about 13%, so if 200 users have the ability to use T-Code A, in fact only 26 do use it.

2. Using Role Replacer. This is a tool in our SAP Authorizations Monitoring Suite that allows you to find the best alternative for a given role, based on certain criteria and requirements. I know that this requires you to have this tool in place, but this is really the quickest option. You can use the “Bulk replace” feature and finish the task in a fraction of the time that it will probably take manually.

Think we’re done? No, there’s another important step…

Step 2: Update the relevant GRC rules and add the new T-Codes

If your organization is obligated to GRC compliance, you’ll need to update your Segregation of Duties rules. These SoD rules are often managed through a dedicated tool – for example, ProfileTailor GRC or SAP GRC. Here, you have to find all the rules that contain T-Code A and replace it with T-Code B. Easy? Well, it depends how you've implemented the rules, but it will still be easier than the former step:

If your SoD rules are based on T-Codes – you’re safe. You just have to replace T-Code A with T-Code B in all the rules, and you’re done. If your SoD rules are based on groups of T-Codes, it will be even easier.

If your SoD rules include both T-Codes and Authorization Objects, then it’s similar to what we did in step 1b above. For the new T-Code B, you will have to see which authorization objects remain the same, which are changed and which are removed. It will be a bit less complicated though, as SoD rules don’t include all authorization objects, but only the most significant ones, like company codes and purchasing groups.

If you have included isolated authorization objects in your SoD rules – it will take some hard work to replace them. If this is the case, we advise you to refer to an SAP authorization consultant or contact us, and we’ll see how we can help you.

By the way, if you’re in the process of implementing SoD rules, don’t miss our most-read blog post about the concept of isolation: Making a separation between technical and business related authorization objects.

Done with steps 1 and 2? How did it go? Please share your experience with us in the comments below.

See how ProfileTailor Dynamics can help you put your authorizations in order.

Yoav Michaeli joined Xpandion in 2008 as a team leader, and in 2010 Mr. Michaeli began managing the entire Research & Development group of the company. Prior to joining Xpandion, Mr. Michaeli served in an elite technological unit of the Israeli Defense Forces as a team leader for various key military projects. Among other achievements, he was instrumental in pioneering the use of advanced .NET technologies for large scale distributed systems. Mr. Michaeli is an expert in programming, agile development, application security and specialized programming techniques.

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest 25/06/2017

Headquarters

+972-3-624-4245

157 Yigal Alon Street,

Tel Aviv 67443, Israel

info@xpandion.com

US Office

+1-800-707-5144

33 West 19th Street, New York,

NY 10011, USA

info.us@xpandion.com

India Office

+91-989-2546216

C 103, Akruti Orchid Park, Andheri-Kurla Road,

Andheri East, Mumbai, India

info@xpandion.com