UST04 table — User to Authorization Profile Assignment Table

One row in UST04 represents the assignment of one authorization profile to one user in one client. In the classic (pre-role) authorization concept this table was maintained directly through profile assignment in SU01 or SU02/SU03. In a role-based system it is populated indirectly: when a role is generated and assigned to a user through PFCG, the generated profile name for that role is written into UST04 for every user assigned to it. The table therefore mixes two origins of authorization: manually assigned single or composite profiles from older setups, and role-derived generated profiles from current setups. It is the table SU01 reads to show the 'Profiles' tab for a user, and it is the table most audit scripts scan when checking who holds a given profile, including SAP_ALL.

The table is client-dependent, so MANDT must be part of every selection when working across systems or client copies. For a single-user question, restrict on BNAME first; that is highly selective and returns a short list even in large systems. For a single-profile question, such as who holds SAP_ALL, restrict on PROFN; this can still return a large result set because generated profiles from broadly assigned roles create many rows. Never scan UST04 without at least one of these two restrictions, particularly in systems with a large number of PFCG roles, since every role generation writes rows here in addition to the role assignment itself in AGR_USERS.

Symptom: a user appears to have access that no currently assigned role explains. Select UST04 for that BNAME and list every PROFN. Then select AGR_USERS for the same UNAME and list the generated profile names tied to currently assigned roles. Any PROFN present in UST04 but absent from that list is either a legacy manual profile assignment or a stale generated profile left behind after a role was removed without a user master comparison being run.

The table structure and its role in the authorization concept carry into S/4HANA unchanged. It is still written whenever a PFCG role is generated and assigned, and it remains the correct place to check the raw profile-to-user link. In practice most consultants work from AGR_USERS and the role assignment first, since role-based authorization is the standard model in S/4HANA, and only drop down to UST04 when a profile-level discrepancy needs to be confirmed directly.

This is a security and GRC team question, not an application team one. The security administrator running SU01 and PFCG is the one whose actions write to this table, and any discrepancy found here should be resolved through role assignment and user comparison in those transactions, never through direct table maintenance.

AGR_USERS carries the role-to-user assignment that generates the UST04 rows for modern systems. UST12 holds the authorization object values inside a given profile. USR02 and USR04 hold the user master logon data and legacy authorization data respectively, useful for cross-checking user status. PFCG generates roles and their profiles; SU01 and SU10 assign roles and profiles to users and trigger the writes to this table.