Two-Factor Authentication – Captive Portal

Technical Challenge

F5 like most large enterprises organizations require Two-Factor Authentication (TFA) for employee remote connectivity. To meet this requirement IT integrated BIG-IP Access Policy Manager with a third-party vendor that provides One-Time Passwords (OTP). After users successfully authenticate they are prompted to provide their OTP that is then verified against a Radius server. Most of the time this works great but occasionally the employees preferred Operating System or VPN Client doesn’t support multiple authentication methods.

BIG-IP Edge Client (Linux)
F5 VPN Client (Windows 10)
Inbox F5 VPN Client (Windows 8.1)

Traditionally to work around these limitations employees would be required to concatenate their Password + OTP. While BIG-IP Access Policy Manager is capable of supporting concatenated passwords there is a more graceful option, TFA through a Captive Portal

The Solution

To workaround the limitation mentioned above IT decided to configure BIG-IP Access Policy Manager to allow all clients to establish a VPN for remote connectivity regardless of the clients ability to preform TFA. An iRule is used to determine whether or not the employee successfully completed TFA.

Clients that natively support TFA are prompted to provide their username, password and OTP on initial connection. After they successfully authenticate and complete TFA they are granted access to the appropriate resources.

Clients that do not support TFA are prompted to provide a valid username and password, after the employee successfully authenticates all HTTP & HTTPS requests are intercepted and a custom login page is returned in response. This custom login page prompts the user to provide a valid OTP. Until the employee provides the correct OTP all traffic is rejected by an iRule applied. Once the employee provides the correct OTP the iRule updates an BIG-IP Access Policy Manager session variable to indicate that the employee should have the same network access as clients that natively support TFA.

Solution Caveat

This solution will leverage layered virtual servers and this could negatively impact network access tunnel layer 4 ACL

https://support.f5.com/kb/en-us/solutions/public/14000/200/sol14219.html?sr=48427459

Putting Everything Together

Step 1 – Update your “Remote Access” Access Policy

We need to differentiate the clients that either do or do not support TFA, IT did this by configuring the BIG-IP Access Policy Manager access policy to detect the Client Type or Operation System as seen below.

Step 2 – Create a Captive Portal Access Policy

Since clients that don’t support TFA will not be able to validate their OTP against the “Remote Access” policy we will need to create an alternative way to validate their tokens. To do this create a second Access Profile and configure the Access Policy to validate the OTP token using the preferred method in ITs case that was radius.

Step 3 – Upload the Captive Portal iFile

If you have questions on iFiles please see => Referencing External Files

Example Captive Portal HTML

<HTML><HEAD><TITLE>TWO-Factor Captive Portal</TITLE>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META content=no-cache http-equiv=pragma>
<link rel="stylesheet" type="text/css" HREF="/public/include/css/apm.css">

</HEAD>
<BODY>
<META id=viewport name=viewport content="width=device-width, initial-scale=1.0">
<META name=robots context="noindex,nofollow">

<TABLE id=page_header>
<TBODY>
<TR>
<TD id=header_leftcell><IMG src="/public/images/my/flogo.png"></TD>
<TD id=header_rightcell></TD></TR>
<TR>
<TD></TD>
</TR></TBODY></TABLE>
<TABLE id=main_table class=logon_page>
<TBODY>
<TR>
<TD style="WIDTH: 1%" id=main_table_info_cell>
<FORM id=auth_form method=post name=e1 action="/my.policy" autocomplete="off">
<TABLE id=credentials_table>
<TBODY>
<TR>
<TD id=credentials_table_header colSpan=2>TWO-Factor Token Validation</TD></TR>
<TR>
<TD id=credentials_table_postheader colSpan=2></TD></TR>
<TR>
<TD class=credentials_table_unified_cell colSpan=2><LABEL for=text>Username</LABEL><INPUT id=input_1 class=credentials_input_text name=username disabled></TD></TR>
<TR>
<TD class=credentials_table_unified_cell colSpan=2><LABEL for=text>One-Time Passcode</LABEL><INPUT id=input_2 type="tel" class=credentials_input_text name=password autocomplete="off" autocapitalize="off"></TD></TR>
<TR id=submit_row>
<TD class=credentials_table_unified_cell><INPUT class=credentials_input_submit value=Validate type=submit></TD></TR>
<TR>
<TD id=credentials_table_footer colSpan=2></TD></TR></TBODY></TABLE><INPUT value=standard type=hidden name=vhost> </FORM>

</TD></TR></TBODY></TABLE>
<DIV id=page_footer>
<DIV>This product is licensed from F5 Networks. © 1999-2014 F5 Networks. All rights reserved. </DIV></DIV>

<DIV id=MessageDIV class=inspectionHostDIVSmall></DIV></BODY></HTML>

Example Captive Portal Page

Step 3.1 – Upload your Captive Portal page as an External File that can be referenced in the iRule below

Step 3.2 – Assign your Captive Portal External File to an iFile that can be referenced in the iRule below

Step 4 – Create the Captive Portal iRule

The iRule listed below will be applied to a virtual that will be targeted with the virtual-to-virtual (V2V) function.

The iRule will disable SSL for HTTP traffic on TCP Port 80
Re-write the Captive_Portal iFile that was uploaded earlier to reference CSS and Images associated to your main login page
Checks to see if the request method is a POST or not
If it is NOT a POST then return the Captive_Portal page
If it is a POST then parse out the OTP token and validate it against the Captive_Portal access policy created earlier
If the Access Policy result is “allow” then update the last radius result value to 1 and redirect the user to the originally requested content

when CLIENT_ACCEPTED { 
if {[TCP::local_port] eq 80} 
{ 
SSL::disable clientside 
SSL::disable serverside 
} 
} 
when HTTP_REQUEST { 
set _un [ACCESS::session data get session.logon.last.username] 
if {[HTTP::method] ne "POST"} 
{ 
set _fqdn [ACCESS::session data get session.server.network.name] 
set _captivePortal[ifile get "/Common/Captive_Portal.html"]
set _captivePortal[string map [list "/my.policy" [HTTP::uri]] $_captivePortal] 
set _captivePortal[string map [list "HREF=\"" "HREF=\"https://$_fqdn"] $_captivePortal]
set _captivePortal[string map [list "src=\"" "src=\"https://$_fqdn"] $_captivePortal]
set _captivePortal[string map [list "input_1" "input_1 value=\"$_un\""] $_captivePortal] 

HTTP::respond 200 content $_captivePortal "Content-Type" "text/html; charset=UTF-8" 
} elseif {[HTTP::method] eq "POST" } 
{ 
HTTP::collect [HTTP::header content-length] 
} 
} 
when HTTP_REQUEST_DATA { 
set _payload"?[HTTP::payload]" 
set _otp[URI::query $_payload "password"] 

if {$_otp eq ""}{HTTP::redirect [HTTP::uri];return} 

set _flow_sid[ACCESS::session create -timeout 600 -lifetime 3600] 
set _profile"/Common/Captive_Portal" ACCESS::policy evaluate -sid $_flow_sid -profile $_profile session.logon.last.username $_un session.logon.last.password $_otp
set _result[ACCESS::policy result -sid $_flow_sid] 

ACCESS::session remove -sid $_flow_sid 
if {$_result eq "allow"} 
{
ACCESS::session data set session.radius.last.result 1 
TCP::close 
HTTP::redirect [HTTP::uri] 
} 
else {HTTP::redirect [HTTP::uri]} 

HTTP::release 
}

Step 5 – Create the Captive Portal Reject iRule

This iRule will be applied to the Layered Virtual Server that will be created later on. This iRule checks to verify that user traffic has PASSED TFA before allowing it to access network resources. It will also detect webtop traffic and allow that through.

If the employee has passed TFA or if they are requesting a proxied resource through the Portal Access
- Take no action
ElseIF the employee has NOT passed TFA and they are NOT requesting a proxied resource and the request isn’t over UDP
- Use the V2V function referenced earlier to direct traffic to the Captive_Portal Virtual
ElseIF the employee is requesting DNS traffic over TCP/UDP port 53
- Take no action
  - If you are concerned with DNS tunneling we could create Layered Virtual Server listening on port 53 and apply a GTM iRule that will intercept DNS Requests
Else
- Reject traffic until the employee completes TFA

when CLIENT_ACCEPTED { 
set _radius[ACCESS::session data get session.radius.last.result] 
set _clientip[ACCESS::session data get session.assigned.clientip] 

if {$_radius eq 1 || $_clientip eq ""} 
{ return } 
elseif 
{$_radius ne 1 && $_clientip ne "" && [IP::protocol] ne 17 } { virtual /Common/v2v_CaptivePortal_v4 } 
elseif {([IP::protocol] eq 17 && [UDP::local_port] eq 53) || ([IP::protocol] eq 6 && [TCP::local_port] eq 53) } 
{ return } 
else 
{ reject } 
}

Step 6 – Create the virtuals that will be used to handle traffic

Step 6.1 – Create the APM Layered Virtual

This virtual server listens on the “connectivity” vlan. The “connectivity” vlan is associated with the connectivity profile applied to the virtual server used to provide employee remote access.
It is commonly referred to as a Layered Virtual Server. For more information on Layered Virtual Servers (LVS) see => Common Deployment Examples for Single Sign-On
This LVS will match all traffic except TCP port 80, a more specific LVS (_tmm_apm_fwd_vip_http) embedded within BIG-IP Access Policy Manager is used to enforce L4 ACL. See below on steps to create a more specific LVS to capture port 80 traffic

ltm virtual lvs_CaptivePortal_v4_ANY { 
destination 0.0.0.0:any 
ip-protocol any 
mask any 
profiles { fastL4 { } } 
rules { Captive_Portal_Reject } 
source 0.0.0.0/0 
translate-address disabled 
translate-port 
disabled vlans { connectivity } 
vlans-enabled 
}

Step 6.2 – Create the APM Layered Virtual that will match on TCP port 80 traffic

The virtual created above will match on all traffic except TCP port 80, to capture that traffic we need to create a more specific virtual.

ltm virtual lvs_CaptivePortal_v4_80 { 
destination 0.0.0.0:http 
ip-protocol tcp 
mask any 
profiles { fastL4 { } } 
rules { Captive_Portal_Reject } 
source 0.0.0.0/0 
translate-address disabled 
translate-port disabled 
vlans { connectivity } 
vlans-enabled 
}

Step 6.3 – Create the V2V Captive Portal Virtual

This virtual is used to display the Captive Portal created earlier and should NOT be assigned to any vlan.

Optional - SSL Forward Proxy

This example utilizes the SSL Forward Proxy functionality to display the prevent a certificate error from being displayed but is not required. For more information on SSL Forward Proxy see => Implmenting SSL Forward Proxy

ltm virtual v2v_CaptivePortal_v4 { 
destination 0.0.0.0:any 
ip-protocol tcp 
mask any 
profiles { 
clientssl_proxy { context clientside } 
http { } 
serverssl_proxy { context serverside } 
tcp { } 
} 
rules { Captive_Portal } 
source 0.0.0.0/0 
translate-address disabled 
translate-port disabled 
vlans-enabled 
}

Published Sep 25, 2015

Version 1.0

application delivery

BIG-IP Access Policy Manager (APM)

two-factor authentication