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
Give the time frame you want to check from the security logs which we have configured via transaction SM19
Continue with “Generate and Activate Positive List” button to generate callback positive list
Continue the process
Now we can check the entires from the table RFCCBWHITELIST via transaction SE16
You can get the details of the list
on the SM59 transaction screen, we can check the details of the related RFC Connections like below for our case
Detail of the “CALLTP_Linux” RFC connection which comes from the generation process with SM19 logs
Detail of the “EU_SCRP_WN32″ RFC connection which comes from the generation process with SM19 logs
Finally we can increase the parameter “rfc/callback_security_method” from 2 to 3 to complete the process
“rfc/callback_security_method” parameter is dynamic , so we can change and activate the parameter without SAP restart
Don’t forget the change the parameter from DEFAULT profile via transaction code RZ10 to make permanent
Finally SM59 “RFC callback check secure” area is GREEN
RFC Callback Security is Activated…