Permission Management Guidelines

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.).

User Groups

Security Groups allow you to group users (Security Logins) together based on the permissions they need (and/or the roles they perform). Whenever possible, grant permissions within adTempus to Groups, and then grant permissions to individual users indirectly, by assigning them to groups.

For example, 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. To managed this need, you would create two Security Groups (using the Server Security Settings editor):

• The "Job Monitors" group
• The "Job Editors" group

To assign permissions to these groups, right-click the Jobs node in the Console tree and choose Edit to open its properties.

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.

Object Groups

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.

See the Security Inheritance topic for information about the levels at which security can be configured.

Object Creator

When you are assigning permissions to a security container (e.g., permissions that apply to all Jobs or to all Notification Recipients) you can specify permissions for a special login placeholder named "<Object Creator>". Permissions that you assign to this placeholder are given to the user who creates an object.

For example, in a typical scenario you might want users to be able to view all Notification Recipients, to create new Notification Recipients, and to modify the Notification Recipients that they have created (but not recipients that others have created).

To accomplish this you would use the following combination of permissions in the Notification Recipient Security window:

• Grant View and Create permission to "adTempus Users"
• Grant Update and Delete permissions to "<Object Creator>"

When a user creates a new Notification Recipient, adTempus will create explicit Update and Delete permissions on the recipient for that user. The user will inherit the View permission configured for the security container.

In a new adTempus installation, a default set of "<Object Creator>" permissions are added to the Server Security Settings, so that they apply to all objects in adTempus.