As an optional client-side component, you can install the PortalGuard Desktop on your workstations.The PortalGuard Desktop software contains multiple, independent features:
1) Desktop Self-Service & Enrollment
3) Desktop Two Factor Login
4) Credibility-Based Authentication
Desktop Self-Service & Enrollment
This feature can be used to force users to enroll in the Challenge Question and Answer recovery feature (by providing personal answers to the questions they choose) AND unlock their account or reset their password directly from the Windows logon screen.
When users log into their Windows workstation, they can be forced to set their challenge answers if they have not already done so. They must complete this enrollment before their Windows desktop will appear. If they forget their password, they can launch a password recovery wizard directly from the Windows login screen that allows them to reset their password and unlock their Active Directory account when on the network.
When users are off the corporate network but forget their Active Directory domain password, resetting the password is not an option as this requires network connectivity to an Active Directory domain controller.Instead they can restore access to their workstation by being shown their current/forgotten password after correctly answering a sufficient number of the same challenge questions.They can then login to their machine using Windows cached credentials.
PassiveKey (formerly named “Transparent Tokenless Toolbar”) provides the security of two-factor authentication without burdening the end-user to manually enter OTPs sent or generated by a mobile phone and without the additional expense and management overhead associated with hardware tokens.See the How It Works section below for more details.
Desktop Two Factor Login
An optional component in the PortalGuard Desktop is Desktop Two Factor Login.When installed, this requires users to login to their Windows workstations with both their Active Directory domain account and a One-Time Passcode (OTP).This feature is good for more security conscious customers who would like to enforce 2FA as part of the Windows login.The allowable OTP types are configurable.
This is comprised of components that integrate with the web browsers on the workstation.Their purpose is to provide better quality information about the client that is delivered to the PortalGuard server.This pertains specifically to the credibility-based authentication feature in PortalGuard that can require less trustworthy requests to login with a more stringent authentication method.The information sent to the server can include geo-location/GPS coordinates, time zone, wireless authentication & encryption levels (when applicable) and locally installed hard drives and other devices.
How It Works
Desktop Self-Service & Enrollment
The PortalGuard Desktop integrates with Windows to communicate with the PortalGuard server when it is available on the network.This allows users to enroll their challenge answers and reset their password and unlock their Active Directory account when on the corporate network.Since an Active Directory domain controller is reachable by the client, any new password can be used immediately to login to the workstation.
Once the user provides their correct credentials to Windows, this feature verifies that the user is in compliance with the settings in their PortalGuard policy.For example, enrolling challenge answers can be enforced in this policy and if the user has not already done so, they will be forced to provide these answers before getting to their Windows desktop.If offline password recovery is enabled in the PortalGuard policy, then these credentials are used to create and/or verify the user's encrypted recovery information on the server.This encrypted information is validated and copied to the local machine upon each network login to Windows.If the user changes their Windows password from the workstation or resets their password using PortalGuard, the new password is sent to the PortalGuard server in the background and this recovery information is automatically rebuilt.
Decryption of the recovery information is attempted using the challenge answers provided by the user when offline.Optionally, an offline lockout feature can be used to delete this recovery information after a configurable number of unsuccessful attempts.
The PassiveKey component of the PortalGuard Desktop serves to validate both the user -AND- the device they're using. PassiveKey is implemented as a browser toolbar installed on workstations that automatically generates a Time-based One-time Password (TOTP) on a regular interval and sets the value as a session-based cookie. This cookie is created for only specific websites and is encrypted using public-key cryptography to ensure only the PortalGuard server can decrypt it.
Once installed, the user is automatically enrolled when they login to their workstation.Enrollment data on the workstation consists of the following:
- A private/public key pair – These are generated and stored on the workstation.They are used to identify this specific user and workstation and create a PKI certificate request which is sent to the PortalGuard server.The password for this container is randomly generated and encrypted using Microsoft’s Data Protection API.This ties the user’s data to their Windows user profile.
- Certificate Authority public certificate – The public key of the PortalGuard server certificate authority is used to encrypt the cookies created by PassiveKey.Only the PortalGuard server has the private key that can decrypt the cookie.
- TOTP seed value – This is used by PassiveKey to generate a temporary time-based OTP.This seed is created by the PortalGuard server during the enrollment process and exists on both the workstation and the PortalGuard server.It is encrypted on the workstation using the user’s public key.
Enrollment data on the PortalGuard server consists of the following:
- A private/public key pair – These are generated and stored on the server in a one-time setup step.They are used to identify the PortalGuard server.They are protected with a randomly generated passphrase that is encrypted and stored in the PortalGuard bootstrap configuration.
- Self-certified Certificate Authority– The foundation of the PKI created automatically by the PortalGuard server.
- TOTP seed value – This is used by the server to validate TOTPs sent by users.This seed is created by the PortalGuard server during the enrollment process.It is encrypted on the server using the server’s public key and is stored as part of the user’s PortalGuard profile.
The enrollment workflow occurs entirely over HTTP/HTTPS and is as follows:
- TTTEnrollment.exe on workstation automatically runs when user logs into Windows. It checks the state of the local enrollment data.It exits immediately if all parts are present and valid.If the signed public certificate is missing, then the process continues.
- The PortalGuard enrollment website is contacted in the background via HTTP/HTTPS.
- If Active Directory is being used as the PortalGuard user repository, then the PortalGuard enrollment website would be configured for Integrated Windows authentication so the user is automatically logged in using Kerberos or NTLM.If Active Directory is not the repository, then the user will receive a prompt to manually authenticate to PortalGuard.
- On the workstation, a public/private keypair is generated and an associated Certificate Signing Request (CSR) is created and sent to the PortalGuard enrollment website.
- If the user’s policy allows PassiveKey enrollment, then a signed public certificate is created and stored in the user’s PortalGuard profile on the server.
- The signed public certificate and the Certificate Authority’s public certificate are sent back to the workstation and saved.
- The workstation then submits a TOTP enrollment request to the server.
- If the user’s policy allows PassiveKey enrollment, then a random TOTP seed is generated, encrypted with the user’s public key and sent back.The TOTP seed is encrypted using the server’s public key and saved in the user’s PortalGuard profile on the server.
- The workstation decrypts the TOTP seed with the user’ private key to ensure validity.It then saves all data in a container, AES-256 encrypts it with a randomly generated 64-character passphrase, then protects that passphrase with Microsoft DPAPI.
During normal browser usage, the toolbar automatically recreates the TOTP and cookie containing it on a set interval.The PortalGuard server will automatically validate the TOTP when it requires a second factor of authentication, saving the user from having to receive and manually prove possession of a device (mobile phone or hardware token).
PassiveKey for VPN/RADIUS
Starting with version 1.8 of the PortalGuard Desktop, PassiveKey TOTPs can now also be used for VPN/RADIUS access.A new “TOTP Helper” executable is installed that computes the TOTP for the current user, enters it into the currently high-lighted field and simulates a press of the ‘Enter’ key.The user triggers the TOTP Helper via Windows hotkey.The default hotkey for the TOTP Helper is Ctrl-Shift-O, with the “O” standing for “OTP”.
Here is a typical sequence demonstrating how this feature is used:
1) User launches their VPN client (e.g. IPSEC-based) or browser to the SSL VPN web page
2) User enters their standard username and password and submits it
3) The PortalGuard server validates these credentials and sends back a RADIUS response to the VPN appliance that causes the user to be prompted for an OTP
4) The user ensures the OTP/challenge input field has focus (e.g. contains a blinking cursor), the presses Ctrl-Shift-O
5) The TOTP Helper runs in the background, generating the TOTP, entering it into the VPN input field and automatically pressing the Enter key for the user.
6) The TOTP is validated by the PortalGuard server and the user’s VPN is successfully established.
This approach allows the PassiveKey TOTP to be used for VPN access without requiring any changes or custom work to occur on the VPN appliance.
Desktop Two Factor Login
The Desktop Two Factor Login component of the PortalGuard Desktop is implemented as a Microsoft Credential Provider module.It enforces 2FA when the user logs into their Windows workstation.It can also be installed on the Windows Server operating system to enforce 2FA login for Terminal Services or Citrix logins.
The user enters their Active Directory domain username and password as usual at the Windows logon screen.These credentials are sent to the PortalGuard web server via HTTPS for validation.If the user’s PortalGuard security policy is configured to require 2FA for Desktop login, then the user receives a prompt to enter an OTP.The PortalGuard server will automatically generate and send the user an OTP if the user’s phone is the default mechanism.
Once the user enters the correct OTP, their Windows session begins.
This is comprised of browser add-ins that run in the context of the web browser on the workstation.Each time the browser is launched, the toolbars loads in the background as well.It does not have a user interface or graphical component.
The toolbar queries the workstation to determine information about the current user, machine, network and devices.Here are some of the attributes that are queried:
- Operating system
- Current time and time zone
- Machine host name
- Active Directory domain
- Windows username
- User Security Identifier (SID)
- Hard drive model and serial numbers
- Network interface cards (NICs) with MAC and IP addresses
- User’s geo-location/GPS coordinates
- Wireless network SSID, authentication and encryption levels (if applicable)
These attributes are formatted into XML, encoded and created as session-based cookies that will only be sent to the PortalGuard server.Each time the user accesses a PortalGuard server through the web browser, this cookie is sent with the HTTP request and PortalGuard has a much richer set of information about the user upon which it can gauge their level of credibility.Client devices with this software installed are referred to as “Managed” devices.