Security is easier to manage when it is kept simple. The best way to do this is to work with groups (of jobs and other objects, and users) rather than individuals (individual users, jobs, etc.).
adTempus does not allow you to define groups of users, but it does recognize user groups defined in Windows. Whenever possible, grant permissions within adTempus to groups of Windows users, and then grant permissions to individual users indirectly, by assigning them to groups.
For example, you must specify which users have permission to connect to adTempus (using the Security Settings Page of the Server Options). Instead of adding individual users here, you should instead create an "adTempus Users" user group in Windows, and grant permission to that group. Then add the appropriate users to this group.
Within adTempus you may then need to further define which users have access to which jobs (and other objects). Again, use Windows user groups to simplify this. For example, at a basic level you may have one set of users who are allowed to view and monitor jobs but not to create or modify them, and a second set of users who are allowed to create and modify jobs. In Windows, create two more groups, such as "adTempus Read-Only Users" and "adTempus Update Users" and assign the appropriate people to the correct group. Make the two new groups members of the "adTempus Users" group you already created and now, through Windows security inheritance, the people you assign to "adTempus Read-Only users" also inherit the permission to connect to adTempus, without you needing to assign them that permission explicitly within adTempus.
Just as you should grant permissions to groups of users rather than individual users whenever possible, so you should also assign security access to groups of objects rather than individual objects. Practically speaking, you will most often be tailoring permissions to jobs, so following this principal you should try to set permissions based on Job Groups rather than the individual jobs. If a set of jobs have a related function (e.g., they are all related to one application on your server) it makes sense to put them in the same Job Group. By the same token, they probably have substantially the same security requirements as well. So rather than modifying the security settings for each one of these jobs, you should set the permissions for the Group that contains them instead. Then as new jobs are added to the group, they automatically inherit the permissions from the group. If a few jobs within the group have specialized security requirements, you can customize them either by modifying those jobs individually to override the inherited permissions, or by grouping them into a lower-level group and customizing the permissions for that group.