Advantages and Disadvantages of Trusted RFC Destinations

Use

Both RFC destinations with a user and password (or trusted RFC destinations with an entered user) and trusted RFC destinations with the option current user have advantages. Weigh which option is more useful for your system landscape, according to your security requirements.

Method	Advantage	Disadvantage or Restriction
RFC destinations with a user and password (or trusted RFC destinations with an entered user)	The user ID of the administrator that changes users in the central system is usually distributed to the child systems. With RFC destinations with a user and password, you can no longer identify in the child systems which administrator changed the users in the central system. With active Central User Administration (CUA), all attributes of a user that an administrator changes in the CUA central system are distributed to the child systems with IDocs. In the child systems, these IDocs are either processed directly with an RFC system user, or in the background with a background user. The change documents of the changed users do not contain the user name of the administrator that changed the users in the CUA central system, but rather the user name of the user in whose name the IDoc inbound processing was performed.	If you operate the CUA with the options trusted RFC and current user, the change documents in the child systems contain the user name of the administrator. However, this is only the case if none of the following occurs: You need to temporarily switch to background processing. Another administrator starts the distribution using transaction SCUL again without actually changing data. The tRFC queue overflows and the IDocs are transferred by background job. The IDocs are not updated in the original order in the child system. In these cases, the user details in the change documents are incorrect.
trusted RFC destinations with the option current user	Increased security. You no longer need to enter system users with the associated authorizations in the RFC destination for the RFC connection from the central to the child system. Instead, when creating the RFC destination, specify that the current user is used. The user of the user administrator is therefore used directly for the RFC connection. This means that there is no longer any danger that the authorizations of an explicitly created system user can be misused.	With data distribution from the child system to the central system (redistribution with distribution parameters): You cannot use trusted system with current user, since the end users change their own user data with transaction SU3 and distribute it back to the central system by redistribution. This would also mean that all end users would require change authorization for the user administration in the central system and could also change all other user data. You have to re-create the authorizations and the system users and expose these to misuse. You restrict the usage possibilities of the RFC destination to redistribution, meaning that no other application can use this destination. You can restrict the danger of misuse of RFC destinations with user ID and password by precise use of the authorization group for RFC destinations. This also provides a high level of security.
Complex setup of trusted RFC: With trusted RFC, you must set up a universal trust relationship between the systems and create an authorization concept for the authorization object S_RFCACL. If you want to use the current user option, you also must ensure that all administrators in all target systems have complete user administration authorizations (this is often not the case without trusted RFC).

Method

Advantage

Disadvantage or Restriction

RFC destinations with a user and password (or trusted RFC destinations with an entered user)

The user ID of the administrator that changes users in the central system is usually distributed to the child systems.

With RFC destinations with a user and password, you can no longer identify in the child systems which administrator changed the users in the central system. With active Central User Administration (CUA), all attributes of a user that an administrator changes in the CUA central system are distributed to the child systems with IDocs. In the child systems, these IDocs are either processed directly with an RFC system user, or in the background with a background user. The change documents of the changed users do not contain the user name of the administrator that changed the users in the CUA central system, but rather the user name of the user in whose name the IDoc inbound processing was performed.

If you operate the CUA with the options trusted RFC and current user, the change documents in the child systems contain the user name of the administrator. However, this is only the case if none of the following occurs:

You need to temporarily switch to background processing.
Another administrator starts the distribution using transaction SCUL again without actually changing data.
The tRFC queue overflows and the IDocs are transferred by background job.
The IDocs are not updated in the original order in the child system.

In these cases, the user details in the change documents are incorrect.

trusted RFC destinations with the option current user

Increased security.

You no longer need to enter system users with the associated authorizations in the RFC destination for the RFC connection from the central to the child system. Instead, when creating the RFC destination, specify that the current user is used. The user of the user administrator is therefore used directly for the RFC connection. This means that there is no longer any danger that the authorizations of an explicitly created system user can be misused.

With data distribution from the child system to the central system (redistribution with distribution parameters):

You cannot use trusted system with current user, since the end users change their own user data with transaction SU3 and distribute it back to the central system by redistribution. This would also mean that all end users would require change authorization for the user administration in the central system and could also change all other user data.
You have to re-create the authorizations and the system users and expose these to misuse.
You restrict the usage possibilities of the RFC destination to redistribution, meaning that no other application can use this destination.

You can restrict the danger of misuse of RFC destinations with user ID and password by precise use of the authorization group for RFC destinations. This also provides a high level of security.

Complex setup of trusted RFC:

With trusted RFC, you must set up a universal trust relationship between the systems and create an authorization concept for the authorization object S_RFCACL. If you want to use the current user option, you also must ensure that all administrators in all target systems have complete user administration authorizations (this is often not the case without trusted RFC).

Note

You have the following options for determining the user names of the changing administrators in the CUA central system:

Manual analysis

If the associated IDocs were not deleted, in the central system, you can use the time in details IDoc Tracing (transaction BDM2) to determine the creator of an outbound IDoc in the change documents of the child system and therefore determine the user administrator.
Table logging

You can generate suitable change documents for role and profile assignments in the CUA central system by activating table logging for tables USLA04, USL04, and optionally USZBVSYS with transaction SE13. You can activate the table logging framework with profile parameter rec/client. You can analyze the table logging with transaction SCU3 or the reports RSTBHIST or RSVTPROT.

For technical reasons, the system does not currently log the changes, but rather logs the previous and the new statuses of all assignments at each change. This means that large quantities of data are produced, which makes analysis more difficult. To use table logging efficiently, import the correction from SAP Note 935510 . This means that the system now logs only the differences from the previous status of the system-specific roles and profile assignments in tables USL04 and USLA04.