Configure policies

This section describes how to configure policies to define rights and settings that will be assigned to users and devices at sign-in. Review the Before you start section before configuring.

Actions menu

The Actions menu allows you to test access, clone the policy for use within this system, export the policy for use in another system (see import), or delete the policy.

Add/Edit policy

To add or edit a policy, click +Add on the Policies page and complete the following fields:

• Name. Enter a name for the policy.

• Notes. Optional. Enter any notes for the policy.

• Status. Select Enabled or Disabled.

• Tags. Click +Add to add tags to the policy.

• Assignment Criteria. Defines when the policy will be assigned. Select criteria to achieve least-privilege access rights. Refer to Using Policies for more details about how they are assigned.

  • Criteria Combining Mode. Each policy can include one or more criteria expressions. Criteria expressions have three different combining modes (without using scripts):

• <all criteria below must be true> - a logical AND of different criteria needs to equate to true

• <at least one of the criteria below must be true> - a logical OR of different criteria needs to equate to true

• <Criteria are met according to custom logic> - a simple Boolean expression comprising a number of different criteria needs to equate to true

NOTE

For more complex expressions it is recommended to use Custom Logic. Script mode is available for very advanced use cases which may break compatibility with the three list modes.

• Criteria. Select +Add and use the Type dropdown top select the criteria type. These claims-based expressions define which user/device a Policy will be assigned to. Use static claims that are unlikely to change during the day - such as directory group membership or email address. Multiple policies can be assigned so care needs to be taken when selecting access criteria to ensure you get the right outcome. If you have pre-defined criteria or user claim scripts, then these will become available via the assignment criteria list. The built-in script <Everyone> will assign the policy to all users.

For more information, see Configure Conditions.

Policy Type Fields

After configuring the initial policy fields, you will define additional settings specific to each type of policy. Select the type of policy you want to configure and complete their fields:

Access Policy

To create an Access Policy, enter values in the following fields:

• Entitlements.

  • Entitlements by Name. Select one or more pre-configured entitlements that will be included in this policy. Policies can comprise entitlements pointing to any number of different Sites.

  • Entitlements by Tag. By selecting one or more tags, all the related entitlements will be included in this policy. AppGate ZTNA will auto-associate all the entitlements to this policy that have the matching tag name (set when the entitlement was created). This is useful when you need to associate many entitlements to a policy. Entitlements can be defined by name and tag at the same time

• Site Settings.

  • Override Site. The system is designed to use the entitlements' Sites, but this can be overridden and have all entitlements deployed to a specified Site. When you configure an entitlement a Site must always be specified (tells AppGate ZTNA where to find this resource). Use should use 'Will not override...' (the default) unless you have a very specific use case which requires a specific override Site to be used.

  • Override with a specific Site. Select another Site to be used from the list.

  • Override using a claim. Select the claim to be used. The claim must return the UUID of the Site. You can get the UUID of the Site from the address bar of your browser - just edit the specific Site and the URL will look like this: https://my-controller:8443/ui/sites/edit/91894c92-3502-4ab4-870e-d573d0362f48. In this case the claim value should be 91894c92-3502-4ab4-870e-d573d0362f48

  • Override with the nearest Site. The Site with the nearest geolocation AND 'Use for nearest Site selection' enabled (both specified in Sites), will be used. The Controller will evaluate the users geolocation and these entitlements will be added to the token for the nearest Site. The same entitlements need to be available on all Sites enabled for nearest Site selection. Remember to enable this feature and to specify the geolocation of the Site in Sites > General. Detailed information about the use of override Site can be found in the Using policies section and there is an example in Sites and tunnels.

  • Use fallback Site. The fallback Site (if specified in Sites) will be used when this Site is unavailable.

Admin Policy

To create an Admin Policy, enter values in the following fields:

• Privileges. Allows admin and API access to the admin port (default 8443) on the Controllers (and LogServer).

  • Admin Roles. Select one or more pre-configured admin roles to provision privileges for administrators or for using the Controller REST API.

Device Policy

Refer to Using policies for more details about device and client controls, including guidance about how they will be assigned. There may be issues when multiple device policies are assigned which can contain conflicting requirements, such as two different proxy PAC files. To provide a simple deterministic outcome, when multiple conflicting controls are assigned; the Policy with its name nearest to the beginning of the alphabet will be used.

To create a Device Policy, enter values in the following fields:

• Device Configuration.

  • Apply Device Proxy. A proxy PAC file will be applied to the device by the client. The proxy rules applied by the PAC file should normally be for other traffic NOT configured to be handled by AppGate ZTNA entitlements. In this case the other traffic might be sent to some cloud based web proxying service. Proxy servers can also be located behind the AppGate ZTNA system and not in the cloud - in which case you must remember to add an entitlement for each of these servers. For more information on usage refer to Device and client controls.

    • URL. Enter the URL of the PAC file i.e. http://mycompany.com/proxy.pac.

    • Persistent Config. Enable to leave the PAC file in place even when the client quits. Never enable this if the proxy server is located behind the AppGate ZTNA system.

NOTE

This is only supported on Windows and macOS.

• Trusted Network Detection. Select Enable Auto-Suspend to suspend the operation of the client when the client is on a trusted network. The client stays running but all routes are removed. In addition to removing routes, any ringfence rules and PAC files that may be in place will also be removed.

  • DNS Suffix. Enter the DNS suffix. The system will check for domains based on the DNS suffix provided, such as uk.mycompany.com. It is checked against the domain defined by DHCP option 15, which normally specifies the domain name that client should use as suffix when resolving hostnames.

NOTE

This is not supported on iOS or Chrome OS.

• Tamper Proofing. Enabled by default. While the client is connected, Tamper proofing re-imposes AppGate ZTNA defined routes, ringfence rules and PAC files if they have been altered by others. Checks every 5 seconds and re-imposes the correct rules/routes if required. Be careful in the case where the user's local subnet matches a defined route. In this case the user will get repeatably disconnected and reconnected.

• Ringfence Rules by Name. Select one or more pre-configured ringfence rules to restrict access to or from the client device.

• Ringfence Rules by Tag. By selecting one or more tags, all related ringfence rules will be included in this policy.

Ringfencing is designed to mitigate the security risk of transmission of malware between user devices when they are sitting on a public network. Ringfence rules can block inbound and/or outbound local traffic except what is required to establish a tunnel to Gateways. Ringfence rules can be applied with entitlements so it is possible to increase local protection of connecting devices while still allowing more restricted access.

For example, to enable an advanced ringfence when users are out of the office, create two complementary policies, such as for a user group to access Skype:

For more information on rules, refer to the Ringfence Rules section.

NOTE

This is not supported on mobile devices.

• Client Configuration.

  • Client Features. Select User Controlled or Managed by Admin. Selecting Managed by admin allows you to hide client features in the client UI and then have their values pre-set by this policy. See the AppGate ZTNA client guide for more details. For more information on usage refer to Device and client controls.

  • Client Help Link. Select Custom to customize the client's help link instead of using the default https://support.appgate.com/support/appgate-ztna-user-guide.

  • Client Profile Settings. Selecting Managed by Admin allows you to specify client profiles and client profile groups to be imposed on the client for this Collective. The order of the profiles can be set, and is the order in which they will appear in the client. The new profile(s) are received when the entitlement token is renewed and applied at sign-out or the next time the client restarts. For more information on usage, refer to Client profiles.

DNS Policy

To create a DNS Policy, enter values in the following fields:

• DNS Settings. DNS servers and match domains set in the DNS policy are used by the client to add a DNS configuration to the local operating system. Unless you are using the client DNS auto-configuration option, you need to add an Entitlement so the user's application is able to access the DNS server(s) you have specified. Leave access control set to Always Allow Action(s).

  • DNS Entitlements by Name. Select one or more pre-configured entitlements that will be included in this policy.

  • DNS Entitlements by Tag. By selecting one or more tags, all the related entitlements will be included in this policy.

  • DNS Configurations. Add one or more DNS configurations for the client based on match domains. Systems other than desktops (Mobile devices, Portal, etc.) require the use of special syntax to operate correctly. For more information about how to use policy based DNS in the AppGate ZTNA system, refer to DNS and name resolution.

    • Match Domain. Enter one or more comma-separated domains. When a domain entered matches a host definition, the DNS server below will be used. When more than one domain is entered, this will create multiple DNS configurations with the same DNS properties.

    • DNS Server. Enter one or more DNS servers to be used by the client. Linux will try only the first DNS server configured.

    • Register the Client's addresses in DNS. The mapped tun IPs presented by the client will be registered with the DNS server for that Site. (Domain-connected Windows only).

  • DNS Requests. Select the checkbox to block local DNS requests.

NOTE

There may be issues when multiple DNS policies are assigned which refer to the same match domain. To provide a simple deterministic outcome, when multiple conflicting DNS policies are assigned; the policy with its name nearest to the beginning of the alphabet will be used.

• Site Settings

  • Override Site. The system is designed to use the entitlements' Sites, but this can be overridden and have all entitlements deployed to a specified Site. When you configure an entitlement a Site must always be specified (tells AppGate ZTNA where to find this resource). Use should use 'Will not override...' (the default) unless you have a very specific use case which requires a specific Override Site to be used.

    • Override with a specific Site. Select another Site to be used from the list.

    • Override using a claim. Select the claim to be used. The claim must return the UUID of the Site. You can get the UUID of the Site from the address bar of your browser - just edit the specific Site and the URL will look like this: https://my-controller:8443/ui/sites/edit/91894c92-3502-4ab4-870e-d573d0362f48. In this case the Claim value should be 91894c92-3502-4ab4-870e-d573d0362f48

    • Override with the nearest Site. The Site with the nearest geolocation AND 'Use for nearest Site selection' enabled (both specified in Sites), will be used. The Controller will evaluate the users geolocation and these entitlements will be added to the token for the nearest Site.

  The same entitlements need to be available on all Sites enabled for nearest Site selection. Remember to enable this feature and to specify the geolocation of the Site in Sites > General.

  Detailed information about the use of override Site can be found in the Using policies section and there is an example in Sites and tunnels.

  • Fallback Site. If Use fallback Site is selected, the fallback Site will be used when the Site is unavailable.

Stop Policy

To create a Stop Policy, enter values in the following fields:

• Profile Removal. This can be used when you want to stop access to the Collective either temporarily or permanently for (a group of) users. For more information on usage, refer to Using policies.

  • Profiles Handling. When enabled, all relevant profiles will be removed from the client stopping any future re-connection attempts.