ST01 — System Trace for Authorization Checks

ST01 activates a kernel-level trace on the application server it is called from, and one of its selectable components is the authorization check trace. When active, every authority-check statement executed by any program running through that server (or, on later releases, that restricted to a specific user) is logged with the object checked, the field values passed, and whether it passed or failed. The structural fact that causes most confusion is that ST01 traces at the server/work process level, not globally across the system by default in older releases. A user working on a different application server, or a background job dispatched to a different instance, will produce nothing in a trace started on the wrong node. Consultants who forget this spend time convinced the trace is not working when it simply never saw the relevant session.

ST01 is reached for once SU53 has been ruled out or has proven inadequate. SU53 only shows the most recent failed authority-check for the logged-on user's current session, which is fine for a single dialog failure the user can reproduce immediately after it happens. It is useless for background jobs, RFC calls, batch input sessions, other users' sessions, or cases where several checks fail in sequence and only the last one is visible. ST01's authorization component is used in exactly those cases: reproduce the failing step while the trace is running, then read the full sequence of checks that were attempted, not just the final one. It is also used when a check unexpectedly passes with broader values than intended, which SU53 would never surface because SU53 only reports failures.

There is no SE16 table to query for a classic ST01 authorization trace; the output lives in the trace file and is only readable through ST01's analysis screen for the window in which the trace was active. To prove a symptom, filter the analysis output by the time range of the reproduction and, where the release supports it, by user ID, then look for the specific authorization object under investigation. If nothing appears at all for that user and window, the first thing to confirm is that the trace was active on the same application server the session actually ran on, not a different one in the logon group.

ST01 itself is unchanged conceptually on S/4HANA and remains available as the general system trace transaction. For authorization work specifically, the aggregated authorization trace transaction (commonly referenced as STAUTHTRACE) is the preferred tool on later releases, since it captures per-user over a longer window and writes into a form that feeds directly into SU24 check indicator proposals via SU25, avoiding ST01's server-scoped, short-lived file limitation. There is no Fiori app for this; it remains a backend technical trace used the same way it always was.

This sits with the security or authorization functional consultant for interpreting the trace and deciding on role or check indicator changes. Basis is needed to identify the correct application server or work process, manage disk space for trace files, and coordinate trace activation for background jobs. A clean handover states the exact reproduction timestamp, the server/instance name, the user ID, and the authorization object suspected of failing or over-permitting.

SU24 defines which authorization objects are even checked for a given transaction, so trace results are only meaningful once check indicators there are understood. SU25 is the tool used after a trace-driven finding to propagate corrected check indicator proposals across roles during an upgrade or cleanup. SU56 shows the authorization buffer for a user, which helps explain a trace entry that seems to be missing because it was served from buffer rather than freshly checked. PFCG is where the actual fix usually lands once a trace has identified a missing or excessive authorization.