You can increase the security of your system landscape with the Trusted RFC concept (see Trusted Systems: Maintain Trust Relationships Between SAP Systems). This blog describes how Trusted RFC can be configured securely.
Some well-known impacts of insecure configuration are:
You find general recommendations about RFC Security including sound recommendations about Trusted RFC in the Whitepaper "Securing Remote Function Calls (RFC)" which you can find on the Support Portal at https://support.sap.com/securitywp.
Trusted systems (these are often infrastructure systems like the central GRC box, the SAP Solution Manager, the Central User Administration system, or the SAP Fiori Gateway) must have the same or higher security classification as trusting systems (which are typically business systems like ERP, or CRM).
The security classification concerning Trusted RFC deals mainly about user management (for transactions like SU01) and network management (for transactions like SM59). The trusted systems have to be managed at least on the same security level than the most critical trusting business systems!
Trust relationships should be reviewed regularly in all business-critical systems, and trust relationships must be removed if they do not conform to this rule.
The following picture, which is based on the presentation RFC Security v1.1 from 2004 respective the Teched 2012 session SIS264 Securing RFC, shows a Trusted-RFC call from one system A to another system B.
The principle is the same if system A calls same system A (on same client or different client).
This picture lists the security related areas which you have to configure correctly:
This blog gives advice to these areas mainly using the example of GRC Access Controls Emergency Access Management (and is therefore heavily based on corresponding note 1694657) and shows an outlook about the secure configuration of other applications which are using Trusted RFC: SAP Solution Manager, Central User Administration, and SAP Fiori. Use the GRC example as a common blueprint for all these applications, too.
Content:
GRC Access Controls Emergency Access Management
SAP Solution Manager
Central User Administration
SAP Fiori
Note 128447 - Trusted/trusting systems
Note 1498973 - Renewing trust relationships to a system
Note 1694657 - Setup of Trusted RFC in GRC Access Control EAM (= security note 2413716)
GRC Access Controls Emergency Access Management (EAM) nowadays uses Trusted RFC to perform a user switch from the personal Fire Fighters user who logs in first to an Emergency User (also known as Fire Fighter ID or FFID) which is used to perform the emergency activities.
During log-in, in order to switch the user account to the Fire Fighter ID, a new session is created which requires a RFC destination to call RFC enabled function module. This RFC destination has to be protected from misuse by implementing authorization checks.
To secure Trusted RFC for GRC Access Control EAM you should execute following configuration changes:
Related Links
You define the trust relationship using transaction SMT1. Depending on the different GRC scenarios different trust relationships are required:
(GRC AC 5.3 is out of maintenance, however, we still describe the required settings because of the similarity with GRC AC 10.x if run in decentral mode.)
These scenarios uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses the GRC fire fighter transaction to switch to the Fire Fighter ID in the same system and same client. Therefore every system requires a trust relationship to itself but not to any other system including the GRC box.
An explicit Trusted RFC definition is only required to establish trust between two different systems. Every systems trusts itself concerning Trusted RFC. Therefore it might had happened that you omitted Trusted RFC definitions in case of decentral firefighting. However, we strongly recommend defining explicit trust relationship in any case to document required trust relationships and to be able to activate the setting "use transaction code".
This scenario is based on the central GRC box: The Fire Fighter user logs into the central GRC box and uses the fire fighter transaction to switch to the Fire Fighter ID in the desired client of the business system. Therefore every system has to trust this central GRC box.
If you want to use fire fighter for the GRC box as well then you need a trust relationship for itself.
If you want to use both central and decentral firefighting then you have to configure both types of trust relationships.
Start transaction SMT1 and follow the process to define the trust relationship. Then navigate to the trust definition on tab "Systems whose calls are trusted", open the trust definition in change mode and activate the setting "use transaction code" for all required trust relationships on tab "Configuration".
Optional: If you have configured Secure Network Communication (SNC) to encrypt communication channels then you can activate the setting "SNC" on tab "Technical Settings", too.
Transaction SMT1:
Caution: You have to be careful if other applications are used in the system landscape, too, which typically make use of Trusted RFC. This could be the SAP Solution Manager or the Central User Management (CUA). If the trust relationship already exists with inactive setting "use transaction code" (or you create an explicit trust relationship replacing the implicit trust relationship for the same system) then you have to analyze and maybe adjust existing roles containing authorizations for authorization object S_RFCACL first. The reason for this is that users might need extended authorizations for field RFC_TCODE after activating the setting "use transaction code".
Use the User Information System, transaction SUIM, to search for roles which are assigned to users having authorizations for authorization object S_RFCACL. Use the report "Roles by complex selection criteria", activate the radio button for "Selection according to user assignment .. with valid assignment of", and provide the authorization object S_RFCACL.
You can use transaction SE16 for table AGR_1251 as well to find the roles. Use the selection OBJECT = S_RFCACL and FIELD = RFC_TCODE. (The disadvantage of using SE16 is that you get all roles but not only roles which are assigned to users.)
Check for every role which authorization value is defined for field RFC_TCODE "RFC transaction code": If you find concrete names for transactions or full authorizations (* value) then the role is already valid, but if you find empty values or symbolic values like ' ' (which is often used to fill empty fields) then you should change these values.
The next chapter describes which values are required for fire fighter roles. For all other roles you can enter full authorizations (* value) ensuring business continuity without reducing security: There is no difference concerning security between ignoring a field (if setting "use transaction code" is inactive) or providing full authorizations (if setting "use transaction code" is active).
Tip: to analyze which trust relationships have active or inactive settings for "use transaction code" you can use transaction SE16 for table RFCSYSACL, too. Inspect the field RFCTCDCHK which shows the activation status of this setting. (Currently, you have to run this analysis in every system. Unfortunately you cannot use the application Configuration Validation of the SAP Solution Manager yet to run a cross system validation within one step yet. The corresponding Target System RFCSYSACL in application Configuration Validation will be extended in SAP Solution Manager 7.2 SP 5.)
Additional activity: Ensure that the trust relationships have been renewed as described in note 1498973.
Execute report RS_SECURITY_TRUST_RELATIONS to check trust relationships. The report lists all trust relationships
For each trust relationship, the report specifies the security procedure used, either security procedure 1 (not recommended) with a red light or security procedure 2 (recommended) with a green light. The procedure-1 relationships to trusted systems (left list) can be deleted by double-clicking the delete icon in the "Delete" column. Procedure-1 relationships from systems that trust the current system, on the other hand, can be updated by running the report RS_UPDATE_TRUST_RELATIONS.
The required authorizations for authorization object S_RFCACL differ in the different GRC scenarios. Following rules should be followed in any case:
GRC AC 5.3
This scenario uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses transaction /VIRSA/VFAT to switch to the Fire Fighter ID in the same system and same client.
Usually the role /VIRSA/Z_VFAT_FIREFIGHTER is used for the Fire Fighter IDs. This role requires an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <local system id>
RFC_CLIENT = <local client>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = /VIRSA/VFAT
RFC_INFO = * (or local installation number)
ACTVT = 16
Caution: Different authorizations and therefore different roles are required in all systems and clients!
As Trusted RFC is used to perform the user switch it is not necessary anymore that the Fire Fighter ID has authorizations for user management. Therefore ensure that no authorization for authorization object S_USER_GRP for activities 02, 03, 05 and the Fire Fighter ID user group are present in the role anymore.
GRC AC 10.x decentral
This scenario uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses transaction /GRCPI/GRIA_EAM to switch to the FFID in the same system and same client.
Usually you copy role SAP_GRAC_SPM_FFID to role Z_SAP_GRC_SPM_FFID which you then assign to the FFIDs. The name of this role must be identical to the name which you have configured in the GRC box using the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name".
Usually you develop roles in customizing development systems and transport these roles to the other systems, however, with GRC 10x it's difficult to follow this pattern if you use emergency access management not only in PROD systems but in DEV, TEST and PROD systems. In this case three different roles are required, but you can only enter one role name into the customizing of GRC AC in the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name". In this case we suggest that you deactivate authorizations for S_RFCACL in this role and put the required authorizations for S_RFCACL into additional roles having the system id and the client in their names which then can be assigned to the FFIDs in all systems independently.
This role requires / these roles require an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <local system id>
RFC_CLIENT = <local client>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = /GRCPI/GRIA_EAM
RFC_INFO = * (or local installation number)
ACTVT = 16
Caution: Different authorizations and therefore different roles are required in all systems and clients!
Tip: Check for updates of note 2150269
GRC AC 10.x central
This scenario is based on the central GRC box: The Fire Fighter user logs into the central GRC box and uses transaction GRIA_EAM to switch to the FFID in the desired client of the business system. Instead of transaction GRAC_EAM, maybe the older transaction GRAC_SPM might be in use. Both transactions are identical.
Usually you copy role SAP_GRAC_SPM_FFID to role Z_SAP_GRC_SPM_FFID which you then assign to the FFIDs. The name of this role must be identical to the name which you have configured in the GRC box using the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name".
This role requires an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <system id of central GRC box>
RFC_CLIENT = <client of central GRC box>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = GRAC_EAM
RFC_INFO = * (or installation number of central GRC box)
ACTVT = 16
The same authorizations are required in all systems and client, therefore you can use the same role in all systems and clients.
GRC AC 10.x central and decentral
If you want to use both central and decentral firefighting then you have to add two authorizations for authorization object S_RFCACL to the corresponding role. Do not merge the combined values into one authorization but use two distinct authorization by adding authorization object S_RFCACL twice.
The RFC Destinations which are used for firefighting are supposed only to be used by Fire Fighters. To restrict usage of these RFC Destinations you can utilize authorization object S_ICF.
You use transaction SM59 to set a value for field "Authorization for Destination" on tab "Logon & Security" for all RFC Destinations related to fire fighting. Enter any value e.g. GRC_FF.
Usually you have copied role SAP_GRAC_SUPER_USER_MGMT_USER to Z_SAP_GRAC_SUPER_USER_MGMT_USER and assigned this role to the Fire Fighter users.
Add an authorization for authorization object S_ICF to this role. Do not enter full authorizations (* value) but enter the value DEST for the authorization field ICF_FIELD and enter the value, which you have chosen for "Authorization for Destination", for authorization field ICF_VALUE, e.g. GRC_FF.
Transaction SM59:
The FFIDs get called via Trusted RFC only, therefore these users do not need a password and should not have a password. Use transaction SU01 tab "Logon data" or transaction SU10 function "Change password" to deactivate the password of these users.
Use the User Information System, transaction SUIM, with report "List of users According to Logon Data and Password Change" to view the password status of all FFIDs.
Use the User Information System, transaction SUIM, to search for roles and users having authorizations for following authorization objects:
Strictly control assignment of these authorization objects. Only specific system administrators should have these authorizations.
The SAP factory roles SAP_GRAC_SPM_FFID and SAP_GRAC_SUPER_USER_MGMT_USER contain S_RFC with full authorizations (* value) on all fields. You should reduce this authorization.
Fire Fighter IDs, which get the role SAP_GRAC_SPM_FFID, are emergency users which have quite critical authorizations in any case and they are strongly secured if you follow the previous listed measures. We still recommend to restrict RFC authorizations to the minimum.
Fire Fighter users, who get the role SAP_GRAC_SUPER_USER_MGMT_USER, mainly need to invoke a new session for the Fire Fighter ID. There is no need to execute anything else remotely, therefore we strongly recommend to restrict RFC authorizations to the minimum.
Use transaction STAUTHTRACE (successor of transaction ST01) or STUSERTRACE (available as of SAP_BASIS 7.40 SP 14 or 7.50 SP 02 with Kernel 7.45 patch 112) to trace all required authorizations directly or use transaction STRFCTRACE to log called RFC functions which you then can add to an authorization for S_RFC.
You find more information about S_RFC in this blog: How to get RFC call traces to build authorizations for S_RFC for free!
Online Documentation - Superuser Management in GRC 10
Blog - Community Collaboration for GRC Blogs and Documents
Blog - Configure Emergency Access (EAM) in GRC 10
Blog - De-centralized EAM GRC 10.0
Blog - Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant
Security Guide – SAP GRC Access Control – Using SAP with Release 5.3
Trusted RFC is optional for the SAP Solution Manager, however, quite useful to enable single sign-on for administrators who start working in the SAP Solution Manager and jump with their own user account into managed systems to perform administrative tasks.
The SAP Solution Manager used the same-user option of Trusted RFC. Therefore you will work with authorization for S_RFCACL containing RFC_EQUSER = Y and RFC_USER = ' ' (dummy value; you can use a symbolic value like "sy-uname" as well).
Most likely you will not be able to provide a full list of calling transactions. You will either omit to activate the transaction flag in the Trusted RFC definition or you will grant authorizations for S_RFCACL containing RFC_TCODE = *.
If you run both scenarios, GRC FireFighter and SAP Solution Manager, together it's important that you manage authorizations for S_RFCACL separately in different roles ensuring that the authorizations for one scenario cannot influence the other. Take care about correct authorizations for fields RFC_SYSTEM, RFC_CLIENT (and RFC_INFO) to identify calling systems and ensure to have proper authorization values for all other fields.
As an example we describe some possible system landscapes:
In the pictures below, the large arrows show the trust relationship, the small red arrows show typical RFC calls of GRC FireFighter for different clients, and the small blue arrows show typical RFC calls of the SAP Solution Manager.
Keep in mind to define an explicit trust relationship on the GRC Box for itself to be able to activate the transaction flag.
Keep in mind to define an explicit trust relationship on all systems for itself to be able to activate the transaction flag.
Some well-known impacts of insecure configuration are:
- abuse functionality restricted to a particular user group
- read, modify or delete restricted data
You find general recommendations about RFC Security including sound recommendations about Trusted RFC in the Whitepaper "Securing Remote Function Calls (RFC)" which you can find on the Support Portal at https://support.sap.com/securitywp.
Trusted systems (these are often infrastructure systems like the central GRC box, the SAP Solution Manager, the Central User Administration system, or the SAP Fiori Gateway) must have the same or higher security classification as trusting systems (which are typically business systems like ERP, or CRM).
The security classification concerning Trusted RFC deals mainly about user management (for transactions like SU01) and network management (for transactions like SM59). The trusted systems have to be managed at least on the same security level than the most critical trusting business systems!
Trust relationships should be reviewed regularly in all business-critical systems, and trust relationships must be removed if they do not conform to this rule.
The following picture, which is based on the presentation RFC Security v1.1 from 2004 respective the Teched 2012 session SIS264 Securing RFC, shows a Trusted-RFC call from one system A to another system B.
The principle is the same if system A calls same system A (on same client or different client).
This picture lists the security related areas which you have to configure correctly:
- Explicit Trusted RFC definition
- Transaction flag of the Trusted RFC definition
- Authorization object S_RFCACL in the RFC server system
- Authorization object S_RFC in the RFC server system
- Authorization object S_ICF in the RFC client system
This blog gives advice to these areas mainly using the example of GRC Access Controls Emergency Access Management (and is therefore heavily based on corresponding note 1694657) and shows an outlook about the secure configuration of other applications which are using Trusted RFC: SAP Solution Manager, Central User Administration, and SAP Fiori. Use the GRC example as a common blueprint for all these applications, too.
Content:
GRC Access Controls Emergency Access Management
- Enhance the trust relationship to transmit the transaction code of the calling transaction (SMT1)
- Maintain authorizations for authorization object S_RFCACL in managed systems
- Adjust RFC destinations to utilize the authorization object S_ICF to secure the usage of RFC destina...
- Deactivate passwords of FFIDs
- Strictly control critical basis authorizations for managing trust relationships and RFC destinations
- Restrict authorizations for S_RFC including within SAP roles from GRC
SAP Solution Manager
- SAP Solution Manager and central FireFighter on different systems
- SAP Solution Manager and central FireFighter on the same systems
- SAP Solution Manager and decentral FireFighter on different systems
Central User Administration
SAP Fiori
Related Notes
Note 128447 - Trusted/trusting systems
Note 1498973 - Renewing trust relationships to a system
Note 1694657 - Setup of Trusted RFC in GRC Access Control EAM (= security note 2413716)
GRC Access Controls Emergency Access Management
GRC Access Controls Emergency Access Management (EAM) nowadays uses Trusted RFC to perform a user switch from the personal Fire Fighters user who logs in first to an Emergency User (also known as Fire Fighter ID or FFID) which is used to perform the emergency activities.
During log-in, in order to switch the user account to the Fire Fighter ID, a new session is created which requires a RFC destination to call RFC enabled function module. This RFC destination has to be protected from misuse by implementing authorization checks.
To secure Trusted RFC for GRC Access Control EAM you should execute following configuration changes:
- Enhance the trust relationship to transmit the transaction code of the calling transaction (SMT1)
- Maintain authorizations for authorization object S_RFCACL in managed systems
- Adjust RFC destinations to utilize the authorization object S_ICF to secure the usage of RFC destin...
- Deactivate passwords of FFIDs
- Strictly control critical basis authorizations for managing trust relationships and RFC destination...
- Restrict authorizations for S_RFC included in SAP roles from GRC
Related Links
1. Enhance the trust relationship to transmit the transaction code of the calling transaction (SMT1)
You define the trust relationship using transaction SMT1. Depending on the different GRC scenarios different trust relationships are required:
- GRC AC 5.3 and GRC AC 10.x decentral
(GRC AC 5.3 is out of maintenance, however, we still describe the required settings because of the similarity with GRC AC 10.x if run in decentral mode.)
These scenarios uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses the GRC fire fighter transaction to switch to the Fire Fighter ID in the same system and same client. Therefore every system requires a trust relationship to itself but not to any other system including the GRC box.
An explicit Trusted RFC definition is only required to establish trust between two different systems. Every systems trusts itself concerning Trusted RFC. Therefore it might had happened that you omitted Trusted RFC definitions in case of decentral firefighting. However, we strongly recommend defining explicit trust relationship in any case to document required trust relationships and to be able to activate the setting "use transaction code".
- GRC AC 10.x central
This scenario is based on the central GRC box: The Fire Fighter user logs into the central GRC box and uses the fire fighter transaction to switch to the Fire Fighter ID in the desired client of the business system. Therefore every system has to trust this central GRC box.
If you want to use fire fighter for the GRC box as well then you need a trust relationship for itself.
If you want to use both central and decentral firefighting then you have to configure both types of trust relationships.
Start transaction SMT1 and follow the process to define the trust relationship. Then navigate to the trust definition on tab "Systems whose calls are trusted", open the trust definition in change mode and activate the setting "use transaction code" for all required trust relationships on tab "Configuration".
Optional: If you have configured Secure Network Communication (SNC) to encrypt communication channels then you can activate the setting "SNC" on tab "Technical Settings", too.
Transaction SMT1:
Caution: You have to be careful if other applications are used in the system landscape, too, which typically make use of Trusted RFC. This could be the SAP Solution Manager or the Central User Management (CUA). If the trust relationship already exists with inactive setting "use transaction code" (or you create an explicit trust relationship replacing the implicit trust relationship for the same system) then you have to analyze and maybe adjust existing roles containing authorizations for authorization object S_RFCACL first. The reason for this is that users might need extended authorizations for field RFC_TCODE after activating the setting "use transaction code".
Use the User Information System, transaction SUIM, to search for roles which are assigned to users having authorizations for authorization object S_RFCACL. Use the report "Roles by complex selection criteria", activate the radio button for "Selection according to user assignment .. with valid assignment of", and provide the authorization object S_RFCACL.
You can use transaction SE16 for table AGR_1251 as well to find the roles. Use the selection OBJECT = S_RFCACL and FIELD = RFC_TCODE. (The disadvantage of using SE16 is that you get all roles but not only roles which are assigned to users.)
Check for every role which authorization value is defined for field RFC_TCODE "RFC transaction code": If you find concrete names for transactions or full authorizations (* value) then the role is already valid, but if you find empty values or symbolic values like ' ' (which is often used to fill empty fields) then you should change these values.
The next chapter describes which values are required for fire fighter roles. For all other roles you can enter full authorizations (* value) ensuring business continuity without reducing security: There is no difference concerning security between ignoring a field (if setting "use transaction code" is inactive) or providing full authorizations (if setting "use transaction code" is active).
Tip: to analyze which trust relationships have active or inactive settings for "use transaction code" you can use transaction SE16 for table RFCSYSACL, too. Inspect the field RFCTCDCHK which shows the activation status of this setting. (Currently, you have to run this analysis in every system. Unfortunately you cannot use the application Configuration Validation of the SAP Solution Manager yet to run a cross system validation within one step yet. The corresponding Target System RFCSYSACL in application Configuration Validation will be extended in SAP Solution Manager 7.2 SP 5.)
Additional activity: Ensure that the trust relationships have been renewed as described in note 1498973.
Execute report RS_SECURITY_TRUST_RELATIONS to check trust relationships. The report lists all trust relationships
- to systems trusted by the current system (first list, left of screen)
- from systems that trust the current system (second list, right of screen).
For each trust relationship, the report specifies the security procedure used, either security procedure 1 (not recommended) with a red light or security procedure 2 (recommended) with a green light. The procedure-1 relationships to trusted systems (left list) can be deleted by double-clicking the delete icon in the "Delete" column. Procedure-1 relationships from systems that trust the current system, on the other hand, can be updated by running the report RS_UPDATE_TRUST_RELATIONS.
2. Maintain authorizations for authorization object S_RFCACL in managed systems
The required authorizations for authorization object S_RFCACL differ in the different GRC scenarios. Following rules should be followed in any case:
- The authorization fields RFC_SYSID and RFC_CLIENT of authorization object S_RFCACL never should contain full authorization (* value). Ignore any piece of information or documentation from SAP or others which suggests to use full authorizations and adjust any role from SAP or created by you which contains full authorizations
Specific values which identify the trusted system should be used always.
- In case of central firefighting this is the system id and the client of the central GRC box which means that you can use the same role in all system and clients.
- In case of decentral firefighting this is the local system id and the local client. Therefore you require different authorizations in all systems and clients!
- If the list of Fire Fighter users is not too large and very stable then you can put this list of user IDs into field RFC_USER. However, it is acceptable to use full authorization (* value) for this field. A GRC Fire Fighter controller can add a new Fire Fighter user at any time – and in case of emergency there is no time to update and transport roles. Mitigation: Secure RFC destinations using S_ICF as described in following chapter.
- The field RFC_EQUSER should get the value N because the switch-user scenario of Trusted RFC is used but not the same-user scenario.
- A Fire Fighter always uses a specific transaction to switch to a Fire Fighter ID, therefore you can and should enter this transaction code into field RFC_TCODE. The different GRC scenarios work with different transactions, therefore enter the scenario specific transaction code into field RFC_TCODE. If you don’t specify the transaction code of the Fire Fighter Cockpit but full authorizations (* value), the destinations to call a new sessions with Fire Fighter ID privileges can be misused by anyone having access to SM59 and other functions having access for using RFC destinations. This may lead to an unwanted escalation of privileges.
- A prerequisite of securing Trusted RFC with the calling transaction code is that the transaction flag is activated in the Trusted RFC definition as described above.
- Be aware that this blocks connection attempts from all other calling transactions including the function "Utilities → Test → Authorization test" in transaction SM59 (but not the function "Utilities → Test → Connection test").
- The field RFC_INFO could be filled with the installation number of the calling system, however, it might be acceptable to use full authorization (* value) because the system id and the client is already checked.
- The field ACTVT only can take the value 16 = execute.
GRC AC 5.3
This scenario uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses transaction /VIRSA/VFAT to switch to the Fire Fighter ID in the same system and same client.
Usually the role /VIRSA/Z_VFAT_FIREFIGHTER is used for the Fire Fighter IDs. This role requires an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <local system id>
RFC_CLIENT = <local client>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = /VIRSA/VFAT
RFC_INFO = * (or local installation number)
ACTVT = 16
Caution: Different authorizations and therefore different roles are required in all systems and clients!
As Trusted RFC is used to perform the user switch it is not necessary anymore that the Fire Fighter ID has authorizations for user management. Therefore ensure that no authorization for authorization object S_USER_GRP for activities 02, 03, 05 and the Fire Fighter ID user group are present in the role anymore.
GRC AC 10.x decentral
This scenario uses local calls: The Fire Fighter user logs into desired client of the business system personally and uses transaction /GRCPI/GRIA_EAM to switch to the FFID in the same system and same client.
Usually you copy role SAP_GRAC_SPM_FFID to role Z_SAP_GRC_SPM_FFID which you then assign to the FFIDs. The name of this role must be identical to the name which you have configured in the GRC box using the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name".
Usually you develop roles in customizing development systems and transport these roles to the other systems, however, with GRC 10x it's difficult to follow this pattern if you use emergency access management not only in PROD systems but in DEV, TEST and PROD systems. In this case three different roles are required, but you can only enter one role name into the customizing of GRC AC in the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name". In this case we suggest that you deactivate authorizations for S_RFCACL in this role and put the required authorizations for S_RFCACL into additional roles having the system id and the client in their names which then can be assigned to the FFIDs in all systems independently.
This role requires / these roles require an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <local system id>
RFC_CLIENT = <local client>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = /GRCPI/GRIA_EAM
RFC_INFO = * (or local installation number)
ACTVT = 16
Caution: Different authorizations and therefore different roles are required in all systems and clients!
Tip: Check for updates of note 2150269
- This note offers an option to use the symbolic value SAME_SYSTEM as a value for authorization field RFC_SYSID. SAP plans to extend the solution introducing another symbolic value SAME_CLIENT for authorization field RFC_CLIENT. As soon as this extension is available for the SAP_BASIS release of your systems you do not need to create individual roles per system and client.
- Limitation: You will not get a symbolic value for authorization field RFC_INFO. Therefore you can only use this solution if you accept to enter full authorizations (* value) for this field RFC_INFO.
GRC AC 10.x central
This scenario is based on the central GRC box: The Fire Fighter user logs into the central GRC box and uses transaction GRIA_EAM to switch to the FFID in the desired client of the business system. Instead of transaction GRAC_EAM, maybe the older transaction GRAC_SPM might be in use. Both transactions are identical.
Usually you copy role SAP_GRAC_SPM_FFID to role Z_SAP_GRC_SPM_FFID which you then assign to the FFIDs. The name of this role must be identical to the name which you have configured in the GRC box using the Implementation Guide, transaction SPRO, in activity "Maintain Configuration Settings" in parameter 4010 "Firefighter ID role name".
This role requires an authorization for authorization object S_RFCACL with following field values:
RFC_SYSID = <system id of central GRC box>
RFC_CLIENT = <client of central GRC box>
RFC_USER = *
RFC_EQUSER = N
RFC_TCODE = GRAC_EAM
RFC_INFO = * (or installation number of central GRC box)
ACTVT = 16
The same authorizations are required in all systems and client, therefore you can use the same role in all systems and clients.
GRC AC 10.x central and decentral
If you want to use both central and decentral firefighting then you have to add two authorizations for authorization object S_RFCACL to the corresponding role. Do not merge the combined values into one authorization but use two distinct authorization by adding authorization object S_RFCACL twice.
3. Adjust RFC destinations to utilize the authorization object S_ICF to secure the usage of RFC destinations (SM59)
The RFC Destinations which are used for firefighting are supposed only to be used by Fire Fighters. To restrict usage of these RFC Destinations you can utilize authorization object S_ICF.
You use transaction SM59 to set a value for field "Authorization for Destination" on tab "Logon & Security" for all RFC Destinations related to fire fighting. Enter any value e.g. GRC_FF.
Usually you have copied role SAP_GRAC_SUPER_USER_MGMT_USER to Z_SAP_GRAC_SUPER_USER_MGMT_USER and assigned this role to the Fire Fighter users.
Add an authorization for authorization object S_ICF to this role. Do not enter full authorizations (* value) but enter the value DEST for the authorization field ICF_FIELD and enter the value, which you have chosen for "Authorization for Destination", for authorization field ICF_VALUE, e.g. GRC_FF.
Transaction SM59:
4. Deactivate passwords of FFIDs
The FFIDs get called via Trusted RFC only, therefore these users do not need a password and should not have a password. Use transaction SU01 tab "Logon data" or transaction SU10 function "Change password" to deactivate the password of these users.
Use the User Information System, transaction SUIM, with report "List of users According to Logon Data and Password Change" to view the password status of all FFIDs.
5. Strictly control critical basis authorizations for managing trust relationships and RFC destinations
Use the User Information System, transaction SUIM, to search for roles and users having authorizations for following authorization objects:
- S_RFC_ADM Administration for RFC Destination
This authorization object is used in transaction SM59 - S_RFC_TT Authorization Object for Trusted-Trusting System Definition
This authorization object is used in transaction SMT1
Strictly control assignment of these authorization objects. Only specific system administrators should have these authorizations.
6. Restrict authorizations for S_RFC included in SAP roles from GRC
The SAP factory roles SAP_GRAC_SPM_FFID and SAP_GRAC_SUPER_USER_MGMT_USER contain S_RFC with full authorizations (* value) on all fields. You should reduce this authorization.
Fire Fighter IDs, which get the role SAP_GRAC_SPM_FFID, are emergency users which have quite critical authorizations in any case and they are strongly secured if you follow the previous listed measures. We still recommend to restrict RFC authorizations to the minimum.
Fire Fighter users, who get the role SAP_GRAC_SUPER_USER_MGMT_USER, mainly need to invoke a new session for the Fire Fighter ID. There is no need to execute anything else remotely, therefore we strongly recommend to restrict RFC authorizations to the minimum.
Use transaction STAUTHTRACE (successor of transaction ST01) or STUSERTRACE (available as of SAP_BASIS 7.40 SP 14 or 7.50 SP 02 with Kernel 7.45 patch 112) to trace all required authorizations directly or use transaction STRFCTRACE to log called RFC functions which you then can add to an authorization for S_RFC.
You find more information about S_RFC in this blog: How to get RFC call traces to build authorizations for S_RFC for free!
Related Links
Online Documentation - Superuser Management in GRC 10
Blog - Community Collaboration for GRC Blogs and Documents
Blog - Configure Emergency Access (EAM) in GRC 10
Blog - De-centralized EAM GRC 10.0
Blog - Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant
Security Guide – SAP GRC Access Control – Using SAP with Release 5.3
SAP Solution Manager
Trusted RFC is optional for the SAP Solution Manager, however, quite useful to enable single sign-on for administrators who start working in the SAP Solution Manager and jump with their own user account into managed systems to perform administrative tasks.
The SAP Solution Manager used the same-user option of Trusted RFC. Therefore you will work with authorization for S_RFCACL containing RFC_EQUSER = Y and RFC_USER = ' ' (dummy value; you can use a symbolic value like "sy-uname" as well).
Most likely you will not be able to provide a full list of calling transactions. You will either omit to activate the transaction flag in the Trusted RFC definition or you will grant authorizations for S_RFCACL containing RFC_TCODE = *.
If you run both scenarios, GRC FireFighter and SAP Solution Manager, together it's important that you manage authorizations for S_RFCACL separately in different roles ensuring that the authorizations for one scenario cannot influence the other. Take care about correct authorizations for fields RFC_SYSTEM, RFC_CLIENT (and RFC_INFO) to identify calling systems and ensure to have proper authorization values for all other fields.
As an example we describe some possible system landscapes:
In the pictures below, the large arrows show the trust relationship, the small red arrows show typical RFC calls of GRC FireFighter for different clients, and the small blue arrows show typical RFC calls of the SAP Solution Manager.
1. SAP Solution Manager and central FireFighter on different systems
2. SAP Solution Manager and central FireFighter on the same systems
Keep in mind to define an explicit trust relationship on the GRC Box for itself to be able to activate the transaction flag.
3. SAP Solution Manager and decentral FireFighter on different systems
Keep in mind to define an explicit trust relationship on all systems for itself to be able to activate the transaction flag.
Central User Administration
The setup of Trusted RFC for the Central User Administration scenario is described in the Online Documentation.
With Trusted RFC you no longer need to enter the password of the powerful system users in the RFC destination for the RFC connection from the central to the child system - these system users do not need a password anymore and should not have one.
Two options are available:
- Trusted RFC with dedicated user
- Trusted RFC with same user
Both have specific advantages. Weigh which option is more useful for your system landscape, according to your security requirements as described in the Online Documentation.
For Trusted Systems, the authorization object S_RFCACL is also checked in child systems but such an authorization is not contained in any of the SAP standard roles which are available in the system, therefore you have to use your own roles.
Most likely you will not be able to provide a full list of calling transactions (it's not only SU01, SU10, PFCG, SUIM, etc.). You will either omit to activate the transaction flag in the Trusted RFC definition or you will grant authorizations for S_RFCACL containing RFC_TCODE = *.
In case of "Trusted RFC with dedicated user", when creating the RFC destination, you still specify a technical user but you can omit the password. This means that there is no longer any danger that the explicitly created system user can be misused via an unintended password logon, however, it's still potentially possible to misuse the defined RFC destination. Therefore we strongly recommend to secure these destinations using authorization object S_ICF.
You will work with authorizations for S_RFCACL containing RFC_EQUSER = N. If the group of user administrators is not too large and stable you can list them in authorization field RFC_USER to ensure that nobody else can invoke these technical users. However, this might be inconvenient and less fail-safe if the group of user administrators change often. In this case you have to work with RFC_USER = *. The additional risk which comes with this value gets mitigated by using authorization object S_ICF on the central system.
In case of "Trusted RFC with same user", when creating the RFC destination, you specify that the current user is used. The user of the user administrator is therefore used directly for the RFC connection. This means that there is no longer any danger that the authorizations of an explicitly created system user can be misused.
So that the CUA user administration user can access the user data of the child system by RFC, you must also create administration users in all of the child systems, to which you assign at least the roles SAP_BC_USR_CUA_SETUP_CLIENT and SAP_BC_USR_CUA_CLIENT. If the administrators are to be able to log on to the system directly and should be able work with transactions, you must also assign additional authorizations.
You will work with authorizations for S_RFCACL containing RFC_EQUSER = Y and RFC_USER = ' ' (dummy value; you can use a symbolic value like "sy-uname" as well).
The RFC destinations from the child systems to the central system are different: You cannot use Trusted Systems with the "current user" for data distribution from the child to the central system (redistribution with distribution parameters) as the end users could change their own user data with transaction SU3 and distribute it to the central system by redistribution. This would also mean that all end users would require change authorization for the user administration in the central system and could also change all other user data.
Although you could use Trusted Systems with an explicitly created system user for redistribution of data from the child to the central system, this brings little advantage. You would have to recreate the authorizations and the system users and expose these to misuse. You would also restrict the usage possibilities of the RFC destination to redistribution, meaning that no other application can use this destination.
We therefore recommend that you use "normal" RFC destinations for the RFC connection from the child to the central system.
Example system landscape:
SAP Fiori
Usually you use SAP Fiori on a dedicated SAP Gateway front-end system which connects via Trusted RFC to the backend systems. (At least on the SAP Solution Manager you can use the built-in Fiory subsystem as well. In this case no remote calls are used.)
All users who are using some of the Fiori based applications require a personal user with approbiate roles in the Fiori system as well as in the connected backend systems. The users login into the Fiory system and consume application services in the connected backend systems via Trusted-RFC with the same-user option. You find an overview about users and roles in the Online Documentation:
You can either setup the remote connection including the Trusted RFC definition manually using transactions SM59 and SMT1 or guided using transaction STC01 and the predefined task list SAP_SAP2GATEWAY_TRUSTED_CONFIG as described in the Online Documentation.
There is no standard role containing authorizations for S_RFCACL. You create one by yourself and assign it to all users in the backend systems.
You will work with authorizations for S_RFCACL containing RFC_EQUSER = Y and RFC_USER = ' ' (dummy value; you can use a symbolic value like "sy-uname" as well) as described in the Online Documentation.
The authorization fields RFC_SYSID, RFC_CLIENT and RFC_INFO should get the appropriate values which match to the Fiori front-end system.
Most likely you will not be able to provide a full list of calling transactions (if transactions are used at all). You will either omit to activate the transaction flag in the Trusted RFC definition or you will grant authorizations for S_RFCACL containing RFC_TCODE = *.
- SAP Managed Tags:
1 Comment
