Centralized Firefighter Stops Working After a RISE Migration: SAP KBA 2314735

A landscape where SAP GRC Access Control stays on premise while the managed ERP systems move to RISE with SAP produces a specific and confusing failure. Everything that GRC does over the RFC connector keeps working: Access Risk Analysis returns results, Access Request Management provisions, Process Control continuous control monitoring collects, and decentralized Firefighter (/GRCPI/GRIA_EAM) in the plugin system behaves normally. Only one thing stops: pressing Logon on the centralized Firefighter logon pad in GRAC_EAM. The Firefighter ID turns red and no session window opens.

Nothing in the GRC layer explains it, which is why these tickets tend to run for weeks through connector settings, user types, authorization objects and note lists. The cause is one layer down, and SAP documents it in KBA 2314735 — Remote Logon through an RFC Destination does not work.

What the failure looks like on both sides

The symptom is asymmetric, and that asymmetry is the first useful clue. On the GRC hub, the logon appears to succeed:

• The Firefighter session is created. GRAC_FFSESSION shows it, and the log synchronization pulls the change documents.
• The change documents on the Firefighter ID show the unlock and the password reset, so the server-side chain ran.
• The system log shows the hub creating its temporary RFC destination for the session and then deleting it again, which means the logon flow completed without raising an exception.
• ST22 is empty, SLG1 is empty, and there is no authorization failure in SU53 for either the Firefighter ID or the RFC user.

In the plugin system, at the same moment (mind the time-zone offset between the two systems when you compare), the system log shows the opposite: Transaction Canceled, message D01, under the Firefighter user, with no transaction code. The session was terminated at establishment, inside the logon program SAPMSYST.

That combination is the whole diagnosis in miniature. The hub considers the logon successful because SYSTEM_REMOTE_LOGIN returns sy-subrc 0 with an empty error message; no exception is raised, so the GRC logon program writes no error status and nothing lands in the application log. The GUI start against the temporary destination fails silently. Meanwhile the target cancelled the session it had begun to build, because it could not deliver a screen to anyone.

The test that takes GRC out of the discussion

Before touching a single GRC setting, reproduce the failure without GRC. In SM59 on the GRC hub, open the plugin destination and use the Remote Logon button.

• Connection test: successful.
• Remote Logon: nothing. No new window, no message, no dump.

That is the exact symptom of KBA 2314735, and it is worth getting on the record early: it reframes the problem from "Firefighter is broken" to "remote logon over this RFC destination is broken", which is a basis and network question rather than a GRC one. Centralized Firefighter logon is a remote logon. The GRC hub creates a temporary destination for the session and calls the remote logon against it; if SM59 Remote Logon does not work for the permanent destination, the temporary one has no chance either.

Maintaining a dialog user with a password in the destination and retrying Remote Logon is a reasonable extra proof point, and it fails in the same way. Silence on Remote Logon with a green connection test is not an authentication problem.

Why the rest of GRC keeps working

This is the part that makes the ticket circular if nobody states it explicitly.

What remains is the one thing only centralized Firefighter needs and nothing else in that list exercises: a connection opened from the target system back to the caller, carrying the SAP GUI screen.

The mechanism

A remote logon cannot use the RFC connection itself as a carrier for GUI data such as a logon screen. The target system therefore sets up a separate return connection to the calling system.

When the remote logon is initiated, the calling system sends its own IP address along with the logon request. The target system also resolves the caller's host name on its own. If those two values disagree, the target cannot open the return connection, the caller never receives the logon screen, and remote logon is not possible. KBA 2314735 illustrates it with two systems whose name resolution is not unique:

The caller announces 10.1.2.3. The target resolves abchost to 100.1.2.3, which is not the address it was given, and stops there. The same applies when the two systems are connected through SAProuter, where name resolution may be perfectly consistent and the target still cannot reach back to the caller directly.

A migration into a managed cloud tenant creates precisely this asymmetry. The GRC hub stays in the corporate network with its internal address; the plugin system now lives in the provider's network, reaches the corporate network through a gateway or peering, and resolves corporate host names through forwarders that may not resolve the hub at all. Nothing about the forward RFC path is affected, which is why every other GRC function is unharmed. We have seen the same behaviour on a second, unrelated managed tenant, while the non-migrated systems in the same landscape continued to work, so this is not a migration accident on one system.

The proper resolution, per the KBA, is to make the calling system's host name resolve to the same IP address in both systems. In a hybrid landscape that is often not achievable, which is what the workaround is for.

The fix: the loopback destination

Two steps, both in the target system, meaning the plugin system that has to open the return connection.

1. Instance profile parameter. Set rdisp/use_rfc_dest_lookup = ON in the instance profile of the target system's instances. The affected instances must be restarted, so this is a planned change, not an RZ11 switch you can back out in seconds.

2. Loopback destination. Create an additional RFC destination in the target system, named after the calling system and carrying the calling system's connection data throughout:

Two details in that table are where the workaround usually fails in practice:

• The gateway options are the caller's, and they are mandatory. The return connection is opened through the gateway of the calling system, so the gateway host and gateway service fields must be filled with the caller's host and sapgwNN. A loopback destination that has only the target host maintained, with the gateway fields left empty, looks plausible, tests successfully, and does not fix the logon. It is the single most common reason for "we created the destination and nothing changed".
• No logon data. The destination exists to describe a route back, not to log anyone on. If you maintain a user, you are building something else.

If SAProuter is involved, the router string is prefixed to both the target host and the gateway host.

Run the connection test on the loopback destination. Once it is successful, the remote logon from the calling system to the target system should work, and with it the centralized Firefighter logon.

Verifying it before and after

Two niping checks tell you whether the route the loopback destination describes actually exists. SAP Note 500235 covers the tool.

From the target host, confirm the caller's gateway service is reachable:

niping -c -O -S sapgwNN -H <grc-hub-host>

From the caller host, confirm the address you maintained in the loopback destination resolves back to the caller's host name:

niping -v -H <ip-address-used-in-the-loopback>

Then work up the stack in order, because each step has a different owner: connection test on the loopback destination, SM59 Remote Logon on the plugin destination from the hub, and only then a Firefighter logon in GRAC_EAM. Testing only the last one wastes a change window when the first one was already wrong.

Doing this on a managed tenant

Both steps of the workaround are inside the SAP-managed system, so both are requests rather than tasks, and they land on a different team than the one holding the Firefighter ticket. A few things make that go faster.

• Ask for the parameter and the destination in one request, with the values. Name the parameter, state that an instance restart is required, and give the full field list for the destination: name, connection type 3, load balancing No, target host, instance number, gateway host, gateway service, no logon data.
• Expect the host file route to be refused. Maintaining the hub's host name in the tenant's /etc/hosts is normally rejected as not aligned with Enterprise Cloud Services standards. Since the hub's host name may not resolve in the tenant's DNS at all, maintaining the IP address directly in the loopback destination avoids the argument.
• Some diagnostics are not available to you. On a managed tenant, checks that expect operating-system access (running RSBDCOS0, for example, as note 2939988 suggests) may simply do nothing. That is a property of the tenant, not a second defect.
• Give the support teams the SM59 Remote Logon test, not the Firefighter symptom. A GRC-component ticket about Firefighter tends to stay in application support. The same failure described as remote logon over an RFC destination reaches the team that can actually change the parameter.

What it is not

Each of the following is a real cause of a Firefighter logon failure, and each one is worth ruling out properly. None of them produces a green connection test with a silent Remote Logon, and none of them can terminate a session inside SAPMSYST before any GRC plugin code has run.

Field lessons

• Prove it in SM59 first. A green connection test and a silent Remote Logon button is a two-minute test that changes who owns the problem. Do it before opening the ticket.
• A connection test proves the forward path only. It says nothing about whether the target can reach back to you, which is the half that GUI-bearing remote logon depends on.
• Read both system logs for the same instant. The hub reporting success while the target reports Transaction Canceled is the signature, and you only see it if you apply the time-zone offset and look at both.
• The parameter without the destination does nothing. Setting rdisp/use_rfc_dest_lookup = ON and retesting is a reasonable first move, and it will not change the symptom. That result is not evidence against the KBA.
• Maintain the gateway fields. A loopback destination without the caller's gateway host and gateway service will pass its connection test and still leave Firefighter broken.
• Put it in the migration test script. Centralized Firefighter is exercised by nobody until the day it is needed. Add "SM59 Remote Logon works from the GRC hub to every migrated plugin destination" to the cutover checklist, and the problem surfaces in testing rather than during the first production incident.

How MTC helps

We work on the unglamorous end of SAP GRC: making Emergency Access Management actually work across landscapes that are no longer uniform, where the GRC hub is on premise and the managed systems are not. That includes connector and RFC design across network boundaries, Firefighter troubleshooting in centralized and decentralized mode, and keeping the Firefighter log and review complete enough to stand up in an audit afterwards. On large GRC programmes we deliver alongside leading global audit, risk and technology consulting firms, with a senior, Switzerland-based team accountable for the security outcome.

Also read

• SAP Note 3318927: SP21 Firefighter Session Changes on GRCPINW V1100
• SAP Firefighter Role Design: Best Practices for Emergency Access
• SAP Cybersecurity: Hardening the SAP Platform, Not Just Access
• SAP GRC Access Control: What It Is and When You Need It

References

• KBA 2314735: Remote Logon through an RFC Destination does not work. The symptom, the cause and the loopback destination workaround.
• 1292082: RFC fails due to non-unique host name resolution.
• 555162: Asynchronous RFCs with dialog via SAP router.
• 500235: Network Diagnosis with NIPING.
• 2939988: FFID session does not start, target system host name or IP address incorrectly mapped in the network.
• 3380027: Firefighter login does not open a new screen or displays the error "No authorization to logon on to the target system".
• 3444624: Firefighter Session was closed without disconnecting the User Session.
• 3164899: Unnecessary S_USER_GRP authorization check (BC-SEC-USR-ADM).
• 1769547: "Plan version Current plan was set" during Firefighter Logon, one of the EAM issues that references KBA 2314735.
• 3495933: FAQ, Emergency Access Management Service Pack 21 and higher.

Frequently asked questions

Why does centralized Firefighter logon do nothing when the RFC connection test is successful?

Because a successful connection test only proves the forward path. Centralized Firefighter logon is a remote logon, and a remote logon cannot carry GUI data over the existing RFC connection: the target system opens a second, separate connection back to the calling system to deliver the logon screen. The caller sends its own IP address with the logon request, and the target resolves the caller host name itself. If the two do not match, which is normal when the two systems sit in different networks or behind NAT, the return connection cannot be established. The caller never receives a screen and the target cancels the session it had started. This is the scenario described in SAP KBA 2314735.

What is a SID@BACK@ RFC destination?

It is the loopback destination from the workaround in SAP KBA 2314735. In the target system you create an RFC destination of connection type 3 named after the calling system ID followed by @BACK@, for example G1P@BACK@ when the calling GRC system has system ID G1P. Its target host, instance number, gateway host and gateway service all point back at the calling system, and no logon data is maintained. With the instance profile parameter rdisp/use_rfc_dest_lookup set to ON, the target system uses that destination to open the return connection instead of relying on its own resolution of the caller host name.

Is rdisp/use_rfc_dest_lookup = ON enough to fix Firefighter remote logon?

No. The parameter only tells the target system to look for a loopback destination; on its own it changes nothing, and we saw exactly that in the field. The destination named after the calling system ID plus @BACK@ has to exist in the target system, and it has to be complete. A loopback destination with the target host maintained but the gateway host and gateway service left empty does not fix the problem either, because the return connection is opened through the gateway of the calling system.

Why does decentralized Firefighter work while centralized Firefighter fails?

Because only centralized Firefighter needs a remote logon. In decentralized mode the user logs on to the plugin system directly and the Firefighter session is established locally, so no return connection is required. In centralized mode the GRC hub builds a temporary RFC destination, calls the remote logon, and the plugin system has to open a connection back to the hub to deliver the SAP GUI session. Decentralized EAM working in the same system is therefore a useful signal: the plugin configuration, the Firefighter ID and its roles are fine, and the failure is in the return path.

How do you apply SAP KBA 2314735 when the plugin system runs on RISE with SAP?

Both steps live in the SAP-managed system, so both go through SAP. Request that rdisp/use_rfc_dest_lookup be set to ON in the instance profile of every instance of the tenant, with the instance restart that the change requires, and that the loopback destination named after your GRC system ID plus @BACK@ be created in SM59 with the target host, instance number, gateway host and gateway service of your GRC system. Maintaining the GRC host name in the tenant host file is usually refused as not aligned with Enterprise Cloud Services standards, which is why the loopback destination with an IP address is the practical route.