BIG-IP APM Operations Guide

Transcription

1 BIG-IP APM Operations Guide Comprehensive Global Access Anytime, Anywhere With BIG-IP Access Policy Manager (APM), your network, cloud, and applications are secure. BIG-IP APM provides valuable insight into who is on your network or cloud, which applications they are accessing, with which devices, from where, and when.

2 CONTENTS Contents About This Guide 1 Before using this guide 1 Limits of this guide 1 Glossary 2 Customization 2 Issue escalation 2 Feedback and notifications 3 Configuration utility 3 Command-line syntax 3 Finding other documents 4 Introduction 5 BIG-IP APM features 5 Client interaction with BIG-IP APM 7 BIG-IP APM with other BIG-IP modules 8 Licenses 11 BIG-IP APM license types 11 License limits 13 BIG-IP APM Lite 14 Use Cases 15 Authentication and Single Sign-On 15 Network Access 21 Per-Application VPN 24 Application tunnel 25 Web Access Management 28 Portal Access 30 Citrix integration 33 VMware View support 36 Exchange proxy 37 Webtop 40 ACLs 41 ii

3 CONTENTS Step-up authentication 42 Forward proxy 45 OAuth authorization 46 BIG-IP Edge Client 49 Client Types 49 VPN client types 50 Remote Desktop Protocol and Remote App Support 52 Features 52 Components 52 Implementation 52 General RDP FAQ 55 RDP load balancing FAQ 56 IPv6 FAQ 57 Client requirements 58 Troubleshooting RemoteAPP and Remote Desktop 59 RDG-RAP access policies 69 Logging 70 Security 72 Session management 72 Identity access management 76 Network Security 77 Auditing 78 High Availability 79 BIG-IP APM failover components 79 High availability 80 Policy Sync 82 High availability on VIPRION 82 Management 87 License usage monitoring 87 Logs 90 SNMP Monitoring 93 Authentication resource monitoring 95 iii

4 CONTENTS Access Programmability 96 irules and F5 support 96 DevCentral community 96 irules on demand and F5 Professional Services 96 ACCESS irules Structure 96 Changing policy behavior 106 Clientless mode 111 Troubleshooting 114 Configuration and compatibility checks 114 Network access issues 118 Application tunnel issues 121 Authentication issues 122 Web Access Management issues 126 Portal Access issues 128 Per-Application VPN issues 129 SSO issues 130 NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO troubleshooting 133 Tools and utilities 135 Collecting BIG-IP APM Data for Support 138 Logging (BIG-IP 12.0 and later) 138 Network captures 139 Optimizing the Support Experience 149 F5 technical support commitment 149 F5 certification 150 Self-help 151 F5 training programs and education 154 Engage F5 Support 154 Legal Notices 165 Trademarks 165 Patents 165 Notice 165 Publication Date 166 iv

5 CONTENTS Copyright 166 Change List 167 v

6 FIGURES Figures Figure 0.1: F5 documentation coverage 2 Figure 1.1: Client interaction with BIG-IP APM 7 Figure 2.1: BIG-IP APM license consumption overview 12 Figure 3.1: Pre-authentication and SSO 16 Figure 3.2: BIG-IP APM client identification. 17 Figure 3.3: BIG-IP APM as an authentication gateway 18 Figure 3.4: Establishing a VPN tunnel 23 Figure 3.5: Per-App VPN tunnel packet flow 25 Figure 3.6: Application tunnel packet flow 27 Figure 3.7: Web Access Management packet flow 29 Figure 3.8: Portal Access packet flow 31 Figure 3.9: BIG-IP APM as authentication proxy for SSO on Citrix Web Interface 34 Figure 3.10 BIG-IP APM integration with Citrix XML broker 35 Figure 3.11 Exchange proxy packet flow 39 Figure 3.12 Sample BIG-IP full webtop 41 Figure 3.13: Step-up authentication in use between the client and server 44 Figure 3.14: BIG-IP APM as a forward proxy 46 Figure 3.15: BIG-IP APM as an OAuth authorization server 48 Figure 5.1: Full webtop with two resources 60 Figure 5.3: Default Microsoft RD Web from Terminal Server s IIS 66 vi

7 FIGURES Figure 5.4: Microsoft RD Web terminal server RemoteApp portal page 66 Figure 7.1: BIG-IP APM failover 81 Figure 7.2: Standalone VIPRION cluster with all blades online 83 Figure 7.3: Standalone VIPRION cluster with blade 2 offline. No user sessions are lost. 84 Figure 7.4: Active-standby VIPRION device group with all blades online 85 Figure 7.5: Active-standby VIPRION device group with Blade 2 on VIPRION A offline 86 Figure 8.1: Variable Assign access policy agent used to collect license usage 88 Figure 8.2: Branch rules in Variable Assign agent collect license usage information 89 Figure 8.3: Logout page error message configuration 89 Figure 8.4: Logout page example as seen by user 90 Figure 9.1: Access irules event diagram 97 Figure 9.2: Access policy Logging agent Properties tab 102 Figure 9.3: Access policy Message Box agent Properties tab 103 Figure 9.4: Sample Message Box 103 Figure 9.5: Access policy Variable Assignment agent Custom Variable 104 Figure 9.6: Access policy Variable Assignment agent Custom Expression 104 Figure 9.7: Access policy Logon Page agent Secure Custom Variable 105 Figure 9.8: Access policy SSO Credential Mapping agent Unsecure Custom Variable 105 Figure 9.9: Access policy with irule event agent 106 Figure 9.10: Access policy irule event agent 106 Figure 9.11: LDAP authentication branch rules 107 Figure 9.12: Variable Assign agent custom expression 108 vii

8 FIGURES Figure 9.13: Empty agent 109 Figure 9.14: Branch rules in an Empty agent 110 Figure 9.19: Clientless mode protocol flow 112 Figure 10.1: Access policy using Logon Page and AD Auth policy agents 117 viii

9 TABLES Tables Table 0.1 Command-line syntax 3 Table 2.1 License requirements by resource type 13 Table 3.1 Client-side and server-side authentication method support matrix 20 Table 3.2 Network access features 21 Table 5.1 RDP Deployment Methods 53 Table 9.1 sessiondump commands 100 ix

10 ABOUT THIS GUIDE LimITS of this guide About This Guide The goal of this guide is to help F5 customers keep their BIG-IP system healthy, optimized, and performing as designed. It was written by F5 engineers who assist customers with solving complex problems every day. Some of these engineers were customers before joining F5, and their unique perspective and hands-on experience serves the guides F5 customers have requested. This guide describes common information technology procedures, as well as those which are exclusive to BIG-IP systems. There may be procedures particular to your industry or business that are not identified. While F5 recommends the procedures outlined in this guide, they are intended to supplement your existing operations requirements and industry standards. F5 suggests that you read and consider the information provided to find the procedures to suit your implementation, change-management process, and business-operations requirements. Doing so can result in higher productivity and fewer unscheduled interruptions. Refer to Feedback and notifications for information on how to help improve future versions of the guide. Before using this guide To get the most out of this guide, first complete the following steps, as appropriate to your implementation: Install your F5 platform according to its requirements and recommendations. Search the AskF5 (support. f5.com) for platform guide to find the appropriate guide. Follow the general environmental guidelines in the hardware platform guide to make sure of proper placement, airflow, and cooling. Set recommended operating thresholds for your industry, accounting for predictable changes in load. For assistance contact F5 Professional Services (f5.com/support/professional-services). Familiarize yourself with F5 technology concepts and reviewed and applied appropriate recommendations from F5 BIG-IP TMOS: Operations Guide. Limits of this guide This guide does not focus on installation, setup, or configuration of your BIG-IP system or modules. There is a wealth of documentation covering these areas in AskF5 (support.f5.com) The F5 self-help community, DevCentral (devcentral.f5.com), is also a good place to find answers about initial deployment and configuration. The following figure shows where the F5 operations guides can best be applied in the product life cycle. 1

11 ABOUT THIS GUIDE ISSUE escalation Figure 0.1: F5 documentation coverage Glossary A glossary is not included in this guide. Instead, the Glossary and Terms page (f5.com/glossary) offers an up-todate and complete listing and explanation of common industry and F5-specific terms. Customization Customization may benefit your implementation. You can get help with customization from a subject matter expert, such as a professional services consultant, from F5 Consulting Services (f5.com/support/professional-services). Issue escalation Refer to Optimizing the Support Experience for issue escalation information. If you have an F5 websupport contract, you can open a support case by clicking Open a support case on AskF5 (support.f5.com) 2

12 ABOUT THIS GUIDE CommAND-LINE syntax Feedback and notifications F5 frequently updates the operations guides and new guides may be released as needed. If you would like to be notified when new or updated content is available, or if you have feedback, corrections, or suggestions to improve this guide, Configuration utility The BIG-IP Configuration utility is the name of the graphic user interface (GUI) of the BIG-IP system and its modules. It is a browser-based application you can use to install, configure, and monitor your BIG-IP system. For more information about the Configuration utility, refer to Introducing BIG-IP Systems in BIG-IP Systems: Getting Started Guide. Command-line syntax We show command line input and output in courier font. The corresponding prompt is not included. For example, the following command shows the configuration of the specified pool name: tmsh show /ltm pool my _ pool The following table explains additional special conventions used in command-line syntax: Table 0.1 Command-line syntax Character Description Identifies a user-defined variable parameter. For <> example, if the command has <your name>, type in your name but do not include the brackets. [] Indicates that syntax inside the brackets is optional.... Indicates that you can type a series of items. TMOS Shell syntax The BIG-IP system includes a utility known as the TMOS Shell (tmsh) that you can use to configure and manage the system at the command line. Using tmsh, you can configure system features and set up network elements. You can also configure the BIG-IP system to manage local and global traffic passing through the system and view statistics and system performance data. You can run tmsh and issue commands in the following ways: You can issue a single tmsh command at the BIG-IP system command line using the following syntax: tmsh [command] [module... module] [component] (options) You can open tmsh by typing tmsh at the BIG-IP system command line: (tmsh)# 3

13 ABOUT THIS GUIDE FINDING other documents Once at the tmsh prompt, you can issue the same command syntax, leaving off tmsh at the beginning. Note You can use the command line utilities directly on the BIG-IP system console, or you can run commands using a remote shell, such as the SSH client or a Telnet client. For more information about command line utilities, refer to the Traffic Management Shell (tmsh) Reference Guide. Finding other documents For information about how to locate F5 product guides, refer to AskF5 article: K : Finding product documentation on AskF5. 4

14 INTRODUCTION BIG-IP APM features Introduction BIG-IP APM features BIG-IP Access Policy Manager (APM ) is a software module of the BIG-IP hardware platform that provides users with secured connections to BIG-IP Local Traffic Manager (LTM ) virtual servers, specific web applications, or the entire corporate network. BIG-IP APM is built around several features including access profiles, access policies, the visual policy editor, and webtops. Access profile An access profile is the profile you select in a BIG-IP LTM virtual server definition to establish a secure connection to a resource, such as an application or a webtop. You can configure access profiles to provide access control and security features to a local traffic virtual server hosting web applications. An access profile contains the following: Access session settings Access policy timeout and concurrent user settings Accepted and default language settings Single sign-on (SSO) information and cookie parameter settings Customization settings The access policy for the profile Access Profile Scope (BIG-IP 12.0 and later.) For more information, refer to Creating Access Profiles and Access Policies in BIG-IP Access Policy Manager: Network Access and Customizing Access Policy Manager Features in BIG-IP Access Policy Manager: Customization. Note For information about how to locate F5 product guides, refer to K : Finding product documentation on AskF5. Access policy An access policy defines acceptable methods of connecting to an internal network. In BIG-IP APM, it is an object in which you define criteria for granting access to various servers, applications, and other resources on your network. A policy may contain the following: One start point One or more actions 5

15 INTRODUCTION BIG-IP APM features Branches Macros or macro calls One or more endings An access policy allows you to perform four basic tasks: Collect information about the client system. Use authentication to verify client security against external authentication servers. Retrieve a user s rights and attributes. Grant access to resources. Access policy types Access policies are either per-session or per-request. A per-session request access policy verifies endpoint security and authenticates a user before starting an access session. A per-request access policy verifies endpoint security and authenticates a user before allowing access to a sensitive resource after the session is established. For more information, refer to Creating an Access Policy in BIG-IP Access Policy Manager: Network Access. Visual policy editor The visual policy editor is a tool within BIG-IP APM Configuration utility for configuring access policies using visual elements. Note The elements you use to build an access policy in the visual policy editor are called by various names in F5 documentation. In this guide, they are referred to as policy agents. For example, the AD Auth policy agent or AD Auth agent. For more information on visual policy editor conventions, refer to Visual policy editor in BIG-IP Access Policy Manager: Visual policy editor. Webtop A webtop is a landing page through which resources are made available to users. There are three types of webtops you can configure: A Network Access webtop provides a landing page for an access policy branch to which you assign only a network resource. A Portal Access webtop provides a landing page for an access policy branch to which you assign only Portal Access resources. A full webtop provides an access policy ending for a branch to which you can assign Portal Access resources, application tunnels, remote desktops, and webtop links, in addition to a Network Access tunnel. 6

16 INTRODUCTION CLIENT interaction with BIG-IP APM For more information, refer to Configuring webtops in BIG-IP Access Policy Manager: Network Access. Client interaction with BIG-IP APM Understanding the basic protocol flow between a client and BIG-IP APM can help in troubleshooting deployment scenarios such as clientless mode and other programmability options. The following figure shows a simplified protocol flow for a typical browser-based client-side interaction with BIG-IP APM. Figure 1.1: Client interaction with BIG-IP APM In the previous figure: 7

17 INTRODUCTION BIG-IP APM with other BIG-IP modules 1. The client makes an initial request to a BIG-IP APM virtual server. The request may have no specific URI, in which case the URI is / or a unique URI pattern, as in shown in the figure. 2. BIG-IP APM creates an access session. The client is redirected to a «/my.policy» URI. A session cookie (pointer) for that access session is set in the redirect response. 3. Client browser returns request to /my.policy and BIG-IP APM session cookie, MRHSession. 4. Access session enters starts and BIG-IP APM begins access policy evaluation. Policy agents such as the Logon Page or Message Box may send responses to client. 5. If access policy evaluation ends at Deny, the access session is marked denied and BIG-IP APM terminates the session and responds with a customizable error page. If access policy evaluation ends at Allow, the access session is marked as allowed. 6. If the session is marked as allowed, BIG-IP APM redirects back to the original request URI. 7. Client browser returns to the URI with the session cookie. Access policy evaluation is skipped, and SSO if applied to the access policy is enabled. All following requests with this session cookie to the BIG-IP APM virtual IP skips access policy evaluation. SSO remains enabled to maintain the server-side authenticated state. Session may expire, depending on configuration of session options. BIG-IP APM with other BIG-IP modules The BIG-IP platform provides the ability to license and provision multiple software modules. Various module combinations can be utilized to meet the specific needs for the network environment. The ability to provision multiple software modules is the foundation for implementing F5 Reference Architecture solutions. BIG-IP APM is capable of working with the following BIG-IP modules: BIG-IP DNS (formerly Global Traffic Manager or GTM) BIG-IP Application Security Manager (ASM ) BIG-IP Advanced Firewall Manager (AFM ) BIG-IP Application Acceleration Manager (AAM ) Note Module combinations are limited by the amount of platform system memory. For more information about module compatibility, refer to the BIG-IP system software version s release note. BIG-IP DNS You can use BIG-IP DNS (formerly BIG-IP GTM) and BIG-IP APM together to provide high availability (HA) and secure remote access to corporate resources from anywhere in the world. BIG-IP DNS can be configured to intelligently direct traffic to the available branch office closest to users. BIG-IP APM uses one of several options to authenticate users and then creates a secure session between the users and the remote office. 8

18 INTRODUCTION BIG-IP APM with other BIG-IP modules Two topologies exist to deploy a BIG-IP DNS and BIG-IP APM solution: High availability configuration Topology-based configuration For more information, refer to Deploying BIG-IP GTM with APM for Global Remote Access. You can use BIG-IP DNS, BIG-IP LTM, and BIG-IP APM together to provide a single namespace (for example, to clients accessing VMware Horizon with View virtual desktops. BIG-IP DNS and BIG-IP LTM work together to ensure that requests are sent to a user s preferred data center, regardless of the user s current location. Additionally, BIG-IP APM validates the login information against the existing authentication and authorization mechanisms, such as Active Directory, Remote Authentication Dial-in User Service (RADIUS), HTTP, or Lightweight Directory Access Protocol (LDAP). BIG-IP ASM You can use BIG-IP ASM and BIG-IP APM together to track sessions using authentication provided by a BIG- IP APM access policy and using BIG-IP ASM session tracking. These modules when used with database security products, such as IBM InfoSphere Guardium, to increase security visibility, receive alerts about suspicious activity, and prevent attacks. For more information, refer to Tracking Application Security Sessions with APM and Overview: Integrating ASM and APM with database security products in BIG-IP Application Security Manager: Implementations. BIG-IP AFM You can use BIG-IP AFM in application delivery controller (ADC) mode, which allows traffic to virtual servers and self IPs on the system. You must explicitly specify any traffic that you want to block. BIG-IP AFM is a network firewall and applies only to the virtual server and self IPs on the system. You can also deploy BIG-IP AFM in Firewall mode, which applies a default deny policy to all self IPs and virtual servers. In this mode, to allow access to BIG-IP APM, firewall rules must be created at the virtual server level. BIG-IP AFM rules do not apply to VPN tunnel traffic from VPN clients to internal networks. F5 recommends using the BIG-IP APM built-in access control lists (ACLs). For more information, refer to Configuring Network Access Resources in BIG-IP Access Policy Manager: Network Access. BIG-IP AAM You can use BIG-IP AAM together with BIG-IP APM Portal Access to provide: Improved performance for an HTTP or HTTPS stream by offloading the compression overhead from origin web servers. Caching of patched (rewritten) Portal Access objects and their delivery directly to clients, improving web page loading time due to repeated file patching. F5 recommends that you apply an HTTP compression and a web acceleration profile to a BIG-IP APM virtual 9

19 INTRODUCTION BIG-IP APM with other BIG-IP modules server. Doing so makes sure that all content delivered to the client is compressed. The addition of a Web Accelerator profile ensures that files are not repeatedly patched over and over. 10

20 LICENSES BIG-IP APM license types Licenses BIG-IP APM session licensing is handled within the BIG-IP licensing infrastructure. For more information, refer to AskF5 article: K7752: Overview of licensing the BIG-IP system. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. BIG-IP APM license types BIG-IP APM uses two different types of licenses: Access session licenses, which are consumed when a user starts any new session. User connectivity licenses (CCUs), which are consumed when a user is assigned one or more BIG-IP APM resources with tunnel-type access. Access session licenses When a user connects to BIG-IP APM, a new session starts and an access session license is used. Once a license is used, it cannot be used again until the user session terminates. After the access session begins, it is subjected to access policy evaluation, with one of two outcomes possible: Access policy evaluation succeeds, and the access session license remains unavailable for other sessions until the current session is terminated or the user logs out. Access policy evaluation fails, the session is terminated and the access session license is released and made available for a new session. Note Applications running the LTM-APM profile type for web application access (such as Microsoft SharePoint) consume one access session license. Important Exceeding the maximum licensed session count leads to loss of service. The number of access session licenses available is determined by the platform on which BIG-IP APM is running. An additional add-on SKU is available to maximize the number of access session licenses available for the platform. This license is specific to the capabilities of the given hardware platform. The following figure shows license consumption process in BIG-IP APM user session management. 11

21 LICENSES BIG-IP APM license types Figure 2.1: BIG-IP APM license consumption overview CCU licenses BIG-IP APM consumes a CCU license when a user is assigned one or more BIG-IP APM resources which have tunnel-type access processed by passing through BIG-IP APM. No matter how many resources are assigned to the user, each session consumes only one CCU license. For example, if a user has access to a BIG-IP APM full webtop with Network Access and an application tunnel, then one CCU license is consumed per access session. If the user has access to a BIG-IP APM full webtop which 12

22 LICENSES LICENSE limits does not contain any CCU resources, then no CCU licenses are consumed. Note An access session license is always consumed for any session. An additional add-on SKU is available to maximize the number of access session licenses available for the platform and is specific to the capabilities of that platform. To see the maximum license counts for various platforms, refer to AskF5 article K : BIG-IP APM session license capacity. The following table shows which access resource types consume a CCU license in addition to an access session license. Table 2.1 License requirements by resource type Access Category Specific Access CCU Consumed? Full Network Access (L3 SSL VPN) Any Access (Edge Client, Browser, API) Yes Per App VPN Edge Client (Android, ios) Yes (One CCU Per Device in Use) Application tunnel Yes VMWare View Resource No Application Access (Port Forwarding) Microsoft Desktop Client (Java or No Plug-in) Citrix Clients Webtop Mode No Web-Based App Links on Webtop Yes Portal Access (Reverse Proxy) Citrix Portal Mode (StoreFront/Web Interface) Yes Secure Web Gateway (SWG) Any Access No Microsoft Exchange No Outlook Anywhere, ActiveSync, Web Service No Microsoft OWA (Without Rewrite Other Profile) No WebAuth No Oracle OAM No SAML Resource on Webtop No OAuth No For more information about license types, refer to AskF5 article: K13267: BIG-IP APM connectivity license. License limits To view the number of access licenses using tmsh at the command line Type the following command: tmsh show /sys license detail grep apm _ access _ sessions The command output appears similar to the following example: apm _ access _ sessions [2500] 13

23 LICENSES BIG-IP APM LITE In this example, a total of 2500 total access licenses are available for use. To view the number CCU licenses using tmsh at the command line Type the following command: tmsh show /sys license detail grep apm _ sessions The command output appears similar to the following example: apm _ sessions [250] In this example, a total of 250 total CCU licenses are available for use. For more information, refer to AskF5 article: K15032: Determining license limits of the BIG-IP APM system. If a user attempts a new connection when the session limit has been reached, two actions occur: The system logs the following error message to /var/log/apm: warning tmm1[10186]: :4: : Global concurrent access session limit reached. The system redirects the user to the login page, which displays the following error message: BIG-IP APM Lite The maximum number of concurrent user sessions has been reached. No new user sessions can start at this time. All BIG-IP systems include a free perpetual license for the BIG-IP APM Lite module. This module includes the same features as a fully licensed BIG-IP APM module, with the following limitations: Licenses for access sessions and CCU sessions are limited to 10 each. Hardware compression is disabled. Software compression is limited to 50Mbps. Oracle Access Manager (OAM) integration is not provided. 14

24 USE CASES AUTHENTICATION and SINGLE SIGN-On Use Cases BIG-IP APM manages secure remote access for network applications and clients. You can configure and deploy it to provide a variety of access management functions. The following sections describe several common BIG-IP APM use case options, including information regarding features, required components, and implementation. Authentication and Single Sign-On BIG-IP APM serves as an authentication gateway or proxy. As an authentication proxy, BIG-IP APM provides separate client-side and server-side authentication. Client-side authentication occurs between the client and BIG-IP APM. Server-side authentication occurs between BIG-IP APM and servers. Loose coupling between the client-side and server-side layers allows for a rich set of identity transformation services. Combined with a visual policy editor and an expansive set of access irules functionality, BIG-IP APM provides flexible and dynamic identity and access, based on a variety of contexts and conditions. For example, a client accessing Microsoft SharePoint through BIG-IP APM in a corporate environment may silently authenticate to BIG-IP APM with NT LAN Manager (NTLM) or Kerberos credentials. On leaving that environment, or on using a different non-sanctioned device, the client may be required to go through another potentially stronger authentication, such as a smart card or other client certificate, RSA SecurID, or one-time passcode. You can require additional device vetting such as file, folder, and registry checks and antivirus and firewall software validation. A BIG-IP APM Authentication and single sign-on (SSO) features access and identity security posture can automatically change depending on environmental factors, such as who or where the user is, what resource the user is accessing, or when or with what method the user is attempting to gain access. Features There are several reasons to use BIG-IP APM Authentication and SSO, including pre-authentication, dynamic access and identity control, and authentication gateway and identity transformation. Pre-authentication BIG-IP APM pre-authentication adds an additional layer of application security by dynamically authenticating and validating users before allowing access to the server resources. You can use pre-authentication for standard web access or other BIG-IP APM access use cases, including Network Access, portals, application tunnels, and virtual desktop infrastructure resources. As a pre-authentication service, BIG-IP APM can enforce stronger authentication processes than the server services can natively support. For example, you can deploy BIG-IP APM can to require client certificate or other two-factor token methods in front of applications that only support Kerberos. Or, you can add an RSA SecurID passcode as a second factor of authentication to applications that only support username/password authentication. The following figure shows the interaction between a client, BIG-IP APM, and the SSO functions, including how user credentials are exchanged with internally hosted applications using SSO. 15

25 USE CASES AUTHENTICATION and SINGLE SIGN-On Figure 3.1: Pre-authentication and SSO Dynamic access and identity control BIG-IP APM can change both the protocol by which a client asserts identity information and the ways in which that identity information is validated, based on environmental factors. In the SharePoint example described in Authentication and Single Sign-On, internal corporate users can present Kerberos or NT LAN Manager (NTLM) credentials to BIG-IP APM for access. You can configure the access policy so that the policy enforces different or additional authentication methods, such as client certificate or one-time passcode, when a user leaves the corporate environment. The policypk can also insert additional endpoint posture 16

26 USE CASES AUTHENTICATION and SINGLE SIGN-On checking like antivirus and system service checks. The following figure shows how BIG-IP APM validates client identity based on environmental factors and provides a stronger authentication layer. Figure 3.2: BIG-IP APM client identification. Authentication gateway and identity transformation Data centers often face the challenge of offering multiple applications with different authentication requirements. You can deploy BIG-IP APM to consolidate and enforce all client-side authentication into a single process. BIG-IP APM can also perform identity transformation on the server side to authenticate to server services using the best-supported methods. This can reduce operational costs since applications remain in the most-supported and documented configurations. Common examples of identity transformation are client-side public key infrastructure (PKI) certificate to server-side Kerberos and client-side HTTP form to server-side HTTP Basic. The following figure shows BIG-IP APM acting as an authentication gateway. Information received during preauthentication is transformed to authenticate to multiple enterprise applications with different requirements. 17

27 USE CASES AUTHENTICATION and SINGLE SIGN-On Figure 3.3: BIG-IP APM as an authentication gateway Components BIG-IP APM Authentication and SSO components include separate client-side and server-side functions. Client-side authentication involves the client (typically a user employing a browser) accessing a BIG-APM virtual server and presenting identity. This is called authentication, authorization, and accounting (AAA). Server-side authentication involves BIG-IP APM providing authentication to a server resource. This is called SSO. Client-side authentication BIG-IP APM supports industry standard authentication methods, including: NTLM Kerberos Security Assertion Markup Language (SAML) Client certificate RSA SecurID One-time passcode HTTP Basic HTTP Form Once access credentials are submitted, BIG-IP APM validates the listed methods with industry-standard mechanisms, including: 18

28 USE CASES AUTHENTICATION and SINGLE SIGN-On Active Directory authentication and query LDAP and LDAPS authentication and query Remote Authentication Dial-in User Service (RADIUS) Terminal Access Controller Access Control System (TACACS) Online Certificate Status Protocol (OCSP) and Certificate Revocation List Distribution Point (CRLDP) (for client certificates) Local User Database authentication BIG-IP APM can further vet client access by inspecting the client device itself, using methods including (but not limited to): File system checks System service checks Registry checks Browser plug-in checks Antivirus software checks Firewall software checks Hard-disk encryption software checks Patch management software checks Peer-to-peer software checks Hardware certificate checks OS and client device ID checks Authentication, validation, and vetting mechanisms are defined within the access policy. For more information on creating BIG-IP APM client-side authentication functionality, refer to BIG-IP Access Policy Manager: Authentication and Single Sign-On. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. Server-side authentication Client side and server side are loosely coupled in the authentication proxy. Because of this, BIG-IP APM can transform client-side identity values of one type can into server-side identity values of another type. You configure SSO within an SSO profile, which is applied to an access profile. The system triggers SSO at the end of successful access policy evaluation and on subsequent client-side requests. BIG-IP APM supports industry standard authentication methods, including: NTLM 19

29 USE CASES AUTHENTICATION and SINGLE SIGN-On Kerberos HTTP Basic HTTP Form Security Assertion Markup Language (SAML) Note Client-side authentication methods outnumber server-side methods. This is because BIG-IP APM does not transmit client certificate, RSA SecurID, or one-time passcodes to the server on the client s behalf. For more information on BIG-IP APM server-side authentication, refer to BIG-IP Access Policy Manager: Authentication and Single Sign-On. Compatibility A successful BIG-IP APM client-side authentication produces a set of session variable values as output that server-side authentication can consume and use as input. However, some server-side methods have requirements that the client side cannot fulfill. For example, server-side NTLM is a challenge-response mechanism. It requires knowledge of the user s password. A client-side Kerberos authentication does not provide access to the user s password, so these two methods are incompatible. The following table shows the compatibility between various client-side and server-side authentication methods. Table 3.1 Client-side and server-side authentication method support matrix Client-side Authentication Methods Server-side Authentication Methods HTTP Form HTTP Basic NTLM Kerberos HTTP Form Yes Yes Yes Yes HTTP Basic Yes Yes Yes Yes NTLM No No No Yes Kerberos No No No Yes Certificate No No No Yes SAML 1 Yes Yes Yes Yes RSA SecurID No 2 No 2 No 2 No 2 One-Time Passcode No 2 No 2 No 2 No 2 1. BIG-IP APM can function as a SAML identity provider (IdP) and a service provider (SP). As an SP, the client generally authenticates at the IdP. Therefore, the SP does not have access to user s credentials. However, it is possible for the IdP to encrypt and transmit those validated credentials in the standard SAML assertion or in a separate artifact communication. In this way a BIG-IP APM SAML SP could perform server-side authentication functions requiring a password. 2. RSA SecurID and one-time passcode are rarely used alone. They are usually combined with username and password authentication to add an additional authentication factor. If these methods are combined with a username and password prompt, then they collectively support server-side authentication methods that 20

30 USE CASES NETwORk ACCESS require a password. However, if these methods are used in a capacity to replace a user password, they generally cannot support server-side authentication methods requiring a password. Network Access BIG-IP APM Network Access feature supports full OSI layer 2 (L2) remote access VPN connectivity to internal network resources. Network access resources assigned to an access policy provide a wide array of security and optimization capabilities for both desktop and mobile clients. With BIG-IP APM Network Access, once connected, the internal network is available to the client. Other controls and features are available to support variations. Features You can configure the Network Access features listed in the following table for each Network Access resource you create. Table 3.2 Network access features Feature Compression Forward error correction SNAT selection (from policy or NA resource) Routing domains Bandwidth controller policy ACLs Application launch Reconnect to domain Drive mapping On-demand VPN Description Enabled in Network Access resource. Parameters of GZIP compression are configured in the connectivity profile. Compression typically provides little benefit, as most network traffic is pre-compressed. Licensable module included with BIG-IP Application Acceleration Manager. Forward error correction (FEC) provides reliability for Datagram Transport Layer Security (DTLS) tunnels at the cost of higher bandwidth usage. It saves bandwidth by enabling compression on DTLS traffic and reducing or eliminating TCP retransmissions. Network access uses flexible mechanisms to choose source-nat addresses based on access policy parameters. Generally SNAT is disabled to support VoIP and improve reliability of SMB similar protocols. Provide the capability to segment network traffic and define separate routing paths for different network objects and applications. Allows for static or dynamic bandwidth control per user. Refer to ACLs. Allows for a client application start immediately after a Network Access connection is established. For example, starting a web browser to a company intranet portal. For more information, refer to AskF5 article: K11464: Launching applications in Network Access connections using dynamic parameters. Synchronizes Active Directory policies and executes domain logon scripts in domainjoined Windows client PCs. It also enables a second option to execute logoff scripts, if desired. Allows for network drives to map after establishing the Network Access connection. Allows the mobile BIG-IP Edge Client to start automatically, given specified URLs. This is typically used with transparent client certificate authentication to allow seamless access. 21

31 USE CASES NETwORk ACCESS Feature Description Can be transparently applied to VPN user traffic. When using SSO, ACLs are not processed for the resources defined for the internal virtual server(s). SSO Proxy support For more information, refer to AskF5 article: K11312: Creating network access with single-sign on capabilities If clients use internal proxy for web access, BIG-IP APM allows for flexible options to apply a static proxy server or PAC configurations to VPN clients that connect. If clients use proxy to access BIG-IP APM to create a tunnel, the VPN client supports the condition that the VPN tunnel is created through a proxy server Important In application start, if more than one operating system is used, pay close attention when specifying application paths and start parameters. Split tunneling and DNS BIG-IP APM supports split tunnels as well as full tunnels. The Network Access client, including BIG-IP Edge Client, changes the client s routing table based on the Network Access resource configuration. You can use multiple routes, or a default route, to direct the client s traffic through the tunnel. For more information refer to Network Security. The Windows Network Access client, including BIG-IP Edge Client, has a flexible proxy DNS service. The DNS service can forward client DNS requests to BIG-IP APM for processing. BIG-IP APM can then answer the requests directly or forward them to the local DNS server. Components You must create the following BIG-IP components for this implementation: A connectivity profile A Network Access lease pool to assign to connecting clients A Network Access resource to configure Network Access properties A full webtop or Network Access webtop to present the Network Access resource to the client An access policy that assigns the webtop and Network Access resource In addition, a VPN web client must be (automatically) downloaded into the user s browser, or you must push out the stand-alone BIG-IP Edge Client to the user. For more information about which features are available on which operating systems, refer to BIG-IP APM Client Compatibility Matrix. Implementation There are two types of transport uses for BIG-IP APM Network Access: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). TLS uses TCP as the transport. DTLS uses UDP. DTLS has lower overhead than TCP and may be better suited for VoIP and VDI solutions. Both TLS and DTLS Network Access work 22

32 USE CASES NETwORk ACCESS in either an IPv4-only environment or a mixed IPv4 and IPv6 environment. BIG-IP APM also supports Network Access optimized applications. Optimized applications are configured in the Network Access feature and allow layer 4 (L4) tunnels to internal networks using the same isession transport method as application tunnels. Application tunnels and Network Access optimized applications support various compression codecs as follows: Client to server codecs are configured in the connectivity profile. Server to client codecs are configured in the Network Access feature, as are the internal TCP network/ subnet endpoints. Three compression methods are supported: deflate, LZO, and bzip2. Adaptive compression automatically selects the compression type based on network and traffic characteristics. The following figure shows an overview of client-server interaction during L2 VPN tunnel establishment. Figure 3.4: Establishing a VPN tunnel 23

33 USE CASES Per-APPLICATION VPN In the previous figure: 1. A user browses to a virtual server URL from a BIG-IP APM client and initiates an access policy evaluation sequence. 2. After successful access policy evaluation, the system creates a valid session and assigns the Network Access resources. 3. The client requests a VPN configuration using an HTTP GET method. 4. The client establishes an L2 tunnel with BIG-IP APM. 5. All of the traffic destined for BIG-IP APM is encapsulated in L2 frames. Per-Application VPN The Per-Application (Per-App) VPN feature makes sure that specific mobile applications and their data remain secure and protected, and only data relevant from the application is sent to the internal network. With the Per-App VPN capabilities of the BIG-IP APM, combined with a mobile device management (MDM) solution, enterprise organizations can be sure only authenticated and authorized mobile users are able to access and send data to the organization from approved mobile applications or mobile containers. Features Per-App VPN deploys using an existing MDM solution. Depending on the authentication in use, Per-App VPN can offer a seamless or relatively simple way to access internal resources. You can apply per-user bandwidth policies and ACLs to make sure that users comply with network use policies. Detailed user activity auditing is also possible with ACL logging or solutions based on irules. You can configure the access policy to act on various mobile properties, such as device ID, compliance status, and more, to provide granular control on Per-App VPN tunnel connections. Components You must create the following BIG-IP components for this implementation: A connectivity profile An application tunnel profile (Java and per-app VPN) An MDM-enrolled mobile device An MDM-deployed application The BIG-IP Edge Client for L3 and Per-App VPN Note Per-App VPN functionality is supported on ios and Android Edge Clients version and later. Implementation Per-App VPN tunnels use an F5 proprietary version of the SOCKS protocol. The following figure shows a Per-App VPN tunnel packet flow. 24

34 USE CASES APPLICATION tunnel Figure 3.5: Per-App VPN tunnel packet flow For more information on Per-App VPN, refer to AirWatch/F5 Solution for Enterprise Mobility. Application tunnel An application tunnel provides secure, application-level TCP/IP connections from the client to the internal network. Features You can use application tunnels to provide access for users with limited privileges who need to access internal applications. Application tunnels do not require administrative privileges to install client modules. Application tunnels have lower overhead in connection establishment, lower client module complexities, and faster application connections when compared to Network Access. Unlike Network Access, application tunnels allow simultaneous creation of multiple connections from a client, even to different BIG-IP APM endpoints. Application tunnels use isession, an F5 proprietary protocol for transport. Application tunnels can be started using native Windows binary components or with a browser-based Java applet on Windows, Mac and Linux platforms. 25

35 USE CASES APPLICATION tunnel Per-user session-level bandwidth policy and ACLs can be applied to application tunnels. Application tunnel optimization Optimization is available for application tunnels. Available compression codecs settings for client-to-server connections can be configured on an application tunnel resource. The server compares the available compression types with the available compression types on the client, then chooses the most effective mutual compression setting. The compression settings for the client can be configured in the connectivity profile and the compression settings for the server can be configured in the application tunnel resource. Note F5 recommends configuring application parameters in an application tunnel resource item with %host% and %port% parameters. Due to local loopback port conflicts with other applications, BIG-IP APM may create app tunnels on different local ports and update %port% with the correct port information. The %host% parameter translates to and is needed in case the user doesn t have sufficient privileges to update the static host file. Components You must create the following BIG-IP components for this implementation: A connectivity profile A full webtop An application tunnel resource An access policy that assigns a webtop and an application tunnel resource The following figure shows client-server communication sequence when the system establishes the application tunnel. After successful access policy execution, client sends HTTP GET/isession?sessionid=<sid> requests to setup isession with BIG-IP APM. The client then establishes an isession connection with BIG-IP APM, and all subsequent communication is encapsulated in F5 proprietary frames. 26

36 USE CASES NETwORk ACCESS Figure 3.6: Application tunnel packet flow For more information regarding application tunnels, refer to Introduction to isessions on DevCentral and Configuring Application tunnel Access in BIG-IP Access Policy Manager: Application Access Guide. Note A DevCentral login is required to view DevCentral content. 27

37 USE CASES web ACCESS ManagemENT Web Access Management The BIG-IP LTM module manages and optimizes traffic for network applications and clients. It can automatically load balance application traffic among multiple internal servers. You can offload the servers SSL encryption to the BIG-IP system. You can integrate BIG-IP APM with BIG-IP LTM to provide authenticated access to web applications through a web browser without the use of tunnels or specific resources. You can protect web applications that don t provide native user login and account validation by using the Web Access Management feature. In some cases this can reduce the expense of application development and deployment. Features Provides a wide range of authentication mechanisms allowing flexible deployment and secure access to the server resources Provides custom user auditing using built-in or irules-based functionality Note Web Access Management is also called LTM+APM and LTM-APM in F5 documentation. Components You must create the following BIG-IP components for this implementation: An access policy configured with an authentication agent A pool of resources An LTM virtual server Implementation The following figure shows communication between the client and server when the client attempts to access protected web application resources. 28

38 USE CASES NETwORk ACCESS Figure 3.7: Web Access Management packet flow 29

39 USE CASES PORTAL ACCESS Portal Access Portal Access is the HTTP reverse proxy feature for BIG-APM. Portal Access allows for any number of internal hosts to be accessed remotely. BIG-IP APM implements a rewrite process to retrieve content on the user s behalf. The system rewrites web content including HTML, Java, JavaScript, CSS, and Flash so that the client s web browser only retrieves content from the enterprise web application using the BIG-IP APM virtual server. Features BIG-IP APM has two primary access modes by which it can provide clientless access to internal web resources: Portal Access and Web Access Management (also called LTM-APM). Web Access Management does not rewrite the page content, and if links or other functionality reside on a different internal host, additional BIG-IP APM-protected virtual servers must be configured to support each. Additionally, a BIG-IP APM session cookie may be shared between any number of other host names in the same domain. Portal Access rewrites page content. HTML, Java, JavaScript, CSS, Flash, and other page functionality are directed through a virtual server protected by BIG-IP APM. Therefore, it does not require the additional virtual servers. Important Rewriting complex JavaScript content may cause web page functions to malfunction. Allow for extra testing time if using Portal Access.. Components You must create the following BIG-IP components for this implementation: A rewrite profile A server SSL profile, when using internal pages protected by HTTPS A Portal Access webtop or full webtop A connectivity profile An access policy that assigns a webtop and portal resource Implementation The figure below shows the packet flow for a user request of a web page served by Portal Access. 30

40 USE CASES PORTAL ACCESS Figure 3.8: Portal Access packet flow In the previous figure: 1. User browses to a virtual server URL and initiates an access policy execution sequence. 2. After successful access policy execution, a valid session is created and portal access resources are assigned. 3. Clients access a special URL in the following format: encoded scheme,host,port>$$/path. The URL typically comes from a Portal Access webtop or full webtop link, but it can also come from an irule 31

41 USE CASES NETwORk ACCESS or from other sources. 4. BIG-IP APM validates the session, retrieves the content through the main BIG-IP APM virtual server, rewrites the content, and then returns the rewritten response. Delivery methods for web applications Most methods of web application delivery are supported with rewrite. However, web applications that contain JavaScript errors or which rely on XML stylesheets are not supported. Reverse proxy technology is not formally standardized and new features in JavaScript libraries develop rapidly. Therefore, compatibility problems do occur in a small number of web applications. F5 continually works to improve Portal Access and encourages users to report issues to F5 support. For more information on troubleshooting, refer to Troubleshooting. For more information on communicating with F5 technical support, refer to Optimizing the Support Experience. Security considerations There are several important security considerations regarding Portal Access: Cookie proxy ensures that cookies are not stored on the client browser. Java rewriting allows Java applets to access URLs and TCP sockets through BIG-IP APM. If a rewritten page includes JavaScript that interacts with that page, in most cases the JavaScript requires rewriting for proper functioning. Selective rewrite is designed to work with standalone web applications across different servers, not different servers hosting parts of the same application. ACLs are allowed. Each Portal Access resource item assigned to a user is considered to be an Allow ACL. Configure ACLs to allow access only to required resources. F5 recommends defining ACLs as narrowly as possible. Portal Access Allow resource items follow the same ACL priority system as other assigned ACLs. If a default deny stance is required, an ACL with a Deny All entry should be configured. For more information, refer to ACLs. Split tunnel allows selective rewriting of the target hosts. Links within rewritten pages that are included in the bypass list of the rewrite profile is not rewritten. They are accessed directly. For example, on a page with an Internet video link in an iframe, the video can bypass rewrite and the remainder of the page is rewritten. For security considerations, you should not use applications outside of your control using rewrite. Disable this option only for testing or troubleshooting. 32

42 USE CASES CITRIx integration Citrix integration When integrated with Citrix, BIG-IP APM performs authentication to control access to Citrix-published applications and remote desktops. SmartAccess filters can also be used. BIG-IP APM supports the following types of integration with Citrix: Integration with Web Interface sites. BIG-IP APM load balances and authenticates access to Web Interface sites, providing SmartAccess conditions based on endpoint inspection of clients. Web Interface sites communicate with XML Brokers, render the user interface, and display the applications to the client. Integration with XML brokers. BIG-IP APM does not need a Web Interface site in this type of integration. BIG-IP APM load-balances and authenticates access to XML Brokers, providing SmartAccess conditions based on endpoint inspection of clients. BIG-IP APM communicates with XML brokers, renders the user interface, and displays the applications to the client. Features BIG-IP APM Citrix integration can simplifies a Citrix environment by replacing some of its core services, including the following: Citrix Web Interface server. In the absence of the Web Interface, BIG-IP APM can communicate with the Citrix XML Broker directly and display the user s published applications along with other non-citrix resources. Citrix Access Gateway and Netscaler. BIG-IP APM provides a single secure entry point for both web and ICA communications and fully supports the Citrix gateway protocol functionality. Citrix Secure Ticketing Authority service. BIG-IP APM secure session token provides comparable functionality to Citrix s STA service. Components The different components involved in the BIG-IP APM Citrix integration depend on the mode deployed and which Citrix services are being replaced. Integration with web interface sites The following figure shows BIG-IP APM deployed as an authentication proxy for SSO on Citrix Web Interface. BIG-IP APM authenticates the client and then performs server-side SSO to the Web Interface. 33

43 USE CASES CITRIx integration Figure 3.9: BIG-IP APM as authentication proxy for SSO on Citrix Web Interface You must create the following BIG-IP components for this implementation: An access policy An SSO profile or a VDI profile applied to a virtual server For more information on configuring the BIG-IP APM integration with Citrix Web Interface, refer to Integrating BIG-IP APM with a Citrix Web Interface Site in BIG-IP Access Policy Manager: Third-Party Integration Implementations. Integration with XML Brokers The following figure shows BIG-IP APM integration with Citrix XML broker. BIG-IP APM communicates directly with the Citrix XML Broker and displays the user s published applications and remote desktops on a common BIG- IP APM webtop. 34

44 USE CASES NETwORk ACCESS Figure 3.10 BIG-IP APM integration with Citrix XML broker You must create the following BIG-IP components for this implementation: An access policy A webtop A Citrix Remote Desktop resource A connectivity profile For more information on configuring the BIG-IP APM integration with XML Brokers, refer to Integrating BIG-IP APM with Citrix XML Brokers with SmartAccess support in BIG-IP Access Policy Manager: Third-Party Integration Implementations. Using an iapp An F5-supported iapp is available to help simplify BIG-IP APM Citrix integration by configuring the required settings for this deployment. The iapp can be found in the DevCentral iapp CodeShare. Note A DevCentral login is required to view this content. 35

45 USE CASES VMwARE View support VMware View support When integrated with VMware View, BIG-IP APM performs authentication to control access to published View remote desktops and optionally simplifies the View environment by replacing the VMware Security Server. The BIG-IP system provides the following VMware View support: Authenticates standalone VMwareView clients Performs authentication and load balance VMware View connection servers Supports the PC-over-IP (PCoIP) display protocol for the virtual desktop Allows a View client to make connections to support different types of traffic between it and a View connection server Supports View client connections with two virtual servers one TCP port 443 and one UDP port 4172 which share the same destination IP address Presents VMware View desktop on a webtop Integrates with View connection servers to present View desktop resources on a BIG-IP APM dynamic webtop Authenticates to a View connection server and renders the View desktop resources Load balances the View connection servers for high availability Supports the necessary connections with two virtual servers that share the same destination IP address Features BIG-IP APM VMware View integration can enhance a View environment in the following ways: Replaces the View security server service. BIG-IP APM functions as a native PCoIP proxy that provides a single secure entry point into the View environment. Allows webtop integration. BIG-IP APM renders VMware View remote desktop resources within a common webtop that can include other non-view resources. Allows layered security. BIG-IP APM can enhance the PCoIP communications with a layer of DTLS (TLS for UDP). Employs single namespace and user persistence. By adding BIG-IP DNS, BIG-IP APM can provide a single common namespace for all View pods. By querying a user directory, BIG-IP APM can persist a user to a selected data center. Components You must create the following BIG-IP components for this implementation: A VMware View remote desktop resource A full webtop 36

46 USE CASES ExCHANGE proxy An access policy A connectivity profile For more information on configuring authenticated standalone View client access, refer to Authenticating Standalone View Clients with APM in BIG-IP Access Policy Manager: Third-Party Integration Implementations. For more information on configuring webtop presentation of View remote desktop resources, refer to Presenting a View Desktop on an APM Webtop in BIG-IP Access Policy Manager: Third-Party Integration Implementations. iapp deployment For iapp deployment options that are supported by F5, refer to VMware applications at DevCentral iapp CodeShare. The listed iapp configures all of the required settings for both deployment options discussed in this section. Note A DevCentral login is required to view this content. Exchange proxy Exchange proxy is the F5 BIG-IP APM solution to provide secure remote access for all Microsoft Exchange services. These include: ActiveSync Autodiscover Exchange Web Services Offline Address Book Outlook Anywhere Outlook Web Access Features Exchange proxy provides NTLM authentication functionality for Microsoft Exchange clients, such as Microsoft Outlook, ios Mail, and Android . The solution is provided in such a way that it can be used simultaneously with multiple client-side authentication types (HTTP Basic, HTTP NTLM, and more) and authentication for mobile devices, depending on capability and protocol used. The solution identifies the remote clients and forces them to successfully authenticate before forwarding requests to the Exchange Client Access Server (CAS) service. This process provides enhanced security and auditing capability. If configured, the Exchange proxy can also provide SSO functionality for Exchange services. 37

47 USE CASES ExCHANGE proxy Components You must create the following BIG-IP components for this implementation: An NTLM machine account An NTLM authentication configuration An Exchange profile A Kerberos SSO profile Support for HTTP Basic for Autodiscover/ActiveSync An access profile with an Exchange profile assigned Implementation The following figure shows the packet flow between BIG-IP APM and the client, BIG-IP APM and the Active Directory Server, and BIG-IP APM and the Exchange CAS service. 38

48 USE CASES NETwORk ACCESS Figure 3.11 Exchange proxy packet flow For more information, refer to HTTP Basic Authentication for Microsoft Exchange Clients in BIG-IP APM Authentication Configuration Guide and Exchange Deployment Guide. 39

49 USE CASES webtop Webtop A webtop is a BIG-IP APM customizable landing page. At the end of successful access policy execution and final client POST to complete the access policy, the client can be redirected to a BIG-IP APM webtop. Webtop types BIG-IP APM supports three types of webtop: Network Access. Contains JavaScript and browser plug-ins to start Network Access on supported browsers or the BIG-IP Edge Client. Portal Access. Contains a 302 redirect to the Portal Access encoded URL. Full webtop. Contains a complex set of JavaScript, XML, and HTML to present a menu to users. Assigned resources are presented to the user as icons. A full webtop also allows the starting of Network Access from a browser and the BIG-IP Edge Client. Note If no webtop is assigned during access policy execution, the session is in Web Access Management/ LTM-APM mode. Features The full webtop can replace intranet or extranet portal pages, offering users a centralized place to start assigned applications. Network Access and Portal Access webtops automatically place users into a specific application assigned during access policy execution. BIG-IP APM provides a basic customization framework allowing administrators to alter images, color, and layout settings. The advanced customization framework allows web developers to completely replace all BIG-IP APM-delivered web content, including webtops, logon pages, and error pages. Implementation In BIG-IP 12.0 and later, Webtop Sections can be assigned to user during Access Policy Execution. Webtop sections can contain up to 300 ordered references to APM resources and are available only with a full webtop. 40

50 USE CASES ACLs Figure 3.12 Sample BIG-IP full webtop ACLs BIG-IP APM uses ACLs to restrict user access to specified internal hosts, ports and/or URIs. For an ACL to have an effect on traffic, it must be assigned to a user session. ACLs are applied to all access methods by default. An ACL consists of a list of access control entries (ACEs). These entries can work on L4, L7, or both. In addition to source (ip:port), destination (ip:port), and Scheme + URI (for L7), each ACL and its entries has a unique acl-order field that determines its priority. Important If no webtop is assigned during access policy execution, the session is in Web Access Management/LTM-APM mode. During access policy execution, BIG-APM assigns a list of ACLs to a user session. BIG-IP APM tests ACLs and ACEs in order, based on their priority in the respective list. To make sure of compliance with network use policies, the order must be correct. If there are no ACLs assigned to a session by the access policy, the default behavior for the session traffic is Allow. If a default deny stance is required, an ACL with a Deny All entry should be configured. This ACL should be assigned to the user session at the end of the ACL entry list (that is, its order field value should be highest number). BIG-IP APM rejects any connection not matched by a previous entry. ACLs can be configured to create log entries when they are matched. These log entries appear in the /var/log/ pktfilter log file. You can view them in the Configuration utility by navigating to System >> Logs : Packet Filter. When BIG-IP APM applies an ACL is applied to an access policy, the policy dynamically creates an internal layered virtual server that the system uses to apply the ACL. However, if the BIG-IP APM virtual server targets a layered virtual server, such as an SSO layered virtual server, traffic bypasses the dynamically-created internal layered virtual server and the ACL is not applied. For more information, refer to AskF5 article K14219: An L4 ACL has no effect when a layered virtual server is used. 41

51 USE CASES STEP-UP authentication Dynamic ACLs A dynamic ACL is an ACL created on and stored in an LDAP, RADIUS, or Active Directory server. A dynamic ACL action dynamically creates ACLs based on attributes from the AAA server. Because a dynamic ACL is associated with a user directory, you can use it to assign ACLs specifically per the user session. BIG-IP APM supports dynamic ACLs in an F5 ACL format, and in a subset of the Cisco ACL format. When using dynamic ACLs, make sure that the dynamic ACL appears after authentication in an access policy since its actions are determined by attributes received from an authentication server. If it s configured in a Cisco format, make sure the dynamic ACL contains the prefix ip:inacl#. For more information, refer to Configuring Dynamic ACLs in BIG-IP Access Policy Manager: Implementations. Step-up authentication Step-up authentication allows a per-request policy to authenticate a user at any time during a BIG-IP APM session. Per-request policy subroutine allows you to create time-limited subsessions to allow user access to areas of an application based on a different gating criteria. Features You can use step-up authentication to limit access to parts of a web application that manage more sensitive data. You can create policies that require stronger authentication within an already authenticated BIG-IP APM session to allow access to sensitive areas of the web application. You can use step-up authentication with Portal Access or Web Application Management (LTM+APM mode). BIG-IP APM supports the following authentication types for step-up authentication: Multi-factor authentication through Radius authentication Certificate-based authentication Password-based authentication Components You must create the following BIG-IP components for this implementation: An access policy configured with an authentication agent A per-request policy with configured subroutine Defined gating criteria for the subroutine A pool of resources An LTM virtual server 42

52 USE CASES STEP-UP authentication Implementation The following figure shows communication between the client and server when the client attempts to access protected web application resources with a per-request policy deploying implementing step-up authentication. 43

53 USE CASES STEP-UP authentication Figure 3.13: Step-up authentication in use between the client and server 44

54 USE CASES FORward proxy Forward proxy You can use BIG-IP APM 13.0 and later as a forward proxy to enforce access controls and implement a compliance policy for Internet access. The system can evaluate outbound traffic against a URL categorization database and scan both request and response data for threats and violations against corporate Internet policies. Features BIG-IP APM supports filtering forward proxy and proxy chaining based on user-defined URL categories. By adding a Secure Web Gateway (SWG) subscription, a URL database with predefined categories and an advanced persistent threat scanning solution provide the ability to do the following: Apply URL filtering policies to outbound web traffic Identify and authenticate users Identify and block malicious content Apply web application controls for application types, such as social networking and online chat Components You must create the following BIG-IP components for this implementation: An access policy configured with an authentication agent An explicit type of HTTP profile A DNS Resolver Profile A Client and ServerSSL profile (for SSL Interception) A per-request policy An LTM virtual server Implementation The following figure shows communication between the client and resource server when the client attempts to access web application resources using the BIG-IP system with a per-request policy implementing URL filtering and policies: 45

55 USE CASES OAUTH authorization Figure 3.14: BIG-IP APM as a forward proxy OAuth authorization BIG-IP APM 13.0 and later supports OAuth 2.0, an authorization framework that enables applications to obtain limited access to user accounts such as Facebook, Google, Salesforce, or an Enterprise Authorization Server such as BIG-IP APM. 46

56 USE CASES OAUTH authorization Features BIG-IP APM can function as an OAuth Authorization Server or an OAuth Client and Resource Server depending on the implementation use case. When functioning as an OAuth authorization server, BIG-IP APM can grant authorization codes, access tokens, and refresh tokens, and the system can perform token introspection. When BIG-IP APM functions as an OAuth resource server, users can log in using external OAuth accounts to gain access to the resources that the system protects. External OAuth accounts can be social accounts, such as Facebook and Google, or enterprise accounts, such as F5 (APM) and Ping Identity. Components You must create the following BIG-IP components for this implementation: One or more defined OAuth Scopes An OAuth client application An OAuth profile An access policy configured with an authentication and OAuth authorization agents A per-request policy An LTM virtual server Implementation The following figure shows communication between the client and resource server when the client attempts to authorize and OAuth client application web application configured to authorize itself with a BIG-IP APM OAuth authorization server. 47

57 USE CASES OAUTH authorization Figure 3.15: BIG-IP APM as an OAuth authorization server 48

58 BIG-IP EDGE CLIENT CLIENT TyPES BIG-IP Edge Client BIG-IP APM provides secure remote access to system resources using a number of clients, among which you can select depending on your deployment and user requirements. For more information, refer to the following documents: BIG-IP APM Client Compatibility Matrix for your version BIG-IP Edge Client Operations Guide AskF5 article: K15326: Browser plugin support for BIG-IP APM features and browser remediation options Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. Client Types There are several BIG-IP APM clients that you can use with BIG-IP APM. BIG-IP Edge client BIG-IP Edge Client is a native, platform-specific application for desktop operating systems which provides Network Access and endpoint inspection. It can also start third-party applications that you configure in an access policy on BIG-IP APM. Note BIG-IP Edge Client cannot provide Portal Access. Mobile clients F5 supports BIG-IP Edge Client and BIG-IP Edge Portal on mobile operating systems such as Apple ios and Android. You can download these applications from their respective vendor stores. Windows Phones 8.1 and later have BIG-IP Edge Client built-in (called Edge Client). With BIG-IP Edge Client, users can connect to BIG-IP APM to provide layer 3 (L3) Network Access to protected enterprise network resources. BIG-IP Edge Portal provides secure remote access to protected enterprise web applications. You can use it to automatically authenticate by bookmarking frequently visited web applications. BIG-IP Edge Portal also provides access to web applications using the BIG-IP APM content rewrite proxy. For more information, refer to Configuration Notes: Inbox F5 VPN Client for Microsoft Windows 8.1 and F5 Access and BIG-IP Edge Apps. BIG-IP Edge command line interface clients BIG-IP Edge command line interface (CLI) clients do not use a graphic user interface (GUI). F5 currently supports CLI clients for desktop operating systems to provide Network Access only. They provide basic multi-factor authentication with client certificates and username and password. 49

59 BIG-IP EDGE CLIENT VPN client types CLI clients run in legacy-logon mode and cannot render any HTML content. Therefore, you cannot use certain access policy agents requiring client-side interaction, such as message boxes and endpoint inspection, with the CLI clients. For more information, refer to BIG-IP Edge Command line Client for Linux in BIG-IP Access Policy Manager: Edge Client and Application Configuration. BIG-IP APM Edge Client SDK BIG-IP APM Edge Client provides an SDK which can be integrated with third-party applications. These can provide customized SSL-VPN applications capable of establishing Network Access with BIG-IP APM. F5 supports SDK only on computers running Windows. For more information, refer to BIG-IP APM Edge Client SDK. Browsers BIG-IP APM provides support for popular browsers such as Internet Explorer, Firefox, Chrome, and others. Browsers can use either Java applet or browser ActiveX controls to create application tunnels and provide Portal Access to web applications. For more information about using BIG-IP Edge Client with browsers and operating system platforms, refer to BIG-IP APM client compatibility matrix guide. VPN client types F5 offers several VPN Access applications for BIG-IP APM 13.0 and later. You can find detailed information about each deployment type on AskF5 and in the BIG-IP APM Client Compatibility Matrix. Windows 7 Edge Client App: This application wraps all available components into a package and you typically start it manually. Browser-based VPN with Internet Explorer: If you start Network Access in Internet Explorer, the ActiveX controls start the VPN connection using the same components as the BIG-IP Edge Client. Browser-based VPN with Chrome or Firefox: If you start Network Access with another browser, BIG-IP APM performs authentication in the parent browser, then starts the new scheme-based VPN application, which launches the browser-based VPN with Internet Explorer. Windows 10 (including Mobile) or Windows 8.1 F5 Access: This application is available in the Microsoft App Store and starts a VPN using the built-in Windows VPN Control Panel. In this mode, client-side endpoint checks (AV/Firewall, Machine Certificate, Windows inspector, and so on) are not available. See the BIG-IP APM Client Compatibility Matrix for current, comprehensive information. The options previously described for Windows 7 are also available for Intel Desktop Windows 10,. Mac Edge Client: Similar to the Windows 7 Edge Client App. Browser-based VPN with Safari: Similar to the Browser-based VPN with Internet Explorer. Browser-based VPN with Chrome or Firefox: Similar to Browser-based VPN with Chrome or Firefox. 50

60 BIG-IP EDGE CLIENT VPN client types ChromeOS F5 VPN Client: Available in the Google Play store, this VPN client can start and maintain a VPN connection. Endpoint inspection is not available. Because ChromeOS is only available in hardware platforms, F5 does not support a virtual editions on this client. Linux Command-line Edge Client: This client can create VPN connections from the command line. This client does not support two-factor authentication mechanisms other than client SSL certificates. Browser-based VPN: This VPN client runs as a Linux application. It operates similarly to other browserbased VPN clients and uses a custom URL scheme to start. IOS/Android Per-App VPN: A Mobile Device Manager (MDM) deploys this F5 VPN client to start applicationspecific VPN connections using the framework available on these platforms. The OS launches the application, and VPN activates when the application requests a network connection. This application requires a third-party MDM for deployment. Notes Android and IOS implementations of Per-App VPN are different. Edge VPN Client is an F5 application, available in the App Store, that can start a VPN connection. F5 supports only limited options for device posture checks. As of version 2.10, Edge VPN Client is called F5 Access. For more detailed information, see the following documents: F5 Helper Applications for Chrome, Firefox, and Edge Browsers for BIG-IP 13.0 BIG-IP Edge Client Operations Guide BIG-IP APM Client Compatibility Matrix for your version 51

61 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT ImPLEmENTATION Remote Desktop Protocol and Remote App Support BIG-IP APM Remote Desktop Protocol (RDP) provides secure access to internal Microsoft Remote Desktop Services and Microsoft RemoteApp Services. You can use a variety of deployment options to provide the preferred user experience. Features Providing access using a proxied method may be faster and less troublesome than using a full VPN connection. BIG-IP APM s flexible authentication options allow you to protect RDP resources with any type of access policy. You can use ACLs to enforce network use policies for ActiveX and Java RDP access. An RDG-RAP access policy controls native RDP access control. For more information, refer to ACLs. Components You must create the following BIG-IP components for this implementation: A connectivity profile A Remote Desktop resource with appropriate settings An RDG-RAP access policy Note An RDG-RAP access policy is required if the target server is dynamic or redirected to a different target server by a Terminal Services server with the broker role installed. Implementation Typically, you connect to Remote Desktop (RD) resources using a web browser, go through the authentication process, and then select a pre-configured Remote Desktop resource from a full webtop. You can configure the RD resource using the methods described in the following table. 52

62 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT ImPLEmENTATION Table 5.1 RDP Deployment Methods Method Remote Desktop Session Host, Client Type Native Remote Desktop Web Access, Client Type Native Remote Desktop Session Host, Client Type ActiveX Remote Desktop Session Host, Client Type Java Application Tunnel for Microsoft Terminal Services Client (MSTSC) RD Gateway Description Provides access to Remote Desktops. Targets can be dynamic or static. Provides access to RemoteApp resources published from Terminal Services. Provides access to Remote Desktops. The client uses the ActiveX control as the RDP client. Provides access to Remote Desktops. BIG-IP APM implements client as Java applet. Provides TCP/IP connections from client to network. Enables authorized remote users to connect to internal network from any device that can run Remote Desktop Connection (RDC) client Connect with* Browser All Any 13.0 All Any 13.0 Windows Internet Explorer Introduced 10.x All Any 10.x Browser, then MSTSC All Any 10.x Internet Explorer 11.6 *Note For the Connect with field in the previous table, F5 recommends that you refer to the Client Compatibility Matrix for your BIG-IP version. For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. Using RDP Gateway protocol Microsoft offers a proxy mechanism with the RDP Gateway (RDG-HTTP) protocol. The RDP Gateway protocol is supported by Windows and Mac, and Linux FreeRDP client software. Note As of June 2017, none of the official distributions of Linux FreeRDP yet include this newest version of Ubuntu 16. There are two generations of the RDP Gateway protocol: An RPC-based generation (BIG-IP 11.6 and later) A newer, simplified non-rpc-based protocol generation (BIG-IP 13.0 and later) Both generations of RDP Gateway protocol use the HTTP protocol for message transport. BIG-IP APM supports both generations, but support of the older protocol requires NT LAN Manager (NTLM) passthrough authentication (similar to Exchange). This means you must configure an NTLM machine account in BIG-IP APM. It s difficult to determine which generation of these protocols BIG-IP APM chooses. If the client chooses the older protocol and you don t have an NTLM Auth profile set up, the following error message syntax appears: <client> does not have associated NTLM Auth profile or ECA profile is missing 53

63 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT ImPLEmENTATION Note For new deployments using BIG-IP APM 13.0 and later, F5 recommends Native mode for RemoteApp or Remote Desktop as the preferred deployment method because it provides the broadest client compatibility and most flexibility. BIG-IP APM RD Architecture In the RemoteApp use case, BIG-IP APM assigns an RDP RemoteApp virtual desktop infrastructure (VDI) resource. When the system displays the full webtop, BIG-IP APM uses the Serverssl profile on the system virtual server to fetch a list of RemoteApps, available on the target Terminal Server over HTTPS, and the associated icons. The system then displays the icons. The system uses HTTPS to connect to the server and RDP (port 3389) to connect to the Terminal Server. In the Terminal Server Desktop use case, the system assigns a native RDP resource. The system displays an associated icon on a full webtop, which you select to gain access to the resource. The system downloads an RDP file to the client computer, and the browser activates the operating system s native RDP client to proceed with the connection. The system uses HTTP to connect to BIG-IP APM over HTTPS and RDP (port 3389) to connect to the Terminal Server. Important The Native RDP mechanism uses SSO that is entirely decoupled from the main SSO mechanism in the Access Profile, so Access Profile settings for SSO do not affect Native Mode RDP for RemoteApp or Native RD Gateway. Instead, the SSO parameters are specified in the resource object itself. Ensure the following: SSO parameters are properly filled in. If AD Auth is in use, use session.logoon.last.actualdomain as the domain parameter, as it automatically fills in the user account domain. The parameter for the username must not contain a domain. Use the Windows SAMAccountName value. Advantages More than half of BIG-IP APM deployments include some form of RDP access, and this native-client MSTSC RDP gateway support strengthens its position and expands the usability of the solution. Additionally, using the RemoteApp support built into newer versions of Microsoft Terminal Services allows you to deliver published applications for Windows, Mac, and mobile users. Using an application tunnel for Microsoft Terminal Services Client An application tunnel provides secure, application-level TCP/IP connections from the client to the network. This option has the most client flexibility and familiar user experience, but lacks SSO capability. You connect using a web browser and select an application tunnel resource from a full webtop. You then run the Microsoft Terminal Services Client (MSTSC) mstsc.exe command to connect to an internal server through a standard application tunnel. 54

64 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT GENERAL RDP FAQ Using RD Gateway for clients Remote Desktop Gateway (RD Gateway) enables authorized remote users to connect to resources on an internal corporate or private network from any Internet-connected device that can run the Remote Desktop Connection (RDC) client. You start a Remote Desktop Connection client and then connect directly to the BIG-IP APM virtual server. For more information, refer to Overview: Configuring APM as a gateway for Microsoft RDP clients in BIG-IP Access Policy Manager: Application Access Guide. Note For information about how to locate F5 product guides, refer to K : Finding product documentation on AskF5. General RDP FAQ What kind of licenses does BIG-IP APM use for RDP access? BIG-IP APM has two license types: CCU and access session. The system uses access session licenses for each established session ID and uses CCUs for network VPNs and other connections which require more advanced features. Native mode RDP does not use a CCU license. Connecting a user consumes only one access session license. What RDP options does BIG-IP APM support? BIG-IP APM supports all RDP options. The options echo back to the client in the RDP file. You can enter your desired parameters into the Custom Parameters area. You can also use session variables in %{session.variable} format. To see a list of RDP options compiled by third parties, refer to Overview of.rdp file settings on DONKZ.NL. Note This link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge. The following options are reserved for BIG-IP APM RDG use. If you attempt to apply these custom parameters, BIG-IP APM ignores or overwrites them: gatewayusagemethod gatewayprofileusagemethod gatewayhostname gatewaycredentialssource gatewayaccesstoken authentication level full address 55

65 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT RDP load balancing FAQ server port enablecredsspsupport signscope signature prompt for credentials on client domain username alternate full address gatewaybrokeringtype RDP load balancing FAQ Can I authenticate clients with a certificate, CAC, SAML, NTLM, or Kerberos and still use Native Client SSO? No. Native Client RDG functionality requires that BIG-IP APM has the username and password. It is not possible to use Kerberos, SAML, or any non-password type authentication. Additionally, RDP clients do not support transmitting client certificates for authentication purposes. Why can t I get Windows 7 to work? In order to use Windows 7 clients, you must obtain the latest RDP client. The following error syntax displays if you attempt to connect without the required RDP client in Windows 7: To use this program or computer, first log on to the following website: <myapm. company.com>. For more information, refer to Client requirements and Update for RDP 8.1 is available for Windows 7 SP1. Note This link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge. To determine the client s version in Windows 7: 1. Right-click the mstsc.exe file and select Properties. 2. Click Details. 3. Check the File version. Important Your client must have Windows 6.3 or later installed for RDP to work. Windows 6.1 (default) does not work. 56

66 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT IPv6 FAQ Can I customize my icons? Yes. The icons for RemoteApps come from the RDP server. You can customize them on the RDP server in the Resource Cutomization Icon area. Can I change the sort order for my RDP RemoteApps? No. An ASCII sort orders RDP RemoteApps. You cannot change this order and or subdivide RemoteApps into separate categories using Webtop Sections. If you must reorder the RDP RemoteApps, request the functionality by contacting the F5 Product and Technology Group and escalating a support ticket. Be sure to describe the functionality you require. Can I change the RDP window title? No. The maximized window title for MSTSC inherits the target device name, not the RD gateway host. The medium-sized window title for MSTSC inherits the RDP filename (launch). Can I automatically start RDP? No. However, you can capture the client s request which triggers the RDP file and set that as the landinguri session variable. IPv6 FAQ What is the maximum possible number of RemoteApps? There is no hard-coded limit, but F5 recommends 100 or fewer. What is the maximum possible number of assigned RD servers? There is no hard-coded limit, but F5 recommends 100 or fewer. Can route domains work if they are set inside a BIG-IP APM resource? Yes. You may assign route domains using the SNAT and Route Domain assign policy item during access policy execution. This sets the session.assigned.route_domain variable, which VDI uses to request socket connections to the Traffic Management Microkernel (TMM) and then to TMM. If you do not set the session.assigned.route_ domain variable, VDI assumes the route domain, based on the route domain of the main BIG-IP APM virtual server. If you set the session.assigned.route_domain variable in the resource ( %2, for example) or if you assign an invalid route domain to the user in the variable, VDI ignores it. Can I use the RemoteApp web page instead of the full webtop web page? No. This use case delivers the Terminal Server s RD Web page using LTM+APM and causes VDI to intercept and successfully proxy the connection to the RD server. F5 does not support this use case. 57

67 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT CLIENT requirements Can I access RDP using HTML5 without a client? No. The Microsoft client is required. Can BIG-IP APM handle multiple logins from the same user? You can configure Terminal Services to allow or disallow a single session from a unique user. However, it may not be possible to have the same user logged in from multiple computers. When this occurs, the new user session takes over the old user session and the system displays the following error: Your Remote Desktop Services session has ended. Another user connected to the remote computer, so your connection was lost. Try connecting again, or contact your network administrator or technical support group. How do I migrate from ActiveX or Java to Native Client? To migrate from ActiveX or Java to Native Client, change the Client Type from ActiveX or Java to Native. In the ActiveX and Java, access control occurs through BIG-IP APM ACLs assigned to the user. In Native, RDP does not honor ACLs. Instead, static resources assigned to the user are used as a whitelist to allow access to those hosts through the RD Gateway. If you require further access, such as for a user-specified host, you must create an RDG-RAP policy to handle the access. Client requirements Both Windows and Mac support MRDC; however, because the protocol uses RD Gateway, only newer RDP clients work. Legacy clients are may not be able to create connections. For Mac clients, use RDC 8 or later. Be sure to obtain the latest client from the App Store. Windows 8.1 and Windows 10 include the required client. For Windows 7 clients, make sure RDC 8.1 is installed. To update RemoteApp and Desktop Connections, refer to Update for RemoteApp and Desktop Connections feature is available for Windows. Note This link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge. If a Windows 7 user tries to use MRDC with the old RDC client or Internet Explorer 10.x or earlier, the following error syntax displays: Unable to download myrd _ appaccess from <host>. Unable to open this Internet site. The requested site is either unavailable or cannot be found. Please try again. 58

68 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP F5 supports the latest ios and Android AppStore RDP clients from Microsoft. Note The ios client does not work if the RDP server uses RDP redirection. Troubleshooting RemoteAPP and Remote Desktop RemoteApp and Remote Desktop present resources in different ways, but once the client downloads the RDP file, BIG-IP APM behaves in the same way for both use cases. Gathering troubleshooting data In order to successfully troubleshoot this feature, gather the following data: VDI log entries (Log sensitivity set to debug). A qkview file, including example session IDs in the logs. Serverssl and Clientssl profiles on the BIG-IP APM virtual IP address, set to the cipher string: RSA+AES. The private key of the certificate for the Terminal Server. RDP is encrypted and must be decrypted for analysis. By default the Terminal Server key is set to be nonexportable. You must switch the key and certification for another. For information on how to switch the key on Terminal Server, see Remote Desktop listener certificate configurations in Windows Server 2012 R2 and Windows Server Note This link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge. Note You cannot use irules to obtain the master key from the serverside SSL communications over RDP because RDP uses a detached SSL connection. Private key or PMS of client s communication to BIG-APM. 0.0 packet capture covering both the HTTPS (port 443) and RDP (port 3389 server-side) communications between BIG-IP APM and the client and between BIG-IP APM and Terminal Server. For more information, see Session variables. Troubleshooting use case: Accessing BIG-IP APM webtop to RDP server to get a desktop In the following troubleshooting processes, presence of the described log messages indicate the success of the associated step. Absence of such messages indicate the step may not have been successful. 1. User obtains a BIG-IP APM session ID. Review the APM log. A log message indicating a successful user ID transmission appears similar to the following: Aug 4 15:23:31 current-2 notice tmm1[13009]: :5: /Common/portal _ test:common:b0a2d1b1: New session from client IP (ST=/CC=/C=) at VIP Listener /Common/user _ 130 _ 75 (Reputation=Unknown) 59

69 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP 2. BIG-IP APM assigns resources to user, including RDP. Review the APM log. Log messages indicating successful assignment of a resource and a full webtop appear simlilar to the following: Aug 4 15:24:46 current-2 notice apmd[7433]: :5: /Common/portal _ test:common:b0a2d1b1: Connectivity resource /Common/rdpresource assigned Aug 4 15:24:46 current-2 notice apmd[7433]: :5: /Common/portal _ test:common:b0a2d1b1: Webtop /Common/fullwt assigned A log message indicating user authentication success and full webtop assignment appears similar to the following: Aug 4 15:24:46 current-2 notice apmd[7433]: :5: /Common/portal _ test:common:b0a2d1b1: Access policy result: Full The user view of the full webtop appears similar to the following figure. Figure 5.1: Full webtop with two resources 3. User clicks the Terminal Server resource to download the RDP file. The VDI plug-in engages. A log message indicating successful VDI engagement appears similar to the following: Aug 10 10:56:36 current-2 info vdi[11172]: : {54b.C.} New APM Webtop request from :52664 to : VDI does the following: Generates an RDP file Generates a cryptographic signature based on the attached ClientSSL profile and puts it in the RDP file Note The client must trust the signature. Creates an auth token and stores it in the /.1/tmm.vdi.rdp.token.<token_id> session database 60

70 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP Updates the user s session variables up through the auth token creation Places the auth token in the RDP file Testing the RDP file The browser downloads the RDP file, which is associated with the Terminal Server application. The Terminal Server application tells the browser to open the RDP file, which contains connection parameters, including the temporary session key. The RDP file appears similar to the following: authentication level:i:0 enablecredsspsupport:i:0 full address:s:ts1.lab.local gatewayaccesstoken:s:oq9vutkflzydgma6b4suya gatewaycredentialssource:i:5 gatewayhostname:s:example.com gatewayprofileusagemethod:i:1 gatewayusagemethod:i:1 server port:i:3389 signature:s: Note Parameters are formatted as follows: parameter name:parameter type:value The MSTSC client opens the hostname specified in gatewayhostname. The tunneled RDP target is in the full address parameter. The client asks the gateway to proxy the connection to the full address target host. Custom Parameters are also contained in this file. 5. The client MSTSC opens the RDP file. 6. The client runs MSTSC with the RDP file. MSTSC validates the signature. If the signature is not valid, the window displays a yellow banner at the top. A valid signature produces a message dialog that appears similar to the following: Do you trust the publisher of this remote connection? This remote connection could harm your local or remote computer. Make sure that you trust the publisher before you connect. Publisher: Type: Remote computer Gateway server: <Publisher> Remote Desktop Connection <Remote computer> <Gateway server> 61

71 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP The subject of the cert+key in the Clientssl profile is the Publisher. The Remote computer is the RDP resource s target. The Gateway server is the DNS name in HTTP. DNS matches the subject. If you select Don t ask me again for remote connections from this publisher, the MSTSC client inserts a key and value in the registry in the following location: HKEY _ CURRENT _ USER\Software\Microsoft\Terminal Server Client\ PublisherBypassList Note To undo, delete the key. If the certificate in the RDP file is invalid (self-signed, expired, untrusted CA, or some other issue), the following error message displays: The digital signature of this RDP File cannot be verified. The remote connection cannot be started. If the client can t validate the SSL cert from the HTTPS connection (subject doesn t match, host is IP address, or some other issue), the following message syntax displays: The computer can t verify the identity of the RD Gateway <Gateway server>. It s not safe to connect to servers that can t be identified. Contact your network administrator for assistance. F5 Support requires that customers have a valid certificate on their BIG-IP APM Clientssl profile as a minimum requirements (required by Windows). 7. MSTSC starts communications and uses data in the RDP file to make HTTPS connections to the server through the MS-TSGU protocol. MS-TSGU is similar to HTTPS and relies on client-initiated HTTP connections for both outgoing and incoming data. A decrypted packet capture appears similar to the following: RDG _ OUT _ DATA /remotedesktopgateway/ HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Accept: */* User-Agent: MS-RDGateway/1.0 RDG-Connection-Id: {B7CCA472-CB01-46E5-99A7-0BE2C5793CB8} RDG-Auth-Scheme: PAA RDG-Correlation-Id: {8526E0BF-135A-40AB-9A91-2C34216C0000} Host: example.com HTTP/ OK <RDP data goes here> 62

72 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP RDG_OUT_DATA and RDG_IN_DATA are used for transmit and receive. 8. BIG-IP APM validates the connection. Once the client starts the connection, BIG-IP APM looks up the session, based on the token. The token appears in the RDP file under gatewayaccesstoken. The corresponding data in sessiondb appears similar to the following: get /.1/tmm.vdi.rdp.token.Sh55aJ2sx _ gefr/ _ Crycgw VALUE tmm.vdi.rdp.token.sh55aj2sx _ gefr/ _ Crycgw af90926b470f7f40dfd75746d135ae /Common/myrd _ appaccess TS1.LAB.LOCAL:3389 In the previous example, the name of the resource is present, as is the target, port, and session ID. BIG-IP APM uses this data to correlate the RD client s connection and the BIG-IP APM session together. The client must create a connection within the specified timeout range (90 seconds). If the client uses a stale RDP file with an expired gatewayaccesstoken, the following error syntax appears: RemoteApp Disconnected Remote Desktop can t connect to the remote computer <remote computer> for one of these reasons: 1) Your user account is not authorized to access the RD Gateway <RD gateway> 2) Your computer is not authorized to access the RD Gateway <RD gateway> 3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password) Contact your network administrator for assistance. 9. If the resource is dynamic (user-defined), BIG-IP APM runs the RDG-RAP access policy. Note RDG-RAP policies are not required for static resources (destination = Host Name or IP Address). They are only required when accessing resources that require RDP redirection (destination = User Defined, or the Terminal Server is redirecting the user). If an RDG-RAP policy is required, the following log message syntax appears in the APM logs: No RDG policy specified, deny access to <computer name>. Unlike everything else in BIG-IP APM, which relies on ACLs, access control in VDI relies on a special access policy that runs after the main access policy, when MSTSC tries to connect. The special RDG-RAP type of access policy can completely redirect the connection to a different host by rewriting the session.rdg.target.host session variable. However, session variables from the main session are not available, so the logic must be statically hard-coded into the RDG-RAP access policy instead of being dynamically assigned by session variables or user Active Directory data. 10. After the RDG session starts and VDI knows the target server to which the client wants to connect, BIG-IP APM performs the following logic: If the target server is specified as a static resource and is assigned to the user, allow the 63

73 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP connection. The resource is usually static unless you re using the User Defined option. Run the RDG-RAP access policy specified in session.rdg.rap. The system assigns this policy with the RDG Policy Assign Policy Item during the main access policy. If that variable is missing, a log message similar to the following appears in the APM logs: Aug 10 20:00:39 current-2 notice vdi[11172]: : {584.C.4ec55c8f} No RDG policy specified, deny access to ts1.lab.local:3389 For more information, see RDG-RAP access policies. 11. SSO proceeds. If you enable SSO for the resource, at the beginning of the RDP connection, BIG-IP APM injects SSO credentials into the data stream. SSO is a binary protocol, so it may be difficult to figure out which username and password combination is injected. If SSO is not enabled for a RemoteApp resource, the RemoteApp icons cannot be retrieved for the full webtop display until the user clicks. The domain must be specified. If the domain isn t specified by logging in with username\domain or username@domain, then use an AD Auth agent followed by a Variable Assign agent to specify the standard session.logon.last.domain variable based on the AD Auth result s session.ad.last.actualdomain variable. The following figure shows a sample access policy configured as described. Figure 5.2: AD Auth agent with variable assign 12. MSTSC runs the connection as usual. BIG-IP APM logs numerous messages similar to the following: Aug 10 20:05:01 current-2 debug vdi[11172]: : {587.S.a3ae6c99} <- 64

74 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP Payload[46] Aug 10 20:05:01 current-2 debug vdi[11172]: : {587.S.a3ae6c99} <- Payload[46] Aug 10 20:05:01 current-2 debug vdi[11172]: : {587.S.a3ae6c99} <- Payload[42] Troubleshooting use case: RemoteApp displays on BIG-IP APM full webtop BIG-IP APM can act as an App Gateway to deliver applications from an MS RemoteApp feed. The operation is similar to the Remote Desktop use case described previously. The BIG-IP APM downloads an XML representation of the RemoteApp Web Feed and delivers the RemoteApp icons through the full webtop. Once clicked, a resource icon on the full webtop triggers BIG-IP APM to download an RDP file, and the Terminal Services client opens the file. To troubleshoot this use case, use the same steps as described previously in Troubleshooting use case: Accessing BIG-IP APM webtop to RDP server to get a desktop adding the following events after 2. BIG-IP APM assigns resources to user, including RDP. : 1. BIG-IP APM obtains a list of the RD feeds. 2. The RemoteApp feed provides a list of RDP App Resources. 3. The system delivers the icons list to the browser. 4. The browser requests an icon through a proxy mechanism in the VDI module. The request appears similar to the following: _ terminal _ server?feeduri=<base64 encoded URI of icon image> Because the RemoteApp feed comes through HTTPS and IIS on the Terminal Server, ensure the following: The BIG-IP data plane can route to the Terminal Server. BIG-IP can create an HTTPS connection to the Terminal Server. Terminal Server correctly renders the page directly to a standard web browser. It should appear similar to the following: 65

75 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP Figure 5.3: Default Microsoft RD Web from Terminal Server s IIS If you log in with user credentials, an App Feed or desktop feed should appear similar to the following: Figure 5.4: Microsoft RD Web terminal server RemoteApp portal page Note Part of the page displayed in the previous figure is the location from which VDI derives the applications and their associated icons. Troubleshooting common problems Problem: TMM selects an unexpected virtual server. When VDI connects to the Terminal Server, TMM standard logic selects a virtual server. If no virtual server exists, there is no problem; however, if TMM selects a virtual server such as a transparent proxy, SSL intercept, or similar, and if that server overrides SSL profile or other critical properties, traffic flow may be disrupted. Troubleshoot by running a packet capture on traffic from BIG-IP APM to the Terminal Server. 66

76 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP Problem: Missing RDG-RAP access policy Troubleshoot by looking for No RDG policy specified in your BIG-IP APM log. Logs appear similar to the following: Mar 6 10:50:07 vw-beta-virtlb01 debug vdi[29838]: 019cffff:7: /Common/clientvdi _ access:common:4e03753a: {34.C} TMEVT _ SESSION _ RESULT Mar 6 10:50:07 vw-beta-virtlb01 notice vdi[29838]: 019cffff:5: /Common/clientvdi _ access:common:4e03753a: {34.C} No RDG policy specified, deny access to ts1.lab. local:3389 To bypass this problem for testing, create an RDG-RAP access policy (Start -> Allow) and assign it in a RDG Policy Assign object. To meet the use case requirements, remember to correctly set up the RDG-RAP policy afterwards. Problem: Incorrect Windows 7 client Troubleshoot by using Windows 10 for testing to make sure it s set up correctly, then review Client requirements. Problem: Connection errors, routing, and other issues Troubleshoot by ensuring that VDI can route to and create SSL connections to the server. VDI does this by using the attached serverssl profile. You may need to modify the serverssl profile or review logs if VDI can t make connections. Error messages in /var/log/apm appear similar to the following: Error reported for an outgoing connection. Note VDI cannot report the cause of connection errors because it routes usingtmm to perform connections. TMM does not return any kind of error code to the plug-in. A generic code displays in the logs instead. Troubleshooting SSO problems Quick checklist 1. Enable SSO in the resource. Note Generally, in BIG-IP ASM, SSO credentials are derived from settings in the access profile; however, in Native RDP, SSO settings are derived from the resource itself. 2. Check the settings. The username, password, and domain are mandatory. Username Source is usually one of the following: session.logon.last.logonname This is the untranslate username that the user enters on the BIG-IP APM logon page. session.logon.last.username 67

77 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT TROUBLESHOOTING RemOTEAPP and RemOTE DESkTOP This is the username that BIG-IP APM translates from the logon page. If you enable Split domain from username in the access policy s Logon Page agent, username syntax <company\ employee> translates to <employee>. Password Source is usually session.logon.last.password. Make sure the correct (encrypted) password exists if you ve used two-factor or other techniques that may modify the password variable. Domain Source You must choose one of the following options, or another variable: session.logon.last.domain This is set manually in the Variable Assign agent. You can also set it in the Logon Page agent if Split domain from full username is set to Yes and the user login credentials include the domain name. session.ad.last.actualdomain If you use an AD Auth agent in your access policy, this variable is set automatically. (Recommended) 3. Check session variables. In the Configuration utility, click View Session Variables. If the SSO input username or password is incorrect, the client does not connect. The error logged on the client computer appears similar to the following: Your computer can t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance. A corresponding error message may appear in the server logs. It appears similar to the following: Feb 13 17:22:56 current-3 info vdi[6934]: 019cffff:6: /Common/ rdpdemo:common:2e3c96c8: {37.S} Performing RDP SSO for LAB.LOCAL\lab\ taccount Feb 13 17:22:57 current-3 err vdi[6934]: 019cffff:3: /Common/ rdpdemo:common:2e3c96c8: {37.S} An exception is thrown: Net:1: Connection was closed The SSO mechanism in the VDI resource does not automatically split usernames for you. Therefore, usernames must specify a variable value in the following format: samaccountname. You cannot specify usernames in the following formats: username@domain domain\username You must specify the domain. F5 recommends using a AD Auth agent, followed by a Variable Assignment agent. For example: 68

78 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT RDG-RAP access policies session.logon.last.domain = mcget "session.ad.last.actualdomain" As long as AD Auth is successful, this configuration correctly sets the session.logon.last.domain parameter automatically. This is particularly useful when using an authentication cascade (multiple fallbacks) for multiple-domain scenarios. If the client is using Windows 7, you must install the RDP 8.1 update. For more information, see Client requirements. RDG-RAP access policies The RDG-RAP feature allows you to permit access only to a list of RD servers gathered from an LDAP or AD Query. This allows users to only connect to valid servers and not arbitrary ones. In BIG-IP APM , RD Gateway runs a special access policy called RDG-RAP to decide if the user has permission to access server resources. RDG-RAP policies are limited in functionality. The only session variables available are the following: session.rdg.target.host This is the host that the Terminal Services client wants to access using BIG-IP APM. session.rdg.target.port This is the port that Terminal Services client wants to access using BIG-IP APM. Both of these session variables are read/write. If you set them to a different value, the Terminal Server connection is directed toward that server, regardless of the desired connection. RDG-RAP does not allow you to access any of the user s session variable information such as username, domain, password, session ID, custom variables, and so on. For more information, see Overview: Configuring APM as a gateway for Microsoft RDP clients in BIG-IP Access Policy Manager: Implementations. How can I tell if I need an RDG-RAP access policy? You may need to use an RDG-RAP policy if you receive an error that appears similar to the following: RemoteApp Disconnected Remote Desktop can t connect to the remote computer <computer name> for one of these reasons: 1) Your user account is not listed in the RD Gateway s permission list. 2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example, computer.1.fabrikam.com or ). Contact your network administrator for assistance. You may need to use an RDG-RAP policy if you see a log message in /var/log/apm that appears similar to the following: Feb 12 09:39:27 labtest01 notice vdi[28911]: 019cffff:5: /Common/rdp _ access:common:118f5cc0: {49.C} No RDG policy specified, deny access to :3389 Note No RDG policy specified 69

79 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT LOGGING Note For testing purposes, you can create a simple Start -> Allow RDG-RAP policy and use the RDG Policy Assign agent to assign it. This allows all authenticated users to access any RDP server using BIG-IP APM and eliminate the possibility of this error. Can I use BIG-IP APM as a gateway for RDP clients? Yes. For information on using BIG-IP APM as a gateway for RDP clients, see Using APM as a gateway for RDP clients in BIG-IP Access Policy Manager: Implementations. Logging In BIG-IP 12.x and earlier, the db variable sys db log.vdi.level controls VDI logging level. In BIG-IP 13.0 and later, the VDI log level is specified along with the other access log settings. When troubleshooting VDI in a testing environment F5 recommends setting VDI logging to Informational or Debug. Important These settings are only appropriate for a test environment. Do not use these settings in a production environment. Troubleshooting reconnections and disruptions Disruptions may occur between the client and BIG-IP APM or between BIG-IP APM and the Terminal Server. Disruption between client and BIG-IP APM If a user disconnects and reconnects, the session resumes. The client instructs the RD Gateway (BIG-IP APM) to reestablish the session. The Remote Desktop session also resumes. If the BIG-IP APM session is deleted or times out or otherwise destroyed, the connection stops, RDP tries to reconnect and fails, and the following error message syntax displays: Remote Destkop Connection Remote Desktop can t connect to the remote computer <computer name> for one of these reasons: 1) Your user account is not authorized to access the RD Gateway <RD gateway name> 2) Your computer is not authorized to access the RD Gateway <RD gateway name> 3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a mart card but you provided a password) Contact your network administrator for assistance. Disruption between BIG-IP and Terminal Server If BIG-IP APM loses connectivity to the Terminal Server, the previous error appears on the client, the connection immediately fails, and the system logs messages similar to the following: Aug 10 20:12:33 current-2 notice vdi[11172]: : {593.S.f9c8bdbc} Error reported for an outgoing connection Aug 10 20:12:33 current-2 info vdi[11172]: : {593.S.f9c8bdbc} Error reported 70

80 REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT LOGGING on initiated outgoing connection. Aug 10 20:12:33 current-2 notice vdi[11172]: : {593.S.f9c8bdbc} Failed to connect to RDG target ts1.lab.local:3389: system:111 In these situations, the lengthy retry mechanism of MSTSC is bypassed, which may cause user complaints. If this happens, you can contact F5 Support case to clarify in detail what the user wants to happen when a disruption occurs between BIG-IP APM and the RDP server. If BIG-IP APM loses connectivity to the client, MSTSC retries the connection several times and the following message displays on the client computer: Reconnecting The connection has been lost. Attempting to reconnect your session... Connection attempt: 1 of 20 71

81 SECURITY SESSION management Security BIG-IP APM provides security through session management, session ID rotation, identity access management, tunneling, ACLs, and several other measures. Session management BIG-IP APM security is based on how BIG-IP APM sessions function and terminate. Several security protections function at the session level: Access Profile Scope (BIG-IP 12.0 and later). Session ID rotation provides protection against session-level hacking. Maximum sessions and timeouts can be configured. Cookie options can be configured. Access policies can be configured based on the client IP address reputation. Provides authentication server protection from distributed denial of service (DDoS) attacks and protects against lockout due to such attacks. Access Profile Scope In BIG-IP 11.x , user session IDs are global to the BIG-IP system and can be presented to any BIG-IP APM virtual server with an attached access profile. In BIG-IP APM v and later, the configurable Profile Scope establishes additional criteria to ensure that a user who has established a session on one virtual server or access profile cannot use that same session cookie to access other virtual servers and the resources behind them. There are three possible Profile Scope settings: Profile gives users access only to resources that are behind the same access profile on any virtual server. (Default.) Virtual Server gives users access only to resources that are behind the same virtual server. Global gives users access to resources behind any access profile that has global scope. This setting is equivalent to BIG-IP 11.x behavior. BIG-IP logs violations of the Profile Scope as follows: Jul 25 00:58:20 bigip3926 notice tmm2[8405]: :5: /Common/ allow2:common:33ea6d81 Session invalidated due to virtual-server scope mismatch (expected /Common/test, got /Common/allow2 ). Jul 25 01:09:18 bigip3926 notice tmm1[8405]: :5: /Common/ allow2:common:a53b6fe6 Session invalidated due to profile scope mismatch (expected /Common/allow2, got /Common/test ). Jul 25 01:14:18 bigip3926 notice tmm[8405]: :5: /Common/ allow2:common:2d Session invalidated due to scope type mismatch (expected profile, got global ). 72

82 SECURITY SESSION management Important Sessions terminate if used outside allowed Profile Scope parameters. For more information, refer to Configuring Access Profiles for Portal Access in BIG-IP Access Policy Manager. Session ID rotation BIG-IP APM tracks all client sessions using a unique, proprietary session ID. During the course of an access policy evaluation, the session ID randomly rotates to prevent session hijacking and fixation attempts. In BIG-IP APM and later, session ID rotation is enabled by default. This feature may cause issues with older clients or deployments using irules if they rely on remembering Session ID. To disable automatic Session ID Rotation using tmsh at the command line 1. To view the current configuration setting for session ID rotation, type the following command: tmsh list /sys db apm.rotatesessionid 2. To disable automatic rotation of BIG-IP APM session IDs by type the following command: tmsh modify /sys db apm.rotatesessionid value disable 3. Save the change by typing the following command: tmsh save /sys config Maximum sessions per user For some access profile types, you can set a custom value for the maximum number of valid sessions a user can have open at one time. Since each session consumes an access license, malicious attacks to consume all BIG-IP APM licenses fail. To set a custom value for maximum sessions per user using the Configuration utility 1. Navigate to Access Policy >> Access Profiles: Access Profiles List. 2. Click a profile name. 3. Select Custom. 4. Under Settings, set a value for Max Sessions Per User. 5. Click Update. Session timeouts BIG-IP APM controls the timeout values of sessions in the definition of an access profile. The values can be used to expire sessions based on inactivity, maximum session time, or exceeding of access policy evaluation time. Once the inactivity timeout setting is configured, there are only four events or actions that override it: The user logs out of BIG-IP APM. 73

83 SECURITY SESSION management The value for Maximum Session Timeout is exceeded. You delete the session. The access policy evaluation exceeds the configured timeout period. Secure cookies To make sure that the client browser doesn t send session cookies in an unencrypted request, the Secure cookie option (enabled by default) adds the secure attribute to the session cookie. The following shows an example of a session cookie with Secure cookie enabled: Set-Cookie: MRHSession=d db9ece7ac6d41f45923; path=/; secure Note Because the secure cookie option makes sure the browser does not send a session cookie in an unencrypted request, the secure cookie option needs to be disabled in application access control deployments where an HTTP virtual server is used. HTTPOnly cookies For browsers that support it, you can enable the HTTPOnly option to mitigate the risk of a client side script accessing the BIG-IP APM session cookies. This option only works for the LTM+APM access profile type. Other access profile types require access to various session cookies. Persistent cookies You can use persistent cookies with Web Access Management/LTM-APM access profile type to store the cookies locally on the client hard disk. When the system first establishes the session, BIG-IP APM session cookies are not marked as persistent. After the user successfully authenticates with BIG-IP APM and the access policy completes successfully, the system marks the cookies as persistent in the next response to the client. Network Access and application tunnels do not support persistent session cookies. Restriction of sessions to a single client IP You can restrict user access to BIG-IP APM to a single client IP address in the access profile. Enabling the Restrict to Single Client IP option associates a client s IP address to their BIG-IP APM session. On each client request, BIG-IP APM verifies that the client s IP address associated with the BIG-IP APM session has not changed. If the IP address has changed, the session is terminated, the request is redirected to the access profile s logout page, and the system logs a message to /var/log/apm indicating that a session hijacking attempt was detected. This setting may not be useful for deployments in which users hop between wireless access points because these access points may give different IP numbers to genuine users. DoS/DDoS Protection The Max In Progress Sessions Per Client IP restricts the number of in-progress access policies for a given client IP address. In-progress access policies are client sessions which BIG-IP APM is still evaluating to determine whether to grant or deny client access to protected resources. The default value only allows 128 in-progress sessions per IP. After reaching that value, BIG-IP APM denies any 74

84 SECURITY additional requests from that IP to start a new BIG-IP APM session. BIG-IP 11.5.x and earlier use a default value of 0. A value of 0 represents unlimited sessions. If the value is less than 128, consider increasing it. Warning If a large number of users simultaneously access BIG-IP APM from behind a device or proxy configured with NAT it may prevent new sessions from starting. Brute-force protection You can enable the Minimum Authentication Failure Delay and Maximum Authentication Failure Delay options to slow or mitigate brute-force attacks against BIG-IP APM. You can use the following AAA types: Active Directory HTTP Kerberos LDAP Local User DB One-time password verification Oracle Access Manager Remote Authentication Dial-in User Service (RADIUS) SecurID Terminal Access Controller Access Control System (TACACS+) You can also prevent brute-force attacks using CAPTCHA on a BIG-IP APM logon page. By default, BIG-IP APM uses the Google recaptcha service, but you can use any CAPTCHA service that provides a recaptchacompatible API. The Local User DB also provides a user account lockout option. After a certain amount of failed login attempts, the system locks the user account for a specified time interval. Lockout limitations include the following: An attacker can cause a DoS/DDoS by locking out large numbers of accounts. Lockout is ineffective against slow attacks that try only a few passwords every hour. Lockout consumes system resources If an attack continues after one or more accounts are locked out. Lockout can reveal information about valid users to attackers during a directory harvest attack. For more information on how to use Local User DB to mitigate brute force authentication attacks, refer to Local User Database in BIG-IP Access Policy Manager: Authentication and Single Sign-On. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. 75

85 SECURITY Identity access management Identity and access management (IAM) consists of the management of user authentication, authorization, and privileges within the enterprise and cloud-based services. The goal of IAM is to increase security and productivity while decreasing cost, downtime, and repetitive tasks. As many organizations move to adopt more cloud-based services, they may experience challenges in ensuring that ACLs are accurate across all services. They may also experience difficulty enforcing a reliable security policy. As with internally managed services, Software-as-a-Service (SaaS) providers maintain their own IAM systems for usernames, passwords, and access control enforcement. This approach may cause security management issues as organizations employ multiple, unintegrated IAM systems. BIG-IP APM access federation addresses these issues by eliminating the disconnect between internally maintained IAM systems and services external to the enterprise. In doing so, BIG-IP APM can deliver consistent security everywhere. Password management is simplified by maintaining all user passwords in the corporate user directory. Users need only a single password to access internal systems and SaaS-based applications. You can implement multi-factor authentication at the access control point (BIG-IP APM). The system can perform client-side inspection checks (such as firewall, antivirus systems, and machine certificate checks) before allowing access to applications. Multi-factor client authentication The three most common authentication factors are known as Something You Know, Something You Have, and Something You Are. Something You Know is typically a password or a PIN, but may include questions that only the user can answer, or a touchpad gesture. Something You Have is typically either a physical or software token, but might include a certificate, or some combination of certificate and token. Something You Are is typically a biometric input, such as fingerprint, retina scan, or facial or voice recognition. Multi-factor client authentication includes a combination of two or more authentication factors. Client credentials protection All in-memory sensitive data, such as user credentials, SSO credentials, and secure stored session variables, are 128-bit AES encrypted. BIG-IP APM uses a per-user master key, which derives from the BIG-IP APM session cookie. The cookie is only valid for that single user session. The system does not store the key in memory, and only stores the session variables in memory as long as the session is valid. Once the session terminates, the system removes the data and destroys the key. 76

86 SECURITY NETwORk SECURITy Network Security BIG-IP APM provides tunnels and ACLs as configurable network security features. Tunneling BIG-IP APM offers support for either full or split tunneling for Network Access. Full tunneling provides Windows, Macintosh, Linux, and Windows Mobile users with access to the complete set of IP-based applications, network resources, and intranet files available, as if they are working at their desktop in the office. Split tunneling provides control over exactly what traffic the system sends or doesn t send over the Network Access connection to the internal network. This feature provides better client application performance by allowing connections to the public Internet to go directly to the destination, rather than being routed down the tunnel and then out to the public Internet. Full tunneling Full provides better security for clients than split tunneling. In a full-tunnel deployment, all VPN traffic is sent through the VPN tunnel, which allows for greater control of traffic from remote users. Traffic destined for the Internet can now traverse through the company s gateway security devices and have corporate policy applied to it. As increasing numbers of enterprises elect to pay for the extra resources required to maintain VPN full tunnels, concerns may arise when users connect to devices when not using the VPN. To alleviate these concerns, many companies allow only corporate-issued devices to connect to the VPN and require VPN connection at all times. Such a forced-vpn connection may be effective in monitoring an off-site corporate asset. Split tunneling Split tunneling results in less traffic flowing through BIG-IP APM, as only traffic destined for the VPN traverses the tunnel. Less traffic leads to a smaller workload for BIG-IP APM and lowered bandwidth requirements. Split tunneling also allows for a strict separation between corporate intranet traffic and private Internet use. Split tunneling also allows a user to access more than one network without having to repeatedly connect and disconnect in order to switch from one network to the other. Security concerns with split tunneling Split tunneling makes it possible for a remote user to bypass network security, such as web content filtering for outbound HTTP traffic. If users are connected to a remote network employing DNS hijacking, name resolution may not work as expected for internal hostnames. To mitigate this issue, BIG-IP APM provides Windows DNS Relay Proxy, which can be configured to allow hostnames for internal domain names to be intercepted and relayed over the VPN tunnel for correct resolution. For more information, refer to AskF5 article: K9694: Overview of the Windows DNS Relay Proxy service. Another security concern is that split tunneling can allow a PC infected with malware to act as a gateway to the 77

87 SECURITY AUDITING corporate network. To protect split-tunneling configurations against such exploitation, BIG-IP APM provides two options that can be used to further protect split-tunnel configurations: Prohibit routing table changes during Network Access Connection and Integrated IP filtering engine. When enabled, the Prohibit routing table changes during Network Access connection option prevents the client s routing table for the F5 Point-to-Point Protocol (PPP) adapter from being changed by adding, deleting, or modifying any existing routes. The adapter is constantly monitored by the F5 VPN software. If any changes to the routing table are found, they are discarded and the routing table reset. When enabled, the Integrated IP filtering engine provides additional security for data leakage. Traffic generated by devices on the client s LAN are not allowed to traverse the tunnel. ACLs Once a BIG-IP APM tunnel is established on a network, users with access to the tunnel have full access to the network. To improve security, remote user access can be limited to crucial network resources only with ACLs. ACLs can be configured on a per-session basis to provide individually tailored access for each user. BIG-IP APM uses both static pre-configured ACLs and dynamic ACLs. Dynamic ACLs live on other devices, such as Active Directory or RADIUS. Many companies configure ACLs on their internal routing and switching infrastructure. Matching on the source address, which is the tunnel address, provides defense against potential Network Access violations. Auditing By enabling audit logging, BIG-IP can track configuration changes. When audit logging is enabled, commands performed by an administrator and by root are logged to the /var/log/audit file. These includes changes to access policy using the visual policy editor and creation, deletion or modification to any profile, AAA server, resource, or other objects. Changes are logged as tmsh commands, regardless of whether the logged action was performed in the Configuration utility or at the command line. 78

88 HIGH AVAILABILITY BIG-IP APM failover components High Availability A high availability (HA) deployment consists of two BIG-IP systems synchronized with the same configuration: one system actively processes traffic while the other remains in standby mode until needed. The goal of such redundant pairing is to provide users with seamless, uninterrupted service in the event of failure on one device. If the active system is taken offline or something occurs to prevent it from processing traffic, the standby system immediately takes over. Typically, the newly active system remains active until an event requires the first BIG-IP system to become active again or until you manually force that system into standby. While BIG-IP system configurations allow for configurations with multiple standby systems or active-active pairings, BIG-IP APM only supports two systems paired in active-standby configuration. For more information, refer to AskF5 article: K15503: BIG-IP APM HA considerations. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. BIG-IP APM failover components Device trust domains, device groups, and traffic groups make possible data synchronization between BIG-IP systems in an HA configuration. Device trust domains To provide failover or configuration sync, BIG-IP APM systems on the network must be in the same trust domain. The trust relationship between BIG-IP APM devices on the network is established through certificatebased authentication. BIG-IP APM devices in a trust domain can synchronize and failover their BIG-IP APM configuration data, and exchange status messages continuously. A local trust domain includes the BIG-IP system local device. Device groups A device group is a collection of BIG-IP systems that have established a device trust and share data with each other. The type of data shared depends on what type of data the device group is configured to share. The two device groups types are sync-only and sync-failover. A sync-only device group synchronizes only configuration data, such as policy data, but it does not synchronize failover objects. Use this configuration for synchronizing configuration data between BIG-IP systems deployed in different geographic locations. A sync-failover device group synchronizes configuration data and traffic group data for failover purposes. Use this configuration to fully synchronize two BIG-IP systems. If the active system becomes unavailable, failover occurs and the standby system is able to instantly pick up traffic passing through the system without interruption. Traffic groups A traffic group is a collection of related configuration objects that run on a BIG-IP system. Together, these objects process a particular type of traffic on that device. In general, a traffic group makes sure that when a device 79

89 HIGH AVAILABILITY HIGH availability becomes unavailable, all of the failover objects in the traffic group fail over to a standby system in its device group. High availability In order to deploy BIG-IP APM systems in an HA configuration, you must first do the following: Establish a device trust between two BIG-IP APM systems. Configure a sync-failover device group. For more information, refer to AskF5 article: K13649: Creating a device group using the Configuration utility. Configuring HA Active-standby deployments with BIG-IP APM should use only traffic-group-1. BIG-IP APM supports only active-standby configurations between two devices. BIG-IP APM peer devices must use identical hardware and run the same software version including hotfix level. For more information, refer to AskF5 article: K8665: BIG-IP redundant configuration hardware and software parity requirements. BIG-IP APM session data synchronizes across an active-standby deployment. You can verify synchronization at the command line by identifying a newly created BIG-IP APM session on the active unit and using sessiondump to verify that the BIG-IP APM session exists on the standby unit. For more information about sessiondump, refer to Tools and utilities. Also refer to AskF5 article: K11134: Locating a user s session ID. Failover and user sessions The BIG-IP system supports both persistence and connection flow mirroring. In a typical BIG-IP LTM use case, the system uses both to share allow TCP connection states between HA peers. However, BIG-IP APM does not support connection flow mirroring. BIG-IP APM HA mirroring configurations synchronize BIG-IP APM session data (such as session variables and session state). In the case of a failover event, the system maintains the client session state and the user is not required to re-establish the session. During typical failover, BIG-IP APM does the following: Maintains active the BIG-IP APM session Resets TCP and PPP connections Automatically renegotiates disconnected client network connections Maintains user sessions, including session state information Re-establishes client applications connections when the tunneled protocol supports automatic reconnect (such as VPN and RDP protocols). Note Depending on the how they are connected, client applications such as FTP and SSH may not 80

90 HIGH AVAILABILITY HIGH availability automatically re-establish their connections. The following figure shows an example of a failover between two systems, APM01 and APM02, deployed in an HA pair. Figure 7.1: BIG-IP APM failover In the previous figure: 1. On an existing connection, client request traffic arrives at a virtual server on APM01 (active unit). 2. APM01 checks its connection table entries and processes the traffic when the entry is matched. 3. APM01 sends response traffic back to client. 4. APM01 experiences a failover event and APM02 becomes the active unit. A gratuitous ARP updates network infrastructure ARP caches with the MAC address of the appropriate interface on APM02 for the virtual server s IP address. 5. The client sends a request using its existing TCP connection and the traffic arrives at APM02 (now the active unit). 81

91 HIGH AVAILABILITY HIGH availability on VIPRION 6. APM02 checks its connection table entries and does not match an entry for the client. 7. APM02 sends a TCP RST to the client. 8. Client initiates a new TCP handshake. 9. APM02 makes an entry in its connection table. A new SSL session is negotiated, and since APM session information is mirrored, the session resumes. 10. APM02 sends response traffic back to client. Policy Sync BIG-IP APM Policy Sync maintains access policies on multiple BIG-IP APM devices while adjusting appropriate settings for objects that are specific to device locations, such as network addresses. You can synchronize policies from one BIG-IP APM device to another BIG-IP APM device, or to multiple devices in a device group. A sync-only device group configured for automatic and full sync is required to synchronize access policies between multiple devices. For more information, refer to Synchronizing Access Policies in BIG-IP Access Policy Manager: Implementations. Note A maximum of six BIG-IP APM systems are supported in a sync-only group type. High availability on VIPRION Note the following considerations before deploying BIG-IP APM on a VIPRION system: BIG-IP LTM currently supports active-active deployments across traffic groups and up to 32 BIG-IP systems. BIG-IP APM only supports active-standby deployments across two BIG-IP APM systems. BIG-IP APM can only run from within traffic-group1 on a BIG-IP system. A BIG-IP VIPRION system can be deployed as a standalone or as a active-standby pair. BIG-IP APM behavior differs depending on which deployment mode you use, on user experience, and on the details of a failover event. SessionDB employs a shared-nothing partitioning scheme to store session entries across all available blades in a VIPRION system. This scheme addresses the challenge of scaling to support high throughput and large data sets. When storing an entry, SessionDB uses a hashing algorithm on the session entry s key to determine which available blade it should be stored on. The same hashing algorithm retrieves the entry. Note The same key may produce different hash values when the number of available blades in the VIPRION system changes. 82

92 HIGH AVAILABILITY HIGH availability on VIPRION Standalone VIPRION In a standalone multi-blade VIPRION system with cluster mirroring set to Within cluster, each session ID entry mirrors to a different blade within the same VIPRION system to mitigate data loss in case a blade goes offline. Figure 7.2: Standalone VIPRION cluster with all blades online In the case of a blade failure, no user sessions are interrupted or lost. 83

93 HIGH AVAILABILITY HIGH availability on VIPRION Figure 7.3: Standalone VIPRION cluster with blade 2 offline. No user sessions are lost. VIPRION BIG-IP APM on VIPRION Sync-Failover In an active/standby sync-failover device group with cluster mirroring set to Between cluster, the system distributes session entries among the online blades and mirrors to the standby VIPRION system. 84

94 HIGH AVAILABILITY HIGH availability on VIPRION Figure 7.4: Active-standby VIPRION device group with all blades online If a blade in the active system goes offline, such as BIG-IP VIPRION - A: Blade 2 in the following figure, all session entries hosted by that blade are lost. Backup copies of session entries are available on the standby VIPRION s primary blade. If the active VIPRION system maintains its role, existing sessions may need to re-establish under the following conditions : The session entries held in offline blade are lost. The system can t find existing session entries and the session lookup algorithm has changed due to the new blade configuration. 85

95 HIGH AVAILABILITY HIGH availability on VIPRION Figure 7.5: Active-standby VIPRION device group with Blade 2 on VIPRION A offline Note To minimize disruption, F5 recommends that failover triggers and that the standby VIPRION assumes the primary traffic-processing responsibility. You can configure the active/standby sync-failover device group to automatically trigger failover by setting the Minimum Number of Blades Up Before Device Is Considered Available option to match the number of blades available in the VIPRION chassis. For example, if there are 2 configured blades in the VIPRION chassis, the value of Minimum Number of Blades Up Before Device Is Considered Available should be set to 2. User sessions mirrored to online blades remain available by manually forcing a failover to the standby VIPRION system. Existing user sessions are maintained and disruptions minimized. 86

96 MANAGEMENT LICENSE usage monitoring Management You must regularly complete several BIG-IP APM management tasks to maintain the health of the system. These include the following: Tracking the number of concurrent user sessions Monitoring the authentication server pool to make sure that the system uses valid servers to authenticate and authorize users Maintaining and reviewing log files to track usage patterns and other information Preventing disk partitions from filling up, which can degrade performance of the BIG-IP system. Note F5 recommends remote logging using high-speed logging (HSL) with irules to conserve disk space. Additionally, storing logs externally to the BIG-IP system allows them to be kept for longer periods, which makes long-term trend analysis possible. License usage monitoring Monitoring BIG-IP APM resource usage is important to maintaining system health. For every user session with BIG-IP APM, the system consumes an access license. If you allow access to a remote access resource, such as Network Access (VPN), Portal Access (HTTP tunneling), or application access (AppTunnels), the system consumes a concurrent user (CCU) license. For more information, refer BIG-IP APM license types. To ensure that there are always sufficient resources available to the user, F5 recommends periodic monitoring of the available access and concurrent licenses. For more information, refer to AskF5 article: K15032: Determining license limits of the BIG-IP APM system. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. Collecting usage data BIG-IP APM supports use of SNMP to determine the number of concurrent user licenses in use. When using SNMP is not possible, you can use the visual policy editor to add a policy agent in the access policy to collect license usage data. The following figure shows a Variable Assign agent in use. 87

97 MANAGEMENT LICENSE usage monitoring Figure 8.1: Variable Assign access policy agent used to collect license usage Using the visual policy editor: Collect Concurrent user licenses in use values only. Prevent network resource access. Terminate in Deny. Variable Assign agent The Variable Assign agent creates the following four session variables, populated with TMM license information: Total Number of Access Session Licenses Available. Number of Access Session Licenses Currently in Use. Total Number of Concurrent User Licenses Available. Number of Concurrent User Licenses Currently in Use. 88

98 MANAGEMENT LICENSE usage monitoring Figure 8.2: Branch rules in Variable Assign agent collect license usage information in session variables Once stored in session variables, these variables display in the visual policy editor and you can use them for the policy. Rather than creating a Message Box agent to display these values, you can use the customization shown in the previous figure to display them on the Deny page. The following figure shows the Error message in the Deny field. The error message uses the variables you create in the Variable Assign agent, but the variables must adhere to the %{variable-name} syntax so that the value of the variable displays rather than the variable name. Figure 8.3: Logout page error message configuration 89

99 MANAGEMENT Logs When the system denies access to a user connection, the following figure displays. Figure 8.4: Logout page example as seen by user The message shows 1 access license out of 2500 in use and 0 CCU licenses out of 1500 in use. Session 87e8ee7d consumes the 1 license. Because this session does not include a remote access resource, it does not consume a CCU. Tip The license information in the previous example requires a minimal access policy. You can develop an automated script, but this process falls outside of the scope of this document. Logs Local database The local database records user session data, such as sessionid, virtual IP address, and client IP address. Note For BIG-IP 12.x and later, due to performance considerations F5 has removed the ability to adjust the amount of logs store in the logging database. The amount of data stored on the BIG-IP for review will depend on how much activity your device has and how verbose you have the logs set. F5 recommends that you use BIG-IQ or an external log collection tool that is compatible with syslog to collect logs for later review. To manage the general properties of the local database (BIG-IP 11.x ) 1. Navigate to Access Policy >> Reports : Preferences. 90

100 MANAGEMENT Logs 2. Configure the preferences: Write to Local Database (enabled by default) stores log files in the reporting log database on the BIG-IP system. BIG-IP APM reports use of the local database. If you disable this setting, reports are empty or include only data written to the local database before you disabled this setting. Log Rotation Period indicates the number of days before the local database logs rotate. Logging is available when you enable Write to Local Database. The allowed range is from 0-90 days. If set to 0 (default), logs are rotated based on the number of records configured in the Maximum Number of Log Entries option. Maximum Number of Log Entries indicates the maximum number of local database log records to store. It is available when you enable Write to Local Database. The oldest log records are deleted after the specified number of log records is reached. The allowed range is 100,000-5,000,000. Optimize for Reporting (disabled by default) improves reporting performance through the use of indexes on log data tables. Indexes improve the speed at which records are retrieved from the database at the expense of slowing down the speed at which records are written to the database. In some cases, when speed is prioritized it is preferable to disable indexes. To do this, click to deselect this option to disable indexes from the log data tables. Changes only take effect after restarting either logd or the BIG-IP APM system. Log Database Maintenance clears records from the local database when you click Delete. Write to APM Log File (enabled by default) stores logs to /var/log/apm. Because BIG-IP APM reporting uses the local database and the Maximum Number of Log Entries allows up to 5,000,000 entries, reporting on a heavily utilized BIG-IP APM system may be strictly limited. Important Local database entries can consume as much as 4 GB of disk space. The file system containing the local database (/var/lib/mysql) is limited to 12 GB total. Checking available free space using tools such as the df-h command or SNMP should be part of your routine maintenance schedule. High Speed Logging You may want to log additional data, such as when an access session starts or completes. Because excessive logging on the BIG-IP APM system can impair performance, you can use the High Speed Logging (HSL) feature to send logs to a remote logging server. HSL uses TMM for faster processing and bypasses the local syslog-ng instance altogether. This can yield a performance gain over normal logging by orders of magnitude. You must use irules to implement HSL on the BIG-IP APM system. You can associate an individual irule with the virtual server you configure with a BIG-IP APM access policy. For example, the following irule logs when an access session starts, completes, and closes, or it logs every HTTP request traversing the access policy: when RULE _ INIT { 91

101 MANAGEMENT Logs } ## user-defined: HSL pool set static::hsl _ POOL hsl _ pool ## user-defined: log ACCESS session start (0 off, 1 on) set static::access _ START 1 ## user-defined: log ACCESS session complete (0 off, 1 on) set static::access _ COMPLETE 1 ## user-defined: log ACCESS session requests (0 off, 1 on) set static::access _ REQUEST 1 ## user-defined: log ACCESS session closed (0 off, 1 on) set static::access _ CLOSED 1 ## user-defined: username session variable set static::access _ USER _ VAR session.logon.last.username when CLIENT _ ACCEPTED { } set hsl [HSL::open -proto UDP -pool $static::hsl _ POOL] when ACCESS _ SESSION _ STARTED { if { $static::access _ START } { HSL::send $hsl <190> ACCESS session started CLIENT:[IP::client _ addr] VS:[IP::local _ addr] ID:[ACCESS::session data get session.user.sessionid] } } when ACCESS _ POLICY _ COMPLETED { if { $static::access _ COMPLETE } { set user if { [ACCESS::session data get $static::access _ USER _ VAR] ne } { } set user User:[ACCESS::session data get $static::access _ USER _ VAR] HSL::send $hsl <190> ACCESS session complete CLIENT:[IP::client _ addr] VS:[IP::local _ addr]${user} ID:[ACCESS::session data get session.user. sessionid] RESULT:[ACCESS::policy result] } 92

102 MANAGEMENT SNMP Monitoring } when ACCESS _ ACL _ ALLOWED { if { $static::access _ REQUEST } { set user if { [ACCESS::session data get $static::access _ USER _ VAR] ne } { } set user User:[ACCESS::session data get $static::access _ USER _ VAR] HSL::send $hsl <190> ACCESS session request CLIENT:[IP::client _ addr] VS:[IP::local _ addr]${user} ID:[ACCESS::session data get session.user. sessionid] URI:[ } } when ACCESS _ SESSION _ CLOSED { if { $static::access _ CLOSED } { set user if { [ACCESS::session data get $static::access _ USER _ VAR] ne } { } set user User:[ACCESS::session data get $static::access _ USER _ VAR] set hsl [HSL::open -proto UDP -pool $static::hsl _ POOL] HSL::send $hsl <190> ACCESS session closed${user} ID:[ACCESS::session data get session.user.sessionid] } } This previous irule allows you to turn logging on and off for each individual event by setting the user defined static variables at the top to 1 (on) or 0 (off) and saving. Warning The previous code example may not be suitable for your configuration. You need to customize irules for your specific environment and thoroughly test them in a non-production environment before using them in production. SNMP Monitoring Simple Network Management Protocol (SNMP) is an industry-standard protocol that gives a standard SNMP management system the ability to remotely manage and monitor a device on the network. BIG-IP APM supports SNMP v1, SNMP v2c, and SNMP v3. SNMP can be used to monitor: 93

103 MANAGEMENT SNMP Monitoring BIG-IP APM sessions BIG-IP APM CCU sessions For more information on how to configure SNMP on BIG-IP, refer to Configuring SNMP in the Configuration Guide for BIG-IP Access Policy Manager. Note For information about how to locate F5 product guides, refer to K : Finding product documentation on AskF5. The following example highlights some of the BIG-IP APM SNMP OIDs of interest to monitor: Task OID Current Active Access Sessions ns Current In Progress Sessions ons Total of Allow Sessions Total of Denied Sessions Total CCU sessions ns Current CCU sessions ns F5-BIGIP-APM-MIB::apmAccessStatCurrentActiveSessio F5-BIGIP-APM-MIB::apmAccessStatCurrentPendingSessi F5-BIGIP-APM-MIB::apmAccessStatResultAllow F5-BIGIP-APM-MIB::apmAccessStatResultDeny F5-BIGIP-APM-MIB::apmGlobalConnectivityStatTotCon F5-BIGIP-APM-MIB::apmGlobalConnectivityStatCurCon All of the previously listed OIDs are counter values with output similar to the following: snmpwalk -v 2c -c public localhost F5-BIGIP-APM-MIB::apmAccessStatCurrentActiveSess ions The command output appears similar to the following example: F5-BIGIP-APM-MIB::apmAccessStatCurrentActiveSessions.0 = Counter64: 104 In this command output, note that 104 is the total current number of access sessions on this device. SNMP monitoring for general system health Because BIG-IP APM includes reporting and other activity occurring outside of BIG-IP TMOS, F5 recommends monitoring statistics related to general Linux system health, including disk and memory. This monitoring helps long-term trends, including potential problems before they can cause trouble. Monitoring parameters are available the same way as in normal Linux systems. If possible, use the native monitoring software s Linux template. If native monitoring software is not available, use the following monitoring procedures. To display disk monitoring information at the command line Type the following command: 94

104 MANAGEMENT AUTHENTICATION resource monitoring snmptable -v 2c -c public localhost HOST-RESOURCES-MIB::hrStorageTable To display system processes and per-process memory consumption at the command line Type the following command: snmptable -v 2c -c public localhost HOST-RESOURCES-MIB::hrSWRunTable snmptable -v 2c -c public localhost HOST-RESOURCES-MIB::hrSWRunPerfTable Monitoring these SNMP parameters together can help spot memory leaks in processes, or potential disk space consumption issues. Authentication resource monitoring The BIG-IP APM system can be configured to use a single authentication (AAA) server for authentication or a pool of AAA servers for high availability. Pools can be created for the following AAA resource types: RADIUS Active Directory LDAP Certificate Revocation List Distribution Point (CRLDP) TACACS+ A BIG-IP monitor should be assigned to the AAA pool in order to determine which servers are available to receive authentication requests. BIG-IP APM does not load-balance authentication requests between the pool members, but instead by the priority number assigned to the pool member. Authentication requests are serviced by the next highest priority pool member if the currently active server is unavailable. Tip Currently, only the gateway_icmp monitor is appropriate for monitoring AAA servers. Select this monitor from Server Pool Monitor when creating the AAA Server object. For more information on priority group activation and other pool related topics, refer to About Pools in BIG-IP Local Traffic Management: Basics. 95

105 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Access Programmability irules is a powerful and flexible BIG-IP feature, based on F5 TMOS architecture. irules provides you with unprecedented control to directly manipulate and manage any IP application traffic. Employing an easy-to-learn scripting syntax, irules can perform nearly any traffic function for network traffic passing through a BIG-IP system, including routing, re-routing, redirecting, inspecting, modifying, delaying, discarding, rejecting, and logging. irules and F5 support F5 provides basic support for existing irules. Support can assist with checking irules syntax, troubleshooting specific commands of irules functionality, and validating irules logic. irules must have been previously operating prior to contacting F5 support. F5 support does not provide concept, design, authoring, or creation of irules. DevCentral community DevCentral is an online developer community of more than 160,000+ F5 users worldwide who collaborate and share innovations, including code samples, new techniques, and other tips. DevCentral is also the home of the irules Wiki, the location of irules reference documentation and a great place to visit when you are getting started with irules. irules on demand and F5 Professional Services irules On-Demand supplies custom-developed irules to address the specific and unique needs of each customer. Visit the F5 Professional Services to review offerings. ACCESS irules Structure BIG-IP APM irules includes two primary components: access events and access commands. Access events irules events are programming structures triggered within the context of a certain state of a connection. With respect to a BIG-IP APM access session, events trigger at different stages of the access policy initiation, evaluation, completion, and termination. For example, when a user initiates a new access session, an event is triggered. When a user completes access policy evaluation, an event is triggered. Throughout policy evaluation and upon subsequent allowed access requests, events trigger. In this way, BIG-IP APM irules provides a robust mechanism for programmatically controlling nearly every aspect of the authentication and access process. The following figure shows access events in the context of access policy evaluation. 96

106 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Figure 9.1: Access irules event diagram In the previous figure: 1. The client browser or the BIG-IP Edge Client application makes an initial request to a BIG-IP APM virtual server. In that request, the client has no established session with BIG-IP APM and sends no session cookie. BIG-IP APM creates an access session and immediately redirect the client to a special /my.policy URI and sets the cookie, MRHSession, (pointer) for that access session in the redirect response. The ACCESS_SESSION_STARTED event is triggered. Information about the client and session are available here, including IP addresses, browser and client type, and session ID. 2. If an irule agent is found at any point in the access policy evaluation, the ACCESS_POLICY_AGENT_ EVENT event triggers. The ACCESS_POLICY_AGENT_EVENT allows access policy processing to move into an irules event that has full access to all of the session data collected up to that point. Note Multiple irules event agents can exist in an access policy. 3. At the end of access policy evaluation, the ACCESS_POLICY_COMPLETED event triggers. The ACCESS_POLICY_COMPLETED event has all of the information collected from the evaluation, as well as the result of policy evaluation (Allow or Deny). 4. After policy evaluation, and during all following requests, the ACCESS_ACL_ALLOWED event triggers. This ACCESS_ACL_ALLOWED has access to all of the session information collected from the evaluation, 97

107 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE as well as HTTP request information. This event can be thought of as an HTTP_REQUEST event triggers after a completed access policy. 5. HTTP_REQUEST events still trigger and may contain access session information. Take care to identify the HTTP_REQUEST before attempting to manipulate access session information. For example, an HTTP_REQUEST event triggers before the ACCESS_SESSION_STARTED event and before any ACCESS_ACL_ALLOWED event. The first HTTP_REQUEST event does not contain information about the evaluated policy and user while following HTTP_REQUEST events may contain that information. It is easier and safer to use the access events directly. F5 recommends that process rather than use of HTTP_ REQUEST events if possible. 6. During access policy evaluation, access to /my.policy URI is allowed. If access policy agents such as Logon Page and Message Box interact with the client, the HTTP_REQUEST event triggers but it is hidden by default. To unhide these events, use the ACCESS::restrict_irule_events command. Important Attempting to manipulate the access session in intermediate HTTP_REQUEST events may cause unexpected behavior. For more information, refer to the F5 DevCentral Access wiki. Note A DevCentral login is required to view this content. Access commands The access commands allow for direct manipulation of session and policy information during and after policy evaluation. irules such as the following example can be used to retrieve user log in information from the session and send that as an HTTP header to the server application on each HTTP request after policy evaluation. when ACCESS _ ACL _ ALLOWED { } set user [ACCESS::session data get session.logon.last.username ] insert X-USERNAME $user For more information, refer to the F5 DevCentral Access wiki. Session variables When an access session starts, data about the session begins to be collected in a discrete and secure message cache. As the policy evaluates, more information is stored in that cache. During access policy evaluation, if a decision has to be made, the system examines those collected session variables. Session variables have a hierarchical naming convention. For example: session.logon.last.username There is no restriction on the name itself and it isn t a member of an enumerable array. You can for example create a session variable named bob, but without the session prefix it does not show up in session reports. F5 recommends naming session variables in context to what they represent. The session.logon.last.username variable represents a username value, collected at log in by an agent like the Logon Page agent. 98

108 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE For more information, refer to Session Variables in BIG-IP Access Policy Manager: visual policy editor. Note For information about how to locate F5 product guides, refer to AskF5 article K : Finding product documentation on AskF5. Every policy agent is responsible for either creating session variables or evaluating them. You don t have to know anything about session variables to create or implement a typical access policy. However, the ability to access and manipulate session variables can be very useful when troubleshooting. Viewing access session variables There are a few different ways you can view created session variables: Use the Configuration utility with administator credentials. View access policy reports. Use sessiondump. View logs. View message boxes. Use irules. Viewing session variables for active user sessions F5 recommends viewing session variables using this method. To view session variables in access policy reports using the Configuration utility 1. Navigate to Access Policy >> Reports : View Reports. 2. Under Report Parameters, set a time period and click Run Report. 3. On the All Sessions tab, click the View Session Variables link for the report you want to view. Session variables for your report open in a new tab. The variables are presented in a hierarchical display. To view session variables in access policy reports using the Configuration utility (BIG-IP 13.0 and later) 1. Log in to BIG-IP APM with test user credentials. 2. Navigate to Access >> Overview >> Active Sessions. 3. Find the session ID for the test user account and click View Session Variables. Viewing session variables with sessiondump The sessiondump utility is a command line alternative you can use to view logs. The utility has a several available commands, including those listed in the following table. 99

109 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Table 9.1 sessiondump commands Command -list -allkeys <Session ID> Result Presents a short list of active sections, one session per line. Presents all session variables for all active sessions. Use sparingly on busy systems. Presents session variables for the session ID you enter. The session ID is an 8-character string. The following output shows the return syntax of the -allkeys sessiondump command. It may be large if you use it on a busy system. However, you can script it. For example, to display a list of all of the authenticated users, you can filter on the session.logon.last.username session variable using the grep -a command: sessiondump -allkeys grep -a session.logon.last.username config # sessiondump -allkeys 209b679c 10 SessionKey 209b679c.session.access.profile 27 /Common/simple-logon-policy 209b679c.session.access.profiletype b679c.session.assigned.uuid 41 tmm.uuid./common/simple-logon-policy.fred 209b679c.session.client.activex b679c.session.client.browscap _ info 87 uimode=0&ctype=mozillacversion b679c.session.client.cpu 7 unknown 209b679c.session.client.js b679c.session.client.platform 4 Win7 209b679c.session.client.plug-in b679c.session.client.type 7 Mozilla 209b679c.session.client.version b679c.session.createdfrom 6 ACCESS 209b679c.session.end 9 timed _ out 209b679c.session.ha _ unit 32 f883a0e5e79d00ec2480ef557b52ld0f 209b679c.session.inactivity _ timeout b679c.session.logon./Common/simple-logon-policy _ act _ logon _ page _ ag.logonname 4 fred 209b679c.session.logon./Common/simple-logon-policy _ act _ logon _ page _ ag.result b679c.session.logon./Common/simple-logon-policy _ act _ logon _ page _ ag.username 4 fred 209b679c.session.logon.last.logonname 4 fred 209b679c.session.logon.last.result

110 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE 209b679c.session.logon.last.username 4 fred 209b679c.session.logon.page.customization.group 45 /Common/simple-logonpolicy _ act _ logon _ page _ ag 209b679c.session.logon.page.errorcode b679c.session.policy.result 6 allow 209b679c.session.rest.clearcache b679c.session.rest.groupname 0 209b679c.session.requestdomain 0 209b679c.session.requesttype 0 209b679c.session.rest.username 0 209b679c.session.server.landiguri 1 / 209b679c.session.server.network.name 16 test.domain.com 209b679c.session.server.network.port b679c.session.snapshotid 32 71c _ 1oooooooooooooo 209b679c.session.state 6 allow 209b679c.session.stats.bytes.in b679c.session.stats.bytes.out b679c.session.stats.egress.compressed b679c.session.stats.egress.rav b679c.session.stats.ingress.compressed b679c.session.stats.packets.in b679c.session.stats.packets.out b679c.session.ui.lang 2 eng 209b679c.session.ui.mode b679c.session.user.agent 90 Mozilla/6.0 (Windows; U; wwindows NT 6.1; en-us rv: ) Gecko/ Firefox/ Viewing session variables in logs The visual policy editor contains a Logging agent that allows you to define a subset of session variables to capture in the BIG-IP APM log. You can add this agent into your access policy and then define it using the variable you re looking for. The Logging agent allows you to define a message in the Log Message field and a wildcard match on based on a hierarchy of variables. In the following example, a custom log is configured to capture session. logon.last.* variables created by the Logon Page policy agent. 101

111 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Figure 9.2: Access policy Logging agent Properties tab To view the log file at the command line Type the following command: tail -f /var/log/apm The contents of the BIG-IP APM log files stream. Log files may be large. You can filter the results using the grep command. For example, if you want to find the session.logon.last.logonname variable, you can to use the grep command to look for the variable that follows log message TEST. In this example, you would type the following command syntax: tail -f /var/log/apm grep -A4 TEST The TEST string occurs one line immediately preceding the session.logon.last.logonname so the -A4 portion of the input returns the TEST string as well as the four lines that follow it. badger1 notice apmd[11324] : :5: /Common/ap _ scratch: Common : a9aefbec: Logging Agent: TEST LOGGING AGENT badger1 notice apmd[11324] : :5: /Common/ap _ scratch: Common : a9aefbec: Following rule fallback from item Logging to ending Allow badger1 notice apmd[11324] : :5: /Common/ap _ scratch: Common : a9aefbec: Access policy result: LTM+APM _ Mode badger1 notice apmd[11324] : :5: /Common/ap _ scratch: Common : a9aefbec: Received client info - Hostname: Type: IE Version: 8 Platform: Win7 CPU: WOW64 UI Mode: Full JavaScript Support 1 Ac: You can use this method to target specific information. You can for example, capture data about user sessions and send that to a remote syslog-capable service like Splunk. Tip BIG-IP APM log messages are located in the /var/log/apm file. 102

112 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Viewing session variables with message boxes You can use Message Box policy agents to view session variables during troubleshooting. This is particularly useful if an access policy functions unexpectedly and you can t diagnose the source of the problem. You can insert one or more Message Box agents in the policy path to test the policy. If you want to refer to a specific value, or set of values, at given points, you can use the following syntax inside the Message Box agent: %{session.variable.name} Figure 9.3: Access policy Message Box agent Properties tab When the policy evaluation occurs, each Message Box triggers at its place in the policy path and displays the defined session variable. The following figure shows a sample of a message returned by the Message Box agent configured in the previous figure. Figure 9.4: Sample Message Box Viewing session variables using irules irules can read and write access session variables using the ACCESS::session data structure. The following command syntax shows an example of reading a session variable in a line of irules code: set user [ACCESS::session data get session.custom.user] 103

113 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Creating session variables You can create session variables using the Variable Assignment agent in the visual policy editor or using irules. Creating session variables with Variable Assignment agent The Variable Assignment agent supports creation of custom variables within its interface. In the following figure, the custom variable session.custom.user is defined with a text string bob. Figure 9.5: Access policy Variable Assignment agent Custom Variable An access session variable must be hierarchical, but the format is arbitrary. For example, a session variable named bob is not allowed but test.bob is. However, the first value must be session for it to show up in reports view. Therefore, session.bob or session.test.bob are allowed session variables and also shows up in the reports view. F5 recommends using the prefix session.custom when defining custom variables. The Variable Assignment agent also supports custom expressions. Custom expressions include AAA attributes, other session variables, and custom expressions, as shown in the following figure. Figure 9.6: Access policy Variable Assignment agent Custom Expression Creating session variables with irules The ACCESS::session data structure can also write session variables. The following example shows the command syntax for setting an access session variable (bob) in a line of irules code: ACCESS::session data set session.custom.user bob Using password session variables If they exist, password session variables display in masked format. The Variable Assignment agent and irules ACCESS::session construct can store values encrypted in the session database. The Logon Page agent automatically sets a field of type password as an encrypted session variable. To manually create a secure encrypted session variable using the Variable Assignment agent, select Secure. 104

114 ACCESS PROGRAmmABILITY ACCESS irules STRUCTURE Figure 9.7: Access policy Logon Page agent Secure Custom Variable To do the same with irules, use the -secure flag in the ACCESS::session command, as shown in the following example: ACCESS::session data set -secure session.custom.mypass secret The SSO Credential Mapping agent is responsible for decrypting a value from an encrypted session variable. It takes whatever encrypted session variable you re using for a password and sends a decrypted copy of that value to the session.sso.token.last.password session variable. Many of the BIG-IP APM SSO profiles use this new session variable for server-side authentication. You can do this using the -secure flag, as shown in the following example: session.custom.mypass = return [mcget -secure {session.logon.last.password}] Figure 9.8: Access policy SSO Credential Mapping agent Unsecure Custom Variable Once the previous command runs, the message cache contains a decrypted copy of the password. However, the session.sso.token.last.password variable still displays masked in reports. For more information on access session variables, refer to the F5 DevCentral Access wiki. Note A DevCentral login is required to view this content. 105

115 ACCESS PROGRAmmABILITY CHANGING policy behavior Changing policy behavior There are two ways to change policy behavior during access policy evaluation: using irules or using visual policy editor branch rules. irules In order to use irules in access policy evaluation, you must insert an irule Event agent. Figure 9.9: Access policy with irule event agent Inserting the irule Event agent triggers an ACCESS_POLICY_AGENT_EVENT event in the irule. The agent runs in the Traffic Management Microkernel (TMM) context to the renderer rather than from the client to BIG-IP APM. You can individually target multiple irule Event agents by evaluating the access policy agent_id access policy value and assigning a unique ID in each event agent. For example, in the following figure two irule Event agents exist in the policy, each configured with a unique ID defined under Custom irule Event agent. Figure 9.10: Access policy irule event agent In the irule code, perform an evaluation using the following command syntax: when ACCESS _ POLICY _ AGENT _ EVENT { switch [ACCESS::policy agent _ id] { EVENT1 { 106

116 ACCESS PROGRAmmABILITY CHANGING policy behavior } } } # do something here EVENT2 { } # do something else here In the previous example, the first irule Event agent has access to information collected from session initiation and the Logon Page agent. You can use this information to create or stage information for the upcoming LDAP authentication. The second irule Event agent contains information from the LDAP Auth agent, and you can use this information to create or stage information for the upcoming LDAP Query. Branch rules Access policy branch rules are written in Tcl command language and you can run them in the branch options of any visual policy editor agent. Branch rules are not the same as irules and do not contain irules protocol or other irules-specific commands. In any of the examples described in the irules section, agents having multiple output paths use using branch rules to determine the correct path. For example, the LDAP Authentication agent in the previous figure uses the following branch rule syntax by default to decide if it should follow the Successful or fallback path: expr { [mcget {session.ldap.last.authresult}] == 1 } Figure 9.11: LDAP authentication branch rules In addition, you can use branch rules to create custom expressions. In the following figure shows a branch rule in use as a custom expression. 107

117 ACCESS PROGRAmmABILITY CHANGING policy behavior Figure 9.12: Variable Assign agent custom expression Note The Custom Expression field is a simple text block. It optionally supports line breaks and spacing, although these are not recommended. Each line of code must end with a semicolon. The branch rule in the previous figure uses a custom expression to extract the userprincipalname (UPN) from a client certificate. The following is the branch rule command syntax: foreach x [split [mcget {session.ssl.cert.x509extension}] \n ] { if { [string first othername:upn $x] >= 0 } { return [string range $x [expr { [string first < $x] + 1}] [expr {string first > -1}]]; }; } return ; Branch rule syntax A branch rule includes several elements, including the mcget statement, the x509 extension, and the expr and return functions. Message cache get (mcget) statement The following is the command syntax of the mcget statement in the previous example: [mcget {session.ssl.cert.x509extension}] mcget allows access to session variables from inside branch rules. In this example, it returns the data inside the session.ssl.cert.x509extension variable. The data in the session populates when BIG-IP APM receives a client certificate. x509 extensions The x509 extensions are a long list of attributes separated by newline characters. You can break the list using the Tcl [split] command and then run through the list with a foreach loop. In each line of the x509 extensions, if the line contains othername:upn, use a set of string commands to extract 108

118 ACCESS PROGRAmmABILITY CHANGING policy behavior this value and return it. That returned value is assigned to the arbitrary session.ssl.cert.upn session variable. It is also defined on the left side of the Variable Assignment agent. If othername:upn is not found, the code returns. expr and return Each branch rule contains one or more expression (expr) or return commands. The expr command functions as a Boolean operator. When it returns true for an input value, the policy follows the branch. When it returns false, the policy follows the next available branch. This continues until the policy reaches the fallback branch. If more than one branch returns true, the first true policy path executes. The expr command is the same one used in Tcl math, so the following expression works: expr { 10/5 == 2 } You can use expr to output a value for variable assignment. For example: session.custom.count = expr { [mcget {session.custom.count}] + 1 } The return operator returns a values from the message cache using the mcget command: return [mcget {session.logon.last.username}] Empty agent Access policy branches typically contain a branch rules tab. On this tab, existing built-in branch rules or custom branch rules can add functionality to the policy. If branches need to be built outside an authentication or assignment, the Empty agent can be used. The Empty agent has no properties and no branches, and it can be configured to trigger and evaluate any policy condition for any reason. The following figure shows a sample configuration for an Empty agent. In this example, the agent is called DG Condition. Figure 9.13: Empty agent The DG Condition agent in this example contains three branch conditions to evaluate. The following figure shows the agent s configured branch rules. Each branch evaluates the session.custom.dgvalue session variable to test whether the condition is true or false, depending on the input. 109

119 ACCESS PROGRAmmABILITY CHANGING policy behavior Figure 9.14: Branch rules in an Empty agent The branches process in order, from top to bottom. If session.custom.dgvalue doesn t match the first branch, the policy processes the next available branch. If none return true, the policy processes the fallback branch. If multiple conditions are true, the policy follows the first branch it evaluates as true. For more information on branch rules, refer to: Tcl Usage in BIG-IP Access Policy Manager: visual policy editor. Branch rules vs. irules Branch rules and irules each have benefits and drawbacks. Circumstance and personal preference determines whether you use a branch rules or irules to manipulate access policy functionality. Branch rules have the advantage of being part of the access policy. If an access policy is exported, the branch rules are automatically included, while irules must be exported separately. irules can be employed in place of a branch expression, except for agent branch path evaluation. In most cases the irules is simpler and cleaner to use than branch rules, as shown in the following command syntax. Taking the branch rule expression from above, foreach x [split [mcget {session.ssl.cert.x509extension}] \n ] { if { [string first othername:upn $x] >= 0 } { return [string range $x [expr { [string first < $x] + 1}] [expr {string first > -1}]]; }; } 110