Troubleshooting Authorization Problems

Troubleshooting Authorization Problems

Use

The procedures described in this section are designed to help you analyze problems that arise in connection with authorizations.

Determining minimum authorization

You can use the following two procedures to determine which authorizations a user requires to carry out a transaction:

Set up authorizations for the relevant transaction and for the SU53 transaction for the user. Then call up the transaction and wait until the authorization check denies you access. Finally, use the SU53 transaction to see what type of authorization check was carried out. Add the missing authorization and repeat the process. This procedure is simple but can be fairly lengthy.
Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.


This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).

Analyzing an authorization problem that occurs for only one personnel number

Authorization problems that occur for a single personnel number are caused almost always by incorrect settings in the environment of the P_PERNR authorization object.

Authorization problems that are user-independent and occur for a single personnel number are caused almost always by a specialized organizational assignment (or even an incorrect organizational assignment). In this case, you should check the data of the Actions (0000) and Organizational Assignment (0001) infotypes and the relationships with the organizational structure (actively integrated systems) thoroughly.

Analyzing authorization problems in connection with locking and unlocking infotype records

Authorization problems that occur in connection with locking and unlocking infotype records are often caused by the CHECK_AUTH_SET_ENQ (SAPFP50M) form.

Localizing the cause of authorization problems after the import of HR Support Packages

The majority of code for the HR Master Data authorization check is localized in the CL_HRPAD00AUTH_CHECK_STD and CL_HRPAD00AUTH_CHECK_FAST classes, the SAPFP50P report, and the HRAC function group. You can also find smaller parts of code in the SAPDBPAP, SAPDBPNP, and SAPFP50M reports. If authorization problems are caused by HR Support Packages, a good place to start looking for changes to the code is in the above-mentioned classes and reports.

Useful questions for solving authorization problems

Over 90% of SAP’s incoming messages about authorization problems are consulting problems. What is more, in many cases customers are convinced that an error is causing their problems when in fact the problem is due to a misunderstanding of the functions of the corresponding protection mechanism. When analyzing authorization problems, it is therefore important that you can answer the following questions:

What data (which infotype/subtype) did the user access and how (using which transaction or which function of a transaction)?
How did the system react (did it incorrectly allow or deny access)?
How should the system have reacted (should it have allowed or denied the user access)?
Which authorization main switches are set up in the system?
How are the authorizations for the activated authorization checks set up?
Are the data records of the Organizational Assignment infotype (0001) as they should be for the personnel number in question?