Trusted and Trusting RFC System connections

Home


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:

1) "Single Sign-On" for multiple systems.

2)  Passwords are not transported over the network.

3) Timeout mechanism for logon data prevents misuse.

4) User-specific logon data for the trusted system is checked.

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.

Displaying and Maintaining Trusted Systems

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:

RFC_SYSID : C00
RFC_CLIENT: 100
RFC_USER :
RFC_EQUSER: Yes
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
You maintain trusted systems as follows:

Log on to the server system (in this example, S00, with the user HUGO in client 100). In transaction SM59, create a destination to the client system (C00), (for example, C00_SYSTEM). Note that the Trusted System option is not active for this destination (Security Options: Trusted System = No). As logon data, enter the user HUGO, client 100, and the correct password.

Note: for each trusted system (client system), you need to create a destination with type 3 (R/3 connection). If you have already created a new destination, carry on reading at the section "Maintaining Destinations for Trusted and Trusting Systems".
Call transaction SMT1 (or call transaction SM59 and choose RFC → Trusted Systems).
Choose Create. Enter the destination of the client system (COO_SYSTEM in this example). After you confirm your entries, an RFC logon to the client system occurs, so that the two systems (C00 and S00) can exchange the information they need.

Note: If there is no logon data entered in the destination (C00_SYSTEM in this example), the RFC logon screen appears for the client system (C00). If so, you must log on manually. You must be logged on to the client system in this step; otherwise, the trust relationship cannot be created. In our example, you log on as the user HUGO in client 100.
If the trust relationship has been created successfully, a trusted entry is displayed for the client system (C00).
To restrict the validity of the logon data, enter a period in the corresponding field. The default (00:00:00) is unlimited validity.
To use the transaction code of the calling program in the target system, select the corresponding option.
Only if you do this does the target system check the user's authorization against the field RFC_TCODE of authorization object S_RFCACL.
The Entry menu allows you to check authorizations for the current server and the trusting system.
Note: If there is no valid logon data stored for the destination, the logon screen of the corresponding system appears. Log onto the system. If the test is unsuccessful, refer to the section "Troubleshooting for Trusted and Trusting Systems".

Important note: When you delete the trusted system relationship the logon screen of the relevant system appears, if no valid logon data is already stored for the destination. You must log on to the system; otherwise the relationship cannot be fully deleted.
Maintaining Destinations for Trusted and Trusting Systems

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.

Displaying Trusted Systems

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

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.

Troubleshooting for Trusted and Trusting Systems

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.

0	No error - successful logon
1	Incorrect logon data (client, user name, password)
2	User account is locked
3	Incorrect logon data; for SAPGUI: connection closed
4	(Successful) Logon using emergency user SAP* (see SAP Note 2383)
5	Error when constructing the user buffer (==> possible follow-on error)
6	User exists only in the central user administration (CUA)
7	Invalid user type
8	User account outside validity period
9	SNC name and specified user/client do not match
10	Logon requires SNC (Secure Network Communication)
11	No ABAP user with this SNC name exists in the system
12	ACL entry for SNC-secured server-server link is missing
13	No suitable SAP account found for the SNC name
14	Ambiguous assignment of SNC names to ABAP users
15	Unencrypted SAP GUI connection refused
16	Unencrypted RFC connection refused
20	Logon using logon/assertion ticket is generally deactivated
21	Syntax error in the received logon/assertion ticket
22	Digital signature check for logon/assertion ticket fails
23	Logon ticket/assertion issuer is not in the ACL table
24	Logon/assertion ticket is no longer valid
25	Assertion ticket receiver is not the addressed recipient
26	Logon/assertion ticket contains no/an empty ABAP user ID
27	Reauthorization check: ticket does not match current user
28	Ticket logon denied by security policy
30	Logon using X.509 certificate is generally deactivated
31	Syntax error in the received X.509 certificate
32	X.509 certificate does not originate from the Internet Transaction Server
34	No suitable ABAP user found for the X.509 certificate
35	Ambiguous assignment of X.509 certificate to ABAP users
36	36 Certificate is older than the date entered as "min. date" (USREXTID)
41	No suitable ABAP user found for the external ID
42	Ambiguous assignment of external ID to ABAP users
50	Password logon was generally deactivated or denied by security policy
51	Initial password has not been used for too long
52	User does not have a password
53	Password lock active (too many failed logons)
54	Productive password has not been used for too long
60	SPNego logon denied by security policy
61	Invalid SPNego token (syntax)
62	NTLM token received instead of SPNego token
63	Missing/incorrect Kerberos keytab entry
64	Invalid SPNego token (time)
65	SPNego replay attack detected
66	SPNego: Error when creating the SNC name
67	SPNego: No suitable SAP account found for the SNC name
68	SPNego: Ambiguous assignment of SNC names to ABAP users
100	Client does not exist
101	Client is currently locked for logons (upgrade running)
110	Tenant was stopped (runlevel STOPPED)
111	Tenant cannot be used generally (runlevel ADMIN)
120	Server does not allow logon
121	No special rights for logon on this server
1001	Password is initial/has expired - interactive change required (RFC/ICF)
1002	Trusted system logon failed (no S_RFCACL authorization)