User policies overview

User policies are Xprotect policies that provide user identity-based access to the applications and files on Xprotect-managed hosts. The identities here refer to the identities of the users fetched from the Active Directory (AD) that is integrated with the Xprotect instance. To use User policies on a host, the Xprotect Host group of the host must be associated with the AD groups or departments of the users who will access the host; this is done through Xprotect User groups. 

Host policies and User policies

The workflow, policy-building experience, syntax, scopes, and the behavior of the rules for User policies are the same as that for Host policies. The Two exceptions with User policies are:

  • User policy is not pushed to the hosts from the Xprotect UI until a relevant AD user logs into the host. The User policy is retained on the host only as long as the relevant user is logged in. This also means that for User policies to work, the hosts must be connected to the instance at all times.

  • User policies do not have settings of their own; they inherit the Policy settings and the AutoTrust settings of the Host policy on a host.

Host policies are needed

A User policy is an additional layer of security for hosts that are already protected with an Xprotect Host policy. Also, User policy is optional; hosts (at the level of their Host group) can be allowed or blocked for User policies. On a host with a Host policy and a User policy, the rules in both the policies work mutually. In case of contradicting rules, the most restrictive rule is processed. This is the default rule-processing behavior on Xprotect.

Hosts can be tuned for User policies in One of the following Two ways - Non-overlapping policies and Overlapping policies.

Non-overlapping policies

Here, rules are added to the Host policy and User policies by the applications (without contradicting rules) used on a host. Different users logging into the host access a non-overlapping set of applications. This type of access suits non-administrative and shared access to applications on the host.

In the following illustration, with only the Host policy, all users can access all applications (Guest, Sales, and Support) on the host. To enable identity-based applications to access on the host:

  1. Tune the Host policy rules to Guest apps only (Web browser, Text and image utilities, and Candidate assessment). 

  2. Create Sales app-centric and Support app-centric User policies and push them to the host.

Overlapping policies

Here, rules are added to the Host policy and User policies by the applications and the applications' processes and services (contradicting rules). Different users logging into the host access an overlapping set of applications. The rules in the policies define the type and degree of overlap and contradiction. This type of access suits shared access to applications for administrators and AD group users.

In the following illustration, with only the Host policy, the Admin users, Sales users, and Support users can use the Remote Desktop (RDP) feature on the host. To enable identity-based access to RDP:

  1. Tune the Host policy rules to allow administrative access to the applications on the host (including full access to use RDP). 

  2. Create a Sales app-centric app User policy with a Block rule for RDP.

  3. Create a Support app-centric app without a rule for RDP.

Enable User policies

This section assumes that Host policies are already created and pushed to the hosts. On a new instance, you must first create Host groups and set up Host policies. 

Do the following to enable User policies on the hosts.

1. Enable User policies for the instance

Enable User policies for the instance. the Allow User Based Polices option for Host groups that contain the hosts you are setting up for identify-based access. Otherwise, the Host group is not available for selection when you create a User group. 

2. Allow User policies on relevant hosts

Enable the Allow User Based Polices option for Host groups that contain the hosts you are setting up for identify-based access. Otherwise, the Host group is not available for selection when you create a User group. 

3. Import user details from an AD

Import user details from an AD - Integrate an AD with the instance. You must make the necessary arrangements in the AD to import selected users to the instance. Use the Base DN and an additional User filter to select the users for User policies. After successful integration, the selected users and their AD group, and the AD department are seen on Xprotect.

4. Create User policies for User groups

User policies are associated with User groups when you create User groups. User policies are similar to Host policies, except that they are only applicable when the users from the integrated AD log into the host. Create User policies and add the necessary Whitelist rules, Blacklist rules, Rule Rings rules, and File Protect rules.

5. Create groups of users (User groups) and associate User policies

Create User groups of users by their AD groups or their AD departments. User groups are created from Host groups; this means you specify which Host groups allow for User policies. Also, you must associate the User policies you created in step 3.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.