Using an RFC trusted/trusting relationship between two SAP systems has the effect that, in the case of an RFC from a trusted system to a trusting system, passwords are no longer sent for logging on to the trusting system. However, the user being used for the logon must have the corresponding authorization object S_RFCACL in the trusting system. The trusted system always corresponds to the RFC client role, and the trusting system to the RFC server role.
Solution
Building a trusted/trusting relationship:
A trusted/trusting relationship must always be built starting from the trusting system (server). The following describes the individual steps for defining a trusted/trusting relationship of the trusted system C00 (client) to trusting system S00 (server):
Log on to the trusting system S00 (server). Here, create a destination for the trusted system C00 (client) using transaction SM59 (for example, C00_SYSTEM). It is important that the option 'Trusted System' is not set to active for this destination (Security Option Trusted System = No).
We recommend that you do not specify any
logon data in this destination, as someone could use a remote login to misuse this
destination in SM59 by working as the user that is
defined here. This destination must only be used for creating and deleting the trusted/trusting relationship and not for any other purpose. It must therefore be named correspondingly.
Call transaction SMT1 (or SM59 and then transaction menu RFC ® Trusted Systems).
Choose Create. Enter the destination of the client system (in the example, C00_SYSTEM) in the dialog box. After confirming this, an RFC logon to the client system occurs, and the necessary information is exchanged between the systems (S00 <-> C00).
If no logon data has been entered in the destination
(in the example, C00_SYSTEM), an RFC logon screen is displayed for the
client system (C00). In this particular case, a manual logon must be
performed. In each case, a successful logon to the client system
must be performed in this step, so that the trusted
relationship can be built.
When a trusted relationship has been successfully built, the trusted entry for the client system (C00) is displayed. If you want to restrict the validity of the logon data for the client system, enter a timeframe in the corresponding field. The default value (00:00:00) means that the validity is unrestricted.
In the scenario where the same user and client are used, you can use the menu option Entry to perform authorization checks: These checks first attempt to reach the client using the logon data specified in the definition destination (in the example, C00_SYSTEM), and then try to log back on to the server system with the same logon data, using a trusted RFC. Choosing the menu option Current Server forces the return path to occur on the current application server, and choosing menu option Trusting System induces load balancing, meaning that the logon takes place on any application server in the server system.
If different users or clients are used for the trusted scenario, you must create an RFC destination on the client side, and perform an authorization check for the specified logon data, setting the flag for "Trusted System" to "Yes".
Using a Trusted/Trusting Relationship
You can now use the configured trusted/trusting relationship to create RFC destinations in the trusted system (client), which are for the trusting system (server), by using transaction SM59 and the ‘Trusted System’ flag. The result of this is that, when such destinations are used for the RFC logon to the trusting system, no password is sent.
A prerequisite for successfully using a trusted/trusting relationship is that the user being used has the corresponding authorization object S_RFCACL in the trusting server system. If you want to create a suitable authorization for different
clients and users, note that you have to enter the caller data (caller client and caller user) of the caller system (in our example from system C00) into the S_RFCACL fields RFC_CLIENT and RFC_USER. For example, if user U_1 under client M_1 in caller system C00 wants to work as user U_2 with client M_2 in the called system S00 under a trusted relationship, then the user (U_2, M_2) in the system S00 must have authorization ZRFCACL_XXX, which has the following settings:
RFC_SYSID : C00
RFC_CLIENT: M_1
RFC_USER : U_1
RFC_EQUSER: N (for NO)
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
The following steps describe how you can enter the above settings for server system S00:
SU03 + double-click the entry "AAAB" "Cross-Application Authorization Objects" and then choose "Authorization check for RFC user (ex. trusted system)" as the object class, then double-click the authorization object S_RFCACL and create Z_RFCACL_XXX.
After this, make sure you activate your settings.
If the same user is always used in the client system and server system for a trusted/trusting relationship (meaning that U_1 = U_2), the authorization Z_RFCACL_XXX can also be defined as follows:
· RFC_SYSID : C00
· RFC_CLIENT: M_1
· RFC_USER : ' '
· RFC_EQUSER: Y (for Yes)
· RFC_TCODE : *
· RFC_INFO : *
· ACTVT : 16
Setting the authorization field RFC_EQUSER to 'Y' is the same as setting the field RFC_USER = SY-UNAME for the logged user in the caller system (here, system C00).
Note that when maintaining and assigning S_RFCACL authorizations (in this case, Z_RFCACL_XXX), you must use as few generic values (for example '*') for RFC_SYSID, RFC_CLIENT and RFC_USER as possible. By doing this, those users who fulfill these criteria regarding RFC_CLIENT and RFC_USER, can call RFC modules from within the caller system, using the called user.
You must ensure that high security requirements in the caller system is linked with the usage of user maintenance transactions (such as SU01). If this is not the case, anyone who has this authorization can get a user and log on to the trusting system (S00).
After you have maintained the authorization Z_RFCACL_XXX, you must create an authorization profile as follows, and link it to the authorization Z_RFCACL_XXX:
Call SU02 and in the field "Manually edit authorization profiles", enter Z_
After this, make sure you activate the profile.
You now have to assign the authorization profile you have just created to the trusted/trusting user. To do this, enter the profile Z_
You can check the authorizations for the logged on users in the current system in advance, by using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.
As of Release 40B, for security reasons, the authorization profile SAP_ALL does not contain an authorization for S_RFCACL.
Authorization errors that occur while using an RFC destination which has the 'Trusted Systems' flag set to ‘Yes’ are documented with the following messages:
No authorization to log on as a trusted system (trusted RC = <0>).
Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:
0 Invalid logon data (user ID and client) for the trusting
system.
Solution: In the server system (trusting system), create the user
in the corresponding client.
1 Calling system is not a trusted system, or security
ID for the system is invalid.
Solution: Create (again) the trusted system (see above).
2 User has no authorization for the server system
(trusting system, for object S_RFCACL), or a logon was made
using one of the protected users DDIC or
SAP*.
Solution:
Provide the user with the corresponding authorization or avoid using the protected users DDIC and SAP*. Authorization errors that occur while using an RFC destination which has the ‘Trusted Systems’ flag set to ‘Yes’ are documented with the following messages:
No authorization to log on as trusted system
(Trusted RC = <0>).
Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:
0 Invalid logon data (user ID and client) for the trusting
system.
Solution: In the server system (trusting system), create the user
in the corresponding client.
1 Calling system is not a trusted system, or security
ID for the system is invalid.
Solution: Create (again) the trusted system (see above).
2 User has no authorization for the server system
(trusting system, for object S_RFCACL), or a logon was made
using one of the protected users DDIC or
SAP*.
Solution: Provide the user with the corresponding
authorization or avoid using the protected
users DDIC and SAP*.
3 Time stamp of the logon data is invalid.
Solution: Check the system time on the client host and server
host, as well as the validity date of the logon data.
(Note that the default date 00:00:00 means unrestricted
validity.)
Trusting Transaction SMT2
The trusting transaction SMT2 (or SM59 ® RFC ® Trusting Systems) constructs a list of all trusting systems that have been established for this trusted system. Here, a logon and authorization check for the current user and client is performed, using the destination TRUSTING_SYSTEM@S00 that has been automatically created.
This basically corresponds to transaction SM51, if you use Remote Login to perform a logon on a different application server.
If problems occur while setting the destination TRUSTING_SYSTEM@S00 (such as host name or service information), you either have to create a new destination for your needs, and then enter the host name or service information using SAP router strings, or adjust the network settings of the server. To correct the problem in transaction SMT2, you have to adjust the network configuration of the server. As this transaction is only to be used for test purposes, in this case you could also choose to ignore the error.
To perform a logon as a different user or client, you have to create a new RFC destination with a trusted option set.
In this scenario, the following error text in SMT2 can be ignored:
No authorization to log on as a trusted system (Trusted RC=0)
If the host name contains the character '_' (as in "my_host"), then the generation of the related trusting system destination may lead to incorrect settings. This problem can be corrected by implementing Support Package SAPKB46D09 (see below). For earlier releases, the changes required to correct the problem can be made manually.
No comments:
Post a Comment