Example of How to Create a Trusted Relationship

In the following, a trusted relationship will be created as an example between systems C00 (client system) and S00 (server system).
The example is shown for the simple case of the "Single Sign-On" procedure. This means that the user for whom the trusted relationship is created exists in both systems (C00 and S00) with the same client and the same user ID (as dialog user) (for example HUGO under client 100).
In the server system (S00), the user (HUGO in client 100) must have the authorization object S_RFCACL_DEV with the following settings:

• RFC_SYSID : C00

• RFC_CLIENT: 100

• RFC_USER :

• RFC_EQUSER: Yes

• RFC_TCODE : *

• RFC_INFO : *

• ACTVT : 16

Proceed as follows to maintain the trusted system:

• Log on to the server system (in this example: system S00 with user HUGO and client 100). Create a destination for the client system (C00) (for example, C00_SYSTEM) using transaction SM59. It is important that the Trusted System option is not active for this destination (Section Safety Option Trusted System = No). As logon data, enter user HUGO, client 100, and the corresponding password.
  
  Note: You should create a separate destination of type 3 (R/3 connection) for each trusted system (client system). If you have created a new destination and want to maintain it, read the section below entitled "Maintaining Destinations for 'Trusted/Trusting' Systems" as well.

• Call transaction SMT1 (from SM59 by following the menu path RFC → Trusted Systems).

• Choose Create. Enter the destination of the client system (in the example: C00_SYSTEM) in the dialog box. After you have pressed Enter, there will be an RFC message in the client system in order to exchange the necessary information between the systems (C00 <-> S00).
  
  Note: If no logon data has been entered in the destination (in the example: C00_SYSTEM), an RFC logon screen appears for the client system (C00). If this is the case, you have to log on manually. It is essential that you successfully log on to the client system in this step in order for the trusted relationship to be created. In our example, user HUGO and client 100 must be used to log on.
  

• When the trusted relationship is created successfully, a trusted entry for the client system (C00) is displayed.

• If you want to limit the validity period of the logon data for the client system, enter a time interval in the relevant field. The default value (00:00:00) means that the validity is unlimited.

• If you want to copy the transaction code of the calling program to the target system, select the relevant checkbox.
  An authorization check against field RFC_TCODE of the authorization object S_RFCACL is only performed if you copy the transaction code to the target system.

• Using the menu entry, you can perform authorization checks for the current server (trusting system).
  If there is no valid logon data for the destination (in the example: C00_SYSTEM), a logon screen for the client system appears. Log on to the system with user HUGO and client 100.
  
  Note: If the test has not run successfully, read also the section entitled "Troubleshooting in "Trusted/Trusting" Systems" further below.
  

Important Note

When you delete the Trusted System relationship, the logon screen for the respective system will appear - if no valid logon data for the destination exists. You must log on to the system; otherwise, the deletion process will be incomplete.

Maintaining Destinations for "Trusted/Trusting" Systems

You can maintain this type of destination from within the maintenance transaction for "Trusted/Trusting" systems for each system by clicking the pushbutton "Destination Maintenance".

The destinations for Trusting Systems are created automatically. These destinations are used in the transaction for Trusting Systems ( SMT2).

You should prevent changes being made to the destination by selecting the checkbox "Destination not changeable" under "Attributes".

You will find details on the individual fields through the field help.

Make sure that the destinations retain consistent data - that is, neither the target system ID, the system number, nor the destination name may be changed.

Displaying Trusting Systems

In a trusted system, you can display a list of all trusting systems.

When you create the list of trusting systems, a logon as well as an authorization check for the current user and client will be performed. This is similar to transaction SM51 when you perform a logon to a server by pressing the pushutton Remote Login. So that you can execute a logon under another user or a client, you need to maintain a respective RFC destionation using the trusted option for this purpose. The transaction SMT2 performs a trusted login for all current users and clients.

In the transaction for trusting systems (SMT2), click the name of a trusting system in order to display the application server of this ABAP system.

The names of the application servers of a trusting system contain the suffix _TRUSTED (that is, in the form <hostname> <br>_< systemid>_<systemnumber>_TRUSTED).

By double-clicking the name of an application server, you receive a dialog box with an input field for a transaction code and an option for execution in the same or a new mode.

Troubleshooting in "Trusted/Trusting" Systems

If you have created a trusted system without the specification of logon data (user name and password), you need to check the destination by loging on to the trusted system using the "Remote Login" button.

Alternatively, you can perform an authorization check for the trusted server through the respective option in the Test menu.

If your logon attempt is not successful, you will receive the following message:
No authorization for logging on to trusted system (Error code = <0|1|2|3>).

The error code has the following meaning:

• 0 - Invalid logon data (user and client) for the trusting system.
  
  Solution: In the trusting system, create the user in the respective client.
  

• 1 - The calling system is not a trusted system or the security key for the system is invalid.
  
  Solution: Create the trusted system correctly.
  

• 2 - The user has no authorization for the server system (object S_RFCACL) or logon was performed using one of the protected users 'DDIC' or 'SAP*'.
  
  Solution: Get the appropriate authorization for the user or do not use any of the protected users 'DDIC' or 'SAP*'.
  

• 3 - The time stamp of the logon data is invalid.
  
  Solution: Check the system time on the client system and the server system as well as the validity date of the logon data (remember that the standard date 00:00:00 sets no limitation).

In the trusting system, you can check whether correct logon data was preset for the trusted system by performing the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

If all the checks have run successfully and you still do not have access to the trusting system, refresh the corresponding database buffer by choosing the following menu path in the user maintenance transaction: Utilities → Mass Changes → Delete All User Buffers.

If you wish to find the cause of the error, activate the trace function in the destinatin maintenance function SM59, reproduce the error, and read the information for error recognition. Also read the information on recognizing erros CALL_FUNCTION_SINGLE_LOGIN_REJ in the short dump of the calling system.

Important Note:

As of Release 4.0b, profile parameters S_RFCACL are not a standard part of the SAP_ALL authorization profile - for security reasons.