Restrict periodic scheduling in SM37

[Former Member]

We have a requirement to restrict the ability for users to schedule periodic background jobs, but allow them to retain the ability to execute/release their own jobs. However, standard SAP authorizations do not allow us to do this (they either get access for both, or neither). There doesn't appear to be a user exit that could be used. Anyone know if you can restrict user ability in SM37?

[Former Member]

I cannot remember having seen such a thing, but that does not mean it is not possible.

Take a look at the documentation of auth object S_BTCH_JOB in tcode SU21 to see whether there is a documented option for it?

If that fails, try checking the domain of the JOBACTION field of the object to see whether there is a value in the value range which suggests that this can be done (check the coding as well, as the value range might be incomplete for such requirements).

If that fails, there is a customizing table which SM37 uses to introduce "features" which should not be disruptive to support pack upgrades, but only introduced at release upgrades, and also some specific customer requests which others who don't need it should be protected from. The name of the table is BTCOPTIONS. Last time I checked, I think an F4 help wasn't available for it (sort of makes sense...), but if you search SAP notes then you might find it there.

If that fails, contact SAP. I for one would support such a feature (action value). Checking jobs when "retiring" users can provide for some surprises when the scheduled jobs are not checked or in extreme cases even visible for the admin who is "retiring" the user account.

Nice question! I will look into it a bit as well now

Cheers,

Julius

[Former Member]

Thanks. I have looked at all that and found nothing. I did a search for notes as well but saw nothing that addressed this particular request. We were trying to avoid a customization from SAP. I would be interested to know if you find anything

[Former Member]

Hi there,

If I do, then I will share it here.

Cheers,

Julius

PS: Unfortunately I killed my lab system earlier (one of those: "What happens if I click here when logged on with SAP_ALL?" things, which could happen to anybody who clicks around too much with too much access) and in our other systems I cannot debug the screen to look for options - so it will not be before Friday by the looks of it.

[Former Member]

Okay, I found something which might be a starting point, but from what I can tell it does more than what you want to the start condition screen and will prevent the release of the job as well. I can however not test it.

Check SAP note 568963.

Idea: Perhaps if you activated the wizard and then only modified the wizard check result after it has changed the screen, then this would be less intrusive on the system, if you are considering a modification anyway.

If you anyway don't let users release their own jobs (S_BTCH_JOB) unless they are the dedicated batch admins (S_BTCH_ADM) then it might work "as is". But that is a tough one and very unlikely if you have many users or a BW.

Cheers,

Julius

[Former Member]

> Check SAP note 568963.

>

> Idea: Perhaps if you activated the wizard and then only modified the wizard check result after it has changed the screen, then this would be less intrusive on the system, if you are considering a modification anyway.

I tried this out in combinations with various authorities for S_BTCH_JOB, but could not get it to work

I would recommend opening a customer message via service.sap.com (perhaps we are just not aware of the solution?), failing which consider a development suggestion. I might be able to help you there.

Cheers,

Julius

[Former Member]

Any more updates on restriction to SM37? I'm very interested on the solution. Just giving it a bump and hopefully somebody had done a successful restriction of SM37 for job names or background user names.

[Former Member]

The user name you can control via S_BTCH_NAM if they have the correct access, but I have not heard anything further about S_BTCH_JOB.

There are a number of threads revolving around this and related topics already (though some are misunderstandings IMHO) so perhaps we should suggest it SAP.

Formally, the route is SAP Note # 11 but I have mixed experiences with that, particularly when it gets a bit technical. But a change such as this might be intrusive on some other customers... so we should have our reasons and support for it backed up.

In the meantime, a check on scheduled (periodic) jobs before retiring user ID's is recommendable... as well as using tcode SMX instead of SM37 to observe their jobs.

@ others: Any more support for this? (please read it carefully!)

Cheers,

Julius

[l_borsboom]

Is there any news yet on this issue?

I have seen audits that consider the ability to schedule background jobs critical only based on the lacking possibility to distinguish between 'scheduling once' and 'scheduling every minute' . The latter posibility could be compared with D.O.S attack

This is a pitty, because scheduling background jobs (once) is beneficial for system performance.

So I think indeed the community here should consider to initiate a development request to SAP.

Or has this been initiated already?

Kind regards!

Lodewijk

[Former Member]

Other than the wizard for SM36 (which I could not get to work) I am not aware of a development.

I have added it to the [Security Wishlist Wiki|https://www.sdn.sap.com/irj/scn/wiki?path=/display/security/securityFunctionalityWishlist-Topics] which we created to track usefull ideas which come from discussions in the forum.

Cheers,

Julius

[l_borsboom]

I have added it to the Security Wishlist Wiki which we created to track usefull ideas which come from discussions in the forum.

Thanks Julius! I took the liberty to add an additional Wish to this list.

Do you have any information if this list is actually read an acted upon by SAP Developers?

Kind regards,

Lodewijk

[Former Member]

Hello,

try t-code smxx

[Former Member]

> maheshwer wrote:

> Hello,

>

> try t-code smxx

Won't work. The start conditions can be selected already at the "execute in background" stage. That is all over the place.

SMX (and SMXX) are very usefull for restricting users to displaying their own jobs though.

Cheers,

Julius

[Former Member]

We are tackling this same issue. I opened a message with SAP and have been told that this is not possible. There are two methods for a user to submit repeating Batch processing. The first method is through SM37 (any access will allow) or by having S_PROGRAM with btchsubmit authorization. Many tcodes have an option to run in background. When executed the user is given the ability to schedule periodic runs. This authorization will allow the user to run daily, weekly and so forth. The only way to control would be to remove release authorization from object S_BTCH_JOB but a user would be responsible for releasing Batch jobs for users.

[Former Member]

Dear Bobbi,

Please check the object S_BTCH_NAM. A user can always schedule his own jobs. But if he wants other users to maintain his own jobs, the user IDs needs to be maintained in this object.

I hope if this object is deactivated in all the roles, each user can maintain his own jobs and will not have any authorizations for others' jobs.

Regards,

[Former Member]

Please read the question and subsequent discussion again carefully...

[Former Member]

Dear Julius,

Somehow I have missed the entire discussion that has happened and thought that i am the person to open the discussion. Later, after posting I have noticed it.

Anyways sorry for the confusion.

Regards,

[Former Member]

No problem. I just wanted to point out the importance of reading the question carefully.

@ Lodewijk:

> Do you have any information if this list is actually read an acted upon by SAP Developers?

I know that SDN discussions have resulted in corrections and new features in the past. One is being processed at the moment as well, see

I dont think there is an obligation to act as these are not bug reports... but Kristian Lehment (from SAP Security Product Management) liked the wiki idea and commented that we should add more information so that developers can respond via the wiki with suggested solutions or ask for more insights. So it will take some time.

Generally with these functionality wishes, one needs to be patient. The main reasons are that they will typically be developed for new releases (some might even require a major release change to be implemented without disturbing backward compatibility with existing functionality which is also in the new release). To "backport" them to existing releases is also a tricky topic as the existing functionality is already being used "in the wild" and might also be included in existing BTC programs of customers.

I have watches set on the wikis, so will update the appropriate threads when SAP comments on them. My understanding is that SAP is thankfull to be able to tap into the "idea pool" of the SDN discussions so I think they will.

Also see SAP note # 11 - although I personally have not had much success via that route.

Cheers,

Julius

Edited by: Julius Bussche on May 1, 2009 10:05 PM

[Former Member]

Hi,

Please try using transaction SMX, it may solve your issue partially.

Regards,

Gowrinadh

[Former Member]

Hi,

You can restrict the user by the giving the value for object S_BTCH_ADM to N. If you do so user can execute his own jobs only.

and if you give object value for S_BTCH_ADM to Y... user can execute all jobs.

Please let me know if you need any further information.

Regards,

Phani.

[Former Member]

Please read the question again, more carefully and including the subsequent discusssion...

Cheers,

Julius

[Former Member]

Hello,

we've got the same problem - we want to restrict users to execute only immediate jobs. Execution of periodic jobs or jobs in future. I described a few seconds ago in

Are there any news on this problem?

Regards,

Julia

[Former Member]

None which I am aware of. Others are progressing (also in development stages) but this one has not attracted any comments yet. Feel free to add a comment to the wiki...

Anyway, most companies solve this using a procedure to check jobs before they retire a user ID, if that is the risk you are refering to.

Via transaction SMX (functionally it is display only) you can also prevent the user from making a change to the job..... if that is the risk you are refering to.

Have you tried the solution which I mentioned in the OSS note above?

Cheers,

Julius

[Former Member]

Hello,

I did following example in SAP:

I created a role with just one authorization objekt: S_TCODE TCD=RSPFPAR.

With my testuser I executed this transaction. In field profile parameter I inserted auth/* and sent the transaction via program - Execution in background as a job in the background.

First the role needs authorization for S_SPO_DEV too - that's ok.

Then I checked: the job is in status "planned" in SM37.

Ok, User needs authorization object S_BTCH_JOB JOBGROUP=*;JOBACTION=RELE; too, so the job is released immediately. No other authorization objects are needed to execute a transaction in background.

Unfortunately the user can - while sending transaction into background - choose between options "immediate", "Date/Time", "After job", "After event", "at operation mode".

The note 568963, which is mentioned in this thread, concerns another problem: users without administration rights for background processing cannot specify a start condition. My testuser hasn't got administration rights and he can specify a start condition, when sending a process in the background with the described way.

So the problem is not the SM36, but the function that a lot of transaction bring with themselves.

Apart from that: I gave my testuser the transaction SM36 too without additional authorization objects and he can choose different start conditions too - without this btcoptions option. The users don't use the wizard.

Our problem is not, that there are aborted jobs, if an user leaves company. The problem isn't that users change jobs.

The problem is, that users can create jobs with start option in future or periodically. For jobmanagement there is a central job scheduling management system, which controls jobs. Of course a user should be able to send a transaction in background, which needs a lot of performance in dialog process. But he should only have option to release this job immediate.

Regards,

Julia

Edited by: Julia Bayrhammer on Dec 10, 2009 2:31 PM

[Former Member]

To my knowledge no. But what is the risk if not immortalizing themselves in future jobs (you can check that as already described...) or intercepting the job to change it (use SMX)?

I can understand that your central batch admin team don't want to have to Release all enduser's jobs all the time. As a workaround you could schedule a periodic job for type C jobs to do it for them? Just a thought.

Cheers,

Julius

[Former Member]

Julia

Have you found any solutions yet? We are in the same situation that you are in. We have a cental scheduling tool. We would like all periodic requests to run thru this tool. Yet we have users that will schedule an event to run hourly, daily etc. Even when we go delete the scheduled / released event in SM37- the user just creates it again. The only thing I can think of at this point is to develop custom code to go a delete items that are scheduled in the table TBTCS with one of the periodic fields containing an 'X'. We would have to run this program maybe every 15 mins or so to delete any new things that came into the schedule. Your input would be appreicated

Randee

[Former Member]

Hello Randee,

we don't have a solution yet. I'm in contact with SAP. Perhaps there will be a possibility to integrate this job monitoring with the central job monitoring software. This could be a solution for especially this combination, but I'm still looking forward to a possiblity to solve this with authorization objects.

I will update and give feedback if we implemented a solution.

Regards,

Julia

[dsanpor]

This message was moderated.

[Former Member]

Do we have an answer for this yet? We are actually interested in doing the reverse: only allowing users to run the background job at a certain time (eg out of business hours). So this form of restriction is close to what we want.

Any updates please?

[Former Member]

Hello

The following OSS note address that issue.

1716340 - A user should not generate periodic jobs

Regards

Yves