In this scenario, the following error text in SMT2 can be ignored:
No authorization to log on as a trusted system (Trusted RC=0)
In this scenario, the following error text in SMT2 can be ignored:
No authorization to log on as a trusted system (Trusted RC=0)
You can now use the configured trusted/trusting relationship to create RFC destinations in the trusted system (client), which are for the trusting system (server), by using transaction SM59 and the 'Trusted System' flag. The result of this is that, when such destinations are used for the RFC logon to the trusting system, no password is sent.
A prerequisite for successfully using a trusted/trusting relationship is that the user being used has the corresponding authorization object S_RFCACL in the trusting server system. If you want to create a suitable authorization for different
clients and users, note that you have to enter the caller data (caller client and caller user) of the caller system (in our example from system C00) into the S_RFCACL fields RFC_CLIENT and RFC_USER. For example, if user U_1 under client M_1 in caller system C00 wants to work as user U_2 with client M_2 in the called system S00 under a trusted relationship, then the user (U_2, M_2) in the system S00 must have authorization ZRFCACL_XXX, which has the following settings:
RFC_USER : U_1
RFC_EQUSER: N (for NO)
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
The following steps describe how you can enter the above settings for server system S00:
SU03 + double-click the entry "AAAB" "Cross-Application Authorization Objects" and then choose "Authorization check for RFC user (ex. trusted system)" as the object class, then double-click the authorization object S_RFCACL and create Z_RFCACL_XXX.
After this, make sure you activate your settings.
If the same user is always used in the client system and server system for a trusted/trusting relationship (meaning that U_1 = U_2), the authorization Z_RFCACL_XXX can also be defined as follows:
· RFC_SYSID : C00
· RFC_CLIENT: M_1
· RFC_USER : ' '
· RFC_EQUSER: Y (for Yes)
· RFC_TCODE : *
· RFC_INFO : *
· ACTVT : 16
Setting the authorization field RFC_EQUSER to 'Y' is the same as setting the field RFC_USER = SY-UNAME for the logged user in the caller system (here, system C00).
Note that when maintaining and assigning S_RFCACL authorizations (in this case, Z_RFCACL_XXX), you must use as few generic values (for example '*') for RFC_SYSID, RFC_CLIENT and RFC_USER as possible. By doing this, those users who fulfill these criteria regarding RFC_CLIENT and RFC_USER, can call RFC modules from within the caller system, using the called user.
You must ensure that high security requirements in the caller system is linked with the usage of user maintenance transactions (such as SU01). If this is not the case, anyone who has this authorization can get a user and log on to the trusting system (S00).
After you have maintained the authorization Z_RFCACL_XXX, you must create an authorization profile as follows, and link it to the authorization Z_RFCACL_XXX:
Call SU02 and in the field "Manually edit authorization profiles", enter Z_<C00> as the authorization profile. Choose "Create work area for profiles" and then create a new profile. Enter S_RFCACL as the object, and Z_RFCACL_XXX as the authorization.
After this, make sure you activate the profile.
You now have to assign the authorization profile you have just created to the trusted/trusting user. To do this, enter the profile Z_<C00> on the tab page Profile in transaction SU01.
You can check the authorizations for the logged on users in the current system in advance, by using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.
As of Release 40B, for security reasons, the authorization profile SAP_ALL does not contain an authorization for S_RFCACL.
Authorization errors that occur while using an RFC destination which has the 'Trusted Systems' flag set to 'Yes' are documented with the following messages:
No authorization to log on as a trusted system (trusted RC = <0 1 2 3>).
Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:
0 Invalid logon data (user ID and client) for the trusting system.
Solution: In the server system (trusting system), create the userin the corresponding client.
1 Calling system is not a trusted system, or security ID for the system is invalid.
Solution: Create (again) the trusted system
2 User has no authorization for the server system (trusting system, for object S_RFCACL), or a logon was made using one of the protected users DDIC or SAP*.
No authorization to log on as trusted system (Trusted RC = <0 1 2 3>).
Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:
0 Invalid logon data (user ID and client) for the trusting system.
Solution: In the server system (trusting system), create the user in the corresponding client.
1 Calling system is not a trusted system, or security ID for the system is invalid.
Solution: Create (again) the trusted system (see above).
2 User has no authorization for the server system (trusting system, for object S_RFCACL), or a logon was made using one of the protected users DDIC or SAP*.
Solution: Provide the user with the corresponding authorization or avoid using the protected users DDIC and SAP*.
3 Time stamp of the logon data is invalid.
Solution: Check the system time on the client host and server host, as well as the validity date of the logon data.
(Note that the default date 00:00:00 means unrestricted validity.)
Call transaction SMT1 (or SM59 and then transaction menu RFC ® Trusted Systems).
If different users or clients are used for the trusted scenario, you must create an RFC destination on the client side, and perform an authorization check for the specified logon data, setting the flag for "Trusted System" to "Yes".
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.
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.
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.)
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).
The system administrator can check a user's logon data using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.
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.
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.
SAP systems may establish trusted relationships between each other.
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.
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.