SAP Authorization errors

A user gets "You are not authorized" (or a transaction/action is blocked) despite needing access.

Immediately after the failure, run SU53 (for that user) to see the failed authorization check, the authorization object and the values that were missing. For complex cases, use an authorization trace (STAUTHTRACE / ST01).

SU53 is the first tool and it is frequently misread, so it is worth knowing exactly what it shows.

It displays the last failed authorisation check for that user, in that session. Three things follow from that sentence.

It must be run immediately, because the next failure overwrites it. A user who carries on working for ten minutes and then runs it shows you a different problem.

It must be run as that user, or from an administrator screen selecting that user. Running it as yourself shows your own last failure, which is usually nothing.

It shows the object and the values requested, alongside what the user actually had. That comparison is the answer: activity 01 was requested, the user holds 03. The fix is a value, not a transaction.

The limitation worth knowing: some checks are made and handled by the program rather than producing a message, and some failures happen in a background task where SU53 has nothing to show. That is when a trace is needed instead, and STAUTHTRACE is the modern one, recording every check for a named user while it runs.

• Missing authorization object/value in the user’s roles.
• Role not assigned (or user comparison not run).
• Org-level restriction (e.g. wrong company code/plant).
• Profile not generated after a role change.

Two more that are easy to miss and account for a surprising share of cases. The role was changed but the profile was not regenerated, so the change exists in PFCG and not in the user's authorisations. And the assignment has not taken effect, because user buffers hold authorisations for the session, so a user who was granted access while logged in must log out and back in.

Twenty minutes, and it is the sequence that turns a vague complaint into a specific fix.

1. Get the user to reproduce it and stop, without doing anything else.
2. Run SU53 for that user. Read the object, the requested values and what they hold.
3. If the failure is on S_TCODE, they cannot reach the transaction at all: the transaction is missing from their roles.
4. If it is on any other object, they reached it and were refused an action. That is a value in an existing authorisation, not a missing transaction, and the two are fixed differently.
5. Check whether the value they need is in a role they have but with a different organisational level, such as the wrong company code. That is the most common shape.
6. If SU53 shows nothing, run STAUTHTRACE while they reproduce it, and read every check rather than the last one.

• Run SU53 to identify the missing object/values.
• Add the needed authorization to the appropriate role (PFCG).
• Regenerate the profile and update the user assignment.
• Have the user retry and confirm.

One caution on the fix itself. The fastest resolution is to add the missing value to whichever role the user has, and that quietly widens that role for everybody else who holds it. The correct fix is to decide whether this user should have this access, then change the role that represents their job, or assign a different role. Widening a shared role to unblock one person is how role creep happens, one justified change at a time.

Design roles for least privilege with the right org-level values, regenerate profiles after changes, and use SU24 defaults to reduce missing-authorization issues. Test roles with representative users before rollout.

The structural prevention is testing roles before they reach production. A role tested by its designer, who holds wide access, proves nothing. Testing means a test user holding only that role, running the job's actual transactions, which finds the missing values before a user does. See transport errors for the other common class of after-a-release failure.

Several failures produce the same message or a similar one, and treating them as authorisation problems wastes a good deal of time.

The transaction is locked. An administrator can lock a transaction system-wide, and the refusal reads like an access problem. SM01 shows it.

The user is locked or expired. Validity dates and administrator locks produce a logon failure rather than a transaction failure, and a user reporting "it says I am not authorised" may actually mean they could not log in at all.

The client is closed to changes. Configuration refused in production is client settings rather than roles, and no amount of authorisation will help.

The document is locked by another user. SM12 shows it, and the message is about the object rather than about access.

A gateway or RFC restriction. An external call refused at the gateway looks like an authorisation failure to the calling system, and the answer is in the gateway access control list.

The distinguishing question is whether SU53 shows anything at all. If a genuine authorisation check failed, it will. If it is empty and the user is definitely being refused, the cause is one of these.

Most authorisation failures in a working system are not a missing transaction. They are the right authorisation with the wrong organisational value, and recognising that shape saves the most time.

An authorisation object carries organisational fields alongside the activity: company code, plant, purchasing organisation, sales area, personnel area. A user who can display purchase orders for plant 1000 and is asked to display one for plant 2000 gets refused, and the message is identical to having no access at all.

This is why derived roles exist. A parent role holds the transactions and activities, and derived children vary only the organisational values, so one design serves twenty plants. When a user moves site or the business opens a new plant, the fix is a derived role rather than a new design.

The diagnostic tell is SU53 showing the object with values the user does hold, differing only in an organisational field. That is not a missing role, it is the wrong one, and adding the value to their existing role widens it for everyone else who has it.

The correct fix is usually assigning the derived role for the organisational unit they now need, which is why understanding the derivation design matters more than knowing the transaction.

• Guessing instead of reading the log/dump.
• Fixing the symptom, not the root cause.
• Changing several things at once.

• Running SU53 too late. It holds the last failure only, and by then it is somebody else's.
• Granting SAP_ALL to prove it is an authorisation problem. It proves it and it is now in the audit log, and it is often not removed.
• Fixing the symptom in a shared role. See RFC errors and gateway errors for failures that look like authorisation problems and are not.

Reading a failed check is the diagnostic half, and designing roles that pass the test before a user meets them is the part you do in the course.