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: 

SAP_ALL authorization for "system" user type

Former Member
0 Kudos

We have few RFC users between BW, APO and E-Rec systems to exchange data or data extraction. We have created them as a "system" user and assigned the SAP_ALL. I would like to know whether is it ok to assign SAP_ALL to system users or we need to drill down to limited authorizations.

If we need to remove SAP_ALL, than how to find the authorization required by these RFC SAP ids. Do we need to activate the trace individually for them or providing S_RFC and S_RFCACL with full access will be enough.

Thanks in advance/

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Particularly in the case of system users with saved logon data (in connections such as those defined in SM59) it is important to limit their authorizations as one does not need to know the password or intercept it - you simply run the connection and call your RFC in the remote system and the system will authenticate the user in the connection data.

You can compare this to an anonymous remote control of the SAP system which can only be meaningfully controlled via restricting the access.

Unfortunately it is a rather tricky and very error prone procedure to restrict the access or retro-fit the correct users (and user type) in the connections. Typically you also only have one chance after which you are never allowed to go near an RFC connection again because you are famous in the company for causing 1000's of short-dumps and delaying the month end reporting...  😉

However there are some gurus at SAP who have made a fine art out of this (I also contributed a bit to the methodology and tools) and if you want SAP to fix your connections for you, then see SAP Note 1682316 for more details of your options.

In addition to the "best practice" approach and experience of what will be needed (e.g. at month end..) the roles are built upwardly-compatible until release 7.31 and alert you with hints if security related SAP Notes affect RFCs which you actually use.

Cheers,

Julius

7 REPLIES 7

shivraj_singh2
Active Participant
0 Kudos

Sameer,

SYSTEM Users are used for system-related processes like ALE, CUA, TMS or internal system processes like background processes

Use users of type Communication for dialog-free communication between systems i.e RFC or CPIC

Assigning SAP_ALL is never a Best Practice. You can search & use SAP delivered roles according to your need.

Regards,

Shivraj

0 Kudos

The usage of user type "SYSTEM" is correct for any kind of technical users!

There still exists some misleading documentation about the user types but the truth is described in note 327917: Forget user type "communication" but use user type "system" for all techical users which are running background jobs or RFC functions.

Here are some tipps to define authorizations for S_RFC:

How to get RFC call traces to build authorizations for S_RFC for free!

(If you are using Trusted-RFC than you need additional authorizations for S_RFCACL. Well, I assume, that you manage this part wjich is not too difficult. Just keep in mind that you should avoid '*' authorizations for RFC_USER. This is very important.)

In addition to restricted access to S_RFC remove at least some of the most critical authorizations: Copy SAP_ALL into a new role and deactivate authorizations for S_USER_*, S_DEVELOP, S_TRANSPRT, S_ADMI_FCD, S_BTCH_ADM,  S_CTS_ADMI, S_BTCH_JOB, S_TCODE (if not used for batch input), S_TABU_DIS, S_TABU_RFC (if not needed), etc.

--

Frank Buchholz

SAP Actice Global Support - Security Services

Former Member
0 Kudos

HI Sameer,

You can actually use the SAP_ALL for system user if you can protect the password as it is only working with RFC but no user is using that.

In turn if you go to PFCG there are 30-35 roles predefined by SAP for RFC. Please go though them and select a suitable for that suits you need.

Thanks

Kanth

0 Kudos

Hi,

Are you really sure that you can protect password? Is every RFC call performed over SNC?

In security you should always start with zero authorization and then just add required authorizations based on requirements. You should not start with full authorization and then remove unwanted authorization. There is a chance that you forget to remove critical authorization. Especially, this is true in complex system such as SAP. Hence I would not suggest using SAP_ALL.

Cheers

0 Kudos

Thanks everyone for the suggestions.I came accross one note  Note 338537 - RFC user authoriz. for data exchange R/3 back end <-> CRM. Here they have mentioned that Non-interactive user can be assigned with all authorizations(means SAP_ALL). Is the same can be applicable for RFC user in E-recruitment system to import/export data from R/3 system. 

Currently SAP_ALL is provided to the RFC user, even if I enable the trace I am not sure for how long I have to activate it to trace all the authorization. From security point of view,  we are not sure which data is excahged and do not want to replace the profile with limited authorization and issues to happen due to missing authorization.

Former Member
0 Kudos

Particularly in the case of system users with saved logon data (in connections such as those defined in SM59) it is important to limit their authorizations as one does not need to know the password or intercept it - you simply run the connection and call your RFC in the remote system and the system will authenticate the user in the connection data.

You can compare this to an anonymous remote control of the SAP system which can only be meaningfully controlled via restricting the access.

Unfortunately it is a rather tricky and very error prone procedure to restrict the access or retro-fit the correct users (and user type) in the connections. Typically you also only have one chance after which you are never allowed to go near an RFC connection again because you are famous in the company for causing 1000's of short-dumps and delaying the month end reporting...  😉

However there are some gurus at SAP who have made a fine art out of this (I also contributed a bit to the methodology and tools) and if you want SAP to fix your connections for you, then see SAP Note 1682316 for more details of your options.

In addition to the "best practice" approach and experience of what will be needed (e.g. at month end..) the roles are built upwardly-compatible until release 7.31 and alert you with hints if security related SAP Notes affect RFCs which you actually use.

Cheers,

Julius

0 Kudos

Thanks Julius. I will send a mail to SAP to get the details..hopefully the tool wil be in our company's budget. Will check for its other benefits to us.