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