Maintaining Trust Relationships Between R/3 Systems 

R/3 Systems may establish trusted relationships between each other.

If a calling R/3 System is known to the called system as a trusted system, no password must be supplied.

The calling R/3 System must be registered with the called R/3 System as a trusted system. The called system is called the trusting system.

Trust relationships between R/3 Systems have the following advantages:

Using this feature, you can create a virtual R/3 System consisting of various R/3 Systems that are called remotely. Remote logon data are checked in the trusting system.

The trust relationship is not mutual, which means, it applies to one direction only. To establish a mutual trust relationship between two partner systems, you must define each of the two as trusted systems in its respective partner system.

For additional security, you can make use of SAP’s SNC interface (Secure Network Communications) for third-party security systems such as Kerberos and SECUDE.

Displaying, Maintaining and Testing Trusted Systems

To display or maintain a trusted system in the trusting system, proceed as follows:

  1. If you want to define an R/3 System as a trusted system, you must first create a logical destination that allows a trusted system relationship. For details, see Maintaining Remote Destinations.
  2. From the RFC destination overview screen (transaction SM59), choose RFC ® Trusted systems or enter transaction code SMT1.
  3. If trusted systems have already been defined, they are displayed in a hierarchy tree. To display existing trusted systems, expand the nodes in the hierarchy tree.

    For details, double click a trusted system.

  4. To create a trusted system, click the Create icon.
  5. In the dialog window, enter the destination for the remote system. To change a destination, see Changing Trusted Destinations below.

    All the necessary information such as application server name and security key is supplied automatically.

  6. If you want to restrict the validity period of the logon data, enter an end date in the Validity period field.
  7. If you want take over the transaction code of the calling program into the called system, mark the appropriate checkbox.
  8. Only then will an authorization check be performed in the called system for the transaction code (field RFC_TCODE of the S_RFCACL authorization object, see Logon Authorization Checks in the Trusting System below).

  9. To delete a trusted system relationship, display the trusted system details and click the Delete pushbutton.

As you delete a trusted system relationship, the logon screen of the relevant system is displayed, if no valid logon data are provided. You must log on to that system to complete the deletion.

Changing Trusted Destinations

You can change existing destinations for each system from the trusted system maintenance screen (RFC ® Trusted systems, transaction code SMT1) by clicking on the Maintain destination pushbutton.

In trusted systems, destinations for trusting systems are automatically created. These destinations are used when you display trusting systems via RFC ® Trusting systems (transaction code SMT2).

To prevent others from making changes to your trusted destination, mark the checkbox Destination not changeable in the Attributes section. To make the destination changeable again, doubleclick the checkbox.

For more details on fields, invoke field help.

,Please note that destinations must remain consistent, which means you must neither change the target system ID, the system number nor the destination name.

Displaying Trusting Systems

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

Choose RFC ® Trusting systems to display the list of trusting systems.

Click on the name of a trusting system to display the application servers of that system. The application server names contain the suffix _TRUSTED.

Double-clicking an application server name provides a dialog window with an entry field for a transaction code to be performed in the trusting system, and whether the transaction is to be carried out in the same mode or in a new mode.

Logon Authorization Checks in the Trusting System

The logon data used for logging on to a trusting system undergo an authorization check.

The data provided by the trusted system is checked for system name, client, user name, and other optional data. These data must match the field values of authorization object S_RFCACL.

The system administrator can check a user’s logon data using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

Error return codes are explained in the Troubleshooting section below.

Testing Trusting Systems

To test a trusted system, you can perform authorization checks for the current server and the trusting system via the Entry menu. If no valid logon data are supplied, the logon screen of the trusted systems appears. You should log on to the system. If your test is not successful, read the section Troubleshooting in Trusted/Trusting Systems below.

Troubleshooting in Trusted/Trusting Systems

After you have created a trusted system, you must test the destination by logging in to the trusted system via the Remote logon pushbutton.

Alternatively, you can perform an authorization check for the trusted server using the appropriate function from the Test menu.

If your login attempt fails, you will receive the following message: No authorization to log in as trusted system (error code = <0|1|2|3>). Note that the special users DDIC and SAP* must not be used.

The error code explanation is as follows:

  1. Invalid login data (user ID and client) for the trusting system
  2. Solution: Create the user ID for the client in the trusting system.

  3. No trusted system entry exists for the calling system, or the security key for the system is invalid.
  4. Solution: Create the trusted system entry again.

  5. The user does not have a trusted system authorization (object S_RFCACL).
  6. Solution: Provide the user with the necessary authorization.

  7. The time stamp of the login data is invalid.

Solution: Check the clock settings on both the client and server host and the expiration date of the login data. (Note that the default expiration period 00:00:00 means no limit.)

You can check whether correct login information has been provided for the trusted system in the trusting system by means of the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

If all your tests are successful and you still don’t get access to the trusting system, refresh the relevant database buffers by choosing Utilities ® Mass changes ® Reset all buffers from the user maintenance screen.

To find out the cause of an error, activate the trace flag on the destination details screen, reproduce the error and read the information provided with the error ID CALL_FUNCTION_SINGLE_LOGIN_REJ in the short dump created in the called system (the trusting system).