SCHEDULER users and roles required

[jimmymac]

We are on E1 9.0, tools 9.1.4.7,

We have 100+ scheduled jobs set up using the JDE Scheduler. They are all submitted under a 'Scheduler' user id, such as SCHEDULE, SCHEDULE2, SCHEDULE3, etc.

These user ids are set up in our system with only the role SYSADMIN. We are now going through an audit and this is being questioned. As the lead developer, I have a role called SYSADMIN which allows me to set up users and handle other security type activities. but this role SYSADMIN is also assigned to these 'Scheduler' type users.

My basic question would be to anyone with an opinion. If we have a user id such as SCHEDULE, do they actually need roles assigned to them. We never actually sign on to a JDE fat client or web client with these id's, they are only used to submit scheduled jobs under. Or if roles are required, why would someone have assigned a role such as SYSADMIN to these id's. This was done many years prior to my arrival. Wish I could ask why these were set up this way but they are long gone.

Any input would be appreciated.

 

[DSauve]

My guess is because your SYSADMIN role likely has access to run most (if not all) UBE's, thereby removing the need to explicitly grant run access to UBE's that are scheduled to run under this user ID.
You could just as well set up a role (or roles) for your user ID's and then just grant them run access to the UBE's that need to run in batch. This would likely stand up to an audit and would be more secure in the long run.

 

[ice_cube210]

Every user ID has to have at least one role assigned to them , and that role must have access to the environment where the user wishes to log in. This applies to IDs that will be used on the scheduler to run batch jobs also. When ever a batch job is run , it must first authenticate the user that is running the job and then depending on your security setup , it will check if the user has access to run the job and then it will run the job.

So in short yes your scheduler User IDs also need at least one role assigned , but it does not have to be SYSADMIN. It can be a new role called SCHEDADMIN for example. Now what security you need to assign to this role depends on the security model you have -open door vs closed door.