Job modification privilege

Hi,

Is it true that security is based on the last modified user of the folder/job? If user A has access to all jobs and user B has access to only job X, user B will not be able to edit job X once user A modifies and saves it, correct? If so, what is your recommendation to restore user B's access to job X?

Also, is there any plans to improve 24x7 scheduler's security features, like synching up with active directory? The scheduler program works great but if we can have better security, user adoption will be a lot easier. Thanks!

Yes, that statement is correct. You can think of the "last modified" as the job owner. There is currently no simple way to transfer job ownership other then make the user B an admin and let him/her update the job so that user B name can be saved in job properties.

There are no plans for direct Active Directory integration, but in the works is a replacement of scheduler based user security with system based. In fact, the 24x7 Multi-platform Edition supports this for quite a while. In other words in that version you don't need to define users and update their passwords within the scheduler. The scheduler relies on the operation system/network to authenticate users and therefore you only need to manage users in one place using your system's management tools.

Thanks for the quick reply.

Since we have the site license which also includes the multi-platform edition, I've installed it and scanned through the documentation. Unfortunately, the doc is not that detailed in the security portion. I do see the native security option, which I am presuming that the scheduler will only verify whether the user is authorized on the server by the user group in the windows system. That sounds like the users actually have to log on to the server the scheduler is installed on and modify the jobs there. However, it still doesn't explain how a situation like what I've described earlier can be avoided. In addition, we also lose the remote control functionality, correct?

Sorry, lots of questions but this is an import feature to auditors and management. Thanks!

Not exactly. Yes, it uses the operation system to authenticate users but it also uses operation system when running jobs as other users (which is by the way also the case for Windows Edition). These "run as user" jobs run in the context of the specified user account and so all the effective security settings associated with the specified account are used as currently defined in the active directory or local security policy.

As you correctly mentioned, the situation with the job ownership is still the same.

Regarding the remote control, yes the multi-platform version doesn't offer graphical desktop-based remote control, but it supports the web based console which is actually the right way to manage the scheduler and monitor jobs in multi-user environment. The Multi-platform version also supports command console-based interface (in recent builds) – which is a sort of remote control, but console based and which can be also used to run automated scripts. For example, we use jobs invoking the console to programmatically disable FTP-based file-watching jobs during nights and then re-enabled them on the following morning.

Let me rephrase this to make sure I understood correctly. Basically, the os authentication is for the purpose of logging in to the scheduler and accessing 'resources' (files/folders) on our network. If that's the case, then it's not exactly what we are looking for. What we are trying to do is control privileges to the 24x7 scheduler. For example, specific groups can only access/modify jobs under specific job folders or like the example I've given in my original post.

The existing security feature is not bad, except for the designation of job ownership by the last modified user. I am not sure if I've asked that specifically, but are there any plans to expand job database security feature? Thank you!

Now I see what you are after. Job folders and job access permission within the scheduler (as well as other inside the scheduler functions) are not tied to the OS user group permissions. I am not aware of any plans to change this behavior.