SAP Library / Security & GRC / Cheat sheet
SAP Security & GRC cheat sheet
26 objects in 5 groups. Each links to its full reviewed page.
T-Codes9
- PFCGPFCG is the transaction used to build, maintain, and generate authorization roles in SAP. It combines a menu of transactions or Fiori apps, a set of authorization objects with maintained values, and organizational level restrictions into a generated profile, which is then assigned to users. Role definition, profile generation, and user assignment are three separate saves.
- SU01SU01 creates and maintains individual user master records: logon data, validity period, user type, roles and profiles, parameters, and address data. It is the single-user counterpart to SU10's mass maintenance. Most confusion around it comes from the gap between assigning a role on the Roles tab and that assignment actually becoming effective in the authorization buffer.
- SU53SU53 is used to show the most recent failed authorization check for the current user session. It is most useful immediately after an authorization error to identify the authorization object, field and attempted value. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SUIMSUIM is the entry point to a report tree, not a single report or table. It groups dozens of standard reports covering users, roles, profiles, authorizations, transactions, and change documents. Each sub-report queries different tables with different logic, so picking the wrong report by name alone is the most common cause of a wrong answer during an access review or audit.
- SU24SU24 maintains which authorization objects PFCG proposes for a transaction, and their default field values, stored in the customer tables USOBX_C and USOBT_C. It does not control the actual runtime AUTHORITY-CHECK in the ABAP code. Changing a check indicator in SU24 only changes what PFCG suggests for future role builds, not what the program actually checks at execution.
- STAUTHTRACESTAUTHTRACE records authorization checks for selected users and applications in more detail than a single SU53 result. Use it when complex Fiori, RFC, background, or multi-step processing fails authorization. Scope the trace narrowly, reproduce one failure, stop the trace, and interpret failed checks carefully because not every failed probe requires a new authorization.
- ST01ST01 is the general system trace transaction. Its Authorization Check component records every authority-check call made on the application server where the trace is active, showing the object, field values, and pass/fail result for each check, in sequence. It is the tool of choice when SU53 only shows the last failed check and the full chain of checks needs to be seen.
- SU25SU25 is the wizard that fills and reconciles the customer tables of authorization default values (check indicators and field proposals) against the SAP-delivered tables, first at initial system setup and again after every upgrade. It is not where individual transaction checks are edited day to day; that is SU24. Skipping it after an upgrade leaves new SAP authorization checks invisible to existing PFCG roles.
- STRUSTSTRUST is used to manage PSEs, certificates and trust chains used by SAP HTTPS, SSL and secure communication. It is most useful when TLS handshakes fail, certificates expire, or a new certificate authority/server certificate must be trusted. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
Authorization Objects8
- S_TCODES_TCODE is the authorization object that controls whether a user is allowed to start a given transaction code at all. It has a single field, TCD, holding the transaction code value. Passing S_TCODE only clears the door to enter the transaction screen; it says nothing about whether the user can display, change, or post anything once inside, which is the single most common source of confusion around this object.
- S_RFCS_RFC controls whether a user is allowed to execute an RFC-enabled function module from outside the calling program's own session, checked on the target system at the moment the call arrives. The critical structural fact: the check is granted at the function group level, never at the individual function module level, so one open group exposes every function module inside it.
- S_TABU_DISS_TABU_DIS controls display and change access to tables through generic maintenance transactions such as SM30, SM31 and SE16 edit mode, based on the authorization group assigned to the table rather than the table name itself. A failed check almost always means the user lacks the group tied to that specific table, not that the table is locked or missing.
- S_TABU_NAMS_TABU_NAM controls access to generic table maintenance (SM30, SM31, and related dialogs) at the level of an individual table name, rather than through an authorization group. It exists mainly to grant access to specific tables that carry no meaningful authorization group, without resorting to broad group-based access that would expose many unrelated tables at once.
- S_DEVELOPS_DEVELOP controls access to ABAP Workbench objects such as programs, function modules, classes, and dictionary objects inside SE38, SE80, SE11, SE24 and SE37. The check is driven less by which transaction is used than by the authorization group (P_GROUP) and package (DEVCLASS) assigned to the object itself, which is why two objects of the same type can behave completely differently under the same role.
- S_PROGRAMS_PROGRAM restricts who can start, edit, or schedule an ABAP report, but only if that report has been assigned a program authorization group in its attributes. Reports with no group assigned bypass the check entirely, which is the main reason two seemingly identical programs behave differently under the same role.
- S_USER_AGRS_USER_AGR controls the act of assigning, changing or removing a role (activity group) on a user master record, typically inside PFCG's user assignment tab or SU01/SU10. It checks the role name against field AGR_NAME and the action against ACTVT (22 for assign). It says nothing about what the role itself contains — that is governed by separate objects.
- S_USER_AUTS_USER_AUT controls who can create, change, display or delete authorization data itself - the object, field and value combinations that sit inside a role or an old-style manual authorization - as distinct from who can assign roles or profiles to a user. It is a meta-authorization: it governs editing the building blocks of authorizations, not editing user master records.
Key Tables6
- AGR_1251AGR_1251 stores the field-level values maintained in a PFCG role's authorization tab, one or more rows per role, authorization object, and field, holding the LOW and HIGH bounds entered for that field. It reflects what was typed into the role before or after generation, not necessarily what is currently active in the user's generated profile.
- AGR_DEFINEAGR_DEFINE is the header table for PFCG roles (activity groups). One row represents one role's basic master record: its technical name, whether it is single, composite, or derived, and its link back to a parent role if derived. It does not store the authorization objects or the user assignments themselves; those live in AGR_1251 and AGR_USERS respectively.
- AGR_TCODESAGR_TCODES stores the transaction codes that have been added to a role's menu in PFCG. One row means one tcode is listed in one role, in one client. It does not mean the role's authorization actually lets a user run that tcode, and it does not mean any user has been assigned the role.
- AGR_USERSAGR_USERS stores the assignment of a role to a user, with a validity period given by FROM_DAT and TO_DAT. It is written whenever a security admin assigns a role in PFCG or through mass assignment in SU10. The table records only who is assigned to which role and for how long -- it holds no authorization values and no assignment history.
- USR02USR02 stores the authentication-relevant part of a user master record per client: the password hash, hash algorithm version, validity dates, user type, lock indicator, and last logon timestamp. It does not hold roles, profiles, address data, or personal details, which live in separate tables. It is the table to check for lockouts, expired validity, and last-logon evidence, never to edit directly.
- UST12UST12 stores the low/high value ranges for individual authorization fields inside manually built authorizations from the classic pre-profile-generator security concept (created via SU02/SU03). It is not where PFCG-generated role authorizations live; those sit in AGR_1251. UST12 survives in current systems mainly as a legacy table, and a non-empty result usually points to an old, hand-built profile still in production use.
Key Concepts2
- SU24 vs SU53 vs STAUTHTRACE: SAP Authorization TroubleshootingSU24 maintains authorization default/proposal data used when building PFCG roles; SU53 shows the current user's most recent failed authorization check in that session; STAUTHTRACE records authorization checks over a trace window with user/context detail. They solve different problems: role-design defaults, quick last-failure diagnosis and full runtime trace. A clean SU53 does not prove there was no authorization failure earlier in the process.
- PFCG Roles: Single, Composite and Derived RolesA PFCG single role contains menu content and authorization data/profiles; a composite role groups multiple single roles for assignment but does not carry its own authorization values; a derived role inherits menu/authorization structure from a master role while allowing organization-level values to differ. Role design should model job functions and organizational scope cleanly, not use composites or derived roles to hide uncontrolled authorization duplication.