RFC calls from work order management lose authentication context when calling remote function modules

ERP SAP S/4HANA
, , , , , , , ,
1

Our SAP S/4HANA 1909 work order management system makes RFC calls to remote function modules in a connected ERP system for equipment master data lookups. Authentication context is not propagating through RFC calls - all remote operations execute as a generic service user instead of the actual logged-in user.

This creates multiple issues:

  1. Work order synchronization failures when the service user lacks specific plant authorizations
  2. Audit trails showing all RFC operations under service user instead of real users
  3. Authorization checks on the remote system failing because user context is lost

Our RFC destination configuration:


RFC Destination: ZWORK_ORDER_REMOTE
Connection Type: 3 (ABAP Connection)
Logon & Security:
  User: RFC_SERVICE_USER
  Password: ********

The problem is we’re using a fixed service user in the RFC destination, so the remote system never sees the original user context. We’ve looked into SSO for RFC but haven’t found clear documentation on user context propagation for work order scenarios. How do we configure RFC destinations to propagate the interactive user’s authentication context rather than using a service user?

system 2

I’ve implemented user context propagation for work order RFC scenarios multiple times. Your issue involves all four key areas: RFC destination configuration, user context propagation, service user setup, and SSO for RFC. Here’s the complete solution:

1. RFC Destination Configuration for User Propagation: Reconfigure your RFC destination in transaction SM59 to support trusted RFC with user propagation:

Transaction SM59 → Create/Change RFC Destination:


RFC Destination: ZWORK_ORDER_REMOTE
Connection Type: 3 (ABAP Connection)
Technical Settings:
  Target Host: <remote_system_host>
  System Number: <remote_sys_number>

Logon & Security:
  Logon Procedure: Current User (NOT fixed user)
  Trusted System: ☑ Enabled
  User: <leave blank>
  Password: <leave blank>
  SNC Options: Enabled (if using SNC)

Critical: Setting “Current User” tells SAP to propagate the interactive user’s context through the RFC call, not use a fixed service user.

2. User Context Propagation Setup: Establish trusted system relationship between source and target systems.

On Source System (calling system): Transaction SMT1 → Create Trusted Relationship:


Trusted System: <TARGET_SID>
Client: <target_client>
Trust Type: RFC Trust
User: * (all users)

On Target System (receiving system): Transaction SMT2 → Display Trusting Systems:


Verify entry exists:
  Trusting System: <SOURCE_SID>
  Client: <source_client>
  Status: Active

Generate and exchange security tokens between systems. The target system must trust RFC calls from the source system.

3. Service User Setup (Fallback Pattern): For scenarios where user propagation isn’t possible or desirable, maintain a properly authorized service user:

Create service user on target system:


User: RFC_WORKORDER_SVC
Type: Service
Valid From: <current_date>
Valid To: <far_future_date>

Roles:
  Z_RFC_EQUIPMENT_READ (equipment master data)
  Z_RFC_WORKORDER_WRITE (work order operations)
  SAP_BC_RFC_METADATA_GET (RFC metadata)

Authorization objects for service user:

S_RFC: Function Group EQUIPMENT_*, Activity 16
I_EQUI: Equipment *, Activity 03 (Display)
I_IWERK: Plant * (or specific plants)
S_RFCACL: RFC Destination *, Activity 16

Implement hybrid RFC pattern:

" For read operations - use service user destination
CALL FUNCTION 'Z_GET_EQUIPMENT_MASTER'
  DESTINATION 'ZWORK_ORDER_REMOTE_SVC'
  EXPORTING
    iv_equipment = lv_equnr
  IMPORTING
    es_equipment = ls_equi.

" For write operations - use user propagation destination
CALL FUNCTION 'Z_CREATE_WORK_ORDER'
  DESTINATION 'ZWORK_ORDER_REMOTE'
  EXPORTING
    is_work_order = ls_workorder
  IMPORTING
    ev_order_number = lv_aufnr.

4. SSO for RFC Implementation: Implement Single Sign-On for RFC using SAP logon tickets:

Step 1: Certificate Configuration Transaction STRUST on both systems:


SSL Server Standard:
  - Import CA certificate
  - Generate system certificate
  - Add to ACL (Access Control List)
  - Export certificate for partner system

Step 2: Profile Parameters Set parameters on both systems:


# Source System
login/create_sso2_ticket = 1
login/accept_sso2_ticket = 1
login/ticket_expiration_time = 480 (8 hours)

# Target System
login/accept_sso2_ticket = 1
login/ticket_only = 0

Step 3: Trust Configuration Exchange certificates between systems and establish mutual trust.

5. Authorization Object Configuration: Configure S_RFCACL on both systems for user context propagation:

Source System - For calling users:

Authorization Object: S_RFCACL
  RFC_TYPE: Function Module
  RFC_NAME: Z_GET_EQUIPMENT_MASTER, Z_CREATE_WORK_ORDER
  ACTVT: 16 (Execute)

Target System - For propagated users:

Authorization Object: S_RFCACL
  RFC_TYPE: Function Group
  RFC_NAME: ZWORKORDER_*, EQUIPMENT_*
  ACTVT: 16 (Execute)

Users must have S_RFCACL authorization on BOTH systems, or RFC calls fail even with proper trust.

6. User Synchronization: Ensure users exist in both systems with identical user IDs:

Option A - Manual sync: Create matching users in both systems

Option B - CUA (Central User Administration): Automatic user synchronization

For CUA setup:


Transaction SCUA → Configure Central User Administration
  Central System: <source_system>
  Logical Systems: Add target system
  User Distribution: Enable automatic

7. Testing and Validation: Test user context propagation systematically:

" Test program for user propagation
REPORT z_test_rfc_user_propagation.

DATA: lv_remote_user TYPE sy-uname.

" Call remote function that returns executing user
CALL FUNCTION 'Z_GET_CURRENT_USER'
  DESTINATION 'ZWORK_ORDER_REMOTE'
  IMPORTING
    ev_user = lv_remote_user.

WRITE: / 'Local User:', sy-uname.
WRITE: / 'Remote User:', lv_remote_user.

IF sy-uname = lv_remote_user.
  WRITE: / 'SUCCESS: User context propagated'.
ELSE.
  WRITE: / 'FAILURE: User context lost'.
ENDIF.

Create function module Z_GET_CURRENT_USER on target system:

FUNCTION z_get_current_user.
  EXPORTING
    ev_user TYPE sy-uname.

  ev_user = sy-uname.
ENDFUNCTION.

Expected result: Local and remote users should match when using trusted RFC.

8. Troubleshooting Common Issues:

Issue: RFC call fails with “User not authorized” Solution: Check S_RFCACL authorization on target system

Issue: RFC executes as service user despite trust configuration Solution: Verify “Current User” selected in SM59, not fixed user

Issue: Trust relationship not working Solution: Regenerate trust in SMT1, verify certificates in STRUST

Issue: User doesn’t exist on target system Solution: Implement CUA or manually create matching user

9. Implementation Results: After implementing this configuration:

  • Work order RFC calls execute with propagated user context (not service user)
  • Authorization checks on remote system use actual user’s permissions
  • Audit trails show correct user for all RFC operations
  • Equipment master data lookups respect plant-level authorizations
  • Hybrid pattern allows flexibility: service user for reads, user propagation for writes

10. Security Best Practices:

  • Use trusted RFC with user propagation for write operations (audit critical)
  • Use service user for read-only operations (simpler, better performance)
  • Implement certificate-based trust, not just user/password
  • Set reasonable ticket expiration times (8-12 hours)
  • Monitor RFC calls via SM59 statistics
  • Regularly review S_RFCACL authorizations
  • Use CUA for multi-system user management

The key principle: RFC destination configuration and trust relationship setup must work together. Configuring “Current User” in SM59 enables user propagation, but it only works if trusted system relationships are properly established via SMT1/SMT2 and certificates are configured in STRUST. Service user setup provides a fallback for scenarios where user propagation isn’t feasible, but should be used selectively based on operation type and security requirements.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

You need to switch from user/password authentication to trusted RFC with SSO tickets. In SM59, change your RFC destination configuration:

Connection Type: 3 (ABAP)

Logon & Security:

  • Select “Current User” (not fixed user)
  • Enable “Trusted System” checkbox
  • Leave User and Password fields empty

Then establish trust relationship between systems using transaction SMT1. This allows user context to propagate through RFC calls automatically.

4

Before implementing trusted RFC, verify both systems support SSO. In transaction STRUST, check that both source and target systems have valid certificates in the SSL Server Standard PSE. Without proper certificate configuration, trusted RFC won’t work.

Also consider whether you really need user propagation for all RFC calls. For equipment master data lookups, a service user with broad read authorization might be simpler than managing user propagation. User propagation is critical for write operations and audit trails, but maybe not for read-only lookups.

5

Even with trusted RFC configured, you’ll need to ensure the remote system recognizes the propagated users. All users who make RFC calls must exist in both systems with identical user IDs (case-sensitive). If a user exists locally but not remotely, the RFC call will fail even with proper trust configuration.

Consider using CUA (Central User Administration) if you’re managing users across multiple SAP systems. This keeps user IDs synchronized and simplifies user context propagation.

6

For work order management specifically, user context propagation is important for authorization checks on equipment access. Different users have different plant authorizations, and those need to be respected on the remote system too.

However, I’ve seen implementations where they use a hybrid approach: service user for standard equipment lookups, but user propagation for write operations like creating or modifying work orders. This balances security with simplicity. You could configure two RFC destinations - one with service user for reads, one with user propagation for writes.

carol_master 7

Confirmed this resolves the authentication loss issue — reconfiguring SM59 with trusted RFC and user propagation eliminated the SY-UNAME reset we saw in remote function module calls.

8

Don’t forget about authorization object S_RFCACL on both systems. This controls which users can execute RFC calls and which function modules they can access remotely. Even with perfect trust configuration, if S_RFCACL isn’t set up correctly, RFC calls will fail.

On the calling system, users need S_RFCACL with RFC destination name. On the target system, users need S_RFCACL with function group authorization. This is often overlooked when implementing trusted RFC.