CUA - "Last Changed by" error

[Former Member]

Hi Friends

I am not sure if you have come across this issue. When I make some changes in CUA regarding a user, in the field "Last changed by" field below the user, it does not show my name after i save it.

When i come out from SU01 and login back and check the user, still " Last changed by" does not show my name even if I was the last person who modified the user. It shows some other persons name. Don't know if there is some kind of a lock which needs to be resetted?

Any ideas?

[Former Member]

Is this in the CUA master or a child system. The CUA change records in a child system will be under the name of the system user which processed the IDOC

[jurjen_heeck]

> Is this in the CUA master or a child system. The CUA change records in a child system will be under the name of the system user which processed the IDOC

In addition to this, role assignments for child systems are appearently not considered to be changes to the user in the master system. Puzzled me too in the beginning,.....

[Former Member]

> Total Questions: 94 (86 unresolved)

[Former Member]

If you use trusted RFC connections and select "Current User" for authentication the change will show your ID or that of the person who made the change. We had initially set up our CUA landscapes without the trusted connections. Therefore when we were looking for who made a change we would find CUA_S31_100 for the user making the change.

Now that we have switched to trusted connections, it will show for example E0066332 the user ID of the current user. For this to work properly the user must have the *_TRUSTED_RFC role assigned to them.

Hope this helps

Todd

[charmaine_greene]

Hi Todd

This is an interesting approach - auditors do have issues with this annoying audit gap in CUA.

I have known some companies to disconnect the production system from CUA for this very reason.

But I don't think this is fool proof solution because it will only work only if the user has your *_trusted_rfc role.

For this to work properly the user must have the *_TRUSTED_RFC role assigned to them.

So there is still a risk that changes will not be captured if someone makes an incorrect role assignment or if some idocs fail to go through.

Regards

Charmaine

[jurjen_heeck]

> or if some idocs fail to go through.

And that brings along the problem that all changes in the children get the changed-by-name of the person who (re-)distributes the idocs rather than the one actually making the changes.........

[Former Member]

Hi Charmaine-

Yes you are correct that it requires the user to have our *_TRUSTED_RFC role. However ensuring the appropriate personnel have this role assigned was part of my security design so it was included.

It isn't foolproof, it isn't the best way but at least for our implementation it is one of our tools to satisfy our auditors. Now, if I could get the CRMD_UI_ROLE_ASSIGN job to run on my child systems when CUA is connected I would be happy.

Todd

[Former Member]

Jurjen-

If I make a change via CUA, say creating a user, the iDOC is sent out and viewable via SCUL. Therefore the iDOC for the change is tied to who made the change. Otherwise I could log into CUA and make a change and then distribute those iDOCS under another user's login ID. That to me would pose a serious security flaw and risk as change docs, audit logs and such would be totally inaccurate. So I have to disagree and say the user who makes the change will be reflected in the iDOCS.

Todd

[jurjen_heeck]

> So I have to disagree and say the user who makes the change will be reflected in the iDOCS.

I was referring to SAP note 898213 which states:

However, it can sometimes happen that:
- You need to temporarily switch to background mode
- another administrator starts the distribution again by using Transaction SCUL without actually changing the data
- the tRFC queue overflows and the IDocs are therefore transferred by background job
- IDocs in the child system are not updated in the original sequence
In these cases, the user specifications are incorrect in the change
documents.

[charmaine_greene]

Hi Todd

And that brings along the problem that all changes in the children get the changed-by-name of the person who (re-)distributes the idocs rather than the one actually making the changes.........

I think what Jurjen means is that if idocs fail, any user can go into BD87 subject to authorisation of course, and push the failed idocs through to the child systems - the changed by field would show the user id of the user who pushed the idocs through and not the user id of the user who made the change in the first instance.

Regards

Charmaine

[charmaine_greene]

Hi Todd

However ensuring the appropriate personnel have this role assigned was part of my security design so it was included.

I would have assumed that you would have assigned this role to all users and not just to a subset. Does it really make sense tracking role changes for a selected group of users?

Charmaine

[Former Member]

Two points:

Jurjen, I stand corrected - you make a good point and you are correct. I had a situation where management was looking for the cause of a change in the system which caused significant problems. The person listed as initiating the change was not the person who made it, but the person who manually distributed users via SCUL/Systems. So, he was listed as the person responsible but it had been another user who had changed the authorizations.

Charmaine, the Security and Basis teams received *_TRUSTED_RFC.

Regards,

Todd

[Former Member]

> ... the Security and Basis teams received *_TRUSTED_RFC.

That still does not say much about the user context, necessarily.

Which values do you have for S_RFCACL fields?

Cheers,

Julius

[Former Member]

Sorry Julius, let me skip your question before I forget my thought here. Would it be possible to use either SE16N_CD_DATA or SE16N_CD_KEY report to view the exact table change for the user who performed the action through CUA? If possible would that bypass the person who distributed the IDOC and reflect the initial table change?

Just a thought.....

[Former Member]

Ok Julius here are the settings:

RFC_SYSID: SM1

RFC_CLIENT: 070

RFC_USER: E00*

RFC_EQUSER: N

RFC_TCODE: *

RFC_INFO: *

ACTVT: 16

[Former Member]

Using SE16N change docs: Those documents are only written when a special editing mode is used which is the equivalent to debugging system programs in change mode. The same user to be able to make the change, would be able to hobble your entire application security concept completely.

=> not a good idea.

Using Trusted RFC: This can be a good approach, but you need to be carefull. Field ID "RFC_EQUSER is dangerous, because the users can logon as each other (or the system will do it for them). Using remote programmatic logons in other user's contexts to get change documents to reflect what appears to be the correct name in a target system is in my opinion not a good design. Much too complicated and error prone. Also, the tcode is not restricted and the name suggests a SolMan system, so there is probably much more than just CUA available to remotely pretend to be or accidentally be someone else's ID. Personally, I would rather accept the change logs in the SYSTEM user's name, and want to control the security and change logs in the source system.

=> What is "RFC_EQUSER: N" needed for the "E00*" users?

Cheers,

Julius

Edited by: Julius Bussche on Jan 12, 2009 8:18 AM

[Former Member]

we can see immediate change in the "last changed by" was when we change the password for any user in CUA master system and for the master system