Application Control powered by AppSense

Ivanti Application Control is the new name for AppSense Application Manager

Condition Management

In this section:

About Conditions

Conditions are used in Custom Rules to apply security controls based on a number of factors. You can set conditions based on the following:

You can also create custom scripted conditions using VBScript or JScript, to handle scenarios that are not supplied as standard from the Application Console.

The security controls set in the rule items such as Allowed Items and Privilege Management are applied when the criteria in the condition are true or false. You can also use regular expressions and ranges to create advanced conditions that apply to multiple matches.

In conditions that support regular expressions, you can use simple regular expressions, such as entering [abc] to match anything that includes any of the characters within the brackets. You can also use more complex queries, for example ^[a-f]+ matches any user name that begins with a letter from a to f.

When you create a custom rule with conditions, remember that Application Control applies a timeout of 10 seconds to evaluate all the conditions for a rule. If the conditions are not evaluated within 10 seconds, the custom rule is not applied. This is especially important when creating scripted conditions, because a script that takes longer than 10 seconds to complete causes the evaluation to time out.

To view the conditions for a Custom rule, select the node for an individual Custom rule in the navigation pane. The work area displays the security level for the rule, and beneath it, a list of the conditions for the rule and whether the rule is enabled.

At the top of the list is the Conditions drop-down menu, from which you create new conditions. Alongside the menu are the following options to manage the conditions:

  • Move Left
  • Move Right
  • Move Down
  • Move Up
  • Edit
  • Delete

Use the Move arrows to arrange the conditions in the list. You can move conditions up and down the list or indent them to the left or right to make them children or parents of other conditions. The position of a condition in the list hierarchy determines how it is applied. Conditions at the same level are evaluated simultaneously (an OR condition). A condition that is a child of another condition evaluates only once the parent condition has been successfully executed (an AND condition). In the following example, the user either must be an administrator OR must be a member of the Finance user group AND using a laptop before the custom rule items can apply:

For any condition that queries the Active Directory, the Application Control administrator must be a member of the target domain or have sufficient permissions to access and query the domain.

If conditions are part of a live configuration, they are included in the report when you create a full report using Configuration Profiler. The report lists the relevant condition beneath each individual custom rule, using the same condition text as in the custom rule work area:

Create a Condition

This section applies to creating Directory Membership, User, Computer and Session & Client conditions only, as the dialog boxes these conditions use follow the same format.

  1. Select the node for a Custom rule.
  2. In the work area for the rule, open the Conditions drop-down menu and select the condition you want to apply, for example Conditions > User > User Group.

    In the condition dialog, the condition tab specific to the condition type displays by default. This tab allows the parameters to be set using a common group of options and fields.

  3. Define the condition using the available fields and checkboxes.
  4. Select the General tab.
  5. Enter a description and any optional notes. The description is used as the display name for conditions. If this field is left blank the display name is automatically set from the configured condition.
  6. Click OK to save the condition.

The Application Control agent uses the condition to find a match with the same criteria for a logged on user. If a match is found, the rule and rule items attached to the condition are applied.

Active Directory Based Conditions for Devices in Child Domains

Active Directory (AD) based client conditions convert the NetBIOS name of the client, obtained from Windows Terminal Server (or Citrix equivalent), to a FQDN used to query AD. The FDQN cannot be resolved if the terminal server is in the parent domain and is trying to resolve the FQDN of a connecting device in a child domain. This impacts Device and Custom rules, with Active Directory based client conditions, that are applied to terminal servers and VDIs in a root domain.

The terminal server must be configured with the DNS suffix of all child domains. The search list must be configured on all terminal servers wanting to resolve names for connecting in child domains.

For example, for the parent domain.local, the child domains, childa.domain.local and childb.domain.local, must be configured on the terminal server in order for AD based conditions to evaluate correctly.

For information about configuring domain suffix search lists, see: https://support.microsoft.com/en-gb/kb/275553

Reusing Conditions

You can reuse conditions you have already created by copying and pasting them from one Custom Rule to another.

You can cut, copy, and paste whole conditions using the options in the Edit Ribbon.

Condition Variables

Each type of condition can be specified using variations of the following fields, drop-downs, and checkboxes:

  • Equal - A comparison is made against the contents of the Match field to target the users or computers that fulfill those criteria. Enter the criteria into the Match field or use the ellipsis (...) to search or select as required.
  • Not Equal - Targets all users or computers that do not fulfill the criteria in the Match field. Enter the criteria in the Match field or use the ellipsis to search or select as required.
  • Query - Targets all users or computers that match the criteria specified in the Query field. Using wildcards in the query allows a wide range of matches, for example:
    • *Windows - target users or computers ending in the text Windows.
    • Windows* - target users or computers starting with the text Windows.
    • *Windows* - target users or computers containing the text Windows.
  • Regular Expression - Use regular expressions to specify advanced queries for users or computers.
  • Between - Used for conditions where a range of values can be set. For example, a condition can be created to apply to a selected range of IP addresses.
  • Evaluate once per session - When selected, a condition is evaluated and the result is cached. If the condition is run again, the result is obtained from the cache rather than evaluating the condition again.

Field Validation

The table below lists the strings that are acceptable in the fields of the various conditions.

Condition Field Allowed String Example
User Group Match domain\group appsense/sales matches the group ’sales’ in the appsense domain.
LDAP CN=sales, matches the ’sales’ group in the appsense.com domain.
Query domain\gro* appsense\sal* matches group names starting with 'sal' in the appsense domain.
domain\*gro appsense\*les matches group names ending with 'les' in the appsense domain.
domain\*gro* appsense\*ale* matches group names containing 'ale' in the appsense domain.
User Name Match domain\user appsense\smithj matches the user name 'smith'j in the appsense domain.
Query domain\use* appsense\smit* matches group names starting with 'smit', in the appsense domain.
domain\*use appsense\*ith matches group names ending with 'ith', in the appsense domain.
domain\*use* appsense\*ith* matches group names containing 'ith', in the appsense domain.
Computer Group Match domain\group appsense/sales matches the group ’sales’ in the appsense domain.
LDAP CN=sales, matches the ’sales’ group in the appsense.com domain.
Query domain\gro* appsense\sal* matches group names starting with 'sal' in the appsense domain.
domain\*gro appsense\*les matches group names ending with 'les' in the appsense domain.
domain\*gro* appsense\*ale* matches group names containing 'ale' in the appsense domain.
Computer Name Match computer SalesDesk01 matches the computer name 'SalesDesk01'.
Query comp* SalesDesk* matches all computer names starting 'SalesDesk'.
*comp Desk01* matches all computer names ending with 'Desk01'.
*comp* Desk* matches all computer names containing 'Desk'.
Computer Domain Match domain appsense matches the domain name 'appsense'.
domain appsense.com matches the domain name 'appsense.com'.
Query dom* app* matches all computer domains starting ' app'.
*dom *sense matches all computer domains ending 'sense'.
*dom* *sen* matches the domains containing 'sen'.
Computer NETBIOS Match computer SalesDesk01 matches the computer NETBIIOS name 'SalesDesk01'.
Query comp* SalesDesk* matches all computer names starting 'SalesDesk'.
*comp Desk01* matches all computer names ending with 'Desk01'.
*comp* Desk* matches all computer names containing 'Desk'.
Computer IP Address Match xxxx.xxxx.xxxx.xxxx 192.168.0.1 matches the IP address 192.168.0.1.
Between xxxx.xxxx.xxxx.xxxx IP Address 1: 192.168.0.1, IP Address 2: 192.168.0.254 matches all IP addresses between "192.168.0.1" and "192.168.0.254".
User OU Membership Match LDAP CN=sales, matches the directory membership of user OU 'sales', in the appsense.com domain.
Query ou* sales* matches user OU names starting with 'sales'.
*ou *sales matches user OU names ending with 'sales'.
*ou* *sales* matches user OU names containing 'sales'.
Computer OU Membership Match LDAP CN=sales, matches the directory membership of computer OU 'sales' in the appsense.com domain.
Query ou* sales* matches computer OU names starting with 'sales'.
*ou *sales matches computer OU names ending with 'sales'.
*ou* *sales* matches computer OU names containing 'sales'.
Directory Site Match sitename testsite matches the site name 'testsite'.

Related Topics


Was this article useful?    

The topic was:

Inaccurate

Incomplete

Not what I expected

Other