Need Clarification on Production Roles

[Former Member]

Hi,

Please clarifiy some things for me for production:

1. Role to run background jobs for batch IDs- What tcodes are necessary to build this role? Will SM35, SM36, SM37 suffice?

2. "" or full authorization on authorization objects - When is this allowed? Is it ok to give them "" on plants, planning plants, cost centers if the users say that they will need access to all plants and cost centers?

3. Should Basis have access to any of the Security tcodes (SU01, SU10, etc)?

4. As Security, should we have access to change roles in production or just display access?

Thanks for all your help.

Edited by: Bliss IM on May 13, 2008 4:27 PM

Edited by: Bliss IM on May 13, 2008 4:27 PM

[Former Member]

>

> 1. Role to run background jobs for batch IDs- What tcodes are necessary to build this role? Will SM35, SM36, SM37 suffice?
>

From a basis-point of view: do you WANT all your users to schedule jobs ... 'my' users only have SMX for their OWN jobs, not to access all the others (who wants the average non-FI user to check on the latest run of RFBIBL00?) ... SM35 should be replaced by scheduling RSBDCSUB (BI-sessions tend to be big ...).

>

> 2. "" or full authorization on authorization objects - When is this allowed? Is it ok to give them "" on plants, planning plants, cost centers if the users say that they will need access to all plants and cost centers?
>

i would say 'no' 'never-ever' but this does depend on several things: how many such structures do you have? how many users do you have? what do your funkies say about how the processes are set up?

>

> 3. Should Basis have access to any of the Security tcodes (SU01, SU10, etc)?
>

again, this depends on your structure - if you have a global setup and only the basis-guys are working in a 3-shift-mode it might come in handy if they can set the one or other odd password ...

>

> 4. As Security, should we have access to change roles in production or just display access?
>

again - i would say never ever change roles in a production system, always do it in DEV and transport it around all the attached systems thus having the same version everywhere. nothing to do with security-guy or basis-guy in this case, just as a general rule.

Edited by: Mylene Euridice Dorias on May 13, 2008 4:58 PM

[Former Member]

Hi,

Broadly similar views to Mylene in a few of the areas

1. Can you explain more what the role intends on doing

2. It depends on a few things, how important that data is, whether it is configured etc. Generally I would say no * for end users for those org levels. Obviously there are exceptions to all rules but there isn't enough to go on. Often org levels can exist which haven't been configured or cleaned up (i.e. standard SAP ones). You wouldn't want anyone to have the ability to post to or use one of them.

3. It depends what your Basis team do & what your setup is. If you are the only security admin then it can be useful for them to have the access. Don't forget that BASIS can sometimes need to unlock batch users etc.

4. No real need to have the access to change roles in prod. In the case of an emergency make sure you can assign yourself a role which would let you do this if it is the best solution.

Edited by: Alex Ayers on May 13, 2008 6:22 PM

[Former Member]

Hi Alex,

For item #1, I need to create a role for Batch IDs to be able to run batch jobs. For example, batch id FIBATCH should be able to run all FI background jobs. HRBATCH, should only be able to run all scheduled/background jobs for HR.

Will tcodes SM35, SM36, and SM37 suffice to get the job done?

Thanks to all that has resplied.

[Former Member]

That's not going to work then since this role would need to do FI postings and you would not have any FI authorizations in this role. Actually, there are 2 aspects:

1. Access to just submit the job - ie. SM36 / SM37.

2. Access to post the job - ie. if job is for FI document post, then you will need for example tcode FB01 and authorizations associated with it.

If you want to just do one role / id, then both 1 and 2 need to be in the role / id.

[Former Member]

Hi Bliss,

JC's post is spot on with what you are asking for