Specifying General Host Checker Options

You can specify global options for Host Checker that apply to any user for whom Host Checker is required in an authentication policy, a role mapping rule, or a resource policy.

To specify general Host Checker options:

1.In the admin console, choose Authentication > Endpoint Security > Host Checker.

2.Under Options:

•In the Perform check every X minutes field, specify the interval at which you want Host Checker to perform policy evaluation on a client machine. If the client machine fails to meet the requirements of the Host Checker policies required by a role or resource policy, then the system denies the associated user requests.

For example, you may require that a user runs a specific third-party antivirus application in order to map to Role A, which enables network connections from an external location. If the user's client machine is running the required antivirus application when the user signs in, then the user maps to Role A and is granted all access features enabled for Role A. If the antivirus application stops running during the user session, however, the next time Host Checker runs, the user fails to meet the security requirements for Role A and therefore loses all access privileges for Role A.

When an end-user logs into a Realm, Host Checker performs an initial policy check, regardless of whether or not the policy is enforced at the Realm, Role, and/or Resource level. The initial policy check establishes a start time. Host Checker evaluates policies at the frequency set by the Perform check every X minutes option starting the clock at the initial policy check. Although the frequency setting is set globally for all Host Checker policy checking, it is not synchronized for all end-user clients connected to the system. Each client performs its own initial policy check and starts its own X minute countdown. If you configure the authentication policy within a realm where Host Checker enforces policies (versus installing), the enforcement occurs only during the pre-authentication phase. After an end-user signs in and for the duration of the user's session, any subsequent Host Checker policy checks have no impact on realm access, meaning that there is no concept of removing an end-user session from a realm once an end-user successfully authenticates into that realm.

If you configure a role restriction where Host Checker enforces policies, the enforcement occurs just after authentication during role mapping. Role restrictions are enforced periodically during the end-user session at an interval specified using the Host Checker frequency setting. If the end-user successfully passes the Host Checker evaluation during role mapping but later fails X minutes after login, that specific user loses rights to that role. If the end-user loses rights to all available roles due to Host Checker policy evaluation, the end-user session is disconnected.

If you configure a resource-based policy rule where Host Checker enforces policies, the enforcement occurs when the end-user attempts to access the resource/backend server. For web resources, the Host Checker evaluation occurs at each request. For SAM and STA resources, the Host Checker evaluation occurs when the system activates the connection to the backend application/server. For VPN Tunneling access, the Host Checker evaluation occurs when the system initiates VPN Tunneling. Existing connections of applications running by way of SAM, Telnet/SSH connection, and VPN Tunneling connections are not affected by further Host Checker evaluations. Only new Web requests, new applications across SAM, new instances of STA, and launching VPN Tunneling are affected. The Host Checker evaluation is based on the most recent policy check that occurred X minutes ago. Example, if you configure the frequency setting to Perform check every five minutes and the end-user attempts to access a protected resource or attempts to launch VPN Tunneling four minutes after the last check, then the policy evaluation is based on the state of the client machine four minutes ago, not at the moment the end-user attempted to access the resource.

If you enter a value of zero, Host Checker only runs on the client machine when the user first signs in.

•For the Client-side process, login inactivity timeout option, specify an interval to control timing out in the following situations:

•If the user navigates away from the sign-in page after Host Checker starts running but before signing in to the device, Host Checker continues to run on the user's machine for the interval you specify.

•If the user is downloading Host Checker over a slow connection, increase the interval to allow enough time for the download to complete.

•This option is available from 22.5R1 onwards. Select Host Checker Timeout to configure the timeout value to accommodate the network responsiveness under various conditions. This option allows host checker to collect client information and send information back to server. By default, the timeout value is 3 minutes and can be increased to10 minutes.

•This option is available from 22.5R1 onwards. In the Admin Console > Endpoint Security > Host Checker, select Require enhanced protection for host checker messages received from client to notify the end user when host checker validation fails.

•Select Perform dynamic policy reevaluation to automatically refresh the roles of individual users by enabling dynamic policy evaluation for Host Checker. Host Checker can trigger the system to evaluate resource policies whenever a user's Host Checker status changes. (If you do not select this option, the system does not evaluate resource policies but it does evaluate the authentication policy, role mapping rules, and role restrictions whenever a user's Host Checker status changes.)

3.Click Save Changes.

Specifying Host Checker Installation Options

If you implement any policy at the realm, role, or resource policy level that requires Host Checker, you must provide a mechanism by which the system or the user can install Host Checker on the client machine. Otherwise, when the system evaluates the Host Checker policy, the user's machine fails because the Host Checker client is not available to return a success status.

You can use three methods to install Host Checker on a user's system:

•Ivanti Connect Secure automatically installs Host Checker-Enable automatic installation through the Users/Administrators > User Realms/Administrator Realms > [Realm] > Authentication Policy > Host Checker page of the admin console. When you do, the system evaluates the realm-level option when the user accesses the sign-in page and then determines if the current version of Host Checker is installed on the user's machine. If Host Checker is not installed, the system attempts to install it using either an ActiveX or a Java delivery method or Pulse Secure Application Launcher (PSAL). When a Windows user signs in to a device, the system attempts to install an ActiveX control on the user's system. If the system successfully installs the ActiveX control, the control manages the installation of the Host Checker program.

If the system cannot install the ActiveX control because ActiveX is turned off on the user's system, it attempts to install Host Checker using Java. For Linux hosts, the system always uses the Java delivery method. The Java delivery method requires only user privileges, but Java must be enabled on the user's system. For the Firefox browser on Linux, the Java runtime and plug-in must be installed.

Due to the end of ActiveX and Java support on many browsers, an alternate solution is provided for launching of client applications such as Host Checker or Ivanti Secure Access Client. For Google Chrome and Edge Browsers on Windows and for Safari and Chrome browsers on MAC, we use PSAL for installing Host checker.

Due to some anomalies with Microsoft JVM, Host Checker may not install, and an error box appears. If this occurs, click Try Again. The subsequent installation should succeed.

If the system cannot use the Java delivery method because Java is disabled on the user's system, it displays a no-access error message.

On Microsoft operating systems, the setup client and Host Checker install automatically.

•The user or administrator manually installs Host Checker (Windows only)-Download the Host Checker installer from the Maintenance > System > Installers page of the admin console and use it to manually install Host Checker on the user's system.

To install Host Checker, users must have appropriate privileges, as described in the Client-side Changes Guide. If the user does not have these privileges, use the Pulse Secure Installer Service available from the Maintenance > System > Installers page of the admin console to bypass this requirement.

Host Checker is supported for agent and agentless clients. The installation options are listed below:

•Browser-based Host Checking (Agentless) - This is used for browser-based logins and requires PSAL to be present on the endpoint. If PSAL is not available on the endpoint, it gets installed as part of the connection.
It is recommended not to keep a very low value for login inactivity timeout (For example,1 or 2 minutes). This might result in connection timeouts on fresh endpoints where PSAL also need to be installed as part of compliance evaluation.

•Ivanti Secure Access Client (Agent)-You can use Ivanti Secure Access Client, which contains the Host Checker component for compliance check. To manually install the Host Checker, Select Maintenance > System > Installers and download the installer.

Client ActiveX Installation Delay

During end-user sign-in, the setup client is delivered through either ActiveX or Java, depending on the client system's capability. By default, Internet Explorer blocks ActiveX content and displays an information bar that lets the user decide whether to install the new ActiveX control.

For restricted users, the information bar displays help information only, it does not allow installation of new ActiveX controls.

The system displays to end-users an intermediate page with a 15-second delay to interact with the information bar content. End-users can choose to skip the installation (and the 15-second delay) by clicking the "click here" link. If end-users choose to skip the installation, they are not prompted again unless they clear their browser cookies.

Administrators can customize the message and locale displayed in this intermediate page by clicking the Custom Messages tab in the Default Options for User Roles page and filling out information under the User Login Messages section.

Using Host Checker with the GINA Automatic Sign-In Function

Using Host Checker in conjunction with the Windows Graphical Identification and Authorization (GINA) sign-in function for VPN Tunneling requires that you pay particular attention to the type, level, and number of items to verify on the client before granting or rejecting access to the system. Since the GINA sign-in function takes place before Windows has completely launched on the client, and therefore, before the user profile on Windows is created, we recommend you adopt the following practices when creating Host Checker policies, you plan to use for Windows clients featuring the GINA sign-in function:

•You can check system-level processes at both realms enforce and realm evaluate. You can check user-level processes only at realm evaluate.

•If you have user-level processes at realm evaluate, create a separate VPN Tunneling role featuring only system-level policy checks that can be performed before Windows has completely launched on the client. Ensure that this role allows connectivity to the Windows Domain infrastructure in your secure network to support drive mapping, software updates, and group policies, for example. Mapping your users to this role allows the GINA authentication to complete. This role is in addition to the final role that you want the user to be mapped.