You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.

Looking for the Diagnostic Utility?

Click Here For Download and Usage Instructions

Require 2FA Only When End-Users Are Outside the LAN


Your LAN is a trusted network so users should only be required to authenticate to PortalGuard using just a username & password or via Kerberos. When they are coming into PortalGuard from the internet, they should be required to login using 2FA.


This can be achieved by differentiating these scenarios based on the user's IP address. The LAN network(s) are readily known and can be used to identify LAN-based access attempts from others.

Enforcing different authentication for the same user based on IP address originally required the use of Credibility Policies and "credibility scoring" through PortalGuard's Credibility-Based Authentication (CBA). The original version of this feature was introduced in 2011 used a scoring model where the higher the score, the more trustworthy the request could be considered. Numerous attributes of the request (IP address, time of day, if the PG Desktop browser toolbar was present, Geolocation) could affect the score differently.

The following problems prevented this feature from widespread use:

  • The scoring had to map down to specific ranges where the resulting authentication type was determined. This scoring "range" approach was not easy to configure and "get right".
  • The Geolocation support required the PG Desktop browser toolbar which utilized the Google Gears API. This API is no longer available.
  • Chrome and Firefox browsers removed support for NPAPI so the PG Desktop browser toolbar was further diminished an option.

The new, simplified v2 implementation of Contextual Authentication does not rely on any client-side software. It also completely eliminates the use of a scoring system in favor of discrete conditions that can be combined to explicitly determine what type of authentication the requestor must perform. For example, if the IP address is outside of those defined, then require 2FA. If the request is coming from Russia, then block it completely.

The conditions that can be evaluated in the new implementation are:

  1. IP-based Geolocation – The request of the IP address is used to lookup the associated location. This utilizes a free SQL database from IP2Location, but paid versions can provide better accuracy. HTML5 based location cannot be used because it requires end-user consent and can be spoofed by the end-user. It cannot be trusted for authentication decisions.
  2. Network/IP Address – The old standby, the IP address of the requestor. When PortalGuard is behind a load balancer or reverse proxy, the device in front of PG *must* send the client IP address in the X-Forwarded-For header (link) for PG to see it. Please consult your product's documentation.
  3. Browser Tracking – Cookies are used to track the user's browser and emails can optionally be sent notifying users when a new browser is used to login to their account. Similar functionality is fairly common today and is leveraged by companies like Google and Microsoft.

The IP-based scenario defined above only requires use of the 2nd type defined above. This does not require any additional setup of configuration aside from changes to the Security Policy that applies to the end-users. The steps below describe how to configure this feature:

  1. Navigate to the PortalGuard server and open the PortalGuard Configuration Editor.
  2. Navigate to the Security Policies tab.
  3. Click on the Security Policy you wish to edit in order to highlight it. Double click or click on the 'Edit' button to modify.
  4. Navigate to the Actions -> Login tab and choose the 'Contextual (Simplified, v2.0)' option from the PortalGuard WebSite Login field
  5. Since you want to only allow single-factor authentication for users on the LAN, set the Default Authentication Type to 'Two-factor (2FA)' on the Actions -> Login -> Contextual 2.0 -> Defaults sub-tab.
  6. On the Conditions - Password Only tab, in the ANY Matches grouping on the right-hand side, click the Add button.
  7. In the 'CBA Condition' dialog box that appears, set the Condition Type field to 'Network / IP'.
  8. Set the Start IP and End IP addresses to match one of the IPv4 subnets for your LAN, then click the OK button.
  9. Follow steps 6-8 for each unique LAN subnet in your environment where single factor authentication to PortalGuard should be allowed.
  10. Click the 'Save' button to keep the changes.
  11. On the main screen of the PortalGuard Configuration Editor, click the red 'Apply to PortalGuard Server' button.
  12. Click the 'Sync' button.
  • 32
  • 24-Sep-2018