S_RFC & BAPI Excel ???

[former_member312761]

hello,

I have a question VB scripting stuff in Excel using BAPI.

Which authorization object must be added, whether it be S_RFC and specific functional groups? Can I possibly give a *, and the power to BAPI will be with current user privileges in the roles?

BR,

T,

[Former Member]

Hi Tomsie,

Which authorization object must be added, whether it be S_RFC and specific functional groups? Can I possibly give a *

Yes. S_RFC with activity 16, and function group * is okay. I recommend check this fantastic article [How to Connect to SAP R3 and Call BAPI from MS Excel VBA|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/608058b4-81b7-2910-4598-8a66dcdba0a8] that gives all the required information on achieving this.

Regards,

Raghu

[Former Member]

Hi,

Restrict the S_RFC access to only the FUGR's you need - this will depend on how you have set parameter auth/rfc_authority_check but should be very easy to pick up what's needed in a trace. As a general point, don't give full access to this object.

For the rest of the access, I wouldn't rely on picking up the auths from the roles. It's a bit of a hit-and-miss approach and really depends what you are trying to achieve through the excel interface. If we can have a bit more info about what it will be used for then we can advise.

[former_member312761]

users want to run reports, download data from Excel using VB.

If you get permission S_RFC:

ACTVT - 16

RFC_NAME - *

RFC_TYPE - FUGR

Whether or not you will be able to perform other actions than those that are in their roles?

BR,

T.

[Former Member]

Hi,

Yes. This should get the required access. However, as mentioned by Alex, put a trace to find out if any additional Function group authorizations are required.

Regards,

Raghu

[Former Member]

users want to run reports, download data from Excel using VB.
> If you get permission S_RFC:
> 
> ACTVT - 16
> RFC_NAME - *
> RFC_TYPE - FUGR
> 
> Whether or not you will be able to perform other actions than those that are in their roles?
> 
> BR,
> T.

Hi, Don't give RFC_NAME - *. Restrict it to the FUGR's (or FM's) that they actually need.

If they are getting data from SAP then don't rely on their existing auths to get the info properly. I would also question why they are not using the many standard reporting frameworks (standard reports, report painter/writer, sap query, BW etc) to get the data in a unified and consistent manner.

[Former Member]

Hi Alex,

When you are using VBA, does it really matter with giving * for the RFC Names, since the Excel only picks up the data from the system using a communication user which has restrictions already??

Please clarify.

Regards,

Raghu

[Former Member]

Hi Raghu,

It really depends on how it's being used. The OP was talking about current privileges in the users roles which indicates that it will be the end users that require the additional access as they will be initiating RFC connection with their own ID through VBA in Excel. In the same way that I wouldn't want S_TCODE = *, it would effectively be doing the same for RFC's. Even if it's a comms user it's still best (in my opinion) to restrict the ability to start FM's through S_RFC.

Cheers

[Former Member]

Alex,

Thanks for the clarification. But, it was just mentioned that the users will be using Excel to run reports. Might be you are right, if they are using their own user Ids to login from Excel. But, if if a communication user is used for reporting purpose, I hope it is okay to give a * to the function groups.

Thanks again for your answer.

Regards,

Raghu

[Former Member]

Hi Raghu,

I still wouldn't give * but each to their own. For an important auth object it's not too much extra work to restrict properly

[Former Member]

For an important auth object it's not too much extra work to restrict properly 

Agree

[martin_voros]

Hi Raghu,

one of the basic principles in security is POLA - Principle of Least Authority. If you don't follow this basic principle than you are really asking for trouble. Giving authorization to run any FM is a really dumb idea.

Cheers

[Former Member]

Note that as of release 7.10 the RFC_TYPE field domain is extended to include FUNC in addition to FUGR. This means that you can control RFC at the function module name level if you first let the function group check fail.

Much more granularity can be achieved this way and it makes building roles much easier because you can add the fuction modules to the menu and maintain FUNC as an SU24 proposal.

Cheers,

Julius