Trusted systems can log onto other R/3 Systems without using a password.
This kind of relationship between two R/3 Systems has the following advantages:
The calling system must be registered as a trusted system (transaction SMT1) in the target system.
The target system in this context is known as a trusting system.
You can set up several R/3 Systems so that each is declared as a trusted system to the others.
When you create a trust relationship between two systems, the initiative comes from the called system
(that is, the server system). In addition, the users of the calling system that are allowed to call
functions remotely using the trust relationship must be known to the called system (as "trusted users").
Before defining a trusted system, you must maintain an RFC destination for it in the calling system.
The RFC user must have the corresponding authorizations in the current (trusting) system (authorization
object S_RFCACL). You can check the current user's authorization in the current
system in advance using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.
Note:In a trust relationship, the calling system (or client system) plays the role of the trusted system, while the called (or server) system plays the role of the trusting system.
In the following section, we create a trust relationship between the systems C00 (the client) and S00 (the server) as an example.
The example shows the simple case of a "Single Sign-On" procedure - that is, one where the user for
whom you are setting up the trust relationship is present in both systems (C00 and S00), in the client,
and with the same user ID (as a dialog user type) - for example HUGO, in client 100.
In the server
system (S00), the authorization object, S_RFCACL_DEV, must be available to theuser (HUGO in client 100), with the following settings:
You maintain trusted systems as follows:
You can maintain one destination per system from the maintenance transaction for trusted and trusting systems by choosing Maintain destinations.
Destinations for trusting systems are created automatically. These are used in the trusting system transaction (SMT2).
To prevent changes being made to the destinations, choose Destination not modifiable in the Attributes menu.
Use the F1 help to display details about each field.
Note that the destinations must remain consistent. This means that none of the target system ID, system number or destination name may be changed.
In a trusted system, you can display a list of all trusting systems.
When it creates the list of trusting systems, the system both logs on and checks the authorization of the current user and client. This is similar to the check performed in transaction SM51 when you log on to a server using Remote Logon.To log on with a different user ID or client, you must create an appropriate RFC destination with the trusted option for this purpose. The transaction SMT2 logs you on with the current user and client.
In the trusting systems transaction SMT2), choose the name of a trusting system to display the application server of this R/3 System.
The names of the application servers of a trusting system have the suffix _TRUSTED (that is, the form
Double-click the name of an application server. 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.
If you create a trusted system without specifying any logon data (user name and password), you must check the destination by logging onto it using the Remote logon to trusted system function.
Alternatively, you can check the authorizations for the trusted system from the Test menu.
If your logon attempt fails, the following message appears:
"You
are not authorized to logon as a trusted system (Error code = <0|1|2|3>)".
The error codes have the following meanings:
0,,Invalid logon data (user and
client) for the trusting system
,,Solution: Create the user in the correct client in the target system.
1,,The calling system is not a trusted system, or its security key is invalid.
,,Solution: Create a trusted system
2,,The user has no authorization in the trusted system (object S_RFCACL), or logged
on as one ,,of the protected users 'DDIC' or 'SAP*'.
,,Solution: Assign the user the correct authorizations, or use a user other than the protected ,,users 'DDIC' or 'SAP*'.
3,,The timestamp on the logon data is invalid
,,Solution: Check
the system time on the client and server hosts and the validity period of the ,,logon data. (Note: the default date 00:00:00 means that the validity is unrestricted.
In the trusting system, you can check whether the correct logon data is stored for the trusted system using 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.
To reveal the causes of the error, activate the trace recording in the destination maintenance transaction (SM59), reproduce the error, and refer to the information under the error ID CALL_FUNCTION_SINGLE_LOGIN_REJ in the short dump in the target system.
Important note: From Release 4.0B onwards, the profile parameter S_RFCACL is no longer made part of the SAP_ALL authorization profile by default, for security reasons.