Limiting Batch Administration Access

[Former Member]

Hi

I've had a request from our Basis team to enable a couple of business users to run a batch job on a periodic basis. I've had a play around with S_BTCH_NAM, S_BTCH_ADM and S_TCH_JOB, but no matter how I configure them it seems as though I can't restrict access down to the specific job that users are required to run.

Has anyone any suggestions on a solution that would be acceptable to both audit and our Basis team? I thought about creating a t-code for the program via SA38, but this won't allow the users to schedule the job.

Any suggestions appreciated.

[Former Member]

Hello,

Please include those business user in S_BTCH_NAM and Restrict them for particular Job Group in S_TCH_JOB

Personally have not tried this is my assumption

Thanks,

Prasant K Paichha

[Former Member]

Did you try restrcitions on the object S_BDC_MONI?

[Private_Member_119218]

Right.

(1) Assign the program in question to an authorization group (program RSCSAUTH);

(2) Create a role containing the following authorization objects and values:

S_PROGRAM (P_ACTION = BTCSUBMIT; P_GROUP = <program's auth. group>);

S_TCODE (TCD = SM37, SM36);

S_BTCH_JOB (JOBACTION = *; JOBGROUP = *);

(3) Assign the role to the user;

(4) Explain how background jobs are scheduled via SM36 to the user;

(5) Profit?

Some things you should note:

(a) Maintaining an authorizations group for program can have side-effects -- users who previously were able to execute it are no longer able to do so due to missing authorizations;

(b) Authorizations groups are not maintained for a lot of (most) standard programs (shame on you, SAP) -- it's your job to do so as anyone can execute a program that is not protected by an authorization group (S_PROGRAM is not checked);

(c) Application-specific authorization are required in addition to the authorizations listed in (2) -- e.g. the user must be able to pass all the internal authorizations checks of the program;

(d) You might want to restrict JOBACTION in S_BTCH_JOB to specific activities but RELE is required;

(e) In addition to BTCSUBMIT in S_PROGRAM, you might want to permit VARIANT if the user should be able to maintain variants for the program too. Kinda risky if there are critical variants and they are not protected.

Enjoy!

[Former Member]

Cool post Martinsh!

One small comment though...

> (b) Authorizations groups are not maintained for a lot of (most) standard programs (shame on you, SAP) -- it's your job to do so as anyone can execute a program that is not protected by an authorization group (S_PROGRAM is not checked);

S_PROGRAM is tough enough to build an authorization concept for and S_TABU_DIS which makes a symbolic check even more so.

Imagine if all reports had authorization groups on them? You would either need to give all users that "ALL" or worse would be various subsets of them - in addition to those which already do have an authorization group on them.

If the report itself makes the correct authority-checks, then an authorization group on it is just a hassle.

If you find a lot of reports which do not make any authority-checks and do not have an authorization group on them that is a different topic. Typically, the best place to start looking for them is in the namespace Z, SAPLZ, SAPMZ* ...

Specifically for this case you can also consider transaction SMX only. They can schedule the job periodically in the background from the report transaction, but then subsequently only display it from SMX.

- If they want it deleted, then they need to go to a batch administrator.

- If they want to change the variant, then they go to tcode VARCH (no execute possibility).

Cheers,

Julius

[Private_Member_119218]

Julius,

I would prefer that SAP had maintained authorization groups for executable programs based on some rough classification which could further be enhanced by the customer on a as-needed basis, and changed the mechanics of S_PROGRAM check so that it is only checked when the user is working with the program directly, i.e. executing it from SE38 or SA38 or scheduling as a background job as opposed through a transaction.

But that's purely a preference. Either way works fine.

[arpan_paik]

(1) Assign the program in question to an authorization group (program RSCSAUTH);
(2) Create a role containing the following authorization objects and values:
S_PROGRAM (P_ACTION = BTCSUBMIT; P_GROUP = <program's auth. group>);
S_TCODE (TCD = SM37, SM36);
S_BTCH_JOB (JOBACTION = *; JOBGROUP = *);
(3) Assign the role to the user;
(4) Explain how background jobs are scheduled via SM36 to the user;
(5) Profit?

However addition to this also access to objects maintained in auth-check for the program in question need to be provided.

For part of SAP I have sail through some program where we can definately enter in the 1st screen by exucuting the program directly or through function mudule but in selection screen proper auth check maintained. And where auth maintained in TSTCA that is more secure. So even a user can execute a program then they might need access to relevent object as well.

Guys having access to SE38, SA38 or SE90 like transaction should not have access to buisness objects so in any case programs provides access to buisness data are secure in further auth-check section.

It is true if a program neither included in auth grp and nor have proper auth check are in risk. I guess SAP did not leave any sensitive such programs open :). I guess.

Arpan

[Former Member]

> ...enhanced by the customer on a as-needed basis, and changed the mechanics of S_PROGRAM check so that it is only checked when the user is working with the program directly, i.e. executing it from SE38 or SA38 or scheduling as a background job as opposed through a transaction.

Then you should read the last paragraph of [SAP Note 1012066|https://service.sap.com/sap/support/notes/1012066]

This will actually give you a control at the program name level from the workbench, but will not interfer with SA38, programaticly SUMBITed reports, scheduled background jobs, etc.

But that will not directly help this specific question as it is batch job administration related. The technical options within the ABAP system's authorization objects are well described in [SAP Note 101146|https://service.sap.com/sap/support/notes/101146] . You have to be very carefull of misleading Su53 results in this area.

Cheers,

Julius

[Private_Member_119218]

>

> > ...enhanced by the customer on a as-needed basis, and changed the mechanics of S_PROGRAM check so that it is only checked when the user is working with the program directly, i.e. executing it from SE38 or SA38 or scheduling as a background job as opposed through a transaction.
> Then you should read the last paragraph of [SAP Note 1012066|https://service.sap.com/sap/support/notes/1012066]
> 
> This will actually give you a control at the program name level from the workbench, but will not interfer with SA38, programaticly SUMBITed reports, scheduled background jobs, etc.

Interesting! This could be useful in the future.

Thank you, Julius!

[Former Member]

Thanks for the answers to date guys.

I can see the logic of applying authorisation groups to batch jobs, however i'm still concerned about the access business users would have to run a non-batch program via SM36, i think i'm right in assuming that any programs not assigned to an authorisation group will still be executable?