Example of How to Create a Trusted Relationship

In the following, an example trusted relationship is created between systems C00 (client system) and S00 (server system).
The example used is for the simple case of a "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 a dialog user) (for example HUGO in 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:

Proceed as follows to configure the trusted system:

Important note

When you delete the Trusted System relationship, the logon screen for the corresponding system appears (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 and 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".

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

To prevent changes being made to the destinations, choose "Destination not modifiable" in its attributes.

Use the F1 help to display details about each field.

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 Trusted 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 pushbutton Remote Login. To log on under a different user or
client, the corresponding RFC destination with the trusted option for this purpose must be entered. 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>
_<systemid>_<systemnumber>_TRUSTED).

A dialog box appears containing an input field for a transaction code and a field in which you can select whether to execute it in the same session or in a new session.

Troubleshooting for Trusted and Trusting Systems

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

Alternatively, you can check the authorizations for the trusted system from the 'Test' menu.

If your logon attempt fails, the following message appears:
No authorization for logging on to trusted system (error code = <0|1|2|3>).

The error codes have the following meanings:

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 of the checks are successful but you still cannot access the trusting system, refresh the corresponding database buffer by choosing Utilities --> Mass changes --> Delete all user buffers in the user administration transaction. Utilities → Mass Changes → Delete All User Buffers.

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