Windows 10 Support (including F5 BIG-IP Edge Client) Available With Certain BIG-IP APM Versions
This isthelatestinformation available from F5 regarding MicrosoftWindows 10 support (including F5 BIG-IP Edge Client) with certain BIG-IP APM versions. Microsoft Windows 10 support is available for certain BIG-IP APM versions. This entry replaces the original AskF5 solution (SOL16626) on support.f5.com F5 currently supports Microsoft Window 10 for the following versions: BIG-IP 12.0.0(seeF5 BIG-IP APM Client Compatibility Matrix for 12.0.0) Note: Support for Windows 10 has been added in BIG-IP 12.0.0 HF1 and later. For more information about BIG-IP hotfixes, please refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). BIG-IP 11.6.0 (see F5 BIG-IP Client Compatibility Matrix for 11.6.0) Note: Support for Windows 10 has been added in BIG-IP 11.6.0 HF6 and later. For more information about BIG-IP hotfixes, refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). BIG-IP 11.5.3 (see F5 BIG-IP APM Client Compatibility Matrix for 11.5.3) Note: Support for Windows 10 has been added in BIG-IP 11.5.3 HF2 and later. For more information about BIG-IP hotfixes, please refer toSOL13123: Managing BIG-IP product hotfixes (11.x - 12.x). Previously, in the original AskF5 solution (SOL16626), it was stated that F5 planned to support Windows 10 withBIG-IP 11.4.1. However, as many customers have been able to upgrade to newer versions of BIG-IP, and because F5customersshouldbenefit substantially from stability improvements in BIG-IP 11.5 and 12.0.0, which are within F5’sMajor Release/Long Term Stability Release model, F5 will not be providing additional support for Windows 10 with BIG-IP APM 11.4.1, as previously stated. Additionally, F5 will be enabling the following as regards Windows 10: Windows 10 Browser Support The Windows Internet Explorer browser included in the Windows 10 release is supported. The BIG-IP APM system does not currently support the Microsoft Edge (Spartan) browser. Inbox F5 VPN Client Windows 8.1 includes a built-in VPN client for BIG-IP APM (Inbox F5 VPN Client). For Windows 10, the VPN client for the BIG-IP system will be available for download from the Windows Store. Please note that the name of the app may also change. Windows Protected Workspace The Windows Protected Workspace feature of BIG-IP APM is not currently supported on Windows 10. Client side checks Certain client-side security checks (such as Patch Management and Windows Health Agent) are no longer supported on Windows 10. Depending on how you use these checks with BIG-IP APM, these Windows 10 client checks may fail. For information about adding Windows 10 clients to BIG-IP APM, please refer toSOL16874: Adding a new device type detection to an access policy.
BIG-IP APM: Max Sessions Per User – Enable users to terminate a specified session
Technical Challenge Recently I was speaking with a customer and they mentioned that they leveraged the “Max Sessions Per User” setting within BIG-IP APM Access Profile to limit the number of concurrent connections that a single user could have at any point in time. The customer mentioned that this works but often their users would complain that the “wrong” session was terminated or that a session they were actively using was closed. After reproducing the scenario in a lab environment I observed that the BIG-IP APM would terminate sessions based on FIFO (First In, First Out). Meaning that the oldest session was always terminated first regardless of which session the user was actively interacting with. Since this was confusing for the customer I figured others experienced this problem and it would be worth sharing my solution with the world. So how do you enforce “Max Sessions Per User” and enable your users to intelligently select which session to terminate? The Solution If we break down the problem statement above we can see that it it is really two issues. First we need to identify if a user has exceeded the maximum number of allocated sessions, then if they have we need to provide them a way to select which session should be terminated. Enforce Max Sessions Per User BIG-IP APM Access Profiles natively provide a way to limit the Maximum number of Sessions a user can establish but it doesn’t provide a way to interact with pre-existing sessions. For more information on Access Profile settings see => https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-network-access-11-6-0/9.html#taskid If the built-in functionality won’t achieve what we want lets build our own using APM iRule Events. iRule Session Enforcement The ACCESS::uuid iRule function will allow us to identify all active sessions for a specified Access Profile and Username. The iRule below will prevent a user from establishing more than 3 sessions when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when ACCESS_POLICY_COMPLETED { set max_sessions 3 set apm_username [ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] log local0. "[PROFILE::access name].$apm_username => session number [llength $apm_cookie_list]" if {[llength $apm_cookie_list] >= $max_sessions} { ACCESS::session remove ACCESS::respond 302 location "/vdesk/hangup.php3" } } This will allow us to limit concurrent connections for a user but is too late in the authentication process to enable the user to select a session to terminate. Instead of having the logic execute in the ACCESS_POLICY_COMPLETED section let’s try using an VPE iRule event. APM VPE iRule Event Session Enforcement First update your Access Policy to look similar to the images below with an iRule Event placed after the user authentication event. The iRule event id will be referenced in your iRule max_session_count The branch logic will be used to identify if the user has more than 3 concurrent sessions expr { [mcget {session.logon.last.count}] >= 3} Update the iRule you created earlier with the code below, this will allow the VPE policy to pause and execute events within the iRule. when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } } } Now as long as the user is below the defined maximum allowed connections they will be allowed to connect as normal. Enabling users to select a Session to be Terminated Now this is the tricky part, we need to provide an interface to the user that will enable them to select a session to be terminated. We could spend a bunch of time creating a custom web interface using javascript or we could re-purpose the Logon Page object built into the APM and display the information to the user with minimal customization. Remove the Password field from the Logon Page object and replace it with Radio and set the variable name to terminate Click on the textbox in the Values column of the terminate row and add one entry for each session the user is allowed to have. (If the max session count is set to 3 then add 3 options) The contents for the radio buttons will be dynamically generated within the iRule Event and stored as APM Session Variables The Value field should be %{session.logon.active.#.sid} (Session ID’s will be stored in a list variable that starts at 0, replace # with the appropriate index number starting at 0) %{session.logon.active.0.sid} %{session.logon.active.1.sid} %{session.logon.active.2.sid} The Text field should be %{session.logon.active.#.text} (The # should be replaced with the corresponding list index id) %{session.logon.active.0.text} %{session.logon.active.1.text} %{session.logon.active.2.text} After adding the appropriate number of options the final option should be cancel with text that will indicate that the current session will be terminated if the user selects cancel Click on the Branch Rules tab and add a new Branch Rule to handle logic that will allow the user to cancel Session Termination expr { [mcget {session.logon.last.terminate}] == "cancel" } Next update the iRule created earlier with the snippet listed below. The updated iRule will populate the session variables that will be used to display session information to the user. when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } } } Terminate the selected Session Now that we have a way to select a session to terminate add a second VPE iRule Event to handle the Session Termination The iRule event id will be referenced in your iRule terminate_session The branch logic will be used to verify that the session was terminated successfully, if it fails to terminate the users current session will be terminated instead. expr { [mcget {session.logon.last.terminateresult}] == 1 } Next update the iRule created earlier with the snippet listed below. The updates will add a second iRule Event that will handle the session termination when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } "terminate_session" { set removed0 set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _terminateid[ACCESS::session data get session.logon.last.terminate] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] if {$_sessionid eq $_terminateid} { set removed 1 ACCESS::session remove -sid [lindex $apm_cookie_list $i] break } } ACCESS::session data set session.logon.last.terminateresult$removed } } } Time to Test Now establish enough sessions to exceed the maximum concurrent user count and you should see receive a logon page prompting you to select a session to terminate. Putting Everything Together Step 1 – Edit your Access Policy When this step is complete your Access Policy should look similar to the attached imaged The first iRule Event should have the following information populated The iRule event id will be referenced in your iRule max_session_count The branch logic will be used to identify if the user has more than 3 concurrent sessions expr { [mcget {session.logon.last.count}] >= 3} The “Logon Page – Session Termination” should have the following information populated Remove the Password field from the Logon Page object and replace it with Radio and set the variable name to terminate Click on the textbox in the Values column of the terminate row and add one entry for each session the user is allowed to have. (If the max session count is set to 3 then add 3 options) The contents for the radio buttons will be dynamically generated within the iRule Event and stored as APM Session Variables The Value field should be %{session.logon.active.#.sid} (Session ID’s will be stored in a list variable that starts at 0, replace # with the appropriate index number starting at 0) %{session.logon.active.0.sid} %{session.logon.active.1.sid} %{session.logon.active.2.sid} The Text field should be %{session.logon.active.#.text} (The # should be replaced with the corresponding list index id) %{session.logon.active.0.text} %{session.logon.active.1.text} %{session.logon.active.2.text} After adding the appropriate number of options the final option should be cancel with text that will indicate that the current session will be terminated if the user selects cancel Click on the Branch Rules tab and add a new Branch Rule to handle logic that will allow the user to cancel Session Termination expr { [mcget {session.logon.last.terminate}] == "cancel" } The second iRule Event should have the following information populated The iRule event id will be referenced in your iRule terminate_session The branch logic will be used to verify that the session was terminated successfully, if it fails to terminate the users current session will be terminated instead. expr { [mcget {session.logon.last.terminateresult}] == 1 } Step 2 – Create and Apply the Custom iRule when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { "max_session_count" { set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list[ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _clientip[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.clientip] set _starttime[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.starttime] set _timeformat[clock format $_starttime -format "%H:%M:%S %d %b %Y "] set _connectiontype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.user.sessiontype] set _browsertype[ACCESS::session data get -sid [lindex $apm_cookie_list $i]session.client.type] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] set _sessioninfo"<table style='border-collapse: collapse' width='100%'>" append _sessioninfo"<tr><td style='border: 1px solid black'>Session ID</td><td style='border: 1px solid black' align='center'>$_sessionid</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Start Time</td><td style='border: 1px solid black' align='center'>$_timeformat</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Client IP</td><td style='border: 1px solid black' align='center'>$_clientip</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Connection Type</td><td style='border: 1px solid black' align='center'>$_connectiontype</td></tr>" append _sessioninfo"<tr><td style='border: 1px solid black'>Browser Type</td><td style='border: 1px solid black' align='center'>$_browsertype</td></tr>" append _sessioninfo"</table>" ACCESS::session data set session.logon.active.$i.sid $_sessionid ACCESS::session data set session.logon.active.$i.text $_sessioninfo } ACCESS::session data set session.logon.last.count[llength $apm_cookie_list] } "terminate_session" { set removed0 set apm_username[ACCESS::session data get session.logon.last.username] set apm_cookie_list [ ACCESS::uuid getsid "[PROFILE::access name].$apm_username" ] for {set i 0} {$i < [llength $apm_cookie_list]} {incr i} { set _terminateid[ACCESS::session data get session.logon.last.terminate] set _sessionid[ACCESS::session data get -sid [lindex $apm_cookie_list $i] session.user.sessionid] if {$_sessionid eq $_terminateid} { set removed 1 ACCESS::session remove -sid [lindex $apm_cookie_list $i] break } } ACCESS::session data set session.logon.last.terminateresult$removed } } }Application Programming Interface (API) Authentication types simplified
API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX API Connectivity Manager authentication and NGINX Single Sign-on.
F5 Access Policy Manager and Firefox Browser version 43 and 47+
Firefox Browser version 43 has new plug-in signing requirements. F5 will be providing Engineering Hotfixes for BIG-IP versions 12.0.0, 11.6.0, and 11.5.3, which will include a F5 Access Policy Manager plug-in signed by Firefox for Microsoft Windows and Linux platforms. With F5 officially supporting Firefox version 34, this is a “best efforts” approach to alleviate any disruptions brought about by Firefox version 43 and the upcoming Firefox version 44, related to plug-in signing requirements (Feature Enhancement ID:564253). If issues are uncovered with versions of Firefox greater than version 34 after installing the appropriate Engineering Hotfix, it is recommended that users be guided to use Microsoft Internet Explorer on Windows, and Safari on Mac, as detailed in thisDevCentral post. Another option is to use BIG-IP Edge Client for these two platforms. For Linux, there is a CLI client available for network access. These Engineering Hotfix releases are short-term fixes. A more permanent solution will be available in an upcoming release of BIG-IP; specifics will also be available in the aforementioned DevCentral post. We will make the Engineering hotfixes available for customers who create a support case with F5 Support. This Engineering Hotfix should be good for up to Firefox 46 and F5 will need to have Mozilla sign the plug-in again for Firefox 47+. This is just how Firefox plug-in signing works currently. January 7, 2016 Update: While we (F5) is making progress in getting the Engineering hotfixes out, we are currently working through some issues seen with the Mozzilla add-on submission tool. Once that is resolved, then we expect to be able to provide an ETA for the Engineering Hotifxes. F5 is working on this with urgency. January 8, 2016 Update: We (F5) have the issue with the Mozilla add-on tools resolved, so we can provide a target ETA of January 15, 2016 (Friday) to provide Engineering Hotfixes for the 3 versions of BIG-IP we had mentioned on this post. January 14, 2016 Update: We have run into a few issues that need to be addressed so we will need a few more days to have the Engineering Hotfixes available. Again,F5 is working on this with urgency. January 21, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.6.0, based on BIG-IP 11.6.0 Hotfix 6 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 12.0.0 and 11.5.3 soon. January 25, 2016 Update: We have an Engineering Hotfix for BIG-IP 12.0.0 based on BIG-IP 12.0.0 Hotfix 1 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 11.5.3 soon. January 26, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.5.3 based on BIG-IP 11.5.3 Hotfix 2. Customers should create a support case with F5 Support. F5 will target to release Engineering Hotfixes before Firefox 47 is available. May 9, 2016 Update: F5 is currently working on Engineering Hotfixes for the various BIG-IP for Firefox 47+ that would work for all Firefox versions (even Firefox 46 and earlier). Mozilla is allowing for plug-in signing for all (*) versions of Firefox again. We do not have the releases ready for customers yet but expect to have it shortly. Once they are available, we will announce it here and also provide it initially to F5 Support and thus customers can get it via a Support ticket. Shortly after it is available via F5 Support, we will provide it on https://downloads.f5.com. May 16, 2016 Update: F5 has Engineering Hotfixes for 11.5.4 HF1 and 11.6.0 HF6 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for12.0.0 HF2 and 11.6.1. May 21, 2016 Update: F5 has Engineering Hotfix for 12.0.0 HF2 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for11.6.1 and 12.1.0. May 31, 2016 Update:F5 has Engineering Hotfix for 11.6.1 available. For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. *These Engineering Hotfixes should work on all versions of Firefox, including 47+, until Firefox removes its NPAPI support. To address that we have another DevCentral post: here:https://devcentral.f5.com/s/articles/addressing-security-loopholes-of-third-party-browser-plug-ins
Implementing PCoIP Proxy as a Security Server or Access Point Alternative
VMware’s Horizon Security Server and Access Point provides secure access to sessions over an unsecured WAN and/or Internet connection. Typically, the Security Server/Access Point is placed within an organization’s DMZ and proxies connections to internal Horizon desktop and application resources. F5 BIG-IP Access Policy Manager (APM) provides an alternative method for secure access to Horizon desktop and application resources by simplifying your VMware Horizon with View architecture, improving security, and increasing scalability. Harden Security and Increase Scalability F5 BIG-IP Access Policy Manager is the industry’s first Application Delivery Networking solution that brings full PCoIP proxy capabilities—certified by Teradici—to the market. This permits IT administrators to replace the View Security Server with a more secure and highly scalable solution in support of their end-user computing deployments. BIG-IP APM is an ICSA Labs–certified flexible, high-performance access and security solution that provides unified global access to your applications and network. BIG-IP APM converges and consolidates remote access, LAN access, and wireless connections within a single management interface and provides easy-to-manage access policies. These capabilities help you free up valuable IT resources and scale cost-effectively. Simplifying Your Horizon Architecture Because BIG-IP APM removes the pairing dependency between Security Servers and Connection Servers, the overall architecture can not only be simplified, but a higher level of scalability can be achieved. In addition to BIG-IP APM, F5 BIG-IP Local Traffic Manager (LTM) can provide intelligent traffic management and load balancing to the Connection Servers. The reduction in the overall number of components that need to be managed results in increased productivity for IT administrators, which is especially critical for multi-site or multi-pod VMware Horizon deployments. Traffic Flow The diagram outlines the traffic flow of an external Horizon Client connection when using the BIG-IP Access Policy Manager (APM) Module as a Security Server/Access Point alternative: Device connects in from the untrusted network. Connection to APM made over HTTPS using the client or the F5 APM WebTop Portal. User logs in. APM processes the authentication (single/multi-factor) to AD and/or other authentication source (LDAPS/RADIUS, etc.) Once user is validated, APM sends a request to the load balanced pool of Connection Servers to get a list of authorized applications and desktops using HTTPS or HTTP. The user is then presented with the list of available and authorized desktops and applications. User selects the application or desktop to launch. Request then sent from client and proxied to View Connection Server via HTTPS – client receives desktop and/or application source machine info (including the public/client facing IP address if using NAT). Client establishes a connection to the virtual desktop or RDS application server to the APM via PCoIP, or HTML 5 (using HTML Access) using HTTPS . The APM proxies this connection back to the virtual desktop or RDS application server. We've developed a step-by-step guide for implementing PCoIP Proxy, which you can download here. You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.
Big-IP Access Policy Manager (APM) Identity Federation SAML Documentation
As enterprise customers start to accelerate their cloud Software-as-a-Service (SaaS) deployments their IT staff is observing increased help desk calls and user password fatigue issues. F5’s Big-IP Access Policy Manager (APM) product can address these requirements through its support for SAML 2.0 federation services like Identity Provider (IdP) for popular SaaS services such as Office 365, Salesforce etc. Big-IP APM supports both Service Provider (SP)-initiated and IdP-initiated deployments for identity federation to SaaS services as illustrated below User logs on to the Big-IP APM IdP and is directed to the webtop User selects a Salesforce service from the webtop. Big-IP APM may retrieve attributes from the user data store to pass on to the SaaS service provider. Big-IP APM directs the requests to the SaaS service with the SAML assertion and optional attributes via the user browser. User accesses Salesforce SaaS service. Salesforce redirects the user back to the Big-IP APM SAML IdP with SAML request via the user's browser. Big-IP APM prompts the user to logon with the relevant credentials. At this time Big-IP APM may retrieve attributes from the user data store to pass on with the SaaS service provider (SP). Big-IP APM then sends a SAML response to Salesforce with the authentication information and optional attributes via the user's browser for allowing access to the service. Over the years F5 has been extending its support for identity federation including support for SAML 2.0 OASIS standard features and publishing collateral for administrators to easily deploy Big-IP APM IdP services. Below is a consolidated list of documentation which includes the deployment guides to federate against the following SaaS services Office 365 Salesforce Workday Amazon Web Services Concur Service Now Jive Wombat Zendesk Cisco Webex Box Google Apps The deployment guides mentioned below provide details on setting up the following Big-IP APM objects for above mentioned SaaS applications Profiles, AAA server and Virtual Server IdP Configuration SP Connector Configuration Access Policy Setup using Visual Policy Editor iApps to setup the above configuration is also available in the guide* The deployment guides also have pointers on configuring SaaS SP services based on the SaaS provider documentation. While these deployment guides are provided as a quick reference for configuring the above mentioned SaaS applications, Big-IP APM can be used to setup almost any other SaaS applications that support SAML 2.0 OASIS standard. Deployment Guides Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Common SaaS Applications (For all SaaS applications other than office 365) Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Microsoft Office 365 Please add comments below should you have any feedback for this documentation or need other APM related documentation. * Production version of APM IdP to Office 365 iApp is available in the Office 365 guide. Beta version of iApp for all other SaaS applications is available here (production version will be released soon)Addressing Security Loopholes of Third-Party Browser Plug-ins - UPDATED FEBRUARY 2017
February 2017 Update Endpoint inspection and network access support with Chrome browser, Firefox, and Edge Browser is now available for BIG-IP v13 . Release notes with details are available here:https://support.f5.com/kb/en-us/products/big-ip_apm/releasenotes/related/relnote-helper-apps-13-0-0.html. January 2017 Update As the popularity of browser-based security attacks and vulnerabilities continue to increase, scrutiny is turning to third-party browser plugins as an attack vector. Java and Flash have both been successful targets, as have certain third-party malicious plugins. As a result, browser vendors are eager to close loopholes that allow control of page content and computer operation outside of the browser context. The longstanding F5 client technique of using browser plugins to allow VPN, application tunnel, and endpoint security checks utilize these functions. To mitigate these concerns, F5 will soon end the use of browser plug-ins. This will support the ability to run the endpoint security checks and connectivity operations such as SSL VPN and app tunnels with client PCs using new versions of popular web browsers - Google Chrome, Firefox, and Microsoft Edge Browser, in addition to Microsoft Internet Explorer and Apple Safari. F5’s plan is to use components that will be installed by end users that run outside of the browser process, thereby eliminating the security concerns of using browser plug-ins. These client components will register a URI scheme and will be able to be called from the browser when users launch a VPN or app tunnel from BIG-IP APM web portals, endpoint security checks (firewall, antivirus, and OS patch and registry checks). Additionally, a plug-in-less technique will be used to launch native Microsoft Remote Desktop apps or desktops on the user’s device without the traditional use of an ActiveX plugin. This solution will not require the use of browsers’ NPAPI support. Although end users will be required to download and install components that run outside of the browser process, F5’s most important goal is to keep the user experience as close to the current browser-initiated experience on currently supported browsers as much as possible. Alternatively, the client components may be installed by Microsoft’s SCCM or other automatic software installation systems in end user populations with limited rights on PCs. With this plan, F5 will also be able to support 64-bit versions of browsers specified above as well. In the meantime, you can use the below instructions to detect unsupported browsers and guide the user to a supported browser with a remediation message. Handling new Firefox and Chrome browsers in BIG-IP APM. Client browsers can be detected by their User-Agent header transmitted along with HTTP requests. APM automatically creates a session variable during Access Session creation that contains this value. It’s a simple matter to handle this in an appropriate way. Launch the Visual Policy Editor. Access Policy => Access Profiles => (your access policy) => Edit. The VPE will launch in a new browser tab Click the + icon to add a new Policy Item. Choose General Purpose => Empty and click Add Item. The new Policy Item will appear Name the Policy Item appropriately. (In this example, “Browser Info” was chosen.). Select the Branch Rules tab and click Add Branch Rule. Name the branch rule “Firefox 43” Click Advanced. Insert the TCL code: expr { [mcget "session.user.agent"] contains "Firefox/43" } Repeat the last 3 steps, this time for Firefox 44. Your new Policy Item should look something like this: 10. ClickSaveto save the changes to the Policy Item. Now we need to add a user friendly error message. 11. Near the top of the VPE screen, clickEdit Endings. 12. ClickAdd Ending. 13. Name the ending “Unsupported Firefox” 14. Click the+near Customization. 15. Change the text to something appropriate for your users. This is a sample: 16. Because the user should close the browser and use a different one, it doesn’t make sense to display a “Restart Session” link, so we simply hide it using the HTML <!-- and --> tags in the New session text and New session link areas. 17. Click the Deny endings attached from Firefox 43 and 44, and change them to the new “Unsupported Firefox” endings. 18. Review your Access Policy. The new section should appear similar to this (note that this policy is empty -- your normal policy should be attached to the “fallback” branch). 19. Test this with Firefox 43 or 44. You should see an error page similar to this: If you need to detect additional browsers and are not sure of the user agent, simply add a Message Box Policy Item to the beginning of the policy to log your browser’s User Agent string, like this: When a browser activates this Policy Item, the User-Agent will be displayed. We hope this is helpful. Update January 2017 Currently the latest Firefox version is release 50. Releases 50 and 51 include NPAPI plugin support that is required by F5 endpoint inspection and VPN access. Firefox release 52 will not allow the use of F5 plugin by default. This means that endpoint inspection and VPN will not function with Firefox browser for BIG-IP APM end users. F5 is planning to release BIG-IP version 13.0 that includes the new lite endpoint check and VPN clients that support a seamless end user experience with Firefox, Microsoft Edge Browser, and Chrome Browser. Based on current release schedules from F5 and Mozilla, the BIG-IP v13.0 release may not be available before Firefox 52 is released. If your end users require endpoint inspection or VPN launch capability with Firefox browser, we recommend installing Firefox ESR. This version will include plugin capability until early 2018. Firefox 51 Firefox 52 Firefox 53 Firefox ESR 52 F5 plugin allowed F5 plugin not allowed by default F5 plugin can be enabled via a configuration parameter in Firefox.* F5 plugin not allowed. F5 plugin will not be enabled even with a configuration parameter used in Firefox 52. F5 plugin allowed by default until Q2 Calendar Year 2018 *Firefox 52 Note: The configuration parameter is called plugin.load_flash_only, and it should be set to false. After this configuration parameter is created and set, the user needs to quit Firefox and delete pluginreg.dat file under profiles folder. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1269807 for more details. Note that this is preliminary information about a non-F5 product and is subject to change. Refer to the information about Firefox ESR: https://www.mozilla.org/en-US/firefox/organizations/ Information from Mozilla on future NPAPI support: https://blog.mozilla.org/futurereleases/F5 Access for Chrome OS Now Available
F5 recently released the F5 Access for Chrome OS version 1.0.0 application on the Chrome Web Store. This release of the F5 Access for Chrome OS app empowers customers to enable access from users’ Chromebooks to enterprise applications via F5 BIG-IP Access Policy Manager’s (APM) VPN capabilities. The F5 Access for Chrome OS v1.0.0 app is available publicly on Google’s Chrome Web Store as of Monday, December 21, 2015, and can be found at https://chrome.google.com/webstore/detail/f5-access/hhogfmlhffdddckpokfodepfiimfffjf?hl=en. Please note, though, that this release is for the F5 Access for Chrome OS v1.0.0 app, and is not the Chrome plug-in for the Google Chrome browser. F5 Access for Chrome OS v1.0.0 supports BIG-IP version 12.0.0, and is supported on Google Chrome OS version 46.0 and later. The BIG-IP versions that currently support F5 Access for Chrome OS v1.0.0 can be found in the BIG-IP Edge Client Compatibility Matrix. The release notes for F5 Access for Chrome OS v1.0.0 may be found at https://support.f5.com/kb/en-us/bigip-edge-apps.html. Please be aware that Chrome OS – and, as such, F5 Access for Chrome OS v1.0.0 – does not support per-app VPN, device ID availability, or VPN auto-reconnect (applicable when a user travels between wireless access points). Also, VPN performance is limited on low-end Chromebooks; this is a documented Chrome OS issue (Chrome OS issue: Issue 514341: chrome.vpnProvider severe performance). F5 Access for Chrome OS v1.0.0 will not support authorized third-party apps starting F5 Access, and the launching of third-party apps after connection. Also, F5 Access for Chrome OS v1.0.0 will not be localized. Please note that the F5 Access for Chrome OS v1.0.0 application will be configurable via Google Apps for Work. Documentation on this configuration will be available from F5 shortly. Should there be any additions or modifications to the F5 Access for Chrome OS v1.0.0 application, F5 will communicate those as soon as possible. Please contact F5 Support with any questions or comment regarding F5 Access for Chrome OS v1.0.0.Managing Horizon Traffic across Multiple Data Centers with BIG-IP DNS
In a typical single data center environment, VMware Horizon virtual desktop clients typically use a fully qualified domain name (FQDN) when accessing desktop and application resources. More and more customers are distributing their Horizon application and desktop infrastructure to distribute across multiple physical/logical data centers. Some of the business and technical reasons may include disaster recovery, system resiliency, and elastic desktop/application capacity. How are these multi-data center implementations of Horizon accessed? One common scenario is to provide a specific domain name to users either based on a user’s geographical location (for example, https://europe.example.com) or a user’s business unit (for example, https://finance.example.com). If the user has an ability to access resources from multiple data centers, the user’s overall experience might be sub-optimal if the end user is not being connected to the most appropriate, optimal data center. By deploying BIG-IP DNS (formerly Global Traffic Manager) with Horizon View, a single namespace (for example, https://desktop.example.com) can be provided to all end users - one URL to remember. BIG-IP DNS and BIG-IP Local Traffic Manager (LTM) also work together to ensure that requests are intelligently routed to a preferred data center, regardless of the user’s current location. In this example, users leverage a single namespace (view-apoc.bd.f5.com). They will initially connect to BIG-IP DNS (GTM). BIG-IP DNS will make a routing decision (based on availability, topology, connection, etc.) and then send the user to a specific data center. The user will then login with the Horizon View client and access their desktop/applications. If a data center is inaccessible, new users are automatically routed to the available data center; existing users will be disconnected and then reconnect to the live data center. Taking advantage of these key BIG-IP modules (BIG-IP DNS and LTM) empowers IT staff to integrate multiple VMware Horizon pods or physical sites for source desktops, all without disrupting users. By enabling users to reconnect to their existing persistent desktop source when required and providing a dynamic and agile infrastructure that can adapt to planned and unplanned events, the BIG-IP system becomes key to successful VMware Horizon deployments. We've developed a step-by-step guide for implementing BIG-IP DNS across two (or more) data centers using BIG-IP DNS and BIG-IP Local Traffic Manager, which you can download here . You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.APM Cannot Access Sesssion Variable Created by Irule
Hello, I am trying to pass the uri from an irule to the APM via a session variable However, the APM cannot find the variable. Here is the statement to generate the session variable. ACCESS::session data set session.user.custom.uri [HTTP::uri] I can see the variable in the console in Access››Overview:Active Sessions. dbe31cda.session.user.custom.uri I can also see it with the session dump command: sessiondump --sid=dbe31cda| grep custom.uri dbe31cda.session.user.custom.uri 18 /xxx/yyyy However, the APM cannot find the variable. variable "session.user.custom.uri" was not found in the local cache for session "dbe31cda" 'getSessionVar()': 594: try to get it from MEMCACHED variable "session.user.custom.uri" for session "dbe31cda" was not found in MEMCACHED Any ideas? Jeffrey
