Recently I wrote an article for a magazine published by the German-language SAP users’ group (DSAG).
In this post, I’d like to share an English translation with you (the original German version used to be available here: http://blaupause.dsag.de/berechtigungstrace-mit-komfort-funktion).
Here we go:
Authorization trace with comfort function:
One of the numerous new features of Enhancement Package 6 is the authorization trace via transaction STAUTHTRACE. In principle, it works like the system trace ST01, but is limited to authorization checks. This makes it a valuable tool for authorization admins and provides comfortable functions.
So far, it was necessary to start an authorization trace on all application servers of a system separately, unless the relevant server was known beforehand. Transaction STAUTHTRACE simplifies this and allows starting a trace on one or more servers in a single step:
Without an explicit selection, the system-wide trace is automatically started on all available servers:
The evaluation section in the lower half of the screen offers detailed options to analyze the result and is much advanced in comparison to ST01.
In a system-wide trace, the selection of the application server in the topmost section is also taken into account.
The option “Evaluate Extended Passport” is extremely handy, as it enriches the trace result with data from the system’s kernel statistics (transaction STAD).
This additional information is helpful when it comes to RFC calls from other systems and consists of the following fields:
- “Initial Component” — the calling system, instance and client
- “Action Type” — e.g. a batch job run or a transaction call
- “Initial Action” — e.g. the name of the job or transaction code
The result is finally displayed in a nice, filterable ALV grid and not in that ugly ST01 list view.
Additionally, it is possible to dive into each line and jump to the affected user, the authorization object and its documentation as well as the line in the source code that triggered the authorization check. Simply double-click in the list or use the menu:
How to use the trace result in PFCG
The result of an authorization trace can be used in PFCG directly now – no matter, whether it comes from STAUTHTRACE or the traditional ST01.
This can be achieved in two ways:
- Maintenance via the role menu
The “Import from Trace” option in a role’s “Menu” tab allows importing the called applications from the trace: Transactions (S_TCODE), External- or Web-Services (S_SERVICE) and RFC Function Modules (S_RFC).
Unfortunately, if you import a transaction call, only the tcode is adopted from the trace – the other values that are checked during transaction start and execution are ignored; instead, the suggested values from SU24 are used.
- Maintenance of authorization values
In the role’s authorization data maintenance screen, the new button “Trace” can be used to import the values that were checked from the result into the role.
In the below example, the role already contains the object S_USER_GRP – but no values yet. The actual check in this case used 02 for the field ACTVT and the user group (CLASS) was “SUPER” – these values can easily be imported from the trace data with some clicks.
💡 The new trace functionality of EhP 6 is a great feature for the analysis of authorization needs and problems – a neat enhancement of the existing toolbox!
I am curious, if using the STAUTHTRACE trace result in PFCG, does it import only error code 4 in the trace results….? We have minimum required permissions policy; I would not want any auth checks inserted in the role, unless they were RC4.
Can we exclude RC12? And also exclude the successful auth checks those are RC0.
We are only interested in the return code 4.
Wondering if you know the answer!
you have 2 options:
1. When you insert the trace result via the role menu, PFCG only imports the transaction codes and no authorization values. This is not what you want!
2. When you insert the trace into the role profile, you can choose which authorization values you want to transfer from the trace to your role for each object individually. The RC is listed (but no filtering takes place) and you can choose the relevant entries yourself. Unfortunately, you can only take over authorization values for existing objects – so you have to add the objects beforehand…
Kind regards, Daniel