Introduction
There are various types of RFC scenarios, and when you look at them (if found) in an existing live system and want to secure them then it can seem a daunting technical and organizational task. However, if you tackle it systematically then it is a hard days work but not that difficult.
This wiki aims to document best practice approaches for securing RFC connections. It is essential that you have some basic understanding of RFC from a programming perspective and the difference between RFC servers (typically an SAP system in this context as the target of the RFC call) and RFC clients (which might also be another SAP server system acting as "caller", or an RFC SDK script on a user's client machine).
Please see the RFC / ICF Security Guide for official SAP documentation and further reading.
General comment: Please use the user type SYSTEM for all RFC scenarios and NOT the user type COMMUNICATION. Main reasons are that SYSTEM type users cannot change their own passwords at interactive logon-time (e.g. via http) and are not required to either by the password rules. They also cannot issue SAP Logon Tickets to remote http callers. They both are not SAPGui capable, but can logon via other protocols.
Additional general comment: You must go about this task very very carefully... and test what you have done and best is that you are not doing it for the first time on your own. If you disrupt business processes because of users who "supposedly" cannot logon to the system, then you will probably not have a second chance to secure your RFC security. Please be very carefull and read this wiki in detail and the links contained in it.
General Tips & Tricks for approaching a cleanup.
The most common root cause of not knowing what is going on in RFC and therefore having very limited chances of securing it stems from not respecting the cardinality of the connections. For example, user "ALEREMOTE" used in all RFC connections between various systems (including their DEV and QAS systems) with the same password in all is a design error. "Cardinality" means 1:1 user:connection relationships (if the "current user" option is not used). This problem is particularly accute if you use CUA or an IdM for "this" user which might have stored logon data in the secure stores of several client side systems, scripts, .ini files, hardcoded into programs, etc...
To go about fixing this, the following approach can be used:
- Collect information about existing RFC destinations in your system landscape from RFC server systems
- Download table RFCDES to Excel from each SID (it is client independent, like SM59 is as well...) to "take stock" of the current setup, document your progress later and changes made.
- You can either use SE16 to retrieve table RFCDES or you can use report RSRFCCHK with selection ‘Display all RFC destination’. Using the report has the advantage to get information about RFC destinations containing user credentials, too. Implementing SAP Note 1646124 from November 2011 you can check http destinations (type G), too, and you get an extended output list.
- Also consider the RFC Client Destination Profile of the Workload Statistics in transaction ST03N to start with analysis about activly used RFC destinations (see How to get RFC call traces to build authorizations for S_RFC for free!).
- Create RFC users in RFC client systems
- We have to distinguish between RFC authorizations for system users and dialog users. Dialog users require some RFC authorizations as well but for now let’s concentrate on system users.
- Create new SYSTEM type users first in the target client (using transaction SU01) with the same role and profile assignments than the existing RFC users like ALEREMOTE, etc. Use a naming convention which identifies the user ID according to where it is being called from. E.g. RFC_HCM_01 would exist in the FI system (created with transaction SU01) and be called from the HR system (using a RFC destination defined with transaction SM59).
- Use 8 character upper-case passwords if required, so that these users do not force the whole system to remain downwardly compatible. Generate the passwords using the SU01 wizard to make them cryptic (also see PRGN_CUST options).
- Use a naming convention for the new user's names so that you can later range SM19 audit log filters (E.g. RFC* - which is possible in higher releases via RZ10 profile parameter rsau/user_selection=1 - see SAP Note 574914) and assign them all to a secure user group. Create a new one for technical system users if required, so that you can later protect them and select them easily in reports.
- When your new target users are ready, then switch the RFC logon data in the calling systems (SM59) to the new dedicated ID and PWD and keep an eye on ST22 for dumps incase you got something wrong
- Monitor RFC calls in RFC client systems
- Monitor the RFC calls on the new users with the Security Audit Log dynamic filters in transaction SM19 to be able to build their role later. Make sure you only activate it for them and that your file size is sufficient.
- Also consider the RFC Server Profile of the Workload Statistics in transaction ST03N for the old users to start with analysis (see How to get RFC call traces to build authorizations for S_RFC for free!).
- Meanwhile, monitor the RFC logons of the old users with transaction/report RSUSR200 until they stop logging on. You need to give this at least a month's time before removing their access first (so that any callers still coming in will write an ST22 dump to alert you about the user still existing in a connection somewhere. Later you can lock them and "retire" them to a user group for the same. Do not delete them, as you might well need the ability to access change documents specific to them later (e.g. during an audit).
- Now if there are "dead" connections (you can see this via the password state in transaction/report RSUSR200) then you can start deleting obsolete RFC connections no longer needed. To double-check, you can also look at the last logon date of the ALEREMOTE user in that client, but it would not be reliable. You need to check this in each client and if you "test" or "use" the connection to access the client, then this will show up, also in the SM19 log. Misuse of the connections will be included as well... so take a carefull look through the RFC calls - you will get to know them quickly. A list of "naughty" RFC's is not the intention of this wiki and would be too long anyway..
- Connections from non-Production systems to Production systems should as a general rule not be allowed. For example ALE distribution models should be transported and not distributed from DEV via it's own ALE connections, or the transport system itself re-invented but without any security... You will have lots of interesting (and possibly "hot") discussions about this. Make sure you have all the steakholders are involved and some management clout to back you up when "the guilty ones" start complaining. Having a good technical developer who is security-conscious is very usefull as an authority as well. There will be exceptions to any general rule.
- Build roles for RFC users in RFC client systems
- Now you can start building the roles for the groups of RFC users. A "one-size-fits-all" role would defeat the purpose of the security hardening project, however they can be grouped. For examples of the possibilities to "group" the types of RFC, see the section below on Best Practices (per client).
- The most elegant way to build the roles is from the function module name taken from the SM19 audit log in Production, and build with these in DEV. Yes, there will be different requirements in DEV and even QAS (e.g. the ability to use external debugging of the RFC calls) but for this a special and separate role only for DEV can be added. Additionally, developers need to be aware that creating new functionality for existing connections which make new checks, require that the role to actually use the functionality need to be developed further alongside it. Possibly even a new destination and user for it will need to be setup. This is very important for the sustainability of the security setup, otherwise at the next shortdump SAP_ALL will be back.
- Via the menu tab of the role, you can insert the function module name as "Authorization Defaults" and pull the proposals from SU24 for them as you would do with transaction codes in a normal user role's menu. However these proposal indicators are seldom maintained, therefore you mainly will get the required S_RFC authorizations automatically. You can organize these “Authorization Defaults” in foldes to document why these function are added to the role.
- Also use the filters in SM20N to exclude the thousands of entries which will soon become like impalas in the Kruger National Park on the 3rd day of a 10 day safari...
In default delivered configuration (param auth/rfc_authority_check) you can also exclude RFC calls via *Internal Destinations* - typically 'NONE' which is invoked by using seperate "new tasks" for LUW and memory management. - Important is to keep an eye on S_TCODE (there should not be any for system users but you might finde few of them for dialog users) and the function group names (object S_RFC) and which calls are coming through. You will get to know them quickly and be able to spot rogues quite easily after a short while.
- Also note that as of release 7.02 respective 7.10 you can control the server side authorization at the function module name level using authorization object S_RFC with field RFC_TYPE='FUNC' (see Note 931251 for details).
- You can optionally also control the client side authority to call the destination (regardless of the function module name) using object S_ICF (see Controlling Access to RFC Destinations for details).
- You can optionally also control the access to select the SM59 data using S_RFC_ADM using the destination name of the connection itself.
- Use logical system names (defined with SM30 view V_TBDLS) of the clients (assigned to clients using SCC4).
- Trusted RFC is also a form of client user side security using server side authorizations of object S_RFCACL for the UID name of the caller. You should assume that the client side can control the user ID name, if you cannot control it...
- Of course all of the above is dependent on the config of the system, so it might work slightly differently if you have tweaked some settings - such as for example profile parameter rfc/reject_expired_password which can be used to force correct user types in the RFC destinations.
- Finally, you should do this starting in DEV and then move your way up the environments to production. As you go about it, you will learn a lot about the systems and integration between them and even business processes! Latest by the time you have restricted the QAS systems, you should contact the departments responsible for the systems and have them test the connections and let you know about any special cases (like payroll simulations, or interfaces which only run each 3 months, etc) which might provide for surprises.
- Please check ST22 regularly as you go about this and test changes. If you cause a big mess and the systems don't work properly or data is lost, or even deliveries and invoicing comes to a standstill.... then you will be very unlikely to have a second chance to touch an RFC connection again and there will be a lot of skeptics who are waiting in anticipation for exactly that to happen before they blow their trumpets...
Best practice of RFC types (per client)
To make the target system clearer for different use cases of RFC, please add a new client to the wiki when you want to document a best practice for a use case which differentiates itself from existing ones.
Client 000 - CCMS agents and trusted RFC.
Although the agents will push monitoring information to a Solution Manager, the administrators might want to be able to navigate easily to the component systems to fix a problem and back to the SolMan as well. For this, trusted RFC is usefull as only one destination with the "current user" flag set is needed in SM59 on the client side and carefull authority for object S_RFCACL on the server side. As someone able to change passwords of other users or maintain the SM59 connection to enter a specific user could gain access to the target system in a different user context, it is important that systems which trust each other for trusted RFC should have the same security status and even be auditable to each other.
For this a dedicated role containing only restrictive S_RFCACL authorizations is needed, which will be in addition to the already existing basis and application roles of the dialog user for whom remote navigation is now enabled. It is advisable to monitor use of this object in all roles. By default, it is not even included in SAP_ALL.
Client 100 - ALE and productive data.
Please see SAP Note 460089 for release dependent recommendations on the minimum requirements for ALE scenarios.
In this case it can be usefull to maintain SU24 for the function modules IDOC_INBOUND_ASYNCHRONOUS and IDOCTYPE_READ_COMPLETE so that you do not need to reinvent the wheel (and make different mistakes) each time. Some security recommendations are mention seperating the RFC communication user which recieved the IDOCS from the background user which processes them, however for a 20% effort : 80% security improvement this does not have to be included - the background processing will anyway do that which it is instructed to do.
Client 200 - CUA and client side security.
Central User Administration also uses RFC to send data to the child systems and read role information into the central system, etc. As the RFC SYSTEM type user needs to be equiped with user administration authorizations (see SAP Note [ 492589|https://service.sap.com/sap/support/notes/492589] ) and RFC connections will generally always be able to do that which you authorize them to do, it can make sense to use application authorizations to control who can even display or more importantly call that destination.
Read the Central User Administration - Cookbook first.
When an RFC client calls a function module via a destination with saved login data (SM59) the S_RFC object is checked on the RFC server side (application server) and performed against the user entered in SM59 (or the current calling user if none is entered). This will determine what the connection does. But who can invoke that communication? (e.g. the CUA).
Restricting access to SU01 etc is not sufficient, as the user might be able to execute the function modules directly from the workbench (see SAP Note 587410 ) or call it from an existing ABAP program or their own one, or even from another system which exposes the "target destination" and the "function name" to another RFC?
You can protect the ability to call the destination at all, or administrate it in SM59 or any of a number of... yes, function modules...by using the "authorization group" field in SM59's login and security tab. This is an optional grouping concept, which protects the selection of the destination via object S_RFC_ADM and protects it from being called by a user via object S_ICF. The administration of the connection uses the destination's technical name via object S_RFC_ADM and not the authorization group literal.
The downside of this, is that it is not scalable to large groups of users (for example to protect WORKFLOW destinations) but highly effective for special powerfull RFC connections.
Note: If an RFC user has SAP_ALL, then it can be used to administrate any connection data - including it's own - and remove this client side RFC protection again... So this is not an excuse to give the RFC user SAP_ALL!
Client 300 - Workflow and application authorizations.
This is a tricky case where only good documentation of implemented workflows and testing of them together with security can help.
For the basic authority required, please see SAP Note 1251255 . For the application authorizations which the workflow needs, this very much depends on the workflow used. There is no medication available for this, although a copy of a business user role can be a shortcut - remember to disable S_TCODE and S_RFC and add additional application objects as required.
Sorry folks, that's all for now...
Client "ICF" - Proxies and externally exposed services.
xxxx
Client "external" - External RFC server programs and TC/IP connections
xxx
Client "http" - Type G connections via RFC calls
xxx
Client "TMS" - The Transport Management System mechanism
xxx