In what case would you assign transaction to System User Type?

[marianne_peterson]

I am an ABAP developer who has been doing some very basic security research, and I want to ask what I think are some fairly simple questions to which  haven't been able to find any really good comprehensive answers.

We have a number of ids that are defined as System user types and are used for communication with SAP by some of our web apps where the users are not SAP GUI users.

The questions I have are as follows:

• Is there any situation where a system user type should be assigned a transaction?
• If there is, explain why.  (Maybe a call transaction within a function group/module that is assigned through S_RFC?)
• How serious are the security risks associated with assigning (a) transaction(s) to a system user type? (I'm thinking if somehow, the id was assigned a function module or function group that it should get assigned and has access to a transaction which is in a role that gives it update capability, that would be an example of a good reason why transactions shouldn't be assigned).

I am nowhere as gifted in this area as all the experts, so I thought I would pose the questions to all of you.

Thank you in advance for your help.

[former_member298454]

Hi,

System user type has two significant properties

- Dialog logon is not possible with this

-Security policy will not applicable for this user type( ex : password length, password expire time etc)

This id is most commonly used for RFC communications , BATCH Job configurations.

In security , Tcode will be assigned to users through roles and no risk involved in assigning access to system users.

Always options are there to track the actions of user if required.

Thanks,Krishna

[marianne_peterson]

I was aware that dialog logon is not possible here.

I understand that the password does not expire.

I know that it is most commonly used for RFC communications and Batch Job configurations

The response you provided doesn't answer any of the questions that I asked.

You can assign a role with a transaction in it to a system user.  If this is done, WHY would it be done?  What reason would one have to do this and is there a security risk?

The only reason I could think of for assigning a role with a transaction in it is to do a CALL TRANSACTION from an RFC that has been assigned to this system user within S_RFC.

But please provide answers to all of my three specific questions if you can.

[former_member298454]

- If batch job (ABAP report) which perform action on tcodes (Su01, Pfud etc) then the job owner (system id ) should have access to these tcodes with sufficient authorization objects to complete the operation .

S_RFC is just control the execution of the FM if it is accessed remotely, it will not influence anything in accessing transactions.If system user calls one FM through  batch program locally it will not check for S_RFC.

if FM calls one transaction (Su01) then user should have Su01 tcode access which should be checked at kernel level S_TCODE then it will go further checks based on actions on SU01(user change  , role assignment etc)

- Common approach is to give SAP_ALL to system users which can be avoided by giving the precise access to each system user by understanding its usage ( ex : You  need to figure out the authorizations required to execute an ABAP report and set up the role for system user , In RFC interface too ) .

Hope this may help !

Thanks,krishna

[Former Member]

Hi Marianne

1. Batch users (system user type) are often required to execute programs which may call transactions, perform BDC sessions using real transactions, processing failed IDOCS etc.  Where there is this requirement then the system user will need to have that authorisation to perform the task and transactional access is necessary.

2. Please see above.

3. The risk of assigning transactional access is usually considered to be within acceptable levels. Many system ID's have SAP_ALL which, while not a great idea for so many reasons, is at least tolerated by most risk managers.  Generally it's expected that access to schedule jobs using system users is restricted to only those who need to do it (system admins & in some cases superusers depending on use cases).  It's also expected that the system user has access proportionate to the task they perform.  If we use external audit as the ultimate reference for risk (has it's drawbacks but it is what it is) then it is unlikely that a serious deficiency will be raised due to a system user having some transactional access.  More concerning is lack of restrictions over the general user population being able to manage batch jobs (including switching userID for execution).

Hope that makes sense.

Cheers

[Private_Member_69416]

Hi

Calling function module require not only S_RFC authorizations but other authorization objects too.

If you calling a code with check for S_TCODE inside you must add transaction to user role.

Adding transaction don't mean you give everything.

There are other authorizations objects inside to check access and should be assigned (or not) too.

Of Course - customer code can be written without any authorization checks and be great security threat

1. Yes

2. Authorization object checks in executed program

3. Identical risk as assigning it to any user. Don't need it don't do it.

Regards

Przemek