Trusted System: Trust Relationships Between SAP Systems

SAP systems may establish trusted relationships between each other.

If a calling SAP system is known to the called system as a trusted system, no password must be supplied.

The calling SAP system must be registered with the called SAP system as a trusted system. The called system is called the trusting system.

Trust relationships between SAP systems have the following advantages:

· Single Sign-On is possible beyond system boundaries.

· No passwords are transmitted in the network.

· Timeout mechanism protects against replay attacks.

· User-specific logon data are checked in the trusting system.

Using this feature, you can create a virtual SAP system consisting of various SAP 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 SAP system as a trusted system, you must first create a logical destination that allows a trusted system relationship.

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.

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.

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

7. If you want to restrict the validity period of the logon data, enter an end date in the Validity period field.

8. If you want take over the transaction code of the calling program into the called system, mark the appropriate checkbox.

9. 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).

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, double-click the checkbox.

Note that destinations must be kept consistent. For this reason, you are not allowed to change the ID of the target system, the system number, or 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 the name of an application server displays a dialog box, in which you can enter the transaction that you want to execute in the trusting system. You can also specify whether the transaction is to be executed in the same session, or in a new one.

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 the authorization checks for the current server and the trusting system. To do this, choose the menu entry. 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 creating a trusted system, you have to test the destination. To do this, log on to the trusted system using remote login.

Alternatively, you can also perform an authorization check for the trusted server. To do this, select the respective 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:

· Invalid login data (user ID and client) for the trusting system

· Solution: Create the user ID for the client in the trusting system.

· No trusted system entry exists for the calling system, or the security key for the system is invalid.

· Solution: Create the trusted system entry again.

· The user does not have a trusted system authorization (object S_RFCACL).

· Solution: Provide the user with the necessary authorization.

· 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 by choosing Environment ® 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).