Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to create RFC Destination without using SM59?

Former Member
0 Kudos

Hello all:

We are troubleshooting an issue. An user created a RFC destination. He claims that he did not use SM59. We checked his access and do not have SM59 in his roles.

He configured VIRSA FireFighter. During the configuration, he created RFC destination. Document says use SM59 or contact BASIS Admin. He claims that he used a config table and he don't remember the config table name. RFC screen shows his ID as creator of the RFC.

We are trying to understand how an RFC can be created (outside of SM59) and plug the security hole in the environment.

Any insights would be appreciated.

--Anand

1 ACCEPTED SOLUTION

Former Member
0 Kudos

The FireFighter solution changes the RFC destination of the service user "on the fly" without S_TCODE checks for 'SM59'. But if I can remember correctly when looking into this, it does not create the RFC destination (in SM59) "on the fly".

> He claims that he used a config table and he don't remember the config table name.

Theoretically this is possible - a config table to define the name of the destination, and then create it if it does not exist yet (when used).

Otherwise, see SAP note 587410 and restrict (remove) his authority for the test environment (concentrate on S_DEVELOP, not S_TCODE - as you have also experienced).

Cheers,

Julius

7 REPLIES 7

Former Member
0 Kudos

The FireFighter solution changes the RFC destination of the service user "on the fly" without S_TCODE checks for 'SM59'. But if I can remember correctly when looking into this, it does not create the RFC destination (in SM59) "on the fly".

> He claims that he used a config table and he don't remember the config table name.

Theoretically this is possible - a config table to define the name of the destination, and then create it if it does not exist yet (when used).

Otherwise, see SAP note 587410 and restrict (remove) his authority for the test environment (concentrate on S_DEVELOP, not S_TCODE - as you have also experienced).

Cheers,

Julius

0 Kudos

Julius:

Thanks for the response. We went through the change documents for the user when RFC was created. We created a test ID in DEV system with same access as the user. We tried SM59, tried to upload RFCDES table and tried to execute SAPMCRFC via SA38 and SE38 to get to SM59.

Finally we checked S_DEVELOP auth. objs. The test ID is not able to execute any of the above said actions and S_DEVELOP has same access in PROD and DEV.

Again thanks for the response.

--Anand

0 Kudos

Hi Annand,

> The test ID is not able to execute any of the above said actions and S_DEVELOP has same access in PROD and DEV.

What is that access? Please post the authorization values.

Cheers,

Julius

0 Kudos

Julius:

Here are the S_DEVELP values:

Maintained ABAP Workbench

Activity 03

Package *

Object name *

Object type *

Authorization group ABAP/4 pro *

Thx.

--Anand

0 Kudos

Depending on your release, 03 would be enough to execute (SAPRL < 6.40). See the note mentioned above. Note that the user is also authorized to debug, so they could stop certain programs if they wanted to.

Another possibility is to help him remember by deleting the RFC connection for the FireFighter and turning the audit log on (see and test the dynamic filters) to see what comes up next time...

Cheers,

Julius

former_member248712
Active Participant
0 Kudos

You may also check the FireFighter ID Log Report if his ID was assigned to one for the FireFighter ID, that would give a Temp access to SM59.

AB

0 Kudos

AB:

This was done at the time FF config and hence no FF logs from that time.

Thx.

--Anand