Suddenly, a user can no longer work properly in the SAP system. And of course – allegedly – missing authorizations are to blame. We will show you how to quickly and reliably analyze whether and which authorization errors are really present.
User XY writes an excited ticket: He can no longer perform his tasks in the SAP system. Until now, this has ALWAYS worked. For first-level support, it was clear: This must be due to authorizations, and the ticket ends up with you. But how do you find out whether the user really lacks authorizations or whether the error lies somewhere else entirely?
Change documents for the user
Let’s assume that you know the user name and in which system and client the error occurs (if not, please ask for this information first). In this case, call the user in the affected system/client via transaction SU01. Go to the “Info” tab at the top of the system menu and click on “Change documents for users”.
In the following screen you can define more precisely which changes you want to see. In the upper area you enter – if known – the time period in which the change probably took place. In our example case, where the user claims that everything worked until today, you could limit the time period here to today. To take into account any changes made by background jobs that came in after the end of the working day, you should also include changes since yesterday to be on the safe side. You can also search for changes made by a specific user. This is not very useful in our example. But if, for example, you only want to see changes made by background jobs, you could narrow down to technical users here.
In the lower part of the screen, you select the content for which you want to see change documents. In our case, for example, select “Roles/Profiles”. Put a check mark here for “Roles”. Theoretically, you could enter role names here, but since we only want to know if any roles have been revoked since yesterday, leave the field empty. If you run the search, the system will show you if and which roles have been removed (or added) to the user.
If the table remains empty, you can run the same analysis again with a larger time period and see if there have been any changes at all recently. If this is also unsuccessful, you need to check whether one or more of the roles assigned to the user have been changed.
Change documents of the roles
If you already know which specific role is causing the error or if the user has very few roles, you can easily perform the analysis using transaction PFCG. Open the PFCG, go there in the menu to “Environment” and “Display changes”. You will then see a screen similar to the one for the change documents for the user. Here you can again limit the person who made the changes and the time period. Also, enter the role or roles you want to review here. Good to know: The role name is entered automatically if you have previously called up the role in the PFCG.
In the lower screen, select “Authorization data”. This opens a field at the end of the list where you can enter authorization objects. This is useful if you already know which object is running on error and want to know when that was changed. If you don’t know that, just leave the field blank.
If you run the search now, the following table will show you which user made which changes to authorization objects that this role contains and when.
If this table also remains empty, you can assume that the problem has NOT occurred since today or that it is not an authorization problem. To analyze this in more detail, you need to look at the error in detail. Also, if the change documents show too many changes or you can’t narrow down which one might have caused the error, you need to dig deeper into the analysis.
SU53
To do this, the next step is to request a SU53 from the affected user. The SU53 is the authorization error log. Ask the user to execute the transaction that runs on error until he or she gets an error message again. Then he or she should run transaction SU53 and send you a screenshot of the table. Attention: it is important that the user sends a complete screenshot (especially in width), because while SU53 shows on the left whether an authorization check was successful or not and which object is affected, you can see on the far right which field values are checked, i.e. used.
Good to know: You can also call transaction SU53 for another user. However, this must be done promptly after the error has occurred. Then call SU53 in the same system/client in which the user is working, switch to the “foreign user” view in the menu ribbon via the icon with the two squares, enter the user name and then follow the steps described above.
Important: The SU53 is always only an excerpt, not a complete authorization log. It is therefore possible that the errors causing the problem do not appear in SU53 or that SU53, called up several times in succession, throws up different errors.
Authorization trace
If SU53 does not throw any (relevant) errors or you fix the problems from the analysis, but the user still cannot work again, it is time for an authorization trace. Find out about the different types of traces. In the vast majority of cases you will work with STAUTHTRACE.
Arrange an appointment with the user, where he should execute all steps again, which lead to the error message. Before he starts, call transaction STAUTHTRACE (in the same system and client), enter the user name of the user you want to trace and, if necessary, select whether you want to start a local or system-wide trace (=all system instances). Now let the user work. After the error occurs, stop the trace, enter the user in the lower part of the screen in the evaluation window and display the results.
The table now shows you all the authorization checks that the system ran for the user during the trace. Authorization checks that ran on errors are highlighted in red. These are relevant for you.
Important: The trace shows ALL (incorrect) authorization checks. This does not mean that all of them are relevant for the error that occurred. But you can narrow down the cause by looking at the objects that run on errors and filtering out the ones that come into question.
SUIM
If you have now found out which objects are probably relevant to fix the error, you have to find out in which roles these objects are installed.
To do this, call transaction SUIM. First check whether the user has roles in which these objects are installed. Very often the user does not lack the complete authorization, but only certain field values in the object.
To do this, call up the item “Roles according to complex selection criteria” in the SUIM under the item “Roles”. Enter the user name in the field “with valid assignment of” and enter the name of the object below under “Selection according to authorization values”. Attention: Don’t forget to press Enter to open the sub-dialog where you can additionally filter concrete field values. However, since we already know from the trace that the user does not have the relevant attributes, leave these fields blank for now and run the analysis.
Good to know: As long as you do not search for concrete proficiencies, you can use the corresponding field in the “Selection by profiles and authorization objects” area instead of the “Selection by authorization values” area.
The result will show you all the roles that contain the object you are looking for and are assigned to the user. Check whether one of these roles can be extended by the missing authorizations.
If these roles cannot be adjusted – for example, because they are only display roles, but you need to assign editing permissions – go back to the search screen and run the analysis without user assignment. Now you will see ALL roles that have the object you are looking for in this system/client. If you additionally now enter the field values that are checked according to the trace in the “Authorization Object” area, your search will be even more precise. Now you will see all roles that contain the concrete authorization you actually need. Check whether you can assign one of these roles to the user.
Tables
Usually, most of the authorization problems can be solved using the SU01, PFCG, SU53, STAUTHTRACE and SUIM transactions. But sometimes you need to dig deeper. For example, if the error occurs because an organizational level is not defined or not sufficiently defined. In this case tables often help (AGR_1252 for orb levels by roles for example). Feel free to take a look at our overview of the most important tables for authorizers to learn more.