RFC Authorizations

[Former Member]

All,

I am currently facing authorization errors with a RFC user created. The systems in questions are ECC and SRM. I have created the RFC user with usertype "System" and authorization profile S_A.SCON.

The current error is to do with function group ERFC, which I have added to the profile. Still need to test though.

My question is wether the above authorization profile is sufficient or I have no other option but to user SAP_ALL / SAP_NEW.

Thanks,

AJS

[Former Member]

Hi Avinash,

Why assigning profiles directly?? I would suggest to create a role and assign it rather than going this way. You would have better control over the authorizations of RFC user if you yourself create the role and provide necessary authorization.

[Former Member]

Hi Akshay,

Yes, I've used the role. However wanted to know if the authorizations that are part of the auth profile mentioned were sufficient.

Wherever I look, SAP_ALL seems to be assigned and I am not comfortable doing that.

It appears that this might take time to fine tune and that's the reason why SAP_ALL come in handy !!

Regards,

Avinash

[Former Member]

Hi Avinash,

Refer to below pdf:

http://help.sap.com/printdocu/core/Print46c/EN/data/pdf/BCSRVCOM/BCSRVCOM.pdf

Profile S_A.SCON has authorizations for RFC communication but we have found several instances that this profile do not have all the necessary S_RFC auth groups for which an additional role has to be created and assigned to the RFC user. Or else add the missing auth groups to this profile.

[Former Member]

Never assign SAP_ALL.

Go to SMP/notes and search with keywords: minimal +authorization + RFC (39 hits for various combinations).

Same goes for SDN and especially this forum. Julius held a nice lecture on that one, once ...

[Former Member]

Gosh! A link to a document on BC-Sapconnect from April, 2001 ...

... no wonder that profile fails to serve you correctly ...

And never, never change a SAP profile - not the original ...

[Former Member]

Hi,

You can create a new role

Authorization menu> change mode>

manually add authorization object "s_rfc" and maintain the appropriate acvtivity & generate the profile and assign to the user

Thanks & Regards

Gangadhar

[Former Member]

Hi AJS,

You are on the right track.

If you look in the FAQ thread, there is a link to the security wiki where I have documented a lot of infos on securing the various types of RFC. It is not complete for all types, but will help you.

It is very tricky and hard work, but once you have understood the concepts available then it is smooth and secure sailing.

Tip 1: If you build role menus for the users with saved logon data from the function modules and not the transactions, then you can maintain SU24 to such an extent that you can even achieve roles with ALL standard authorizations only.

Tip 2: You must restrict the users in development systems already. Developers should maintain SU24 for the RFC's they develop. At that ponit in time they know most about the application use-case. Do not use transaction codes and be wiery of any S_TCODE authorizations included - even the sacred SU01 which makes all the correct checks does not check it in all it's BAPI_USER* RFC's.

Cheers,

Julius

[Former Member]

Julius,

I now run into the below error and have no clue whatsoever about my next move: The status shows "SYSFAIL" in SMQ1 on the qRFC Monitor (Outbound Queue). I also get the below information window:

"Structure 01 CP 50002975 CP-S-O: No agent found:"

When I try to debug it in SMQ1 I get the message "Function Module Does Not Exist or EXCEPTION Raised"

Where do I look for a solution to this message? Nothing online even remotely similar to the error above.

Thanks,

AJS

[Former Member]

Sounds like faulty config to me. This is often the case, and not authorizations.

Check in ST22 whether there is a more detailed dump there. Don't post the whole dump!

Cheers,

Julius

[Former Member]

15 runtime errors in all, however nothing for the user there. What else can I check?

[Former Member]

Then we don't have much to work with, except instinct.

To me this looks like an evaluation path and a workflow (hence you cannot debug the function module) is trying to send a workitem to a user which does not exist in the org structure.

Is this a test user in a development system with little data in it?

Sometimes tracing and even unit tests makes more sense in a test system (QAS) and then building the role for it in DEV.

If you can reproduce the original error, then turn a developer trace (ST11) on and run it again. If you want to debug it, then change the user type to SERVICE in the workflow engine and single-step the FM in system debug mode (/hs)

Cheers,

Julius

[Former Member]

Yes, since we are attempting to build a role to suit, it is being execute between the SRM DEV and ECC DEV system.

I am not in a position to reproduce the error, will ask the user to repeat the sequence after I have turned the trace on. What should I be looking for in the trace? Also, how do I go about accomplishing the below:

"If you want to debug it, then change the user type to SERVICE in the workflow engine and single-step the FM in system debug mode (/hs)"

Tx,

AJS

[Former Member]

> Yes, since we are attempting to build a role to suit, it is being execute between the SRM DEV and ECC DEV system.

The assign SAP_ALL temporarily to verify whether it really is authorizations or faulty config.

> I am not in a position to reproduce the error, will ask the user to repeat the sequence after I have turned the trace on. What should I be looking for in the trace?

St22 in the target system is your friend for config and RFC related errors (not authorized or function does not exist). If it is an exception, you will need to look deeper. Is there anything in SM58?

> Also, how do I go about accomplishing the below:

>

> "If you want to debug it, then change the user type to SERVICE in the workflow engine and single-step the FM in system debug mode (/hs)"

When debugging skips the remote function call, then change the user type to SERVICE and make sure that the user context of the RFC call has S_DEVELOP authority (DEBUG display should be enough..). Set your break-point immediately ahead of the CALL FUNCTION with DESTINATION extension. When you hit the break-point, open the menu and select "system debugging". Hit F5 to step into the function on the remote system. The external debugging session will show arrows to inform you from / to your RFC debugging is being performed. Your authorizations in the debugger are those of the user in the target system where the FM is.

Cheers,

Julius

[Former Member]

Had to revert to SAP_ALL. Impatient requestor ...

[Former Member]

Used SAP_ALL

[Former Member]

Pity about that.

If you want to secure RFC connections you generally only have one chance and have to provide timely guru support, otherwise "impatience" for it sets in very quickly.

It is not the sort of thing which can be done remotely in my opinion either. At least, not without becoming a failure to achieve the security aspects of a good project...

Cheers,

Julius

[former_member266763]

Hi ,

Well , i was just searching for some thread, and checked this one...we were implementing Mobile Direct Store Delivery MDSD, and we used to have this error , in our case it was due to incomplete master data,

To what i remember , it wasnt due to authorization...but u make sure.. It might help

Thanks

Adnan

[Former Member]

In my experiences it is also faulty config, master data (ine)quality and convenience features which lead to problems.

For some of them, you can throw authorizations at the problem for a while...

Cheers,

Julius