ST01 and STAUTHTRACE transactions can be used for short term in-depth authorization traces. The problem is that these traces are very detailed and generate a lot of data.
For some use cases, you need to know what authorizations are needed for a user for longer period of time. Example: you have some background users with too many authorizations and your are tasked to reduce this. Then you want to enable a long term trace that records which authorizations are used by this user ID. You are not interested in how many times and when, but just need a complete list over a very long time (for example 2 months). Another example is when you are tasked to S_TABU_NAM full * authorization with actual table names. How to find out which tables are actually needed?
This is the goal of the STUSERTRACE: long term recording of authorization checks called including detailed table level.
STUSERTRACE enabling settings
The activation is described in OSS note 2220030 – STUSERTRACE: User trace for authorization checks. The first step is to switch parameter to value F. There is an option to set to Y for full, but don’t do this. F is the value where filtering happens.
As explained in OSS note 2220030 there is a minor performance impact. To limit the impact, use filtering.
Now start transaction STUSERTRACE to set the filters:
If you are in a customizing action and you want to see who did perform changes, select the menu Utilities and then option Change Log. Select date and time frame to analyze and press Execute. As example here changes to Plant Definition (table T001W):
By default a lot of SAP configuration and important setting tables have the log changes activated. But not all. It is not uncommon to activate table logging for standard SAP configuration tables important for your business. For important custom configuration Z tables you might want to activate table logging.
Table logging is not a replacement for change documents. Standard SAP generates change documents for changes to documents that must be kept for tracking and audit purposes. This is common for all major transnational objects and its underlying tables. That is why for example for an important table like VBAK (sales order header) the table logging is off: change documents are already generated.
It is very bad practice to make use of table logging for business data reasons. Table logging is used for recording changes to configuration and if all theses logs are deleted there should be no business impact.
If you are still using the old classic ST01 authorization trace, do keep on reading and you will want to switch to the new STAUTHTRACE improved authorization trace.
Questions that will be answered in this blog are:
How to run the new STAUTHTRACE tool?
What are the major improvements in STAUTHTRACE tool?
For long term user tracing there is a different tool: STUSERTRACE. Read more in this blog.
Running new STAUTHTRACE tool
To run the new tool start transaction STAUTHTRACE. If the transaction code is too complex, add it as favorite to your start screen.
From the start screen you see the immediate benefits. You can start the authorization trace for:
All application servers in one go (this is highly useful in an authorization issue with RFC users or background users where you have no control on which application server it will run): just record on all servers
Specific user only, but errors only: this will reduce your logging footprint to errors only
Filter the results to not show duplicate entries
Results
The result screen from STAUTHTRACE is similar to ST01 trace
But the result is more comprehensive, since it can take errors only, with duplicates filtered and take data from all application servers. This make the result complete and more easy to catch authorization issues.
