rfc/callback_security_method

RFC callback is a mechanism the called server can initiate to the calling client during synchronous RFC calls. The opened RFC connection to the RFC client is used and it doesn’t require another user logon.

For this backward connection the predefined destination BACK is used which exists in all ABAP-based software systems. All RFC function modules that the calling user is authorized to execute in the calling RFC client can be executed by the called server through RFC callback mechanism. Asynchronous RFC, transactional RFC, queued RFC, and background RFC cannot establish RFC callback.

RFC callback white lists are maintained in transaction SM59 in systems based on SAP NetWeaver AS for ABAP 7.3 with enhancement package with SAP Note 1686632 The logged RFC callbacks stored in the security audit log are analyzed programmatically and RFC callback white lists are generated from the logs. The white list is then displayed in the “Logon & Security” tab of RFC destinations. SAP Note 2058946 explains the maintenance of RFC callback white lists in other systems in standard maintenance.

Main Steps of the Process ;

Master OSS Note ;

1686632 – Positive lists for RFC callback

SAP Profile Parameter ;

rfc/callback_security_method = 0 / 1/ 2/ 3

Transaction : RZ10

* Paramater is “Dynamic” so you can change it without SAP restart.

Transaction : RZ11

Value 0: Emergency mode (fallback).
- If the callback is prohibited by the preceding call of the function module RFC_CALLBACK_REJECTED, the callback is rejected. Otherwise, the callback is executed.
- All whitelist entries (including the active entries) for RFC callbacks are ignored.

Value 1: Compatibility mode (default):
- If the callback is prohibited by the preceding call of the function module RFC_CALLBACK_REJECTED, the callback is rejected.
- If the callback is prohibited by an active whitelist, it is rejected.
- In all other cases, the callback is permitted.
- Each permitted callback is logged in the security audit log with a “non-critical” (green) entry, while each rejected callback is logged with a “critical” (red) entry.

Value 2: Simulation mode:
- If the callback is prohibited by the preceding call of the function module RFC_CALLBACK_REJECTED, the callback is rejected.
- If the callback is prohibited by an active whitelist, it is rejected.
- In all other cases, the callback is permitted.
- Each rejected callback is logged with a “critical” (red) entry with the message ID “DUJ” in the security audit log. Each permitted callback, which would be rejected if the whitelist is activated, is also logged with a “critical” (red) entry with the message ID “DUK” in the security audit log. All other permitted callbacks are logged with a “non-critical” (green) entry with the message ID “DUI“.

Value 3: Most secure mode:
- If the callback is prohibited by the preceding call of the function module RFC_CALLBACK_REJECTED, the callback is rejected.
- If the callback is prohibited by an active or inactive whitelist, it is rejected. (Note that, in this mode, an inactive whitelist is equally as effective as an active whitelist.)
- In all other cases, the callback is permitted.
- Each rejected callback is logged with a “critical” (red) entry with the message ID “DUJ” in the security audit log. Each permitted callback is logged with a “non-critical” (green) entry with the message ID “DUI“

Callback log settings can be configured via transaction code SM19 like shown below ;

After some time (better to wait at least one week) to SM19 collects some data, then we can ready to “Generate of RFC Connections” via SM59 transaction code

SM59 –> Generate of RFC Connections