Skip to content

RFC_NO_AUTHORITY

The calling user lacks authorization to execute the remote function module.

The user under whose credentials the RFC call runs does not have the S_RFC authorization object for the target function module or its function group.

Symptom

ST22 shows:

Runtime Errors         RFC_NO_AUTHORITY
Short text             No authorization to call function module "FUNCTION_NAME".

The "Variables in memory" section shows the function module name and function group that triggered the authorization failure.

Cause

Every RFC call is checked against the S_RFC authorization object, which has two fields:

Field Description
RFC_TYPE Object type: FUNC (function module), FUGR (function group), DEST (destination)
RFC_NAME The specific FM name, function group name, or * for all

Missing S_RFC authorization is common in:

  • Background jobs running under a service/background user with minimal roles.
  • RFC-enabled programs calling FMs across systems where the service user hasn't been granted access.
  • New function modules added to an existing system without updating roles.
  • PI/PO or middleware integration users that have limited auth profiles.

Fix

Step 1 — Identify the missing authorization from ST22

Open the dump. Note the function module name in the short text. The authorization check failure details are in "Active Calls" and "Variables in memory".

Step 2 — Check the user's current S_RFC authorizations

" Check programmatically — useful for debugging
AUTHORITY-CHECK OBJECT 'S_RFC'
  ID 'RFC_TYPE' FIELD 'FUGR'
  ID 'RFC_NAME' FIELD 'SYST'   " function group name
  ID 'ACTVT'    FIELD '16'.    " 16 = execute

IF sy-subrc <> 0.
  MESSAGE 'Missing S_RFC for SYST function group' TYPE 'E'.
ENDIF.

Step 3 — Add the authorization to the user's role

In PFCG, open the role assigned to the background/RFC user:

  1. Go to the Authorizations tab.
  2. Add authorization object S_RFC.
  3. Set RFC_TYPE = FUGR and RFC_NAME = <function group name>.
  4. Alternatively, set RFC_NAME = * for full access (use sparingly).
  5. Generate and save the profile. Re-assign the role to the user.

Granting RFC_NAME = * is a security risk

S_RFC with RFC_NAME = * allows calling any function module via RFC. For service users, always restrict to the specific function groups actually needed. Use transaction SUIM to audit who has broad S_RFC access.

Step 4 — For cross-system calls, check the destination user too

In SM59, the RFC destination has a logon user. That user needs S_RFC on the target system for the FMs being called there.

Prevention

  • When creating new RFC-enabled function modules, immediately update the relevant roles with S_RFC for the new function group.
  • Document which RFC user runs each integration scenario so auth gaps are caught during role reviews.
  • Test background jobs under the exact service user account (not your dialog user) before go-live.
  • Use SU53 after an authorization failure — it shows the last failed auth check details for a user.

See also

  • CALL_FUNCTION_REMOTE_ERROR — connection-level RFC failure (different from auth failure)
  • Transaction PFCG — role maintenance
  • Transaction SU53 — authorization check analysis
  • Transaction SUIM — user information system
  • Transaction SM59 — RFC destinations

Comments