Question:
Have any of you used trusted RFC connections instead of the CUAADMIN ID in CUA with appropriate controls on S_ICF, S_RFCACL, and S_RFC?
Instead of the normal CUAADMIN ID in the SM59 RFC connection it would be changed to a trusted connection for current user. In addtion the other trusted transactions are used smt2/smt1.
Just a thought. It would also make the change docs in the child system easy to read with the real ID of the person who changed it instead of always showing CUAADMIN.
Cheers,
The_Bean
Answer:
To be the most secure you should not have an ID or password in the SM59 destination at all. ANYONE can use the RFC destination and get to the other systems if the ID and password is in the RFC destination .
The most secure is to NOT put the ID in and require the user calling the target system logon, this verified the pweson using the call, records all change dosument in the target system to be the person actually calling the target system, and you can limit the access by person and not have to make it generic or too broad.
Trusted system have the same problem. ANYONE can use the RFC destination, SAP does not control on whether a person is authorized to use an RFC or not (long contention with SAP on my part), if it is defined the user can use it.
Down side is Every NEW call to the other system requires a logon.
_________________
John A. Jarboe
Answer:
John,
I agree with you that not having the name/password within the RFC destination is most secure. If you had to pick between using an RFC destination with name/password versus using a properly controlled trusted RFC for each level (dev, qa, prd) within the system landscape which would you go with?
No RFC's from a lower level system to higher level system. IE DEV to QA or PRD.
the_bean
Answer:
I personlally only use CUA to maintian Production enviroments and logon the QA and DEV directly. If you use CUA to maintian all, then source out of production and send the data out of Prodution to the other systems. This is a bit more secure, not ideal as there is a a way back into Production if you know how.
The potential problem of a trusted system is the target ID used. If the ID is a communication ID or Service ID then the Password does not expire and no DIALOG session can be established. If the trusted path is designed and you want accountability from the person who initiated the update then IF a trusted system works as you expect then that path can be used to open a dialog system into another system. Once there anything can hapen, even returning back to Production.
Unless there are recent changes, CUA sends ALL the Records for and ID to All the system when a change is made and if you are maintianing MANY that can load your network needlessly. There is no selction in CUA to check what you want maintianed so when you make changes to and ID ALL records (master data, Parameter IDs, Roles, Profiles, etc) old, new and changed get sent to the various systems the ID exists in and has to be processed in each system even though nothing changed. You then have to BD85 periodically in all the target systems anyway to ensure all was processed. The "all is saved" message in CUA does not verify if the data made it to the target or if it updated the database.
_________________
John A. Jarboe