SECRET
ARTICLE
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:
RFC_SYSID : C00
RFC_CLIENT : 100
RFC_USER :
RFC_EQUSER : Yes
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
Proceed as follows to configure the trusted system:
Log on to the server system (in this example, the system S00 with
the user HUGO and the 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 ). In the logon data, enter user
HUGO , client 100, and the corresponding password.
Note: 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 configure 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, an RFC logon is performed in the client system, to exchange the
necessary information between the systems ( C00 - S00 ).
Note: If no logon data is 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 log on successfully to the client system in
this step 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
(00:00:00) is unlimited validity.
To use the transaction code of the calling program in the target system,
select the appropriate option.
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 stored for the destination (
C00_SYSTEM in the example), the logon screen of the corresponding
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 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:
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 indicates no limits on the date).
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved