BIG-IP APM Operations Guide - AskF5

BIG-IP APM Operations Guide - AskF5
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.
A message from Julian Eames, Chief Operations Officer and Executive Vice
President, F5 Business Operations
Welcome to the F5 Operations Guide series.
Our series of operations guides address real-world scenarios and challenges. The content was written by
the engineers who design, build, and support our products, as well as other F5 professionals—some
former customers worked in the field and have firsthand experience.
While no document can anticipate every question or situation, F5 endeavors to provide a better
understanding of your BIG-IP system and offer tools needed to address common issues and conditions.
In this guide you’ll find recommendations, practices, and troubleshooting tips to keep your F5 products
running at peak efficiency and elements that may be incorporated into your own run books.
F5 is pleased to offer industry-leading products and services, including world-class support, and
welcomes your suggestions and feedback. Let us know how we can better serve you.
—Julian Eames
CONTENTS—
Contents
About This Guide
1
Before using this guide
1
Limits of this guide
1
Glossary2
Customization2
Issue escalation
2
Feedback and notifications
3
Configuration utility
3
Command-line syntax
3
Finding other documents
4
Introduction5
BIG-IP APM features
5
Client interaction with BIG-IP APM
7
BIG-IP APM with other BIG-IP modules
8
Licenses10
BIG-IP APM license types
10
License limits
12
BIG-IP APM Lite
13
Use Cases
14
Authentication and Single Sign-On
14
Network Access
20
Per-Application VPN
23
Application tunnel
24
Web Access Management
27
Portal Access
29
Citrix integration
32
VMware View support
35
Exchange proxy
36
Webtop39
ACLs40
iii
CONTENTS—
Step-up authentication
41
Forward proxy
44
OAuth authorization
45
BIG-IP Edge Client
48
Client Types
48
VPN client types
49
Remote Desktop Protocol and Remote App Support
51
Features51
Components51
Implementation51
General RDP FAQ
54
RDP load balancing FAQ
55
IPv6 FAQ
56
Client requirements
57
Troubleshooting RemoteAPP and Remote Desktop
58
RDG-RAP access policies
68
Logging69
Security71
Session management
71
Identity access management
75
Network Security
76
Auditing77
High Availability
78
BIG-IP APM failover components
78
High availability
79
Policy Sync
81
High availability on VIPRION
81
Management86
License usage monitoring
86
Logs89
SNMP Monitoring
92
Authentication resource monitoring
94
iv
CONTENTS—
Access Programmability
95
iRules and F5 support
95
DevCentral community 95
iRules on demand and F5 Professional Services
95
ACCESS iRules Structure
95
Changing policy behavior
105
Clientless mode
110
Troubleshooting113
Configuration and compatibility checks
113
Network access issues
117
Application tunnel issues
119
Authentication issues
121
Web Access Management issues
125
Portal Access issues
127
Per-Application VPN issues
128
SSO issues
129
NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO troubleshooting
132
Tools and utilities
134
Collecting BIG-IP APM Data for Support
137
Logging (BIG-IP 12.0 and later)
137
Network captures
138
Optimizing the Support Experience
148
F5 technical support commitment
148
F5 certification
149
Self-help150
F5 training programs and education
153
Engage F5 Support
153
Legal Notices
161
Trademarks161
Patents161
Notice161
Publication Date
162
v
CONTENTS—
Copyright162
Change List
163
vi
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
11
Figure 3.1: Pre-authentication and SSO 15
Figure 3.2: BIG-IP APM client identification.
16
Figure 3.3: BIG-IP APM as an authentication gateway
17
Figure 3.4: Establishing a VPN tunnel 22
Figure 3.5: Per-App VPN tunnel packet flow
24
Figure 3.6: Application tunnel packet flow
26
Figure 3.7: Web Access Management packet flow
28
Figure 3.8: Portal Access packet flow
30
Figure 3.9: BIG-IP APM as authentication proxy for SSO on Citrix Web Interface
33
Figure 3.10 BIG-IP APM integration with Citrix XML broker
34
Figure 3.11 Exchange proxy packet flow 38
Figure 3.12 Sample BIG-IP full webtop
40
Figure 3.13: Step-up authentication in use between the client and server
43
Figure 3.14: BIG-IP APM as a forward proxy
45
Figure 3.15: BIG-IP APM as an OAuth authorization server
47
Figure 5.1: Full webtop with two resources
59
Figure 5.3: Default Microsoft RD Web from Terminal Server’s IIS
65
vii
FIGURES—
Figure 5.4: Microsoft RD Web terminal server RemoteApp portal page
65
Figure 7.1: BIG-IP APM failover 80
Figure 7.2: Standalone VIPRION cluster with all blades online
82
Figure 7.3: Standalone VIPRION cluster with blade 2 offline. No user sessions are lost.
83
Figure 7.4: Active-standby VIPRION device group with all blades online
84
Figure 7.5: Active-standby VIPRION device group with Blade 2 on VIPRION A offline
85
Figure 8.1: Variable Assign access policy agent used to collect license usage
87
Figure 8.2: Branch rules in Variable Assign agent collect license usage information in session variables 88
Figure 8.3: Logout page error message configuration
88
Figure 8.4: Logout page example as seen by user
89
Figure 9.1: Access iRules event diagram
96
Figure 9.2: Access policy Logging agent Properties tab
101
Figure 9.3: Access policy Message Box agent Properties tab 102
Figure 9.4: Sample Message Box 102
Figure 9.5: Access policy Variable Assignment agent Custom Variable
103
Figure 9.6: Access policy Variable Assignment agent Custom Expression
103
Figure 9.7: Access policy Logon Page agent Secure Custom Variable
104
Figure 9.8: Access policy SSO Credential Mapping agent Unsecure Custom Variable
104
Figure 9.9: Access policy with iRule event agent
105
Figure 9.10: Access policy iRule event agent 105
Figure 9.11: LDAP authentication branch rules
106
Figure 9.12: Variable Assign agent custom expression
107
viii
FIGURES—
Figure 9.13: Empty agent
108
Figure 9.14: Branch rules in an Empty agent
109
Figure 9.19: Clientless mode protocol flow
111
Figure 10.1: Access policy using Logon Page and AD Auth policy agents
116
ix
TABLES—
Tables
Table 0.1 Command-line syntax
3
Table 2.1 License requirements by resource type
12
Table 3.1 Client-side and server-side authentication method support matrix
19
Table 3.2 Network access features
20
Table 5.1 RDP Deployment Methods
52
Table 9.1 sessiondump commands
99
x
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
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
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, email opsguide@f5.com.
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
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: K12453464: Finding product
documentation on AskF5.
4
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. Access profiles can be configured 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 K12453464: 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
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. The elements used 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
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
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 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
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,
https://desktop.example.com) 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, RADIUS, HTTP, or LDAP.
BIG-IP ASM
You can use BIG-IP ASM and BIG-IP APM together to track sessions using authentication provided by a BIGIP 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. Any traffic you want to block must be explicitly specified. 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
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. 9
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 K12453464: 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. 10
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
11
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 K15624537: 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
Microsoft Desktop Client (Java or
Plug-in)
No
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
Profile)
No
WebAuth
No
Oracle OAM
No
SAML Resource on Webtop
No
OAuth
No
Application Access (Port
Forwarding)
Other
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]
12
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 following error message is logged to /var/log/apm:
warning tmm1[10186]: 01490508:4: 00000000: Global concurrent access session
limit reached.
•
The user is redirected to the login page, which displays the following error message:
The maximum number of concurrent user sessions has been reached. No new
user sessions can start at this time.
BIG-IP APM Lite
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.
13
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.
14
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 NTLM credentials to BIG-IP APM for access. You can configure the access policy so that, on leaving
the corporate environment, it enforces different or additional authentication methods, such as client certificate or
one-time passcode. It can also insert additional endpoint posture checking like antivirus and system service
15
USE CASES—Authentication and Single Sign-On
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 PKI certificate to serverside 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.
16
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
•
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:
17
USE CASES—Authentication and Single Sign-On
•
Active Directory authentication and query
•
LDAP and LDAPS authentication and query
•
RADIUS
•
TACACS
•
OCSP and 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 K12453464: 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
•
Kerberos
18
USE CASES—Authentication and Single Sign-On
•
HTTP Basic
•
HTTP Form
•
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
SAML1
No
No
No
Yes
Yes
Yes
Yes
Yes
No
2
No
2
No
2
No
2
No
2
No
2
RSA SecurID
No
2
One-Time
Passcode
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
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.
19
USE CASES—Network Access
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
Description
Compression
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.
Forward error
correction
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.
SNAT selection
Network access uses flexible mechanisms to choose source-NAT addresses based
(from policy or NA on access policy parameters. Generally SNAT is disabled to support VoIP and
resource)
improve reliability of SMB similar protocols.
Routing domains
Provide the capability to segment network traffic and define separate routing paths
for different network objects and applications.
Bandwidth
controller policy
Allows for static or dynamic bandwidth control per user.
ACLs
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.
Application launch
For more information, refer to AskF5 article: K11464: Launching applications in
Network Access connections using dynamic parameters.
Reconnect to
domain
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.
Drive mapping
Allows for network drives to map after establishing the Network Access connection.
On-demand VPN
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.
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
For more information, refer to AskF5 article: K11312: Creating network access with
single-sign on capabilities
20
USE CASES—Network Access
Feature
Proxy support
Description
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
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:
21
USE CASES—Network Access
• 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
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
22
USE CASES—Per-Application VPN
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 2.0.1+ for L3 and Per-App VPN
Note Per-App VPN functionality is supported on iOS and Android Edge Clients version 2.0.7 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.
23
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.
24
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 http://%host%/application 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.
25
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.
26
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.
27
USE CASES—Network Access
Figure 3.7: Web Access Management packet flow
28
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.
29
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:
https://apm/f5-w-<hex 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
30
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.
31
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.
32
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 BIGIP APM webtop.
33
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.
34
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
35
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 email. 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.
36
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. 37
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.
38
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.
39
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.
40
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
41
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.
42
USE CASES—Step-up authentication
Figure 3.13: Step-up authentication in use between the client and server
43
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:
44
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.
45
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.
46
USE CASES—OAuth authorization
Figure 3.15: BIG-IP APM as an OAuth authorization server
47
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 K12453464: 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.
48
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.
49
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
50
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.
51
REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT—Implementation
Table 5.1 RDP Deployment Methods
Method
Remote Desktop Session
Host, Client Type Native
Description
Provides access to Remote Desktops.
Targets can be dynamic or static.
Provides access to RemoteApp
Remote Desktop Web
resources published from Terminal
Access, Client Type Native
Services.
Connect
with*
Browser
Introduced
All
Any
13.0
All
Any
13.0
Remote Desktop Session
Host, Client Type ActiveX
Provides access to Remote Desktops.
The client uses the ActiveX control as
the RDP client.
Windows
Internet
Explorer
10.x
Remote Desktop Session
Host, Client Type Java
Provides access to Remote Desktops.
BIG-IP APM implements client as Java
applet.
All
Any
10.x
Application Tunnel for
Microsoft Terminal
Services Client (MSTSC)
Provides TCP/IP connections from
client to network.
Browser,
then
MSTSC
Any
10.x
RD Gateway
Enables authorized remote users to
connect to internal network from any
device that can run Remote Desktop
Connection (RDC) client
All
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 K12453464: 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 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
52
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.
53
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 K12453464: 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
54
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.
55
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 (1.2.3.4%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.
56
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
Unable
cannot
Please
to download myrd _ appaccess from <host>.
to open this Internet site. The requested site is either unavailable or
be found.
try again.
57
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 2012.
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]: 01490500:5: /Common/portal _
test:Common:b0a2d1b1: New session from client IP 172.18.43.222 (ST=/CC=/C=) at
VIP 10.11.10.75 Listener /Common/user _ 130 _ 75 (Reputation=Unknown)
58
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]: 01490008:5: /Common/portal _
test:Common:b0a2d1b1: Connectivity resource ‘/Common/rdpresource’ assigned
Aug 4 15:24:46 current-2 notice apmd[7433]: 01490128: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]: 01490102: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]: 01490000: {54b.C.} New ‘APM Webtop’
request from 172.17.2.164:52664 to 10.11.10.75:443
4. 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
59
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: <Publisher>
Type:
Remote Desktop Connection
Remote computer
<Remote computer>
Gateway server:
<Gateway server>
60
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/1.1 200 OK
<RDP data goes here>
61
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 0 74
41af90926b470f7f40dfd75746d135ae|/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
62
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]: 01490000: {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]: 01490000: {587.S.a3ae6c99} <-
63
REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT—Troubleshooting RemoteAPP and Remote Desktop
Payload[46]
Aug 10 20:05:01 current-2 debug vdi[11172]: 01490000: {587.S.a3ae6c99} <Payload[46]
Aug 10 20:05:01 current-2 debug vdi[11172]: 01490000: {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:
https://apm.example.com/f5vdi/rdp/icon/Common/lab _ 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:
64
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.
65
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
66
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:
67
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 11.6 - 12.1, 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 157.60.0.1).
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 10.10.80.43:3389
Note No RDG policy specified
68
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]: 01490000: {593.S.f9c8bdbc} Error reported
for an outgoing connection
Aug 10 20:12:33 current-2 info vdi[11172]: 01490000: {593.S.f9c8bdbc} Error reported
69
REMOTE DESKTOP PROTOCOL AND REMOTE APP SUPPORT—Logging
on initiated outgoing connection.
Aug 10 20:12:33 current-2 notice vdi[11172]: 01490000: {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
70
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 - 11.6, 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. 12.0 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]: 01490576: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]: 01490576: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]: 01490576:5: /Common/
allow2:Common:2d390958 Session invalidated due to scope type mismatch
(expected ‘profile’, got ‘global’).
71
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 11.2.0 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. Disable automatic rotation of BIG-IP APM session IDs by typing 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.
72
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=d896020385383db9ece7ac6d41f45923; 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
73
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
• RADIUS
• SecurID
• 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 K12453464: Finding
product documentation on AskF5.
74
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.
75
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
76
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.
77
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 K12453464: 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
78
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
79
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).
80
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.
81
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.
82
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. 83
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.
84
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.
85
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 K12453464: 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.
86
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.
87
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
88
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. To manage the general properties of the local database
1. Navigate to Access Policy >> Reports : Preferences. 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.
89
MANAGEMENT—Logs
•
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,0005,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 {
## user-defined: HSL pool
set static::HSL _ POOL “hsl _ pool”
## user-defined: log ACCESS session start (0 off, 1 on)
90
MANAGEMENT—Logs
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]”
}
}
when ACCESS _ ACL _ ALLOWED {
if { $static::ACCESS _ REQUEST } {
91
MANAGEMENT—SNMP Monitoring
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:[HTTP::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:
• BIG-IP APM sessions
• BIG-IP APM CCU sessions
92
MANAGEMENT—SNMP Monitoring
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 K12453464: 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
F5-BIGIP-APM-MIB::apmAccessStatCurrentActiveSessio
Current In Progress Sessions
ons
F5-BIGIP-APM-MIB::apmAccessStatCurrentPendingSessi
Total of Allow Sessions
F5-BIGIP-APM-MIB::apmAccessStatResultAllow
Total of Denied Sessions
F5-BIGIP-APM-MIB::apmAccessStatResultDeny
Total CCU sessions
ns
F5-BIGIP-APM-MIB::apmGlobalConnectivityStatTotCon
Current CCU sessions
ns
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:
snmptable -v 2c -c public localhost HOST-RESOURCES-MIB::hrStorageTable
93
MANAGEMENT—Authentication resource monitoring
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
• 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. 94
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.
95
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,
96
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”]
HTTP::header 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.
97
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 K12453464: 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.
98
ACCESS PROGRAMMABILITY—ACCESS iRules Structure
Table 9.1 sessiondump commands
Command
Result
-list
Presents a short list of active sections, one session per line.
-allkeys
Presents all session variables for all active sessions. Use sparingly on busy systems.
<Session ID>
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 1 0
209b679c.session.assigned.uuid 41 tmm.uuid./Common/simple-logon-policy.fred
209b679c.session.client.activex 1 0
209b679c.session.client.browscap _ info 87 uimode=0&ctype=Mozillacversion- . . . .
209b679c.session.client.cpu 7 unknown
209b679c.session.client.js 1 1
209b679c.session.client.platform 4 Win7
209b679c.session.client.plug-in 1 1
209b679c.session.client.type 7 Mozilla
209b679c.session.client.version 1 5
209b679c.session.createdfrom 6 ACCESS
209b679c.session.end 9 timed _ out
209b679c.session.ha _ unit 32 f883a0e5e79d00ec2480ef557b52ld0f
209b679c.session.inactivity _ timeout 3 500
209b679c.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 1 1
209b679c.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 1 1
99
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 1 0
209b679c.session.policy.result 6 allow
209b679c.session.rest.clearcache 1 0
209b679c.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 2 60
209b679c.session.snapshotid 32 71c39630815 _ 1oooooooooooooo
209b679c.session.state 6 allow
209b679c.session.stats.bytes.in 1 0
209b679c.session.stats.bytes.out 1 0
209b679c.session.stats.egress.compressed 1 0
209b679c.session.stats.egress.rav 1 0
209b679c.session.stats.ingress.compressed 1 0
209b679c.session.stats.packets.in 1 0
209b679c.session.stats.packets.out 1 0
209b679c.session.ui.lang 2 eng
209b679c.session.ui.mode 1 0
209b679c.session.user.agent 90 Mozilla/6.0 (Windows; U; wWindows NT 6.1; en-US
rv:1.9.2.13) Gecko/20101203 Firefox/3.6.11
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.
100
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 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] : 01490143:5: /Common/ap _ scratch: Common :
a9aefbec: Logging Agent: TEST LOGGING AGENT
badger1 notice apmd[11324] : 01490143:5: /Common/ap _ scratch: Common :
a9aefbec: Following rule ‘fallback’ from item ‘Logging’ to ending ‘Allow’
badger1 notice apmd[11324] : 01490143:5: /Common/ap _ scratch: Common :
a9aefbec: Access policy result: LTM+APM _ Mode
badger1 notice apmd[11324] : 01490143: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.
101
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
syntax shows an example of reading a session variable in a line of iRules code:
set user [ACCESS::session data get session.custom.user]
102
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 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.
103
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.
104
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 syntax:
when ACCESS _ POLICY _ AGENT _ EVENT {
switch [ACCESS::policy agent _ id] {
“EVENT1” {
105
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.
106
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 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 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
107
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.
108
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 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}]];
}
};
109
ACCESS PROGRAMMABILITY—Clientless mode
return “”;
the same functionality can be performed with iRule as below:
if { [ACCESS::session data get session.ssl.cert.x509extension] contains
“othername:UPN<” } {
set upn [findstr [ACCESS::session data get session.ssl.cert.x509extension]
“othername:UPN<” 14 “>”]
}
The iRule skips the foreach loop and directly extracts the string contents with an iRules findstr command.
Clientless mode
Clientless mode refers to an endpoint which doesn’t use a standard web browser style client. This client may not
support HTTP cookies, may not follow HTTP redirects or may not have a way to collect user input. These clients
may include Citrix receivers, ActiveSync clients, Outlook Anywhere, or other customized web applications or web
services.
In a normal Web Access Management/LTM-APM session, the first request meet with a redirect to /my.policy and
a Set-Cookie with the initial MRHSession token. Subsequent requests flow between the client and BIG-IP APM
while the system evaluates the access policy. At the end of that evaluation, if the session is allowed, a final redirect
sends the client back to the originally requested URI.
Clientless mode disables these redirects and adds the MRHSession token in the first response from the
application instead of the initial redirect to /my.policy. Any subsequent requests from the client uses the same
session if the client sends back the session cookie. If the client does not send back the session cookie, then a new
BIG-IP APM session is created for each request. The existing sessions are removed based on the timeout settings
in the access policy. The access policy Logon Page agent extracts inputs from the request headers or body. No additional input is
collected from the user during access policy evaluation. Therefore, you cannot use any agents which interrupt the
flow of traffic. Access policy agents requiring user input are ignored. These include Logon Page, End Point
Security, Message Box, Decision Box, and others.
110
ACCESS PROGRAMMABILITY—Clientless mode
Figure 9.19: Clientless mode protocol flow
Use iRules to enable clientless mode
Clientless mode can be enabled with an iRule by inserting a clientless-mode header with the HTTP::header
command.
when HTTP _ REQUEST {
HTTP::header insert “clientless-mode” 1
}
Clientless mode limitations
Clientless-mode does not support the following:
•
Logon Page retry
•
Password change
•
Two factor (challenge/response based) authentications
•
Multi-domain SSO
•
On-demand client certificate
111
ACCESS PROGRAMMABILITY—Clientless mode
APM maxrequestbodysize
In clientless mode, the initial request from the client (POST or GET) must be buffered into memory on BIG-IP APM.
Because of this, the default limit on client HTTP request is 64KB. This is adjustable by setting the tmm.access.
maxrequestbodysize DB variable to the expected maximum number of bytes (up to 3MB). This may increase
memory consumption if many large incoming requests are handled. This condition only applies to requests that
are transmitted to BIG-IP APM without a valid session cookie. Once the session is established, BIG-IP APM does
not need to buffer the client request and the problem does not happen.
HTTP_REQUEST configuration
If the clientless mode client must present credentials to gain access, such as a certificate or username/password,
the HTTP_REQUEST event must be configured to happens before the access session starts. The first HTTP_
REQUEST event do not contain an MRHSession cookie. For client certificate, select the request or require option
in the Client Authentication section of the client SSL profile. 112
TROUBLESHOOTING—Configuration and compatibility checks
Troubleshooting
This chapter details troubleshooting methods for several of the most commonly reported issues with BIG-IP®
APM® and includes references to existing support documentation for detailed procedures and information. If your
issue is not included, you can check other F5® self-help methods covered in “Optimizing the Support Experience”.
If there are configurations or issues you would like to see covered in future versions of this guide, send your
detailed request by email to opsguide@f5.com.
Configuration and compatibility checks
Start with the following checks when troubleshooting your BIG-IP APM system.
NTP and DNS
Make sure that DNS and NTP are working as intended. These functions are critical to proper operation of
authentication, high-availability synchronization, and other services in BIG-IP APM.
For more information, refer to General Configuration Properties in BIG-IP System: Essentials.
Note For information about how to locate F5® product guides, refer to AskF5 article K12453464: Finding
product documentation on AskF5.
Client compatibility
Make sure that you are using a client that your version of BIG-IP APM supports. To find information regarding
supported clients for each version of BIG-IP APM, refer to the Client Compatability Matrix for your version.
Note If your version is a point release (11.5.2, for example), a Client Compatibility Matrix may not be
available. If not, look on the support page for the previous version.
Connectivity checks
Continue general troubleshooting by checking connectivity.
Data and control plane troubleshooting
Traffic passes through two planes of the BIG-IP APM system: the Traffic Management Microkernel (TMM) and the
control plane (Linux). This means that data passing through the control plane may not necessarily be the same
data that passes through the data plane. For example, a ping to a server-connected VLAN from the Configuration
utility uses the control plane. The control plane may have access to the server, but if there is no connectivity from
the data plane, application traffic fails. F5 recommends using tcpdump or a BIG-IP LTM® monitor to verify that the BIG-IP data plane has the necessary
and correct routing information.
Virtual server connectivity
Make sure that the initial client requests arrive at the virtual server. One way to confirm this is to check a BIG-IP
session report for username or client IP of the local client.
113
TROUBLESHOOTING—Configuration and compatibility checks
To run a session report using the Configuration utility
•
Navigate to Access Policy >> Reports : Run Report.
If client requests do not arrive at the virtual server, refer to Virtual Server Troubleshooting in F5 Local Traffic
Manager and Global Traffic Manager Operations Guide.
Session timeouts
Session timeouts can cause issues. A BIG-IP APM session may terminate for various reasons, including a timeout.
Sessions can time out before the access policy completes, based on the Access Policy Timeout specified by the
policy configuration.
Sessions can also time out if they exceed a specified total session lifetime as defined by Maximum Session
Timeout.
BIG-IP APM automatically configures default timeout settings for each access profile. You can modify these
settings.
To modify timeout settings in the Configuration utility
1. Navigate to Access Policy >> Access Profiles.
2. Select the profile to be modified. 3. In Settings, modify timeout values.
4. Click Update.
Log file checks
You can use log files to troubleshoot access policy evaluation.
You can view log messages about the access policy evaluation as it follows each policy agent and event.
To view the BIG-IP APM log messages at the command line
•
Type the following command:
tail -f /var/log/apm
Tip BIG-IP APM log messages are located in the /var/log/apm file.
Logging (BIG-IP 12.0 and later)
In BIG-IP versions 11.x - 11.6, logging settings are global for all access profiles. In BIG-IP version 12.0 and later,
each access profile is attached to a logging profile. This means that you can set log levels per access profile,
allowing greater flexibility in logging.
Note If you find during troubleshooting that an access profile is not logging events as desired, verify that it
has the appropriate Log Setting attached.
114
TROUBLESHOOTING—Configuration and compatibility checks
Default log settings
Access policy event log settings establish a minimum log level for access policy, per-request policy, SWG URL
filtering activities, and so on. The upgrade creates a default log setting, default-log-setting. In this setting, the
access policy logging is enabled, the apm_general_logging log publisher is specified, and the default minimum
log level Notice is specified for each object. The upgrade adds the default-log-setting log setting to every access
profile.
Upgrade result and post-upgrade configuration
The local logging (to the database or syslog) configured prior to upgrade remains configured for access policy
events by default. Also, any time an access profile is created, the default-log-setting log setting is attached to it.
You can remove it, replace it, or add other log settings to the access profile. For flexibility and redundancy, up to
three log settings that specify access policy logging can be added to an access profile.
Note To take advantage of remote high-speed logging, you must configure remote HSL destinations along
with a pool of logging servers.
Disposition of log messages from the previous release
In BIG-IP 12.0 and later, none of the log messages stored in the local database are carried over. The new database
structure does not support the old log message format.
Changing logging levels (BIG-IP versions v. 11.x - 11.6)
To use log messages for troubleshooting, you may need to change the BIG-IP APM log level to debug. This setting
provides more complete messages.
Important Logging at the debug level creates large log files which may lower performance. Once you are
finished troubleshooting, you need to return the logging level (Notice).
To enable additional Access Policy logging using the Configuration utility
1. Navigate to System >> Logs : Configuration : Options : Access Policy.
2. In the Access Policy Logging section, for Access Policy, SSO, Portal Access, and VDI, select
Debug.
3. Click Update.
Tip To return to default logging level, set each item to Notice.
To enable additional logging using tmsh at the command line
•
Type the following commands:
tmsh modify sys db log.accesscontrol.level { value “debug” }
tmsh modify sys db log.sso.level { value “debug” }
tmsh modify sys db log.webapplications.level { value “debug” }
115
TROUBLESHOOTING—Configuration and compatibility checks
tmsh modify sys db log.vdi.level { value “debug” }
To disable additional logging using tmsh at the command line
•
Type the following commands:
tmsh modify sys db log.accesscontrol.level { value “notice” }
tmsh modify sys db log.sso.level { value “notice” }
tmsh modify sys db log.webapplications.level { value “notice” }
tmsh modify sys db log.vdi.level { value “notice” }
Access policy evaluation log messages
The following figure shows the visual policy editor view of an access policy applied to a BIG-IP virtual server. Figure 10.1: Access policy using Logon Page and AD Auth policy agents
Tip Each log message contains a session ID, which you can use to identify a particular session when
filtering large log files.
When a user first connects to the virtual server with the access policy shown in the previous figure, a new BIG-IP
APM session log message is created, which appears similar to the following:
notice tmm[23456]: 01490500:5: 4da2e357: New session from client IP 172.17.2.157 (ST=/
CC=/C=) at VIP 172.24.102.83 Listener /Common/testvip
In this example, the session is assigned session ID 4da2e357.
Following the policy from Start, the next log message in the BIG-APM log file appears similar to the following:
info apd[1234]: 01490006:6: 4da2e357: Following rule ‘fallback’ from item ‘Start’ to
item ‘Logon Page’
This message shows that the user was presented a BIG-IP APM login page by the Logon Page agent.
If the user attempted to log in, log messages similar to the following appear:
notice apd[1234]: 01490010:5: 4da2e357: Username ‘administrator’
info apd[1234]: 01490006:6: 4da2e357: Following rule ‘fallback’ from item ‘Logon
Page’ to item ‘AD Auth’
info apd[1234]: 01490005:5: 4da2e357: Following rule ‘Successful’ from item ‘AD Auth’
to ending ‘Allow’
For BIG-IP version 12.0 and later, the syntax appears similar to the following:
116
TROUBLESHOOTING—Network access issues
notice apmd[11324]: 01490010:5: /Common/ap _ scratch:Common:7825458b: Username
‘viewuser1’
err apmd[11324]: 01490107:3: /Common/ap _ scratch:Common:7825458b: AD module:
authentication with ‘viewuser1’ failed: Clock skew too great, principal name:
viewuser1@SERVICES.LOCAL. Please verify current time and configuration. Time skew
must be less than 5 minutes. (-1765328347)
notice apmd[11324]: 01490005:5: /Common/ap _ scratch:Common:7825458b: Following rule
‘fallback’ from item ‘AD Authentication’ to ending ‘Deny’
notice apmd[11324]: 01490102:5: /Common/ap _ scratch:Common:7825458b: Access policy
result: Logon _ Deny
Note the addition of the word “profile” to the strings.
These log messages show that BIG-IP APM successfully authenticated the user administrator and allowed
access to the target resource.
The first log message shows that the BIG-IP APM system received a login attempt from user with the
username administrator.
The second log message shows that the policy followed the fallback branch to the Logon Page policy agent.
That agent received valid information and the access policy then followed the fallback branch to the AD
Auth agent. The AD Auth agent in this example took the username and password stored in the session cache and
verified it against an Active Directory AAA resource configured in it. The third log message shows that the AD Auth agent executed successfully. This completes the access policy
evaluation. The path followed the Successful branch and terminated at Allow.
Network access issues
When issues with BIG-IP APM Network Access arise, check the BIG-IP APM log messages to see whether or not
the Network Access resource at issue is correctly assigned and started.
Tip BIG-IP APM log messages are located in the /var/log/apm file.
Log message troubleshooting
The following list shows sample message logs indicating successful evaluation of various Network Access
resources actions. Messages on your system vary but should look similar to these.
•
Log message indicating network resource was successfully assigned:
notice apd[12025]: 01490008:5: e0401776: Connectivity resource ‘/Common/test _
network _ access’ assigned
•
Log message indicating that an IP address has been assigned:
notice tmm3[16234]: 01490549:5: e0401776: Assigned PPP Dynamic IPv4: 10.40.10.9
Tunnel Type: VPN _ TUNNELTYPE _ TLS NA Resource
•
Log message indicating that the PPP tunnel was correctly started:
notice tmm3[16234]: 01490505:5: e0401776: PPP tunnel 0x5700dd101400 started.
117
TROUBLESHOOTING—Network access issues
•
Log message confirming that the maximum number of access sessions has not been reached:
warning tmm[16234]: 01490509:4: d8330ccb: Concurrent user sessions limit reached
for access profile: /Common/test _ access _ policy
Note The Max Sessions Per User setting in an access profile periodically terminates older sessions.
If your logs show no errors and the client is not able to establish a tunnel, continue troubleshooting from the
perspective of the client.
Client-side troubleshooting
Note These troubleshooting options are only available on Windows client systems.
The following procedures check common issues associated with establishing Network Access and the Windows
BIG-IP Edge Client from the client perspective.
Privilege troubleshooting
Several BIG-IP Edge Client® components require elevated privileges to install and function properly. If a user
without local administrator privileges experiences an issue, you can test whether the privileges assignment is the
problem.
To test whether or not privileges are the cause of an issue
1. Log in to the client system experiencing the trouble using an account with local administrator
privileges.
2. Attempt to reproduce the issue on the client system.
If you cannot reproduce the issue, it is possible that the cause is insufficient Windows privileges
for non-administrator accounts.
To test administrative privileges
1. Assign local administrator privileges to the user’s account on the client system.
2. Install all required BIG-IP Edge Client components and the component installer service on the
client system. If the components do not install correctly, the problem may not be a privileges issue but may
originate from the user’s machine. To test whether the issue is machine-related
1. Locate another machine on the same Windows domain as the one having the issue.
2. Log in using the account of the user experiencing the Network Access issue.
•
If you cannot reproduce the issue, it is likely the issue originates from the user’s machine.
118
TROUBLESHOOTING—Application tunnel issues
•
If you can reproduce the issue, try again on multiple machines in the same Windows domain.
•
If you can reproduce the issue on multiple machines, it is likely the issue originates from BIG-IP
Edge Client software.
Important Windows client systems that are members of a Windows domain may have a group
policy which affects the operation of the Network Access (VPN) connection. F5 recommends that you
attempt to reproduce the issue using at least one system that is not a member of the same Windows
domain.
Network connectivity troubleshooting
If you have followed the procedures previously listed and the user still experiences network activity issues, check
network connectivity with the following methods:
•
Check TCP/IP connectivity on the client system using tools such as the ping utility.
•
Visit the BIG-IP APM login page using several different web browsers to make sure the issue isn’t related to
the client browser.
•
Run the nslookup or dig utilities on the client system to verify that DNS is resolving properly. The BIG-IP
APM hostname must resolve to only a single IP address, so make sure that multiple records are not
returned.
Configuration items troubleshooting
If you have followed the procedures previously listed and the user is still experiencing network activity issues,
using the Configuration utility, check the following settings for the Network Access resource in question:
1. Make sure Traffic Options is set to Use split tunneling for traffic.
2. Make sure SNAT address can be reached when SNAT Pool is set to Auto Map.
3. If VPN clients use IP addresses from the LAN IP subnet, make sure Proxy Arp is enabled.
4. Make sure that the domain name setting for DNS Address Space is correct.
5. Make sure that no ACLs assigned to the network resource are blocking access to a resource.
Note The tcpdump utility tool can be used to diagnose protocol errors and DNS and/or routing problems.
For more information, refer to Ask F5 article K411: Overview of packet tracing with the tcpdump utility.
Application tunnel issues
Application tunnels may fail to establish for the following reasons:
•
DNS resolution fails for the application tunnel resource host.
•
The access policy fails to assign the resource.
•
Application launch is incompatible with the client OS.
119
TROUBLESHOOTING—Application tunnel issues
•
Connectivity issues prevent resources from being reached.
DNS resolution troubleshooting
When an application tunnel resource is configured using a hostname, BIG-IP APM tries to resolve the hostname
for the configured host. If DNS resolution fails, check the BIG-IP APM log file. If hostname cannot be resolved, the
system may log messages similar to the following:
err apd[12025]: 0149015d:3: 695b8701: DNS request to resolve hostname
(somehostthatdoesnotexist.corp) failed for application tunnel resource (/Common/
myapptunnel). errno(139717604) h _ errno(-2) Error str(Name or service not known)
err apd[12025]: 01490000:3: modules/EndingAgents/Allow/AllowAgent.cpp func:
“createATImplicitACL()” line: 695 Msg: Remove AT(/Common/myapptunnel) as DNS
resolution failed for somehostthatdoesnotexist.corp
Tip BIG-IP APM log messages are located in the /var/log/apm file.
You can also confirm the BIG-IP system DNS configuration. The nslookup command line utility can be used to
determine whether or not the configured host can be resolved by the BIG-IP system. Access policy assignment troubleshooting
If the access policy fails to assign a resource to a user, check the BIG-IP APM log file. A successful assignment of
an application tunnel resource is logged in the BIG-IP APM log file. A log message similar to the following may
appear:
apd[12025]: 01490008:5: 695b8701: Connectivity resource ‘/Common/myapptunnel’
assigned
You can also review the access policy to make sure that the user is assigned the correct group or user privileges
to have access to the resource.
Application launch incompatibility troubleshooting
To access an internal hostname using application launch with an application tunnel resource, specify Application
Path parameters associated with the application. You can add the following parameters:
•
%host% Substituted with the loopback host address. For example: http://%host%/application/.
•
%port% Loopback port. Use this if the original local port has changed due to conflicts with other
software.
If these parameters are left out, the application launch may fail. F5 recommends installing BIG-IP DNS Relay Proxy
service to make sure that resolution of all internal hostnames succeeds.
For more information refer to AskF5 article: K9694: Overview of the Windows DNS Relay Proxy service.
Connectivity troubleshooting
The BIG-IP APM needs to be able to connect to resource servers for an application tunnel to succeed. Linux
utilities such as ping and curl can be used to confirm that resource addresses are accessible from BIG-IP APM.
120
TROUBLESHOOTING—Authentication issues
If user sessions are configured to use SNAT settings, confirm that the SNAT address is routable to the VLAN on
which the destination resource is located.
An assigned ACL may block access to resources. The system evaluates ACLs in numerical order, from lowest to
highest. Check to make sure an ACL isn’t responsible for blocking access.
If protocol errors and/or routing errors prevent the application tunnel from establishing, use the tcpdump utility to
capture traffic for detailed analysis.
For more information, refer to AskF5 article: K411: Overview of packet tracing with the tcpdump utility. Authentication issues
If users cannot authenticate during access policy evaluation, troubleshoot the authentication (AAA) elements listed
in this section, as appropriate for the resource types. Note Complete troubleshooting described in the previous sections of this chapter, on both the client side
and server side of your BIG-IP APM system before troubleshooting authentication issues.
Active Directory troubleshooting
Active Directory AAA resources use the Kerberos protocol for communicating with the Active Directory server(s). If
users are experiencing an authentication issue, make sure the following network ports are not blocked between
the BIG-IP APM and Active Directory server:
•
TCP/UDP port 88
•
TCP/UDP port 464
•
TCP/UDP port 53
If the issue persists, continue troubleshooting by making sure of the following:
•
NTP is configured on the BIG-IP APM and there is no more than a 5-minute difference between the clocks
on BIG-IP APM and the Active Directory servers.
•
DNS is configured correctly on BIG-IP APM.
•
DNS SRV records are correctly returned for Active Directory domain controllers.
•
Split Domain From Username option is enabled in the Logon Page agent appearing before the AD Auth
agent in the access policy.
Tip For troubleshooting purposes, you can enable Show Extended Error in the AD Auth policy agent. This
setting returns a full error in the case of authentication failure.
In Active Directory environments that have domain trusts or parent-child domain relationships, enable Cross
Domain Support in the AD Auth policy agent in the resource access policy. This setting makes sure Kerberos
referrals can be followed to child or other domains in the AD forest. For more information on Active Directory troubleshooting, refer to the following AskF5 articles:
•
K11628: Error Message: Clock skew too great, principal name: [username]
121
TROUBLESHOOTING—Authentication issues
•
K11473: Error Message: Client not found in Kerberos database
•
K11830: Error Message: Server not found in Kerberos database
RADIUS troubleshooting
The RADIUS protocol provides access control for network devices using one or more centralized servers. RADIUS
operates over UDP and provides AAA management for users connecting to a network service. RADIUS messages sent between the BIG-IP APM and RADIUS server are authenticated through the use of a
shared secret. When troubleshooting issues with RADIUS make sure of the following:
•
UDP port 1812 between BIG-IP APM and the RADIUS server(s) is not blocked.
•
The shared secret matches on BIG-IP APM and the RADIUS server(s).
•
Network availability of the remote RADIUS server is available. Use a utility, such as ping or traceroute.
Trace RADIUS traffic
To troubleshoot RADIUS sessions, you can use tcpdump packet to capture traffic.
To packet trace RADIUS traffic at the command line using tcpdump
• If the RADIUS server is reachable on the management network, type the following syntax:
tcpdump -s0 -ni eth0 port 1812 -vw /shared/tmp/rad.pcap
• If the RADIUS server is reachable on a TMM network, type the following syntax:
tcpdump -s0 -ni <vlan _ name> port 1812 -vw /shared/tmp/rad.pcap
Note The -vw switches write the output to /shared/tmp/rad.pcap. It also starts a packet counter to show
if any packets are written to the file. Once the traffic is captured, you can view the capture file using a packet
analysis program.
For more information on troubleshooting RADIUS, refer to AskF5 article: K15789: Troubleshooting RADIUS
authentication for application traffic.
RSA SecurID troubleshooting
When troubleshooting system-wide issues authenticating against RSA SecurID, make sure of the following:
•
The IP address of the RSA SecurID server in the BIG-IP APM configuration.
•
TCP port 1645 between BIG-IP APM and the RSA SecurID server is not blocked.
•
There is no more than a 5-minute difference between the clocks on BIG-IP APM and the RSA SecurID server.
•
The Agent Host IP Address matches the agent host record on the RSA SecurID server.
For more information, refer to the following AskF5 articles:
122
TROUBLESHOOTING—Authentication issues
•
K12117: Overview of the Agent Host IP Address setting for Native RSA SecurID authentication
•
K12164: Troubleshooting RSA SecurID authentication
LDAP troubleshooting
The BIG-IP APM system supports LDAP as an authentication method. If users experience authentication issues
with LDAP authentication, troubleshoot the communication between the LDAP server and the BIG-IP system to
find the cause of the failure.
When troubleshooting LDAP issues, make sure of the following:
•
If using an LDAP pool, the IP address of LDAP server(s) is correct.
•
TCP port 389 (LDAP) is open between BIG-IP APM and the LDAP server.
•
TCP port 636 (LDAPS) is open between BIG-IP APM and the LDAP server or pool members.
•
LDAP server or pool members can resolve using DNS.
•
LDAP administrator credentials are correct.
For more information, refer to the following AskF5 article: K13328: Troubleshooting LDAP authentication with
tcpdump.
Kerberos troubleshooting
You can use a Kerberos AAA resource to validate Kerberos tickets provided by users and provide authenticated
access to resources through the BIG-IP APM. If users experience issues logging in to the BIG-IP APM system using Kerberos authentication, troubleshoot the
communication between the key distribution center (KDC) server and the BIG-IP system.
When troubleshooting Kerberos issues, make sure of the following:
•
KDC is online.
•
Network connectivity from the BIG-IP system to the KDC functions. •
TCP and UDP ports 88 (Kerberos) are open between the BIG-IP system and the KDC.
•
The KDC can be resolved using DNS.
If you want to verify Kerberos authentication configurations, use the following procedures:
To verify the keytab for client-side Kerberos
•
At the command line, type the following klist command syntax:
klist -kt <path to keytab file>
Example:
klist -kt /config/filestore/files _ d/Common _ d/kerberos _ keytab _
file _ d/\:Common\:SUN-SPNEGO-APM106 _ key _ file _ 2
123
TROUBLESHOOTING—Authentication issues
Important The complete command must be typed on one line.
The output appears similar to the following:
Keytab name: FILE:/config/filestore/files _ d/Common _ d/kerberos _ keytab _
file _ d/:Common:SUN-SPNEGO-APM106 _ key _ file _ 2 KVNO Principal
3
HTTP/apm106.labt.companynet.com@labt.companynet.com(arcfour-hmac)
For more information on troubleshooting Kerberos, refer to the following AskF5 articles:
•
K11830: Error Message: Server not found in Kerberos database
•
K11474: Error Message: Cannot contact any KDC for realm
Online certificate status protocol responder troubleshooting
The Online Certificate Status Protocol (OCSP) enables applications to determine the revocation status of a
certificate. An OCSP client, in this case the BIG-IP APM, acts as the client, and issues a status request to an
OCSP responder and suspends acceptance of that certificate until the responder provides a response.
If users experience authentication issues and you are validating client certificates with an OSCP responder,
troubleshoot the responder. When troubleshooting OCSP responder issues, make sure of the following:
•
OCSP URL is configured correctly in the OCSP AAA resource.
•
BIG-IP APM can resolve the OCSP URL.
•
The access policy is configured to request a client certificate through either--but not both--the On-Demand
Cert Auth agent or the client SSL profile.
•
OCSP AAA is configured with a CA certificate, CA certificate bundle, or validation authority (VA) certificate
to validate the signature of the returned response.
The following list contains some common error messages and their descriptions, similar to those which may
appear in the BIG-IP APM log file.
•
The OCSP URL is missing in the OCSP Auth policy agent configuration:
warning apd[29223]: 01490146:4: e006090f: OCSP Auth agent: Failure status ‘Bad
param in module configuration’
•
OCSP responder is not reachable:
warning apd[29223]: 01490146:4: e7bd4ddf: OCSP Auth agent: Failure status
‘Failed to connect to OCSP responder host (192.168.49.68) at port 8888’
•
BIG-IP APM is not able to find the correct CA certificate for the client certificate:
warning apd[12557]: 01490146:4: a7d52582: OCSP Auth agent: Failure status
‘Issuer certificate not found for the session’
•
BIG-IP APM did not receive a client certificate:
warning apd[12557]: 01490146:4: b4577458: OCSP Auth agent: Failure status
124
TROUBLESHOOTING—Web Access Management issues
‘Certificate not found for the session’
•
BIG-IP APM is unable to validate the OCSP responder’s certificate chain:
warning apd[29223]: 01490146:4: 4717a222: OCSP Auth agent: Failure status
‘Response Verify Failure’
For more information on troubleshooting OCSP, refer to OSCP Authentication in BIG-IP Access Policy
Manager: Authentication and Single Sign-On.
Certificate revocation list distribution point troubleshooting
BIG-IP APM supports retrieving certificate revocation lists (CRLs) from network locations/distribution points (DP). A
certificate revocation list distribution point (CRLDP) AAA server defines how BIG-IP APM accesses a CRL file from
a distribution point. A distribution point is either an LDAP URI—a directory path that identifies the location where
the CRLs are published—or a fully qualified HTTP URL.
The system uses CRLDP to validate an SSL client certificate for authentication purposes during access policy
execution. If you experience issues logging in to the BIG-IP APM system and are using CRLDP authentication,
troubleshoot the communication between the CRLDP distribution point and the BIG-IP system to determine the
cause of the failure.
When troubleshooting CRLDP issues, make sure of the following:
•
CRLDP is online.
•
Network connectivity from the BIG-IP APM system to the CRLDP is functioning. •
A valid CRLDP AAA is assigned to the CRLDP agent in the access policy.
•
The access policy is configured to request a client certificate through either—but not both—the On-Demand
Cert Auth agent or the client SSL profile.
For more information on troubleshooting CRLDP, refer to CRLDP Authentication in BIG-IP Access Policy
Manager: Authentication and Single Sign-On.
Web Access Management issues
Web Access Management issues typically involve configuration of virtual servers, HTTP profiles, or access
policies, or connectivity problems. To determine whether your issue is related to BIG-IP LTM® configuration or BIG-IP APM access policy
configuration, remove the access profile from the virtual server and see if you can reproduce the problem.
If the issue still occurs, then connectivity or an issue with virtual server or HTTP profile configuration is likely the
root of the problem.
If the issue no longer occurs, troubleshoot the access policy..
Virtual server troubleshooting
•
When troubleshooting virtual server issues, make sure of the following:
125
TROUBLESHOOTING—
•
Connectivity between the client and the BIG-IP APM system is functioning.
•
IP connectivity between the BIG-IP system and any dependent resources, such as pool members, is
functioning.
•
SNAT settings are correct.
•
A pool is associated with the virtual server.
•
At least one of the pool members is available.
•
HTTP profile settings are correct.
•
Clientlssl profile and/or Serverssl profile settings are correct.
Access policy troubleshooting
When troubleshooting access policy issues, make sure of the following:
•
Correct endings exist for all access policy branches.
•
Correct results return after access policy execution. (For example, the user’s access device is correct when
using the Client Type policy agent.)
Access policy execution log messages troubleshooting
Log messages showing a successful access policy evaluation looks similar to the following:
notice tmm[23456]: 01490500:5: 4da2e357: New session from client IP 172.17.2.157 (ST=/
CC=/C=) at VIP 172.24.102.83 Listener /Common/testvip
notice apd[1234]: 01490010:5: 4da2e357: Username ‘administrator’
info apd[1234]: 01490006:6: 4da2e357: Following rule ‘fallback’ from item ‘Logon
Page’ to item ‘AD Auth’
info apd[1234]: 01490005:5: 4da2e357: Following rule ‘Successful’ from item ‘AD Auth’
to ending ‘Allow’
notice apmd[6261]: 01490102:5: /Common/swg-explicit-ap:Common:cae7b0d8: Access policy
result: LTM+APM
Tip BIG-IP APM log messages are located in the /var/log/apm file.
If the log messages show unsuccessful policy evaluation, look for authentication errors or configuration problems
in the access policy.
If log messages show successful policy evaluation but the issue persists, check to see if any assigned ACLs are
blocking access to resources.
126
TROUBLESHOOTING—Portal Access issues
Portal Access issues
If a Portal Access resource is not working as expected, begin troubleshooting by verifying the access policy
executes as expected and the appropriate resource is assigned. Several browser plug-ins and tools exist for capturing HTTP traces, such as HTTPWatch, Fiddler and the
Developer Tools for Google Chrome, Mozilla Firefox, and OS X Safari browsers.
HTTPWatch’s HWL file or an HTTP Archive (HAR) file are F5 preferred formats.
Note Clear the client’s browser cookies and cache, then close and re-open the browser before capturing a
new HTTP trace.
If users are experiencing Portal Access issues, troubleshoot the communication between the BIG-IP APM and the
configured resource items to determine the cause of the failure.
When troubleshooting Portal Access issues, make sure of the following:
•
IP addresses of resource items are correct.
•
The defined paths for the resource items allow access to the correct URI Path for the rewritten application.
•
If enabled, the Match Case for Paths setting is not causing URL pattern match issues.
•
Scheme and port for the resource item is correct.
•
Client Cache settings are not causing stale information to be sent to clients.
Browser incompatibility and script troubleshooting
If the Portal Access issues settings are not contributing to the issue, continue troubleshooting by doing the
following:
•
Rule out browser incompatibility and script issues.
•
Capture an HTTP trace from the client directly to the web application.
•
Capture an HTTP trace from the client using the Portal Access resource.
To determine if browser incompatibility exists, use a different web browser to connect to the resource. If the issue
no longer occurs, there may be a incompatibility issue with the previous web browser or web browser version. Make sure that the Portal Access application does not contain any script errors. Attempt to execute the
problematic function with script errors enabled, or by viewing the web console.
The list below shows the procedure for accessing the web console on the current versions of the three most
popular browsers:
•
Internet Explorer: Tools > Internet Options > Advanced > Display a notification about every script
error.
•
Chrome: Customize and Control Google Chrome > More Tools > Developer Tools > Console.
•
Firefox: Open Menu > Developer Tools > Toggle Tools > Console.
127
TROUBLESHOOTING—Per-Application VPN issues
To get the best user experience with a Portal Access resource, the web application must execute with no errors.
Warnings are acceptable, but if errors should be addressed within the browser as they may be the cause of the
issue.
Use HTTP trace from client direct to web application in troubleshooting
HTTP traces taken from the client directly to the application without BIG-IP APM provide a picture of what a
successful request or HTTP session should look like.
When capturing the HTTP trace, the client must use the server hostname (http://example.com/) and not IP address
(http://192.168.1.100/)
. The HTTP trace must be started before the first request is executed.
Use HTTP trace through a BIG-IP APM Portal Access resource in troubleshooting
An HTTP trace taken while accessing a Portal Access resource on the BIG-IP APM shows the application failure.
The HTTP trace must be started before the first request.
For additional troubleshooting tools, refer to the AskF5 article: K13384: Performing a web applications trace (11.x).
Per-Application VPN issues
Per-application (Per-App) VPN problems are typically caused by one of the following: •
MDM policy issues
•
Access Policy issues
•
Connectivity issues
MDM policy troubleshooting
Per-App VPNs require deployment of a third-party mobile device management (MDM) application. You must
correctly apply an MDM policy to mobile devices. Without this policy, Per-App VPN tunnels are not be created. If
users experience issues with Per-App VPNs and the BIG-IP APM, troubleshoot the MDM solution.
When troubleshooting MDM issues, make sure of the following:
•
VPN profile settings are correct.
•
MDM profile settings are correct. •
There are two limitations for applications that use iOS 7 Per-App VPN API:
•
Only managed applications installed on the user’s device using an MDM solution are able to use iOS 7
Per-App VPN.
•
Only TCP applications are currently supported.
Important Apple’s implementation of the iOS 7 Per-App VPN API are the source of these limitations and
are subject to change in any future iOS release.
128
TROUBLESHOOTING—SSO issues
Access policy troubleshooting
The BIG-IP APM log file should be reviewed to make sure the access policy is successful. If it is not, review the
message logs for any error messages related to the following
•
Authentication errors
•
Misconfiguration of access policy items
Additionally, review the BIG-IP APM log file to make sure of the following:
•
Correct endings exits for all access policy branches.
• Correct result is returned from each access policy agent. (For example, the user’s access device is correct
when using the Client Type agent.)
Tip BIG-IP APM log messages are located in the /var/log/apm file.
If the access policy completes successfully, confirm that no assigned ACLs are is blocking access to the
resources.
Connectivity troubleshooting
If the access policy starts and completes successfully, the problem is likely a connectivity issue. The BIG-IP APM
must be able to connect to the resource for the Per-App VPN to succeed. When troubleshooting connectivity issues, make sure of the following:
•
Connectivity between the client and the BIG-IP system is functioning.
•
IP connectivity between the BIG-IP system and any dependent resources, such as internal hosts, is
functioning.
•
SNAT settings are correct on the BIG-IP LTM virtual server.
SSO issues
Symptoms of issues with SSO include the following:
•
Application prompts users to sign more than once.
•
Application loops on the login page.
•
Invalid login message appears on the login page.
•
SSO is successful the first time but fails on subsequent attempts.
Common issues troubleshooting
•
SSO mechanisms in BIG-IP APM require separate troubleshooting techniques, but there are several
common causes of issues. When you begin troubleshooting SSO, you can start by seeing if any of the
following are the cause of the issue:
129
TROUBLESHOOTING—SSO issues
•
Once an SSO failure is detected within a user session, the SSO becomes disabled for all SSO types.
•
SSO mechanisms that require a password read the access session variables created by the SSO Credential
Mapping policy agent. This agent must execute during access policy execution for each user session.
•
HTTP NTLM and Kerberos SSO methods require correct configuration of the session session.logon.last.
domain variable. The variable can be set manually with a Variable Assign policy agent. It is also assigned
automatically if users provide a domain in the Logon Page policy agent and log in using a domain\
username or username@domain format.
•
Kerberos SSO (S4U) and SAML SSO types do not require a password.
•
Kerberos AAA, NTLM (ECA), and client certificate (OCSP, CRLDP, or on-demand) AAA types do not provide
a password. SecurID RSA AAA (or RADIUS with RSA) AAA types typically provide an OTP token that does
not represent a user password but has validity for internal resources.
For more information, refer to AskF5 article K13595: Frequently used tools for troubleshooting BIG-IP APM and
Edge Gateway issues (11.x).
Forms (server-initiated) troubleshooting
With forms SSO, the Web SSO process transmits user credentials to the internal web server when the user
accesses the Start URI.
To troubleshoot forms SSO
1. Increase log verbosity, as described in Increase log verbosity in this section.
2. Use a Linux text utility, such as less or tail to follow the BIG-IP APM log messages.
3. Log in as a test user and attempt SSO processes.
4. Review log messages. Refer to the following procedure for more information.
Tip BIG-IP APM log messages are located in the /var/log/apm file.
When troubleshooting SSO, make sure of the following, in the order listed:
1. The correct Forms SSO policy agent is used in the access policy.
2. Client issues its request to the correct Start URI, configured in the Forms SSO access policy
agent.
Web SSO logs the Start URI and the request URI. These must match exactly so that the Forms
SSO agent is triggered.
In the following log message example, SSO is configured with a Start URI of mywebapp.corp/
login.asp, and the client’s request an unmatched URI of «/». The resulting output is no start uri
match.
debug websso.0[22225]: 014d0030:7: 4e763e75: checking start uri match, start
uri: ‘/mywebapp.corp/login.asp’, request:”/”
130
TROUBLESHOOTING—SSO issues
debug websso.0[22225]: 014d0030:7: 4e763e75: no start uri match
3. Successful Logon Detection Match Type and Successful Logon Detection Match Value are
selected are working correctly.
If these options are not correctly configured, SSO may be inadvertently disabled. The following
sample syntax shows this condition:
notice websso[16111]: 014d0038:5: c2bd29cd: success match failed for ‘test’
using config ‘/Common/myformssso’, SSO disabled for this session
Forms-client initiated troubleshooting
With forms client-initiated SSO, the Web SSO process inserts a script into the web application’s logon page. This
script causes the client to automatically POST credentials to the web app, mimicking a user login.
To troubleshoot forms-client initiated SSO
1. Set SSO logging to debug level within the Forms-Client Initiated SSO policy agent.
2. Use a Linux text utility such as less or tail to follow the BIG-IP APM log messages.
3. Use an HTTP trace utility with recording capability, such as Fiddler, HTTPWatch, or HTTPFox to
record a web session on the test user’s local machine.
4. Enable the web browser’s JavaScript error console to make visible any JavaScript errors.
5. Log in as a test user and attempt SSO.
6. Review the log messages and recorded session. Refer to the following procedure for more
information.
Important Set log verbosity for the Forms-Client Initiated SSO policy agent within the policy agent object
rather than as described in Increase log verbosity.
When reviewing log messages and web session recording, make sure of the following, in the order listed:
1. The correct Forms Client-Initiated SSO policy agent is used in the access policy by looking for a
log message with a syntax similar to the following.
Mar 16 23:31:58 f5b info tmm1[19390]: 014d0002:6: 996e8bee: SSOv2 Request “GET
/”, config /Common/my _ client _ initiated _ sso
The config /Common/my_client_initiated_sso portion of the previous sample message indicates
the Forms Client-Initiated SSO agent is being used.
Client issues its request to the correct Start URI, configured in the Forms Client-Initiated SSO
access policy agent. Also check that the form is detected correctly. Do this by looking for log
messages with the syntax similar to the following:
info tmm1[19390]: 014d0002:6: 996e8bee: SSOv2 Request match, config /Common/
my _ client _ initiated _ sso form Loginform info tmm1[19390]: 014d0002:6:
131
TROUBLESHOOTING—NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO troubleshooting
996e8bee: SSOv2 Form detected, config /Common/my _ client _ initiated _ sso
form Loginform
The Request match and Form detected portions of the previous sample log messages indicate
correct configuration.
2. In the recorded session data, the HTML body of the web app’s login page includes JavaScript near
the bottom to automatically POST the credentials. It can be identified by the text f5-sso-token,
3. which is the password transmitted by the client.
4. No script errors occur on the client web browser.
Note Some web applications use script attached to the form submit button or form onsubmit action
to perform various tasks. In such cases, the inserted JavaScript must be customized specifically for
the web app’s login page. This procedure requires JavaScript programming experience and is outside
the scope of this document. For further assistance, contact F5 Professional Services (https://f5.com/
support/professional-services).
NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO troubleshooting
NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO methods use standard HTTP authentication mechanisms
transmitted on the user’s behalf by BIG-IP APM. The authentication appears within the internal server traffic.
To troubleshoot NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO
1. Increase log verbosity, as described in Increase log verbosity in this section.
2. Use a Linux text utility such as less or tail to follow the BIG-IP APM log messages.
3. Use ssldump to decrypt HTTPS or tcpdump to capture HTTP communication between BIG-IP
APM and the internal web server.
4. Log in as a test user and attempt SSO.
When reviewing log messages and decryption/capture information, make sure of the following, in the order
listed:
1. Recorded HTTP transactions for HTTP 401 responses from the internal server are correct.
2. The correct SSO profile is used for the session. Check this by looking for a syntax similar to the
following:
info websso.3[27034]: 014d0014:6: 52bd552a: Found HTTP 401 response for SSO
configuration ‘/Common/my-http-sso’ type:’ntlmv1’
The /Common/my-http-sso’ type:’ntlmv1 portion indicates the SSO profile used.
3. The internal server Web SSO process returns a “Found HTTP 401” response. Check this by
looking for syntax similar to the following:
info websso[27034]: 014d0014:6: 52bd552a: Found HTTP 401 response for SSO
132
TROUBLESHOOTING—NTLMv1 SSO, NTLMv2 SSO, and HTTP basic SSO troubleshooting
configuration ‘/Common/my-http-sso’ type:’ntlmv1’
The Found HTTP 401 response portion indicates the 401 response.
4. SSO is not disabled for the session. Check this by looking for syntax similar to the following:
“ _ ssoDisabled: true”
For more information, refer to the following AskF5 articles:
•
K10209: Overview of packet tracing with the ssldump utility
•
K411: Overview of packet tracing with the tcpdump utility
Kerberos SSO troubleshooting
Kerberos SSO utilizes a Kerberos extension called Service 4 User (S4U). Web SSO obtains a Kerberos ticket on
behalf of the user and either inserts it into the request sent to the server or waits for the HTTP 401 response from
an internal server.
Common Kerberos failures are caused by the following:
•
DNS resolution failure. For Kerberos SSO to function, a PTR record and an A record must exist and be
correctly configured for target resources.
•
NTP must be configured and working correctly.
•
Duplicate service principal names (SPNs) must be corrected.
When troubleshooting Kerberos SSO make sure of the following:
•
The SSO policy agent is correctly configured and applied in the access profile.
•
Transitive trust is in place for cross-realm or cross-forest Kerberos delegation and user’s realm specified in
the User Realm Source variable. The BIG-IP APM Kerberos SSO module does not follow enterprise
canonical referrals. •
Delegation account belongs to the same realm as the resource.
•
Delegation account is configured properly.
To verify server-side Kerberos delegation at the command line
•
Type the following syntax:
kinit <SPN of delegation account>
Example:
kinit HOST/krbsvc.example.com@EXAMPLE.COM
You are prompted for a password and should receive a ticket (no output, no error). The kinit command retrieves a
ticket-granting ticket (TGT) from the key distribution center (KDC) for the delegation account.
Server-side Kerberos delegation also performs protocol transition, or S4U2Self.
133
TROUBLESHOOTING—Tools and utilities
To test S4U2Self functionality at the command line
•
Type the following syntax:
kvno -U <valid user> <SPN of delgation account>
Substitute a valid AD user account and SPN of the delegation account.
Example:
kvno -U bob.user HOST/krbsvc.example.com@EXAMPLE.COM
A successful kvno command returns a key version number (kvno).
For more information on configuring DNS A, PTR, and SRV records and on resolving duplicate SPNs, search
Microsoft Knowledge Base articles on Microsoft’s Support search page.
Note This link takes you to a resource outside of AskF5. The third party could remove the document without
our knowledge.
Tools and utilities
You can use several command line tools to troubleshoot the BIG-IP APM system. You can use sessiondump and
configdump utilities to check current user session data and tcpdump and ssldump to analyze traffic traversing
the BIG-IP APM system.
Additionally, you can use a client-based component troubleshooting utility to debug logging, diagnostic reports
and manual removal of the client components
Using sessiondump
Use sessiondump to view session variables for one or more active sessions, including sessionid, assigned
resources profiles, and others. sessiondump includes the following commonly used commands:
-allkeys returns all session variable for all current sessions.
<Session ID> returns all session variables for the specified 8-character session id.
To see all the sessiondump options, type sessiondump at the BIG-IP APM command line and press Enter. The following sample output shows sessiondump using the -allkeys option:
[root@sam10:Active] config # sessiondump -allkeys
04447e63 10 SessionKey
04447e63.session.access.profile 10 jm _ ap _ web1
04447e63.session.assigned.resource _ groups 8 jm _ rg _ 1
04447e63.session.assigned.resources 47 again google jm _ na _ res1 my _ new _ app vim
webApp2
04447e63.session.assigned.uuid 17 UUID:j:jm _ ap _ web1
04447e63.session.assigned.webtop 18 jm _ portal _ web _ vim1
134
TROUBLESHOOTING—Tools and utilities
04447e63.session.client.activex 1 0
04447e63.session.client.cpu 3 x86
04447e63.session.client.js 1 1
Tip The -all keys command in sessiondump can return large amounts of data on busy systems.
Using configdump
Use configdump to view configuration variables for access policies and includes the following commonly used
commands:
• -list returns the list of configuration snapshots
• -allkeys returns all configuration variables for all configuration snapshots
• <Configuration self device ID> returns all configuration variables for the specified configuration ID.
The following example shows a partial output using the -list option:
[root@sam10:Active] config # configdump -list
Configudump using self device name: /Common/bigip3907mgmt.lab.fp.f5net.com
Configudump using self device ID: 9d67a1fda622c7617240fa9e3ffc885a
/Common/accessSSL3.1428085704 32 282f098ade80 _ 1oooooooooooooooooo
/Common/accessSSL3.current 10 1428085704
/Common/accessSSL3.1428085703 32 27db53b9490e2 _ 0ooooooooooooooooo
Using tcpdump
Use tcpdump to trace packets in a BIG-IP APM Network Access tunnel by specifying the name of the connectivity
profile as the interface.
For example:
tcpdump -i <apm _ connectivity _ profile _ name>
To view the current BIG-IP APM connectivity profile using the Configuration utility
1. Navigate to Local Traffic >> Virtual Servers, and click the name of the virtual server for the
Network Access policy you want to trace.
2. The profile name is displayed in the Connectivity Profile menu.
For more information, refer to AskF5 article: K411: Overview of packet tracing with the tcpdump utility.
Using ssldump
Use ssldump to examine, decrypt, and decode SSL-encrypted packet streams managed by the BIG-IP system. For more information, refer to AskF5 article: K10209: Overview of packet tracing with the ssldump utility.
135
TROUBLESHOOTING—Tools and utilities
Using the component troubleshooting utility
The Component troubleshooting utility can provide debug logging, diagnostic reports and manual removal of
the client components. The report that the utility generates is required, in most cases, when opening support
cases for client-side problems.
For more information, refer to AskF5 article: K12444: Overview of the Component Troubleshooting Utility.
136
COLLECTING BIG-IP APM DATA FOR SUPPORT—Logging (BIG-IP 12.0 and later)
Collecting BIG-IP APM Data for Support
To open a support case for BIG-IP® APM®, additional module-specific data collection may be necessary to give
support engineers a complete understanding of your system’s issues. Depending upon the BIG-IP APM access
method or feature at issue, F5® support may request this additional information. Use the following section to guide
you in collecting the this information.
Logging (BIG-IP 12.0 and later)
In BIG-IP 11.x - 11.6, logging settings were global for all access profiles. In BIG-IP 12.0 and later, each access
profile is attached to a logging profile. This means that log levels can be set per access profile, allowing greater
flexibility in logging.
Note If you find during troubleshooting that an access profile is not logging events as desired, verify that it
has the appropriate Log Setting attached.
Default log settings
Access policy event log settings establish a minimum log level for access policy, per-request policy, Secure Web
Gateway URL filtering activities, and so on. The upgrade creates a default log setting, default-log-setting. In it,
access policy logging is enabled, the apm_general_logging log publisher is specified, and the default minimum
log level, Notice is specified for each object.
The upgrade adds the default-log-setting log setting to every access profile.
Upgrade result and post-upgrade configuration
The local logging (to the database or syslog) configured prior to upgrade remains configured for access policy
events by default. Also, any time an access profile is created, the default-log-setting log setting is attached to it.
You can remove it, replace it, or add other log settings to the access profile. For flexibility and redundancy, you
can add up to three log settings to an access profile that specify access policy logging.
Note To take advantage of remote high-speed logging, you must configure remote high-speed logging
destinations along with a pool of logging servers. Instructions are included in BIG-IP Access Policy
Manager documentation.
Disposition of log messages from the previous release
In BIG-IP 12.0 and later, none of the log messages stored in the local database are carried over. The new
database structure does not support the old log message format.
Change logging levels (BIG-IP 11.x - 11.6)
You can also use the BIG-IP APM log messages to assist in data collection. To do so, you may need to change the
BIG-IP APM log level to debug.
Important Logging at the debug level creates large log files which may lower performance. Once you are
137
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
finished troubleshooting, you need to return the logging level (Notice).
To enable additional Access Policy logging using the Configuration utility
1. Navigate to System >> Logs : Configuration : Options : Access Policy.
2. In the Access Policy Logging section, for Access Policy, SSO, Portal Access, and VDI, select
Debug.
3. Click Update.
Tip To return to default logging level, set each item to Notice.
To enable additional logging using tmsh at the command line
Type the following commands:
tmsh modify sys db log.accesscontrol.level { value “debug” }
tmsh modify sys db log.sso.level { value “debug” }
tmsh modify sys db log.webapplications.level { value “debug” }
tmsh modify sys db log.vdi.level { value “debug” }
To disable additional logging using tmsh at the command line
Type the following commands:
tmsh modify sys db log.accesscontrol.level { value “notice” }
tmsh modify sys db log.sso.level { value “notice” }
tmsh modify sys db log.webapplications.level { value “notice” }
tmsh modify sys db log.vdi.level { value “notice” }
Network captures
In most issues involving BIG-IP APM, having network packet trace information available is beneficial. As BIG-IP
APM is a full proxy, a trace that captures traffic on both the client side and server side is recommended. Utilities
such as tcpdump and ssldump can capture traffic.
For more information on these utilities, refer to AskF5 articles: K13637: Capturing internal information with tcpdump
and K10209: Overview of packet tracing with the ssldump utility.
Note For versions BIG-IP APM 11.2.0 and later, ssldump utility should be run with the -M command line
switch to generate the pre-master secret (PMS) key log file. The decrypted output contains the SSL
certificate information required to decrypt network captures. This data should be included with your support
case information and may be requested by Support if it is not.
When multiple traffic captures using tcpdump utility are required, be sure to run all captures concurrently
138
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
before sending test traffic.
Tip The ssldump utility can only decrypt data if the client and server use RSA for key negotiation. You may
need to temporarily force the client and server to use RSA for their SSL session.
For more information, refer to K10209: Overview of packet tracing with the ssldump utility.
Note For information about how to locate F5® product guides, refer to AskF5 article K12453464: Finding
product documentation on AskF5.
Network Access data collection
For issues related to Network Access, data needs to be collected both from the BIG-IP system and on the client
system.
BIG-IP APM network capture
A network capture taken on the BIG-IP APM connectivity profile interface shows all VPN traffic as it arrives from
the client or traffic received from the local LAN to be sent to a VPN client decrypted:
tcpdump -nnvi <connectivity _ profile>:nnn -s0 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
To view traffic entering and leaving the BIG-IP using the local VLAN interfaces at the command line
•
Type the following command:
tcpdump -nnvi 0.0:nnn -s0 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
Tip The tcpdump utility captures can get quite large, therefore you should attempt to start the capture
immediately before and stop the capture immediately after the behavior you want to send to F5
Support. Optionally, you can add a -c command to the tcpdump command line to indicate how many
packets to capture.
Follow the -c option with a packet number value. For example: tcpdump -nnvi 0.0:nnn -s0 -c
5000000 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
Windows Remote Access Service
F5 VPN components rely on Microsoft Remote Access Service (RAS) components, so enabling RAS logging
provides details if the issues are occurring on a Windows client.
To enable RAS tracing using a Windows command line
•
Open a Windows command line and type the following command
netsh ras set tracing * enabled
139
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
Once the command completes, a new Network Access session can be started. Once the issue occurs, flush RAS.
To flush RAS logs using a Windows command line
•
Open a Windows command line and type the following command
netsh ras set tracing * disabled
The resulting log files are located in the \windows\tracing directory. The ppp.log file should be provided to F5
support.
Client-side logging and network captures are also necessary in order to provide F5 support with an end-to-end
view of the issue.
You can use Microsoft network monitor (Netmon) or Wireshark to gather network capture on the client machine.
NetMon allows for direct captures on PPP interfaces and exports output in pcap format, which is compatible with
tcpdump.
To use Netmon to capture network data
1. Find the application and right-click Run as Administrator.
2. From the Interface Adapter list, select the active network interface (wireless or wired) and the
NDISWANBH adapter.
3. Select New Capture.
4. Press Play.
5. Start the F5 Edge Client.
6. Navigate to Details and select Enhanced Logging.
7. Click Connect and log in to BIG-IP APM.
8. Once the APM session is established, note the client IP address. If possible, also determine which
session ID the user received.
9. Once the issue occurs, disconnect from the Edge Client.
10. In Netmon, click Stop.
11. Save the network monitor capture using File > Save As.
Tip Session ID information can be found using the Configuration utility in the Access Policy >> Manage
Sessions menu.
The traffic captured on NDISWANBH is not encrypted by the TLS/DTLS layer of the F5 VPN Adapter. The F5
f5wininfo.exe utility also gathers F5 specific log files from the F5 VPN components installed on the system.
140
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
To generate the information needed for support with ftwininfo.exe
1. Download and run the Client Troubleshooting utility. For more information, refer to Ask F5
article: K12444: Overview of the Client Troubleshooting utility for Windows.
2. Click File.
3. Click Generate Report.
4. Click the Text option.
5. Click Save As.
6. Enter a path and filename where you want to save the report.
7. Click Save.
8. When the report completes, click Cancel.
Apple OS X and Linux
For information on how to enable debug logs for the OS X Edge Client, refer to AskF5 article: K12321: Enabling
Network Access debugging for Mac OS X and Linux.
Once debugging is enabled, you can start a network capture and the user can start a Network Access session. To
capture network traffic, you can use Wireshark or tcpdump to capture traffic on tun device tun0. This device is
created only after the Network Access tunnel establishes (that is, after the user logs in to BIG-IP APM), so this
capture starts in a separate terminal window.
To capture the whole session (login, during session, and logout), run a simultaneous tcpdump capture from a
terminal on the interface connected to the Internet, as shown in the following example:
sudo tcpdump -w /path/to/file -nni <interface> -vv -s0 host <Virtual server IP>
Portal Access data collection
For all Portal Access issues, you can collect the following general data to provide to F5 Support:
• Name of the access portal resource experiencing the issue
• HTTP trace data from client direct to web application
• HTTP trace data through the BIG-IP APM Portal Access resource
Tip Clear the client’s browser cookies and cache, then close and reopen the browser before capturing a
new HTTP trace.
A number of browser plug-ins and tools exist for capturing HTTP traces like HTTPWatch, Fiddler, and the
developer tools for Google Chrome, Mozilla Firefox and OS X Safari browsers. Preferred file formats are
HTTPWatch’s HWL file or an HTTP Archive (HAR) file.
141
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
HTTP trace from client direct to web application
You can take HTTP traces from the client directly to the resource application without BIG-IP APM involved to
provide a picture of what a successful request or HTTP session looks like. When capturing the HTTP trace, the
client must use the server hostname (http://example.com/) rather than the IP address (http://192.168.1.100/).
You must start the HTTP trace prior to the first request.
Note Clear client browser cookies and cache, then close and reopen the browser before capturing a new
HTTP trace.
HTTP trace through BIG-IP APM Portal Access resource
You can take HTTP traces while accessing the Portal Access resource on the BIG-IP APM to show the application
failure. BIG-IP APM provides an additional tool for gather diagnostics data using the Web Application Trace
functionality. For more information, refer to AskF5 article: K13384: Performing a web applications trace (11.x - 12.x).
Note Clear the client’s browser cookies and cache, then close and reopen the browser before capturing a
new HTTP trace. Also, start the capture at the point of launching the Portal Access favorite, and end the
capture after error condition.
JavaScript errors
If JavaScript errors occur, you can view them in your browser using the following steps:
• In Internet Explorer, navigate to Tools > Internet Options > Advanced > Display a notification about
every script error.
• In Firefox, navigate to Menu > Developer > Web Console.
• In Chrome, navigate to Menu > Tools > JavaScript Console.
Important Once you’ve gathered the troubleshooting data, return the access policy and Portal Access log
settings to their defaults.
Java rewrite
If a Portal Access issue involves a Java Applet, make sure of the following:
• A Web Acceleration profile is applied on the BIG-IP APM virtual server and the URL matching the JAR file
paths in the URI List.
• The Portal Access resource has the Java Patching enabled.
• The Portal Access resource item has a correctly matching path defined which matches the JAR file paths.
If the issue still persists after validating these steps, do the following:
• Gather the Java console logs from the client machine as described in Java Console, Tracing, and Logging in
Java Platform, Standard Edition Deployment Guide. Note: This link takes you to a resource outside of AskF5. The third party could remove the document
142
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
without our knowledge.
• Make sure that the Java console debug logs when accessing the application directly, bypassing BIGIP APM.
• Take a network capture taken on the client machine.
• Take a network capture on the BIG-IP system Internal VLAN connected to the Web Application server.
To take a network capture of the Internal VLAN connected to the Web Application server at the command line
•
Type the following command:
tcpdump -nnvi <internal _ vlan _ name>:nnn -s0 -w /var/tmp/<f5-issue-idddmmyy>.pcap host <web _ application _ server _ ip>
Application access data collection
Application tunnels are split tunnels. Before troubleshooting, make sure of the following on the client machine:
• DNS Relay Proxy service is up and running.
• Component Installer service up and running.
• The user on the client machine has administrative rights.
If you can’t verify any of these conditions, make sure that the DNS relay proxy and component installer services
are installed. These components are required to allow application tunnels to run correctly without user elevation
privilege or name resolution issues.
ActiveX and RDP application tunnels
The f5wininfo.exe utility also gathers F5 specific log files from the F5 application tunnel components installed on
the system.
To generate the information needed for support using the f5wininf.exe utility
1. Download and run the Client Troubleshooting utility.
2. Click File.
3. Click Generate Report.
4. Click the Text option.
5. Click Save As.
6. Enter a path and filename where you want to save the report.
7. Click Save.
143
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
8. When the report completes, click Cancel.
For more information, refer to AskF5 article: K12444: Overview of the Client Troubleshooting utility for Windows.
Tip Running the f5wininfo.exe utility on a user system that is not experiencing the same issue is helpful.
Java application tunnels
Java Application Tunnels can be run on Windows, Macintosh, or Linux clients. The following troubleshooting steps
work on any of these operating systems.
• Gather the Java console logs from the client machine as described in Java Console, Tracing, and Logging in
Java Platform, Standard Edition Deployment Guide.
Note: This link takes you to a resource outside of AskF5. The third party could remove the document
without our knowledge.
• Make sure that Java console debug logs when accessing the application directly, bypassing BIG-IP APM.
• Take a network capture taken on the client machine.
• Take a network capture on the BIG-IP system Internal VLAN connected to the Web Application server.
To take a network capture of the Internal VLAN connected to the Web Application server at the command line
•
Type the following command:
tcpdump -nnvi <internal _ vlan _ name>:nnn -s0 -w /var/tmp/<f5-issue-idddmmyy>.pcap host <web _ application _ server _ ip>
Per-App VPN data collection
When experiencing issues with a Per-App VPN, the following information needs to be collected:
Mobile OS type (such as iOS or Android).
• BIG-IP EdgeClient version being used.
• BIG-IP EdgeClient logs.
• Per-App VPN mobileconfig file (if used to provision mobile client).
• Network trace on 0.0 interface while reproducing issue:
tcpdump -nnvi 0.0:nnn -s0 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
VDI Issues data collection
BIG-IP APM provides services for:
• Citrix XenDesktop/XenApp
144
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
• VMWare View
• RDP
Citrix
When collecting data for Citrix issues, gather data by answering the following questions:
• The BIG-IP APM deployment in use? (such as Web Interface, storefront, or portal mode)
• Whether a Citrix XenApp server is in use and if so, the version
• Whether a Citrix XenDesktop server is in use and if so, the version
• Whether a Citrix StoreFront server is in use and if so, the version
• Whether a Citrix Web Interface server is in use and if so, the version
• Whether a Citrix Receiver is in use
• Operating system in use: (such as iOS, Android, Windows)
• Citrix Receiver client version in use
In addition to obtaining a qkview file, combine the BIG-IP APM logs by typing the following command:
tail -f /var/log/{apm,ltm} > /var/tmp/f5-issue-id-ddmmyy-citrix.log
In a separate terminal window, type the following command:
tcpdump -s0 -nni 0.0:nnn (host <client _ ip> or host <xml _ broker(s) _ ip(s)> or host
<connection _ resource _ ip>) -w /var/tmp/f5-issue-id-ddmmyy-citrix.pcap
VMWare View
When collecting data for VMware issues, provide the following information:
• Whether a VMware Horizon View in use and if so, the version.
• Whether a Connection server in use and if so, the version.
• Whether a vCenter server in use and if so, which version.
• Whether a VMware Horizon View Client in use and if so, the version.
• The operating system in use and its version.
• The HTML5 connection in use if applicable.
• Whether the desktop resource have HTML Access software installed on it.
In addition to obtaining a qkview file, combine the BIG-IP APM logs with the following command:
tail -f /var/log/{apm,ltm} > /var/tmp/f5-issue-id-ddmmyy-view.log
145
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
In a separate terminal window, run the following command:
tcpdump -s0 -nni 0.0:nnn (host <client _ ip> or host <view _ connection _ server _
ip(s)> or host <view _ security _ server _ ip(s)> or host <vdi _ desktop _ server _ ip(s))
-w /var/tmp/f5-issue-id-ddmmyy-view.pcap
Authentication and SSO data collection
Authentication issues with AAA resources occur usually between the BIG-IP APM and AAA resource on an internal
VLAN. A network capture between the BIG-IP APM and AAA resource provides the most insight in most cases:
cpdump -nnvi <internal _ vlan _ name>:nnn -s0 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
In addition, the following information should be collected:
• Session report for the failed user session
• BIG-IP APM logs files in debug level (provided in qkview)
• Name of the AAA resource in use
• Network capture taken on the user’s system if Kerberos authentication is being used to authenticate users
SAML
You can deploy BIG-IP APM as an IdP or SP to provide SAML federation to clients. When troubleshooting issues
for federated access, the following data should be gathered:
• Use Case: IdP or SP initiated
• HTTPWatch HWL, HAR archive or SAML Trace log (Firefox only) session.
• XML before and after canonicalization from application
• Metadata from the partner device
• A test account on the partner device to the BIG-IP APM (IdP or SP) and associated metadata
• A network capture on interface which sees the SAML traffic
SSO
SSO issues occur between the BIG-IP APM system and an application. A network capture between the BIG-IP
APM and the application provides the most insight in most cases:
tcpdump -nnvi <internal _ vlan _ name>:nnn -s0 -w /var/tmp/<f5-issue-id-ddmmyy>.pcap
In addition, the following information must be provided:
• Name of the SSO resource in use
• SSO Type (such as Basic, Forms, Kerberos, and so on)
146
COLLECTING BIG-IP APM DATA FOR SUPPORT—Network captures
• Application authentication in use
• An mpidump capture. For more information, refer to K11765: Frequently used tools for troubleshooting
BIG-IP APM and Edge Gateway issues (10.x) or K13595: Frequently used tools for troubleshooting BIG-IP
APM and Edge Gateway issues (11.x).
OPSWAT (antivirus/firewall) data collection
In cases where a client endpoint inspection check fails or does not work correctly, do the following:
• Run a session report for the failed user session.
• Download, install, and run the latest OPSWAT Security Score tool.
Note: This link takes you to a resource outside of AskF5. The third party could remove the document
without our knowledge.
High-resource utilization
BIG-IP APM uses multiple system daemons to provide functionality. If processes use too much CPU time or hang
refer to AskF5 article K15263: BIG-IP APM daemons (11.x). If daemons seem to be the problem, run the following
commands:
top -cbn 5 > /var/tmp/<f5-issue-id-ddmmyy>-top.txt
qkview -s0 -C
Important F5 believes the information it furnishes to be accurate and reliable. However, F5 assumes no
responsibility for the use of this information, nor any infringement of patents or other rights of third parties
which may result from its use. No license is granted by implication or otherwise under any patent, copyright,
or other intellectual property right of F5 except as specifically described by applicable user licenses. F5
reserves the right to change specifications at any time without notice.
147
OPTIMIZING THE SUPPORT EXPERIENCE—F5 technical support commitment
Optimizing the Support Experience
F5 technical support commitment
F5® strives to continuously improve its support service and create closer customer relationships. Designed to
provide assistance with specific break-fix issues and ongoing maintenance of F5 products, F5 professional
support services are consistently high-quality.
This means:
•
F5 network support engineers conduct themselves professionally at all times.
•
F5 is committed to providing the best customer experience possible.
•
F5 treats customers are with respect and give them every consideration possible.
•
F5 aims to provide resolutions the first time, every time.
•
You can ask for manager escalation for unresolved or “site down” issues.
Some technical support issues arise from configuration errors, either within the BIG-IP® system or with other
devices in the network. In other cases, a misunderstanding of BIG-IP capabilities can lead to support questions
and issues. Although F5 does everything possible to prevent defects in BIG-IP hardware and software, these
issues may still arise periodically. Regardless of the root cause of a problem, the goal is to resolve any issues
quickly.
F5 technical support offerings
A variety of technical support offerings are available to provide the right level of support for any organization.
F5 Standard and Premium Support include remote assistance from F5 network support engineers, both online and
over the phone.
Premium Plus customers receive priority status at F5, with fast, easy access to a dedicated team of senior-level,
F5-certified network support engineers and a Technical Account Manager.
To learn more, refer to F5 Technical Support Offerings or send email to services@f5.com.
Professional services
Take advantage of the full range of F5 Professional Services to help you design, customize, and implement a
solution that is right for your IT infrastructure and which supports your business goals.
Professional Services (f5.com/support/professional-services) provides information on a wide range of F5
Professional Services offerings and Professional Services Partners. You can use our online forms to request
Consulting Services OnDemand for custom, shorter scope consulting engagements, or iRules® OnDemand to get
fast access to iRules scripts tailored to your specific needs.
You can make an online request for specific support services by filling out a request form:
148
OPTIMIZING THE SUPPORT EXPERIENCE—F5 certification
•
Consulting request form (f5.com/support/professional-services/consulting-request-form).
•
iRules consulting request form (f5.com/support/professional-services/irules-consulting-request-form).
GUARDIAN Professional Services Partners
F5 GUARDIAN® Professional Services Partners are authorized as installation providers and are also available to
assist you. F5 GUARDIANs are selected because they have the skills and experience required to ensure successful
implementations of F5 BIG-IP installations.
Refer to F5 GUARDIAN Professional Service Partners (f5.com/support/professional-services#guardian) for a
complete list of partners.
F5 certification
F5 Certified® exams test the skills and knowledge necessary to be successful when working with today’s
application delivery challenges. Our technically relevant and appropriate exams deliver consistently reproducible
results that guarantee excellence in those that achieve certification.
Certification levels
F5 Certified! is the F5 certification program, with a progressive program of four levels (Administrator, Specialist,
Expert, and Professional), each of which build on the skills and knowledge demonstrated on previous exams.
C1 – F5 Certified BIG-IP Administrator (F5-CA)
The starting point for all certifications: a certified BIG-IP Administrator has basic network and application
knowledge to be successful in application delivery.
C2 – F5 Certified Technology Specialists (F5-CTS)
The Technology Specialist certification assures employers that the candidate is fully qualified to design,
implement, and maintain that specific product and its advanced features.
C3 – F5 Certified Solution Expert (F5-CSE)
The Solution Expert focuses on how F5 technologies combine with industry technology to create real-world
business solutions.
C4 – F5 Certified Application Delivery Engineer (F5-CADE)
The Application Delivery Engineer certification exam and requirements are still under development.
C5 – F5 Certified Application Delivery Architect (F5-CADA)
The Application Delivery Architect certification exam and requirements are still under development.
Certificate expiration
F5 certifications are valid for two (2) years. Three months before the expiration date, the holder becomes
149
OPTIMIZING THE SUPPORT EXPERIENCE—Self-help
recertification-eligible and can register for the exam necessary to re-certify. Only the last exam in the highest level
certification achieved needs to be retaken.
Certification beta program
F5 uses beta exams in the creation of all our exams and to maintain their relevancy and accuracy after production.
Beta exams are open to all and give candidates an opportunity to have an impact on the F5 Certified program.
While beta exams are twice as long, they cost less than regular exams and give candidates the chance to leave
feedback on the exam. Beta exams are critical to our exam development process and a great way to change the
F5 Certified program for the better.
Get involved
There are a several ways to get involved with the F5 certification beta program:
•
Beta participation. Interested in taking our beta exams? Contact us at F5Certification@f5.com to learn
more.
•
Exam development. Contact us at F5Certification@f5.com if you’re interested in helping us create our
Certified exams.
•
LinkedIn community. Join us on LinkedIn for answers to frequently asked questions, community developed
resources, and more.
Note: This link takes you to a resource outside of F5, and it is possible that the document may be removed
without our knowledge.
Visit F5 Credential Manager System (certification.f5.com) for information or follow the steps to get registered.
Self-help
F5 offers a number of resources to assist in managing and supporting your F5 systems:
•
AskF5™ (support.f5.com)
•
Downloads (downloads.f5.com) User name and password required.
•
Security Updates (interact.f5.com/AskF5-SubscriptionCenter.html)
•
BIG-IP iHealth® (f5.com/support/tools/ihealth)
•
TechNews (interact.f5.com/AskF5-SubscriptionCenter.html)
•
RSS feeds (https://support.f5.com/csp/article/K9957)
•
DevCentral (devcentral.f5.com/) User name and password required.
•
F5 Training Programs and Education (f5.com/education/training)
150
OPTIMIZING THE SUPPORT EXPERIENCE—Self-help
AskF5
AskF5 (support.f5.com) is a great resource for thousands of articles and other documents to help you manage your
F5 products more effectively. Step-by-step instructions, downloads, and links to additional resources give you the
means to solve known issues quickly and without delay, and to address potential issues before they become
reality.
Whether you want to search the knowledge base to research an issue, or you need the most recent news on your
F5 products, AskF5 is your source for product manuals, operations guides, and release notes, including the
following:
•
F5 announcements
•
Known issues
•
Security advisories
•
Recommended practices
•
Troubleshooting tips
•
How-to documents
•
Changes in behavior
•
Diagnostic and firmware upgrades
•
Hotfix information
•
Product life cycle information
Downloads
Downloads are available from the F5 website. F5 strongly recommends that you keep your F5 software up-to-date,
including hotfixes, security updates, OPSWAT updates, BIG-IP Application Security Manager™ (ASM®) signature
files, and geolocation database updates. All software downloads are available from F5 Downloads (https://
downloads.f5.com).
Security updates
You can receive timely security updates and BIG-IP ASM attack signature updates from F5. When remote
vulnerabilities are discovered, F5 implements, tests, and releases security hotfixes for any vulnerable supported
version, and sends an email alert to the F5 Security mailing list. F5 encourages customers with an active support
account to subscribe to this list. For more information, refer to AskF5 article: K41942608: Overview of AskF5
security advisory articles.
151
OPTIMIZING THE SUPPORT EXPERIENCE—Self-help
BIG-IP iHealth
The BIG-IP iHealth® (iHealth.f5.com) diagnostic viewer is among the most important preventative tools to verify the
proper operation of your BIG-IP system. It ensures hardware and software are functioning at peak efficiency and
helps detect and address issues that may potentially affect F5 systems. BIG-IP iHealth is not integrated within the
BIG-IP system. It is hosted by F5 and can be accessed with any web browser.
F5 recommends you generate a BIG-IP iHealth qkview file on the BIG-IP system and upload it to iHealth on a
weekly basis in order to benefit from the many regularly occurring diagnostic updates. Uploading qkviews to
iHealth also provides F5 technical support with access to your qkviews if you open a support case.
By reviewing the iHealth output, many of the issues commonly experienced by customers can be resolved without
the need for opening a support case with F5.
For more information on running BIG-IP iHealth diagnostics, refer to BIG-IP iHealth in the TMOS Operations
Guide.
TechNews
AskF5 Publications Preference Center provides two email publications to help keep administrators up-to-date on
various F5 updates and other offerings:
•
TechNews Weekly eNewsletter Up-to-date information about product and hotfix releases, new and
updated articles, and new feature notices.
•
TechNews Notifications Do you want to get release information, but not a weekly eNewsletter? Sign up to
get an HTML notification email any time F5 releases a product or hotfix.
•
Security Alerts Receive timely security updates and ASM attack signature updates from F5.
AskF5 recent additions and updates
You can subscribe to F5 RSS feeds to stay informed about new documents pertaining to your installed products or
products of interest. The New and Updated Articles page on AskF5 provides an overview of all the documents
recently added to AskF5.
New and updated articles are published over RSS. You can configure feeds that pertain to specific products,
product versions, and/or document sets. You can also aggregate multiple feeds into your RSS reader to display
one unified list of all selected documents.
DevCentral
DevCentral™ (devcentral.f5.com) is an online forum of F5 employees and customers that provides technical
documentation, discussion forums, blogs, media and more, related to application delivery networking. DevCentral
is a resource for education and advice on F5 technologies and is especially helpful for iRules and iApps®
developers. Access to DevCentral is free, but registration is required.
152
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
As a DevCentral member, you can do the following:
•
Ask forum questions.
•
Rate and comment on content.
•
Contribute to “wikis.”
•
Download lab projects.
•
Join community interest groups.
•
Solve problems and search for information.
•
Attend online community events.
•
View educational videos.
F5 training programs and education
F5 provides training programs and education, including traditional classroom learning opportunities, live online
training, and free, self-paced online courses to help you get the most out of your investment. F5 Training and
Education (f5.com/education/training) provides links to course schedules, pricing, and registration details. It also
has information about alternative training solutions such as virtual and web-based training for those who cannot
attend training in person.
• In-person courses: F5 courses are available in multiple training facilities across five continents. Each one
combines instructor presentations, classroom discussions, and interactive labs. The hands-on learning
environment helps provide a fast track to accomplishing your goals.
• Virtual instructor-led training: Remote on-line courses mirror classroom training. Participants watch the
remote instructors’ live lecture online, participate in discussions, and perform lab exercises using remote
desktop control.
• Free online training: You can use the self-paced Getting Started series of free, web-based courses to learn
how to deploy F5 solutions to address your most common application delivery problems.
Links to more information are provided on F5 Training and Education for those interested in F5 Professional
Certification or a non-accredited Application Delivery Networking Certificate through F5 and the University of
Phoenix.
Note: This link takes you to a resource outside of F5, and it is possible that the document may be removed
without our knowledge.
Engage F5 Support
F5 Support is designed to provide support for specific break-fix issues for customers with active support
contracts. For more information about F5 scope of support, refer to Support Policies.
153
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
F5 Support resources
F5 Support resources are available 24 hours a day, seven days a week, and are distributed around the world in
multiple support centers. Live support is provided by our professional network support engineers. Hours of
availability may vary depending on the service contract with F5.
Contact numbers
Standard, Premium, and Premium Plus Support customers can open and manage cases by calling one of the
contact numbers listed below.
North America
North America: 1-888-882-7535 or (206) 272-6500
Traffix® Support Only: 1-855-849-5673 or (206) 272-5774
Outside North America
Outside North America, Universal Toll-Free: +800 11 ASK 4 F5 or (800 11275 435)
Additional contact numbers by country
Australia: 1800 784 977
China: 010 5923 4123
Egypt: 0800-000-0537
Greece: 00-800-11275435
Hong Kong: 001-800-11275435
India: 000-800-650-1448; 000-800-650-0356 (Bharti Air users)
Indonesia: 001-803-657-904
Israel: 972-37630516
Japan: 81-3-5114-3260 or 0066-33-812670
Malaysia: 1-800-814994
New Zealand: 0800-44-9151
Philippines: 1-800-1-114-2564
Saudi Arabia: 800-844-7835
Singapore: 6411-1800
South Africa: 080-09-88889
154
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
South Korea: 002-800-11275435
Taiwan: 00-800-11275435
Thailand: 001-800-12-0666763
United Arab Emirates: 8000-3570-2437
United Kingdom: 44-(0)8707-744-655
Vietnam: 120-11585
Open a support case
F5 provides several resources to help find solutions to problems. Before opening a support case with F5 technical
support, check to see if the issue you are encountering is already documented.
The following is a list of resources to consult before opening a support case with F5:
•
Deployment guides and white papers provide information about specific deployment configurations.
•
AskF5 provides many articles including known issues, how-to guides, security issues, release notes, and
general information about products. Many of the issues customers encounter are already documented on
this site.
•
BIG-IP iHealth enables customers to upload qkview configuration snapshots in order to verify operation of
any BIG-IP system.
Gather information to open a support case
If your issue cannot be solved using the resources listed, and you need to open a support case, you must first
gather several pieces of important information about your issue. Providing full and accurate information helps
speed the path to resolution. The required information for the majority of situations is summarized below:
•
The serial number or base registration key of the specific BIG-IP system requiring support. For more
information, refer to AskF5 article: K917: Finding the serial number or registration key of your F5 device.
•
A full description of the issue. A clear problem statement is the best tool in helping to troubleshoot issues.
Your description should include as much of the following information as you can provide.
•
Occurrences and changes: The date and times of initial and subsequent recurrences. Did this issue arise at
implementation or later? Were there any changes or updates made to the BIG-IP system prior to the issue
arising? If so, what were they?
•
Symptoms: Ensuring your list of symptoms is as detailed as possible gives more information for support
personnel to correlate with.
•
Scope of the problem: Note whether the problem is system-wide or limited to a particular configuration
feature, service, or element (such as VLAN, interface, application service, virtual server, pool, and so on).
•
BIG-IP component: The feature, configuration element, or service being used when the problem occurred
155
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
(for example: portal access, network access, authentication services, VDI, Exchange).
•
Steps to reproduce: The steps to reproduce the problem as accurately and in as much detail as possible.
Include expected behavior (what should happen) as well as actual behavior (what does happen).
•
Errors: Complete text of any error messages produced.
•
Environment: Current usage of the system. (Is this unit in production? If so, is there currently a workaround
in place?)
•
Browsers: Types and versions, if applicable.
•
Changes: System changes made immediately prior to the problem’s first occurrence. This may include
upgrades, hardware changes, network maintenance, and so on. Have any changes been made to resolve
the problem? If so, what were they?
•
Issue Severity: A description of the impact the issue is having on your site or case severity
• Severity 1: Software or hardware conditions on your F5 device are preventing the execution of critical
business activities. The device does not power up or is not passing traffic.
• Severity 2: Software or hardware conditions on your F5 device are preventing or significantly impairing
high-level commerce or business activities.
• Severity 3: Software or hardware conditions on your F5 device are creating degradation of service or
functionality in normal business or commerce activities.
• Severity 4: Questions regarding configurations (“how to”), troubleshooting non-critical issues, or requests
for product functionality that are not part of the current product feature set.
•
Contact and availability information including alternate contacts authorized to work on the problem with F5
Support. When there are more personnel available to work with F5 Support, the resolution of your issue may
be expedited.
•
Remote access information, if possible.
•
A qkview file obtained while problem symptoms are manifesting. A qkview of the system before the
occurrence is also useful. F5 recommends archiving qkviews regularly. For more information, refer to
BIG-IP iHealth in the TMOS Operations Guide.
•
Product-specific information: Software versions and types of equipment in use.
•
Platform and system. Version and provisioned software modules of the affected system.
To locate platform and system information using tmsh at the command line
•
Type the following command:
tmsh show /sys hardware
Output appears similar to the following example:
<SNIP some of the output>
156
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
Platform
Name
BIG-IP 3900
BIOS Revision
F5 Platform: C106 OBJ-0314-03 BIOS (build: 010) Date: 02/15/12
Base MAC
00:01:d7:be:bf:80
System Information
Type
C106
Chassis Serial
f5-jspv-lzxw
Level 200/400 Part
200-0322-02 REV C
Switchboard Serial
Switchboard Part Revision
Host Board Serial
Host Board Part Revision
To copy software version and build number information at the command line
1. Type the following command:
cat /VERSION
Output appears similar to the following example:
Product: BIG-IP
Version: 11.6.0
Build: 0.0.401
Sequence: 11.6.0.0.0.401.0
BaseBuild: 0.0.401
Edition: Final
Date: Mon Aug 11 21:08:03 PDT 2014
Built: 140811210803
Changelist: 1255500
JobID: 386543
2. Highlight and copy the output information and include it with your support case.
To copy provisioned module information at the command line
1.
Type the following command:
157
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
tmsh list /sys provision
Output appears similar to the following example:
sys provision afm { }
sys provision am { }
sys provision apm {
level nominal
}
sys provision asm { }
sys provision avr { }
sys provision fps { }
sys provision gtm { }
sys provision lc { }
sys provision ltm {
level minimum
}
sys provision pem { }
sys provision swg { }
2.
Highlight and copy the output information and include it with your support case.
Open a support case
If you cannot find the answer to your problem using the resources listed above, you can open a support case
online, using F5 Support (f5.com/support).
Before you open a support case, you need to log in to F5. If you do not have an F5 login, you’ll need to register for
one.
To register for support access
1. Navigate to login.f5.com.
2. Click Register for an F5 Support Account.
3. Enter your email address.
4. Enter your contact information. If you have a support contract, click I have a support contract
and need access to MySupport.
158
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
5. Enter your serial number or registration key in the Serial Number or Registration Key (optional)
field.
Once you’ve submitted your information, your service contract is reviewed. If your information is
accurate you receive an email from MySupport, and you can use this to open your case.
Send information to Support
Once you have the information listed in “Gather information to open a support case”, transfer it to F5 technical
support following the steps in “Share diagnostic files with F5 technical support”. For more information, refer to
AskF5 article: K2486: Providing files to F5 Technical Support.
Share diagnostic files with F5 technical support
F5 technical support may require diagnostic files to help resolve technical support issues. Upload files to F5 using
one of the following two methods:
•
Upload qkview diagnostic files to BIG-IP iHealth (ihealth.f5.com).
•
Upload/downloading files using the F5 Dropbox (dropbox.f5.com). User name and password required.
Upload qkview diagnostic files to BIG-IP iHealth
The preferred method for providing a qkview diagnostic file to F5 Support is to upload the file to the BIG-IP iHealth
website. BIG-IP iHealth allows you to quickly diagnose the health and proper operation of your BIG-IP system. For
more information about using BIG-IP iHealth, refer to the BIG-IP iHealth chapter of the TMOS Operations Guide.
Upload/download files using the F5 Dropbox
The F5 Dropbox site is a widely available file repository for exchanging incoming and outgoing diagnostic files with
the F5 Technical Support team. The dropbox.f5.com site supports HTTP, FTP, and SFTP for transferring files to F5,
and FTP and SFTP for retrieving files from F5.
User name and password
Access to the F5 Dropbox is associated with an open support ticket number with syntax CXXXXXX or
1-########. The user name provided to the F5 Dropbox site is the ticket number, and the password provided is
an email address of a user associated with the ticket.
For example, if joeuser@example.com has opened ticket C123456, he would log in to the F5 Dropbox using the
following information:
User name: C123456
Password: joeuser@example.com
If joeuser@example.com has opened ticket 1-12345678, he would log in to the F5 Dropbox using the following
information:
159
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
User name: 1-12345678 Password: joeuser@example.com
For additional information regarding uploading and downloading files using the F5 Dropbox , refer to AskF5 article
K2486: Providing files to F5 Technical Support.
160
LEGAL NOTICES—
Legal Notices
Trademarks
AAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced Routing,
AFM, APM, Application Acceleration Manager, Application Security Manager, Applications without Constraints,
ARX, AskF5, ASM, BIG-IP, BIG-IP EDGE GATEWAY, BIG-IQ, BIG-IP iControl, Cloud Extender, CloudFucious,
Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DDoS Frontline, DDoS Hybrid
Defender, DDoS SWAT, Defense.net, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client,
Edge Gateway, EDGE MOBILE, EDGE MOBILITY, EdgePortal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5, F5
Agility, F5 iApps, F5[DESIGN], F5 Certified [DESIGN], F5 iControl, F5 LINK CONTROLLER, F5 Networks,
F5SalesXchange [DESIGN], F5Synthesis, f5Synthesis, F5Synthesis[DESIGN], F5 TechXchange [DESIGN], F5
TMOS, Fast Application Proxy, Fast Cache, FCINCO, Global Traffic Manager, GTM, GUARDIAN, Herculon, iApps,
IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iCall, iControl, iHealth, iQuery, iRules,
iRules OnDemand, iSeries, iSession, L7 RateShaping, LC, Link Controller, Local Traffic Manager, LTM, LineRate
Operating System, LineRate Point, LineRate Precision, LineRate Systems [DESIGN], LROS, LTM, Message
Security Manager, MSM, OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol Security
Manager, PSM, Real Traffic Policy Builder, Ready Defense, SalesXchange, ScaleN, Signalling Delivery Controller,
Silverline, Silverline Threat Intelligence, SDC, SSL Acceleration, SSL Everywhere, SSL Orchestrator, SDAC (except
in Japan), StrongBox, SuperVIP, SYN Check, SYNTHESIS, TCP Express, TDR, TechXchange, TMOS, TotALL,
Traffic Management Operating System, Traffix Systems, Traffix Systems (DESIGN), Transparent Data Reduction,
UNITY, VAULT, vCMP, VE F5 [DESIGN], Versafe, Versafe [DESIGN], VIPRION, Virtual Clustered Multiprocessing,
WAF Express, WebSafe, We Make Apps Go [DESIGN], We Make Apps GO, and ZoneRunner, are trademarks or
service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without express written
consent.
All other product and company names herein may be trademarks of their respective owners.
Patents
This product may be protected by one or more patents. Refer to the F5 Patents page (https://www.f5.com/about/
guidelines-policies/patents).
Notice
THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE, SCRIPTING AND COMMAND EXAMPLES, OR THE USE OR OTHER
DEALINGS WITH THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES.
161
LEGAL NOTICES—Copyright
Publication Date
This document was published in June 2017.
Copyright
Copyright © 2013-2017, F5 Networks®, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no
responsibility for the use of this information, nor any infringement of patents or other rights of third parties which
may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other
intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right
to change specifications at any time without notice.
162
CHANGE LIST—
Change List
Date
Chapter/Section
August 2015
All
August 2015
High Availability/Policy
Sync
November 2015
All
July 2016
Change
Updates to formatting
Addition of surveys
Policy sync supports six
devices, not 32 as
previously listed.
Revision for style
Updates for BIG-IP 12.0
Reason
New Operations Guide
style
Error
BIG-IP 12.0 release
Licenses
Added SKU for session
licenses
Missing information,
Use Cases
JavaScript rewrite note
wrong figure
replaced figure 3.7
All
June 2017
Updates for BIG-IP 13.0,
BIG-IP 13.0 release
Updates to AskF5 style
Operations guides
moved to AskF5
Introduction
Figure 1.1 updated
Expanded functionality
represented
Use Cases
Expanded to include new
use cases and Remote New use cases and
Desktop Protocol moved expanded materials
into its own chapter
163
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising