Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Last failed check

10 min

Listen to this lesson

0:00 / 5:29

Transaction SU53, Display Authorization Check, is the first tool for any SAP GUI authorization failure. You can call it from the menu (System, then Utilities, then Display Authorization Check) or by entering /nSU53 in the command field right after the error. It can be run from any session of the user, not only the one where the error happened, which makes it easy for testers to capture.

What SU53 stores and for how long

Failed checks are kept in a ring buffer in the application server's shared memory. SAP's learning material describes the display as listing up to 100 failed checks per user from at most the last three hours, each with its context (the transaction, RFC function module or service that was running). The buffer size per application server is set by the profile parameter auth/su53_buffer_entries. Two practical consequences: capture SU53 promptly, and if Contoso's CMQ runs several application servers, the entry lives on the server where the failure happened.

SU53 data lives in each application server buffer, so capture it promptly and on the server where the failure happened.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203
ContextWhich transaction, app service or RFC function was running, and when.
Failed checkThe authorization object and the field values the program asked for, for example object F_BKPF_BUK with company code 1710 and activity 01.
User's authorizations for that objectWhat the user actually holds for the same object, and from which profile.
The gapThe difference between the two rows. That gap, not the whole object, is what a fix may add.
How to read SU53: context, required values, held values, then the gap.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203

Reading it properly

The upper part of the display shows what the program checked: the object, each field and the value requested. The lower part shows the user's authorizations for that object. Read them side by side. In SAP's own training example, the user held the object S_USER_GRP but not with activity 03 and the required user group. The fix was a value, not the object.

For Ana's invoice, SU53 might show that the program checked F_BKPF_BUK for company code 1710 with activity 01 (create), and that Ana's role grants the object for 1710 with activity 03 (display) only. The precise gap is activity 01 for 1710. A rushed fix would add activity * and company code *; the right fix adds only what the job design says Ana needs, and only if the design says she needs it.

Related displays

  • SU56 shows the authorizations currently in the user's buffer. After a role change, compare it with the role to confirm the user actually received the change (a new logon or user comparison may be needed).
  • The User Information System (SUIM) answers which roles contain a value and which users have a role, which is how Nadia finds the right role to change.
  • For Fiori failures, the browser shows a 403 for the OData call; SU53 for the same user usually shows the failed back-end check, and the SAP Gateway error log helps when the service itself is the problem.
After a role fix, SU56 confirms whether the change actually reached the user buffer before anyone retests.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203
  1. ReproduceThe tester repeats the step with the role-based user and notes the exact message.
  2. Capture SU53 at onceScreenshot or save the output with time, system CMQ and client 100.
  3. Identify the gapObject, field, requested value versus held value.
  4. Check the designIs the job supposed to do this? If not, the failure is correct behavior.
  5. Hand overAttach SU53 and the step to the defect for security.
Priya's standard for capturing an authorization defect from a test step.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203

What would you do?

Ana's SU53 shows a failed check on F_BKPF_BUK for company code 1810, activity 01, while she was posting an invoice in CMQ. Her role is designed for company code 1710 only. What is the right conclusion?

Key points
  • SU53 shows recent failed checks per user, with context, requested values and held values.
  • Capture it promptly: the buffer is limited in size and time and is held per application server.
  • Read the gap, field by field; the fix is usually a value, not a whole object.
  • A failed check can be correct behavior: compare it with the role design before changing anything.
  • When fixing one gap reveals another, or checks fall back to other objects, move to a trace.

Check your understanding · not graded

Lesson check

  1. 1. Where are the failed checks that SU53 displays kept?

  2. 2. SU53 shows object F_BKPF_BUK checked for company code 1710 with activity 01; the user holds 1710 with activity 03. What is the gap?

  3. 3. What does SU56 display?

  4. 4. Why might the failure in SU53 not be the check the designer intended?