PortalGuard Desktop

This component is described in the overview section.

Installation Requirements

The following items are required for all features available in the PortalGuard Desktop software:

  • Windows XP SP3, Vista, Windows 7 or 8 operating system (32 or 64-bit)
  • The .NET Framework 2.0 or later must be installed on the machine
  • Installation must be performed by an administrator
  • A PortalGuard server must be running on your network and reachable by the client workstation. The server bit size (32-bit or 64-bit) does not need to match that of the client.

NOTE: Beginning with version 2.0 (released August 2013), the Desktop Self-Service & Enrollment feature no longer attempts to ping the PortalGuard server using ICMP/echo to determine if it is reachable. It now uses HTTP to test for connectivity instead. For both methods, if the connectivity test fails, the PortalGuard Desktop will fall back to its “offline” mode if that feature is installed or display a “recovery not possible” message if the “offline” feature was not installed.

For Desktop Self-Service & Enrollment

  • On Windows XP, you must use the standard Microsoft GINA

For Desktop Two Factor Login

  • The PortalGuard server must be configured to verify the user’s credentials against the network directory (e.g. Active Directory domain).
  • Login using local Windows accounts is not supported.
  • Windows XP is not supported, only Windows 7 and later
  • The workstation must have HTTPS connectivity to the PortalGuard server. Offline and logins using cached windows credentials are not currently supported.
  • Resending generated OTPs is not currently supported.

For PassiveKey and Credibility-based Authentication

Supported web browsers are:

  • Microsoft Internet Explorer 8.0 or later (32-bit only)
  • Mozilla Firefox version 18 or later
  • Google Chrome version 19 or later

Installation

The PortalGuard Desktop is installed through an MSI. There are separate MSIs for 32-bit and 64-bit platforms. A reboot is required for the Desktop Self-Service & Enrollment and Offline Recovery features to work correctly after the install due to the low-level integration with the operating system, but it can be postponed.

Because the MSIs are fully-compliant, they can be rolled out silently with MSTs using third party products such as Microsoft SMS and Altiris, or via logon scripts. Please contact our technical support team for further details about automated deployment.

Desktop Self-Service & Enrollment

If you wish to install the Desktop Self-Service & Enrollment feature, simply choose the feature shown in the illustration below:

;

You will be prompted for the full URL to the PortalGuard server.

If you wish to also give users the ability to recover their password while traveling, choose the “Offline Recovery” feature for installation. Please note the “Desktop Self-Service & Enrollment” feature must also be installed if you would like to use Offline Recovery.

Desktop Two Factor Login

If you wish to install the Desktop Two Factor Login feature, simply choose the feature shown in the illustration below:

;

You will be prompted for the full URL to the PortalGuard server.

NOTE: This feature can be installed with the “Desktop Self-Service & Enrollment” feature but cannot be installed with its “Offline Recovery” feature.

PassiveKey™ and Credibility-based Authentication

If you wish to install the Credibility-based Authentication web browser add-ons, choose the feature shown in the illustration below:

After installing the feature, the servers to which the credibility cookie will be sent must be specified. This is currently done by opening the appropriate CBA_servers.reg file in the “Program Files\PistolStar\PortalGuard Desktop” folder in a text editor. The RBA_Servers” string should contain the host names and IP addresses of your PortalGuard servers. To specify multiple server names or IP addresses, they must be separated by a single comma without any spaces as shown below:

Merge the .reg file into the local registry as an administrator to ensure the changes are accepted by Windows. Please note that a standard .reg file can be used for your entire environment.

Using the PortalGuard Desktop

Desktop Self-Service & Enrollment

After reboot, Windows XP machines show a Forgot Password? button on the logon dialog. In Windows 7 and Vista, a Forgot Password? link is available on each user's logon tile. When the user clicks either of these controls, it launches a protected web browser shell that goes to the Reset Forgotten Password web application wizard directly from the PortalGuard server when the user is on the network.

To make offline recovery available, you must enable it in the PortalGuard policy that applies to the user. Users must also log on to their workstation while on the corporate network at least once for the encrypted recovery information to be copied to their local machine. Encrypted recovery information for multiple users can be stored on the same machine and is automatically refreshed each time users log into a machine on the corporate network. The encrypted recovery information is stored as base64 encoded string variables in the following registry key:

HKLM\Software\PistolStar\PortalGuard\ERB

Since the operating system reads and writes this information during offline recovery, end-users do not need any explicit rights to this key.

Desktop Two Factor Login

After reboot, the user will be prompted to login using their username and password as usual. You can tell the PortalGuard Desktop is handling the login attempt because the tile image will be the green PortalGuard lock.

The entered information is sent to the PortalGuard server for verification against the network directory (e.g. Active Directory domain). If the user’s PortalGuard security policy is set to require only username and password authentication for Desktop logins, the user will not be prompted to enter any additional information once their credentials are submitted correctly.

If the PortalGuard security policy requires two factor authentication for Desktop logins, the user will be prompted to enter an OTP using their default method. Administrators can set the default OTP method in the PortalGuard security policy and optionally allow users to override this on their PortalGuard Account Management page. A new OTP will immediately be generated and sent if the user’s default OTP method is set to phone. The user will be prompted appropriately based on their default OTP method.

Multiple OTP methods, including Help Desk generated OTPs, may be acceptable – again, based on the PortalGuard security policy. Once the user supplies a correct OTP, their credentials will be passed to the default Windows authentication package (e.g. Kerberos) which will also validate them before creating the Windows session and allowing the user access to their Windows desktop.

Credibility-based Authentication

There is no user interface for this feature so the end-user does not need to interact with it.