S_RFCACL — Trusted RFC Logon Authorization

S_RFCACL governs whether a trusted RFC call arriving from another SAP system is accepted without re-authenticating the calling user with a password. It sits inside the trusted system relationship on the trusting system's side: once a source system is marked as trusted to call into a target system, this object decides whether the specific user, client and system asserting that trust is actually permitted to log on without credentials. The structural fact that causes most confusion: this is not the object that decides whether a function module may be called; that is S_RFC. S_RFCACL decides whether the trust itself is honored for that user before the call gets anywhere near a function group. A role can have every RFC authorization correct and still be rejected here because the trust relationship or the user mapping is missing at the connection level, not the function level.

The check fires during logon processing for an incoming RFC call that presents itself as trusted rather than authenticating with a stored password. It is evaluated by the kernel-level trusted RFC logic in the target (trusting) system, before the requested function module starts, and before any application-level authorization check such as S_RFC or S_TCODE is even reached. It is not attached to a particular transaction code or program in the usual sense: any RFC destination configured with the trusted flag, whether it drives a background job trigger, a system-to-system interface, a portal call, or a monitoring connection between landscape systems, goes through this check on every logon attempt. In landscapes where systems are chained together, one system calling another which in turn calls a third, each hop that relies on trust is evaluated independently against S_RFCACL on the receiving side, and a failure on one hop does not point at the others.

Start from the fact that trusted RFC failures often leave no normal SU53 trail, because the logon is rejected before a dialog user context exists; running SU53 as the calling user afterward frequently shows nothing relevant. Confirm the trust relationship is actually configured and active between the two systems before touching any role. If the relationship exists, run an authorization trace on the target system, filtered to the time window and, if possible, to the RFC_USER value, then repeat the failing call from the source side. The trace will show the S_RFCACL check with the exact values requested, system ID, client, user, activity, against what the buffered authorization actually holds. Hand the security team that exact combination, target system ID, client, calling system ID, RFC_USER value, and the expected RFC_EQUSER setting, rather than a screenshot of a generic connection error, since the fix usually involves either the trust configuration or a specific S_RFCACL entry, not a broad role change.

This is a security team object, not a functional one, because it governs system-to-system trust rather than any single application's authorization. A useful request states the calling system ID and client, the RFC_USER the interface runs as, and whether user names are expected to match across systems. Functional teams should confirm the interface's expected behavior, not attempt to author the S_RFCACL entry themselves.