S_rfc in a common role

[Former Member]

Hello everyone !

i want to merge two roles , one is the common role that every user has and the other one is the Firefighter role for accesing the Firefighter tool .

My question is , how critical is it , if i add the object S_RFC in the common role which is needed for the firefighter. The fields of S_RFC are : actvt :16 , RFC_NAME: syst and RFC_TYPE : FUGR.

Have in mind that the role i want to add the s_rfc is used by every user ,

Best regards,

David

[Former Member]

> i want to merge two roles , one is the common role that every user has and the other one is the Firefighter role for accesing the Firefighter tool .

Then every user in your system will access the Fire Fighter tool?

> My question is , how critical is it , if i add the object S_RFC in the common role which is needed for the firefighter. The fields of S_RFC are : actvt :16 , RFC_NAME: syst and RFC_TYPE : FUGR.

It depends. There is a SAP note which describes the minimum S_RFC authority for different scenarios.

The Fire Fighter tool uses the remote login approach to generate a new session via a temporarily modified RFC connection. It (the FF user account) will need SYST in that case.

> Have in mind that the role i want to add the s_rfc is used by every user.

I am sure that your Fire Fighter role has more in it than just this RFC authority. Is that not of greater concern to you?

Cheers,

Julius

[Former Member]

Hello Julius ,

yes every user will be able to use the Firefighter tool. But only the ones that will have a FFid assigned will have more privileges ofcourse.

I know that the FF uses S_RFC to generate a new session. I am just wondering if the S_RFC will give the user other critical rights.

The FF role has only two objects , one s_tcode with /virsa/vfat and the s_rfc as described..

What do you think of this approach ?

regards,

David

[Former Member]

No ..Unless the User ID is assigned as to a FFID AND the user has the ability to inititate the FF TCD user will not have access to FF ( Which is part of GRC ) wnated to mention this as the readers may be lead to beleive that if they have an access to s_rfc they have access to FF too.

There exsists an explicit method to assign the FF to a dialog user.

[Former Member]

Are you sure that the caller has to be a dialog user?

[Former Member]

Julius,

Yes The Dialog user id calls a FFID which is a service user.

Now to David,

I understand that you have a concern with S_RFC as it gives acces to FFID -No It doesnot !!!

Unless the FFID ( Service user) is assigned to a dialog the no user will ever have access to the FFID.

Moreover any ativity through aFF is imediately notified even before the activity begins !

Thankx

[Former Member]

Hello George G ,

If you read my thread , i dont say that with S_RFC object users can access FFID.

I said that with the role we created someone can access the tool and the role has two objects as mentioned . Accessing the tool , i dont mean accessing FFID unless there is a FF assignment .

I kindly ask you to read the entire thread before posting Maybe it was my fault trying to explain exactly what my purpose was. Just put aside GRC for this thread please.

My only question so there are no misunderstandings is : Could all users have the S_RFC object with the values as mentioned ? I understand it is a critical object , but is there an explanation as well ?

Edited by: David Damaskinos on Dec 18, 2008 1:37 PM

[Former Member]

The FFID will need RFC authoritity for SYST, as itself is the user context via which the destination is called to generate a session. These functions are described as "non-critical" functions for "internal" system stuff.

If your other users have all not needed this before, then they will also not need it now either.

It still sounds to me as if you are wanting to add this authority to the universal role, so that you can add it to the FFID as well via that way.

In that case what you get for it is that the FFID can itself also start the Fire Fighter again to request yet another FFID, and all your users can also use themselves in RFC connections to generate sessions in the system.

Whether or not that is critical, is up to you as we obviously don't know the rest of your setup.

Hope that helps to narrow down the "grey area" a bit

Julius

[Former Member]

David,

I would love to keep the GRC stuff aside but unable to as the post itself revoles around combinig two set of authorization one beign the FF which is part GRC - and a general role so it cannot be moved out.

S_RFC as regards to the FF role ( There are various roles in FF I dont know which one you are mentioning here unless I know the contents of S_tcode of FF role ) is also used to communicate between two FFIDs -- for example when one is in "red " and there is another person who wants to use the same ID can message him by clickin on the " message icon".

If your fear is-- due to the presence of this object in FF role if the assingee can aceess wider authorizations of FF roles answer is a BOLD NO. The reason for this stout no is mentioned above in many words.

The other option of S_RFC object in common role doesnot arise as the object is absent in the common role !

can you please mention the contents of S_TCODE in the FF role ? If it has any entries apart from /Virsa/vfat

Then please donot combine the roles !!

Also david --I read in your post " They can use FF tool but cannot use the FFID " The user then access the FF "Tool " for what ??

[Former Member]

Hello Julius ,

thank you once more for your informations and understanding.

You have right , i want to add the Firefighter role to the universal role which every user has. The firefighter role is only a role to access the Firefighter Tool (not to use FFID ofcourse), so it includes only the S_tcode : /n/virsa/vfat and the s_tcode :S_rfc.

The reason we need this , is because the users that will use FF-IDs are not known yet , so it could be anyone from the business area. Its is a step to avoid the FF role assignment to the users when they need access to the tool . A different person will be ofcourse responsible for making the USER-FFID assignment.

You said aswell correctly that

all your users can also use themselves in RFC connections to generate sessions in the system

if they have the S_RFC. This is my only concern and i am still looking for information in that field.

cheers,

david

[Former Member]

If you are sure that is the only authority required, there is no additional risk from the user logging on via RFC instead of via SAPGUI and do not want any other functions which are not used, then from release 7.10 you can tweak the RFC authority further to restrict it to the function module name and not the function group.

In that case, use:

S_RFC rfc_type = 'FUNC' (not FUGR) and in the rfc_name field add 'SYSTEM_REMOTE_LOGIN'.

The users (as will as the FFIDs) will be able to additionally perform a remote login, but not call other functions from the group remotely. Of course, once logged on, they will be able to call those functions locally, but only within the program context they have access to (such as the coding off the FF transaction). At that point, you need to rely on the security of the coding of the transaction when being used, but that is generally a good thing to achieve (and review) as well.

See [SAP Note 931251|https://service.sap.com/sap/support/notes/931251] for further infos on distinuishing between the group name and the function name. The value range of the domain of the field will of course also need to be extended so that you do not grant a '*'.

Hope that helps you further,

Julius

[Former Member]

Hi,

Yes, Please merge with S_RFC with Firefirhter Role. its secured & required. let me know if you need any more details.

while using FF ID's all the tcodes stored in log file.

[Former Member]

My question was if it is secure to merge our FF role with the basic role that all users have.

The FF role has , as mentioned , only two objects , S_tcode and S_rfc. My question is not really realavant with the Firefighter tool

If all users , after the merge of the roles , would have the S_rfc object with values as described , would there be a lack of security ?

[Former Member]

Its definitly a lack of security..you need to careful with what we are assigning to end users.

You can create a new composite role by combining these two roles and assign it to only those user who require it.

[Former Member]

Can you be a little more specific with security lack issue ? We have a situation, where i wanted not to assign to each user the FF Role , but to implement it to the role every user has.

If i create a composite role and assign to the user that actually need the role , then i am back to my first situation where the role exists and i need to assign the role to every user .

Thanks for your effort and help!