CUA: User & Role Master Data Change Document

[Former Member]

Hi Team,

I would like to know is there any way to find out CUA user master & role assignment change document data from CUA Central System & All Targets Systems.

I am looking for user friendly tool similar to SUIM.

I have looked into other methods of CUA change document tips and tools but it is not so fruitful to convenes my Audit team.

FYI. System Users (CUA_ADMIN) is not the user which i want to see in my change document window, i want to know actual security consultant ids within that.

Kindly get back to me.

Appreciate, for your response.

Regards,

Asif

[Former Member]

Asif,

Do you have Trusted RFCs from CUA to the Child system? Based on what you are saying it sounds like CUA_ADMIN is configured in the RFC connection that is use for the USERCLONE distribution. If you have trusted RFC connections from CUA to the Child system it will use your Security Administrator's authorizations both on CUA and the destination Child system therefore leaving a record of update by the named user on the Child system. From there you can view the SUIM or Change Docs in the destination Child system to see who performed the activity.

Does that help and make sense?

Thanks.

Matt U.

[Former Member]

Hi Matt,

We donu2019t use trusted System for CUA RFC Connections. I think there was an article/note from SAP in that SAP has mentioned using Trusted Systems is not recommended due to lot of limitations hence we are not using it.

If incase of No Risk using Trusted System then we could have started it before.

Do you have any experience by using Trusted Systems RFC connections for CUA?

Regards,

Asif

[Former Member]

Asif,

Do you have a link to that article? I have always heard the opposite that Trusted RFCs are to be used for additional security.

I have always used Trusted RFCs from CUA to Child systems. Some of the main reasons are around the audit trail and security. For security, if someone was to obtain access to CUA and enable an update to an account, the RFC id will aways have access even though the user didnt. With trusted RFCs both the USER on CUA and Child system need to be authorized to make the changes, just an additional layer of access control.

CUA Documentation (refer to page 17)

https://websmp205.sap-ag.de/~sapdownload/011000358700001037122002E/October_670_change.pdf

Secure RFCs in your landscape

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/a08fbe33-0501-0010-2d9c-fb37e9795fd9

How-to Secure RFCs

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/b2cce390-0201-0010-5a9f-cca08c75b6ea

- Matt

[Former Member]

HI Matt,

Not sure whether you have looked into this link

Advantages and Disadvantages of Trusted RFC Destinations

http://help.sap.com/saphelp_nw2004s/helpdata/en/44/4dd720b5ac2152e10000000a114a6b/frameset.htm

Disadvantage (Restriction)

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.

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

● You cannot use trusted system with u201Ccurrent useru201D, 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 recreate 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 need to 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 need to ensure that all administrators in all target systems have complete user administration authorizations (this is often not the case without trusted RFC).

****well, bcoz of SU3, you canu2019t use current user option for Trusted RFCu2019s then CUA Central repository change document window will give you System User name (like CUA_PRD) for All the SU3 change access redistribution field values.

As we also do OM level of Indirect Roles assignment in few of our Child Systems hence it will not possible to see the administrator ids from the Central System (CUA) for Role Assignment.

That means...2 ways of communication with Trusted System wonu2019t possible fully. Am i rt ?

Regards,

Asif

[Former Member]

Asif,

I think the key take away I see in that article is the statement "You need to weigh up which option is more useful for your system landscape, depending on your security requirements." Every organization views security differently and its must select was fits them. You must work with the right people to balance the levels.

As for the SU3 data distribution, that can be controlled via your SCUM settings and if need end users can have a general role on CUA for authorization purposes only to all for SU3 updates along with S_RFC / S_RFCACL. For OM role based assignments, the changed by record will have the individual that executed PFUD or (RHAUTUPD_NEW) that triggered the change.

Thanks,

Matt

[Former Member]

Hi Matt,

Thanks for the response.

As we have already implemented 2 Tier CUA in our Company landscape...is it possible to convert Normal RFC Connections to Trusted RFC Connection along with current user option?

What would be the impact to the current setup with this Change ? Any idea - Pls advise.

Appreciate for your response.

Regards,

Asif

[Former Member]

Asif,

By 2 Teir you mean 2 CUAs (1 non-prod & 1 prod)? If so you should be able to switch to trusted RFCs pretty easily. You can refer to the CUA guide I mentioned in a previous post for setup details but essentially you need to create a trust between the CUA and the Child system. I suggest you perform this within the a sanbox environment first to get confortable and work out the authorization issues (if any).

1) I would update the authorizations on both CUA and the Child system of your security administrators to include S_RFC, S_RFCACL and related Security Auths for administration of roles and user profiles.

2) Create the trust from the CUA to the Child (SMT1, SMT2) and update the RFC (SM59) to use the trusted relationship

3) Create the trust from the Child to the CUA (SMT1, SMT2) and update the RFC (SM59) to use the trusted relationship

4) Test out your security management functions and ensure all authorizations are correctly maintained to allow for proper distribution from CUA to Child system. Use trace (ST01) and CUA logs (SCUL) to ensure everything is in alignment.

As for the possible risks, if you dont have correct authorizations you will lock yourself out of administration of user and SCUL logs will begin to build up.

Thanks,

Matt

[Former Member]

HI Matt: Your understanding is correct for CUA Tier2 Setup.

FYI.

We have successfully configured trusted relationships between SAP Systems with the help of my BASIS & UNIX team.

To do this: We have performed following actions:

u2022 Trusted System trust relationships for the RFC Connection has been maintained from the Central to the Child System and from All Child to Central System via transaction code SMT1.

u2022 UNIX Database level trusted relationship entries has also been added with the help of UNIX Team

u2022 RFC Destinations has been reconfigured with Current user option (SM59).

u2022 For Security Administrator special authorizations has been provided in order to get trusted relationship RFC authorizations.

Note:

I have added Full Authorizations under these new special objects S_RFC, S_ICF, S_RFCACL, & S_RFCADM and same was assigned to all our Security Administrators. Remote Logon & Trusted Connectivity is working fine for all of us.

We are 4 Security Administrator here, And for All of us this new concept of Trusted RFC for CUA is working fine.

New Authorizations updated on both CUA and the Child System.

Our ids are replicating as a log in the last change by field of SU01 and change document of SUIM. Happy to see this. 

But unfortunately there are strange ABAP dumps are started generating from CUA (SolMan) System soon after this Implementation.

When we look into ST22, runtime errors CALL_FUNCTION_SINGLE_LOGIN_REJ & CALL_FUNCTION_SYSCALL_ONLY are keep generating.

Following are the example of dump logs and all the dump are with similar fashion but with different user-ids within that.:

Short text: No authorization to logon as trusted system (Trusted RC=0).

What happened? : Error in the ABAP Application Program The current ABAP program "SAPMSSY1" had to be terminated because it has come across a statement that unfortunately cannot be executed.

Error analysis: An RFC call (Remote Function Call) was sent with the invalid user ID "(End user user-ids)". Or the calling system is not registered as trusted system in the target system.

How to correct the error: The error code of the trusted system was 0.

Meaning: 0 Correct logon as trusted system mode

1 No trusted system entry for the calling system "BIP " (like other child System) or the security key entry for the system "BIP " is invalid

2 User "111552 " (Type of End user) does not have RFC authorization (authorization object

(S_RFCACL) for user "End User id " witl client 100.

3 The timestamp of the logon data is invalid

The error code of the SAP logon procedure was 6. (6 No external user check)

My Point: I think All these End users are trying to connect CUA Trusted RFC connections through individual different child Systems..

Why they need to Connect to CUA and for what reason they need special Trusted RFCu2019s authorization???

Pls help me to fix this problem.

I have gone through the old SDN posts related to the same topic and few SAP notes and help link but it wont help.

Note 1579570 - Problem with trust relationship after using HMAC

Note 128447 - Trusted/trusting systems

Note 131387 - No authorization to log on as a trusted system

Note 986707 - No authorization to log on as a trusted system (RC=1)

Few More SAP Notes: 986707, 333441, 1151790 & 128447

http://help.sap.com/saphelp_nw04/helpdata/en/8b/0010519daef443ab06d38d7ade26f4/frameset.htm

We donu2019t see any logs under SCUL, BD87 & ST01.

Please anyone can assist me on this.

Regards,

Asif

[Former Member]

Asif,

Are the short dumps being created by project team/business users or the Security Team? Essentially once you create a Trusted RFC, anyone who triggers any functionality that uses that specific RFC call, then they must have access to S_RFC and S_RFCACL. If that is the case you can restrict your users to only the systems that they should be authorized to make calls to. Within the S_RFCACL there is a spot for RFC SYSID to restrict the systems to connect to (if required).

- Matt

[Former Member]

Hi Matt,

Short dumps are being created by business users as well as the system & communication users...means dumps are throwing through Dialog, System and Communication users.

Yes they only have S_RFC authorization but we have not given S_RFCACL authorization to anyone except from Security Administrators.

I am unable to figure out your point, how to fix this pls ?

Appreciate for your response.

Regards,

Asif

[Former Member]

Asif,

If you created a trusted RFC, all your users must have S_RFCACL. I would grant the access to the system ids and business users. Again, limit the RFC SYSIDs if you need to restrict the systems they can connect to.

To test you can grant full access to S_RFCACL for the time being, then tweak to your environment.

- Matt

[Former Member]

Hi Matt,

Just for clarification, could be this one is in laymen language.

Trusted RFCu2019s are created only for CUA Purpose and there are lot of others RFCu2019s which are not trusted and the same has been using for some others purposes.

CUA is 100 % independent Client business users have nothing to do in this.

S_RFCACL is the special authorization check (more secured) then why would we need to allow this to all End users (business Users) or any other System or communication user.

Just to update you: I have not given any field redistribution option to the end users instead we have put Global, Local and Proposal through SCUM.

With your last email, you mean to say that allow S_RFCACL access to all the business users in all the Target Production System?

I am sorry to bother you on thisu2026but it is puzzling me a lotu2026why end user needs S_RFCACL authorization access.

Regards,

Asif

[Former Member]

A usefull way to solve this is to use client side RFC security.

Take a look in transaction SU21 at the documentation on object S_ICF.

This will stopp them short-dumping in the target because the source system protects the authorization for the destination. Then give S_ICF with this value only to those with more-than-change access to SU01 (actually, give the others SU01D).

Cheers,

Julius

[Former Member]

Hi Julius,

Trust you are doing good.

We have only given S_ICF & S_RFCACL authorization access to our Security administrators and none of others users having this authorization access in all of my CUA destination systems.

I am again reattaching the Short dump information of User and Transaction error details for your reference & further analysis and necessary advice.

Client.............. 000

User................ "SAPSYS"

Language Key........ "E"

Transaction......... " "

Transactions ID..... "4DF80A4E6C1800F4E1008000AC137F50"

Program............. "SAPMSSY1"

Screen.............. "SAPMSSY1 3004"

Screen Line......... 2

Information on caller of Remote Function Call (RFC):

System.............. "PRD"

Database Release.... 620

Kernel Release...... 640

Connection Type..... 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)

Call Type........... "synchron and transactional (emode 0, imode 0)"

Inbound TID.........." "

Inbound Queue Name..." "

Outbound TID........." "

Outbound Queue Name.." "

Client.............. 100

User................ 114715

Transaction......... " "

Call Program........."SAPLARFC"

Function Module..... "ARFC_DEST_CONFIRM"

Call Destination.... "PSOCLNT300"

Source Server....... "XYZprd07_PRD_99"

Source IP Address... "XXX.XX.XXX.XX"

Additional information on RFC logon:

Trusted Relationship "X"

Logon Return Code... 6

Trusted Return Code. 0

Above dump attached user is (User................ 114715) business users. Pls clarify me do you want me to allow this authorization to all of my end-users (business users)? If yes, then why they need this access?

Pls help me to understand the System behavioru2026Really appreciate for your help.

Regards,

Asif

[Bernhard_SAP]

Hi,

so you mean that the 'new' changlog report RSUSR100N doe not provide the information you require?

b.rgds, Bernhard

[Former Member]

Hi Bemhard,

Report RSUSR100N is much better tool to find out the change documents for users from CUA System but unfortunately my audit team is not fully satisfied with this.

Few Examples:

When you look into CUA Roles change documents for indirect Role assignment from CUA System, we could see changes under Changed by Tab is RFC user (rather they need actual consultant id) and under Transaction code Tab is showing PFUD@(Logical System Name), however for direct Role assignment behaviour is satisfied.

Under User Created changed document window, results are reflected from the day of User Transfer to CUA System not the actual date of user-id created in Target System.

Behaviour of User Created and CUA Systems (added) are not in Sync.

Change documents for License Data are not available.

Hope you have got my points.

Regards,

Asif

[Former Member]

Hello Experts,

As per the above recommendations I have given authorization for the following objects under my child system to few of the users, in order to make sure the child side authorization check is working fine.

Authorization Check for ICF Access S_ICF

Authorization Check for RFC Access S_RFC

Authorization Check for RFC User (e.g. Trusted System) S_RFCACL

Initially authorizations was given for specific Target Host Destination and SYS id and then later on changed it to * (full access) for all the fields values but it wont help.

Unfortunately we are still getting below given short dumps in CUA Solution Manger System.

CALL_FUNCTION_SYSCALL_ONLY

CALL_FUNCTION_SINGLE_LOGIN_REJ

Pls advice on how to fix this.

Regards,

Asif

[Former Member]

Check out the following links for help. Looks like they should provide you mrowe insight into your system and its configuration leading to the short dumps.

/people/rajeev.p/blog/2010/07/31/top-10-abap-dumps

http://help.sap.com/saphelp_nw70/helpdata/en/22/042671488911d189490000e829fbbd/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/f9/3f69fd11a80b4e93a5c9230bafc767/frameset.htm

Thanks,

Matt

[Former Member]

HI Matt & Others,

Just for your information. Short dump issues have been resolved.

Finally below given options works fine for us.

1. Only one way Trusted Communication maintained with current user option i.e., CUA to All Target Systems.

2. Target Systems SYSTEM users for Normal RFC Communication have been created in all the other child Systems and CUA along with Special authorizations.

3. SCUM field parameters: Redistribution from Target to Central System restricted.

Regards,

Asif

[Former Member]

Asif - glad to hear all is fixed and working.

[Former Member]

Hi Matt,

Indeed your help is much appreciated.

Many Thanks,

Regards,

Asif