InTrust 11.4.2 - Deployment Guide

Implementing Role-Based Administration

To implement role-based InTrust administration, do the following:

1. Make an Active Directory security group for each new role.
2. Populate the group with accounts that must have the role.
3. Set permissions on InTrust objects for the group.

It is recommended that you create groups with descriptive names. For example, if you need to define an auditing administrator role, you should create a group called InTrust Auditing Admins or something similar, depending on the naming conventions in your environment.

InTrust Object Security

Objects can inherit security permissions from their parents or have them assigned directly. You can specify security settings to a number of InTrust configuration objects using InTrust Manager snap-in. Setting permissions on these objects affects the objects' availability in the InTrust Manager snap-in and the InTrust operations, if the respective jobs or tasks are running under an account other than the InTrust Server account. Permissions control whether specific people can access objects in the snap-in and whether an account under which a certain job is running can access objects used by this job.

The following figure illustrates the inheritance of security permissions of InTrust configuration objects available in the InTrust Manager snap-in. Containers are shown as folders. The lock icon means that you can edit security settings of the marked object using the Security tab in its properties dialog box.

Consider the following examples:

• If you select Deny for Read, Modify and Full Control on an object for a specific group, users in that group will not see that object in the snap-in.
• Changing InTrust-specific permissions on a database has no effect on real database permissions; similarly, role-based administration-specific repository permissions are not in any way associated with the NTFS permissions on actual repository files.

To set object security

1. In InTrust Manager, right-click an object and select Properties.
2. Go to the Security tab.
3. Click Add to specify the groups (or users if necessary) for which you want to define permissions.
4. Select the check boxes you need in the Permissions section.

For convenience, InTrust offers a simplified security model with only three options: Full Control, Modify, and Read. The state of each of these options can be either Allow or Deny.

Internally, however, security is more granular and resembles the NTFS model. For example, extended privileges over InTrust objects are given to users who create those objects. This is analogous to users retaining the Creator Owner permission on an NTFS file or folder that they create—object creators can change their own permissions.

Switching Role-Based Administration On and Off

To enable or disable the InTrust role-based administration feature, use the adccfgsec.exe utility from the Resource Kit (located in the <InTrust_installation_folder>\Server\ADC\SupportTools folder on the InTrust Server computer). You can run this command-line utility with the following parameters:

Examples: Who Can Do What

View Configuration Objects

If you need to enable a group of users to use several configuration objects in their InTrust workflow, consider the following:

• To specify an InTrust configuration object when configuring other InTrust objects, a user must have at least the Read permission on that object.
• The default permissions that an object inherits from its parent can enable an unintended user to use and modify the object.

Manage Configuration Objects

An administrator who creates an InTrust configuration object automatically gets the Full Control permission on that object. In addition, unrestricted access to the object is given to the accounts in the list of InTrust organization administrators. If you want another group of users to be able to manage an object, delete it, or associate it with other InTrust objects, you must grant them the desired permissions explicitly. Specifically, consider the following:

• To modify or delete an InTrust configuration object, a user must have the Modify or Full Control permission on the object.
• Account under which a certain job is running must have at least Read permission on objects used by this job.
• Every newly created configuration object inherits permissions from its parent node by default. These inherited permissions can enable an unintended user to use or modify the object.

View Alerts

To authorize a group of users to read alerts from a certain InTrust site and a certain rule group, keep in mind the following:

• You must have a real-time monitoring policy that uses the rules you need and the InTrust sites you want to monitor.
• To configure read access to alerts for users or groups, you need to give their accounts the Read right in the properties of the policy on the Alert Security tab.

Manage Alerts

You may want to enable a group of users to view and modify alert records generated by rules in a specific rule group in a specific InTrust site. Alert records are available to users only if their accounts have sufficient permissions. To do this, consider the following:

• You must have a real-time monitoring policy that uses the rules you need and that works on the InTrust sites you want to monitor.
• To configure access (read and modify) to alerts for users or groups, enable the Change Alert State right in the properties of the policy on the Alert Security tab.

Case Study: Regional Scenario

Suppose that Acme Corporation has its headquarters in London and branch offices in Mexico and Tokyo. The desired configuration is as follows:

• An administrator from the Tokyo office is authorized to manage a set of configuration objects created by an InTrust organization administrator. These objects might include sites, servers, tasks, databases, repositories, and notification groups.
• An administrator from Mexico office is authorized to manage a different set of configuration objects created by InTrust organization administrator.
• Import and gathering policies are unified. InTrust administrators from regional agencies can view these objects but cannot delete or modify them.

To implement this scenario, consider the following:

• The organization administrator must create the InTrust configuration objects that will be used by regional InTrust administrators in the Tokyo and Mexico offices.
• Object permissions inherited from parent objects must not break the desired security policy.
• The regional InTrust administrators must have at least the Modify permission on configuration objects that are used in the InTrust workflow in their offices.
• If a regional administrator has the Full Control permission on an object he or she can assign permissions to other users.
• The Read permission on the Gathering node is sufficient for both regional administrators.