Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Restriction of back ground from end user

Former Member
0 Kudos

Hi all, i am ABAPer, but i need to work on authorization issue,

I have to restrict our FI End users (8 users) from the back ground job,

At present scenario is they can run others job also in SM35 including thier job, recently our company aduit found this given the below solution

Excessive batch job authorisation was given to end users (End users should be restricted from the object S_BTCH_ADM and S_BTCH_NAM which allows them to release and schedule jobs using other usersu2019 ID)

when i go thorugh i chenged the value S_BCTH_ADM as N and S_BCTH_NAM as *

and S_BTCH_JOB as LIST,RELE,PROT.

Kindly give me the solution <removed_by_moderator>

Regards

Chandra

Edited by: Julius Bussche on Jun 16, 2008 6:02 AM

8 REPLIES 8

Former Member
0 Kudos

If they only need to manage their own jobs, remove SM35 and gove them SMX

0 Kudos

Hi alex,

Thanks for your reply, if remove SM35, are they able to schedule their own session ? what is gov SMxx, pls let me know.

0 Kudos

Hi Chandra, I have just re-read your post and there are 2 things here.

SM36 - background processing. You can give users tx SMX and they can manage only their own background jobs with this. That would mean you don't need S_BTCH_ADM = Y or S_BTCH_NAM

If they need to view/process other jobs then you can use S_BTCH_JOB with the job names defined in that auth object

SM35 - batch input, you restrict with S_BDC_MONI and restrict it by the session name. You cannot restrict users to their own jobs unless you create a role for each user and have a strict naming convention. What often is used is that users will have access in S_BDC_MONI for jobs named FI* and they can perform activities on all FI* sessions. You could restrict it further by putting in the exact names of the sessions they can run, delete etc. The object documentation gives you more info on this.

0 Kudos

I believe S_BTCH_JOB will only allow view of other ids jobs and DELETE, but the other functions like COPY and CHANGE will not be available.

0 Kudos

I'm pretty sure you can use it to copy jobs too & control access to the spool docs (not that it should be too difficult to get the info another way).

On reflection I think you are right about the change

0 Kudos

Hi,

Thank you very much by your post i solved my problem.

and Is there any possiblity to restrict the naming convention of background job ie in the sm36 screen Jobname coloumn if i want to restrect with a particular naming convention is int possible example Z:XYZ is the first part of the job name.

Thanks & Regards,

Ganesh

0 Kudos

> Is there any possiblity to restrict the naming convention of background job ie in the sm36 screen Jobname coloumn if i want to restrect with a particular naming convention is int possible example Z:XYZ is the first part of the job name.

AFAIK you can only restrict this for JOBACTION 'SHOW' and this would only work if your JOBGROUP field was already populated with a value.

The name of the job would not work. So I would say that you need to arrange that organizationally.

I think way back a few years ago there was a thread here about this and the possibility of using the user's ID as the JOBGROUP value - but if I remember correctly it was disbanded as being impractical.

So the answer is most likely: No.

Cheers,

Julius

0 Kudos

>

> SM35 - batch input, you restrict with S_BDC_MONI and restrict it by the session name.

Agree! I'm also allowing SM35 and SMX and restricting them by Session Name.