FirePass Controller Handbook

Transcription

FirePass Controller Administrator Guide
®
MAN-0211-00
Service and Support Information
Product Version
This manual applies to the current version of the FirePass® Controller.
Legal Notices
Copyright
Copyright 1999-2006, 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.
Trademarks
F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, iControl, GLOBAL-SITE, SEE-IT, EDGE-FX, FireGuard,
Internet Control Architecture, IP Application Switch, iRules, OneConnect, Packet Velocity, SYN Check,
Control Your World, ZoneRunner, uRoam, FirePass, TrafficShield, WANJet, and WebAccelerator are
registered trademarks or trademarks of F5 Networks, Inc. in the U.S. and certain other countries. All other
trademarks mentioned in this document are the property of their respective owners. F5 Networks'
trademarks may not be used in connection with any product or service except as permitted in writing by
F5.
Export Regulation Notice
This product may include cryptographic software. Under the Export Administration Act, the United States
government may consider it a criminal offense to export this product from the United States.
RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which
case the user may be required to take adequate measures.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant
to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This unit generates, uses, and
can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential area
is likely to cause harmful interference, in which case the user, at his own expense, will be required to take
whatever measures may be required to correct the interference.
Any modifications to this device, unless expressly approved by the manufacturer, can void the user's
authority to operate this equipment under part 15 of the FCC rules.
Canadian Regulatory Compliance
This class A digital apparatus complies with Canadian I CES-003.
Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to
Information Technology products at the time of manufacture.
FirePass® Controller Administrator Guide
i
Acknowledgments
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/).
This product includes cryptographic software written by Eric Young ([email protected])
Third-party software
This product contains software licensed and copyrighted by OPSWAT, Inc. For more information see
OPSWAT on the World Wide Web (http://www.opswat.com).
ii
Table of Contents
Table of Contents
1
Introducing the FirePass Controller
Introducing the FirePass controller ............................................................................................1-1
Introducing FirePass controller features ..........................................................................1-1
Reviewing the FirePass controller models .......................................................................1-3
Finding the FirePass controller software version number ...........................................1-4
Understanding the FirePass controller .............................................................................1-5
Getting started with the FirePass controller ............................................................................1-9
The recommended path .......................................................................................................1-9
Possible configuration scenarios ...................................................................................... 1-10
Using this guide ............................................................................................................................. 1-12
Audience ............................................................................................................................... 1-12
Stylistic conventions in this document ........................................................................... 1-12
Finding help and technical support resources ....................................................................... 1-15
2
Managing Users and Configuring Groups
Introducing master groups and resource groups ....................................................................2-1
Understanding master groups .............................................................................................2-1
Understanding resource groups .........................................................................................2-1
Understanding how master groups and resource groups work together ...............2-2
Understanding user account management options ........................................................2-3
Configuring authentication for users .................................................................................2-4
Creating internal users on the FirePass controller ........................................................2-4
Managing user information in an external data store .............................................................2-6
Managing users in the FirePass controller data store .............................................................2-8
Setting up master groups and users ...........................................................................................2-9
Configuring a master group .............................................................................................. 2-11
Populating master groups with users ............................................................................. 2-13
Understanding entries in the User Management list .................................................. 2-15
Understanding dynamic group mapping .................................................................................. 2-16
Finding procedures for dynamic group mapping ......................................................... 2-16
Understanding dynamic master group mapping ........................................................... 2-17
Understanding how a user is authenticated ................................................................. 2-17
Understanding dynamic resource group mapping ....................................................... 2-18
Understanding how resource groups are assigned ..................................................... 2-19
Using dynamic group mapping ......................................................................................... 2-22
Setting and changing mapping priority ........................................................................... 2-45
Setting up authentication ............................................................................................................ 2-46
Choosing an authentication scheme ............................................................................... 2-46
Setting up internal authentication .................................................................................. 2-49
Setting up RADIUS server authentication ................................................................... 2-50
Setting up LDAP server authentication ........................................................................ 2-51
Setting up HTTP basic authentication to external server ......................................... 2-53
Setting up initial signup on LDAP with subsequent strong internal password ..... 2-53
Setting up Windows domain server authentication ................................................... 2-54
Setting up Active Directory authentication (Kerberos authentication) ................. 2-55
Setting up HTTP form-based authentication ................................................................ 2-55
Setting up client-certificate-based authentication ....................................................... 2-55
Setting up RSA SecurID authentication ......................................................................... 2-61
FirePass®Controller Administrator Guide
v
Table of Contents
Working with resource groups ................................................................................................ 2-63
Creating favorites in resource groups ........................................................................... 2-63
Associating resource groups with users ........................................................................ 2-65
Configuring resource group favorites ............................................................................ 2-66
Impersonating a user .......................................................................................................... 2-67
3
Configuring Endpoint Security
Understanding endpoint security ................................................................................................3-1
Collecting information ..........................................................................................................3-1
Using the inspectors ..............................................................................................................3-2
Using session variables ..........................................................................................................3-5
Performing remediation .......................................................................................................3-7
Protecting resources .............................................................................................................3-8
Understanding protection options .....................................................................................3-8
Understanding protection limitations ............................................................................ 3-10
Using pre-logon sequences ........................................................................................................ 3-11
Understanding pre-logon sequence flow ....................................................................... 3-12
Understanding the visual policy editor .......................................................................... 3-12
Understanding pre-logon sequence elements .............................................................. 3-13
Implementing client system checking ...................................................................................... 3-15
Creating pre-logon sequences to protect resources .......................................................... 3-16
Creating a pre-logon sequence ........................................................................................ 3-16
Using data gathered by pre-logon sequences ............................................................... 3-18
Assigning a protected configuration ............................................................................... 3-19
Using actions in pre-logon sequences ............................................................................ 3-19
Defining rules for actions in pre-logon sequences ...................................................... 3-23
Browser requirements for endpoint security .............................................................. 3-26
User rights requirements for protected workspace and pre-logon inspectors ... 3-26
Creating protected configurations ........................................................................................... 3-27
Protecting resources ................................................................................................................... 3-31
Understanding protection assignment ........................................................................... 3-32
Configuring post-logon protection .......................................................................................... 3-32
Using other kinds of protection ............................................................................................... 3-33
4
Using Server Certificates
Understanding SSL server certificates ........................................................................................4-1
Using server certificates on the FirePass controller ....................................................4-1
Using Certificate Authority-signed SSL server certificates ..........................................4-2
Using self-signed SSL server certificates ...........................................................................4-2
Managing certificates on the FirePass controller .....................................................................4-3
Displaying information on installed certificates ..............................................................4-3
Generating a Certificate Signing Request or self-signed certificate ....................................4-4
Submitting the CSR ...............................................................................................................4-6
Understanding the files generated for the self-signed certificate ...............................4-6
Installing a server certificate ................................................................................................4-6
Associating an SSL server certificate with a web service .............................................4-8
Installing a self-signed certificate on client computers ..................................................4-8
Updating installed server certificates ................................................................................4-9
Deleting installed certificates ........................................................................................... 4-10
Installing and configuring client root certificates .................................................................. 4-11
Using CRLs and OSCP ...................................................................................................... 4-11
Using OCSP to validate client certificates .............................................................................. 4-13
vi
Table of Contents
5
Configuring Network Access
Introducing Network Access .......................................................................................................5-1
Understanding Network Access features ........................................................................5-1
Understanding FirePass controller Network Access ....................................................5-3
Using client applications with Network Access .............................................................5-4
Configuring global Network Access settings ............................................................................5-6
Understanding routing ..........................................................................................................5-9
Configuring global packet filter rules ............................................................................. 5-10
Using overlapping IP address pools ................................................................................ 5-12
Configuring bitrate evaluator parameters ..................................................................... 5-18
Configuring Network Access resource group settings ....................................................... 5-19
Understanding Client Settings options .......................................................................... 5-19
Understanding DNS options ............................................................................................ 5-22
Understanding Hosts options .......................................................................................... 5-22
Understanding Drive Mappings options ........................................................................ 5-23
Understanding Launch Application options .................................................................. 5-23
Understanding IP Group Filters options ....................................................................... 5-25
Understanding Policy Checks options ........................................................................... 5-27
Understanding Customization options .......................................................................... 5-29
Configuring Network Access master group settings .......................................................... 5-37
Customizing the user experience for Network Access connections ..................... 5-38
6
Configuring Application Access
Introducing Application Access ...................................................................................................6-1
Understanding App Tunnels .........................................................................................................6-2
Choosing a static or dynamic App Tunnel .......................................................................6-3
Defining a web application tunnel ......................................................................................6-5
Understanding access restrictions for App Tunnels ......................................................6-6
Defining App Tunnel favorites .....................................................................................................6-7
Creating web application App Tunnel favorites .......................................................... 6-12
Configuring Remote Host and Local Host settings: important considerations ... 6-14
Creating custom App Tunnels ......................................................................................... 6-14
Configuring App Tunnels that open automatically ...................................................... 6-16
Creating static App Tunnels to network file shares ................................................... 6-16
Restricting access to App Tunnels .................................................................................. 6-17
Configuring master group settings for App Tunnels ........................................................... 6-22
Understanding common master group settings for all App Tunnels ...................... 6-22
Understanding master group settings for dynamic and web application tunnels . 6-23
Understanding Legacy Host connections ............................................................................... 6-25
Defining legacy host favorites .......................................................................................... 6-26
Configuring legacy hosts keyboard mapping ................................................................ 6-27
Configuring master group settings for legacy hosts connections ............................ 6-29
Configuring terminal server favorites ..................................................................................... 6-30
Configuring master group settings for terminal server connections ...................... 6-32
Configuring global settings for Application Access .............................................................. 6-35
Handling Windows power-management events .......................................................... 6-35
Configuring client messages for Windows loopback ................................................. 6-35
vii
Table of Contents
7
Configuring Portal Access
Introducing Portal Access .............................................................................................................7-1
Introducing Portal Access features and operation .........................................................7-1
Introducing Portal Access application support ...............................................................7-2
Configuring web applications on the FirePass controller ......................................................7-4
Understanding proxy and cache functionality .................................................................7-5
Defining favorites for Portal Access Web Applications access ...................................7-6
Configuring web applications for minimal rewriting ................................................... 7-10
Configuring NTLM and basic authentication proxy .................................................... 7-14
Configuring split tunneling for Portal Access ............................................................... 7-15
Understanding access control lists for Portal Access ................................................ 7-16
Preserving host names ....................................................................................................... 7-17
Configuring content processing for web applications ................................................ 7-18
Configuring caching and compression ............................................................................ 7-30
Configuring intranet webtop options ............................................................................. 7-32
Preserving page content .................................................................................................... 7-33
Configuring proxy options ................................................................................................ 7-34
Configuring Windows files ......................................................................................................... 7-35
Configuring Windows Files favorites ............................................................................. 7-35
Configuring Windows Files master group settings ..................................................... 7-36
Configuring Mobile E-Mail .......................................................................................................... 7-38
Configuring the LDAP query ............................................................................................ 7-39
Configuring LDAP as the email address source .......................................................... 7-40
Disabling email attachments ............................................................................................. 7-41
Changing where Mobile E-Mail links appear on the webtop .................................... 7-41
Configuring content inspection ................................................................................................ 7-42
Configuring cross site scripting security ....................................................................... 7-42
Configuring SQL injection scanning ................................................................................ 7-44
Configuring buffer overflow protection ........................................................................ 7-46
Configuring anti-virus scanning of uploaded files ........................................................ 7-47
8
Managing and Monitoring the FirePass Controller
Configuring global FirePass controller settings ........................................................................8-1
Maintaining the network configuration settings .....................................................................8-2
Understanding the finalize process ....................................................................................8-3
Understanding the Interfaces tab settings ........................................................................8-5
Configuring VLAN settings ..................................................................................................8-7
Configuring IP addresses and subnets ...............................................................................8-8
Configuring routing tables and rules .................................................................................8-9
Configuring DNS ................................................................................................................. 8-16
Configuring host names ..................................................................................................... 8-17
Configuring web services .................................................................................................. 8-18
Configuring other network settings ............................................................................... 8-23
Configuring access scope .................................................................................................. 8-24
Introducing realms ....................................................................................................................... 8-26
Configuring the Full Access realm .................................................................................. 8-26
Configuring the FirePass controller for realms ........................................................... 8-27
Assigning administrative privileges to a user accounts ............................................... 8-29
Upgrading with administrators configured in versions previous to FirePass 5.4 . 8-30
Using reports inside realms .............................................................................................. 8-30
viii
Table of Contents
Completing other configuration activities .............................................................................. 8-31
Configuring Admin Email ................................................................................................... 8-31
Adding definitions for other types of browsers .......................................................... 8-32
Configuring a new RSA SecurID authentication server (for Native RSA
authentication) ..................................................................................................................... 8-33
Specifying the SMTP email server ................................................................................... 8-37
Configuring an SNMP agent ............................................................................................ 8-38
Specifying HTTP and SSL proxies ................................................................................... 8-39
Specifying the time, time zone, and NTP server ........................................................ 8-40
Performing maintenance ............................................................................................................. 8-43
Managing FirePass controller licenses ............................................................................ 8-43
Backing up and restoring the FirePass controller ....................................................... 8-45
Upgrading controller software ........................................................................................ 8-46
Managing log files ................................................................................................................ 8-49
Configuring for RADIUS accounting .............................................................................. 8-56
Shutting down and restarting the FirePass controller ................................................ 8-57
Using the troubleshooting tools ...................................................................................... 8-59
Monitoring the FirePass controller ......................................................................................... 8-62
Displaying FirePass controller statistics ....................................................................... 8-62
Displaying FirePass controller system health ............................................................... 8-63
Monitoring the load on a FirePass controller .............................................................. 8-65
Customizing the user’s webtop ................................................................................................ 8-66
Configuring for multiple languages ........................................................................................... 8-67
9
Using FirePass Controller Client Components
Downloading client components .................................................................................................9-1
Installing client components on Windows systems .......................................................9-1
Using MSI to preinstall client components ......................................................................9-3
Using the Component Installer ..........................................................................................9-4
Installing the F5 Networks VPN Client for Windows ..................................................9-5
Installing the Networks Client API ....................................................................................9-6
Using Macintosh and Linux clients with the FirePass controller .........................................9-7
Introducing supported Network Access features ..........................................................9-7
Using Macintosh clients ........................................................................................................9-8
Using Linux clients .................................................................................................................9-8
Configuring the starting of applications on Macintosh or Linux clients ....................9-9
Installing the client on Macintosh and Linux systems ................................................. 9-10
Establishing client connections .................................................................................................. 9-11
Understanding Network Access error messages on Macintosh or Linux clients ........ 9-12
Controlling the client using the command-line interface .................................................... 9-14
Using the -start command ................................................................................................ 9-14
Using the -stop command ................................................................................................. 9-17
Using the -info command .................................................................................................. 9-19
Using the -profile command ............................................................................................. 9-23
Using the -help command ................................................................................................. 9-24
Using the command-line interface on the client ................................................................... 9-26
ix
Table of Contents
10
Using FirePass Controller Reports
Overview of FirePass controller reports ............................................................................... 10-1
Using the App Logs report ........................................................................................................ 10-2
Working with the App Logs report ............................................................................... 10-2
Understanding entries in the App Logs report ............................................................ 10-3
Using the Group report ............................................................................................................. 10-4
Working with the Group report .................................................................................... 10-4
Understanding entries in the Group report ................................................................. 10-4
Using HTTP Log reports ............................................................................................................ 10-6
Working with the HTTP Log report .............................................................................. 10-6
Understanding entries in the HTTP Logs report ........................................................ 10-7
Using the Logons report .......................................................................................................... 10-10
Working with the Logons report ................................................................................. 10-10
Understanding entries in the Logons report .............................................................. 10-11
Using the Sessions report ........................................................................................................ 10-12
Working with the Sessions report ............................................................................... 10-12
Understanding entries in the Sessions report ............................................................ 10-13
Using the Summary report ...................................................................................................... 10-16
Working with the Summary report .............................................................................. 10-16
Understanding entries in the Summary report .......................................................... 10-17
Using the System Logs report ................................................................................................. 10-18
Working with the System Logs report ........................................................................ 10-18
Understanding entries in the System Logs report .................................................... 10-18
11
Using FirePass Controllers for Failover
Understanding FirePass controller high availability .............................................................. 11-1
Introducing failover configuration ................................................................................... 11-1
Reviewing the configuration process ............................................................................. 11-2
Introducing a failover member into a production environment .............................. 11-5
Configuring the active FirePass controller ............................................................................. 11-7
Enabling failover on the active controller ..................................................................... 11-7
Configuring the active controller with a self IP address ............................................ 11-9
Configuring the active controller with a shared IP address .................................... 11-10
Configuring web services for the IP addresses of the active controller .............. 11-10
Configuring the active controller’s heartbeat, synchronization, and miscellaneous
settings ................................................................................................................................. 11-13
Configuring the standby FirePass controller ....................................................................... 11-15
Enabling failover on the standby controller ................................................................ 11-16
Configuring the standby controller with a self IP address ...................................... 11-16
Configuring a shared IP address .................................................................................... 11-17
Checking the FQDN ........................................................................................................ 11-17
Configuring DNS server entries .................................................................................... 11-17
Adding and configuring web services, and specify a synchronization service ..... 11-17
Configuring the heartbeat ............................................................................................... 11-17
Finalizing and restarting the active controller ............................................................ 11-17
Accessing a standby controller ...................................................................................... 11-18
Post-configuration tasks ........................................................................................................... 11-19
Starting failover controllers ............................................................................................ 11-19
Verifying the failover configuration ............................................................................... 11-19
Verifying controller identity ........................................................................................... 11-20
Triggering manual failover ............................................................................................... 11-20
x
Table of Contents
12
Using FirePass Controllers in Clusters
Understanding FirePass controller clusters ........................................................................... 12-1
Understanding synchronization in clusters ................................................................... 12-1
Installing FirePass controllers as a cluster ..................................................................... 12-2
Configuring FirePass controller clusters ................................................................................ 12-2
Making configuration changes in clusters ...................................................................... 12-3
Understanding the configuration process ..................................................................... 12-3
Consolidating logs ............................................................................................................... 12-4
Enabling clustering ........................................................................................................................ 12-5
Configuring the primary node .......................................................................................... 12-5
Configuring the secondary nodes ................................................................................... 12-6
Configuring clustering synchronization ................................................................................... 12-7
Configuring a synchronization service ........................................................................... 12-7
Configuring load balancing ....................................................................................................... 12-11
Configuring load balancing on the primary node ...................................................... 12-11
Configuring load balancing on the secondary node .................................................. 12-12
Activating load balancing ................................................................................................. 12-12
Verifying the cluster configuration ................................................................................ 12-13
Verifying the load balancing configuration ............................................................................ 12-13
Managing a cluster configuration ............................................................................................ 12-15
Accessing a secondary controller’s configuration ..................................................... 12-15
Displaying statistics for a FirePass controller cluster ............................................... 12-15
13
Using Web Applications Engine Trace
Understanding Web Applications engine trace .................................................................... 13-1
Using the Web Applications engine trace feature ............................................................... 13-2
Understanding trace files .................................................................................................. 13-3
Analyzing Web Applications engine traces ............................................................................ 13-5
Fixing common problems .................................................................................................. 13-6
A
How-To Examples
Introducing how-to scenarios .....................................................................................................A-1
Denying access to users running Google Desktop Search ..................................................A-2
Creating the Google Desktop Check pre-logon sequence ........................................A-2
Adding the Google Desktop Check action to the pre-logon sequence ..................A-5
Customizing the Google Desktop Check logon-denied message .............................A-7
Denying and allowing logons from specific operating systems and requiring certificates ....
A-10
Rule 1 – Deny Windows 95, Windows 98, and Windows Me connections ........A-10
Rule 2 – Require Windows NT and Windows 2000 clients to log on using the virtual
keyboard ...............................................................................................................................A-14
Rule 3 – Allow logons only from Windows XP, Linux, Pocket PC, and Macintosh
computers that have a valid certificate. .........................................................................A-16
Index
xi
Table of Contents
xiii
Table of Contents
xiv
1
• Introducing the FirePass controller
• Getting started with the FirePass controller
• Using this guide
• Finding help and technical support resources
Introducing the FirePass controller
The F5® Networks FirePass® controller is a network appliance that provides
remote users with secure access to corporate networks, using most standard
Web browsers. The FirePass controller is easy to set up with proper
planning, and installation requires no modification to existing corporate
applications. No configuration or set up is required at the user’s remote
location. If the user’s Web browser can connect to Web sites on the Internet,
then that browser can connect to the FirePass controller.
The FirePass controller provides a web-based alternative to traditional
remote-access technologies such as modem pools, RAS servers, and
IPsec-layer Virtual Private Networks (VPNs). By leveraging the browser as
a standard thin client, the FirePass controller enables your corporation or
organization to extend secure remote access easily and cost-effectively to
anyone connected to the Internet with no special software or configuration
on the remote device. You do not need to make any additions or changes to
the back-end resources being accessed. This approach eliminates the IPsec
VPN support burden, and adds application functionality well beyond mere
connectivity.
The FirePass controller enables full access to network resources, and
provides broad application support, including:
• File servers
• Email
• Intranet and Web applications
• Terminal servers
• Legacy mainframe, AS/400, and Telnet applications
• Proprietary corporate applications
• Client/server applications
Introducing FirePass controller features
All FirePass controller models include the following features:
◆
Standard Web browser support
FirePass controllers can be used with most standard browsers supporting
secure HTTP (also known as HTTPS). These include Internet Explorer®,
Netscape Navigator®, Mozilla®, Safari™, and Firefox.
◆
WAN security
The FirePass controller supports common encryption technologies,
including RC4, Triple DES, and AES. It uses standard SSL encryption
from the client browser to the FirePass controller.
◆
Authentication
The FirePass controller can perform authentication using your own
authentication method, including LDAP directories, Active Directory
and Windows Domain servers, RADIUS servers, to support two-factor
1-1
Chapter 1
(token-based) authentication, support for RSA SecurID and VASCO
Digipass, and integration with single sign-on (SSO) systems such as
Oracle® COREid®, eTrust™ SiteMinder®, and others. The FirePass
controller can also perform basic authentication using its internal data
base. In addition, the controller uses signed digital certificates to
authenticate devices.
◆
Broad application support
The FirePass controller provides access to virtually all corporate and
desktop applications, including email applications such as Outlook Web
Access (OWA) and iNotes, file and intranet server access, client-server
application access, legacy host application access (mainframe, AS/400,
and Telnet), and Terminal Services/Citrix® application access.
◆
Mobile device access
The FirePass controller provides email (OWA and iNotes), file, and
intranet server access from mini-browsers on mobile devices. These
include Internet-enabled (WAP and iMode) telephones, PDAs (PalmOS®
and Pocket PC), and RIM Blackberries™.
◆
Endpoint security
The FirePass controller provides a broad set of endpoint security features
such as a protected workspace, client integrity checking, browser cache
cleaner, secure virtual keyboard, and support for 100+ versions of
antivirus and firewall software.
◆
Visual policy editor
To facilitate policy definition, the FirePass controller provides a built-in
policy editor that is graphically based, which eases management and
supports a visual audit of endpoint security policies.
◆
Administration
The FirePass controller provides a web-based Administrative Console.
The console includes tools for installing and managing the FirePass
controller, managing user and group enrollment, configuring clustering
and failover, certificate generation and installation, and customization of
the remote client user interface.
◆
Audit trail
The FirePass controller provides audit tools including full-session audit
trails, drill-down session queries, and customizable reports and queries.
◆
Client/Server application support
The FirePass controller provides application-specific tunnels for
client-server applications like Microsoft® Outlook®, ERP package
applications, and custom TCP/IP applications.
The FirePass controller also includes Network Access which gives
remote clients full network access comparable to that offered by a
traditional IPsec VPN connection.
◆
1-2
High availability
You can configure FirePass controllers to fail over to standby controllers,
ensuring availability for users.
◆
Scalability
FirePass controller cluster nodes support up to 20,000 users with built-in
load balancing support (4000 and 4100 controllers only). In addition, the
FirePass controller integrates with BIG-IP to support large-scale,
high-performance clustering, which offers universal, secure access for
remote, wireless, and internal network users.
◆
Integration with BIG-IP system
Integration between the FirePass controller and BIG-IP system provides
a uniform framework, an architecture that provides remote, WLAN, and
LAN access control as a unified solution, rather than having to manage
access control and security policies in three different places.
◆
Macintosh and Linux support
The FirePass controller includes Network Access support for Macintosh
and Linux remote clients.
◆
Standalone VPN client and APIs
FirePass controller includes a standalone VPN client and APIs for
building FirePass controller remote access services into applications.
Reviewing the FirePass controller models
The FirePass controller is available in the following models:
◆
FirePass 1000
The FirePass 1000 (Figure 1.1) is a 1U rack-mounted controller designed
for small to medium enterprises, supporting up to 100 concurrent users.
◆
FirePass 1200
for small to medium enterprises, supporting up to 100 concurrent users.
◆
FirePass 4100
for large enterprises, supporting up to 2000 concurrent users, with
clustering expanding support to 20,000.
The 1000. 1200, and 4100 models support failover configuration for high
availability. For more information, see Chapter 11, Using FirePass
Controllers for Failover.
The FirePass 4100 controller also supports clustering, which provides
increased numbers of connections and load balancing. For more
information, see Chapter 12, Using FirePass Controllers in Clusters.
1-3
Chapter 1
Figure 1.1 The FirePass 1000
Finding the FirePass controller software version number
When you work with F5 Networks technical support, you might need to
have the version number of the software running on your FirePass
controller. You can find the software version number on the Welcome page,
available by clicking Device Management and then clicking Welcome
from the navigation pane. The screen presents the version numbers below
the introductory graphic. Following is an example of the version numbers.
Version - FirePass 6.0
Thu, 1 Jun 2006 00:44 PST
URM-6.0-20060601
1-4
Understanding the FirePass controller
The FirePass controller offers remote connection support for Windows®,
Macintosh®, and Linux® clients. The controller supports IP applications on
all three platforms, and includes an open API that third-party application
vendors can use to build secure remote access solutions into their client
applications.
Availability
Unlike IPsec VPNs, the web-based remote access of the FirePass controller
works over all ISP connections, and from behind other firewalls. ISPs
cannot detect and block FirePass controller conversations as they might with
detected IPsec traffic. Failover and clustering options provide high
availability and high capacity. You can cluster FirePass controllers to
support up to 20,000 concurrent connections on a single logical URL
without performance degradation.
Security
The FirePass controller adheres to the highest standards of security.
◆
Endpoint security
The FirePass controller provides a broad set of endpoint security features
such as a protected workspace, client integrity checking, browser cache
cleaner, secure virtual keyboard, and support for 100+ versions of
antivirus and firewall software. Configurable remediation helps
end-users that fail compliance checks to automatically download the
needed client software to meet endpoint security requirements, for
example, the latest antivirus signature files, operating system updates,
and others. The FirePass controller can display a custom message
containing a download link, so end-users can perform their own
remediation, meet compliance requirements, and get access without
requiring having to call the IT help desk
◆
Encryption.
You can get several levels of encryption, depending on the capability of
the client browser and the configuration of FirePass controller security
settings. The controller supports high encryption standards such as Triple
DES and AES, as well as FIPS and hardware encryption accelerator
options.
◆
Authentication
The FirePass controller supports a number of authentication methods.
• An internal user database for user name and password authentication
• Basic HTTP and forms-based authentication methods
• Authentication based on client certificates
• Authentication based on your existing Active Directory, RADIUS,
LDAP, and Windows domain servers
1-5
Chapter 1
As an administrator, you can choose to require different authentication
methods for different groups. Because the FirePass controller supports
RSA SecurID® token-based authentication, and also offers an optional,
built-in implementation of VASCO Digipass®, you can configure
two-factor authentication.
◆
Access Control
You can use the FirePass controller to grant users access to specific
applications on an individual level or on a group level, enabling
role-based access. With FirePass controller’s access controls, you can
restrict individuals and groups to particular internal resources. For
example, partners can have access restricted to an extranet server, while
sales staff are allowed to connect to email, the company intranet, and the
internal customer-tracking system. The FirePass controller administrative
realms allow you to configure administrators access by restricting access
to different features.
◆
Application security
The FirePass controller provides web application protection that guards
against targeted web application attacks such as SQL injection, cross site
scripting (CSS), and cookie manipulation. Built-in antivirus protection
scans built-in web mail attachments and files that are uploaded to the
FirePass controller.
Accessibility
The FirePass controller provides a range of accessibility options.
◆
Full network access
Full network access provides a connection that is always available,
assuming the client machine supports it. Full network access virtually
puts the client machine inside the company network, so that clients
perform operations exactly as if they sat at their corporate desktop
computers.
Typically, an administrator would choose full network access as the
deployment method for client computers that are from a well-known or
trusted source, such as company-provided laptops.
◆
Application tunnel access
Application tunnel access (also called App Tunnels) provides access to
TCP applications that support fixed ports or a range of ports. The client
experience is similar to full network access, but it exposes only specific
functionality available on the local machine.
Typically, an administrator would choose application tunnel access as the
deployment method for client computers that are from a somewhat
trusted source, such as employee-owned equipment.
◆
Specialized application access
Specialized application access provides browser-based interaction with a
set of commonly used functions:
• Mobile email
• Legacy hosts
1-6
• Windows files
• Terminal Servers
Each application was specifically developed for use on the FirePass
controller.
Typically, an administrator would choose specialized application access
as the deployment method for client computers that are from a public or
untrusted source, such as computers that are publicly accessible (for
example, systems in public libraries, at internet cafes, and from other
public portals).
◆
Web application access
Web application access enables interaction to proprietary and custom
applications using the reverse-proxy technology. Essentially, you can use
web application access to create a specialized application, similar to the
ones listed in the Specialized application access list. Because there is no
overarching protocol for web applications, the degree of support
available for any given application varies based on its content and
method of implementation.
For example, applications that use HTML over HTTP integrate relatively
seamlessly. However, if your application contains a lot of customized
script or applets, you may have to work with your interim application to
support web application access.
Ease of use, deployment, maintenance, and management
You can install and configure the FirePass controller quickly. An intuitive,
browser-based client interface means you do not have to train remote access
users. You can upgrade the FirePass controller remotely, over the Internet,
using browser-based administration. Automatic notifications about release
updates prompt you to download new versions when they become available.
You can also add FirePass controller features and capacity over the Internet.
Determining security requirements for users
Whether you maintain users externally or internally, you can specify several
levels of security, as determined by the governing master group and the
resources you want the users to access. Specifying security requirements
ensures that unauthorized users do not have access while authorized users
do. For example, you can:
◆
Require that the clients logging on have a specific certificate. If the
certificate you define is not present, you can prevent logon or provide
access to a restricted set of resources. For more information about
certificates, see Setting up client-certificate-based authentication, on
page 2-55.
1-7
Chapter 1
◆
Gather information about the client environment and grant or restrict
access based on the antivirus software type and update time, the presence
of a firewall, the operating system and browser version, and other factors.
For more information about pre-logon inspection of client systems, see
Implementing client system checking, on page 3-15.
◆
Define protected configurations, a set of safety checks to protect
resources. Protected configurations focus on a specific aspect of
protection, such as unauthorized access, information leaks, virus attacks,
and keystroke loggers. For each criterion, the FirePass controller
provides specific safety measures. For example, to prevent information
leaks, you might specify that the user run inside the protected workspace
or download the cache cleaner to remove cached files when the user logs
off. For more information about protected configurations, see Creating
protected configurations, on page 3-27. At the resource level, you can
apply a definition in one of the following ways:
• To the entire feature
Users must meet certain requirements to use the functionality.
• To one or more resources
Users must meet certain requirements to access a specific server
• To the master group
Users must belong to a specific master group to get access to certain
resources.
• To applications and files
Users must meet certain requirements to have access to specific
applications or files.
1-8
Getting started with the FirePass controller
The FirePass controller is a multi-featured appliance whose interface allows
configuration from any location. You can follow guidelines in The
recommended path, on page 1-9 to set up your FirePass controller, or you
can elect to travel your own path, choosing from the options described in
Possible configuration scenarios, on page 1-10.
The recommended path
If you are new to the FirePass controller, you can follow the path outlined in
this section. This recommended path is designed to guide you through the
most common operations, and includes descriptions to help you complete
the task, as well as links to other sections with related functionality.
1. Determine client-system security requirements
For more information, see Understanding endpoint security, on
page 3-1.
2. Identify authentication mechanism
The FirePass controller supports two types of authentication:
external and internal. For each type, you can select from a number
of authentication methods, depending on your security setup. These
include Active Directory, RADIUS, LDAP, and others.
• If you are not sure which type of authentication you want, review
topics in Choosing an authentication scheme, on page 2-46.
• If you already have an authentication mechanism in place and
you want to use it for verifying user identity, you can read more
at Managing user information in an external data store, on page
2-6.
• If you want to use the FirePass controller database to authenticate
users, you can read more at Managing users in the FirePass
controller data store, on page 2-8.
3. Assign users to groups and map master groups to users
For more information, see Setting up master groups and users, on
page 2-9 and Using dynamic group mapping, on page 2-22.
4. Test user connectivity.
This is a good point to test to make sure that users can connect to the
FirePass controller. To do so, open a new browser window and log
on using a logon account you know exists.
5. Create certificates for user groups
For more information, see Using client certificates, on page 2-56.
6. Configure resource groups with the applications and functionality
you want to provide
For more information, you can review content in several sections:
1-9
Chapter 1
• Configuring global Network Access settings, on page 5-6
• Defining favorites for Portal Access Web Applications access, on
page 7-6
• Configuring terminal server favorites, on page 6-30
• Defining App Tunnel favorites, on page 6-7
• Defining legacy host favorites, on page 6-26
7. Map resource groups to master groups and users
For more information, see Working with resource groups, on page
2-63.
8. Test connectivity and access
For more information, see various sections in Chapter 8, Managing
and Monitoring the FirePass Controller.
9. Ensure availability by configuring failover systems
For more information, see Understanding FirePass controller high
availability, on page 11-1.
10. Expand capacity by configuring clustering
For more information, see Understanding FirePass controller
clusters, on page 12-1.
11. Learn about monitoring and maintaining the FirePass controller
For more information, see Maintaining the network configuration
settings, on page 8-2.
12. Read sample how-to scenarios
For more information, see Introducing how-to scenarios, on page
A-1.
Possible configuration scenarios
There are several ways you can begin the configuration process. You can
start with existing groups, even if you want to manage user authentication
internally.
1 - 10
◆
To authenticate users from an external server
If you already have an authentication mechanism in place and you want
to use it for verifying user identity, you can read more at Managing user
information in an external data store, on page 2-6.
◆
To authenticate users from a database on the FirePass controller
If you want to use the FirePass controller database to authenticate users,
you can read more at Managing users in the FirePass controller data
store, on page 2-8,
◆
To gather information from client systems
If you want to specify requirements for client systems to determine
authentication (whether to grant user access) and authorization (which
resources to grant access to), you can read more at Implementing client
system checking, on page 3-15.
◆
To configure the resources, applications, and functionality you want
to provide
If you prefer to start with the resources, applications, and functionality
that you want to provide to your users, you can read more at the
access-type specific sections:
• Configuring global Network Access settings, on page 5-6
• Defining favorites for Portal Access Web Applications access, on
page 7-6
• Configuring terminal server favorites, on page 6-30
• Defining App Tunnel favorites, on page 6-7
• Defining legacy host favorites, on page 6-26
◆
To configure the internal networking parameters
If you want to prepare the FirePass controller for all of the network
interaction and availability required, such as specifying IP addresses for
web services and setting up failover and clustering members, you can
read more at Maintaining the network configuration settings, on page
8-2, Introducing failover configuration, on page 11-1, and Configuring
FirePass controller clusters, on page 12-2.
◆
To learn about monitoring and maintaining the FirePass controller
If you want to get a head start on understanding the ongoing operations
and logging functionality provided with the FirePass controller, review
content in Monitoring the FirePass controller, on page 8-62, and
Backing up and restoring the FirePass controller, on page 8-45.
◆
To set up certificates on the server
If you are ready to set up and install server certificates for the FirePass
controller, read more in Chapter 4, Using Server Certificates.
◆
To see how-to information on various subjects
If you want exposure to sample configurations that use step-by-step
examples, see Appendix A, How-To Examples.
1 - 11
Chapter 1
Using this guide
This guide provides overview information about the FirePass controller, and
step-by-step instructions for key features.
This guide is available as an Adobe Acrobat file (.pdf) and as an HTML file
on the F5 Networks Technical Support Web site, http://tech.F5.com.
Audience
This guide is intended for system and network administrators who configure
and maintain IT equipment and software. This guide assumes that
administrators have experience working with network configurations.
Stylistic conventions in this document
To help you easily identify and understand certain types of information, this
documentation uses the following stylistic conventions.
Using the solution examples
All examples in this documentation use only private class IP addresses.
When you set up the solutions we describe, you must use valid IP addresses
suitable to your own network in place of our sample addresses.
Identifying new terms
When we first define a new term, the term is shown in bold italic text. For
example, HTTPS is HyperText Transport Protocol (Secure), or secure
HTTP.
Identifying references to objects, names, and commands
We apply bold text to a variety of items to help you easily pick them out of a
block of text. These items include web addresses, IP addresses, utility
names, and portions of commands such as variables and keywords. For
example, the ping command requires that you include at least one
<ip_address> or <fully qualified domain name> variable.
Identifying references to other documents
We use italic text to denote a reference to a specific section or another
document. In references where we provide the name of a book as well as a
specific chapter or section in the book, we show the book name in bold,
italic text, and the chapter/section name in italic text to help quickly
differentiate the two.
1 - 12
For example, you can find information about various FirePass controller
models in the FirePass Controller Getting Started Guide, Chapter 1,
FirePass controller models.
Identifying command syntax
We show actual, complete commands in bold Courier text. Note that we do
not include the corresponding screen prompt, unless the command is shown
in a figure that depicts an entire command line screen. For example, to log
on to the Maintenance Console, type the user name:
maintenance
Table 1.1 explains additional special conventions used in command line
syntax.
Item in text
Description
\
Continue to the next line without typing a line break.
<
>
|
You enter text for the enclosed item. For example, if the command
has <your name>, type your name.
Separates parts of a command.
[
]
...
Syntax inside the brackets is optional.
Indicates that you can type a series of items.
Table 1.1 Command line conventions used in this manual
Additional Conventions
We use a conspicuous note format for a variety of information, ranging from
supplemental to critical.
A Tip suggests ways to make administration easier or faster. For example:
Tip
An easy way to enter a user agent string is to copy and paste the string from
the Logons report.
A Note provides supplemental, helpful information. For example:
Note
If you want users to be able to define their own personal webtop favorites or
preferences, then you must use internal user management.
1 - 13
Chapter 1
An Important note contains important information. For example:
Important
If you are starting up a controller cluster, always start the primary
controller first, or the remaining cluster controllers cannot start properly.
A Warning describes actions that can cause data loss or problems. For
example:
WARNING
If you are configuring failover in a production environment, the order in
which the pair of controllers restart is very important, and can result in data
loss if the two controllers do not restart in the correct order. For more
information, see Introducing a failover member into a production
environment, on page 11-5.
Finding help and technical support resources
You can find additional technical documentation about the FirePass
controller using the following resources:
◆
Getting Started Guide
The FirePass Controller Getting Started Guide is provided as a printed
document in the box with the FirePass controller. The Getting Started
Guide contains all of the information you need to set up and install a new
FirePass controller. You can find a copy of the guide (in PDF and HTML
formats) on the F5 Networks Technical Support Web site,
http://tech.F5.com.
◆
Release notes
Release notes containing the latest information for the current version of
the FirePass controller are available from the Administrative Console. In
the navigation pane, click Device Management, expand Maintenance,
and then click Online Update. A link to Release notes for the current
release is at the top of the screen. Release notes include a list of new
features and enhancements, a list of fixes, and a list of known issues.
You can also find release notes for the FirePass controller in HTML
format on the F5 Networks Technical Support web site,
http://tech.f5.com/home/firepass/. This site includes release notes for
the current, and all previous versions of the FirePass controller.
◆
Online help for FirePass features
You can find help online for virtually all screens on the Administrative
Console. To open the context-sensitive online help, click the Help
button in the upper right of the screen.
◆
1 - 14
Technical support through the World Wide Web
The F5® Networks Technical Support web site, http://tech.f5.com,
provides the latest technical notes, answers to frequently asked questions,
release notes and release note updates, and the Ask F5 natural language
question and answer engine. You can also find Release notes there, and
all the guides in PDF format. To navigate to the Ask F5 site, click the
Ask
button in the upper right of any screen on the FirePass controller
Administrative Console.
1 - 15
Chapter 1
1 - 16
2
• Introducing master groups and resource groups
• Managing user information in an external data store
• Managing users in the FirePass controller data store
• Setting up master groups and users
• Understanding dynamic group mapping
• Setting up authentication
• Working with resource groups
Introducing master groups and resource groups
The FirePass controller uses groups to authenticate users and enable access
to resources, applications, and files. Using multiple groups, you can
configure different authentication schemes and define different access rules
to fit different sets of users. FirePass controller supports two types of
groups: master groups, and resource groups.
Understanding master groups
A master group is a collection of users. It contains authentication settings,
overall security configuration settings for groups of users, network access
filtering policies, user experience (appearance and sequence of the user’s
home page), and, if you are maintaining users on the FirePass controller,
user accounts. Using master groups, you can define sets of users, and to
enforce different authentication requirements and security settings for
different groups. Each user who connects to the FirePass controller is
associated with one master group, and the master group provides the
authentication that defines what the user can access.
You can also configure different user experience settings for users in
different master groups. For example, you can divide users into two groups:
employees who are authenticated against your Active Directory server and
can access almost all resources on your intranet, and partners who are
authenticated against a RADIUS server and can access only a few resources.
Understanding resource groups
A resource group is a collection of resources, access control lists, and
protection criteria, which includes your company intranet servers,
applications, and network shares. Using resource groups, you can define sets
of resources and control access to these resources discretely.
Each resource in a resource group is represented using a special
configuration construct called a favorite. A favorite has all of the
information needed for the client computer to connect to an resource.You
can define several kinds of favorites:
◆
Intranet server favorites
• Network Access connections
• App Tunnel connections
◆
Favorites for various applications
• Terminal Servers connections
• Web applications connections
• Legacy Hosts connections
◆
Network share favorites for Windows files access
2-1
Chapter 2
When a user attempts to log on to the FirePass controller, if the user is
authorized to access a resource, the corresponding favorite appears as a link
on the user’s browser-based home page. The user can click the link to access
the resource.
Understanding how master groups and resource groups work
together
A master group is associated with one or more resource groups. Once the
master group authenticates the user, the user is allowed to access the
resources configured for that master group. You can associate a resource
group with one or more master groups or to individual users. Using resource
groups, you can ensure that only the users who meet the authentication
criteria and security settings requirements configured for the master group
have access to the resource group. This way, you can restrict access to
certain resources based on which master group a user belongs to.
Fundamentally, master groups concern authentication of users who want
access, and resource groups concern the functionality and locations users
can access. Figure 2.1, following, illustrates the relationship between master
groups, resource groups, and favorites categories.
Figure 2.1 Association between users, master groups, resource groups, and favorites categories
2-2
Understanding user account management options
You have a choice when determining the user-management structure of
master groups:
◆
Manage users externally on your corporate servers
This is the recommended method. Using this method, you keep your
user’s information on an external server. The FirePass controller
retrieves the user’s group information from the external server at logon
time. The FirePass controller supports the following methods for
externally managing users:
• RADIUS server
• LDAP server
• Windows® Domain server
• Windows Active Directory® server
• RSA SecurID® technology
For more information, see Managing user information in an external
data store, on page 2-6.
◆
Manage users internally on the FirePass controller
Using this method, you add users to the internal FirePass controller
database. You populate internal master groups with users and user
information manually, using signup-templates, or by user-import
functions. For more information, see Managing users in the FirePass
Note
If you want users to be able to define their own personal webtop favorites or
preferences, then you must manage users internally on the FirePass
controller.
Understanding the best practice for managing users
F5 Networks highly recommends managing users externally using your own
network group structure. First, the user-administration task is much simpler.
Second, managing users externally results in increased FirePass controller
performance because the controller does not have to create as many files on
the system. This is especially important with sites with large numbers of
users and failover configured, since in such cases synchronizing the user
database can be the bottleneck of performance. Finally, although the
FirePass controller has some capability for automating the synchronization
of users (using the master group features signup templates and the
LDAP/Active Directory synchronize options), there are no such issues with
externally managed users.
2-3
Chapter 2
Configuring authentication for users
You have a choice when determining the authentication method for users in
master groups:
• External authentication
Authenticates users with information retrieved from an external source.
You can elect to authenticate users from an external server whether you
manage the users internally on the FirePass controller, or externally on
your network server.
• Internal authentication
Authenticates users with information from local user accounts. You
cannot configure internal authentication for externally managed users.
The FirePass controller authenticates a user based on the authentication
method configured for that user’s master group. The FirePass controller
supports the following authentication methods:
• LDAP server query
• RADIUS server query
• Windows domain server query
• Windows Active Directory server query
• Specified client certificate Organization (O) field, Organization Unit
(OU) field, or string match against Distinguished Name (DN)
• HTTP form-based communication
• RSA SecurID® technology
• HTTP basic authentication
Creating internal users on the FirePass controller
If you want to use the FirePass controller to manage users, you can add user
accounts to master groups by using any of the following methods.
2-4
◆
Manually add users
You can add a single user at a time. This is the least efficient, yet most
controlled method. If you have more than about 100 users, manually
adding users can be extremely time consuming, and result in extensive
administrative requirements. See Understanding user account
management options, on page 2-3.
◆
Import users from an Active Directory or Windows domain server
In some environments, the administrator might prefer to add users to the
FirePass controller, but already has an Active Directory or Windows
domain server structure in place. In this case, you can use your existing
user base as an import source for FirePass controller master groups.
◆
Import users from an LDAP server
Similarly, in an environment that has an LDAP server structure in place,
administrators can use their existing user base as an import source for
FirePass controller master groups.
◆
Import users from a text file
In cases where there is no existing server structure, the internal FirePass
controller database can contain the users. The advantage of using a file is
that you can add many users simultaneously, simplifying the add-user
process.
◆
Use signup templates to automatically add users
For setups using locally managed users, you can use signup templates to
automatically add users to the internal FirePass controller database. See
Using signup templates to add user accounts, on page 2-14.
All of these methods create user accounts in the FirePass controller internal
database. For specific procedures for each of these operations, see the online
help,
2-5
Chapter 2
Managing user information in an external data store
You can use existing user accounts that you have defined on an external
server in your own network environment to authenticate FirePass controller
users. External user management is the recommended user-management
method. The advantage of using an external data store is that you can use the
same server to authenticate FirePass controller users as you use to
authenticate your local network users. Using an external data store for
authentication greatly reduces the administrative effort needed to maintain
user accounts on the FirePass controller, as well as on your internal network
servers. In addition, using an external data store for authentication improves
FirePass controller performance because user accounts are not maintained
on the FirePass controller.
Tip
If you already have an authentication mechanism in place (for example, you
are using the Active Directory service), you can use that mechanism to
manage users of the FirePass controller. Using external user authentication
reduces administration time, and is the simplest client-authentication
method.
For example, if your network uses the Active Directory service, you can
configure the FirePass controller to map to that structure. In this case, the
FirePass controller queries the directory to get user information, and uses
the results to associate each user to a master group as they log on. All
FirePass controller users must be assigned, or mapped, to a master group.
To configure master groups for external users
1. In the navigation pane, click Users, expand Groups, and click
Master Groups.
The Master Groups screen opens.
2. Click the Create new group button.
The Group Management screen opens.
3. In New group name, specify a name for the group.
4. From the Users in group list, select External.
5. From the Authentication method list, select the authentication
method you want to use.
You cannot select Internal database or Initial signup on LDAP
with Subsequence Strong Internal Password as the authentication
method for master groups of external users.
6. Click the Create button.
The master group configuration screen opens with the General tab
selected.
7. To use dynamic group mapping in master groups, check Allow
users to be assigned to this master group using dynamic master
group mapping.
If you do not check this option, the FirePass controller gives the user
2-6
access only to resource groups that are statically assigned to the
master group and individually assigned to the user. To access this
option, you must check the option Determine the user’s master
group dynamically using the master group mapping table on the
Users : Groups : Dynamic Group Mapping screen.
8. To use dynamic group mapping in resource groups, check Allow
resource groups to be assigned to this master group using
dynamic resource group mapping.
If you do not check this option, the FirePass controller gives the user
access only to resource groups that are statically assigned to the
user. To access this option, you must check the option Determine
the user's resource group dynamically using the resource group
mapping table on the Users : Groups : Dynamic Group Mapping
screen.
9. Click the Resource Groups tab, and select the resource groups you
want this master group to access.
You can select one or more resource groups and click Add to make
them accessible to the master group’s users.
10. Finally, click the User Experience tab to customize the look and feel
of the screen for users in this master group.
Tip
You can create new master groups that use settings from existing master
groups by selecting the group from the Copy settings from list when you
create a new group.
2-7
Chapter 2
Managing users in the FirePass controller data store
If you prefer, you can create users in the FirePass controller data store. The
process involves first creating the master groups, and then adding users. You
can add users manually, by importing them from existing external sources,
or by configuring sign-up templates.
Managing users internally is not the recommended method. However, there
are several circumstances in which you might want to use this method.
• Administrators who have no existing user management and
authentication source in place might want to use the FirePass controller
to manage users.
• An administrator might want a single location that lists which users have
access to which resources.
This is an easy way to determine who has individual access to various
devices.
• Some administrators might want to create an administrators-only group
that exists only on the FirePass controller.
This might be effective when the external authentication source is not
available.
• Those administrators who want users to create their own favorites or
change personal preferences, must maintain users locally.
To configure master groups for local users, follow the same steps as needed
for configuring a master groups with external users, as described in the
procedure To configure master groups for external users, on page 2-6.
Note
The FirePass controller has a default master group called Default. You can
use this master group without creating any other master groups, or you can
create master groups to use instead of, or in addition to, the default group.
2-8
Setting up master groups and users
For each master group, you can separately manage users and set up
authentication methods, resources, and other features. This is the
recommended process for setting up groups, user accounts, authentication,
and certificates on the FirePass controller.
◆
Determine the requirements you want for different sets of users.
The FirePass controller uses groups to determine authentication, resource
assignment, and many other features. This is the task at which you should
determine how much access each set of users has. The guidelines defined
in your company’s security policy might help you answer some of these
questions:
• Where will the FirePass controller reside physically and logically in
your network structure?
• What are your company’s authentication requirements? That is, do
you use Active Directory, RADIUS, LDAP, or something else? Will
you use the company’s authentication requirements or develop
something else?
For more information, see Choosing an authentication scheme, on
page 2-46.
• What are the requirements for password length and content?
For more information, see Setting up initial signup on LDAP with
subsequent strong internal password, on page 2-53.
• Who gets access to which resources and who does not?
For more information, see Determining security requirements for
users, on page 1-7.
• What are the endpoint security procedures and penalties for dealing
with information leaks, unauthorized access, and security breaches?
For more information, see Creating protected configurations, on page
3-27.
◆
Create the FirePass controller master groups to correspond to the
requirements you define.
For more information, see Populating master groups with users, on page
2-13.
◆
Configure authentication for each group on the FirePass controller.
For more information, see Setting up authentication, on page 2-46.
◆
Map external groups to internal FirePass controller groups.
For more information, see Understanding dynamic group mapping, on
page 2-16.
You use group mapping under either of the following circumstances:
• You plan to manage users externally. For more information, see
Managing user information in an external data store, on page 2-6.
2-9
Chapter 2
• You plan to have locally managed users, but you want to control their
master group membership dynamically each time they log on to the
FirePass controller. For more information, see Managing users in the
FirePass controller data store, on page 2-8.
You can configure group mapping using any of the following sources.
• Windows Active Directory server
For more information, see Setting up Active Directory
authentication (Kerberos authentication), on page 2-55.
• Windows Domain server (pre-Windows 2000 compatibility)
For more information, see Setting up Windows domain server
authentication, on page 2-54.
• LDAP server
For more information, see Setting up LDAP server
• RADIUS server (including RSA SecurID RADIUS)
For more information, see Setting up RADIUS server
• Client certificate (passwordless)
For more information, see Setting up client-certificate-based
• URI landing page
For more information, see Mapping based on landing URI, on
page 2-39.
Note: Mapping by URI landing page on its own does not verify
users. F5 Networks recommends mapping using external groups
instead.
2 - 10
◆
Add user accounts directly to the FirePass controller database.
If you plan to manage users internally, you can add them manually, by
creating accounts individually or by importing then into the database, and
you can add them automatically using the signup-by-template feature.
For more information, see Managing users in the FirePass controller
data store, on page 2-8, and Using signup templates to add user
accounts, on page 2-14.
◆
If you plan to use client certificate authentication, set up server
certificates specifically for your site, and set up client certificates to
validate clients.
For more information, see Managing certificates on the FirePass
controller, on page 4-3.
◆
Install a client root certificate and certificate revocation list (CRL),
and configure the FirePass controller to validate client certificates
installed on each user’s computer.
You can use client certificates for authentication and to control access to
specific resources. For more information on setting up server and client
certificates, see Managing certificates on the FirePass controller, on
page 4-3.
Configuring a master group
After creating a master group, your next step is to configure the group. You
use the Master Groups screen for these tasks. The Master Groups screen lists
all the master groups, including the default master group. To access the
screen, in the navigation pane, click Users, expand Groups, and click
Master Groups.
The Master Groups screen contains several tabs that provide specific
configuration options. For more information about options on each tab, see
the online help for the Master Groups screen.
◆
General
Presents options that govern how to assign users and resources to the
master group.
◆
Authentication
Presents options for the authentication method the group requires.
◆
Resource Groups
Presents options for assigning resource groups to master groups.
◆
Signup Templates
Presents options for automatically adding users to internal groups
◆
User Experience
Presents options that govern the appearance of the user’s FirePass
controller webtop.
Tip
On many configuration screens, you can switch to a different master group
by selecting a group from the Group list box at the upper left. This is an
easy way to change the master group you are configuring, without returning
to the Master Groups list screen.
Navigating the Master Groups list screen
The Master Groups list screen displays all the master groups, along with
some configuration information. To access the screen, in the navigation
pane, click Users, expand Groups, and click Master Groups. By default,
the master groups list is sorted by group name, but you can sort by
authentication method by clicking the Authentication column heading. You
can click a column entry to open the tabbed Master Group configuration
screen or a user or group management screen.
The columns of the Master Groups list screen provide information about
each master group.
◆
Group Name
Lists the name of each group. You can click a group name to open its
Master Group configuration screen containing options such as how users
and resources are assigned to the group.
2 - 11
Chapter 2
◆
Authentication
Lists the type of authentication the group uses. You can click the
authentication method to open the Master Group configuration screen
containing options such as authentication-specific settings
(Authentication tab).
◆
Resource Groups
Lists the number of resource groups assigned to the master group, and
whether dynamic resource assignment is enabled. You can click an entry
to open the Master Group configuration screen containing options for
adding or removing resource groups for the associated master group.
◆
Signup Template
Shows whether signup templates are enabled (options are: N/A, No, and
Yes). The N/A entry indicates master groups of externally managed
users. You can click a No or Yes entry to open the Master Group
configuration screen containing options such as whether to allow
automatic sign-up by template and others.
Note: You can specify signup template as an optional parameter only for
master groups of internally managed users.
◆
Max concurrent sessions
Contains the number representing the maximum number of sessions
configured for that master group. The default varies depending on the
number of licenses you have for the FirePass controller. You can specify
a different number on the General tab by clicking the associated link,
checking Limit the number of concurrent sessions for this group, and
specifying the number you want. In no case can you specify a number
greater than the number of licenses you have.
◆
Users
Contains an indication of whether the group’s users are maintained
internally (Local) or externally (External). In any group containing
locally managed users, you can click the Local link to display the users.
Note: You cannot view the list of users from master groups with
externally managed users.
◆
Routing Table
Contains an indication of which routing table governs the associated
master group. You can click the link in the column to open the Select
Routing Table screen to select a different table to associate with a master
group. The FirePass controller routes the traffic from users in the master
group according to the routes in the associated routing table.
◆
Delete
Provides links for deleting the associated master group. You cannot
delete the Default master group.
You can use the Back to Users : Groups : Master Groups page link at the
top of the screen to return to the Master Groups list screen. You can also
return to the Master Groups list screen by clicking Master Groups in the
navigation pane.
2 - 12
Managing master groups
Once you have set up the master groups you want, you can manipulate them
in various ways so that they meet the requirements you have,
◆
Use the Master Groups list screen
You can access the Master Groups list screen by navigating to the Users :
Groups : Master Groups screen. The Master Groups list screen is where
you accomplish all of the tasks described in this section.
◆
Create a new master group
You can create a new master group by clicking the Create new group
button at the upper right.
◆
Configure a master group
You can configure a master group by clicking the group name, or by
clicking any link in the following columns: Authentication, Resource
Groups, Signup Template, Max concurrent sessions, or Users.
◆
View the group’s users
You can list the users by clicking the Local link in the Users column.
You can view group members for locally maintained users only.
◆
Delete a master group
You can delete a master group by clicking the associated Delete link.
When you click Delete, the FirePass controller presents a confirmation
prompt in which you can move users to a different master group or to
delete the group’s members. You cannot delete the Default master
group.
Important
If you move internal users from externally authenticated groups to internally
authenticated groups, you must manually specify each user’s password and
any other user information requested on the Users : User Management
screen.
For specific procedures for each of these operations, see the online help,
Populating master groups with users
You can populate master groups with users in the following ways.
◆
Mapping external groups to FirePass controller groups.
You can map your external groups to the FirePass controller’s master
groups.
◆
Importing users from external sources.
You can import users from the following sources:
• LDAP directory
• Windows Domain (NTLM)
• Text files
• Active Directory
2 - 13
Chapter 2
You can then use automatic sign-up and synchronization options to make
sure the group membership stays current.
If you want different settings for sets of users, you can either manage this
through use of multiple master groups (with resource groups statically
assigned to each master group), or with a single master group (and enabling
dynamic group mapping to map individual resource groups to users).
Note
F5 Networks recommends authenticating users externally.
Tip
If you plan to use the same authentication and settings for all users, you can
simply add all users to the existing default master group and just change the
authentication type.
Using signup templates to add user accounts
If you manage users locally, you can configure a signup template to
automatically add the users to the internal group when they log in to the
FirePass controller for the first time. When you elect to use signup
templates, the FirePass controller can display a screen for first-time users to
enter their user name, password, and other information.
To set up signup templates
Master Groups.
The Master group list screen opens.
2. Click one of the existing master group names, or click Create new
group to create a new master group.
3. Click the Signup Templates tab, and check Allow Authenticated
Signup by Template.
You can also check Bypass signup by template form and enter
user information later to allow the user to log on using only the
user name and password. That is, the FirePass controller does not
present a signup template to users, but adds users to the group.
Using this option, you can specify content for the user account at
any time after creation. Sign Up By Template is only available for
those master groups whose user information is stored locally in
FirePass controller database.
Tip
You can switch to a different master group by selecting the group from the
Master Group list at the upper left of any Master Group configuration
screen. This is an easy way to change the master group you are configuring.
2 - 14
If you also use group mapping, the FirePass controller retrieves the user’s
group information and adds the user to the corresponding internal mapped
group, and then presents the signup template as needed. If a user is a
member of several groups on the external server and you have set up
mapping for each group, the FirePass controller adds the user to the first
group it finds that matches a group specified for signup templates.
For more information about group mapping, see Understanding dynamic
group mapping, on page 2-16.
Understanding entries in the User Management list
If you manage users locally, you can use options on the User Management
screen to create and delete individual users, import groups of users, activate
and deactivate user accounts, export user information to a file, configure
user access to resources, and move users to another group. To access the
screen, in the navigation pane, click Users, and click User Management.
You can use links at the top of the list of users to sort users by logon, name,
email, and group. You can specify search-by criteria and strings to find
users and limit the scope and the size of the list of results.
2 - 15
Chapter 2
Understanding dynamic group mapping
Using dynamic group mapping, you can associate a user with a master group
and with resource groups dynamically at user logon time. This functionality
allows the FirePass controller to use your user’s group-based and role-based
policies that you maintain on your existing corporate policy server. If you
are using dynamic group mapping, you only need to change the group-based
policy or roles at your corporate server. During the logon attempt, the
FirePass controller retrieves the user’s current group information and
dynamically associates it with a master group or resource groups.
Note
We recommend that you optimize your mapping table using the fewest
number of mappings to accomplish what you want. The trade-off is
performance-based. Because the FirePass controller retrieves group
mapping information at logon time for every user, a large number of groups
and mappings might slow logon times.
Finding procedures for dynamic group mapping
The FirePass controller dynamic group mapping feature provides support
for several types of mapping operations. You can find a general example as
well as specific procedures for each of the group mapping methods.
For more information, see one or more of the following sections.
• Configuring dynamic master group mapping: an example, on page 2-20
• Configuring dynamic resource group mapping: an example, on page
2-21
• Enabling dynamic group mapping, on page 2-23
• Specifying fallback master groups, on page 2-24
• Completing group mapping configuration, on page 2-25
• Specifying a group mapping method, on page 2-26
For information about one of the specific group mapping methods, see one
or more of the following sections.
• Mapping based on Active Directory or Windows domain controllers,
on page 2-27
• Mapping based on LDAP information, on page 2-32
• Mapping based on client certificates, on page 2-38
• Mapping based on RADIUS groups, on page 2-39
• Mapping based on landing URI, on page 2-39
• Mapping based on virtual hosts, on page 2-42
• Mapping based on session variables, on page 2-43
2 - 16
Understanding dynamic master group mapping
During dynamic master group mapping, the FirePass controller queries the
external group mapping servers and matches the value of the external groups
with the entries in the master group mapping table. If a user matches more
than one entry in the master group mapping table, the FirePass controller
uses the first match it encounters. If the mapping succeeds, then the FirePass
controller authenticates the user by the authentication methods configured
for that master group.
Understanding how a user is authenticated
The FirePass controller goes through a series of activities when it uses
master group mapping to determine to which master group a user belongs.
Then the FirePass controller authenticates the user by whatever
authentication method is configured for that master group. The FirePass
controller steps through the master group mapping process in the following
order:
◆
First, the FirePass controller queries any external servers that are
configured with mapping methods and attempts to match the user to a
master group based on entries in the master mapping table. For example,
if LDAP is the configured mapping method, the FirePass controller sends
a query to the LDAP server to gather the information requested.
◆
Next, the FirePass controller compares the results of the query with each
entry you have specified in the master group mapping table, looking for a
match. At this point, if the system has not identified a master group, the
FirePass controller searches its internal database to determine the user’s
master group information.
◆
When the FirePass controller finds a match, it associates the user with the
master group and prepares for authentication. If a single user matches
more than one master group, as determined by entries in the master
mapping table, the FirePass controller uses the first match it encounters.
You can set the order in which the FirePass controller should perform
group mapping operations by specifying the mapping’s priority number
in the master group mapping table.
◆
If the system has not yet found a match, it can search through the fallback
master groups specified.
Figure 2.2 illustrates the dynamic master group mapping process. You can
find sample mapping procedures in Specifying a group mapping method, on
page 2-26.
2 - 17
Chapter 2
Figure 2.2 The FirePass controller master group mapping process
The Dynamic Group Mapping screen contains text that describes the process
illustrated in Figure 2.2. Dynamic Group Mapping is available under Users :
Groups : Dynamic Group Mapping.
Understanding dynamic resource group mapping
During dynamic resource group mapping, the FirePass controller queries the
external group mapping servers and matches the value of the external groups
against the entries in the resource group mapping table. The user gets an
association for each resource mapping table entry whose resource group
configuration matches. When the FirePass controller finds a match, it
provides the user access to the resource groups associated with the mapped
entries. The FirePass controller then permits the user access to all resources
in all resource groups returned by any of the configured methods, and
presents the resources as favorites on the user’s webtop. If dynamic resource
group mapping fails, the following actions occur:
• If the user belongs to a group whose users are maintained externally, the
FirePass controller does not provude the user access to the resource.
• If the user belongs to a group whose users are maintained in a FirePass
controller resource group, the FirePass controller provides the user
access to only those resource groups that are statically assigned to the
master group and individually assigned to the user.
2 - 18
Understanding how resource groups are assigned
The FirePass controller makes resources available in the following ways:
• From dynamically assigned resource groups
• From resource groups that are statically assigned to the user’s master
group
• From resource groups that are statically assigned to a user
When you enable dynamic resource group mapping, and the user logs on to
the FirePass controller, the FirePass controller completes the following
sequence of events to map a user to available resources:
◆
First, the FirePass controller attempts to use dynamic resource group
mapping to determine which resource groups are assigned to the user. If
the system finds assigned resource groups, the FirePass controller
presents to the user the resources from those groups.
◆
Next, the FirePass controller attempts to determine which resource
groups are statically assigned to a user’s master group. If the system
finds resource groups, the FirePass controller allows the user access to
the resources associated with that master group.
◆
The FirePass controller then attempts to determine which static resource
groups are statically assigned to the user. If the system finds resource
groups, the FirePass controller permits the user access to those statically
assigned resources as well.
◆
Finally, the FirePass controller presents to the user all resource groups
received from this sequence.
Figure 2.2 illustrates the dynamic master group mapping process. You can
find sample mapping procedures in Specifying a group mapping method, on
page 2-26.
2 - 19
Chapter 2
Figure 2.3 The FirePass controller resource group mapping process
Configuring dynamic master group mapping: an example
You define two groups on your corporate policy server: employees and
consultants. You want to authenticate the users in these two groups using
different authentication servers: employees through your own authentication
server, and consultants through a third-party authentication server.
On the FirePass controller, you have two master groups: Employees and
Consultants. You specify an authentication scheme for the Employees
master group that matches your internal network servers. You configure
resource groups with resources that are appropriate for access only by
company employees, and map those resource groups to the Employees
master group.
Similarly, for the Consultants master group, you specify a third-party
authentication scheme, and you configure resource groups with access only
to resources that corporate consultants should access, that is, resources that
2 - 20
are isolated from the corporate network or prevent access to confidential
information. You configure map those resource groups to the Consultants
master group.
Next, you configure mapping entries that associate your external group
Employees with the FirePass controller master group employees, and
Consultants with consultants.
Here is what happens for two users: Maria, an employee, and George, a
consultant.
Whenever Maria tries to log on to the FirePass controller, the FirePass
controller retrieves the group information from your corporate policy server,
maps Maria to the FirePass controller master group Employee, and
authenticates Maria against your authentication server. The FirePass
controller then allows Maria to access all of the resource groups associated
with the master group Employee.
When George tries to log on to the FirePass controller, the FirePass
controller retrieves group information from a third-party source, maps
George to the FirePass controller master group Consultant, and limits
George to only those resource groups that are associated with the master
group Consultant.
If, in the future, George becomes an employee, you do not have to make any
changes on the FirePass controller. You just have to update group
information for George on your corporate policy server, changing it from
consultant to employee.
When George next tries to log on to the FirePass controller, the FirePass
retrieves the group information from your corporate policy server instead of
the third-party source, maps George to the FirePass controller master group
Employee, and authenticates George against your authentication server. The
FirePass controller then allows George to access all of the resource groups
that are associated with the master group Employee.
This example shows that dynamic master group mapping allows you to
dynamically control the authentication, security, and resource assignment
for a user.
Configuring dynamic resource group mapping: an example
Dynamic resource mapping allows you to assign resources dynamically to a
user, based on roles. At logon time, the FirePass controller retrieves
role-based policies (groups) information from your corporate policy server.
The FirePass controller then assigns resources to the user dynamically,
based on the user’s groups.
In this scenario, you have two kinds of users in your marketing division:
staff and managers. Staff can access most of your marketing resources, but
the confidential information on some servers is only accessible to managers.
To use dynamic resource group mapping, you define two resource groups on
the FirePass controller: Staff and Managers. In Staff, you create favorites
that represent the resources appropriate for those users to access. In
Managers, you create favorites that represent all resources.
2 - 21
Chapter 2
Next, you configure the dynamic resource group mapping table to map your
staff group to the FirePass controller Staff group, and your managers group
to the FirePass controller Managers group.
Here is what happens for Joe, a new staff member at your company.
When Joe starts at your company, you create user account information for
him in the staff group. When Joe tries to log on to the FirePass controller,
the FirePass controller retrieves the group value staff from your corporate
policy server. Based on the configured dynamic resource group mapping
entries, the FirePass controller maps the value staff to the FirePass controller
Staff resource group.
Now, Joe can access all of the resources configured for the Staff resource
group.
In this scenario, 12 months later, Joe is doing such good work that he is
promoted to a managerial position. To provide Joe access to the resources
that all managers see, the only thing you need to do is to change Joe’s group
from Staff to Managers on your corporate policy server.
The next time Joe tries to log on, the FirePass controller retrieves the group
value managers from your corporate policy server. Based on the configured
dynamic resource group mapping entries, the FirePass controller maps the
value managers to the FirePass controller Managers resource group, and
gives Joe access to all of the resources available to the Managers resource
group.
This example shows that dynamic resource group mapping allows you to
keep your group-based or role-based policies on your corporate policy
server. You can then configure the FirePass controller to apply these
policies dynamically when the user logs on. If a policy changes, you do not
have to reconfigure the FirePass controller, you can just move the user to a
different group on your corporate server. Because you have defined the
mapping entries, the FirePass controller automatically provides access
correctly, based on the user’s changing role.
Using dynamic group mapping
Dynamic group mapping is accomplished by configuring associations in a
mapping table. The group mapping table serves as a framework to ensure
that the FirePass controller correctly authenticates external users or local
users authenticated externally, and that those users get access to the
appropriate resources.
The FirePass controller maintains a table of associations between external
groups and users and a table of internal master groups and resource groups.
The master mapping table controls the association between users and
master groups, and the resource mapping table controls the association
between users and resource groups.
2 - 22
You can configure dynamic group mapping by completing these tasks.
◆
Enable master group mapping and resource group mapping.
For more information, see Enabling dynamic group mapping, following.
◆
Specify fallback master groups.
For more information, see Specifying fallback master groups, on page
2-24.
◆
Add one or more mapping methods.
For more information, see Specifying a group mapping method, on page
2-26.
◆
Specify the mapping configuration.
For more information, see Completing group mapping configuration, on
page 2-25.
◆
Configure entries in the master mapping table.
For more information, see Completing group mapping configuration, on
page 2-25.
◆
Configure entries in the resource mapping table.
For more information, see Associating resource groups with users, on
page 2-65.
You can use signup templates to have the group mapping functionality
automatically add new users to master groups at logon time. For more
information, see Using signup templates to add user accounts, on page 2-14.
Enabling dynamic group mapping
Dynamic master group mapping is automatically selected for master groups
with external users. By default, group mapping is not selected when you
create master groups with local users. You can specify group mapping when
you create a group, or at any time after the group has been created. Until you
enable dynamic group mapping, you can add users manually, or by
importing them from an external source.
Users that you maintain locally on the FirePass controller can have both
dynamically and statically assigned resource groups.
For dynamic group mapping to succeed, you must specifically enable it for
each master or resource group.
To enable dynamic mapping
Master Groups.
2. Click the group name of the group you want to use in group
mapping.
The screen changes, and you see the General screen for this master
group.
3. Select the option appropriate to the type of group you are mapping.
2 - 23
Chapter 2
• For master groups, select the Allow users to be assigned to this
master group using dynamic master group mapping option.
Selecting this option uses settings on the master group mapping
table to map users to master groups.
• For resource groups, select the Allow resource groups to be
assigned to this master group using dynamic resource group
mapping option.
Selecting this option uses settings on the resource group mapping
table to map users to resource groups.
4. Click the Update button.
Specifying fallback master groups
Since most users belong to several groups in a network structure, using
fallback groups can help direct the FirePass controller to identify a user as
part of a specific master group. In this case, if the FirePass controller cannot
identify the user as part of the first master group in the mapping, it tries the
master groups listed in the fallback master group list, in the order the group
appears in the list.
By default, the FirePass controller adds newly created master groups to the
list of fallback master groups. You can add and remove master groups, and
you can rearrange the order of master groups in the list. Specifying fallback
master groups is part of configuring for dynamic group mapping.
To add a fallback master group
Dynamic Group Mapping.
The Dynamic Group Mapping screen opens.
2. Check the box following Step 3, Determine the user's master
group by attempting to authenticate the user in each of the
fallback master groups.
3. In the Available master groups list, select any master groups you
want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
4. To add a master group as a fallback master group, click Add.
The selected group or groups appear in the Fallback master groups
list.
5. In the Fallback master groups list, select any master groups you
want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
6. Perform an action. The following list contains possible actions.
• To prevent the FirePass controller from using the master group
selected as fallback master group, click Remove.
2 - 24
• To position the selected master group so that the FirePass
controller uses it earlier in the dynamic group mapping process,
click Move Up.
• To position the selected master group so that the FirePass
controller uses it later in the dynamic group mapping process,
click Move Down.
Completing group mapping configuration
Once you enable dynamic group mapping, you can proceed to select the
mapping method you plan to use (see Specifying a group mapping method,
on page 2-26), configure the request for user information (see Completing
group mapping configuration, on page 2-25), and add entries to the master
group mapping table and the resource group mapping table (see the section
relating to the type of mapping you are configuring). When you complete
these tasks, the FirePass controller can perform dynamic group mapping.
To configure dynamic group mapping
The Group mapping sequence screen opens.
2. Check or clear the options you want to create the mapping sequence.
3. If you plan to have fallback groups for mapping users, in Step 3, add
and order master groups to the Fallback master groups list.
4. If you plan to have dynamic resource group mapping, check the
option in the Resource Groups Mapping Sequence section.
5. Click the Group mapping methods tab.
The Group mapping methods screen opens.
6. From the mapping methods list, select the method you want, and
click Add mapping method.
The new method is added to the list. If the method is already added,
it is not present in the list. For more information, see Specifying a
group mapping method, on page 2-26.
7. Click the Request configuration tab.
The Request configuration screen opens.
8. From the Select method to configure request list, select the
method you plan to use for group mapping, and then click Switch.
The screen refreshes to reveal options that are relevant to the
method you selected.
9. Configure the settings that reflect your external group and network
structure, and then click the Update button.
You must configure settings so that the FirePass controller can send
the request for user information to the appropriate server on your
network. For more information, see Completing group mapping
configuration, on page 2-25.
2 - 25
Chapter 2
10. Click the Master mapping table tab.
The Master mapping table screen opens.
11. From the Mapping Method list, select the type of mapping table
entry you want to create, and click Add.
The master mapping table screen opens for the mapping method you
added.
12. Specify the mappings you want, and then click Add.
The Master mapping table screen opens, showing the mapping you
added.
This is where you add master mapping entries. For more
information, see the section that describes configuring mappings
based on the method you are using. For example, if you are mapping
using the LDAP (user object) method, see To add the LDAP user
object mapping method, on page 2-33.
13. Click the Resource mapping table tab.
The Resource mapping table screen opens.
14. From Mapping Method, select the type of mapping table you want
to create, and then click Add.
The Resource mapping table screen opens for the mapping method
you added.
15. Specify the mappings you want, and then click Add.
The Resource mapping table screen opens, showing the mapping
you added.
This is where you add resource mapping entries. For more
information, see the section that describes mappings based on the
method you are using.
Specifying a group mapping method
You can define how the FirePass controller gets authentication information
from the associated server by specifying fields and choosing settings when
configuring the mapping method.
The options and settings you configure depend on your external network
setup. The FirePass controller supports the following types of group
mapping configurations:
• Active Directory or Windows domain group mapping
For more information, see Mapping based on Active Directory or
Windows domain controllers, following.
• LDAP information mapping (user object, group object, or filter mapping)
For more information, see Mapping based on LDAP information, on
page 2-32.
• Client Certificate mapping
For more information, see Mapping based on client certificates, on page
2-38.
2 - 26
• RADIUS group mapping
For more information, see Mapping based on RADIUS groups, on page
2-39.
• Landing URI mapping
For more information, see Mapping based on landing URI, on page 2-39.
• Virtual Host mapping
For more information, see Mapping based on virtual hosts, on page 2-42.
• Session Variable mapping
For more information, see Mapping based on session variables, on page
2-43.
When you add a Windows Domain or Active Directory mapping, or any of
three LDAP-based mapping, the system provides a link for configuring the
mapping method. You can read more about configuring mapping methods in
the procedure for each mapping type.
Note
A group’s authentication method and group mapping type do not have to
match, although they can and probably do.
Mapping based on Active Directory or Windows domain controllers
If your external network structure uses Active Directory or Windows
domain groups, you can use the FirePass controller group mapping function
to take advantage of that structure. The system provides a method for
mapping groups within an Active Directory to FirePass controller master
groups. Use the Active Directory method with Windows 2000 and later
domain controllers. Use the Windows domain controllers method against
pre-Windows 2000 servers, or when you have a mix of Windows platforms
in your environment.
Within an Active Directory or Windows domain, there are usually a number
of groups defined, with users belonging to one or more of these groups. You
can map existing master and resource groups directly to these Active
Directory or Windows domain groups. When a user attempts to log on to the
FirePass controller, the domain queries your external Active Directory or
Windows domain groups to determine what groups contain the user. The
FirePass controller looks for matches in its dynamic group mapping
framework. When it finds a match, the FirePass controller authenticates the
user and allows access to the appropriate resources.
When mapping a user to one or more resource groups, the FirePass
controller attempts to match all domain groups against the configured
resource group mapping, and the user is assigned one or more resource
groups based on any matches.
Configuring Active Directory-based mapping
If you use Active Directory for your user database, you can configure the
FirePass controller to map users based on Active Directory groups.
2 - 27
Chapter 2
Configuring Active Directory-based mapping involves three procedures:
adding the Active Directory mapping method, mapping the Active Directory
to a FirePass controller master group, and mapping the Active Directory to a
FirePass controller resource group.
To add the Active Directory mapping method
6. From the mapping methods list, select Active Directory, and click
Add mapping method.
The new method is added to the table. If the table already contains a
mapping method of this type, the list contains no Active Directory
item.
7. Click the Configure link to the right of the entry in the Mapping
methods table.
The Mapping methods configuration screen opens.
8. In Domain name, type the Domain name for the Active Directory
to use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in
Domain name. Domain name is a required parameter.
9. In Kerberos server name, type the Kerberos server name or IP
address.
Kerberos server name is an optional parameter.
10. In WINS server IP address, type the WINS server IP address.
WINS server IP address is an optional parameter.
11. In Domain admin name and Domain admin password, type a user
name and password that has Active Directory administrative
permissions.
Domain admin name and Domain admin password are required
parameters.
12. To use a second Active Directory server, check Use a secondary
AD server.
The screen changes to reveal additional options.
address.
2 - 28
15. To use a third Active Directory server, check Use a tertiary AD
server.
address.
18. To limit Active Directory group mapping to the user’s primary
domain, check Only use Active Directory primary group for
mapping.
19. To configure options for synchronizing the FirePass controller
database with the external Active Directory, check Synchronize
FirePass user database with Active Directory.
• From the Action list, select an option:
Deactivate FirePass account if user is not in Active Directory
or
Delete FirePass account if user is not in Active Directory
• Check Notify by e-mail to have the system inform the user of the
deactivation or deletion operation.
• In Check interval, specify the number of minutes to wait
between synchronization operations.
20. To update user information in internal FirePass controller database
records, check Update user information from Active Directory.
• Check Map first name to update the first name.
• Check Map last name to update the last name.
• Check Map e-mail to update the e-mail address.
• Check Allow user to edit personal information obtained from
Active Directory to allow the user edit access to Active
Directory information.
21. Click Update to save your settings.
22. Continue with the following procedure.
To configure the Active Directory mapping table
1. Complete the previous procedure.
2. Click the Master group mapping table tab.
The Master group mapping table screen opens.
3. From the Mapping Methods list, select Active Directory, and click
Add.
Note: If there is no Active Directory item, click the Group mapping
methods tab, and add the Active Directory mapping method first.
2 - 29
Chapter 2
4. In the box in the Active Directory Group column, specify the Active
Directory group you want to map.
5. From the list in the FirePass group column, select the group you
want to map to.
6. Click Add to save your mappings.
7. Configure resource group mapping.
The steps for configuring resource group mapping are the same as
those for configuring master group mapping.
Note
Instead of specifying each Active Directory group individually, you can
have the system retrieve the external groups, but this method is
recommended if you have fewer than several hundred groups.
Configuring Windows domain-based mapping
You can use Windows domain-based authentication in two ways.
◆
Native NTLM
If you provide domain administrative credentials when configuring
Windows domain authentication, then the FirePass controller performs
authentication using native NTLM. You can use this method to add a
machine account for itself, join the domain, and create a one-way,
Windows NT 4.0-style, trust relationship with the Primary Domain
Controller (PDC).
◆
Basic
If you do not provide domain administrative credentials when
configuring Windows domain authentication, then the FirePass controller
authentication mechanism connects to the PDC's netlogon share using
the user’s credentials, to determine whether the user has a valid account
within the domain.
If you use Windows domain for your user database, you can configure the
FirePass controller to map users based on Windows domain groups.
Configuring Windows domain-based mapping involves three procedures:
adding the Windows domain mapping method, mapping the Windows
domain group to a FirePass controller master group, and mapping the
Windows domain to a FirePass controller resource group.
To add the Windows domain mapping method
2 - 30
6. From the mapping methods list, select Windows Domain, and click
Add mapping method.
mapping method of this type, the list contains no Windows Domain
item.
methods table.
8. In Domain name, type the Domain name for the Windows domain
to use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in
Domain name. Domain name is a required parameter.
9. In PDC server name, type the name of the Primary Domain
Controller (PDC).
PDC server name is an optional parameter.
WINS server IP address is an optional parameter.
11. To have the FirePass controller join the Windows domain, check
Join Windows domain.
12. In Domain admin name and Domain admin password, type a user
name and password that has Windows domain administrative
permissions.
Domain admin name and Domain admin password are required
parameters.
To configure the Windows domain mapping table
3. From the Mapping Methods list, select Windows Domain, and
click Add.
Note: If there is no Windows Domain item, click the Group
mapping methods tab, and add the Windows Domain mapping
method first.
4. In the box in the Windows Domain Group column, specify the
Windows domain group you want to map.
2 - 31
Chapter 2
want to map to.
Note
Instead of specifying each Windows domain group individually, you can
have the system retrieve the external groups, but this method is
recommended if you have fewer than several hundred groups.
Mapping based on LDAP information
If your external network structure uses LDAP to store user information, you
can use the FirePass controller group mapping function to take advantage of
that structure. LDAP-based group mapping automatically synchronizes
changes on the LDAP server with group functionality on the FirePass
controller. For example, if you move a user to a different group on the
LDAP server, the FirePass controller automatically provides the user with
access to the new set of resources the next time the user logs on.
If you use a signup template for new FirePass controller users, group
mapping can also have the FirePass controller query the external server for
each user’s group membership, and automatically associate the user to the
mapped master and resource groups on the FirePass controller.
You can use LDAP in several ways.
• Mapping based on an LDAP user object attribute
For more information, see Mapping based on LDAP information from a
user object, following.
• Mapping based on the LDAP group object that describes the user's group
For more information, see Mapping based on LDAP information from a
group object, on page 2-34
• Mapping based on a filter you specify
For more information, see Mapping based on an LDAP filter, on page
2-36
You can use one, two, or all three modes simultaneously.
Important
In the request configuration, you can specify an LDAP port and configure
the FirePass controller to use SSL for the query operation. If you use LDAP
authentication over SSL, be sure that the host name you specify exactly
matches the host name on your LDAP server's certificate.
When you specify a query template for the request to use when searching for
a user, it must be a valid LDAP query expression.
2 - 32
Mapping based on LDAP information from a user object
If you have LDAP configurations that use a specific attribute as the unique
identifier for the user, you can configure group mapping based on that
attribute. For example, if your LDAP server uses an LDAP attribute called
userPrincipalName, you could specify that when you configure the
request.
Configuring LDAP user object-based mapping involves three procedures:
adding the LDAP user object mapping method, mapping the LDAP user
object to a FirePass controller master group, and mapping the LDAP user
object to a FirePass controller resource group.
To add the LDAP user object mapping method
6. From the mapping methods list, select LDAP (user object), and
mapping method of this type, the list contains no LDAP (user
object) item.
methods table.
8. In the LDAP server box, specify your user DN. For example
CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
9. In the Query LDAP user object area, select the method you want the
FirePass controller to use to query the external LDAP server.
• If you select the Get user DN using template option, click
Update, and type the user’s entry in Template. For example,
cn=%logon%,dc=eng,dc=net,dc=com
• If you select the Get user DN using query option, click Update,
and specify the base DN in Search Base DN. For example:
CN=Users,dc=eng,dc=net,dc=com
And specify the search string in Query template. For example:
&(sAMAccountName=%logon%)
2 - 33
Chapter 2
You can use %logon% in the template to have the FirePass
controller insert the user’s logon name into the query. For example,
if you specify as the template
&(objectclass=person)(cn=%logon%), and the user’s name is
"george", at logon time the FirePass controller sends the actual
query: &(objectclass=person)(cn=george).
10. In the Fetch group information from LDAP user object area, define
the attributes to use to map the group. For example, memberOf.
You can use multiple attributes, each one on a separate line.
To configure the LDAP user object mapping table
3. From the Mapping Methods list, select LDAP (user object), and
click Add.
Note: If there is no LDAP (user object) item, click the Group
mapping methods tab, and add the LDAP mapping method first.
4. From Attribute, select the attribute you want to map to.
5. In the Attribute value column, specify the string for the FirePass
controller to use for mapping.
Note: You can instead map the LDAP user attribute directly to a
FirePass controller master group name by checking the Map
verbatim box. In this case, the group names must match exactly. In
this case, the FirePass controller removes the fields in the Attribute
value and FirePass Group columns.
want to map to the users returned by the filter expression.
Mapping based on LDAP information from a group object
If you have an LDAP configuration that uses a group object to organize
users, you can configure group mapping based on that structure. For
example, you can use the user interface to create new groups, or you can use
existing groups. Your configuration mechanism must have a group object in
your LDAP schema to use for mapping groups. The group should have at
least two multi-valued attributes for its members.
2 - 34
Configuring LDAP group object-based mapping involves three procedures:
adding the LDAP group object mapping method, mapping the LDAP group
object to a FirePass controller master group, and mapping the LDAP group
object to a FirePass controller resource group.
To add the LDAP group object mapping method
6. From the mapping methods list, select LDAP (group object), and
mapping method of this type, the list contains no LDAP (group
object) item.
methods table.
8. In the LDAP server box, specify your user DN. For example
9. In the Fetch group information from LDAP group object area,
specify the attributes in the appropriate box.
• The Static members attribute relates to objects with
multi-valued membership attributes such as the attribute that
contains the list of the user’s DNs, for example, groupofNames,
groupofUniqueNames.
• The Dynamic members attribute determines membership by
executing an LDAP URL, for example, groupOfURLs, or an
LDAP query that specifies criteria for a group’s membership.
Note: There is no group object, as such. That is, the LDAP URL
exists only in the application that is using it.
To configure the LDAP group object Master group
mapping table
2 - 35
Chapter 2
3. From the Mapping Methods list, select LDAP (group object), and
click Add.
Note: If there is no LDAP (group object) item, click the Group
mapping methods tab, and add the LDAP mapping method first.
4. In the LDAP group object DN column, type the group object DN
you want to map from the LDAP group to the FirePass group.
5. From FirePass group, select the group you want to map to the
specified LDAP group.
Mapping based on an LDAP filter
If you have discrete groups of users that you have configured with an
attribute other than the user attributes and you do not use a group object
implementation of LDAP, the LDAP filter option is the option to configure.
You can configure the mapping of LDAP groups based on results returned
by sending a query containing an LDAP filter.
Within a set of defined Windows domain groups, there are usually logical
divisions. For example, you may have a group whose users consist of
regular employees and consultants. The type and breadth of access allowed
for each division within the group usually varies. For example, you might
give regular employees access to internal human resources services, and
prevent consultants from having the same access. If your LDAP structure
matches this organization, you can accomplish this access division using
filters. In this case, you define the filter to map to a specific master group.
Configuring LDAP filter-based mapping involves three procedures: adding
the LDAP filter mapping method, mapping the LDAP filter to a FirePass
controller master group, and mapping the LDAP filter to a FirePass
controller resource group.
To add the LDAP filter mapping method
2 - 36
6. From the mapping methods list, select LDAP (filter), and click Add
mapping method.
mapping method of this type, the list contains no LDAP (filter)
item.
methods table.
8. In the LDAP server box, specify the fully qualified domain name
(FQDN) of the LDAP server.
9. In the LDAP port box, specify the port you want to use.
The default is 389 for an LDAP connection, and 636 for a secure
LDAP connection.
10. In the User DN box, specify the user DN. For example
To configure the LDAP filter Master group mapping table
3. From the Mapping Methods list, select LDAP (filter), and click
Add.
Note: If there is no LDAP (filter) item, click the Group mapping
methods tab, and add the LDAP mapping method first.
4. In the box in the LDAP filter column, specify the filter you want to
use to define FirePass group membership.
You can use %logon% in the filter expression to have the FirePass
controller insert the user’s logon name into the query. For example,
if you specify as the template
&(objectclass=person)(cn=%logon%), and the user’s name is
"george", at logon time the FirePass controller sends the actual
query: &(objectclass=person)(cn=george).
want mapped to the users returned by the filter expression.
2 - 37
Chapter 2
Most Active Directory objects use the cn property as their naming attribute.
Some objects, however, use a naming attribute other than cn. For example, a
domain controller uses the domainDNS property for the naming attribute,
and an organizational unit uses the organizationalUnit property for the
naming attribute. To avoid having to use a different naming attribute for
different object types, you should use the name property, which contains the
relative distinguished name of the object, to search for objects by name.
For example,
&(&(objectClass=user)(objectCategory=person))(|(name=Sales*)(name
=Marketing*))
Mapping based on client certificates
For users with client certificates, you can use the Organization (O) or
Organizational Unit (OU) attribute from the certificate’s issuer or subject
Distinguished Name (DN) to map the user to a FirePass master group or to
one or more resource groups.
It is also possible to use a substring of the issuer or subject DN to map the
user to a FirePass controller group. For example, a typical subject DN might
appear as follows:
/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/ema
[email protected]
For this case, you can specify L=MyCity to map MyCity to a particular
FirePass controller master or resource group.
Configuring client certificate-based mapping involves three procedures:
adding the Client Certificate mapping method, mapping a client certificate
attribute to a FirePass controller master group, and mapping the client
certificate to a FirePass controller resource group.
To configure the client certificate Master mapping table
6. From the mapping methods list, select Client Certificate, and click
Add mapping method.
mapping method of this type, the list contains no Client Certificate
item.
2 - 38
8. From the Mapping methods list, select Client Certificate, and then
click Add.
The associated Master group mapping table opens.
Note: If there is no Client Certificate item, click the Group mapping
methods tab, and add the client certificate mapping method first.
9. From the list in the Attribute column, select the certificate attribute
you want to use for mapping.
10. In the box in the Value column, specify the string for the FirePass
controller to map to.
Note: You can also map the user’s client certificate attribute
directly to a FirePass controller master group by checking the box
in the Map verbatim column. In this case, the FirePass controller
removes the Value and FirePass Group columns. For example, if
the box in Map verbatim is checked, and you select Subject
Organizational Unit (OU), then the FirePass controller maps all
client certificates configured as OU=MyDept to the master group
named MyDept.
want to map to the associated users.
Mapping based on RADIUS groups
You can map external RADIUS groups directly to existing master and
resource groups. Then, when a user logs on to the FirePass controller, the
FirePass controller queries the external RADIUS server to retrieve the list of
groups to which the user belongs. The FirePass controller attempts to match
the retrieved external RADIUS groups against the configured mapping.
The FirePass controller retrieves the external RADIUS group information
from an attribute returned from the RADIUS user profile. This attribute
contains the external RADIUS group list. The FirePass controller parses the
return value to retrieve the external group information in various formats.
For step-by-step procedures on configuring RADIUS group mapping, see
the online help for the Users : Groups : Dynamic Group Mapping screen.
Mapping based on landing URI
A URI is a Uniform Resource Identifier. In the FirePass controller context,
URI means the fully-qualified domain name, followed by
/<uri-specific_path>. For URI-based customization, URIs are defined
inside of the FirePass controller. You can create customized FirePass
controller user interfaces for different URIs. By configuring URI-based
2 - 39
Chapter 2
customization, you can present a different look and feel depending on the
URI the user specifies when logging on. This is similar to mapping based on
virtual hosts.
Important
You cannot simultaneously use virtual-host based dynamic group mapping
and landing URI-based dynamic group mapping.
From a user standpoint, URI-based customization is maintained by a cookie.
Once a user establishes a session using a URI that gets customized, then all
subsequent FirePass controller sessions started in that browser use the same
customization, even if the user specifies the domain name alone (for
example, www.siterequest.com), or the domain name qualified by a
redirect page (for example, www.siterequest.com/my.logon.php3). To end
URI customization, the user must start a new browser session.
If you configure URI-based customization, you can use it as a basis for the
group mapping. URI-based mapping, you map a customized URI to a
specific master group. Using URI-based mapping, you can map users to
different master groups or assign them to different resource groups based on
the landing URI used by the users to log on to the FirePass controller.
For example, a FirePass controller might have two landing URI’s
configured: outlook and CRM. To support URI-based master group
mapping, the administrator creates two mappings in the Master group
mapping table. To support URI-based resource group mapping, the
administrator creates two mappings in the Resource group mapping table.
Users who log on to www.sitrerequest.com/outlook receive access to one
set of master and resource groups, which includes access to outlook. Users
who log on to www.siterequest.com/crm receive another set of master and
resource groups, which includes access to CRM.
Configuring landing URI-based mapping involves four procedures: adding
the Landing URI mapping method, specifying the landing URI, mapping the
landing URI to a FirePass controller master group, and mapping the landing
URI to a FirePass controller resource group.
To add the Landing URI mapping method
2 - 40
6. From the mapping methods list, select Landing URI, and click Add
mapping method.
mapping method of this type, the list contains no Landing URI item.
To specify the Landing URI
2. Click the link Click to configure landing URIs.
The Device Management : Customization screen opens with the
URI-based Customization tab active.
3. In the Create Landing URI box, type the URI you want to map.
The URI you specify must be alphanumeric and cannot contain
spaces. Type only the portion of the URI that follows the domain
name in the URL. For example, to create a URI consisting of
www.siterequest.com/partners, type partners in the box.
4. Click Apply.
The Configuring URIs screen opens.
5. Select and specify the settings you want, and click the Update
button corresponding to each configuration you make.
6. When you have finished, click the link Back to Users : Groups :
Dynamic Group Mapping page.
The Dynamic Group Mapping screen opens with the Group
mapping methods tab active.
To map the URI to a FirePass controller group
3. From the Mapping Methods list, select Landing URI, and click
Add.
Note: If there is no Landing URI item, click the Group mapping
methods tab, and add the Landing URI mapping method first.
4. From each list in the FirePass group column, select a group for
mapping to the URI.
2 - 41
Chapter 2
Mapping based on virtual hosts
In the FirePass controller context, a virtual host means the domain name or
IP address that users specify when logging on to a web service you create on
a virtual IP. When you want to segment users based on the virtual host they
are requesting, you can use virtual host information to dynamically map
users to a master group or resource group.
You can create customized user interfaces for different virtual servers. By
configuring virtual host-based customization, you can present a different
look and feel depending on the virtual host address the user specifies when
logging on. This is similar to URI-based mapping.
Important
You cannot simultaneously use virtual-host based dynamic group mapping
and landing URI-based dynamic group mapping.
A virtual server can be one of the following things.
• An additional IP address that resolves to the FirePass controller, plus a
user web service within the FirePass controller, configured on that IP
address
• A distinct host name, configured on your DNS to resolve to the same IP
address
For virtual servers, you can define one customization for a single IP address.
URI-based customization takes precedence over virtual host customization.
Virtual host customization takes precedence over the default, global
customization.
Configuring virtual host-based mapping involves three procedures: adding
the Virtual Host mapping method, mapping the virtual host to a FirePass
controller group, and mapping the URI to a FirePass controller resource
group.
To add the Virtual Host mapping method
2 - 42
6. From the mapping methods list, select Virtual Host, and click Add
mapping method.
mapping method of this type, the list contains no Virtual Host item.
To map the virtual host to a FirePass controller group
3. From the Mapping Methods list, select Virtual Host, and click
Add.
Note: If there is no Virtual Host item, click the Group mapping
methods tab, and add the Virtual Host mapping method first.
mapping to the virtual host.
Mapping based on session variables
Creating dynamic group mapping with session variables is particularly
useful to mapping based on user information. You can use the following
types of the session variables for dynamic group mapping:
• System-provided and custom session variables defined during a
pre-logon sequence.
• Sessions variables defined by attributes received from external Active
Directory and LDAP servers during dynamic group mapping. The system
converts these attributes to session variables.
Because some session variables are defined after the FirePass controller
performs group mapping, you cannot use them. These include the following
types of session variables:
• Session variables defined by post-logon operations
• Session variables defined by attributes received from external Active
Directory and LDAP servers during the user-authentication process
Configuring session variable-based mapping involves three procedures:
adding the Session Variable mapping method, mapping the session variable
to a FirePass controller group, and mapping the session variable to a
FirePass controller resource group.
2 - 43
Chapter 2
To add the Session Variable mapping method
6. From the mapping methods list, select Session Variable, and click
Add mapping method.
mapping method of this type, the list contains no Session Variable
item.
To map the session variable to a FirePass controller group
3. From the Mapping Methods list, select Session Variable, and click
Add.
Note: If there is no Session Variable item, click the Group mapping
methods tab, and add the Session Variable mapping method first.
4. In the Session variable column, define the session variable you want
to map to, making sure to enclose the session variable within
percent ( % ) characters.
5. In the Value column, specify the string for the FirePass controller to
use for mapping.
Note: You can instead map the Session Variable value directly to a
FirePass controller master group name by checking the Map
verbatim box. In this case, the group names must match exactly. In
this case, the FirePass controller removes the fields in the Value
and FirePass Group columns.
mapping to the session variable.
2 - 44
Setting and changing mapping priority
The group mapping functionality maps users to one master group. If you
have users who belong to more than one group in your network structure,
the mapping functionality can map to only the first match it finds, as
determined by the order of mappings in the master mapping table.
Therefore, the order of mappings might impact the authentication and access
the user receives.
For example, OneUser belongs to two groups: Sales and Marketing, both of
which are configured for dynamic group mapping. In the master mapping
table, the mapping for Marketing occupies the top slot, Priority 1, and Sales
occupies Priority 2. In this case, at logon time, the FirePass controller maps
OneUser to Marketing because that group’s priority is higher.
Initially, the order in which you create mappings determines the order in
which the FirePass controller checks for matches. That is, the FirePass
controller compares users with the first mapping you create, then the second,
and so on.
You can determine the order on the master mapping table, available from
the Users : Groups : Dynamic Group Mapping screen. You can set priority
on the Master mapping table screen to change the order of the mappings in
the table.
2 - 45
Chapter 2
Setting up authentication
Authentication is the process of verifying the identity of a user logging on
to a network. In a typical authentication process, a system requires that users
provide logon information such as user name and password. The system
then checks those credentials against information maintained remotely or
locally on a server or in a database.
Note
The stringent nature of the authentication mechanism you use for the
FirePass controller should match your local network. That is, you should
use equally high standards for the FirePass controller authentication as you
do for your local network.
The FirePass controller uses master groups to determine authentication
parameters, so you set up authentication when you create master groups.
You can authenticate users using FirePass controller internal groups, or you
can use an external server. To determine which authentication method is
right for your setup, see Managing user information in an external data
store, on page 2-6 or Managing users in the FirePass controller data store,
on page 2-8.
Authentication (tasks that ensure that users are who they claim to be), and
authorization (tasks that enable access to resources, applications, and
network shares) are two separate processes on the FirePass controller.
Choosing an authentication scheme
You specify an authentication scheme when you create your master groups.
You can also change an authentication scheme from one type to another.
You can select from several structures for maintaining users for
authentication.
2 - 46
◆
If you plan to use local authentication using the same scheme for all
users, you can simply add all users to the FirePass controller default
master group and set up the authentication you want for the default
group.
◆
If you plan to use external authentication using the same scheme for all
users, F5 Networks recommends that you create a new master group with
external user maintenance. In this case, you do not need to add users to
the FirePass controller at all. Because the default master group is
configured for internal users, you must create a new master group in
order to maintain users externally.
◆
If you want to use different authentication for different users, you must
create separate master groups on the FirePass controller.
To specify the authentication method for a group
1. In the navigation pane, click Users, expand Groups, and then click
Master Groups.
3. In New group name, type the name you want for the group.
You can use up to 48 alphanumeric characters, as well as underscore
( _ ), hyphen ( - ), and period ( . ), and the first character must be
alphanumeric.
4. From Users in group, select Local to maintain users in the FirePass
controller database, or External, to have the users authenticated
from your external network server.
5. From Authentication method, select the authentication method you
want. For more information on the available authentication
methods, see Determining the authentication method, following.
6. Click Create after selecting any other options you want for the
group .
For more information on creating master groups, see Configuring a master
group, on page 2-11.
Determining the authentication method
You can set up FirePass controller authentication using any combination of
the following methods for different master groups. Each master group uses
one authentication method.
Important
To use a specific authentication scheme, you must have a server at your site
that supports the scheme.
◆
FirePass controller’s internal authentication
Uses the internal FirePass controller authentication method for storing
the logon credentials, email, group, and mail server. Internal
authentication does not require any other configuration. You must assign
each user a password, which the users can then change from their
webtops. The FirePass controller stores a hash of user passwords. For
more information on this method, see Managing users in the FirePass
◆
RADIUS server
Uses the server at your site that supports authentication using the
RADIUS protocol. If you want to use RSA SecurID over RADIUS
protocol, select this option. If you want to use RSA SecurID over its
native protocol, select the RSA SecurID option instead. For more
information on this method, see Setting up RADIUS server
2 - 47
Chapter 2
2 - 48
◆
LDAP server
Uses the server at your site that supports authentication using LDAP. For
more information on this method, see Setting up LDAP server
◆
Basic HTTP authentication to external server
Uses external, web-based authentication servers such as Oracle®
COREid®, eTrust™ SiteMinder®, and others to validate user logons and
passwords, and to control user access to specific network resources. For
more information on this method, see Setting up HTTP basic
authentication to external server, on page 2-53.
◆
Initial signup on LDAP with subsequent strong password
Authenticates first-time users against an LDAP directory, but at the first
use also presents a form to require them to entry a strong password.
Subsequently, the user is authenticated using the internal FirePass
controller database. This method allows you to use strong passwords not
supported by your LDAP directory, while providing most of the
convenience of LDAP authentication. For more information on this
method, see Setting up initial signup on LDAP with subsequent strong
internal password, on page 2-53.
◆
Windows domain server
Uses the Windows domain server at your site that supports NTLM
authentication against a pre-Windows 2000 domain controller. For more
information on this method, see Setting up Windows domain server
◆
Windows Active Directory
Uses the server at your site that supports Kerberos authentication against
a Windows 2000 or later server. For more information on this method,
see Setting up Active Directory authentication (Kerberos authentication),
on page 2-55.
◆
HTTP form-based
Integrates with single sign-on systems such as Oracle COREid, eTrust
SiteMinder. For more information on this method, see Setting up HTTP
form-based authentication, on page 2-55.
◆
Client certificate passwordless
Requires no name or password at logon for users who have the installed
client certificate. For more information on this method, see Setting up
client-certificate-based authentication, on page 2-55.
◆
RSA SecurID
Uses the server at your site that supports RSA’s SecurID technology over
its native protocol. RSA SecurID represents a two-factor authentication
scheme that uses a combination of a known password and a digitally
generated string to grant access to the FirePass controller. The FirePass
controller is RSA-certified. If you want to use RSA SecurID over
RADIUS, select RADIUS instead. For more information on this method,
see Setting up RSA SecurID authentication, on page 2-61.
Changing authentication methods
You can convert from any authentication scheme to another.
To convert the authentication method for a master group
Master Groups.
2. In the Authentication column, click the link associated with the
master group you want to affect.
The master-group-specific authentication screen opens.
3. Click the Convert authentication method link.
The convert-authentication screen opens.
4. From the list of authentication schemes available for conversion,
click the method you want to convert to. For more information on
the available authentication methods, see Determining the
authentication method, on page 2-47.
5. On the convert-confirmation screen, click the Continue button.
The associated Authentication screen opens.
6. Specify the settings and options you want, and then click the Save
Settings button.
Important
Depending on the conversion, you might be required to configure additional
settings. For example, if you convert to the internal authentication method,
you must make sure to specify passwords as well as add any missing data so
all of the fields are filled on the associated user information screen. For
more information on converting to an authentication type, see the section
associated with the specific method. For example, if you are converting to
the RADIUS authentication method, see Setting up RADIUS server
Setting up internal authentication
This method uses an internal database storing FirePass controller user data:
name, logon designation, password (stored as cryptographically strong
hashes), email address, group name, mail server, and NFS logon/password.
Initially, each user has to be assigned a password. Later on a user can
change it from the webtop.
2 - 49
Chapter 2
Setting up RADIUS server authentication
The FirePass controller can authenticate using a RADIUS server. On the
RADIUS server, you must set up the FirePass controller as a client of the
RADIUS server. Then, establish a shared secret and add it to both the
RADIUS server and the FirePass controller so the RADIUS server can trust
the FirePass controller.
Important
Be sure that the RADIUS server is configured to recognize the FirePass
controller as a client. Use the same shared secret in both the RADIUS
server configuration, and in the FirePass controller configuration.
Tip
You can specify up to three RADIUS servers for redundancy. The FirePass
controller tries to authenticate using the first configured server. If there is
no response, it falls back to the secondary server. If the secondary server
does not respond, the FirePass controller tries with the tertiary server.
Configuring RSA SecurID using RADIUS
FirePass controller fully supports RSA extensions for RADIUS and is
RSA-certified. You have one of the following options.
• If you plan to use RSA SecurID over RADIUS, select RADIUS as the
authentication method.
• If you plan to use RSA SecurID over its native protocol, select RSA
SecurID as the authentication method.
For more information, see Setting up RSA SecurID authentication, on page
2-61.
Troubleshooting RSA SecurID on Windows using RADIUS configuration
If you are having difficulty authenticating using RSA SecurID over
RADIUS, on the authentication server that is running RSA SecurID server,
check to make sure these settings are correct:
2 - 50
◆
The RADIUS service is active.
Even if the RADIUS service has been started from the SecurID options
window on the Windows SecurID server, the service may not be active.
In the Windows Services Manager, make sure that the service is set to
start each time the server boots, and is currently running. RSA SecurID
authentication using RADIUS takes place on a different port than does
native SecurID authentication.
◆
The SecurID server is configured correctly for RADIUS
authentication.
While using RSA SecurID over RADIUS, the SecurID server is a client
of itself. The RADIUS service functions as a standalone process, and if
the SecurID server is not set up as a client of itself, it rejects the FirePass
controller authentication request and does not store anything in the logs.
In this case, the FirePass controller reports that authentication has failed,
and with no log information, the failure is difficult to diagnose. To
troubleshoot, check that:
• You have enabled support for the RADIUS protocol for the RSA
SecurID server.
• You have configured the FirePass controller as a client of the RSA
SecurID server.
Configuring Single Sign On using a RADIUS attribute
You can configure the FirePass controller to retrieve the Single Sign On
(SSO) password information from an attribute returned from the RADIUS
user profile. The FirePass controller parses the return value to retrieve the
SSO password information in various formats.
For example you can use 25 for the Class attribute, 26 for the Vendor
Specific attribute, or 11 for the Filter-ID attribute.
Note
SSO configuration is applicable for simple RADIUS as well as RSA SecurID
over RADIUS.
Setting up LDAP server authentication
The FirePass controller can authenticate using any LDAP database,
including a Windows Active Directory.
You can use an LDAP-protocol-based directory, including an Active
Directory, to authenticate users dynamically. In this case, you do not store
user information on the FirePass controller. Instead, you obtain it from the
LDAP entry.
Using the Template option for LDAP authentication
If the FirePass controller logon matched the naming attribute that your
LDAP directory uses as part of the bind DN, you can look for the user’s
entry directly by configuring the option described in the following
procedure.
To specify the template option for LDAP authentication
Master Groups.
2 - 51
Chapter 2
2. In the Authentication column, click the link representing the master
group you want to configure.
The screen changes, and you see the authentication screen for the
corresponding master group.
3. In Host, specify the FQDN or the IP address of the LDAP server.
4. In Port, specify the port on which the LDAP server listens.
The default values are 389, which represents LDAP, and 636, which
represents secure LDAP.
5. From the Protocol version list, select 2, if yours is an LDAPv2
configuration, or 3, if yours is an LDAPv3 configuration.
6. In User DN Template, type the following string, substituting the
appropriate value for YourCo.
cn=%logon%,o=YourCo
During logon, the authentication mechanism substitutes the user’s FirePass
controller logon as part of the bind DN, and supplies the entered password
as the bind password. If the bind operation succeeds, the user is validated.
Using the Query option for LDAP authentication
If the user name and password are not the same as the LDAP logon (for
example, if the LDAP user ID contains characters that the FirePass
controller does not support), then you cannot use the FirePass controller
logon to bind to the LDAP directory. Instead, you must query to find the
correct DN to use in a second attempt to bind.
Query the appropriate part of the directory tree structure (specified by the
search base, or container, DN) to find a user within that branch.
Your LDAP directory might allow anonymous queries. If so, you do not
need to specify an account and password. Otherwise, either specify
credentials of any LDAP account that is allowed to query this part of LDAP
directory, or create a new LDAP account for FirePass device.
Note
Your schema may vary considerably from the examples presented in the
following list. The user object class user is different on some LDAP servers,
and your structure might have more layers of names defined between the
root and the leaves.
To specify certain parameters, you must have the following information,
which you can get from your LDAP server administrator:
• User DN for query: The fully qualified DN of the user with rights to run
the query. We recommend specifying this value in lower case and
without spaces for compatibility with some specific LDAP servers.
The specific content of this string depends on your directory layout.
For example, in an Active Directory structure, a typical User DN for
query would be similar to the following string:
cn=administrator,cn=users,dc=eng,dc=net,dc=com
2 - 52
• Password: The password associated with the DN you specified in User
DN for query. You can leave this field blank if your LDAP server
allows anonymous queries.
• Search base DN (Container DN): Determine the appropriate values
from your specific directory layout.
The specific content of this string depends on your directory layout.
For example, in an Active Directory structure, a typical Search base DN
would be similar to the following string:
cn=users,dc=eng,dc=net,dc=com
• Query template: For example, (&(sAMAccountName=%logon%))
After the FirePass controller runs the query. If it finds a matching user entry,
it uses the returned DN value and the user-entered password to bind to the
LDAP directory. If the second bind succeeds, the authentication succeeds
(that is, the user is validated). If either bind fails, the authentication fails.
Setting up HTTP basic authentication to external server
Basic authentication requires a valid URL resource. This resource must
respond with a challenge to a non-authenticated request. This method
supports authentication over both HTTP and HTTPS protocols. Redirects
are not supported.
Note
F5 Networks strongly recommends using HTTPS because basic
authentication passes user credentials as clear text.
You can test the URL by logging on with valid and invalid credentials, to
make sure your external authentication server issues a challenge when
invalid credentials are tendered, and that it does not send a redirect.
Setting up initial signup on LDAP with subsequent strong internal
password
This option authenticates new users against an LDAP directory. At logon,
the FirePass controller presents a form requiring the new user to enter a
strong password. Subsequently, the user is authenticated using the FirePass
controller internal method.
With this method, you can use strong passwords not supported by LDAP
directory, while providing most of the convenience of LDAP authentication.
To use Initial Signup on LDAP with Subsequent Strong Internal Password
authentication, you also must use template-based signup for the group. To
enable signup by templates, use the Users : Signup Templates screen.
2 - 53
Chapter 2
A strong password is one that is difficult to detect by both humans and
computer programs, which effectively protects data from unauthorized
access.
On the FirePass controller, a strong password must:
• Contain at least eight characters
• Start with an alphabetical character
• Contain at least one numeric character from the set 0, 1, 2, 3, 4, 5, 6, 7, 8,
9.
• Contain at least one special character from the set ` ~ | . , : ; ? / ' " \ { } <
>!@#$%^&*()+=_• Contain no more than three consecutive occurrences of the same
character
• Not contain the employee name or logon
Note
In a strong password, neither the number nor the special character may be
in the last character position.
Setting up Windows domain server authentication
Within a Windows domain there are usually a number of groups defined,
with users belonging to one or more of these groups. You can map existing
Windows domain groups directly to existing FirePass controller master
groups. When a user attempts to log on to the FirePass controller, the
Windows domain groups that the user belongs to are retrieved from the
domain. The FirePass controller attempts to match one of the domain groups
against the FirePass controller-configured mapping, and the user is
dynamically moved to the new FirePass master group based on a match. For
more information on group mapping, see Understanding dynamic group
mapping, on page 2-16.
Windows domain server supports the following authentication modes:
2 - 54
◆
Native NTLM authentication
Uses Native Windows NT LAN Manager (NTLM) authentication if you
specify domain administrative credentials when you set up Windows
domain authentication on the FirePass controller. This allows FirePass
controller to add a machine account for itself, join the domain, and create
a trust relationship with the Primary Domain Controller (PDC). FirePass
controller can then authenticate users using native NTLM services.
◆
Netlogon Share
If you do not specify domain administrative credentials when you set up
Windows domain authentication on the FirePass controller, then the
FirePass controller uses a more basic method for authenticating users.
The FirePass controller connects to the Netlogon share on the configured
PDC using the user’s credentials to determine whether the user has a
valid account within the domain. If binding to Netlogon succeeds, the
FirePass controller authenticates the user.
Setting up Active Directory authentication (Kerberos
authentication)
Computers using Windows 9x or Windows NT typically use the NTLM
protocol for network authentication in Windows 2000 domains. Computers
running Windows 2000 and later might use NTLM when authenticating to
servers with Windows NT 4.0 and when accessing resources in Windows
NT 4.0 domains, but the more commonly used protocol is Kerberos,
generally referred to as Active Directory. If you are running Windows 2000
or later servers, F5 Networks recommends that you use Active Directory
authentication instead of Windows domain authentication.
For specific procedures for setting up Active Directory authentication, see
Configuring Active Directory-based mapping, on page 2-27.
Setting up HTTP form-based authentication
You can configure the FirePass controller to use external, web-based
authentication servers such as Oracle COREid, eTrust SiteMinder, and
others, to validate user logons and passwords and to control user access to
specific network resources. The FirePass controller can detect any of the
following response types from an external server:
• A valid redirect URL in the external server’s response
• A specific, configurable substring in the external server's response
• The presence of a specific cookie in the external server's response to the
FirePass controller request for user validation
From the standpoint of the authentication server, the FirePass controller
appears as a proxy browser. The FirePass controller itself is transparent to
the authentication application. You do not need to make any configuration
changes to the authentication server to integrate it with the FirePass
controller.
Setting up client-certificate-based authentication
To use client certificates, you must have a server configured as a Certificate
Authority (CA) that can generate a client root certificate and the client
certificates based on the client root certificate. Or, you can purchase the
client root certificate and client certificates from an external CA. For more
information about installing client certificates, see Installing and
configuring client root certificates, on page 4-11.
2 - 55
Chapter 2
Using client certificates
When the FirePass controller is serving as the client certificate CA, you can
generate and download client certificates on the User’s details screen. To
access the screen, click Users, click User Management, and click the edit
button associated with a specific user.
The issued client certificates are based on the subject fields of the issuing
client root CA certificate. The common name (CN) is set to the logon name,
and the Organization Unit (OU) might be set to the user’s group name on the
FirePass controller (for use with dynamic group mapping functions).
You can enable the setting to request the client certificate during logon only
after installing a valid client root certificate. This instructs the FirePass
controller to request the client certificate as part of the SSL session
negotiation, which occurs before the client attempts to log on to the FirePass
controller. It also validates and logs the client certificate, but it does not
restrict access to the FirePass controller.
You can determine whether content from client certificate fields
automatically populates the user name field at logon time. When you request
a client certificate during logon, you use one of several options.
2 - 56
◆
Do not use certificate field for logon username
Select this option if you do not want any client certificate field to map to
the FirePass controller logon name. When you select this option, the
FirePass controller does not support client certificate passwordless
auto-logon authentication, and other client certificate functions do not
check to ensure that the user name matches any client certificate field.
However, the FirePass controller does check the client certificate the user
provides against the installed root CA certificate, and against any
configured CRL checking mechanisms.
◆
Use certificate common name (CN) for logon username
Select this option if your PKI infrastructure issues client certificates that
use the common name (CN) as the FirePass controller logon user name
or when the certificate is generated on the FirePass controller. When the
FirePass controller is configured to serve as the client root CA and issues
client certificates directly, it issues certificates that use the client
certificate CN as the logon name. When you select this option, the
FirePass controller populates the logon name prompt with this value, and
other client certificate functions check to make sure the logon name
matches the CN field in the client certificate.
◆
Use certificate e-mail address for logon username
Select this option to use the email address of the user as the FirePass
controller logon user name. When you select this option, the FirePass
controller populates the logon prompt with this value, and other client
certificate functions check to make sure the logon name matches the
email address in the client certificate. the FirePass controller checks
against the first user account found with the specified email address.
◆
Use certificate serial number (SN) for logon username
Select this option to use the certificate serial number (SN) as the FirePass
controller logon name. When you select this option, the FirePass
controller populates the logon name prompt with this value, and other
client certificate functions check to make sure the logon name matches
the SN field in the client certificate.
◆
Use certificate subject DN field (regex extraction) for logon
username
Select this option to use a different value from the client certificate
distinguished name (DN) as the FirePass controller logon name. You can
then specify a Perl-style regular expression to extract the user name from
the DN. A sample DN appears as follows:
/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/emailA
[email protected].
You can use an expression such as |CN=(.*)/| to extract the CN for use as
the logon name. When you select this option, the FirePass controller
populates the logon prompt with the value extracted, and other client
certificate functions check to make sure the logon name matches the
extracted field from the client certificate.
◆
Use certificate ext subjectAltName field (regex extraction) for logon
username
Select this option to use the X509v3 extension’s Subject Alternative
Name attribute. You can then specify a Perl-style regular expression to
extract the subjectAlternativeName from the certificate. For example, if
the certificate has the SubjectAltName extension attribute as
X509v3 Subject Alternative Name:
email:[email protected], email:[email protected]
to extract the second e-mail address from this attribute using a regular
expression, you can use the following expression
|email:.*, email:(.*)|
Configuring for client certificate authentication
Client certificates serve as a security mechanism that allows the FirePass
controller to verify that the client computer is a valid computer. You can use
client certificates in the following ways:
◆
Two-factor authentication
In the two-factor authentication system, users must have a valid client
certificate installed in addition to specifying a user name and password.
After installing a client root certificate and enabling the option to request
client certificate during logon, the Client Certificate Two-Factor
Authentication section becomes available on the Authentication tab for
each master group. To access the screen, click Users, expand Groups,
click Master Groups, and click the link in the Authentication column
for the master group you want to configure. For information about this
feature, see Configuring client-certificate two-factor authentication, on
page 2-60.
◆
Extra policy layer of protection
You can specify use of client certificates for individual access functions
or individual resource protection. For example, you can limit access to
2 - 57
Chapter 2
the FirePass controller Network Access service only to corporate laptops
with valid client certificates installed. In that case, users do not have
access to the Network Access service from untrusted locations, such as
public access kiosks. But you still can give them access to Web
Applications, even from untrusted locations.
You can use client certificates to control access to resources by creating a
named endpoint configuration on the Protected Configuration screen. To
access the screen, click Users, expand Endpoint Security, click
Protected Configurations, and then click the New Protected
Configuration link. You can assign the endpoint protection you created
on the Protect Resources screen. To access the screen, click Users,
expand Endpoint Security, and click Protect Resources. Then click the
Select link for each service (for example, all Web Applications or
webtops), an individual resource group, or several favorites you want to
protect, and select the protected configuration you want to use. For
information about protected configurations, see Creating protected
configurations, on page 3-27, and for information about protecting
resources, see Protecting resources, on page 3-31.
2 - 58
◆
Passwordless auto-logon
The presentation of a valid user client certificate, where the common
name (CN) matches the user logon name, enables either a zero-click or
one-click automatic logon. You can configure a passwordless automatic
logon mechanism on the Authentication screen. To access the screen,
click Users, expand Groups, click Master Groups, and click the link in
the Authentication column for the master group you want to configure.
For information about this feature, see Configuring passwordless
◆
Dynamic group mapping
The existence of a valid user client certificate allows use of fields within
the client certificate to enable dynamic mapping of users into particular
FirePass controller master authentication groups or to particular resource
groups. This allows use of extensive resource policy management based
on existence and fields within a client certificate. You can configure the
dynamic group mapping mechanism on the Dynamic Group Mapping
screen. To access the screen, click Users, expand Endpoint Security,
and click Dynamic Group Mapping. For information about dynamic
group mapping, see Understanding dynamic group mapping, on page
2-16.
◆
Pre-logon sequence processing
The existence or nonexistence of a valid user client certificate controls
whether the FirePass controller performs the defined pre-logon actions,
such as loading the protected workspace or denying access to the
FirePass controller logon screen. You can configure a pre-logon
sequence that require client certificates on the Pre-Logon Sequence
and click Pre-Logon Sequence. For information about pre-logon
sequences and inspectors, see Creating pre-logon sequences to protect
resources, on page 3-16.
◆
Resource protection
You can use client certificates to control access to resources by assigning
a previously defined and named endpoint configuration (created using
the New Protected Configuration link on the Users : Endpoint Security
: Protected Configurations screen) to a resource on the Protect Resources
and click Protect Resources, and then click the Select link for each
service you want to protect. For information about protected
configurations, see Creating protected configurations, on page 3-27.
Using client certificates to authenticate users
To use client certificates, you must have a server configured as a Certificate
Authority (CA) that can generate a client root certificate and the client
certificates based on the client root certificate. Or, you can purchase the
client root certificate and client certificates from an external CA.
Here is an overview of the tasks required for using client certificates to
authenticate a user’s computer:
◆
Install the client root certificate on the FirePass controller. You can
install a client root certificate using the Certificates screen. To access the
screen, click Device Management, expand Security, and click
Certificates.
◆
Enable the validation of client certificates.
◆
Configure client certificate validation as part of the authentication for a
group.
◆
Instruct users how to download and install the client certificate on their
computers. You can also email the client certificates to users.
◆
Install a certificate revocation list (CRL) that contains a list of client
certificates for users who you want to deny access to the FirePass
controller, for example, the revoked client certificates of users who have
left your company.
The FirePass controller can then request and validate the computer’s
client certificate against its installed client root certificate as part of the
authentication process.
Configuring passwordless authentication
If you select the Client certificate passwordless authentication method for
any group, the FirePass controller requests a client certificate from the user
machine. This client certificate can be one issued by your company’s PKI
infrastructure, one made available from a SmartCard solution, or one created
and distributed to the user by the FirePass controller itself.
If the client machine has a trusted certificate, the FirePass controller follows
this process when authenticating.
2 - 59
Chapter 2
◆
Hide the password prompt, and populate the User name box on the
logon page with the client certificate field that you configured on the
Certificates screen. The user cannot edit this logon user name.
◆
The FirePass controller validates the certificate against the installed
client root certificate. It also checks the certificate against any configured
CRL methods enabled.
◆
The FirePass controller validates the user name against the internal
authentication database. If you specify use of sign-up by templates for
the group (along with dynamic group mapping, to make sure the user is
mapped to a group supporting client certificate authentication), then the
FirePass controller automatically adds the user based on the client
certificate.
Users who are validated need only click the Logon button to log on to
the FirePass controller webtop (one-click logon). If you have enabled
automatic logon when the client certificate is present, the FirePass
controller logs the user directly on to the FirePass controller webtop
(zero-click logon). In this case, the FirePass controller verifies the client
certificate common name (CN) field against the logon user name.
◆
If there is no client certificate on the remote machine, the FirePass
controller provides the regular logon screen, and attempts to authenticate
the users using the methods specified for other authorized groups.
If you have more than one client root certificate installed, you can select a
client certificate issuer to restrict authentication to certificates issued by that
specific client root certificate. For more information on functionality with
more than one client root certificate installed, see Installing and configuring
client root certificates, on page 4-11.
Configuring client-certificate two-factor authentication
You can require the existence of a valid client certificate as a secondary
authentication factor, that is, a scheme requiring two authentication
methods. You can configure client certificates as part of a two-factor
authentication system, in which users must have a valid client certificate
installed on their computer in addition to entering their user name and
password at logon time.
A server certificate verifies the server’s identity to a user’s computer. In
addition to using server certificates, you can require client certificates that
enable the FirePass controller to verify the identity of a user’s computer, and
to control access to specific resources, applications, and files. For more
information about server certificates, see Using server certificates on the
FirePass controller, on page 4-1.
You can require valid client certificates to gain access to specific
applications. For example, you might provide access to the FirePass
controller Network Access service only for users who present valid client
certificates. That user could access the Network Access service from the
laptop, but not from other locations, such as public access kiosks, where the
certificate might not be installed.
2 - 60
To configure two-factor authentication
Master Groups.
2. In the Authentication column, click the link representing the master
group you want to configure.
The screen changes, and you see the authentication screen for the
corresponding master group.
3. In the Client Certificate Two-Factor Authentication area, check the
Require client certificate for user logon check box.
The screen refreshes to reveal certificate-specific options, and a
message indicating which client certificate field the FirePass
controller uses to populate the logon field, depending on the option
you selected on the Device Management : Security : Certificates
screen.
4. From the Required client certificate issuer list, select a client
certificate that you want the client computer to present.
The client certificate can be one issued by your company PKI, one
made available by a SmartCard solution, or one created and
distributed to the user by the FirePass controller itself.
If you have not installed a client certificate, you do not see the Request
client certificate during logon check box on the Device Management :
Security : Certificates screen, or the Require client certificate for user
logon check box on the Users : Groups : Master Groups screen. In that case,
install a client root certificate first, using the Client Root Certificate or
Self-Signed Certificate option on the Device Management : Security :
Certificates screen. For more information, see Installing and configuring
If you have more than one client root certificate installed, you can select a
client certificate issuer to restrict authentication to certificates issued by that
specific client root certificate. For more information on functionality with
more than one client root certificate installed, see Installing and configuring
Setting up RSA SecurID authentication
If you are using an RSA SecurID server using its native protocol (that is, not
over RADIUS), you must configure the authentication server so that the
FirePass controller can communicate with it.
You can enable support on the server by adding the FirePass controller as a
UNIX Agent Host to the RSA server configuration.
When you configure the UNIX Agent Host, make sure to use the virtual IP
address of the FirePass controller as the primary IP address. If your
configuration uses failover units, configure each failover unit as a secondary
2 - 61
Chapter 2
node, using the actual (not virtual) IP address. You can find more
information on configuring secondary nodes in the administrator’s guide for
your RSA SecurID server.
Next, you must configure a new RSA SecurID server on the FirePass
controller. To do so, navigate to the Device Management : Configuration :
RSA SecurID screen. Because the FirePass controller is a multihome
appliance with multiple IP addresses, the source IP address setting that the
FirePass controller uses for communicating with the RSA SecurID server is
very important. It must be the same address as the IP address you specified
in the network address field when you configured the FirePass controller as
an agent host on the RSA SecurID server. Once configured, the
Authentication screen for any master group shows the name, configuration
file upload time, and source IP address it will use for communicating with
the RSA SecurID server.
When you specify the source IP on the FirePass controller, if there is a NAT
device in the network path between the FirePass controller and the RSA
SecurID server, use as the source IP the address as translated by the NAT
device. Otherwise, specify the IP address from among those configured on
Important
In all cases, the source IP address must match the SourceIP address in the
IP packets received by the RSA SecurID server.
For specific procedures for each of these operations, see the online help for
the Device Management : Configuration : RSA SecurID screen.
If you have already configured one or more RSA SecurID servers on the
FirePass controller, you can select from the list of RSA SecurID servers on
the Users : Groups : Master Groups screen, using the Authentication tab.
2 - 62
Working with resource groups
When you are ready to configure the resources for users to access, you use
the options on the Resource Groups screens. Using theses options, you can
configure favorites that link to intranet resources, web applications, network
shares, application tunnels and legacy host applications.
To create a resource group
Resource Groups.
The Resource Groups list screen opens.
The Group Management screen opens.
3. In the New group name box, type the name you want for the group.
You can specify up to 48 alphanumeric characters, as well as
underscore ( _ ), hyphen ( - ), and period ( . ), and the first character
must be alphanumeric.
4. From Copy settings from, select Do not copy to configure all
settings for the new resource group, or select an existing resource
group to copy settings from.
This gives you a fast way to reuse settings you have already
specified.
5. If you select a resource group to copy settings from, you can also
check Assign the new resource group to the same set of master
groups to associate master groups from the based-on resource group
to the new resource group. This gives you a fast way to associate
master groups to resource groups.
The FirePass controller provides a default resource group called
Default_resource that by default has no associated master group. You can
create your own resource groups to use instead, or you can modify the
default group.
The Resource Groups list screen lists all the resource groups, including the
default group. From this screen, you can navigate to the other screens you
need for creating favorites. You can also delete any group by clicking the
associated Delete link.
Creating favorites in resource groups
You can create three basic categories of favorites for resource groups: those
that provide portal access, those that enable network access, and those that
support application access. Figure 2.4, on page 2-64, illustrates resource
groups and favorite association.
2 - 63
Chapter 2
◆
Portal Access
Provides a web-based application that gives users access to POP or
IMAP email, network shares, and proprietary corporate applications. For
more information about portal access, see Introducing Portal Access, on
page 7-1.
◆
Network Access
Connects users to the network just as if they were using a traditional
IPsec Virtual Private Network connection. Then users can access any
applications that use IP networking between their remote computer and
the corporate intranet structure, enabling full network access through an
SSL-VPN tunnel. For more information about network access, see
Introducing Network Access, on page 5-1.
◆
Application Access
Provides users access in the following ways:
• App Tunnels, connections to a server on a corporate LAN that uses an
HTTPS-based, encrypted tunnel through the FirePass controller.
• Terminal Servers, connections to Microsoft Terminal Servers,
Windows XP® desktops, Citrix MetaFrame® servers, and VNC
servers.
• Legacy Hosts, connections to legacy greenscreen systems (for
example, Vt100, Vt320, TN3270, and others) on mainframes,
AS/400s, and UNIX hosts).
For more information about application access, see Introducing
Application Access, on page 6-1.
Figure 2.4 Visual representation of favorites categories
Note
Portal access, network access, and application access all have master group
settings. When you configure favorites for a resource group, you should also
check the master group settings. Master group settings apply to all favorites
in a category. To find a category’s master group setting, from the
navigation pane, click Network Access, Portal Access, or Application
Access, and then click Master Group Settings. You can find more
information about master group settings in the online help for the associated
screen.
2 - 64
Associating resource groups with users
Resource groups can be static or mapped.
A resource group is considered a static resource group when it is explicitly
assigned to a master group or to a internally managed user. All users in the
associated master group are granted access to the statically assigned
resource groups. In this case, the mapping becomes associated with the user,
irrespective of the user’s associated master group, so the user can move to
any master group and still keep the same resource group assignment. You
can assign a static resource group to a user when you create the user
account, or at any time after the user account has been created.
A resource group is considered a dynamically mapped resource group
when the FirePass controller grants access based on the resource mapping
table. Any user who belongs to the external group is granted access to the
resource groups. Users who move to a different external group are
automatically granted access to any resource groups mapped to the new
external group. When you add a new favorite or reconfigure an existing one,
the change applies to users in all mapped groups.
When a user logs on and is successfully authenticated in a master group, the
FirePass controller grants the user access to the associated master group’s
assigned resource groups. You can also directly assign resource groups to
local users from the User : User Management screen.
To assign a resource group statically
1. In the navigation pane, click Users and click User Management.
The User Management list screen opens.
2. Click the edit button associated with the user you want to have
access to the resource group.
The User’s details screen opens
3. In Available individual resource groups, along the right side of the
screen, check the resource groups you want the user to access.
4. Click the Change button.
The groups now appear in Assigned resource groups.
To assign a resource group dynamically
Master Groups.
The Master groups list screen opens.
2. Click one of the existing master group names.
The master group’s screen opens, with the General tab selected.
3. In the Resource Groups column click the link associated with the
master group you want to configure with resources.
The Resource Groups configuration screen opens.
2 - 65
Chapter 2
4. From the Available list, select the resource group or groups you
want to make accessible to users in the master group.
You can use the Shift and Ctrl keys to select multiple resource
groups.
5. Click the Add button to add the resource groups to the Selected list.
See Figure 2.1, on page 2-2, for a visual representation of the relationship
between users, master groups, resource groups, and favorites categories.
To edit a resource group association
Resource Groups.
The Resource groups list screen opens.
2. In the Network access, Portal access, or Application access column
for any resource group, click the Edit link.
The category’s favorites page opens.
3. Configure the favorites you want.
For more information about favorites, see Configuring resource
group favorites, following.
Tip
You can switch to a different resource group by selecting a group from the
Resource Group list. This is an easy way to switch from one resource group
to another, without returning to the Resource groups list screen.
Configuring resource group favorites
Once you have created resource groups, the next step is to configure
favorites for the resource group. Any user who belongs to a resource group
automatically gets the configured favorites of that resource group. Favorites
include web applications, Windows files, App Tunnels, Legacy Hosts,
Terminal Servers, Portal Access, and Network Access. You configure the
favorites for resource groups based on which users have the resource groups
assigned to them. or their master group
• Web Application favorite
Provides remote users with secure access to Web servers on your
organization intranet. For more information, see Defining favorites for
Portal Access Web Applications access, on page 7-6.
• Windows Files favorite
Provides remote users with the ability to browse and view files stored on
Windows servers on your LAN. For more information, see Configuring
Windows Files favorites, on page 7-35.
2 - 66
• App Tunnels favorite
Gives a remote FirePass controller user to access a TCP/IP client/server
application on your LAN. For more information, see Defining App
Tunnel favorites, on page 6-7.
• Legacy Host favorite
Provides remote FirePass controller users access to legacy applications
on your organization’s hosts. For more information, see Defining legacy
host favorites, on page 6-26.
• Terminal Server favorite
Gives remote users access to computers running Terminal services,
Citrix MetaFrame servers, and VNC servers. For more information, see
Configuring terminal server favorites, on page 6-30.
• Network Access favorite
Provides remote FirePass controller users with SSL VPN access to
applications and network resources on your LAN. For more information,
see Configuring Network Access resource group settings, on page 5-19.
Impersonating a user
You can use the Impersonate User feature to log on as if you were a user.
This feature can help you mechanism to troubleshoot configuration once
everything is configured. You can find Impersonate User on the Users item
in the navigation pane. This feature is useful for checking favorites that you
create and for troubleshooting other connection issues.
Important
When you impersonate a user, the system ends your administrative session.
The impersonation process skips the step of authenticating the user. In order
to skip authentication, the FirePass controller must have sufficient
information about those users to treat them appropriately. Therefore, you
can impersonate only those users whose information is maintained in
FirePass controller data store.
When you log on using the Impersonate User feature, the system behaves as
if users were authenticated, even if those users would not pass normal logon
procedure. While impersonating a user, you do not have access to any
network resources that require logging on.
While you are impersonating a user, system records the actions of the
impersonated user in the Sessions report, available in Reports : Sessions.
Because the user did not actually log on, the system does not record an entry
in the Logon report.
Note
Although you can impersonate deactivated users, you will not have access to
any of the users’ assigned resources.
2 - 67
Chapter 2
2 - 68
3
• Understanding endpoint security
• Using pre-logon sequences
• Implementing client system checking
• Creating pre-logon sequences to protect resources
• Creating protected configurations
• Protecting resources
• Configuring post-logon protection
• Using other kinds of protection
Understanding endpoint security
Endpoint security is a centrally managed method of monitoring and
maintaining client-system security. The FirePass controller provides three
mechanisms for accomplishing endpoint security:
• A pre-logon sequence, which defines a set of actions that need to be
done in order to evaluate the client system or device.
• A protected configuration, which is a definition that takes information
gathered by the pre-logon sequence and instructs the system to respond
based on the result.
• Protecting resources, which is the process of assigning a protected
configuration to a set of resources you have defined.
Endpoint security performs three basic tasks:
◆
Collects information about the client system
For example, whether the user is operating from a company-issued
computer, what antivirus software is present on the machine, what
operating system the computer is running, and others. This is
accomplished by the pre-logon sequence.
◆
Performs remediation, if possible
For example, puts the system into the protected workspace, asks the user
to download antivirus software, and others. This is a function of the
FirePass controller, based on information gathered by the pre-logon
sequence.
◆
Protects resources based on the collected information
For example, prevents access to a resource until the user downloads and
installs the antivirus software requested, and others. This is accomplished
by creating protected configurations and assigning them to protect
resources.
Collecting information
The FirePass controller collects various types of information about the client
system using ActiveX controls or Java plug-ins. In clientless mode, that is,
when the inspection process does not download any controls or plug-ins, the
endpoint security process inspects the HTTP headers to gather the
information.
The FirePass controller provides checking primarily for Windows-based
systems, and some of the checking is not supported on Mac OS X or Linux
systems. The FirePass controller does support file checking on Mac OS X
and Linux systems. Table 3.1, following, shows the complete list of
inspectors
3-1
Chapter 3
Using the inspectors
Inspectors are the basic working functionality for sequences. The pre-logon
sequence determines which inspectors to activate, and the inspectors
evaluate the system of the user logging on. Depending on the outcome of
evaluation, the FirePass controller permits the logon to continue, initiates an
action, presents a message, or rejects the attempt. The FirePass controller
supports the following inspectors.
Table 3.1 contains information about each inspector. You can find more
information about session variable usage and operating system requirements
for each inspector in the online help.
Inspector
Description
Decision
The decision box allows you to present a user options to select from a list. You
can use a rule containing the variable session.user_decision.last.check==1
to match the first option selected by user. Default options are Yes and No, but
you can modify these options, and you can add other options from which the
user can select.
Define custom variable
Defines a new variable and assigns a value to an existing one. For more
information about the custom variable, see the section Using variables
generated by inspectors for Action Rule expressions in the online help for the
Pre-logon Sequence screen.
Extended Windows information
Gets version information about the Windows operating system, such as version
and hotfix information from the remote system. This inspector uses the
session.win_info.os_version, session.win_info.hotfixes.count, and
session.win_info.hotfixes.hf_<hotfixname>, which you can then use to
define a rule for a specific action in a sequence.
Far-End Security Integration
Provides integration with third-party endpoint security products using the
session.external_security_check.result session variable. A match to
session.external_security_check.result == 1 indicates that the check
completed successfully.
You can use this inspector to detect WholeSecurity’s Confidence Online™
Server, which automatically identifies and eliminates both known and unknown
threats without requiring users to install or update signatures. For more
information about how to use this feature, see the deployment guides for
FirePass controller integration with Whole Security, available on the F5
Networks Solution Center at http://www.f5.com/solutions/.
Google Desktop Search Inspector
Checks for the presence of Google Desktop Search software using the
session.google_desktop_check.result session variable. A match to
session.google_desktop_check.result != 1 indicates that Google Desktop
Search is running.
Internet Explorer information
Collects version information about the Internet Explorer software, such as
version and hotfix information, from the remote system. This inspector
generates the variables session.ie_info.version,
session.ie_info.hotfixes.count, and
session.ie_info.hotfixes.hf_<hotfixname>, which you can then use to define
a rule for a specific action in a sequence.
Table 3.1 Endpoint inspectors
3-2
Inspector
Description
Linux file checker
Checks for the presence of certain Linux files and uses MD5 to authenticate
files. This inspector uses the session.file_check_linux.<filename>.result
session variable. A match to
session.file_check_linux.<filename>.result ==1 indicates the presence of the
file with all associated parameters.
Logger
Writes user-defined information to the logon and system logs. For the string,
you can use a session variable name enclosed in percent symbols (%) to have
the system substitute the appropriate information. For example, typing Logon
from %session.network.client.ip% creates an entry containing the IP address
for the client system where the logon operation originated.
Mac OS X file checker
Checks for the presence of certain Mac OS X files and uses MD5 to
authenticate files. This inspector uses the
session.file_check_macosx.<filename>.result session variable. A match to
session.file_check_macosx.<filename>.result ==1 indicates the presence of
the file with all associated parameters.
Mailer (Sending email action)
Sends email to the specified address during the pre-logon operation. For the
string, you can use a session variable name enclosed in percent symbols (%) to
have the system substitute the appropriate information.
For example, you can type the following message text:
Antivirus: %session.detected_av.av_1.name%,
%session.detected_av.av_1.engine_version%,
%session.detected_av.av_1.monitor%,
%session.detected_av.av_1.database_time%,
%session.detected_av.av_1.last_scan%
The following is a sample message constructed using these session variables.
pre-logon: Antivirus: McAfeeAV, 4400, enabled, 2005.08.01.00.00,
2005.07.29.00.00
For a list of session variables, see Using variables generated by inspectors for
Action Rule expressions in the online help for the Pre-logon Sequence screen.
Important! A busy or incorrectly configured email server can cause an
extended delay in a pre-logon process. You can configure the email server on
the Device Management : Configuration : SMTP Server screen.
Message
Presents a message to the user during the pre-logon check and prompts the
user to click the Continue button to continue with the pre-logon check. This
inspector does not return any session variables.
You can use the Endpoint Inspector Details screen to create the message you
want to present. In addition to the content you enter, you can select left
alignment, center alignment, or right alignment of the message text.
3-3
Chapter 3
Inspector
Description
Protected Workspace inspector
Controls various aspects of switching Windows 2000 and Windows XP users to
run inside the F5 Networks protected workspace (PWS). Running inside the
PWS, you can restrict users from printing, saving files, or storing information on
a Windows file share. Placing users inside the PWS is especially useful when
your users are working on devices that are outside of company control.
Running inside the PWS only reduces the risk of unintentional or accidental
information leaks, but does not eliminate that risk. The PWS restricts users to a
temporary workspace, which is created fresh at the beginning of each session.
This workspace contains temporary Desktop and My Documents folders. In
protected mode, the user cannot unintentionally or accidentally write files to
locations outside the temporary folders, unless you specify additional allowed
locations. The PWS control deletes the temporary workspace and all of the
folder contents at the end of a session. For additional security, when users
enter the PWS, the operation closes any third-party toolbars that are running.
Note that running inside the PWS does not prevent information leaks from
Internet mail, web blogs, or web chat.
Important! Although the protected workspace control does attempt to remove
temporary files after a hard reboot, users who perform a hard reboot of their
remote systems could allow viewing of and operations on the temporary files.
This inspector uses the session.pws.active == 1 variable to indicate that the
user is currently running inside the protected workspace. Available settings
include requesting a confirmation before entering the protected workspace,
allowing the user to temporarily exit the protected workspace, allow use of
printers while the user is in the protected workspace, closing Google Desktop
Search before placing the user into the protected workspace, and specifying
Windows share locations to which the user can write.
Virtual keyboard enabler
Toggles use of the virtual keyboard for client logon operations. Activating this
inspector presents a graphical representation of a keyboard and requires users
to type their password using mouse clicking on the graphical keyboard. This
helps prevent keyboard loggers from harvesting users logon names and
passwords. In addition to presenting the virtual keyboard, you can elect to have
the keyboard graphic repositions itself randomly with each mouse click.
Randomly repositioning prevents captured mouse movements from revealing
password information.
Windows antivirus checker
Enforces antivirus protection and performs endpoint checks for viruses. This
inspector uses a number of session variables. The online help contains a list of
them all.
This inspector uses the following rules:
Monitor is running
(session.av.summary.monitor >= 1) AND
(NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected !=
0)))
AV installed
(session.av.summary.count>0)AND
(NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected !=
0)))
Virus detected
EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)
Using one instance of this inspector, you can scan for up to three antivirus
packages. To find the list of supported antivirus packages, see the online help
for the Windows antivirus checker.
3-4
Inspector
Description
Windows file checker
Checks for the presence of certain Windows files using the
session.file_check.<filename>.result session variable. A match to
session.file_check.<filename>.result ==1 indicates the presence of the file
with all associated parameters.
Windows firewall checker
Checks for the presence of a firewall on the remote system. This inspector uses
the following rules:
running
session.fw.summary.enabled == 1
installed
session.fw.summary.count>0
You can enable the Windows firewall if other firewalls are not enabled. To find
the list of supported firewalls, see the online help for the Windows firewall
checker.
Windows process checker
Collects information about the running Windows processes using the
session.process_check.<process>.result session variable. A match to
session.process_check.<process>.result == 1 indicates that the process is
running.
Windows registry checker
Collects information about Windows registry keys using the
session.process_check.<registry_check_ID>.result session variable. A
match to session.process_check.<registry_check_ID>.result == 1 indicates
the presence of the registry item specified on the details page for this inspector.
Using session variables
You can use session variables to direct users to a specific master group and
assign them specific resource groups based on session variables. FirePass
controller session variables consist of two main sets:
• Session variables defined during pre-logon sequence
The FirePass controller defines these variables while the system performs
pre-logon checking. These variables contain information about the client,
or information that you define for custom variables.
You can find a complete list of these variables in the online help for the
Users : Endpoint Security : Pre-Logon Sequence screen and in the online
help for the Define custom variable inspector.
• Session variables defined during group mapping and user authentication
During dynamic group mapping and user authentication, the FirePass
controller retrieves user attributes from the external Active Directory and
LDAP servers. The system then converts these attributes to session
variables.
Note
The FirePass controller does not convert to session variables attributes
received from external RADIUS servers.
3-5
Chapter 3
The FirePass controller names the session variables in the following
manner:
session.ad.groupmapping.attribute_name = attribute_value
session.ldap.groupmapping.attribute_name = attribute_value
session.ad.auth.attribute_name = attribute_value
session.ldap.auth.attribute_name = attribute_value
If the attribute contains multiple values, the FirePass controller forms a
space separated string containing all values, and uses that as the attribute
value.
session.ad.groupmapping.attribute_name = "attribute_value1
attribute_value2…"
session.ldap.groupmapping.attribute_name = "attribute_value1
session.ad.auth.attribute_name = "attribute_value1
session.ldap.auth.attribute_name = "attribute_value1
You can use the session variables corresponding in the following ways:
• To configure Network Access favorites. For example, you might specify
session.ldap.auth.SubNetAddress in the LAN address space box for a
Network Access favorite. Then, when a user is authenticated, the
FirePass controller substitutes the user’s SubNetAddress value. You can
configure this option in a favorite definition, available on the Network
Access : Resources screen.
• To configure protection criteria when defining a protected configuration.
For example, in the Custom check expression box you might specify
%session.ldap.auth.NetworkAccessAllowed%=YES
AND
%session.ldap.auth.OU%=Sales
Then, when the user matching these specifications logs on, the FirePass
controller allows access to the resources protected by that configuration.
You can configure this option in a protected configuration definition,
available on the Users : Endpoint Security : Protected Configuration
screen.
• To configure various rules in pre-logon sequences, which you can then
use for defining protected configuration. You can configure this option in
a pre-logon sequence, available on the Users : Endpoint Security :
Pre-Logon Sequence screen.
• To direct different users to different webtops based on the landing URI
they request. For example, you can use the session variable
%session.userdef.my-dynamic-webtop% for different master groups
on the Portal Access : Web Applications : Intranet Webtop screen. Then,
you create a pre-logon sequence to initialize this custom variable to
appropriate values based on landing URI information.
3-6
You can enable the Save user’s session variables to Logon Report option
on the Device Management : Maintenance : Troubleshooting screen to have
the system write a user’s session variables to the Logon report for that user.
Then you can view the variables on the Reports : Logon screen.
Performing remediation
When the endpoint security process is inspecting the client systems, it can
take several actions to correct the state or condition of the client computer.
◆
Present information to the user
If the inspection process requires the download of certain controls or
plug-ins, and the user does not have sufficient privileges for the
download operation, the system can inform the user and present
recommendations for making the changes necessary, or ask the user to
download and install a security update. You can present information to
the user using the Information box inspector.
◆
Perform the action needed
If the protection configuration needs a specific condition to be met, and it
is possible to perform the action, the system takes the remediative action
necessary. The following items describe some actions that the system can
take to remediate the situation.
• If the protection configured requires that the computer run in the
protected workspace, the system can place the running processes into
the protected workspace. The Protected Workspace inspector
performs this action automatically.
• Depending on the action needed, the system can present a list of
options from which the user can select. You can write rules tailored to
the options that you provide. For example, you can write a set of rules
that redirect users to various external logon pages, by defining a
Decision box inspector with different External Logon Page endings.
• If the protection configured requires that a specific process not be
running, the system can ask the user to halt the process.
• Depending on the protection configured, the system can locate
installed antivirus and firewall software, and configure actions based
on the results returned.
• If the protection configured requires a scan for viruses, the system can
run virus-scanning operations, using actions associated with the
Windows Antivirus Checker Inspector.
• If the protection configured requires an updated version of an
antivirus software package, the system can ask the user to download
and update the package. You can use the External Logon Page ending
to send the user to a custom page you create on an external server, or
to a page you create in the FirePass controller sandbox. For more
information, search for WebDAV in the FirePass controller online
help.
3-7
Chapter 3
◆
Request action from the user
If the protection configured requires any action that the system cannot
complete, you can configure a request that the user perform the action
instead. For example, if the protection configured requires an updated
version of an antivirus software package, and the system cannot
automatically download and update the package, you can configure a
request that the user download and update the package before continuing.
Protecting resources
The final task of the pre-logon sequence is to protect resources. Protected
configurations use information that the inspectors gather to protect the
resource you assign them to. Protected configurations use the values that the
pre-logon sequence returns in its session variables to determine how to
respond to requests for resource access.
Important
If you plan to use protected configurations to grant or deny access to
resources, you must construct and activate a pre-logon sequence that
collects all necessary information. If you assign protected configurations to
your resources, but you do not activate a sequence, users receive the
following message: Endpoint check is not activated or pre-logon inspection
failed.
You can read more about protected configurations in Creating protected
configurations, on page 3-27. You can read more about protecting resources
in Protecting resources, on page 3-31.
Understanding protection options
You can configure protection options based on a number of factors,
including operating system, type of browser used, presence of a specific file
or process, and others. You can also define custom session variables in
pre-logon sequences so that a protected configuration can check whether the
user has passed a particular point in the pre-logon sequence. For more
information about custom session variables, see the online help for the
Endpoint Inspector Details screen for the Define custom variable inspector.
You can select from a wide range of antivirus and firewall software the
FirePass controller supports, such as Symantec® (Norton AntiVirusTM),
Networks Associates (McAfee®), and Microsoft®. The software supported
changes frequently, so the current list is maintained in the FirePass
controller release notes that accompany a specific release. In addition to
3-8
antivirus and firewall detection, inspectors provide information about
operating system, file versions, running processes, and others. You can use
this information to configure protection options.
Note
You must have an Anti-Virus/Firewall / Inspector license on the FirePass
controller to inspect the client system for antivirus and firewall software. If
you do not have a license, contact your sales representative to get one.
The inspectors you set up on the FirePass controller evaluate or operate on
client systems in several areas:
◆
Antivirus and firewall detection
Detects multiple antivirus and firewall installations on a client computer.
You can use the Windows antivirus checker to determine whether the
user has antivirus software installed, and to scan processes for the
presence of viruses.
◆
Operating system detection
Discovers the version of the operating system running the client
computer, so that protected configurations can use the version
information.
◆
File version checking
Evaluates the versions of antivirus binaries, DLLs, signature files, and
scan engines to determine whether they match the criteria you configure.
◆
MD5 signature validation
Inspects the MD5 signature of a file on a client system to ensure that the
file has not been tampered with or corrupted.
◆
Scan performance
Performs scans for viruses on the client machine. You can specify several
values to use when scanning for antivirus software:
• Antivirus vendor
Represents the maker of the antivirus software.
• Engine version
Represents the number assigned to a specific release of the software.
• Database signature
Represents an electronic, encryption-based, secure stamp of
authentication provided by the antivirus vendor by which you can
determine the authenticity of the software.
You can find database signature information by searching the Internet
or checking for the value on a specific product's web site.
• Database update time
Represents the timestamp on the antivirus software on the user’s
computer.
◆
Custom inspector usage
Gathers data related to the custom variable defined.
For more information, see the Endpoint Inspector Details online help for
the Define custom variable inspector .
3-9
Chapter 3
Understanding protection limitations
For Windows clients, the FirePass controller downloads and installs
ActiveX controls or Java plug-ins to gather some information on the client
device. To install the controls or plug-ins, the logged on user must have
power user rights on the device. You can also preinstall the controls on the
client machine using an administrator account, or an account that has power
user rights. For more information about installing client components, see
Using MSI to preinstall client components, on page 9-3 and Using the
Component Installer, on page 9-4.
In addition, the client’s browser must be configured to allow the running of
ActiveX controls, Java, and JavaScript, otherwise, the inspection operation
might not collect all of the information needed.
Pre-logon inspection switches to clientless mode automatically if
installation of the required ActiveX control or Java plug-in failed due to
insufficient rights, or the operating system does not support the control or
plug-in. In clientless mode, information collection and actions that require
client components are not performed. The following actions do not require
any client components to be downloaded to the client system.
• Show virtual keyboard
• Send email
• Check the time on the system
• Check the type of device
• Check the operating system
• Check the client certificate
• Write content to the Logon log
3 - 10
Using pre-logon sequences
The FirePass controller collects information from the client system by using
inspectors. The various inspectors consist of ActiveX controls or Java
plug-ins that collect information about the client system. When a user first
accesses the FirePass controller, the browser downloads the inspector
control or plug-in needed to check for a specific condition, process, or piece
of data.
You can configure inspectors in pre-logon sequences, a named set of
inspectors, rules, and actions, which evaluates each endpoint system
presented for log on to the FirePass-controlled network.
Protected configurations use information that the inspectors gather. If the
system meets the requirements configured in the protected configuration, the
user is granted access to the resource requested.
You use the visual policy editor to create pre-logon sequences. The visual
policy editor consists of a graphical area in which you click to add and
delete actions and rules to use when inspecting the client system to
determine whether it meets certain conditions.
You can configure pre-logon sequences using options on the Pre-Logon
Sequence screen. To access the screen, click Users, expand Endpoint
Security, and click Pre-Logon Sequence.
For step-by-step procedures for creating a pre-logon sequence, see Creating
the Google Desktop Check pre-logon sequence, on page A-2.
3 - 11
Chapter 3
Understanding pre-logon sequence flow
When a pre-logon sequence is active and a user logs on, a series of
operations occur based on the content of the sequence. Figure 3.1,
following, describes the basic flow.
Figure 3.1 Pre-logon sequence flow
Understanding the visual policy editor
You use the visual policy editor to create and modify the pre-logon
sequences you want to use in checking client systems. The layout of the
sequence in the visual policy editor window provides visual clues to indicate
the flow of the action as it occurs on the client system.
Figure 3.2, following, contains the Corporate Access Check pre-logon
sequence, which you can create by following steps in Denying and allowing
logons from specific operating systems and requiring certificates, on page
A-10.
3 - 12
Figure 3.2 Corporate Access Check pre-logon sequence with open CHANGE SEQUENCE pane
Note
The Corporate Access Check pre-logon sequence contains an action named
Show virtual keyboard, which is attached to the rule Windows NT and 2000.
This action presents a visual representation for Windows NT and Windows
2000 users to protect against key-logger software. For more information
about the Show virtual keyboard action, see the online help for the Virtual
Keyboard enabler Endpoint Inspector Details screen.
Understanding pre-logon sequence elements
When you construct a pre-logon sequence, you use the visual policy editor
to add actions, which are made up of rules. You can use one of the
predefined actions, or you can construct one of your own. You can add
inspectors to existing or custom actions, and you can build rules for the
inspectors to use.
3 - 13
Chapter 3
As you construct pre-logon sequences, you can use the elements described
in Table 3.2.
Element
Description
Action
Represents one or more inspectors associated with one or more rules. Actions provide the
container for the inspectors. In the visual policy editor, actions appear inside a rectangle.
Rule
Contains one or more Boolean expressions that describe a specific condition. Rules
evaluate what information the inspector collects. Each action has a fallback rule that
evaluates to true so you can specify the action to take if the result is not acceptable. For
example, the predefined action Check client certificate contains two rules: yes and
fallback. The yes rule defines the action to take if the result returned is acceptable. The
fallback rule defines the action to take if the result is not acceptable. In the visual policy
editor, rules appear along connecting lines as underlined words.
Ending
Indicates the final outcome of the pre-logon inspection. The FirePass controller provides the
following endings: Logon Allowed, Logon Denied, External Logon Page (Client data
posted), Redirect (No client data posted), and Subsequence. In the visual policy editor,
endings appear in a rectangle with a cut-out right edge.
External Logon Page and Redirect perform essentially the same function, except that
Redirect uses the GET command for redirecting and does not send any data to the external
server.
Subsequence
Represents a collection of actions, rules, and endings that branch off from the main
sequence path. In the visual policy editor, subsequences appear in the lower portion of the
screen, under the heading Subsequences. In the visual policy editor, a subsequence
appears in a rectangle with a pointed-out right edge when it occurs in the sequence
The subsequence appears in a shaded rectangle with a pointed-out right edge when it
occurs in the subsequence.
Table 3.2 Pre-logon sequence constituent elements
For an example of a subsequence, see Figure 3.2, Corporate Access Check
pre-logon sequence with open CHANGE SEQUENCE pane, on page 3-13.
3 - 14
Implementing client system checking
You want to make sure that all users accessing your resources are running
on computers that meet your security requirements.
The pre-logon sequences you construct gather the information about the
client system. The protected configurations you define use the information
gathered, and associate safety measures to respond to potential threats. Once
you have constructed the pre-logon sequences that gather the client-system
information and defined protected configurations that use safety measures to
address security risks, you assign the protected configurations to your
resources.
In summary, when you implement endpoint security to check client systems,
you must complete several tasks.
◆
Construct the pre-logon sequence
For more information, see Creating pre-logon sequences to protect
resources, on page 3-16.
◆
Create a protected configuration
For more information, see Creating protected configurations, on page
3-27.
◆
Assign the protected configuration
For more information, see Protecting resources, on page 3-31.
Important
You must create the pre-logon sequence to gather the information that the
protected configurations needs. Otherwise, protected configurations block
access.
3 - 15
Chapter 3
Creating pre-logon sequences to protect resources
The first task of implementing endpoint security is to create a pre-logon
sequence. The FirePass controller uses pre-logon sequences to provide the
functionality, available on the Users : Endpoint Security : Pre-Logon
Sequence screen.
In a pre-logon sequence, you configure inspectors to gather the information
you want to have about the client. The inspectors create session variables
containing the detected information. The FirePass controller passes the
information to the protected configuration to determine access to protected
resources.
The controller ships with several pre-defined sequence templates (for
example, Google Desktop Search block, Collect information with no
pre-logon actions, and Empty), which you can use or modify. You also can
create new sequences, using any of these as your starting point, or an empty
sequence with just a starting and ending point, if you prefer.
Once you create the sequence, you must use the data it gathers by creating a
protected configuration. A protected configuration is a collection of safety
measures or checks that guard the connection and client system against
various kinds of attacks or threats.
Creating a pre-logon sequence
Creating pre-logon sequences basically consists of adding actions in the
visual policy editor. Each action contains one or more rules that specify the
criteria that you plan to evaluate, and an ending that follows depending on
the outcome of the evaluation. For more information about actions, see
Using actions in pre-logon sequences, on page 3-19, and for more
information about rules, see Defining rules for actions in pre-logon
sequences, on page 3-23.
For example, you might want to require that all users operate inside a
protected workspace while they access a specific resource. To do so, you
create a new sequence, and add the action that switches the user to the
protected workspace.
To create a pre-logon sequence that checks whether the
user is in the protected workspace
1. In the navigation pane, click Users, expand Endpoint Security, and
click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens.
2. In the Create new sequence box in the New Sequence area, type a
name for the sequence.
3. From the Based on list, select template : Empty.
3 - 16
4. Click Create.
The new sequence appears in list of sequences in the upper portion
of the screen.
5. Click the edit link next to the sequence you created.
The visual policy editor screen opens.
6. Position the cursor along the connecting line between Sequence
Start and Logon Allowed Page, until you see the insert-action icon
.
7. Click the
icon.
The screen refreshes to show the change sequence pane.
8. In the list of Predefined actions, select Switch to PWS.
9. Click the Apply changes button.
The screen refreshes to show the Switch to PWS action, along with
two rules: inside PWS, which continues to the Logon Allowed Page
ending, and fallback, which continues to the Logon Denied Page
ending. Figure 3.3, following, shows the completed pre-logon
sequence.
Figure 3.3 The completed sequence containing the Switch to PWS action
Next, you use the data the pre-logon sequence gathered in a protected
configuration. For more information, see Using data gathered by pre-logon
sequences, following.
The active pre-logon sequence runs when a user tries to log on to the
FirePass controller. Only one pre-logon sequence is active at any one time.
A selected button next to the sequence name on the Users : Endpoint
Security : Pre-Logon Sequence screen indicates the active pre-logon
sequence.
3 - 17
Chapter 3
Using data gathered by pre-logon sequences
In Creating a pre-logon sequence, preceding, you created a pre-logon
sequence that inspects client systems for the protected workspace. Now, you
can put that data to use in a protected configuration and assign the
configuration to a resource favorite.
To create a protected configuration that uses the data
collected by the protected workspace pre-logon sequence
click Protected Configurations.
The Protected Configurations screen opens, showing a list of
predefined protected configurations.
2. Click the New Protected Configuration link.
The Protected Endpoint Configuration definition screen opens.
3. In the Protected configuration ID box, type a name of up to 30
characters for the protected configuration.
4. In the Description box, type a description, if you wish.
5. From Mode, select the type of access you want.
Check endpoint protection, grant access if check passed is the
default. This is the recommended setting for using protected
configurations. The Temporary bypass check, grant access
always and Temporary bypass check, do not grant access
settings are for temporarily troubleshooting configurations and
logon problems.
You do not need to click Cancel or Save at this point.
6. Click the Protection Criteria tab along the top of the table.
The Protected Configurations screen opens with the Protection
Criteria tab selected.
7. Click the Information Leaks link.
The screen refreshes to reveal the safety measures or checks
associated with information leaks.
8. From the list, select Protected Workspace, and then click Add.
The Required safety measures or checks area refreshes to contain
the Protected Workspace criterion.
9. Click Save.
The Protected Configurations screen opens, with the protected
configuration you created shown at the bottom of the list.
10. Next, you assign the protected configuration to a resource. For more
information, see Assigning a protected configuration, following.
For more information about creating protected configurations, see Creating
protected configurations, on page 3-27.
3 - 18
Assigning a protected configuration
In Using data gathered by pre-logon sequences, preceding, you created a
protected configuration that uses the protected workspace information the
pre-logon sequence gathers. Now, you can put that protected configuration
to work, by assigning the configuration to the webtop, an entire resource
group, a resource type, or an individual favorite.
To assign a protected configuration to a favorite
1. In the navigation pane, click Portal Access, or Application Access,
and click an existing favorite or the Add New Favorite link.
The favorite definition screen opens.
2. From the Endpoint protection required list, select the protected
configuration you just created.
3. Click Update.
The favorite appears in the list with the protected configuration
assigned. Now, users clicking the favorite are switched to the
protected workspace before being granted access to the associated
resource.
You can also use settings on the Users : Endpoint Security : Protect
Resources screen to assign a protected configuration to a favorite. For more
information, see Protecting resources, on page 3-31.
For more information about creating favorites, see Defining favorites for
Portal Access Web Applications access, on page 7-6, Configuring Windows
files, on page 7-35, Defining legacy host favorites, on page 6-26, or
Configuring terminal server favorites, on page 6-30.
Using actions in pre-logon sequences
An action, depicted by a rectangle in the pre-logon sequence editor (see
Table 3.2, on page 3-14), is an ordered set of rules for evaluating a remote
system. Each action invokes one or more inspectors. The action then uses
rules to test the inspectors’ findings.
An action invokes rules in the order they appear in the sequence. To change
the order, delete the rule you want to move, and recreate it in the desired
position. If the inspectors’ findings satisfy a rule’s conditions, the sequence
passes to the element in the sequence specified by the rule. Otherwise, the
process moves on to the next rule in the action.
The FirePass controller includes a number of predefined actions. You can
see the available actions in the visual policy editor when you click the
insert-action icon , which is activated by positioning the cursor along the
action’s connector line. The action pane appears to the right of the visual
sequence editor, as shown in Figure 3.2, on page 3-13. You can create your
3 - 19
Chapter 3
own custom rules in the action pane of the visual policy editor. To follow a
step-by-step lesson in creating your own pre-logon sequence, see Appendix
A, How-To Examples.
When you create a new action, the sequence editor automatically creates a
default rule, called fallback. The fallback rule is always the last rule in the
ordered set of rules. It cannot be moved. It governs all cases that do not
satisfy a preceding rule. The default next action for the fallback rule is the
Logon Denied Page ending. You can change this by editing the ending,
inserting additional actions, or adding other rules.
Figure 3.4 shows the internal structure of an action.
Figure 3.4 The flow of control in a pre-logon sequence action
3 - 20
You can see an example of the action pane for the Check for Antiviruses
action in Figure 3.5, on page 3-22, available when you have a license for the
Anti-Virus / FireWall Checker inspector. Table 3.3, following, shows the
rules and definitions for the Check for Antiviruses action.
Rule
Definition
Monitor is running
(session.av.summary.monitor >= 1) AND
(NOT(EXIST(session.av_scan.infected) AND
(session.av_scan.infected != 0)))
AV installed
(session.av.summary.count>0)AND
(NOT(EXIST(session.av_scan.infected) AND
(session.av_scan.infected != 0)))
Virus detected
EXIST(session.av_scan.infected) AND
(session.av_scan.infected != 0)
fallback
The default rule for every action
Table 3.3 Rules and definitions for the Check for Antiviruses action
3 - 21
Chapter 3
The action pane is where you can type a description for the action, add and
modify the action’s inspectors, and define rules for the action to use. Figure
3.5, following, contains the Check for Antiviruses’s action pane with the
rules shown.
Figure 3.5 The action pane for the Check for Antiviruses action
For additional information, see the help for each inspector, and review the
rules of the predefined actions shipped with the FirePass controller.
3 - 22
Defining rules for actions in pre-logon sequences
A rule determines the flow of actions. The outcome of the evaluation in a
rule grants or denies access or sends the flow to the next action.
In a pre-logon sequence, you use predefined actions with already defined
rules. You can modify these rules or create new rules to test for a specific
condition. You can create custom actions and add your own rules to them.
The ending is the last rule applied. Figure 3.4, on page 3-20, shows the flow
of a rule-checking operation.
A rule uses data from variables returned by inspectors to determine user
access criteria. For more information about variables, see Using session
variables in sequence rules, on page 3-24.
By default, if the system does not meet the requirements, the FirePass
controller denies the user access. You can change the outcome by changing
the sequence ending, and by modifying rules to check for different criteria.
Using rule syntax
You can include the following syntax elements in rules:
◆
Boolean operators: AND, OR, NOT
◆
Operators:
• less than <
• less than or equal to <=
• greater than >
• greater than or equal to >=
• equal to =
• equal to ==
• not equal to !=
◆
◆
Functions: EXIST()
Other symbols: (, ), “
Viewing rule examples
Following are some examples of rules. The first rule defines the criterion
that a user’s system be in the protected workspace.
session.pws.active == 1
The session variable session.pws.active has two possible values: 1, which
indicates that the user’s computer is operating inside the protected
workspace, and 0, which indicates that it is not.
The second example represents a rule that searches for the presence of the
McAfee antivirus software that has an engine version greater than or equal
to 4.3.20, and checks to make sure that the most recent antivirus scan
occurred on or after December 12, 2004, at midnight.
3 - 23
Chapter 3
(EXIST(session.av.McAfeeAV))AND(session.av.McAfeeAV.engine_version >= "4.3.20")AND(
session.av.McAfeeAV.last_scan >= "2004.12.10 00:00")
You can see an example of the not running rule included with the
predefined action Google Desktop Search Checker in Figure A.6, on page
A-6. In this case, the rule description is
session.google_desktop_check.result !=1, which indicates that when the
session variable is not equal to 1, then the Google Desktop Search
application is not running.
You can edit a rule by clicking the rule’s link in the visual policy editor. The
rules pane appears to the right of the visual sequence editor, as shown in
Figure A.15, on page A-15.
For additional information, see the help for each inspector and review the
rules of the predefined actions shipped with the FirePass controller.
Using session variables in sequence rules
The rules in pre-logon sequences use the values that the inspectors return in
session variables. A session variable contains a number or string that
represents a specific piece of information. You can specify another action or
an ending in response to the information returned. To understand how rules
operate in sequences, you can view the sequence flow defined in the
predefined actions provided with the FirePass controller.
You can use session variables to create your own rules to use in the custom
actions you define.
To create a rule
click Pre-Logon Sequence.
2. Open an existing sequence, or create a new one.
The visual policy editor opens.
3. Add an action as described in Creating a pre-logon sequence, on
page 3-16.
The action pane opens in the visual policy editor.
4. From the Using list in the action pane, select New action.
5. Click Apply changes.
The sequence refreshes to contain the action New action.
6. In the Name box in the action pane, change the name to a
meaningful title for the action, and add some descriptive text in
Description, if you like.
7. Click Update details.
The visual policy editor refreshes to show the title you specified.
8. Position the cursor along the connecting line between the action you
added and the fallback rule, until you see the insert-rule icon .
3 - 24
9. Click the
icon.
The screen refreshes to show the insert rule pane.
10. In Name, type a name for the rule.
11. In the larger box, type the session variable and the other text you
want to use for the rule.
For information about the expression syntax for rules, see Defining
rules for actions in pre-logon sequences, on page 3-23.
For a list of the session information returned by specific inspectors, see the
online help for the Pre-Logon Inspection screen.
Creating subsequences for pre-logon sequences
Subsequences are defined sequences that run when processing encounters a
branch in the sequence. Subsequences do not pass control back to the parent
sequence from a subsequence; the flow continues through to the
subsequence ending, or to another subsequence. However, when you are
creating sequences, having subsequences can eliminate duplication in
sequences. Using subsequences is particularly useful when you have a
number of actions that all run the same series of rules, actions, and endings.
For example, the Corporate Access Check sequence, which you can create
by following steps in Appendix A, How-To Examples, contains a
subsequence named Subsequence: certificate check that runs at the end of
the Windows XP, Linux, PocketPC, and Mac OS rules.
The subsequences section of the visual policy editor appears below the main
sequence section. You can create and use as many subsequences as you like
to support the sequence you want to apply. Figure 3.6, following, contains
an example of a subsequence.
Figure 3.6 The subsequence certificate check from the Corporate Access
Check sequence
3 - 25
Chapter 3
Browser requirements for endpoint security
The FirePass controller supports only specific browser versions and
functionality. The browser enables communication with the client systems
so that the inspectors can access information and perform scans and other
operations. For information about browser requirements for client
component download, see Downloading client components, on page 9-1.
You can find the most current browser support list in the release notes. For
information about user rights requirements for endpoint inspector support.
see Installing client components on Windows systems, on page 9-1.
User rights requirements for protected workspace and pre-logon
inspectors
Because of how the FirePass controller supports protected workspace and
pre-logon inspectors, the user must have certain rights for the process to
complete successfully. In most cases, this means the user must have Power
User or Admin rights, or you must preinstall the components using an
account with such rights. For more information, see Installing client
components on Windows systems, on page 9-1.
3 - 26
Creating protected configurations
Once you have determined the client information you plan to gather, you
create protected configurations, named sets of safety checks and security
measures, to assign to resources, applications, and files.
Protected configurations represent the conditions that control access to
resources under their protection. Controlled conditions include what
antivirus software the endpoint system is running, whether a logon comes
from a company-issued computer, what time of day the logon occurs, which
certificate the client is using, and others. Protected configurations provide a
way for you to collect a set of safety requirements, store it under a name of
up to 30 characters, and assign it to a resource to define a very restrictive set
of configurations that govern access to the resources presented to end users.
Security measures help guard against factors that put network resources at
risk. These are described in the risk-factor/safety-feature associations table
on the Protected Configurations configuration screen. To access the screen,
click Users, expand Endpoint Security, click Protected Configurations,
and click the New Protected Configuration link, or click the name of an
existing protected configuration.
In order to use a protected configuration, a pre-logon sequence inspector
must gather the necessary information. For information about pre-logon
sequences and inspectors, see Using pre-logon sequences, on page 3-11.
Important
Protected configurations use the result of the pre-logon and post-logon
operations to determine how to respond to requests for resource access. To
take advantage of protected configurations, you must define and activate a
pre-logon sequence. If you assign a protected configuration without
properly configuring a pre-logon sequence, you lock out all access to that
resource.
You can assign protected configurations at a very granular level by
exempting specific master groups from safety checks configured for a
resource. For a very refined accessibility/protection trade-off, you can
combine safety checks using Boolean logic, as described in the Defining
rules for actions in pre-logon sequences, on page 3-23.
Table 3.4, following, provides a summary of risk factors and associated
protection criteria available for protected configuration definitions.
3 - 27
Chapter 3
Risk factor
Available protection
Unauthorized Access
The following protection criteria are available for preventing unauthorized access:
Client Certificate
Requires that the client certificate meet criteria specified in properties. For this type of
protection, you must enable a pre-logon sequence.
Trusted Network
Specifies that logon is restricted to traffic arriving from the networks specified in properties.
To access properties, click the [ I ] icon to the right of the Trusted Network entry in the
table. For this type of protection, you must enable a pre-logon sequence.
Time Interval
Restricts access to the days and hours specified in properties. This protection requires no
pre-logon sequence.
Custom Check
Checks variables collected by the pre-logon sequences (or a variable set by the define
custom variable inspector). For this type of protection, you must enable a pre-logon
sequence.
Note: Only the Custom Check protection can use the data returned by the user-defined
variable in a pre-logon sequence. For more information, see the online help for the Endpoint
Inspector Details screen for the Define custom variable inspector.
SSL Encryption Control
Provides options for requiring specific SSL cipher security and SSL protocol versions. You
can read more about SSL cipher and protocol settings in the online help for the Device
Management : Security : User Access Security screen. For this type of protection, you must
enable a pre-logon sequence.
Note: F5 Networks recommends that customers use TLS only protocol option to ensure
maximum FIPS cipher compliance. In addition, to ensure maximum FIPS compliance, F5
recommends that SSL certificates that administrators import into the FirePass controller use
FIPS-approved SHA1 instead of MD5 as their signing algorithm.
To maximize FIPS compliance, configure FirePass systems to allow only TLS (that is, select
the Accept only TLS protocol option), and verify that all RSA private keys for Web Services
have been imported into the FIPS card. On systems with imported keys, the Security field
lists FIPS instead of Normal in the online help for the Device Management : Configuration :
Network Configuration › Web Services : Configure SSL Certificates screen.
No Measure or Check Required
Indicates that no protection is configured for the risk factor. For this type of protection, you
must enable a pre-logon sequence.
Logon Allowed
Checks that prelogon inspection was done and that logon was allowed. For this type of
protection, you must enable a pre-logon sequence.
Table 3.4 Risk factors and associated protection criteria
3 - 28
Risk factor
Information Leaks
In addition to Client Certificate, No Measure or Check Required, and Trusted Network,
described above, the following protection criteria are available for preventing information
leaks:
Protected Workspace
Requires a user workspace that prevents external access and deletes any files created
before leaving the protected area. When you add the Protected Workspace protection, the
user is placed into the protected workspace after logging on successfully. Operating inside
the protected workspace restricts access to specific folders and deletes all files created
when the user logs out. You can read more about using the protected workspace inspector
in the Endpoint Security : Pre-Logon Sequence online help. For this type of protection, you
must use the Protected Workspace inspector in an enabled pre-logon sequence.
Trusted Windows Version
Restricts access to users running specific Windows versions or hot-fixes, as specified in
properties. If you specify Trusted Windows version, make sure also to configure the versions
you want to accept in properties. To access properties, click the [ I ] icon to the right of the
Trusted Windows Version entry in the table. For this type of protection, you must use the
Extended Windows information inspector in an enabled pre-logon sequence.
Cache Cleaner
Removes content from the cache when users log out. For this type of protection, you must
enable Inject ActiveX/Plugin to clean-up client browser web cache on the Users :
Endpoint Security : Post-Logon Actions screen.
Trusted Browser
Requires use of a browser specified in properties. If you specify Trusted Browser, make sure
also to configure the browsers you want to accept in properties. To access properties, click
the [ I ] icon to the right of the Trusted Browser entry in the table. For this type of
protection, you must use the Internet Explorer information inspector in an enabled pre-logon
sequence.
You can read more about the inspectors in the online help.
Loggers
In addition to Protected Workspace, Trusted Network, Client Certificate, and No
Measure or Check Required, described above, the following protection criteria are
available for preventing access by key-logging programs:
Virtual Keyboard
Specifies that passwords be entered using mouse clicks on a screen representation of a
keyboard. For this type of protection, you must use the Virtual Keyboard Enabler inspector in
an enabled pre-logon sequence.
Registry Control
Associates a result with a specific name generated by a Pre-Logon add Windows registry
checker operation. For this type of protection, you must use the Windows registry checker
inspector in an enabled pre-logon sequence.
Process Control
Associates a result with a specific name generated by a Pre-Logon add Windows process
checker operation. For this type of protection, you must use the Windows process checker
File Control
Associates a result with a specific name generated by a Pre-Logon add Windows file
checker operation. For this type of protection, you must use the Windows file checker
3 - 29
Chapter 3
Risk factor
Virus Attack
In addition to Protected Workspace, Virtual Keyboard, Trusted Network, Client
Certificate, Registry Control, Process Control, File Control, and No Measure or Check
Required, described above, the following protection criteria are available for preventing
virus attacks:
Antivirus
Requires the presence of specific antivirus software, as specified in properties. To access
properties, click the [ I ] icon to the right of the entry in the table. For this type of protection,
you must use the Windows antivirus checker inspector in an enabled pre-logon sequence.
Firewall
Requires the presence of specific firewall software, as specified in properties. To access
properties, click the [ I ] icon to the right of the entry in the table. For this type of protection,
you must use the Windows firewall checker inspector in an enabled pre-logon sequence.
Note: You must have an Anti-Virus/Firewall / Inspector license on the FirePass controller to
inspect the client system for antivirus and firewall software. If you do not have a license,
contact your sales representative to get one.
3 - 30
Protecting resources
Once you have the protected configurations you want, you protect resources,
a process of assigning protected configurations to resources, applications,
and file stores. The FirePass controller uses protected configurations to
control access to network resources.
For example, you may have a general configuration for all Network Access
favorites, which require only that the logon arrive from a computer with
installed and running antivirus software. In this case, you would create a
pre-logon sequence that requires company-provided antivirus software,
define a protected configuration that uses the information from the
pre-logon sequence, and assign the protected configuration to all Network
Access favorites. This prevents access to network resources from computers
that are possibly infected, thus protecting your corporate intranet.
The FirePass controller uses protected configurations to control access to
network resources. A protected configuration is a definition of criteria that
users’ systems must meet in order to be granted access to specific resources.
Once you define a protected configuration, you must assign it. You can
assign resource protection at the following levels:
• Webtop
Protects all types of resource favorites.
• Resource type
Protects a class of resource favorites (for example, Web Applications or
Network Access favorites).
• Resource group
Protects all elements defined in resource group including favorites and
access control lists.
• Individual
Protects a single resource (for example, the Sales Intranet).
Protection is cumulative. That is, each type of protection is combined, so
that the effect is additive, affecting all resources at all levels.
Important
Protected configurations use the result of pre-logon and post-logon
operations to determine how to respond to requests for resource access. To
take advantage of protected configurations, you must define and activate a
pre-logon sequence. If you assign a protected configuration without
properly configuring a pre-logon sequence, you lock out all access to that
resource.
You can define custom session variables in a pre-logon sequence, so
protected configurations can check whether a user has passed a particular
point in the logon sequence. For more information, see the online help for
pre-logon sequences. For information about protected configurations, see
Creating protected configurations, on page 3-27. For information about
pre-logon sequences, see Using pre-logon sequences, on page 3-11.
3 - 31
Chapter 3
Understanding protection assignment
This is an example of how to implement access control using protected
configurations.
The sample company has a general configuration for all Network Access
resource favorites, most of which require only that the logon arrive from a
computer running antivirus software. In this case, you create a pre-logon
sequence that requires company-provided antivirus software. In addition, for
the Sales Intranet, the company wants to further require that the employee
use a company-issued laptop authenticated with a client certificate, and that
only members of the Executive and Sales groups are eligible.
For this configuration, the FirePass controller administrator creates and uses
two protected configurations: a general configuration (which allows access
to all Network Access resources not otherwise secured) that requires that the
user’s computer has antivirus protection, and a second configuration (which
grants access to Sales and Executive users with certificate-bearing company
laptops) that allows certain users also to access the Sales Intranet.
Configuring post-logon protection
For additional security, you can configure protection that runs after the user
logs on to the FirePass controller. You can configure to download an
ActiveX control or Java plug-in to support the following kinds of post-logon
protection.
• Activate cache cleanup to allow attachment downloads in Mobile E-Mail
and downloads from Web Applications.
• Activate cache cleanup to allow file downloads in Windows Files. If this
option is not checked, the user can only download .zip archives.
• End the FirePass controller session if the user closes the browser or
webtop.
• Uninstall downloaded FirePass controller components.
• Remove dial-up entries that Network Access clients use.
• Uninstall ActiveX components downloaded during the session.
• Empty the Windows Recycle Bin.
• Clean forms and passwords autocomplete data.
• Close Google Desktop Search.
• Inherit caching policy settings from Portal Access Web Applications
configuration.
You can specify different post-logon protection for each master group.
For more information on each of these options, see the help for the
Post-Logon Actions screen, available under Users : EndPoint Security.
3 - 32
Using other kinds of protection
In addition to the protected configurations described in Table 3.4, on page
3-28, there are other protections such as:
• Two-factor authentication
For information, see Configuring client-certificate two-factor
• Using certificates
For information, see Setting up client-certificate-based authentication,
on page 2-55.
• Pre-logon inspection
For information, see Using pre-logon sequences, on page 3-11.
• Requiring strong passwords
For information, see Setting up initial signup on LDAP with subsequent
strong internal password, on page 2-53.
• Configuring other authentication features for groups
For information, see Setting up authentication, on page 2-46.
3 - 33
Chapter 3
3 - 34
4
• Understanding SSL server certificates
• Managing certificates on the FirePass controller
• Generating a Certificate Signing Request or
self-signed certificate
• Installing and configuring client root certificates
• Using OCSP to validate client certificates
Understanding SSL server certificates
The SSL (Secure Sockets Layer) protocol uses the certificate to establish a
secure connection. A valid SSL server certificate, also known as a security
certificate, is necessary for establishing secure HTTPS connections. An SSL
server certificate identifies your server to any connecting client browser.
The certificate contains information identifying the server, the organization
it was issued to, as well as an expiration date. Most browsers that support
SSL connections have internal lists of Certificate Authorities (CAs), and
automatically accept certificates issued by these organizations. If there is an
error, some browsers display security warnings; other browsers, notably
those found on wireless devices such as PDAs or smart phones, might refuse
a connection.
Note
When a signed certificate expires and you do not plan to update it, you
should delete it from the FirePass controller. For information on how to
delete a certificate, see Deleting installed certificates, on page 4-10.
Using server certificates on the FirePass controller
When a user connects to the FirePass controller, the FirePass controller
presents a server certificate to the client browser. The browser validates the
certificate based on its internal list of trusted certificates from CAs, and, if it
finds a match, allows the connection. The browser displays a warning if:
• There is no corresponding CA certificate to validate against.
• The name of the server certificate does not match the name of the server
(the FirePass controller) in the URL.
• The certificate is expired.
The FirePass controller includes a preconfigured, default SSL server
certificate for firepass.company.xyz. You can use this certificate while
configuring and testing a FirePass controller, but the certificate is not
unique, and the certificate’s server name will not match the name you give
to the FirePass controller, so anyone connecting to the FirePass controller
sees warning messages from their web browser.
Important
Before you make the FirePass controller available to external users, you
should replace the default server certificate with a permanent certificate
that is appropriate for your environment.
4-1
Chapter 4
Using Certificate Authority-signed SSL server certificates
Most organizations should purchase and install a server certificate signed by
a known, trusted CA. A CA-signed certificate provides a high level of trust
by verifying that the server is actually what it claims to be. Most web
browsers automatically recognize server certificates issues by known,
trusted CAs, and FirePass controller users can log on without seeing
warning or error messages.
To obtain a trusted server certificate, submit a Certificate Signing Request
(CSR) to a trusted CA such as Thawte or Verisign. The CA verifies your
organization’s identity before issuing a signed certificate.
You can generate a CSR from the FirePass controller Administrative
Console. For more information, see Generating a Certificate Signing
Request or self-signed certificate, on page 4-4.
Using self-signed SSL server certificates
An alternative to a CA-signed server certificate is a self-signed certificate. A
self-signed server certificate is a digital certificate signed by its owner. The
self-signed certificate that the FirePass controller generates provides a
greater level of trust than the default certificate, but it is not as secure as a
CA-signed certificate.
Note
All production-level FirePass controllers should have a server certificate
signed by a known, trusted CA.
A self-signed certificate is automatically recognized by client browsers, so
users connecting to a FirePass controller that has a self-signed certificate
installed may see warnings posted by the browser. The user can add the
certificate to the browser’s accepted list to eliminate the warnings. For
details on self-signed certificates, see Generating a Certificate Signing
Request or self-signed certificate, on page 4-4.
A CA-signed server certificate provides the highest level of trust, but a
self-signed certificate may provide an acceptable level of trust for some
production environments. A self-signed certificate has not been validated by
a trusted organization, but it is unique (the default FirePass controller server
certificate is not).
4-2
Managing certificates on the FirePass controller
A pre-installed, default server certificate (for firepass.company.xyz) is
included on each FirePass controller. This certificate is intended only for
testing and initial configuration. It should not be used for any other purpose.
Before you make secure connections using the FirePass controller, you
should install at least one signed SSL server certificate.
When you want to manage server certificates, you can use options on the
Device Management : Security : Certificates screen.
• Display and review information about installed certificates
• Generate Certificate Signing Requests (CSRs) to submit to trusted
Certificate Authorities
• Install server certificates issued by known, trusted CAs
• Generate and install self-signed server certificates
• Update installed certificates
• Delete installed certificates
• Configure certificate revocation lists (CRLs) and Online Certificate
Status Protocol (OCSP)
Displaying information on installed certificates
You can determine what server certificates the FirePass controller has
installed, and view basic information about each certificate. The SSL Server
Certificate screen displays the following information:
• Status of the certificate (Valid or Fake. A status of Fake means the
certificate is invalid or has expired.)
• Names of the certificate and private key files
• Common name on the certificate
• The issuer of the certificate
• The certificate’s expiration date
To access the server certificates information
1. In the navigation pane, click Device Management, expand
Configuration, and click Network Configuration.
The IP Configuration screen opens.
2. Click the Web Services tab.
The Web Server Configuration screen opens.
3. Click the Configure SSL Certificates link.
The SSL Server Certificate screen opens.
The SSL Server Certificate screen lists all the server certificates that
you have installed on FirePass controller. If you have not installed
any certificates, the SSL Server Certificate screen lists only the
default certificate for firepass.company.xyz.
4-3
Chapter 4
Generating a Certificate Signing Request or
self-signed certificate
To install a server certificate, you first send a Certificate Signing Request
(CSR) to a trusted CA or create a self-signed certificate on the FirePass
controller. The FirePass controller provides functionality that automates the
process of getting a CA-signed certificate. When the CSR is generated, you
can save it, and submit it to a trusted CA. The CA verifies the identity of the
FirePass controller and sends you a signed digital certificate.
The self-signed certificate does not need to be sent to a CA. You can do one
or both of the following actions.
• Install the certificate on the FirePass controller using the process
described in To generate a certificate request or a self-signed certificate,
following.
• Install the certificate on the client computers using the procedures
described in Installing a self-signed certificate on client computers, on
page 4-8.
To generate a certificate request or a self-signed certificate
Security, and click Certificates.
The Certificates screen opens.
2. In the Renew/Replace SSL Server Certificate section, click
Generate to generate a CSR, or click Self-Sign to generate a
self-signed certificate.
The SSL Server Certificate screen opens, containing the Generate
New Certificate Request or Generate New Self-Signed Certificate
options, depending on what you clicked.
3. In the Server Name box type the fully qualified domain name
(FQDN) of the FirePass controller.
The following characters are not accepted in any certificate request
field: < > ~ ! @ # $ % ^ * / \ ( ) ?.,&
Note: Make sure the name you specify matches the name to be used
to access the FirePass controller on the web service using this
certificate.
4. In the Country Name box, type the two-letter country code, US for
the United States of America, JP for Japan, and so on.
5. In the State box, type the state or province in which your
organization is located.
6. In the City box, type the city in which your organization is located.
7. In the Company box, type your organization name.
8. In the Organizational Unit box, type the name or title of your
organizational unit.
4-4
9. In the Contact Email box, type your email address.
The CA uses this address for verification purposes, and for
notification at certificate-renewal time. If this is your first certificate
request, the CA may require additional information to verify your
identity and the validity of the data.
10. If you are generating a self-signed certificate, select an interval from
the Expiration list.
The default time limit is 1 month. If you plan to use the self-signed
certificate instead of a CA-signed certificate, select a time limit of
two years or longer.
If you are generating a CSR, the CA specifies the time interval
during which the signed certificate is valid, based on the time
interval purchased.
11. In the Encryption Password and Confirm Password boxes, type
the password for the FirePass controller to use to encrypt the
generated private key. A password must be at least four characters
long.
Note: Make a note of the password you specify; you will need this
password when you install the signed certificate.
12. Click the Generate Request button to generate a CSR, or click the
Generate Certificate button to generate a self-signed certificate.
The SSL Server Certificate screen opens, with a message saying
your CSR or self-signed certificate has been generated.
Note: If you skipped or mis-typed any required value, the screen
displays an error message when you click the generate button.
Correct the problem and click the appropriate generate button
again.
13. Review the information for accuracy.
14. Click the here link to download the CSR or self-signed certificate to
your local hard drive.
To avoid certificate warnings, users can add this self-signed
certificate to their browser’s list of acceptable certificates.
15. When prompted, download the CertRequest.zip or Cert.zip file to
your computer.
The .zip file contains three files, which differ depending on what
you generated.
Important
The FirePass controller does not save the CSR. You need to click the here
link to download the .zip file to a safe location.
4-5
Chapter 4
Submitting the CSR
For CSRs, the CertRequest.zip file contains the following files:
• README.html
Contains instructions for submitting the CSR to a known CA. You can
view this file using any browser.
• newcert.csr
Contains the content for the CSR.
• new.key
Contains the private key that corresponds to the certificate (encrypted
with the password you specified). Keep this file in a safe place. You need
it when you install your CA-signed certificate.
Submit your CSR to a known, trusted CA. Typically, certificate vendors
provide a web form in which you can paste the contents of the CSR file.
Alternatively, you can submit your CSR as an email attachment. If the
vendor requests a certificate type, specify mod_ssl (Apache). As part of the
verification process, the CA might contact you to verify details you
submitted in the CSR.
Understanding the files generated for the self-signed certificate
For self-signed certificates, the cert.zip file contains the following files:
• README.html
Describes the contents of the newcert.crt and newcert.key files.
• newcert.crt
Contains your newly generated self-signed SSL server certificate.
• newcert.key
Contains the private key that corresponds to the certificate (encrypted
with the password you specified).
Self-signed certificates are automatically available for use on the FirePass
controller, once the certificate had been generated and saved. Self-signed
certificates do not require installation.
Installing a server certificate
Install a signed server certificate on the FirePass controller before you allow
any user to log on. You can install any of the following types of certificates.
4-6
◆
A CA-signed certificate
If you install a CA-signed certificate, users should not see warning
messages from their browsers.
◆
A self-signed certificate
If you install a self-signed certificate, users might see warning messages
from their browsers unless you also install the self-signed certificate in
the browser’s certificate store on the user computers. Self-signed
certificates provide a limited level of security, but may be appropriate for
a pre-production environment, for example. For information on installing
a self-signed certificate on user browsers, see Installing a self-signed
certificate on client computers, on page 4-8.
◆
An intermediate certificate
If you are using a CA-signed intermediate certificate (also known as a
chaining certificate), install the intermediate certificate when you install
your signed certificate.
You need the private key associated with the certificate, as well as the
encryption password. If you are generating a CSR using the FirePass
controller, the key (new.key) is in the zipped file that you saved.
To install a server certificate
Security, and click Certificates.
The Certificates screen opens.
2. Click Install.
3. Open the certificate file using a text editor, and copy the entire
content of the file to the system clipboard.
If you are installing a self-signed certificate, this is the newcert.crt
file.
4. Paste the certificate text into the box labeled Paste the new
certificate in PEM format (for Apache + mod_ssl) here.
5. Open the private key file (newcert.key) in a text editor, and copy its
entire contents to your system clipboard.
6. Paste the private key text in the box labeled Paste the
corresponding cryptographic key in PEM format here.
7. In the Enter password here box, type the password you used when
you generated the CSR or self-signed certificate.
8. If you are using an intermediate certificate, paste that in the box
labeled Optionally, put your intermediate certificate chain here
(in the PEM format).
9. To complete the installation process, click the Go button.
Note
If the FirePass controller is configured with FIPS 140-encryption hardware,
the certificates and private keys are automatically stored in the FIPS
hardware. You do not need to perform any additional steps when installing
certificates on FirePass controllers equipped with FIPS hardware.
4-7
Chapter 4
The certificate is installed on the FirePass controller. You must now
configure a Web service to use the certificate. For details on configuring a
web service, see the online help for the Web Services tab of the Device
Management : Configuration : Network Configuration screen.
Associating an SSL server certificate with a web service
After you have installed the CA-signed or self-signed certificate, you
associate it with a web service.
To associate an SSL server certificate with a web service
3. In the Web Server Configuration table, click the Configure link for
a service that has SSL enabled.
The web services that are SSL-enabled contain the text SSL in the
Use SSL column of the table.
4. From the Certificate list, select your newly installed certificate and
key.
Note: You can view details about each certificate on the SSL Server
Certificate screen. To access the screen, from the Web Services
screen, click the Configure SSL Certificates link.
5. Click Update.
6. When you are finished, click the Finalize tab at the top of the page
and follow the instructions to put the changes into effect.
Installing a self-signed certificate on client computers
Client browsers do not recognize a self-signed certificate unless you install
it in the browser’s certificate store.
For example, when a user uses Internet Explorer to connect to a FirePass
controller that is using a self-signed certificate, the browser presents a
security alert that states that the certificate was issued by a company you
have not chosen to trust. To eliminate browser warning messages when
using a self-signed certificate, install the certificate on each client browser.
You can pre-install the certificate on each browser, or you can have each
user install the certificate when the browser displays a warning.
4-8
To install a self-signed certificate in the Internet Explorer
browser store
1. Connect to the FirePass controller using the URL associated with
the certificate.
A warning should appear.
2. Click the View Certificate button on the browser warning.
Most browsers display a warning that includes an option to view the
certificate.
3. Follow the prompts to install a certificate on the local browser.
For details on installing a signed certificate on other browsers, see the
browser’s documentation.
Updating installed server certificates
It is important to keep your server certificate valid by renewing it as
necessary, usually every year. You can use the FirePass controller
Administrative Console to update a CA-signed certificate that is going to
expire. The issuing CA warns you when a certificate that they signed is
about to expire, and you have the option of renewing it.
You can check the expiration date of the server certificate on the Device
SSL Certificates screen. For steps that show you how to access the SSL
Certificates screen, see the following procedure.
When you update the expiring certificate with the new certificate that the
CA sends, you will also need the private key that was created when you first
generated the CSR.
Note
If you update an existing CA-signed certificate, you do not need to
reconfigure the web services that are using that certificate. If you install a
new certificate, you must configure the web services to use that certificate.
To update an installed certificate
4. Click the Edit link in the right column of the certificate you want to
update.
The SSL Server Certificate screen opens, displaying details of the
certificate you selected.
4-9
Chapter 4
5. Copy the new CA-signed certificate, and paste it into the Paste the
new certificate in the PEM format (for Apache + mod_ssl) here
box.
6. Copy the private key (from newcert.key in the CertRequest.zip
file you saved when you generated the original CSR) and paste it in
the Paste the corresponding cryptographic key in PEM format
here box.
7. In the Enter password here box, type the password you created
when you generated the original CSR.
8. To update the CA-signed certificate, click the Go button.
Deleting installed certificates
You may need to delete an installed server certificate, for example, if you
have been using a self-signed certificate while waiting for a CA-signed
certificate to be issued, for example.
To delete an installed certificate
Note: If you have not installed any certificates, the SSL Server
Certificate screen only lists the default, internal certificate for
firepass.company.xyz. You cannot delete the default FirePass
certificate.
4. Check the box to the left of one or more certificates, and click the
Delete Selected button.
5. When you are finished, click the Finalize tab at the top of the
screen, and follow the instructions to put the changes into effect.
4 - 10
Installing and configuring client root certificates
You can use one of the following methods to install a client root certificate
and issue client certificates to users.
◆
If your company already has a PKI (Public Key Infrastructure) in place
for deploying client certificates to users, you can leverage it for use with
the FirePass controller. To do so, complete these tasks:
• Install on the FirePass controller the client root certificate only (no
private key) from your PKI server, along with a certificate revocation
list (CRL).
• Enable the client certificate two-factor authentication, passwordless
authentication, policy checking, or dynamic group mapping functions.
The FirePass controller then uses your existing PKI for deploying client
certificates to users.
◆
If your company does not have a PKI in place, then you can use the
FirePass controller’s built-in client certificate PKI capabilities. The
FirePass controller can generate a self-signed client root CA certificate,
generate and issue client certificates for users, and manage an internal
CRL. After generating a self-signed client root CA certificate, you can
generate and email or download PKCS#12 certificate packages for
individual users (on the Users : User Management screen, by editing
each user’s details). Then, you can install them on the client computers.
◆
If your company does not have a PKI in place, but has purchased or
generated an appropriate root CA certificate for issuing client
certificates, you can install it on the FirePass controller (including the
private key), and the FirePass controller can perform the same functions
as those described for the self-signed client root CA certificate.
Note
Use of smart card-based security solutions is fully supported with the
FirePass controller. With these solutions, a client certificate is made
available to the user’s web browser, and this certificate is then provided to
the FirePass controller as part of initial SSL session negotiation. You must
install the issuing client root certificate on the FirePass controller which
corresponds to the client certificate provided by the user’s smart card.
Using CRLs and OSCP
A certificate revocation list (CRL) is a list of revoked certificates. The CRL
describes the reason for the revoked status of the certificate, and provides
the certificate’s issue date and originator. The list also notes its next update.
When a user with a revoked client certificate attempts to log on to the
FirePass controller, the FirePass controller allows or denies access based on
the user’s CRL entry.
4 - 11
Chapter 4
A CRL is one of two common methods for maintaining valid,
certificate-based access to servers in a network. The other method is Online
Certificate Status Protocol (OCSP), and it has superseded CRL in some
instances. The main limitation of CRL is that the current state of the CRL
requires frequent updates. On the other hand, OCSP checks certificate status
in real time. You can read more about OCSP in Using OCSP to validate
client certificates, on page 4-13.
On the Device Management : Security : Certificates screen, you can
configure the FirePass controller to periodically retrieve CRLs from
specified URLs using HTTP or HTTPS. The FirePass controller provides
options for specifying the hour to retrieve CRL updates, as well as retrieval
frequency options ranging from every five minutes to every twelve months.
Note
You should not configure CRL updates if you are using the FirePass
controller to generate and issue client certificates to users (using either a
self-signed client root CA certificate, or a client root CA certificate from a
trusted CA). In this case the FirePass controller manages CRLs internally.
On the FirePass controller, you must specify CRLs in PEM format,
beginning with '-----BEGIN X509 CRL-----' and ending with '-----END
X509 CRL-----'.
4 - 12
Using OCSP to validate client certificates
The Online Certificate Status Protocol (OCSP) enables applications to
determine the revocation status of a certificate. OCSP provides more timely
revocation information than is possible using CRLs, and may also be used to
obtain additional status information. An OCSP client issues a status request
to an OCSP responder and suspends acceptance of that certificate until the
responder provides a response.
The FirePass controller supports OCSP validation of client certificates. For
a step-by-step procedure, see the online help for the Device Management :
Security : Certificates screen.
Note
Do not use Client Certificate OCSP if you are using the FirePass controller
to generate/issue client certificates to users (using either a self-signed client
root CA certificate, or a client root CA certificate issued by a trusted CA). In
this case, the FirePass controller is managing CRLs internally.
4 - 13
Chapter 4
4 - 14
5
• Introducing Network Access
• Configuring global Network Access settings
• Configuring Network Access resource group
settings
• Configuring Network Access master group settings
Introducing Network Access
The FirePass controller Network Access feature provides secure access to
corporate applications and data using a standard web browser. Using
network access, employees, partners, and customers can have access to
corporate resources when they are working from home and traveling outside
the company. Sending connections through the FirePass controller helps
keep them secure.
The FirePass controller’s Network Access feature provides users with the
functionality of a traditional IPsec VPN client. Unlike IPsec, however,
Network Access does not require any pre-installed software or configuration
on the remote user’s computer. It is also much more robust than IPsec VPN
against router and firewall incompatibilities. For more information about
client component downloads, see Downloading client components, on page
9-1.
Users connected through Network Access have equivalent functionality to
those users directly connected to the LAN. You can use pre-logon checks
and protected configurations to control access to Network Access. For
information about pre-logon checks, see Using pre-logon sequences, on
page 3-11, and for information about protected configurations, see Creating
Understanding Network Access features
FirePass controller enables automated, secure access for applications by
providing secure system-to-system or application-to-application
communication. Using Network Access, applications can automatically start
and stop network connections without requiring users to log on again. This
enables faster connections for end users while reducing client application
installation.
Network Access provides support in several areas.
◆
Full access from any client
Provides Windows, Macintosh, Linux, and PDA users with access to the
complete set of IP-based applications, network resources, and intranet
files available, as if they were working at their desktop in the office.
◆
Split tunneling of traffic
Provides control over exactly what traffic is sent over the Network
Access connection to the internal network and which is not. 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.
◆
Client integrity checking
Detects operating system and browser versions, antivirus and firewall
software, registry settings, and active processes and programs to ensure
the client configuration meets the organization’s security policy for
remote access.
5-1
Chapter 5
◆
Compression of transferred data
Utilizes GZIP compression to compress traffic before it is encrypted,
reducing the number of bytes transferred between the FirePass controller
and the client system, improving performance.
◆
Routing table monitoring
Monitors changes made in the client's IP routing table during a Network
Access connection. You can configure this feature to halt the connection
if the routing table changes, helping prevent possible information leaks.
◆
Session inactivity detection
Closes Network Access connections after a period of inactivity, which
you can configure. This feature helps prevent security breaches.
◆
Automatic applications start
Starts a client application automatically after establishing the Network
Access connection. This feature simplifies user access to specific
applications or sites.
◆
Automatic logon support
Opens configured connections and completes configured drive mappings
without requiring user intervention.
◆
Automatic drive mapping
Connects the user to a specific drive on the intranet. This feature
simplifies user access to files.
◆
Resource protection
Controls access to a network resource using configured rules, based on
the type of device being used for remote access. This feature helps secure
connections from unauthorized sources.
◆
Protection definitions
Collects data about a client machine and compares it with a set of safety
measures and protection criteria to mitigate the risk of unauthorized
access, information leaks, loggers, and virus attacks. You can name the
collection and assign it to protect various resources.
◆
Packet-based, group-based IP filters
Restricts groups of users to particular types of traffic, ports, and
addresses or ranges within the internal network. Also supports auditing
capabilities with packet-filter logging. The feature provides full
client-server application support without opening up the entire network
to each user.
◆
Minimized network router reconfiguration
Provides plug-and-play installation without reconfiguration of your local
network’s routing when Network Address Port Translation (NAPT) is
used. For more information about NAPT, see Table 5.1, in Configuring
global Network Access settings, on page 5-6.
◆
Flexible IP address assignment
• Static IP addresses
Assigns users IP addresses that do not change.
5-2
• IP address using RADIUS
At time of authentication, retrieves IP addresses from an external
RADIUS server using RADIUS attribute 8 (Framed-IP-Address).
• IP addresses from a pool
Assigns IP addresses dynamically from an internally configured pool
of addresses.
Understanding FirePass controller Network Access
The FirePass controller’s Network Access feature implements a
point-to-point network connection over SSL. This is a secure solution that
works well with firewalls and proxy servers. Network Access gives remote
users access to all applications and network resources. It uses standard
HTTPS protocol and works through proxy servers.
Comparing connections in Network Access and App Tunnels
While the FirePass controller’s Application Access App Tunnels features
provides remote users with access to particular applications on a specific
server and port, Network Access can provide access to all applications and
network resources that you configure.
You can use endpoint security checks, protected configurations, recurring
policy checks, split tunneling, and IP filtering to help secure against
unauthorized client access, and restrict resources available over the Network
Access connection.
Understanding how Network Access works
Network Access global settings specify IP address pools that the FirePass
controller uses to assign IP addresses to a client computer’s point-to-point
protocol (PPP) adapter. When the end user opens the address of the FirePass
controller in their web browser, the browser opens an SSL connection to the
FirePass controller. The user can then log on to the FirePass controller. You
can see a visual representation of how Network Access works in Figure 5.1,
following.
5-3
Chapter 5
Figure 5.1 Illustration of Network Access process
Using client applications with Network Access
The applications that users run during Network Access connections are the
same ones they run in their daily work. For example, if Outlook is their
email application and Windows Explorer provides file browsing, then these
are the applications they use for Network Access connections as well. This
makes Network Access connections ideal for corporate laptop use or use
with known systems, such as an employee’s home computer. Using
Network Access, users can leverage knowledge of familiar applications, and
do not have to learn a different application.
This differs from the FirePass controller Portal Access configurations,
which would run Outlook Web Access instead of Outlook, and would use
FirePass controller’s Windows Files connections instead of the Windows
Explorer interface. For more information about the Portal Access feature,
see Introducing Portal Access, on page 7-1.
When users click a Network Access link on the webtop, the FirePass
controller downloads, installs, and runs ActiveX controls or Java plug-ins on
the client computer, which starts the Network Access connection. Network
5-4
Access uses a Java-based installer when configuration on the client web
browser prevents the automatic download and install of controls or plug-ins.
The Java installer downloads and installs the necessary controls or plug-ins.
Note
The Windows NT 4 client is no longer supported by the FirePass controller.
Once the FirePass controller-to-client connection is established, the client
uses an automatically configured virtual PPP adapter to communicate with
the FirePass controller. Traffic is sent from the client’s virtual PPP adapter
over the SSL-secured Network Access connection to the FirePass controller.
The FirePass controller routes the client traffic onto the internal network.
You configure whether all client traffic or only traffic designated for
specific subnets is sent over the Network Access connection. You can see a
visual representation of how Network Access works in Figure 5.1, on page
5-4.
5-5
Chapter 5
Configuring global Network Access settings
In order to make Network Access available to remote users, you need to
configure the following settings.
• Global settings
Global settings apply to all Network Access users. For more information,
see this section.
• Resource settings
Resource settings apply to specific resource groups. For more
information, see Configuring Network Access resource group settings, on
page 5-19.
• Master group settings
Master group settings apply to associated master groups. For more
information, see Configuring Network Access master group settings, on
page 5-36.
You can configure Network Access using NAPT, or as a virtual subnet.
If you choose to use NAPT, communication between the FirePass controller
and internal servers on your network uses the FirePass controller interface
IP address. If you do not use NAPT, then the FirePass controller uses an IP
address from the pool configured for Network Access to communicate
between the FirePass controller and internal network servers.
Table 5.1, following, briefly shows the trade-off criteria for each method.
Criterion
Virtual subnet
NAPT
Requires one or more
subnets from the corporate
network space
FirePass controller is
the gateway for a
collection of virtual
subnets
Single FirePass IP
address
Requires addition of routes
to the virtual subnets in the
corporate routing
infrastructure
Yes
No
Supports Microsoft
Networking
Yes
No
Works with most client
server applications
Yes
Yes
Works with more demanding
networking applications, for
example, applications that
use IP broadcast packets for
their functionality
Yes
No
Table 5.1 Comparison of virtual subnet and NAPT
5-6
◆
NAPT
If you use NAPT, all packets forwarded into the LAN appear to have a
FirePass controller interface as their source IP address. Most
client-server applications work with NAPT configurations. The
advantage of NAPT is that it requires no changes to the LAN, whereas
using virtual subnets does. To use virtual subnets, you must configure
your internal routers to route the virtual subnet address pool back to the
controller; the FirePass controller does not change the IP address to its
interface IP address.
◆
Virtual subnet
For the most demanding networked applications, and to fully support
Microsoft Networking, you can instead configure a virtual subnet, and
configure an address pool for the FirePass controller to use when
assigning the source IP address in forwarded packets. In this case, you
must also configure your network infrastructure, including routers and
firewalls, to recognize this new subnet and to route the traffic. The router
must know that traffic with IP addresses from the associated address pool
should be routed to the FirePass controller. To prevent routing problems,
ensure that the Network Access address pool does not contain the
FirePass controller’s own IP address. For more information about
configuring routing without NAPT, see Understanding routing,
following.
5-7
Chapter 5
Figure 5.2, following, illustrates the differences between configuring virtual
subnets and configuring using NAPT.
Figure 5.2 Sample server addresses for virtual subnet configuration compared with NAPT enabled
Both with and without NAPT, the FirePass controller uses the IP address
pools to issue addresses to the remote client machines.
You can enable NAPT on the Network Access : Global Settings screen.
You also use the Network Access global settings screen to configure IP
address pools that the FirePass controller assigns to the client. You can
configure these settings in IP Address and Mask, by specifying the network
to be used for Network Access client addresses. The FirePass controller then
assigns client an address in this range.
Important
Make sure that the IP address of the FirePass controller itself does not fall
within the subnets you specify on the Network Access : Global Settings
screen.
5-8
Understanding routing
When incorporating the Firepass controller into your network, if you do not
use NAPT, you must make some routing changes to support Network
Access clients. Routing changes are required because existing hosts, routers,
or firewalls need to know how to route packets to the virtual subnet that the
Network Access connections use. If users establish a Network Access
connection, but then cannot communicate with systems on your internal
network, the most common solution is to add the needed routing
configuration.
The specific routing configuration changes you must make depend on the
way you deploy the FirePass controller in your network, typically in one of
the following ways:
• FirePass controller interface connected to the internal LAN
• FirePass controller placed in a separate network from the LAN
For more information on configuring group-based routing for master groups,
see the online help for the link to the routing table on the Users : Groups :
Master Groups screen.
FirePass controller connected to the internal LAN
In the most common deployment scenario, you connect one interface of the
FirePass controller to your internal, corporate LAN. (This interface might or
might not be the only FirePass controller interface used). The hosts on the
internal LAN have a default gateway that is not the IP address of the
FirePass controller’s LAN interface. When a Network Access client (which
has an IP address in the virtual subnet) sends packets to an internal LAN
host, the internal host routes its response packets through the default
gateway, rather than through the FirePass controller. Thus, the packets never
reach the Network Access client on the virtual subnet.
For this deployment scenario, you can use the following solutions.
◆
Use NAPT
You can configure NAPT on the Network Access : Global Settings
screen. NAPT changes (translates) the source IP address of each packet
from the Network Access client to the IP address of the FirePass
controller’s internal LAN interface. As a result, internal hosts send their
response packets to the FirePass controller, not the default gateway. The
FirePass controller then re-translates the IP addresses as needed and
passes the packets back to the Network Access client. For more
information, including reasons why you might not want to use NAPT,
see Table 5.1, on page 5-6.
◆
Add a static route to the virtual subnet in routing tables of the LAN
systems
Configure a static route to the virtual subnet in the routing table of each
host on the internal LAN that communicates with Network Access
clients. This allows the hosts to route packets to the virtual subnet
through the FirePass controller’s interface on the internal LAN. The
5-9
Chapter 5
static route uses as the destination network, the value configured in the IP
Address column on the Network Access : Global Settings screen. The
gateway for the route is the IP address of the FirePass controller interface
on the internal LAN. You should add a route for each virtual subnet you
configure in the IP Address column under Network Access Settings.
Refer to your documentation for the host operating system for
information on commands (such as the route command) that add routes
to the routing table.
FirePass controller placed in a separate network from the LAN
In the second deployment scenario, you do not connect the FirePass
controller to the internal LAN. Rather, it exists in an independent network,
such as a DMZ subnet. If no routes to the virtual subnet exist on the routers
or firewalls that separate the internal LAN from that independent network,
packets from hosts on the internal LAN cannot reach the Network Access
clients.
For this deployment scenario, you can use the following solutions.
◆
Use NAPT
Use NAPT, as described in FirePass controller connected to the internal
LAN, preceding. If this does not solve the problem, you may need to
employ the following solution, either as an alternative, or in addition to
NAPT. For more information, including reasons why you might not want
to use NAPT, see Table 5.1, on page 5-6.
◆
Add a static route to the virtual subnet in routing tables of routers and
firewalls
Configure a static route to the virtual subnet in the routing table of each
router or firewall that exists in the path between the FirePass controller
and the target hosts on the LAN or other networks. The static route uses
as the destination network, the value configured in the IP Address
column on the Network Access : Global Settings screen. The gateway for
the route is the FirePass interface. Refer to your documentation for the
router or firewall for information on commands to add routes to a routing
table.
Configuring global packet filter rules
You can specify global packet filters to apply to Network Access traffic.
When you check the Use packet filter to access LAN option on the
Network Access : Global Settings screen, you can specify a set of common
rules that the Network Access applies to all Network Access client traffic
that comes into the FirePass controller as well as the client’s outgoing
traffic. Network Access activates these rules on service startup, and applies
changes when you click the adjacent Apply these rules now button.
Without packet filtering enabled, Network Access accepts all packets. When
you enable packet filtering, Network Access creates a default Drop ALL
rule that runs after all other global rules run. Network Access also creates a
Drop ALL rule that runs at the end of each group’s rules. Once you enable
5 - 10
packet filtering, you must add filtering rules to allow the traffic you want to
pass through. If you want to accept all packets not otherwise filtered out,
you should precede this default rule with an Accept ALL rule. To create an
accept-all rule, select ALL from the Proto box and Accept from the Action
box.
Note
You cannot delete the default rules.
When configuring global rules, you typically select the Continue action in
the global rule and then specify more granular packet filtering under the IP
Group Filter tab on the Network Access : Resources screen. For
information about configuring IP group filters, see Understanding IP Group
Filters options, on page 5-25.
Network Access checks each packet coming from the user’s Network
Access client against the common, global rules. The packet might be
explicitly accepted, dropped, or rejected. However, if the packet matches
settings from a global rule with a Continue action, the packet is also
evaluated against the more granular, resource group-level rules. The group’s
rules must then explicitly accept, reject, or drop the packet.
Network Access applies the global rules, then the group rules, from top to
bottom. At each stage, Network Access uses the first-found matching rule to
process the packet. For more information about group-level rules, see
Understanding IP Group Filters options, on page 5-25.
While working in the Packet Filter Rules area on the Global Settings screen,
when you click the Add New Rule link, the screen presents options for
specifying several setting.
◆
Rulename
Contains the name for global packet rule.
◆
Protocol
Contains the options TCP, UDP, ICMP or All, that represent the
protocol Network Access uses to process the packet.
◆
Dst Port
Represents the port number or port range that the client uses as a
destination port while accessing various resources on the internal LAN.
You specify a port number or range of port numbers using the following
format
first_port_number:last_port_number, for example, 1:65535, which
means any port. An empty field also means any port. Network Access
does not use Dst Port for processing packets over ICMP.
◆
Dst Address/Mask
Represents the destination IP address used by the client when it tries to
access various resources on the internal LAN. For example, 192.168.2.1,
or subnet/mask, for example 192.168.2.0/24 or
192.168.2.0/255.255.255.0. You can specify 0/0 to mean any IP address.
5 - 11
Chapter 5
◆
Action
• Accept: Ends filtering and forwards the packet to its destination.
• Continue: Passes the packet to the resource group rules.
• Drop: Does not pass the packet, and does not notify the sender.
• Reject: Drops the packet and notifies the sender. Depending on the
specific reject action type, Network Access sends the sender the
ICMP message code you select, or a TCP packet with the RST bit set.
◆
Src Address/Mask
Represents the source address and mask used by the client while
accessing resources on the internal LAN. You can use Src
Address/Mask to configure packet rules for a specific IP address pool.
◆
Log all matches
Writes to the system log all of the packets that match conditions in any
global packet rule. You can view log entries on the Reports : System
Logs screen by selecting Packet Filter from the Source list. For more
information about system logs, see Using the System Logs report, on
page 10-18,
Using overlapping IP address pools
You can use the same IP address in more than one IP address pool. IP
address pooling is useful in an ISP environment, where the same FirePass
controller hosts multiple managed customers, who often need to use the
same IP address space.
Note
The FirePass controller also supports overlapped IP address assignment
through an external RADIUS server or by defining static mapping on the
FirePass controller. The configuration steps are same as those described
here for IP address pools.
Using overlapping IP address pools: special considerations
To use overlapping IP address pools, you must route to different VLANs the
traffic for resource groups that use overlapping IP address pools. You can
not assign the same VLAN to two resource groups that use overlapping IP
pools. Because routing is configured on a per-group basis, this means that
you cannot use overlapping IP pools for multiple resource groups in a single
master groups. In other words, each resource group using overlapping IP
address pools must be associated with a different master group.
5 - 12
Configuring overlapping IP address pools
Configuration of overlapping IP address pools requires very careful
planning of the VLANs and routing configuration on the FirePass controller.
This process involves multiple tasks:
• Define overlapping IP pools
For more information, see Defining the IP pools, following.
• Define VLAN interfaces
For more information, see Configuring VLAN interfaces, on page 5-14.
• Define routing tables and VLAN routes
For more information, see Configuring routing tables and VLAN routes,
on page 5-15.
• Define master groups and associate routing tables to resource groups
For more information, see Configuring master groups and associating
routing tables to master groups, on page 5-15.
• Define resource groups and associate overlapping IP pools to resource
groups
For more information, see Configuring resource groups and associating
IP pools, on page 5-16.
• Associate master groups and resource groups
For more information, see Associating master groups with resource
groups, on page 5-17.
• Configure routing rules
For more information, see Configuring routing rules, on page 5-17.
This section presents the process, with a step-by-step explanation of a
sample configuration. This example uses the following elements.
• Two master groups: M1 and M2
• Two defined resource groups: R1 and R2
• Two overlapping IP address pools: P1 and P2
• Two routing tables: TABLE1 and TABLE2
• Two VLANS: VLAN1 and VLAN2
• Two defined routing rules, one for TABLE1 and one for TABLE2
The following sections describe how to define each element. Once you are
finished, when users log on to use R1 and R2, the FirePass controller assigns
them IP addresses from P1 and P2.
Note
Because the defined ranges for P1 and P2 are overlapping, it is possible for
more than one user to have assigned the same IP address, though never in
the same resource group. Overlapping IP address pooling provides the
option of having more than one user with the same IP address.
5 - 13
Chapter 5
Defining the IP pools
The first step is to specify pools with overlapping IP addresses.
To set up overlapping IP address pools
1. In the navigation pane, click Network Access, and click Global
Settings.
The Global Settings screen opens.
2. Check Allow overlapping IP addresses in different address
pools.
3. In the Add new IP Address Pool section, type P1 in the Name box.
4. In the IP Address box, type 10.0.0.0.
5. In the Mask box, type 255.255.0.0.
6. Click the Add button.
7. To add the second address pool, in the Add new IP Address Pool
section, type P2 in the Name box.
8. In the IP Address box, type 10.0.0.0.
9. In the Mask box, type 255.255.255.0.
Configuring VLAN interfaces
The next step is to define two VLANs.
To define VLAN interfaces
1. Click Device Management, expand Configuration, and click
Network Configuration.
The Network Configuration screen opens with the IP Config tab
active.
2. Click the VLAN tab.
The VLAN screen opens.
3. In the Add New VLAN section, in the Name box, type VLAN1.
4. In the Tag box, type the number to be used throughout the LAN in
the packet header, to identify this VLAN. The valid tag range is
from 1 to 4094.
5. From the Interface list, select the FirePass controller physical
interface used by this VLAN.
6. Repeat these steps for VLAN2.
5 - 14
Configuring routing tables and VLAN routes
After you have defined overlapping IP address pools and VLANs, you must
configure routing tables and VLAN routes.
To configure routing tables and VLAN routes
Configuration, click Network Configuration, and then click the
Routing tab.
The Routing screen opens in light mode.
2. Follow these steps to add a routing table.
a) Click the Switch to advanced mode [>>] link.
The Routing screen opens in advanced mode.
b) Scroll down to the Add new routing table section at the bottom of
the screen.
c) In the Name box, type TABLE1.
d) In the Number box, type a number between 1 and 252, inclusive,
that is not used by another routing table.
e) Click the Add New button.
The Routing screen refreshes in light mode.
3. Repeat step 2, using TABLE2 for the name.
4. Click the Switch to advanced mode [>>] link.
The Routing screen refreshes in advanced mode.
5. In the Add Single route section, add to TABLE1 a route that directs
all outgoing traffic to the VLAN1 interface.
6. Repeat the previous step to create a route in TABLE2 to VLAN2.
7. Click the Finalize tab to activate the new routing table in the
networking configuration and restart the FirePass controller.
Configuring master groups and associating routing tables to master groups
After you have created the routing tables and VLAN routes, you must create
two master groups and associate the routing tables to each one.
To define master groups and associate them with routing
tables
Master Groups.
The Create new group screen opens.
3. In the New group name box, type M1.
5 - 15
Chapter 5
4. From the Routing Table list, select TABLE1 from the list of
routing tables.
5. Click Create.
The Master Groups screen opens, with the General tab selected.
6. Click the Back to Users : Groups : Master Groups page link in
the upper right of the screen.
The Master Groups screen opens, showing the M1 master group. In
addition, TABLE1 appears in the Routing Table column for the M1
master group.
7. Repeat these steps to create the M2 master group and associate it
with TABLE2.
Configuring resource groups and associating IP pools
After you have created two master groups and associated the routing tables
to each one, you must create two resource groups and associate them with
the corresponding IP pools.
To configure resource groups and associate IP pools
Resource Groups.
The Resource Groups screen opens.
The Create new group screen opens.
3. In the New group name box, type R1.
4. Click Create.
The Resource Groups screen opens, showing the R1 resource group.
5. In the Network Access column, click the Edit link for the R1
resource group.
The Network Access screen opens for the R1 resource group, with
the Client Settings tab selected.
6. From the list in the IP address assignment section, select
P1 : 10.0.0.0/255.255.0.0 as the IP address pool.
7. Configure other settings for Network Access favorites.
For more information on configuring Network Access, see
Configuring Network Access resource group settings, on page 5-19.
8. Repeat these steps to associate resource group R2 with IP pool
P2 : 10.0.0.0/255.255.0.0.
5 - 16
Associating master groups with resource groups
After you have created two resource groups and associated them with the IP
pools, you must associate the master groups with the resource groups.
Master Groups.
2. In the Resource Groups column, click the dynamic only link.
The Master Groups screen for the M1 master group opens, with the
Resource Groups tab selected.
3. In the Available list, select R1.
The screen refreshes to show R1 in the Selected list.
5. Repeat these steps to add R2 to the list of resource groups available
to M2.
Configuring routing rules
The final step is to direct all the incoming traffic on VLAN1 to TABLE1
and traffic on VLAN2 to TABLE2, so that it can be properly routed and
given back to the appropriate resource group M1 and M2 (and subsequently
to R1 and R2). This is done by adding a routing rule in the main routing
table of the FirePass controller.
To configure routing rules.
This is the most important step for configuring overlapping IP address
pools. In Configuring routing tables and VLAN routes, on page 5-15, you
added default routes in TABLE1 and TABLE2 to direct the traffic to
VLAN1 and VLAN2. The FirePass controller routes the traffic for M1
according to the routes in TABLE1, and traffic for M2 according to the
routes in TABLE2.
The Network Configuration screen opens, with the IP Config tab
selected.
2. Click the Routing tab.
3. In the Add new rule section, type following values in the associated
fields:
From: 0.0.0.0/0
To: <leave this field blank>
Interface: VLAN1
Table: TABLE1
5 - 17
Chapter 5
4. Similarly, for associating VLAN2 to TABLE2 (and consequently to
R2), type the following settings:
From: 0.0.0.0/0
To: <leave this field blank>
Interface: VLAN2
Table: TABLE2
Important
If you decide to disable overlapping IP address pools, check to make sure
that you redefine any overlapping IP address pools or statically defined
mappings. The FirePass controller does not automatically redefine address
pools. The presence of overlapping IP addresses along with a disabled
overlapping address pools setting can cause connectivity problems.
Configuring bitrate evaluator parameters
You can configure options on the Global Settings screen in Network Access
to update a session only when the bitrate exceeds a specified threshold. You
can use this option to distinguish between real application traffic, and
keepalive requests from application clients. Network Access disregards
keepalive requests when enforcing session timeouts.
You can specify bitrate settings in the Bitrate Evaluator Parameters area of
the Network Access : Global Settings screen.
Setting a value in the Timing window box defines, in seconds, the period
that the evaluation should use to average the bitrate. Setting a value in the
Bitrate threshold (Bytes/sec) box defines, in bytes per second, the criterion
for updating the session statistics. Network Access updates the session if the
averaged bitrate exceeds the threshold. If you set the bitrate threshold to
zero, Network Access does not apply session timeouts.
You can determine how to set bitrate value by examining regular network
usage, depending on what applications are in use and how much data those
applications generate. Typical values are 50 bytes/sec or higher. The
FirePass controller activates timing and threshold rules on service startup,
and applies changes when you click the adjacent Apply these rules now
button.
5 - 18
Configuring Network Access resource group settings
After configuring global Network Access settings, you need to configure
resource group settings. These are also called favorites. You specify
favorites on the Network Access : Resources screen.
You can create favorites that cover the following areas.
• Client Settings
For a description of these options, see Understanding Client Settings
options, following.
• DNS
For a description of these options, see Understanding DNS options, on
page 5-22.
• Hosts
For a description of these options, see Understanding Hosts options, on
page 5-22.
• Drive Mappings
For a description of these options, see Understanding Drive Mappings
options, on page 5-23.
• Launch Application
For a description of these options, see Understanding Launch
Application options, on page 5-23.
• IP Group Filters
For a description of these options, see Understanding IP Group Filters
• Policy Checks
For a description of these options, see Understanding Policy Checks
• Customization
For a description of these options, see Understanding Customization
Note
The FirePass controller does not perform proxy operations on any site in
the microsoft.com domain. In addition, you cannot configure as a favorite
any site in the microsoft.com domain.
Understanding Client Settings options
You can use options on the Client Settings tab to configure favorite name,
split tunneling operation, proxy settings for the client, and IP address
assignment. The Client Settings screen presents options for specifying
various settings.
5 - 19
Chapter 5
◆
Connection name
Contains the name the end user sees in the Network Access area of the
webtop. If the box is empty, the link to Network Access coming from a
given Resource group does not appear in the list.
◆
Use split tunneling for traffic
Directs through the Network Access tunnel all network traffic that is not
destined for the LAN, specifically, the address specified in the LAN
address space box. A tunnel is a secure connection between computers
or networks over a public network. When you configure split tunneling,
the FirePass controller directs all other traffic out of the local network
connection. You can configure both of the following options when you
check the Use split tunneling for traffic check box.
• LAN address space
Provides a list of addresses or address/mask pairs describing the target
LAN. When using split tunneling, only the traffic to these addresses
and network segments goes through the tunnel configured for
Network Access. You can use the following format to configure this
option:
10.0.0.0/255.0.0.0
10.0.0.0/8
10.0.0.0/8,10.1.0.0/8
You can use spaces, commas, or semi-colons to separate list items.
You can also use a session variable to specify a LAN address space.
When you specify a session variable, the system resolves the address
by substituting the value received during user authentication. For
example, you can have the system substitute the value from the user’s
LDAP attribute SubnetAddress when you specify the session variable
%session.ldap.auth.SubnetAddress% in LAN address space.
• DNS address space
Provides a list of names describing the target LAN DNS addresses.
You can use spaces, commas, or semi-colons to separate list items.
For example, enter *.sales.siterequest.com
*.engineering.siterequest.com to help the browser resolve which
DNS server to use for resolving a host name. For example, Internet
Explorer uses the VPN DNS server settings for hosts in the DNS
address space, and the local client DNS for others.
5 - 20
◆
Force all traffic except local subnet traffic through tunnel
Routes all traffic (except traffic to the local subnet), through the tunnel.
Use this option if you expect your users to connect from well-known
networks, such as their home computers, and you want to allow them
access to local resources, such as their printers at home, while using
Network Access.
◆
Force all traffic through tunnel
Routes all traffic (including traffic to the local subnet) through the
tunnel. In this case, there is no local subnet. Users cannot access local
resources, such as their printers at home, until they disconnect from
Network Access.
◆
Client proxy settings
Directs Network Access clients to work through the specified proxy
server on the remote network. This option requires the client computer to
have Internet Explorer 5.0 or later installed. The following options
appear when you check Client proxy settings.
• Autoconfig script
Contains the URL of the proxy-autoconfiguration script.
• Address, Port
Contains the address and port number of the proxy server you want
Network Access clients to use to connect to the Internet.
• Bypass proxy for local addresses
Indicates whether you want to use the proxy server for all local
(intranet) addresses.
• Proxy exclusion list
Contains the Web addresses that do not need to be accessed through
the proxy server. You can use wild card characters to match domain
and host names or addresses. For example, you could specify
www.*.com, 128.*, 240.*, *., mygroup.*, *x*, and so on. You can
use spaces, commas, or semi-colons to separate list items.
◆
Use gzip compression
Compresses all traffic between the Network Access client and the
FirePass controller, using the GZip method.
◆
Autolaunch based on endpoint protection
Automatically opens a Network Access connection after the FirePass
controller authenticates the user, providing that the user passes any
endpoint security requirements. When you check this option, you can
select Any endpoint configuration, which always launches Network
Access connection automatically, or an existing protected configuration,
whose requirements vary. For example, if you have a protected
configuration named ClientCert that requires a valid client certificate
before autolaunching, you can select that protected configuration here.
For more information about protected configurations, see Creating
◆
IP address assignment
Contains options for specifying how IP addresses are assigned. You must
select at least one of the following options.
• Use static IP address per user from mapping table (1st priority):
Assigns IP addresses on a per-user basis. You must configure the
static IP address to be assigned to the user in the User to IP address
mapping table. When you check this option, a new section appears,
Configure User To IP Address Mapping Table, containing Logon and
IP Address fields you can specify to create user-to-IP address maps.
• Retrieve IP address from an external RADIUS server (2nd
priority): Retrieves IP addresses from external Radius Server using
RADIUS attribute 8 (Framed-IP-Address). The FirePass controller
retrieves the IP address at the time of authentication. This option
5 - 21
Chapter 5
requires the use of RADIUS as the authentication method for any
master group associated with this resource. This option is not
supported in clustered environments.
• Assign IP address dynamically using IP address pool (lowest
priority: Enabled by Default): Assigns IP addresses dynamically
from an internally configured pool of addresses.When you check this
option, a new section appears, Select IP Address Pool, containing a
list of the IP address pools defined on the Network Access : Global
Settings screen.
Understanding DNS options
Select the DNS tab when you want to set parameters for DNS
Configuration. The screen presents options for specifying the following
settings:
◆
Name Servers
Represents the IP addresses of the DNS server that Network Access
assigns to the remote user. These should represent DNS server or servers
that the internal company network uses.
◆
WINS Servers
Represents the IP addresses of the WINS server to be conveyed to the
remote access point. These are needed for Microsoft Networking to
function fully. For fully functioning Microsoft network share browsing,
you should configure the FirePass controller to use a virtual subnet and
disable NAPT. For more information, see Configuring global Network
Access settings, on page 5-6.
◆
Default domain suffix
Represents the DNS suffix to use on the client computer. If this field is
not specified, Network Access uses the first suffix from the name servers
configured on the Device Management : Configuration : Network
Configuration screen on the DNS tab.
Understanding Hosts options
Pick the Hosts tab to set parameters for static host names. The screen
presents options for adding, editing, and deleting static host names. With
static hosts, you can configure a list of static hosts for the Network Access
client to use. The static hosts you configure modify a client computer’s local
hosts table and override the configured DNS server, so you should use them
only when you need to augment or override the existing DNS.
Important
For this file-change operation, users on Windows platforms must have local
administrative rights to modify the hosts file during the connection, or the
administrator must change the attributes of the hosts file to allow
nonadministrative modification.
5 - 22
Understanding Drive Mappings options
Use the Drive Mappings tab to set options for specifying the name, the UNC
path to the network share, and the preferred letter to use for mapping. If the
drive letter is in use, the system uses another one connection time.
Using Drive Mappings options, you can specify network shares to be
mapped automatically on the client computer whenever a user logs on.
Because the FirePass controller does not verify the accuracy of a path, you
should make sure the path is correct.
Troubleshooting drive mapping failures
After establishing a Network Access connection, Windows needs a varying
length of time (depending on network speed and other factors, usually about
one minute) before it can start using WINS for NetBIOS name resolution.
During this time, the drive-mapping operation can fail and provide the
message: The network resource type is not correct. If the UNC path is
configured with the NetBIOS name, you may get the message: The
network path was not found.
If drive mapping fails, try the following corrections:
• Use an IP addresses instead of NetBIOS names
For example, specify \\192.168.191.1\share instead of \\server\share.
• Use fully qualified DNS names
For example, specify \\server.domain.com\share instead of
\\server\share.
• Check the default domain suffix
Make sure that the FirePass controller is configured with the proper DNS
suffixes.
• Try the operation again
Advise users to retry mapping. Subsequent mapping attempts usually
succeed after a 30 to 40-second delay. To retry, have the user click the
Relaunch button in the user's Network Access popup window.
• Check the Windows version
Some older Windows systems (mostly Windows 95 systems) cannot use
IP addresses in Windows Networking.
Understanding Launch Application options
Use the Launch Applications tab to set options for configuring Network
Access to start client-side applications. This feature is particularly useful for
Network Access clients who connect to application servers for which they
have a client-side component on their computers. For example, it is common
to configure Network Access connections for directly accessing an internal
Exchange server. In this case, when the client makes a Network Access
connection, it automatically starts an Outlook client on the connecting
computer. This makes access easier for the end user.
5 - 23
Chapter 5
You can let the end-user control whether applications start, by checking the
Display message box before launching applications check box. This is
especially useful for slower systems, or if you want to prevent the attempt to
run certain applications when the system has insufficient memory to run
them. You can specify different applications for Windows, Macintosh, and
UNIX remote systems.
Specifying application paths and parameters
On the Launch Applications screen, to configure applications to launch
automatically, specify the complete path in the App Path box and any
application parameters in the Parameters box, and select the target
operating system from the OS list. The following examples contain strings
for the App Path and Parameters boxes.
Example: Starts Internet Explorer pointed at an internal web server.
• App Path:
iexplore http://internal_application.siterequest.com
Example: Starts the Microsoft Terminal Server client against an internal
terminal server.
• App Path:
%SystemRoot%\System32\mstsc.exe
• Parameters:
v:internalterminalserver.siterequest.com /f
You can specify environment variables in either App Path or Parameters
using the following syntax: %envvarname%. The Network Access control
resolves the value at runtime to the environment variable on the remote
system.
Running domain scripts
For certain client systems, you can automatically run domain logon scripts
after establishing a Network Access connection. The client systems must
meet the following requirements:
• The system is running Microsoft Windows 2000, Windows XP, or later.
• The remote user’s computer is a member of the specified domain.
• The user is logged on to Windows using domain credentials cached on
the local client computer.
The following example illustrates how to start a domain logon script:
• App Path
logon
• Parameters
\\domain_controller_ip_address %username%
or
domain_name %username%
The domain_name entry represents the target domain name, and the
domain_controller_ip_address entry represents the IP address of the
domain controller.
5 - 24
Understanding IP Group Filters options
You can specify resource group-specific packet filters to apply to Network
Access traffic only on the IP Group Filters tab.
Note
To make the IP Group Filters tab available, you must check the Use packet
filter to access LAN box on the Network Access : Global Settings screen.
For information about the global packet filtering options, see Configuring
global Network Access settings, on page 5-6.
Network Access applies the global rules, then the resource group rules, from
top to bottom, as they appear in the list of configured rules. At each stage,
Network Access uses the first-found matching mechanism to process the
packet.
Network Access checks each packet coming from the user’s Network
Access client against the global rules first. There, the packet is accepted,
dropped, or rejected, depending on which rule it matches. However, if the
packet matches settings from a global rule with a Continue action, the
packet is also evaluated against the resource group-level rules that you
configure on the IP Group Filters tab.
Without packet filtering enabled, Network Access forwards all packets that
the global rules pass through. When you enable packet filtering on the
Network Access : Global Settings screen, Network Access defaults to a drop
policy. This means that unless you create a rule to explicitly let traffic in, it
is denied.
Note
The default drop rule runs after all other group-based rules, and you cannot
delete the default drop rule. If you want to allow traffic not otherwise
filtered out, you must precede this default rule with a rule that accepts
traffic.
Adding group-level packet filtering rules
To apply settings for a specific resource group, first select the group from
the Resource Group list at the top of the screen.
When you click the Add New Rule link, the screen refreshes to present
options for specifying the following settings:
◆
Rule Name
Contains the name for group packet rule.
◆
Proto
Contains the options TCP, UDP, ICMP or All, that represent the
protocol Network Access uses to process the packet.
◆
Port
Represents the port number or port range that the FirePass controller uses
to communicate with the client.
5 - 25
Chapter 5
You specify a port number or range of port numbers using the following
format:
first_port_number:last_port_number, for example, 0:65535, which
means any port. An empty field also means any port. Network Access
does not use Port for processing packets over ICMP.
◆
Address/Mask
Represents the destination address and mask for the packet filter rule, for
example, 192.168.2.1, or subnet/mask, for example 192.168.2.0/24 or
192.168.2.0/255.255.255.0. You can specify 0/0 to mean any address.
◆
Action
• Accept: Ends filtering and forwards the packet to its destination.
• Drop: Does not pass the packet, and does not notify the sender.
• Reject: Drops the packet and notifies the sender. Depending on the
specific reject action type, Network Access sends the sender the
ICMP message destination unreachable or a TCP packet with the
RST bit set.
◆
Log all matches
Writes to the system log all of the packets that match conditions in any
global packet rule. You can view log entries on the Reports : System
Logs screen by selecting Packet Filter from the Source list. For more
information about system logs, see Using the System Logs report, on
page 10-18,
Configuring policy-fallback rules
You can configure fallback policy rules to evaluate those users who fail any
checks configured on the Policy Checks tab. For information about Policy
Checks options, see Understanding Policy Checks options, following. You
can configure the fallback IP group filters the same way you configured the
primary IP group filters, described in Adding group-level packet filtering
rules, preceding.
To activate fallback rules, check the Enable policy fallback option on the
IP Group Filters screen. Enable policy fallback also applies to Policy
Checks options, described in the following section.
Understanding Policy Checks options
Use the Policy Checks tab to set parameters for client policy, policy checks,
personal firewalls and antivirus checks, and fallback settings. The FirePass
controller enforces these settings only for Network Access connections. You
can prevent changes to the network settings or routing settings on the client
computer while a connection through the Network Access client is active.
5 - 26
You can also require specific applications like virus-checking software to be
running on the client computers. You can prohibit other applications like
known Trojan horses from running on client computers.
Note
Policy checks are not supported on Macintosh, Linux, or PDA remote
clients.
Important
The policy checks that you configure here are completely independent of any
Endpoint Security checked configured on the Users : Endpoint Security
screens. These checks are simple, recurring checks run on the client for
Network Access only. You can use them in conjunction with any Endpoint
Security checks you have configured. For information about pre-logon
sequences, see Using pre-logon sequences, on page 3-11.
The screen presents options for specifying the following settings:
◆
Prohibit routing table changes during Network Access connection
Prevents modifications in the client’s IP routing table during an active
Network Access connection.
When you select this option, the FirePass controller terminates the
Network Access connection if there are any changes to the network or
routing on a client computer during the connection.
◆
Enable integrated IP filtering engine
This feature is only available when you select the Use split tunneling or
Force all traffic through tunnel option on the Client Settings screen,
available from the Client Settings tab on the Network Access : Resources
screen. This protects the FirePass controller and internal LAN from
outside traffic (that is, traffic generated by network devices on the
client’s LAN), and ensures that FirePass controller traffic is not leaking
into the client’s LAN.
The main goal is to prevent IP packets destined to or originating from the
LAN Address Space from being sent unencrypted to the user’s LAN. It
also prevents using a client device as a routing gateway between the
LAN and the FirePass controller.
◆
Processes to be present/absent
Represents a Boolean expression containing strings that specify
executable process names that must be present or absent on the client
system during an active Network Access connection. You can use the
following conventions to specify the string:
• Wildcard characters asterisk ( * ), which represents many characters,
and question mark ( ? ), which represents a single character
• The logical operators AND, OR, and NOT.
• The characters open parenthesis ( and close parenthesis )
5 - 27
Chapter 5
◆
Check system registry
Contains a Boolean expression that verifies certain keys and values in the
system registry database. When you specify the expression, use the
following syntax, including the quotation marks.
"key"."value" operator [data]
• "key" represents a path in the Windows registry.
• "value" represents the name of the value.
• operator represents one of the supported logical operators defined in
the conventions list, following.
• data represents the content to compare against,
• Open square bracket [ and close square bracket ] represent optional
values.
You can use the following conventions to specify the string:
• The operators ISPR (is present)
• Wildcard characters asterisk ( * ), which represents many characters,
and question mark ( ? ), which represents a single character
• The logical operators AND, OR, and NOT
• The characters open parenthesis ( and close parenthesis )
◆
Operating system service packs
Contains a Boolean expression that evaluates the list of installed service
packs and hotfixes. You should specify the operating system name (for
example, Win95, Win98, Win98SE, WinNT 4, Win2k, WinXP,
Win2003), service packs (for example, SP1 or SP2), and hotfixes (for
example, KB1234, Q1231312, Q3253).
The following example represents a complete string.
(Win2003 OR (WINXP AND SP2) OR (WIN2k AND SP4 AND
KB1234) ) AND NOT (WIN95 OR WIN98 OR WIN98SE OR
WINME)
You can check the Microsoft support site for the list of published
hotfixes for the target operating system.
◆
Internet Explorer service packs
Contains a Boolean expression that evaluates the list of installed service
packs and hotfixes for Internet Explorer. The string should be formatted
with the browser name (for example, IE5 or IE6), service packs (for
example, SP1 or SP2) and hotfixes (for example, KB326489).
The following example represents a complete string.
(IE5 OR IE6) AND NOT (IE3 OR IE4)
You can consult the Microsoft support site for the list of published
hotfixes for the target operating system.
◆
5 - 28
McAfee VirusScan
Contains the software products that should be running during the
Network Access session. You also can configure options to require
specific versions and last-update dates of the signature databases.
◆
Enable policy fallback
You can configure fallback policy rules to evaluate those users who fail
the first set of rules.You might want to allow certain clients access, but
restrict them to a subset of the network. You can configure the fallback
policies the same way you configured the primary policies, described
earlier in this section. Enable policy fallback also applies to IP Group
Filters options, described in Adding group-level packet filtering rules, on
page 5-25.
For examples and additional information, see the online help for Network
Access : Resources on the Policy Checks tab.
Understanding Customization options
You can use items on the Customization tab to customize the behavior and
appearance of the Network Access client for remote users. You can use the
customization configuration options to control what remote users see when
they connect or disconnect, how the Network Access client behaves if
Windows goes into power management mode, and what messages display in
the event of a connection error.
Configuring Customization options
Using options in the Customization section of the Customization tab, you
can configure how Network Access connections behave on the client
computer.
◆
Present the user with a message box after successfully connecting
Network Access client
Posts an alert to the end user upon establishing a Network Access
connection.
◆
Minimize window after successfully connecting Network Access
client
Minimizes the connection window upon establishing a Network Access
connection.
◆
Use Tray icon instead of Taskbar entry when minimized
Minimizes the connection window as an icon in the Windows system
tray. By default, when a user establishes a Network Access connection,
the FirePass controller displays a connection window to users notifying
them that they have successfully established a Network Access
connection. When you enable this feature, the system hides the window
and shows the connection as an icon in the Windows system tray at the
lower right of the Taskbar. Users can use the icon in the Windows system
tray to restore or maximize the connection window, or to terminate their
◆
Do not display tray icon for connection
Prevents display of the Network Access connection in the Windows
system tray.
5 - 29
Chapter 5
◆
Displayed bandwidth B/Sec
Reports the Network Access connection media speed to Windows. This
affects the speed shown in the connection status window on the client’s
computer. This value is also used by Windows 2000 and Windows XP to
determine the default TCP window size advertised for TCP connections
over the Network Access connection, and can in some cases affect TCP
performance over the connection. For a table of how the speed displays
and the impact on window size, see the online help for the Network
Access : Resources screen on the Customization tab.
Configuring Power Management options
Using options in the Power Management section of the Customization tab,
you can control Network Access client behavior in response to Windows
power-management operations on the client computer. You can select from
several settings.
◆
Do nothing. Ignore power management events
Indicates that Windows power management operations on a client
computer have no effect on FirePass system client functionality.
◆
Prevent Windows from entering standby/hibernate during
connection
Indicates that the FirePass system client responds to power-management
operations by keeping the computer from hibernating or switching to
standby mode.
◆
Terminate Network Access connection if Windows is entering
standby/hibernate
Indicates that the FirePass system client responds to power-management
operations by ending its Network Access connection.
Configuring Custom Messages options
Using options in the Custom Messages section of the Customization tab,
you can configure the text for policy check messages that display when
specific events occur.
5 - 30
◆
Connection Established
Displays the configured message when the FirePass controller makes a
Network Access connection with a client computer.
◆
Connection Established using Fallback Configuration
Displays the configured message when the FirePass controller makes a
Network Access connection using a fallback configuration.
◆
Disconnect due to Routing Table Changes
Displays the configured message when the FirePass controller terminates
a Network Access connection because a change was made to the remote
client’s routing table.
◆
Disconnect due to Configuration Error
Displays the configured message when the FirePass controller terminates
a Network Access connection because there was a configuration error.
◆
Check for Processes Failed
Displays the configured message when the check does not detect the
required process, or when it detects the presence of a forbidden process.
◆
Registry Check Failed
Displays the configured message when the registry check fails.
◆
System Patch Level Check Failed: Displays the configured message
when the system patch level check fails.
◆
Internet Explorer Patch Level Check Failed
Displays the configured message when the patch level check for Internet
Explorer fails.
◆
Personal Firewall/Antivirus Check Failed
Displays the configured message when the check for a personal firewall
or antivirus fails.
◆
Connection Name in Network Connections Folder
Displays the configured connection name used in the network
connections folder.
Configuring additional end-user customization options
You can configure additional end-user options to customize the end-user
experience for Network Access users. The Customize Client Components
screen contains the options. You can find the Customize Client Components
tab on the Device Management : Client Downloads : Windows (x86) screen.
Configuring FirePass controllers
The FirePass controller client component uses the FirePass Controllers List
area to determine the FirePass controllers available for connection. The
client component and Windows logon integration share these settings.
The client component connects to the FirePass controller using the HTTP
protocol and receives an HTTP 302 redirect message from the FirePass
controller. The client component then redirects the connection to that
FirePass controller. Every other connection is made over HTTPS.
To specify the list of FirePass controllers available to the
client component and Windows logon integration
1. In the navigation pane, click Device Management, click Client
Downloads, and click Windows (x86).
The Customize Package screen opens.
2. Click the Customize Client Components tab.
The Customize Client Components screen opens.
3. Locate the FirePass controller list area.
4. In the add new FirePass controller area, specify a FirePass controller
in the following form:
[protocol://]host[:port][/landinguri]
5. Click Add Controller.
The new entry appears in the list.
5 - 31
Chapter 5
You can use the up, down, and delete icons to operate on items in the list.
The client component accesses the FirePass controllers in the order they
appear in the list. When the client component finds an available controller, it
stops looking.
Configuring user interface options
You can determine several methods of operation for users to customize their
experience.
◆
Starting mode
You can select Start in Simple Mode to have the Network Access
connection start immediately after logon, or you can select Start in
Advanced Mode to have the system present a list of favorites from
which the user can select. Start in Simple Mode is the default.
◆
Minimize location
You can select Move to System Tray when Minimized to have the
Network Access connection appear as an icon in the user’s Windows
System Tray when the user minimizes the window running the Network
Access connection. The default is checked.
◆
Tooltip visibility
You can select Show Tooltips to have the system present identifying text
on Windows when the user positions the cursor over a setting or icon.
The default is checked.
◆
Status message visibility
You can select Show Additional Status Messages to have the system
display messages that track system status. The default is checked.
◆
Logon prompt usage
You can select Use Legacy Logon Prompt to have the system present
Username and Password as the labels for the logon prompts. The
default is not checked, so the system uses a web-based interface to logon,
which supports pre-logon checks. The user cannot save the values in
Username and Password using the web-based interface. By default, the
system uses the Username prompt and Password prompt labels
specified in the Customization section of the screen. By default, these are
Username and Password.
◆
Toolbar and status bar visibility and appearance
You can select Show Toolbar to have the system display the toolbar on
the user’s Network Access connection screen. You can select Show
Status Bar to have the system display a line of explanatory text in the
user’s Network Access connection screen. You can select Use Large
Icons in Toolbar and Add Text to Toolbar Icons to control how icons
display in the user’s toolbar. The default is checked for all options.
Configuring proxy settings
The FirePass controller client component uses the Proxy Settings area to
determine proxy settings to use for connection. The client component and
Windows logon integration share these settings.
5 - 32
◆
Use System Proxy Settings
Uses the Windows proxy settings configured in Internet Explorer to
connect to the FirePass controller. This option does not apply to the
Window Logon Integration settings.
◆
Use Custom Proxy Settings
Selects a proxy from the configured items, in a specific order. For
example, when you configure all custom proxy options, the client
attempts to use a custom proxy option in the following order, until one
succeeds: Automatically Detect Proxy Settings, Use Automatic
Configuration Script, Use a Proxy Server.
◆
Automatically Detect Proxy Settings
Detects the proxy settings on the proxy server using the Web Proxy
Auto-Discovery (WPAD) protocol.
◆
Use Automatic Configuration Script
Detects the proxy settings using a configuration script at a specified
URL.
◆
Use a Proxy Server
Specifies which proxy server the client uses to connect to the FirePass
controller. You can configure two proxy server settings:
• Address
Specifies the protocol and host name of the proxy server.
• Port
Specifies the port number of the proxy server.
Configuring Windows logon integration options
You can configure Windows logon integration options for client
connections originating on Microsoft Windows 2000 and Windows XP or
later. When configured, the FirePass controller uses the user’s Windows
logon credentials for authenticating Network Access connections. In
addition, users can change their Windows passwords over Firepass
controller connections.
The Windows logon integration options provide close integration with the
Windows domain logon process. The component uses domain credentials
for authorization for external users or external authorization for internal
users. The connection users receive looks like a dial-up connection. There is
only a clientless mode, no browser window. Using the Windows logon
integration functionality enables automatic start of the connection at logon
and provides support for logon scripts such as drive mappings.
Windows logon integration settings provide the following connection
functionality:
• Establishes a VPN connection to the FirePass controller before users log
on onto their computers using a virtual dial-up entry. To use this feature,
the user must check the option Logon using the dial-up connection at
the Windows logon prompt. This option is available only for computers
that are members of the domain (that is, corporate computers).
• Establishes a VPN connection to the FirePass controller when users log
on to their computer.
5 - 33
Chapter 5
To set up Windows logon integration
1. In the navigation pane, click Device Management, click Client
Downloads, and click Windows (x86).
2. Check the Windows Logon Integration check box.
4. Click the Customize Client Components tab.
The Customize Client Components screen opens.
5. Specify a list of FirePass controllers for use by the Windows Logon
Integration component.
6. Click the Download tab.
The Download components screen opens.
7. Click the Download link, and specify a location for saving the MSI
package containing the Windows Logon Integration control.
8. Copy the file to the client computer, and double-click to install it.
You can specify the following Windows Logon Integration settings. The
default is checked for all options except where noted.
• Phonebook Entry Name
Specifies a unique name for the virtual dial-up entry, which the system
displays on the client computer in the Network Connections folder. If
more than one resource exists, the system presents a list from which the
user can select. For this option to succeed, the connection must be
running with rights to write to the AllUsers profile.
• Reconnect Attempts
Specifies the maximum number of reconnection attempts for the
operation.
• Time between Reconnect Attempts (sec)
Specifies the amount time to wait for the client (in seconds) before the
system attempts to reconnect.
• Display Progress while Connecting
Displays the progress of the connection attempt.
• Prompt for User Name and Password
Prompts users to enter their user name and password.
• Include Windows Logon Domain
Presents the user’s domain on the Windows logon screen.
• Prompt for FirePass Controller Address
Prompts users to enter their FirePass controller address, as either a host
name or IP address.
• Show Icon in Notification Area when Connected
Displays to users an icon in the notification area when they establish a
connection.
• If Connection Fails, Try Next Controller
If the connection fails, tries the next FirePass controller specified in the
list in the FirePass Controllers List area.
5 - 34
• Move Successful Controller to Top of List
Upon successful connection, moves the FirePass controller to the top of
the FirePass controller list. The default is not checked.
Configuring session options
You can specify session-based options for client connections originating on
Microsoft Windows 2000 and Windows XP or later. Session settings govern
persistence and update configuration.
◆
Enable Autoreconnection
Specifies that the client can try to automatically reconnect to a FirePass
controller. The default is not checked.
• Maximum Autoreconnection Attempts (1-99)
Indicates the number of times the client can try to reconnect
automatically. You must check Enable Autoreconnection to specify
Maximum Autoreconnection Attempts. The default is 5.
◆
Maintain History
Specifies whether the client can store a list of the FirePass controllers it
accessed. The default is checked.
• Save Passwords
Specifies whether the client can store the logon password along with
the history. You must check Maintain History to be able to select
Save Passwords. The default is not checked.
◆
Automatic update options
Provides a set of options that govern automatic updates for installed
components.
• Automatically Update Components
Specifies that the client can receive automatic updates for installed
components. This is the default.
• Prompt User before Installing Updates
Specifies that the system request confirmation from the user before
the client can receive automatic updates for installed components.
• Don’t Perform Component Updates
Prevents automatic updates of installed components.
Configuring user permissions options
User permissions options control how the client receives session settings
and whether a user can override certain settings.
• Dynamically Download Session Settings During Logon
(Do not allow users to change session settings)
Specifies that the system downloads session settings when the client logs
on to the FirePass controller. When you check this option, users cannot
change their session settings when they are connected to the FirePass
controller.
• Do not Allow Users to override Proxy Settings
Specifies that the user cannot change the proxy settings configured in the
Proxy Setting area.
5 - 35
Chapter 5
Configuring Network Access master group settings
When you want to customize Network Access settings for a specific group
of users, you can configure master group settings. Master group settings
include auto-logon options, the running of policy checks on client
workstations, and configuring the FirePass controller webtop.
The FirePass controller provides master-group-related options on the
Network Access : Master Group Settings screen. You can select the master
group you want to configure from the Master Group list at the top of the
screen. For more information about configuring master groups, see
Configuring a master group, on page 2-11.
The Master Groups Settings screen presents options for specifying the
following settings:
◆
Auto-logon to drive mappings using FirePass user logon credentials
Logs on using the user’s FirePass controller name and password if the
mapped drives require user authentication. Checking this option reveals
the Domain/Workgroup option, in which you can specify a domain name
to use when logging on to the mapped drives.
◆
Perform continuous policy verification during the Network Access
connection
Periodically checks for the presence or absence of processes configured
in Policy Checks. Checking this option reveals Process Timeout Value
in which you can specify the timeout interval (in seconds), before the
FirePass controller terminates the Network Access connection. The
FirePass controller provides continuous verification only on policies
configured to monitor processes. For more information, see descriptions
for setting processes under Understanding Policy Checks options, on
page 5-26.
◆
Click to change the status and/or webifyer position on the webtop
Opens the Users : Groups : Master Groups screen, with the User
Experience tab selected. Options available include enabling the user to
change account information on the webtop, allowing the user to create
personal webtop favorites, and migrating most-used webtop items to the
top of the list. For more information on configuring the user experience,
see the online help for the Users : Groups : Master Groups screen on the
User Experience tab.
Note
When you create a new favorite, the user must log out and log on again to
have the favorite available.
5 - 36
Customizing the user experience for Network Access
connections
There are a number of ways to customize the user experience for Network
Access connections.
• Configuring for a Network Access-only user experience
For more information, see Configuring for a Network Access-only user
experience, following.
• Ordering the items on the user’s webtop
For more information, see Ordering the items on the user’s webtop, on
page 5-38.
• Controlling how the favorites reorder in response to frequency of use
For more information, see Ordering the items on the user’s webtop, on
page 5-38.
• Displaying banners and logos on the screen
For more information, see Displaying banners and logos on the screen,
on page 5-38.
• Allowing users to change their information and create favorites
For more information, see Allowing users to change their information
and create favorites, on page 5-38.
• Specifying the first-name, last-name order presented in the user’s webtop
For more information, see Specifying the first-name, last-name order
presented in the user’s webtop, on page 5-38.
• Presenting the Network Access connection as an icon in the Windows
system tray
For more information, see Presenting the Network Access connection as
an icon in the Windows system tray, on page 5-39.
• Minimizing the connection window after successful connection
For more information, see Minimizing the connection window after
successful connection, on page 5-39.
Configuring for a Network Access-only user experience
You can configure for a Network Access-only user experience by checking
the Use Network Access Only Webtop check box on the User Experience
screen, available on the Users : Groups : Master Groups screen. This option
is useful when you have only one Network Access favorite This option is
used only when you have one Network Access favorite and Autolaunch
based on endpoint protection is checked on the Client Settings tab on the
Network Access : Resources screen. Selecting the Use Network Access
Only Webtop option starts the Network Access connection and replaces the
webtop with the contents of the Network Access window.
If you also check the option Minimize window after successfully
connecting Network Access client, available on the Network Acces :
Resources screen, the system minimizes the browser window after
establishing the Network Access connection. If you check the options
Minimize window after successfully connecting Network Access client
5 - 37
Chapter 5
and Use Tray icon instead of Taskbar entry when minimized, the system
minimizes the browser window to the F5 icon in the system tray. If you
check the options Minimize window after successfully connecting
Network Access client, Use Tray icon instead of Taskbar entry when
minimized, and Do not display tray icon for connection, the system
minimizes the browser window, and shows only the F5 icon in the system
tray.
Ordering the items on the user’s webtop
You can specify the order items appear on the user’s webtop by configuring
items on the User Experience screen, available on the Users : Groups :
Master Groups screen. You can use arrows to reorder items on the user’s
webtop, specify custom names for the different items, and determine content
for browsers that support HTML 3.2 and later, browsers for PDA, i-mode,
and other minibrowsers, and WAP phone.
Controlling how the favorites reorder in response to frequency of use
You can elect to have frequently used favorites migrate to the top of the
user’s list by checking the Enable user-level adaptive ordering of
webifyers option on the User Experience screen, available on the Users :
Groups : Master Groups screen. Then, favorites that users click on move to
the top of their favorites list when they next access their webtops.
Displaying banners and logos on the screen
You can control whether banners and logos show along the top of the user’s
webtop by checking the FirePass Webtop doesn’t show logo and banner
by default option on the User Experience screen, available on the Users :
Groups : Master Groups screen. You can also control whether the webtop
contains both favorites and icons by selecting one of the following options:
• Show Favorites only, hide Webifyer icons
• Show both Favorites and Webifyer icons
• Show Webifyer icons only (classic look)
Allowing users to change their information and create favorites
You can allow users to change their information by checking the Allow user
to change user information option. When checked, users can change their
first name, middle initial, last name, and email address by selecting the
Tools : Account Details screen from their webtops.
Specifying the first-name, last-name order presented in the user’s webtop
You can control how you want to display the user’s full name on the User
Management screen, in reports and logs, in other places in the Administrator
Console, and on the user’s webtop.
5 - 38
You can elect to have user names governed by the global option Default
order for full user name, available on the Device Management :
Customization : Global screen, by checking the option Use global setting in
Device Management : Customization. When this option is not checked,
you can select an ordering option from the Order in full user name list on
the User Experience screen, available on the Users : Groups : Master Groups
screen. The ordering option applies to all users in the master group specified
in the Master Group list.
Presenting the Network Access connection as an icon in the Windows
system tray
You can have the Network Access connection appear as an icon in the
Windows system tray instead of showing as a Windows Taskbar entry when
minimized. To do so, check the Use Tray icon instead of Taskbar entry
when minimized option on the Customization tab, available on the Network
Access : Resources screen. When you check this option, when the user
minimizes the Network Access connection window, the system places an
icon in the Windows system tray instead of creating an entry for the
Windows Taskbar. Using this option simplifies the user experience, takes up
less space on the user’s Taskbar, and prevents the user from using Alt+Tab
to navigate to the Network Access connection window.
You can also eliminate the tray icon completely by checking the Do not
display tray icon for connection option on the Customization tab, available
on the Network Access : Resources screen. Using this option prevents the
user from inadvertently closing the Network Access connection.
Minimizing the connection window after successful connection
You can have the system automatically minimize the Network Access
connection window after establishing a successful connection by checking
the Minimize window after successfully connecting Network Access
client option on the Customization tab, available on the Network Access :
Resources screen. Using this option helps simplify the user experience and
expand screen real estate by removing the Network Access connection
window.
5 - 39
Chapter 5
5 - 40
6
• Introducing Application Access
• Understanding App Tunnels
• Defining App Tunnel favorites
• Configuring master group settings for App Tunnels
• Understanding Legacy Host connections
• Configuring terminal server favorites
• Configuring global settings for Application Access
Introducing Application Access
The FirePass Applications Access features provide remote users with
web-based remote access to a wide variety of network applications and
resources, including email servers, intranet servers, file servers, terminal
services, and legacy mainframe, IBM iSeries and AS/400, Telnet
character-based terminal applications.
Application Access enables users to use an existing client to access the
server application through App Tunnels, or they can have the FirePass
controller supply the browser-based Legacy Hosts and Terminal Servers
ActiveX components or Java client.
Application Access consists of three main types of access:
• App Tunnel access
Provides remote users with browser-based access to a backend server.
App Tunnels provide secure, application-level TCP/IP connections from
the client into a specified set of IP addresses and ports on the LAN.
• Legacy host access
Provides remote users with browser-based, character-driven terminal
access to legacy VT100, VT320, Telnet, SSH, and IBM 3270 and IBM
5250 applications without any modifications to the applications or
application servers.
• Terminal services access
Provides remote users with browser-based, graphical terminal interfaces
for Microsoft Terminal Servers, Citrix MetaFrame applications, and
VNC servers.
Application Access does not require any application modifications or any
third-party software to enable the interaction with the application.
The connection process automatically downloads and installs all
components required on the client system. You can also preinstall the
components, if your company security policy prohibits ActiveX component
installation by the end user.
Legacy Host access supports TN5250 and IBM iSeries and AS/400
connections through an ActiveX control for Internet Explorer, and a
self-installed plug-in for Netscape or Mozilla browsers on Windows client
computers to interpret the terminal data stream. Legacy Host access
provides support through Java for VT100/320 for UNIX, and TN3270 for
mainframes.
6-1
Chapter 6
Understanding App Tunnels
Application Tunnels, or App Tunnels, provide much the same functionality
as Network Access, but they allow additional control over which application
a user can access through the FirePass controller.
Using App Tunnels, you can configure secure, application-level TCP/IP
connections from the client to a specific set of IP addresses and ports on the
network. On the remote end, the browser loads an ActiveX control in
Internet Explorer, and a self-installed plug-in for Netscape or Mozilla
browsers on Windows platforms. After the process establishes a connection,
the user-defined applications that use these connections can be started
automatically.
Unlike a traditional IPsec VPN client that exposes the entire network, App
Tunnels only create connections to the specific resources used by the
configured application. You can also restrict users to the particular
application they need to use.
You can configure the following applications for use with App Tunnels:
• Applications that are accessed using HTTP or HTTPS
• Terminal emulators, including SSH
• Internet Mail (POP/IMAP/SMTP)
• LDAP-enabled clients
• Network drive mapping
• Custom applications
Note
App Tunnels do not support UDP application traffic.
6-2
Figure 6.1, following, shows a comparison of the flow of application data in
a traditional environment and with the FirePass controller App Tunnels.
Figure 6.1 Comparison of application data flow without and with the FirePass controller
Choosing a static or dynamic App Tunnel
The FirePass controller supports two types of App Tunnels: static and
dynamic. The system creates static tunnels when the client clicks to run a
favorite, before the application starts. The system creates dynamic tunnels
in response to an application requests.
Note
You can configure a combination of dynamic and static tunnels for a single
App Tunnel definition.
You use static App Tunnels support connections to a specific set of IP
addresses and ports on the network. You can configure static App Tunnels
to work without requiring the user to have administrative rights on the client
system.
The following cases represent examples of when to use static App Tunnels:
• Applications that are accessed using HTTP or HTTPS
• Custom applications
• Applications that do not allow more than one instance, and you do not
want to halt the existing instance
• Internet Mail (POP/IMAP/SMTP)
• LDAP-enabled clients
• Network drive mapping
6-3
Chapter 6
• Windows file sharing (because this application uses the operating system
kernal to provide network communication or server, not the Windows
socket API)
• Terminal emulators, including SSH
Dynamic App Tunnels support applications that require dynamic IP
addressees and ports. The following are examples of candidates for dynamic
App Tunnels.
• A web application that uses ActiveX controls or Java-based plugins to
open a network socket directly to the application server
• A web application that uses XML to embed a hard-coded IP address or
hard-coded port number of the application server
• A custom (nonbrowser-based) application that does not communicate
using the HTTP protocol
• Applications that support only one instance, but it is acceptable to halt
the existing instance to start the new application
Dynamic App Tunnels work best with applications that support multiple
instances. To determine whether an application supports multiple instances,
on a Windows computer, right-click the Windows Taskbar, select the Task
Manager item, and click the Processes tab. Then start an application several
times to see if more than one process of this application appears in the list on
the Processes screen. If the application does not support multiple instances,
there is always only one process in the list.
You can still use dynamic App Tunnels with these types of applications if
you check the Terminate existing check box when you configure the
dynamic App Tunnel favorite. When you check this option, when the user
starts an App Tunnel that would result in an additional instance being
created, the system prompts the user to close the existing instance before
starting the additional one.
When you use dynamic App Tunnels, the system creates a tunnel when the
client application needs to communicate with the server. Therefore, dynamic
App Tunnels are a also good choice in cases in which you do not want all
ports created at the same time, for example, when you have a number of
servers performing load balancing.
Important
Dynamic App Tunnels requires power user rights.
You configure dynamic App Tunnels on the following screens:
• In a specific definition on the Application Access: App Tunnels :
Resources screen under the Application Tunnels tab
• On the Application Access: App Tunnels: Master Groups Settings screen
on the Dynamic Tunnels/Web Application Tunnels tab
Note
If you have legacy App Tunnels that are working for you, there is no need
for reconfiguration. The system automatically uses static App Tunnels.
6-4
Defining a web application tunnel
A web application App Tunnel is a dynamic App Tunnel designed
specifically for a web browser-based application. To configure a Web
Application Tunnel, you use URLs to specify the location of the application.
In this case, the system creates the tunnel when the user clicks a link (that is,
dynamically).
Note
Although you can configure the same application using a dynamic App
Tunnel, the process for configuring web application App Tunnels is simpler.
Web applications are perfect candidate for using dynamic App Tunnels as
long as they do not use reverse proxy. If an application uses reverse proxy,
you can still try configuring it for dynamic App Tunnels. If the application
does not work through dynamic App Tunnels, you should use Portal Access
instead to configure the connection.
Web App Tunnels require a browser that supports multiple instances.
Windows Internet Explorer supports multiple instances. Mozilla and
FireFox support multiple processes within the same instance. Therefore, all
dynamic App Tunnels start an instance of Internet Explorer or a custom
minibrowser created to support dynamic App Tunnels.
Use of the minibrowser provides additional security in that users cannot
copy text from the minibrowser window, print when the minibrowser is the
active application, or drag and drop to the minibrowser window. In addtion,
the minibrowser does not allow the running of plug-ins or extensions.
Tip
You can configure this additional security for Internet Explorer uses as well
by checking the Locked Browser check box when you create a Web
Application Tunnel favorite.
You configure web application App Tunnels on the following screens:
• On the Application Access : App Tunnels : Resources screen under the
Web Application Tunnels tab. For more information about creating web
application App Tunnels, see To create an App Tunnel favorite or alias,
on page 6-7.
• On the Application Access : App Tunnels : Master Groups Settings
screen under the Dynamic Tunnels/Application Tunnels tab. For more
information about options on this tab, see Understanding master group
settings for dynamic and web application tunnels, on page 6-23.
Understanding access restrictions for App Tunnels
You can configure an access control list (ACL) to restrict access for a static
or dynamic App Tunnel. ACLs define locations the App Tunnel users can
access from within the App Tunnel. Defining ACLs prevents users from
6-5
Chapter 6
navigating to locations outside the ones you specifically define for the App
Tunnels that access your network. For procedures for defining ACLs, see
Restricting access to App Tunnels, on page 6-17.
Static and dynamic App Tunnels and web application App Tunnels share
access control lists for the duration of a FirePass controller session. To
change which ACLs govern a session, users must halt the connection and
start it again.
You can configure ACLs in the following areas:
• On the Application Access : App Tunnels : Master Group Settings screen
under the Common tab
Application Tunnels tab
Web Application Tunnels tab
• In the Allow list box specific to the App Tunnel you define on the
Application Access : App Tunnels : Resources screen under the
Application Tunnels tab or the Web Application Tunnels.
The location of the ACL definition does not matter. The system combines
all ACLs to use during the session. The system combines entries in ACLs
from definitions in the following locations:
• At the master group level
• At the resource group level
• In the specific App Tunnel favorite definition
ACLs defined on the Master Group Settings screen cover the entire master
group, but you can specify additional resource-level ACLs on the Resources
screen. In addition, ACLs defined on the Resources screen cover the entire
resource group, but you can specify App Tunnel-specific ACLs in the Allow
list box for the App Tunnel.
Important
For dynamic App Tunnels, if you do not specifically allow acess, the system
disallows it.
6-6
Defining App Tunnel favorites
You can create favorites and aliases to favorites on the Resources screen. A
favorite is a named and saved set of options. An alias to a favorite is a
named link to an existing favorite in another resource group. Favorites and
aliases to favorites appear as links on the user’s webtop. When a user clicks
a favorite or an alias, the system establishes the static App Tunnel and starts
the application specified.
To create an App Tunnel favorite or alias
1. In the navigation pane, click Application Access.
The Application Access : App Tunnels : Resources screen opens.
2. From the Resource Group list in the upper left, select the resource
group you want to contain the favorite.
3. Click the Add New Favorite link.
The screen refreshes to reveal additional options.
4. From the Type list, select from the following types:
• Favorite: Represents a new App Tunnel.
To create a new favorite, select Favorite, and skip to To complete
the favorite definition, following.
• Alias: Represents an association with a existing favorite from a
different resource group. If there are no other groups available, or
if you have not defined other connections, the system does not
present the Alias option.
When you select Alias, the screen refreshes to reveal additional
options, as described in To complete the alias definition, on page
6-11.
To complete the favorite definition
1. Complete the procedure, To create an App Tunnel favorite or alias,
on page 6-7, selecting Favorite from the Type list.
2. In the Name box, type the identifying label you want to use.
The FirePass controller displays this name as a label for the App
Tunnels favorite on the user’s webtop.
3. In Allow List, specify a host name or IP address and ports in the
following format:
host_name:ports or IP_address/mask:ports
For example:
*.siterequest.com:80 or 172.30.11.0/24:80,443
Note: For more information about specifying ACLs, see To specify
ACLs for favorites or aliases, on page 6-20.
6-7
Chapter 6
4. If you want to restrict access based on a defined protected
configuration, from the Endpoint protection required list, select
the protected configuration. To add endpoint protection, you must
first define it. For more information about protected configurations,
see Creating protected configurations, on page 3-27.
5. Click the Add Favorite button.
The new favorite appears in the list.
6. To add a dynamic App Tunnel, click the Add New Dynamic App
Tunnel button, and continue with the following procedure.
7. To add a static App Tunnel, click the plus icon
to the left of the
Static Tunnels heading, and continue with the procedure To
complete the static App Tunnel definition, on page 6-10.
To complete the dynamic App Tunnel definition
1. Complete the procedure, To complete the favorite definition,
preceding, electing to configure a dynamic App Tunnel.
2. From the list of clients, select a type of application you want the
client to use. You can select one of the following types of
applications:
• Custom
When you select Custom, you can specify the application name
and path, including any environment variables in the format
%envvarname%, enclosing the string in quotation marks when
the path contains spaces. The variables resolve to the value
representing the environment variable on the client computer. For
example, to configure for the Microsoft Service Terminal client,
specify the following string in Application:
"%SystemRoot%\system32\mstsc.exe" /v: mysite
For more information about creating custom App Tunnels, see
Creating custom App Tunnels, on page 6-14.
• Citrix Neighborhood Agent
When you select Citrix Neighborhood Agent, the system
populates the Name field with the value Citrix Neighborhood
Agent, places the value "%ProgramFiles%/Citrix/ICA
Client/pnagent.exe" in the Application field, and checks the
Terminate Existing box. These are default values that you can
change.
• Microsoft Outlook
When you select Microsoft Outlook, the system populates the
Name field with the value Microsoft Outlook, places the value
outlook.exe in the Application field, and checks the Terminate
Existing box. These are default values that you can change.
• Microsoft Outlook Express
When you select Microsoft Outlook Express, the system
populates the Name field with the value Microsoft Outlook
6-8
Express, places the value msimn.exe in the Application field,
and checks the Terminate Existing box. These are default values
that you can change.
• Microsoft Telnet client
When you select Microsoft Telnet client, the system populates
the Name field with the value Microsoft Telnet client, and
places the value
"%SYSTEMROOT%/SYSTEM32/telnet.exe" in the
Application field. These are default values that you can change.
• Microsoft Terminal Server Client
When you select Microsoft Terminal Server Client, the system
populates the Name field with the value Microsoft Terminal
Server Client, and places the value
"%SYSTEMROOT%/SYSTEM32/mstsc.exe" in the
• PuTTY
When you select PuTTY, the system populates the Name field
with the value PuTTY, and places the value
"%ProgramFiles%/PuTTY/putty.exe" in the Application
field. These are default values that you can change.
• SecureCRT
When you select SecureCRT, the system populates the Name
field with the value SecureCRT, and places the value
"%ProgramFiles%/SecureCRT/SecureCRT.exe" in the
• Private Shell
When you select Private Shell, the system populates the Name
field with the value Private Shell, and places the value
"%ProgramFiles%/Private Shell/pshell.exe" in the
3. In the accompanying Name box, specify the user-friendly name for
the system to use when presenting the name to the user in a dialog
box, for example, when the system detects a running instance of an
application, and the system prompts the user to close it.
4. In the Application box, specify a string that starts an application
transparently for the user.
For example:
telnet 127.10.10.10
putty -ssh 127.10.10.10
"%SYSTEMROOT%/SYSTEM32/mstsc.exe"
Note: The system searches the path for the application, so you do
not have to specify the complete path if the path is already set. If you
do not specify a path, the FirePass controller searches the Windows
registry. If an application registers itself in the Windows registry,
like Microsoft Outlook does, for example, the FirePass controller
can run it.
6-9
Chapter 6
5. Check or clear the Terminate Existing box, if the application you
are starting does not support multiple instances, or when you want
the system to prompt the user for confirmation in halting the
existing instance.
6. Click the Add New Dynamic Tunnel button.
You can modify any existing setting by changing it and clicking the
Update All button.
Note
To complete the static App Tunnel definition
1. Complete the procedure, To complete the favorite definition, on
page 6-7, electing to configure a static App Tunnel.
2. From the list of clients, select a type of application you want the
client to use. You can select one of the following types of
applications:
• Custom client
For more information about creating custom App Tunnels, see
Creating custom App Tunnels, on page 6-14.
• Exchange
• Internet EMail (POP + SMTP)
• Internet EMail (IMAP + SMTP)
• LDAP
• http
• https
• Telnet
• SSH
• VNC
• Front Page/WebDAV
• MS Terminal Services
• Citrix
• RPC port mapper
• FTP (Passive)
• MS File Shares
• Exchange Client/Server Comm.
When you select an option, the system adds fields, if necessary, and
populates those fields with common settings. For example, if you
select Internet EMail (POP and SMTP) as the application class,
the FirePass controller the FirePass controller adds a definition row,
and populates the two rows with common application settings. In
the first row, the system places a port number of 110 in the Remote
6 - 10
Host : Port or Range box. The FirePass controller next generates
an IP address from the 127.0.0.0/255.0.0.0 subnet, and places that
generated value, along with 110, in the Local Host : Port or Range
boxes. This is the IP address and port combination the client
connects to when accessing the App Tunnel. Finally, the system
generates another IP address from the same subnet, and places that
generated value, along with 25, in the Local Host : Port or Range
boxes. This is the IP address that the system uses for SMTP
exchanges. You can change these values to match those of your
local network, when they differ from the defaults.
3. In the Application box, specify a string that starts an application
transparently for the user. For example:
iexplore http://127.10.10.80/sales/automation.pl
telnet 127.10.10.10
putty -ssh 127.10.10.10
4. Check or clear the Keep Alive box.
Checking Keep Alive turns on the TCP-based Keep Alive setting on
both the client-to-FirePass controller connection and the FirePass
controller-to-target-host connection. Checking Keep Alive does not
prevent the user’s session from timing out.
5. Click the Add New Static Tunnel button.
You can modify any existing setting by changing it and clicking the
Update All button.
Note
To complete the alias definition
1. Complete the preceding procedure, To create an App Tunnel
favorite or alias, on page 6-7, selecting Alias from the Type list.
2. From the Group list, select the resource group containing the
existing favorite you want to use as the source for the alias.
3. From the Favorite list, select the favorite you want to use as the
source for the alias.
4. Check Inherit Allow List to use the defined ACLs from the source,
or clear the box to reveal an Allow List you can configure
specifically for this alias.
the protected configuration.
To add endpoint protection, you must first define access rules.
6. Click the Add Favorite button.
The new alias appears in the list.
6 - 11
Chapter 6
Note: The alias uses the dynamic or static application tunnel
definition from the source favorite.
Creating web application App Tunnel favorites
To make dynamic web applications tunnels available to users, you create
favorites that access your internal web sites. When the user clicks a web
application tunnel favorite, the FirePass controller starts a web browser,
which opens the specified URL The system dynamically creates all TCP
tunnels required to download the page.
To create a web application App Tunnel
1. In the navigation pane, click Application Access.
The Resources screen opens.
2. Click the Web Application Tunnels tab.
The Web Application Tunnels screen opens.
group you want to contain the web application App Tunnel.
• Favorite: Represents a new web application App Tunnel.
To create a new favorite, select Favorite, and skip to To complete
the web application favorite definition, on page 6-13.
different resource group. If there are no other groups available, or
if you have not defined other connections, the system does not
present the Alias option.
options, as described in the following procedure.
To complete the web application alias definition
1. Complete the preceding procedure, To create a web application App
Tunnel, selecting Alias from the Type list.
2. From the From group list, select the resource group containing the
existing favorite you want to use as the source for the alias.
3. From the Favorite list, select the favorite you want to use as the
source for the alias.
4. Check Inherit ACL to use the defined ACLs from the source, or
clear the box to enable the Local ACL box, where you can specify
ACLs for this alias.
5. Click the Add New button.
The new alias appears in the list.
6 - 12
Note: The alias uses the endpoint protection setting from the source
favorite.
To complete the web application favorite definition
1. Complete the procedure, To create a web application App Tunnel,
on page 6-12, selecting Favorite from the Type list.
2. In the Name box, type the identifying label you want to use.
The FirePass controller displays this name as a label for the App
Tunnels favorite on the user’s webtop.
3. In URL, type the intranet web server that serves the application. For
example: http://server.siterequest.com/index.html
Note: You can click the Add to allow list link to add the URL to
Allow list automatically.
4. In URL variables, type the arguments to be either appended to the
GET request or sent as data in a POST request to the specified URL.
5. Check Use POST for URL variables to have the system include
the variables in the POST request, or clear the box to prevent
sending of the variables.
6. Check Locked Browser to prevent certain user functionality,
including:
• Typing URLs in the browser’s address box
• Selecting text on the page
• Saving web pages
• Printing web pages.
7. In Allow List, specify a host name or IP address in the following
format:
host_name:ports or IP_address/mask:ports
For example:
*.siterequest.com:80 or 172.30.11.0/24:80,443
Note: For more information about specifying ACLs, see To specify
ACLs for favorites or aliases, on page 6-20.
the protected configuration. To add endpoint protection, you must
first define access rules.
The new favorite appears in the list.
Once you configure a favorite, you can select one to start automatically by
selecting it from the Default box, and clicking Update.
You can also define resource-group level ACLs for web application App
Tunnels. For more information, see To specify a resource-group level ACL,
on page 6-20.
6 - 13
Chapter 6
Configuring Remote Host and Local Host settings: important
considerations
If you specify a network name (that is, a DNS name, a WINS name, or a
static host name) instead of an IP address in Remote Host or Local Host,
the App Tunnel or Terminal Servers connection operation changes the hosts
file on the client computer during the connection. If you define the remote
hosts with IP addresses then the system does not modify the hosts file.
On Windows systems, you can find the hosts file in
<drive>\<windowsdir>\system32\drivers\etc\hosts.
The temporary patch allows the App Tunnel or Terminal Server connection
to override the network name settings, while preserving the existing network
name settings for the applications. The App Tunnel or Terminal Server
connection restores the original hosts file when it ends the session.
Important
Static App Tunnels support forwarding ranges of TCP ports. To do so,
specify the range in the Remote Host : Port or Range and Local Host :
Port or Range boxes as port1-port2,port3,port4-port5, and so on. App
Tunnels limits the maximum number to 50. If you use port ranges, the range
you specify in local and remote must match.
Creating custom App Tunnels
You can create a custom tunnel by specifying the values you want for the
connection in the Remote Host : Port or Range and Local Host : Port or
Range boxes.
In general, F5 Networks recommends that you specify the port number of
the remote host, unless the client’s computer is already running a service on
that port. You can specify a port range containing a maximum of 50 ports. If
you specify a port range is used, the local and remote ranges must match.
We also recommend that the IP addresses you specify be associated with the
DNS name of the service the clients need in either the local hosts file or on
the DNS server. For example:
telnet.siterequest.com 127.10.10.10
Important
6 - 14
In custom App Tunnels, you can specify environment variables in the
format %variable%. The system replaces the variable with the appropriate
value when it creates the tunnel. Use quotation marks to enclose any
application strings that contain spaces.
The system supports the following variables:
• %envvarname%
Represents the value of the environment variable on the client computer.
• %group%
Represents the master group name of the user who is logging on.
• %username%
Represents the name of the user who is logging on.
• %firstname%
Represents the user’s first name.
• %lastname%
Represents the user’s last name.
• %fullname%
Represents the combination of the user’s first and last name.
The system also supports the following variables for mapping Microsoft
Windows network shares.
• %envvarname%
Represents the value of the environment variable on the client computer.
• %password%
Resolves to the user’s password when you enable the master group
option Auto-logon to applicable AppTunnels using FirePass user
logon credentials.
• %host%
Represents the host address, which the system resolves to the loopback
host address.
• %port%
Indicates the loopback port.
The %port% variable is useful when original local port changes because
of conflicts with other software.
The following entries illustrate valid strings for various App Tunnels.
iexplore http://%host%:%port%/sales/automation.pl?u=%username%
telnet 127.3.54.34
%SystemRoot%\System32\mstsc.exe /v:127.107.93.167 /f
Configuring App Tunnels that open automatically
You can configure an App Tunnel to open automatically. You can have the
system restrict automatic open to App Tunnels depending on the assigned
protected configuration.
6 - 15
Chapter 6
To configure App Tunnel auto-open
1. Create an App Tunnel favorite, as described in Defining App Tunnel
favorites, on page 6-7, making sure to select a defined protected
configuration from the Endpoint protection required list.
2. Check the Autolaunch based on endpoint protection check box.
3. From the endpoint list, select the endpoint protection you want to
require, or select Any endpoint configuration to have the system
open the App Tunnels based on any security you have configured
for the clients.
4. In the Autolaunch tunnels section, check the box to the left of each
tunnels you want the system to automatically open for clients that
pass the configured endpoint security requirements.
5. Click the Apply button.
Now, when users who log on have the endpoint protection you require, the
FirePass controller automatically opens the associated App Tunnel and
provides the user access.
Creating static App Tunnels to network file shares
You can configure a static App Tunnel to map to network file shares. You
can have the tunnel open automatically, depending on the assigned protected
configuration, like other App Tunnels.
To map a network drive
1. Create a static App Tunnel, and select MS File Shares.
For more information about creating application tunnels, see
Defining App Tunnel favorites, on page 6-7.
2. Retain the default value of 139 in Remote Host : Port or Range
and Local Host : Port or Range.
3. In Command Line, type a string for the process to use to mount the
drive.
You can use the following templates, substituting your network
information in the appropriate places.
mount <drive_name> \\<network_computer_name>\<shared_folder_name>
mount <drive_name> \\<automatically_generated_IP_address>\<shared_folder_name>
For example, if you want to map the H drive on the client computer
to the sales share, which is located on the corporate_presentations
computer, type:
mount H: \\corporate_presentations\sales
mount H: \\127.31.21.233\sales
6 - 16
Note: You can use the syntax specified in the second example when
the client operating system is Windows NT, Windows 2000,
Windows SP, or Windows ME.
For drive mapping to work, the FirePass controller must have a valid
certificate signed by a Certificate Authority accepted by the client’s
browser. Otherwise, a security warning dialog could prevent the drive from
being mapped successfully.
Tip
When you configure App Tunnels for mapping drives, you can have clients
use their FirePass controller logon credentials by selecting the option
Auto-logon to applicable AppTunnels using FirePass controller user
logon credentials on the Application Access : App Tunnels : Master Group
Settings screen. This option applies only to App Tunnels configured to map
a network drive. If you select this option, you can also provide a domain or
workgroup name to be used when logging on to the mapped drive.
Restricting access to App Tunnels
Sometimes called Allow Lists, ACLs control access within App Tunnel at
three levels, each level’s ACLs being combined to govern the entire session.
You define ACLs when you want to prevent the user from accessing
locations outside the ones you specifically define for the App Tunnels that
access your network. You can specify ACLs in the fllowing locations.
◆
In all App Tunnels in a specific master group
You define master-group level ACLs on the Master Group Settings
screen, available under Application Access : App Tunnels. For specific
procedures, see To specify ACLs for a master group, on page 6-19.
◆
For an entire resource-group
You define resource-group level ACLs on the Application Tunnels or
Web Application Tunnels tabs, available from the Application Access :
App Tunnels : Resources screen. For specific procedures, see To specify
a resource-group level ACL, on page 6-20.
◆
Within specific favorites or aliases you define
You define favorite- or alias-level ACLs in the favorite or alias directly.
For specific procedures, see To specify ACLs for favorites or aliases, on
page 6-20.
One FirePass controller session for a user shares all ACLs you define for the
master group that contains the resource groups, those for all static and
dynamic App Tunnels and web application App Tunnels in a specific
6 - 17
Chapter 6
resource group, and ACLs you specify for favorites or aliases within a
resource group. For a description of ACLs, see Understanding access
restrictions for App Tunnels, on page 6-5.
Important
For App Tunnels, if you do not specifically allow acess, the system disallows
it.
Specifying ACLs
When you specify an ACL, you use a specific format, consisting of various
elements. This section describes each element of an ACL and presents
specific examples of how to define an ACL entry in the list.
When you specify an ACL, use the following format:
hostname:port | :port_range
ip_address/mask:port | :port_range
Separate each entry with a return. Separate multiple ports and port ranges
with a comma. If you do not specify a port or range of ports, the system
allows access from every port.
◆
hostname or ip_address
Represents the host name or IP address that you want the user to have
access to, for example:
siterequest.com
192.168.200.216:80-8080
You can use the asterisk when specifying hostname. The asterisk
matches any number of characters, for example:
*.siterequest.com:80
*.site*quest.com:23,80,443
*.siterequest*:23-25
You cannot specify a protocol or a URI in any ACL.
◆
mask
Represents the subnet mask for the IP address, specified as a number of
bits or in dotted-quad notation, for example:
172.30.11.0/24:80,443
172.30.11.0/255.255.255.0:1-65535
◆
port or port_range
Represents one or more port numbers, ranges of ports, or a combination
of individual ports and port ranges, specified in accordance with the
following guidelines:
• Every port number or range is a number from 1 through 65535.
• The port range is represented by a dash between two ascending
numbers, for example, 1-10 or 500-600.
• Each instance of a port or port range is separated by commas.
6 - 18
• No instance of a port or port range overlaps another, that is, one
specified port or port range cannot be contained in another port range,
so it is not valid to specify 24,22-25.
• You must specify port numbers in ascending order, for example:
www.siterequest.com:22-25,80,443
• If you do not specify a port, the system substitutes a port range of
1-65535, which represents all ports.
Important
If you specify a fully qualified domain name (FQDN) as the host name in the
ACL, the user must specify the FQDN to access the host.
To specify ACLs for a master group
1. In the navigation pane, click Application Access, expand App
Tunnels, and click Master Group Settings.
The Master Group Settings screen opens with the Common tab
active.
2. From the Master Group list near the upper left of the screen, select
the master group you want to affect.
The screen changes to reveal the existing App Tunnels defined for
the selected master group.
3. In the Allow List box in the Access Control List area of the screen,
type the host name or IP address you want the client to be able to
access. For example:
Separate multiple entries with a return. Separate multiple ports and
port ranges with a comma. If you do not specify a port or range of
ports, the system allows access from every port. For more
information about ACL elements, see Specifying ACLs, on page
6-18.
4. Click Update.
Important
Make sure you click Update to save your ACLs. If you select a different
master group before you click Update, the system discards any ACLs you
have specified.
6 - 19
Chapter 6
You can specify ACLs on a per-resource-group basis.
To specify a resource-group level ACL
Tunnels, and click Resources.
The App Tunnels Resources screen opens with the Application
Tunnels tab active.
2. From the Resource Group list near the upper left of the screen,
select the resource group you want to affect.
the selected resource group.
3. In the Allow List box in the Access Control List area of the screen,
type the host name or IP address you want the client to be able to
access.
6-18.
4. Click Update.
Important
have specified.
ACLs specified at the resource-group level are combined with those set at
the master-group level. You can specify additional ACLs in the favorite or
alias itself.
To specify ACLs for favorites or aliases
The App Tunnels Resources screen opens with the Application
Tunnels tab active.
2. From the Resource Group list near the upper left of the screen,
select the resource group you want to affect.
the selected resource group.
3. Click the Add new favorite link to create a new favorite or alias.
For associated procedures, see To create an App Tunnel favorite or
alias, on page 6-7.
4. In the Allow List for the favorite or alias, specify the ACLs, for
example:
6 - 20
6-18.
5. Click Update.
Important
have specified.
ACLs specified at the favorite or alias level are combined with those set at
the resource-group level and the master-group level.
6 - 21
Chapter 6
Configuring master group settings for App Tunnels
You can specify master-group based settings that apply whenever a user
who belongs to a specific master group clicks a favorite in the App Tunnels
section of the webtop. You set master group settings on the Application
Access : App Tunnels : Master Group Settings screen. The screen provides
two tabs: Common and Dynamic Tunnels/Web Application Tunnels.
Understanding common master group settings for all App Tunnels
General master group-based settings for App Tunnels govern the App
Tunnels type of Application Access connections. You can find general
master group settings on the Common tab on the Application Access : App
Tunnels : Master Group Settings screen.
On the Common screen, you can specify the following master-group-based
settings.
◆
Show administrator-defined favorites only
Restricts client access to App Tunnels that are defined and listed in the
favorites section of the user’s webtop. When you clear this check box,
the system removes the Direct Connect link from the user’s webtop as
well as prevents users from creating their own favorites.
◆
Use gzip compression
Compresses all traffic between the client and the FirePass controller,
using the gzip deflate method.
◆
Auto-logon to applicable AppTunnels using FirePass user logon
credentials
Allows logon using the FirePass controller logon credentials. Use this
option when users’ FirePass controller name and password match their
Windows logon credentials. This feature permits the user to access a file
share without having to logon again.
◆
Access control list
Restricts user access to host and port combinations specified. For more
information about specifying ACLs for master-group-level access
restriction, see To specify ACLs for a master group, on page 6-19.
For general information about master groups, see Introducing master groups
and resource groups, on page 2-1.
Configuring Customization settings on the Master Group Settings screen
Settings in the Customization section affect all App Tunnels types of
Application Access connections in the master group specified in the Master
Group list at the top of the screen.
• Present the user with a message box after successfully creating Static
Tunnel
Lets the user know that the static App Tunnel was successfully created.
6 - 22
• Minimize window after successfully creating Static Tunnel
Minimizes the user's App Tunnel control window after the App Tunnel
opens.
• Use Tray icon instead of Taskbar entry when minimized
Minimizes the connection window as an icon in the Windows system
tray. By default, when a user establishes an App Tunnel, the FirePass
controller displays a connection window to users notifying them that they
have successfully established a connection. When you enable this
feature, the system closes the window and shows the connection as an
icon in the Windows system tray at the lower right of the Taskbar. Users
can use the icon in the Windows system tray to restore or maximize the
connection window, or to terminate their connection.
• Do not show remote server address in AppTunnel window
Cleans the user’s URL so that the actual server address does not appear
in the browser’s address field.
Configuring settings for the AppTunnels webifyer status in the group
‹groupname› section of the Master Group Settings screen
The final section of the Master Group Settings screen contains a message,
for example:
AppTunnels is presented at the Beginner level, always visible to a user
in the group <groupname>.
The User Experience screen, accessible by clicking Click to change the
status and/or webifyer position on the webtop, provides some options for
customizing what the user sees.
Understanding master group settings for dynamic and web
application tunnels
You can use options on the Dynamic Tunnels/Web Application Tunnels tab
of the Master Group Settings screen to configure split tunneling. Split
tunneling of traffic provides control over exactly what traffic is sent over the
App Tunnel connection to the internal network and which is not.
Configuring split tunneling results in better client application performance
by allowing direct routing of connections destined for the public Internet,
rather than routing the request through the App Tunnel and then out to the
public Internet.
You can set options on the Dynamic Tunnels/Web Application Tunnels
screen for each master group. To specify the master group you want to
affect, select the name from the Master Group list at the upper left of the of
the screen.
6 - 23
Chapter 6
The Dynamic Tunnels/Web Application Tunnels screen contains the
following options:
◆
Force all traffic through tunnel
Sends all traffic to or from the local subnet through the dynamic and web
application tunnels.
◆
Use split tunneling for traffic
Routes through dynamic and web application tunnels only the traffic that
meets the specified criteria.
When you select this feature, the screen refreshes to reveal additional
options:
• DNS address space
Provides a list of names describing the target local network DNS
addresses.
Some applications use the FirePass controller DNS server settings for
hosts in the DNS address space, and the local client DNS server for
others. You can elect to use the DNS servers specified on the DNS
tab, available on the Device Management : Configuration : Network
Configuration screen, or you can specify which DNS server to use, in
the DNS address space box. You can use spaces to separate multiple
items. DNS address space supports the asterisk, which represents any
number of characters, for example, type the following to help the
application determine which DNS server to use for resolving a host
name:
*.sales.siterequest.com *.engineering.siterequest.com
• LAN address space
Provides a list of addresses or address/mask pairs describing the target
LAN.
When using split tunneling, the system passes through the configured
tunnel only the traffic to these addresses and network segments, and
traffic to any hosts specified in DNS address space. You can use
spaces to separate multiple items. You can use the following format to
configure this option:
192.168.10.0/255.255.255.0
192.168.10.0/24
192.168.10.0/24 192.168.20.0/24
When you finish specifying entries in DNS address space and LAN
address space, make sure you click the Update button. If you make
changes, and then select a different master group from the Master Group
list before clicking the Update button, the system discards the changes.
6 - 24
Understanding Legacy Host connections
You can configure access to legacy, or green screen, systems on
mainframes, and other traditional text consoles, using the Legacy Hosts
option. To set master-group-level policies and behaviors, use the
Application Access : Master Group Settings screen. For more information,
see Configuring master group settings for terminal server connections, on
page 6-32.
The Application Access : Legacy Hosts feature supports the following
terminal types:
• Tn3270, 80x24 in Java
• Tn3270, 80x32 in Java
• Tn3270, 80x43 in Java
• Tn3270, 132x27 in Java
• Tn5250, 80x32 as ActiveX control
• Tn5250, 132x27 as ActiveX control
• Vt-100 Telnet in Java
• Vt-100, 80x25 in Java
• Vt-100, 80x32 in Java
• Vt-100, 132x24 in Java
• Vt-100,132x32 in Java
• Vt-220, 80x25 in Java
• Vt-220, 80x32 in Java
• Vt-220, 132x24 in Java
• Vt-220, 132x32 in Java
• Vt-320 HTML
• Vt-320, 80x25 Telnet in Java
Password-based SSH connection (v2.0) is optional. You can find additional
information in the online help for the Application Access : Legacy Hosts :
Resources screen.
6 - 25
Chapter 6
Defining legacy host favorites
You can create favorites for legacy host connections. A favorite is a named
and saved set of options. A favorite appears as a link on the user’s webtop.
When a user clicks the link, the system establishes a connection to the
legacy host configured.
To create a Legacy Host favorite or alias
1. In the navigation pane, click Application Access, and click Legacy
Host.
The Application Access : Legacy Hosts : Resources screen opens.
• Favorite: Represents a new connection definition.
To create a new favorite, select Favorite, and skip to step 5.
different group. If there are no other groups available, or no other
connections have been defined, the Alias option is not available.
options. Continue with these steps:
a) From the From group list, select the resource group containing
the existing favorite you want to use as the source.
b) From the Favorite list, select the favorite.
c) Click the Add New button.
The new Alias appears in the list.
5. To continue creating a new favorite, in Name, type the identifying
label you want to use.
The FirePass controller displays this name as a label for the Legacy
Host favorite in the user’s web browser.
6. In Host, type the legacy host for the connection.
7. In Port, type the port you want the connection to use.
8. Check the Use SSH check box to use SSH, or leave the box empty.
9. Check Open in a separate window to have the connection open in
a new instance of the browser window.
Note: This option is always on for 5250 sessions.
10. From the Term-type list, select the type of terminal the connection
is for,
11. In Session name, specify the name for the terminal session.
Note: Session name is available for 5250 sessions only.
6 - 26
12. Check the Keep Alive check box to prevent the session from
ending, or leave the box empty to permit the sessions to end.
Note: Session name is available for 5250 sessions only.
13. From the Column separators list, select the type of column
separators for 5250 terminals.
14. From the Default charset list, select the character set to use for the
session. The FirePass controller provides several choices:
• DEC Supplemental Graphic Set
• MS-DOS Codepage 850 (Multilingual Latin 1)
• IBM Codepage 850
• ISO 8859-1 (Latin-1)
• Unicode
15. From the 3270 language list, select the language supported by the
3270 terminal.
16. From the Default font size list, select the default font size to use for
Java-based terminals.
17. From the Unicode encoding list, select the encoding. The FirePass
controller provides several choices:
• UTF-8
• UTF-16 little-endian
• UTF-16 big-endian
• UTF-32 little-endian
• UTF-32 big-endian
You can change any of these settings by clicking the link representing the
favorite, modifying the setting, and clicking the Update button.
Configuring legacy hosts keyboard mapping
A keyboard map contains mapping instructions for associating one
keystroke or key sequence on the client, to another keystroke or key
sequence. For example, you can map Esc+Shift+1 to the F1 key if the client
keyboard does not have function (F) keys on it.
6 - 27
Chapter 6
The FirePass controller provides default keyboard mappings for the listed
terminal types. However, you can override one or all key mappings. Using
keyboard mapping, you can customize legacy hosts favorites to use
non-standard keyboards or other code pages, and to add custom commands
and shortcuts.
The Legacy Hosts Keyboard Map section of the Legacy Hosts screen
contains the table of defined keyboard mappings that becomes the default
for the legacy hosts favorite you are configuring. You can debug user-side
keyboard mapping issues for specific devices and sessions by specifying a
keystroke in the table, and then invoking that keystroke when connected to a
legacy hosts session.
To modify or add to the mapping table
1. In the navigation pane, click Application Access, and click Legacy
Hosts.
The Legacy Hosts : Resources screen opens.
2. From the list to the left of the Load button, select the terminal type
you want to configure a keyboard map for.
3. Click the Load button.
The FirePass controller loads the saved mapping table into the box.
If no saved table exists, the FirePass controller uses the default
mapping table.
4. Edit the table as needed to override the mappings you need to
change, or to add key sequences to be translated into application
commands. For more information about the structure of the
mapping table, see Understanding the mapping table, following.
5. When you specify the settings you want, click the Save button.
Understanding the mapping table
Each line in the keyboard mapping table list contains one mapping rule for a
single key. You can type directly in the table to specify entries. The first
column in the table contains any modifiers, which represent the Ctrl, Alt,
and Shift keys on the keyboard. The second column contains the key, such
as F12 or Tab. The third column contains the action command. The first and
second columns must be separated only by blank spaces. At least one tab
character is required between the second and third columns. You can omit
content in the first and second columns to create a map for modifiers only,
or for keys only.
Commands are specific to one application or terminal type. You can supply
command arguments within the parentheses. A command with no arguments
ends with an pair of empty parentheses.
The default keyboard mapping contains default commands for standard
terminal types. You can add commands that act as application shortcuts.
These shortcuts can send commonly-used strings to your host applications
using the Send("String") command.
6 - 28
For example, if you want a specific key combination to send a text
command plus a program function key whenever the user presses Ctrl and
Alt and Shift and F12, the mapping rule might look like this:
Ctrl+Alt+Shift
F12
Send("MY COMMAND"); PF1();
You can find additional information in the online help for the Application
Access : Legacy Hosts : Resources screen.
Configuring master group settings for legacy hosts connections
who belongs to a specific master group clicks a favorite in the Legacy Hosts
section of the webtop. You set master group settings on the Application
Access : Legacy Hosts : Master Group Settings screen.
Understanding general master group settings for legacy host connections
General master group-based settings for legacy host connections govern the
legacy host type of Application Access connections. You can specify the
following master-group-based settings.
• Limit Legacy Hosts Access to Favorites only (for Extranets, partner
and customer access, etc.)
Removes the Direct Connect link from the user’s webtop, and prohibits
the user from creating custom favorites, which limits client access to
Legacy Hosts that are defined and listed in the favorites section.
• Restart the Legacy Hosts Server
When clicked, restarts a subsystem on the FirePass controller.
Configuring settings for the Legacy Hosts webifyer status in the group
‹groupname›section of the Master Group Settings screen
for example:
Legacy Hosts is presented at the Beginner level, always visible to a user
in the group <groupname>.
status and/or webifyer position on the webtop, provides a some options
for customizing what the user sees.
6 - 29
Chapter 6
Configuring terminal server favorites
You can create favorites for terminal server connections. A favorite is a
named and saved set of options. A favorite appears as a link on the user’s
webtop. When a user clicks the link, the system establishes a connection to
the terminal server configured.
You can provide users access to internal Microsoft Terminal Servers,
Windows XP® desktops, Citrix MetaFrame® servers, and VNC servers. To
specify group-level settings for Terminal Servers, use the Application
Access : Terminal Services : Master Group Settings screen. For more
information, see Configuring master group settings for terminal server
connections, on page 6-32.
To create a Terminal Servers favorite or alias
1. In the navigation pane, click Application Access, expand Terminal
Servers, and click Resources.
The Application Access : Terminal Servers : Resources screen
opens.
4. From the Type list, select from the following types.
• Favorite: Represents a new terminal server connection.
To create a new favorite, select Favorite, and skip to step 5.
different group. If there are no other groups available, or no other
connections have been defined, the Alias option is not available.
options. Continue with these steps:
a) From the From group list, select the resource group containing
the existing favorite you want to use as the source.
b) From the Favorite list, select the favorite.
c) Click the Add New button.
The new Alias appears in the list.
5. To continue creating a new favorite, in Name, type the identifying
label you want to use.
The FirePass controller displays this name as a label for the favorite
under Terminal Servers in the user’s web browser.
6. In Host, specify name or IP address.
You can enter a list here for MetaFrame and VNC hosts. The
FirePass controller shuffles the entries, then tries to use the first one
in the list. If connection fails, the FirePass controller tries the next
one in the list, and so on, until a working server is found. You can
use this simple technique for high availability solutions.
6 - 30
7. In Port, type a number to use for the port.
To automatically populate Port with the appropriate default value,
select from the adjacent list. Options are:
• Microsoft Terminal Server - default value 3389.
• Citrix MetaFrame - default value 1494.
• VNC - default value 5900.
• Citrix MetaFrame Browser - default value 80.
This option is useful for accessing Citrix server farms, and for
resolving application names to IP:port.
• Citrix MetaFrame Portal
Populates Port with the value 80.
This option provides functionality similar to Citrix NFuse web
portal. In this case, the FirePass controller contacts the Citrix
master browser using the supplied user credentials, and obtains a
list of published applications configured for that specified user.
Note: Citrix MetaFrame Browser relies on the Citrix XML Service,
which must be enabled on the target server.
8. In Select a program, type the full path to the application on the
target server to limit terminal access to a single program, restricting
access to the whole system.
For Citrix, always precede the application name with a pound sign
( # ) for published applications, for example, #app_name
This can be a path to Clarify on the Crete MS Terminal Server.
9. In Working Dir, specify the working directory for the application
you specified in the preceding step.
10. Check the Open in new window check box to have the favorite run
in a new browser window, or leave the box clear to have the favorite
to run in the current browser session, replacing content of the user’s
webtop.
11. Check the Redirect local resources (drives, printers, COM ports)
check box to have the target server’s local resources available to the
client after the application starts, or leave the box clear to have users
retain the resources on their computers.
12. In Encryption (Citrix-only), select the encryption level for Citrix
MetaFrame connections.
This setting specifies an internal Citrix parameter, which must
match the MetaFrame server setting. Connection from the client to
the FirePass controller is made using SSL, regardless of this setting.
Options are:
• Basic
This is the default.
• RC5 128 bit-logon only
• RC5 40 bit
• RC5 56 bit
• RC5 128 bit
6 - 31
Chapter 6
13. From Color Depth, select the number of colors the display on the
target server supports. Options are:
• 16 Colors
• 256 Colors
This is the default.
• High Color (16 bit)
• True Color (24 bit)
• True Color (32 bit)
You can change any of these settings by clicking the link representing the
favorite, modifying the setting, and clicking the Update button.
Configuring master group settings for terminal server connections
who belongs to a specific master group clicks a favorite in the Terminal
Servers section of the webtop. You set master group settings on the
Application Access : Terminal Servers : Master Group Settings screen.
When you enable master group policy routing for a particular master group,
you should not allow users of the master group to create terminal server
favorites for accessing servers that are not part of the VLAN defined for that
master group.
Understanding general master group settings for terminal server
connections
General master group-based settings for terminal server connections govern
the terminal server type of Application Access connections. You can specify
the following master-group-based settings.
• Screen resolution
Sets the initial screen resolution for Terminal Servers and Citrix
MetaFrame content, which users can override. Although users can
change screen resolution if they wish, you should set the initial resolution
sufficiently large to accommodate the application window. For example,
if you select 640x480, users cannot start Ethereal® applications because
there is no access to the OK button.
6 - 32
• Limit Terminal Servers Access to Favorites only (for Extranets,
partner and customer access, etc.)
Removes the Direct Connect link from the user’s webtop, and prohibits
the user from creating custom favorites, which limits client access to
Terminal Servers that are defined and listed in the favorites section.
• Auto-logon to applicable Terminal Services using FirePass controller
user logon credentials
Uses the user’s FirePass controller user name and password to access
Terminal Servers. You can also enter an optional domain or workgroup
name for the FirePass controller to use when users log on to Terminal
Servers. In situations in which the user’s FirePass controller user name
and password match the Windows Domain credentials, this feature
permits the user to access a Terminal Servers connection without having
to logon again.
Citrix ICA client location
The FirePass controller dynamically loads the Citrix client onto the user’s
system, at runtime. If your site requires a version of the Citrix Web Client
that is different from what the FirePass controller provides, you can use the
options described in this section to specify the location of the Citrix client to
be downloaded. You can specify this setting on the Application Access :
Terminal Servers : Master Group Settings screen.
◆
Embedded
If the end-user does not have a Citrix client installed, or if the installed
version does not match the number displayed in the Version box,
downloads and installs the Citrix client supplied on the FirePass
controller.
◆
Citrix web-site
version does not match the number displayed in the Version box, obtains
the client from the Citrix web site. You can also specify the target
version number you want to download.
◆
Custom URL
version does not match the number displayed in the Version box, obtains
the client from the location entered. You can specify the source URL and
the target version number you want to download.
Configuring keyboard redirection for Microsoft Terminal Servers
The keyboard redirection setting specifies how and when to apply Windows
key combinations, for example, Alt+Tab. On the Master Group Settings
screen for Application Access, you can configure to apply key combinations
only locally on the client computer, always, and only when the client is
running in full-screen mode.
6 - 33
Chapter 6
Table 6.1, following, presents the Microsoft Terminal Servers shortcut keys
that this setting affects.
Key combination
Description
Alt+Page Up
Switches between programs from left to right.
Alt+Page Down
Switches between programs for right to left.
Alt+Insert
Cycles through the programs in the order they were started.
Alt+Home
Displays the Start menu.
Ctrl+Alt+Break
Switches the client between window and full-screen mode.
Ctrl+Alt+Break is F12 on NEC98.
Ctrl+Alt+End
Brings up the Windows Security dialog box.
Ctrl+Alt+End is F15 on NEC98.
Alt+Delete
Displays the Windows menu.
Ctrl+Alt+minus ( - )
Places a snapshot of the active window, within the client, on
the Terminal Server clipboard (provides the same
functionality as pressing Print Scrn on the local computer).
Ctrl+Alt+plus ( + )
Places a snapshot of the entire client windows area on the
Terminal Server clipboard (provides the same functionality
as pressing Alt+Print Scrn on the local computer).
Table 6.1 Microsoft Terminal Servers shortcut keys
Configuring Terminal Servers webifyer status in the group ‹groupname›
section of the Master Group Settings screen
for example:
Terminal Servers is presented at the Beginner level, always visible to a
user in the group <groupname>.
status and/or webifyer position on the webtop, provides a some options
for customizing what the user sees.
For information on how to set User Experience options, see the online help
for the User Experience tab, available on the Users : Groups : Master
Groups screen.
6 - 34
Configuring global settings for Application Access
You can configure global settings that apply to all Application Access
connections. You set global settings on the Application Access : Global
Settings screen.
Handling Windows power-management events
You can select one of the following power-management settings to apply to
Windows-based App Tunnels, Terminal Servers, and the ActiveX version of
5250 Legacy Hosts Access. This setting specifies what should occur when
Windows enters the standby, or hibernate, mode.
• Do nothing: Ignore power management events
• Prevent Windows from entering standby/hibernate mode while a
connection exists
• Terminate connection if Windows enters standby/hibernate mode
Configuring client messages for Windows loopback
There is an issue introduced in Windows XP SP2 in which an error occurs
when attempting to connect to IP addresses in the loopback range. You can
read more about the issue by clicking the KB884020 link on the Application
Access : Global Settings screen.
The FirePass controller displays a message when it encounters a computer
that has not received the loopback fix. By default, the FirePass controller
displays the following message:
Your computer requires an update to run this application. Click here
or enter the following link into your web browser to install the required
update from Microsoft (KB884020).
http://support.microsoft.com/default.aspx?kbid=884020
You can change the message by modifying the text in the box in the
Customization section, and clicking the Update button. The message can
contain any valid HTML.
6 - 35
Chapter 6
6 - 36
7
• Introducing Portal Access
• Configuring web applications on the FirePass
controller
• Configuring Windows files
• Configuring Mobile E-Mail
• Configuring content inspection
Introducing Portal Access
Portal Access connections enable end users to use a web browser to access
specific services on the internal network. With Portal Access, the FirePass
controller communicates with back-end servers, and translates the content
into HTML pages for the client browser. The advantage is that the client
computer requires no client software other than a browser application.
This method of access differs from connections configured for Network
Access and App Tunnels, which provide direct access from the client to the
internal network. These technologies do not manipulate or analyze the
content being passed between the client and the internal network. These
technologies do require small, automatically installed client components,
but provide the most seamless direct access to internal applications. Portal
Access configuration provides an administrator refined control over the
applications that a user can access through the FirePass controller, as well as
inspection of contents of transferred data.
For more information on connections configured for Network Access and
App Tunnels, see Chapter 5, Configuring Network Access and Chapter 6,
Configuring Application Access.
The other advantage of Portal Access is security. Because Network Access
and App Tunnel connections communicate directly with the server, client
connections must come from a trusted computer. Publicly available
workstations do not meet this requirement. However, even though a
workstation does not meet those requirements, your users should still be
able to access certain applications.
In Portal Access connections, the client computer itself never communicates
directly with the end-point application. That means that all communication
is inspected at a very high level, and any attacks originating on the client
computer fail because the attack cannot navigate through the links that have
been rewritten by reverse proxy. In Portal Access connections, the FirePass
controller communicates with the back-end servers, and then generates the
HTML page for presentation in the browser window.
Introducing Portal Access features and operation
Portal Access provides remote users with web-based remote access to a
wide variety of network applications and resources, including:
• Intranet web servers
• Email servers
• Windows file servers
• Terminal servers
• Legacy, character-based applications.
7-1
Chapter 7
Portal Access serves the internal resource into and out of the end user’s web
browser. The application being accessed and the protocol being supported
(HTTP and HTTPS) dictate how Portal Access operates. Figure 7.1,
following, shows the process that Portal Access follows.
Figure 7.1 The Portal Access functionality of the FirePass controller
Introducing Portal Access application support
You can use Portal Access when users need access but they are away from
their regular computers. FirePass provides additional functionality to secure
connections from client machines, such as public kiosks or PDAs, which
might not have the necessary applications installed or configured, but
usually do have browsers installed. In this case, the web browser serves as
the interface to the application.
You can set up different types of access for users in different master groups.
For example, you can enable Windows Files access to users from one master
group, and prevent access by users in another master group. In addition, you
can enable browsing of internal web sites by name or IP address, which
would be typical for employees, or limit access only to specified favorites,
which would be useful in an extranet for partners and customers.
7-2
Using Web Applications
Web Applications access allows remote users secure access to internal web
servers, such as Outlook Web Access (OWA), Microsoft SharePoint, IBM
Domino Web Access (also known as Lotus iNotes), Domino Sametime, and
Citrix NFuse. Using Web Application functionality, you can also provide
access to most web-based applications and internal web servers. Portal
Access provides access to web applications by performing an intelligent
proxy of the content through the FirePass controller, so it changes all links
to reference the FirePass controller address, rather than the originating
server. The high performance, full-content rewrite engine also supports
rewriting complex JavaScript™, Java™ applets, and Flash® content. You
can use features such as the web cache, minimal content rewriting bypass
mode, user-defined content processing scripts, and a number of others, to
help refine compatibility and tune performance.
Using Windows Files
Windows Files access allows remote users browser-based access to browse,
upload, download, move, copy, or delete files in shared directories. The
FirePass controller communicates with file servers using the Server
Message Block (SMB) protocol, which can support Windows 2003,
Windows 2000, Windows for Workgroups, Windows NT 4.0.
Using Mobile E-Mail
Mobile E-Mail access provides very lightweight access to POP/IMAP and
SMTP email servers and LDAP address books using a standard web
browser, or mini browsers on a PDA or smart phone. Users can send and
receive messages, download attachments, and attach files from the internal
LAN to send email messages. Mobile E-Mail is intended to complement a
fat client by optimizing content for low bandwidth, mobile devices.
Using Content Inspection
Content Inspection scans URL arguments and POST data sent by users
through Web Applications, and blocks the request if it appears as if it might
be an attack. Content Inspection guards against cross-site scripting attacks,
SQL injection attacks, buffer overflow attacks, and viruses from files
uploaded using Windows Files, Web Applications, or Mobile E-mail.
7-3
Chapter 7
Configuring web applications on the FirePass
controller
You can configure the FirePass controller to provide access to web
applications without requiring client configuration changes or software
downloads. Typically, you use Portal Access when your users only require
access to specific internal web portal-based applications, and do not require
full Network Access. The FirePass controller provides security by rewriting
links in all requests to internal servers. When the FirePass controller
processes the connections, it uses the proxy engine’s built-in logic and
additional custom-configurable content-processing scripts to modify the
URLs and other links in the original HTML document. The controller
changes these links by rewriting the path to the URL. You can use stream
editor (SED) scripts to modify intranet web pages to handle issues related to
the FirePass controller sending custom content through the proxy engine.
F5 Networks has tested the following web applications to ensure that the
FirePass controller handles them without client reconfiguration.
• Microsoft Outlook Web Access (OWA)
• Microsoft SharePoint
• IBM Lotus Domino Web Access (also known as Lotus iNotes)
• Domino Sametime
Some of your custom web applications will work with Portal Access without
you having to make changes to the applications. However, some of your
web applications, particularly those that make extensive use of JavaScript,
Java applets, ActiveX controls, and Flash components, might require that
you use content processing scripts or other configuration changes to enable
the user to access them using Portal Access connections.
If you have a specific web application that requires additional configuration
to work through Portal Access, you can generally use Application Tunnels
or Network Access. These access methods provide a direct connection to the
internal network, and do not require proxy-based changes or modification of
web application content.
If you cannot use Application Tunnels or Network Access to solve access
issues, you can try the proxy feature Minimal Content-Rewriting Bypass.
For more information about this feature, see Configuring web applications
for minimal rewriting, on page 7-10.
7-4
Understanding proxy and cache functionality
You can use the FirePass controller Portal Access : Web Applications
feature for the following operations:
• Rewrite of complex HTML, JavaScript, Java applets, and Flash content
• Dynamic cache of rewritten content
• Extensive bypass configuration and content pre-processing and
post-processing using scripts
The FirePass controller uses a high-performance, full-content rewrite engine
to handle complex HTML, JavaScript, Java applets, and Flash. You can also
enable a built in dynamic cache, so that the FirePass controller does not have
to repeatedly rewrite content for static objects such as HTML, JavaScript,
style sheets, and Java applets. Also, the web applications engine supports
rewrite of complex applets such as Citrix, VNC (when presented by Java
applets), as well as .jar and .cab archive resigning.
In some cases you might want to bypass the FirePass controller’s reverse
proxy to support some very complex web applications using the Minimal
Content-Rewriting Bypass feature. To use this feature, your applications
must reside on the single target server. When you use the bypass feature, the
proxy engine operates differently.
With the bypass feature, the proxy engine:
• Uses the FirePass controller name to replace only the originating host
name in the address. If the URL also contains a port, then the proxy
engine replaces the host name and port with the FirePass controller name
and port.
• Does not rewrite URL references to other servers
• Does not modify cookies, when you enable the global setting, cookie
pass through.
• Applies minimal content settings at the master group level
You can use the bypass feature by configuring a one-to-one mapping
between one of the following options:
• A URL pattern and an internal intranet host
• A dedicated FirePass Web service on an alternate port or IP address, and
an internal host
You can use SED scripts to rewrite output instead of preventing rewriting by
configuring bypass. For information about Web application content
processing using SED scripts, see Configuring content processing for web
applications, on page 7-18.
Setting cookie availability for web bypass
In some cases, for example, if your web application manipulates a client
cookie, you want the FirePass controller to pass the cookie to the browser
without altering it.
7-5
Chapter 7
To specify cookie pass through
1. In the navigation pane, click Portal Access, expand Web
Applications, click Content Processing, and click the Global
Settings tab.
The Content Processing : Global Settings screen opens.
2. Scroll down to the Web Applications Global Settings section.
3. Check the Do not block cookies at FirePass, pass them to the
browser for specified URL patterns check box.
4. In the box, specify the list of URLs or URL patterns you want the
FirePass controller to ignore when performing proxy operations.
5. To have the FirePass controller add URLs from sites that require
cookie manipulation, check the Automatically add websites that
require client side cookie manipulation check box.
6. Click Update.
Defining favorites for Portal Access Web Applications access
To make Portal Access Web Applications available to users, you create
favorites to internal web sites and URLs. A favorite is a collection of
settings that represents a single link on the user’s webtop. When the user
clicks a Portal Access Web Application favorite, the FirePass controller
opens the connection and runs the configured application.
Note
Understanding Portal Access favorites options
You add new favorites using the Portal Access : Resources screen. To
access the screen, in the navigation pane, click Portal Access, expand Web
Applications, and click Resources. When you click the Add new favorite,
link, the screen reveals additional options.
• Type
Indicates whether the link is a new configuration (Favorite) or a pointer
to an existing one in another master group (Alias). Alias is available as
an option only when there are Portal Access favorites configured in
another resource group.
• Name
Contains the name for the intranet site that you are defining as a favorite.
This is the name the user sees on the webtop. The string you specify can
be any name; field format is not limited. For example:
Site Request application
7-6
• Web Application Type
Specifies web servers as generic, Microsoft Outlook Web Access (OWA)
or IBM iNotes. For OWA and iNotes, Portal Access automatically
selects the optimal caching and compression settings.
• URL
Indicates the intranet web server that serves the application. For example:
http://server.siterequest.com/index.html
• URL variables
Contains variables to be either appended to the GET request or sent as
data in a POST request to the specified URL. For more information and
examples, see Working with URL variables, following.
• Post URL variables
Indicates that you want the variables in URL variables to be included in
the POST request to the URL specified. For more information and
examples, see Working with URL variables, following.
• Enforce user-agent
Contains the string you want the FirePass controller to send to the
internal web server instead of the browser’s actual user-agent identifier.
For more information, see Specifying user-agent strings, on page 7-8.
• Open in new window
Indicates whether the application opens in the existing browser window
or in a new browser window.
Check this option to open the application in a new window, or leave the
option cleared to have the application replace the user’s webtop.
• Endpoint protection required
Provides a list of Protected Configurations defined on the Users :
Endpoint Security : Protected Configurations screen. If the user’s
endpoint protection does not satisfy the defined condition, the FirePass
controller does not include this favorite on the webtop or allow access.
Once you have configured all of the necessary parameters for your
application, click the Add New button to add the favorite. When you have
configured at least one favorite, you can specify which link serves as the
default by selecting it from the Default box, and clicking Update.
The default favorite starts automatically when users of the resource group
open their web application favorites. With more than one default favorite
defined, for example, when a user has multiple resource groups assigned,
the FirePass controller starts only one of the defaults.
Working with URL variables
Although they are optional, you can use URL variables to support favorites,
such as automatic user logon to intranet web sites, or for customizing
intranet content for a user. You can use the %username% and
%password% variables as values in a GET request. At logon time, the
FirePass controller replaces the parameters with the user’s FirePass
controller user name and password.
7-7
Chapter 7
URL variables are specified in the form:
variable1=value1&variable2=value2&variable3=value3
The following is an example of how to build an intranet favorite that
contains a URL variable. First you specify the string in the URL box:
Then you specify the variables you want to use in the Url variables box:
show_custom_content=1&user=%username%&password=%password%
For FirePass controller user johndoe with password johndoepassword,
using these variables results in the following actual favorite link:
http://server.siterequest.com/index.html?show_custom_content=1&
user=johndoe&password=johndoepassword
Alternately, you can specify that the FirePass controller send the variables in
a POST request to the configured URL. This is a more secure way to
provide a user name and password for logging on to an intranet site, because
the variables are not visible on the URL line of the browser for someone to
see.
For example, if you have the following form contents on an intranet logon
page:
<form action=logon.php method=POST>
<input type=TEXT name=user>
<input type=PASSWORD name=password>
<input type=HIDDEN name=do_logon value=1>
<input type=SUBMIT value=Logon>
</form>
First, you specify the string in the URL box:
http://server.siterequest.com/logon.php
Then you specify the variables you want to use in the Url variables box:
user=%username%&password=%password%&do_logon=1
For FirePass controller user johndoe with password johndoepassword,
using these variables results in the following actual favorite link:
http://server.siterequest.com/logon.php
The FirePass controller sends the following data directly to the
server.siterequest.com site in a POST request:
user=johndoe&password=johndoepassword&do_logon=1
Specifying user-agent strings
The user-agent string identifies what the client’s web browser uses with a
specific network protocol. Some servers use the user-agent string to
determine what content to send to the client browser. Although optional,
specifying a user-agent string is useful when you need to simplify FirePass
controller content. For example, for a highly complex web application, it
might help to downgrade the content supplied by specifying the following
user-agent string:
7-8
Mozilla/4.7 [en] (Windows NT 4.0; U)
Table 7.1, following, contains a list of common user-agent strings.
Browser
User-agent string
IE 6.0 on Windows
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1)
IE 5.5 on Windows
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
IE 5.0 on Windows
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
IE 4.5 on Windows
Mozilla/4.0 (compatible; MSIE 4.5; Windows NT)
IE 4.01 on Windows
Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)
Mozilla 1.7.8 on
Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.8) Gecko/20050511
Netscape 7.2 on
Windows
rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Netscape 4.5 on UNIX
Mozilla/4.5 [en] (Win98; U)
Netscape 3.04 on UNIX
Mozilla/3.04Gold (Win95; U)
Opera 5 on UNIX
Opera/5.12 (Windows 2000; U) [en]
Opera 5 mimicking
Netscape on Windows
Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera
5.01 [en]
Safari 2.0 for Macintosh
OS X
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en)
AppleWebKit/412 (KHTML, like Gecko) Safari/412
FireFox 1.0.4 on the
Macintosh
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
FireFox 1.0.6 on
Windows
rv:1.7.10) Gecko/20050716 Firefox/1.0.6
FireFox 1.0.1 on Linux
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB;
rv:1.7.6) Gecko/20050222 Firefox/1.0.1
Table 7.1 User-agent strings for several browsers
Tip
An easy way to enter a user-agent string is to copy and paste the string from
the Logons report into the Enforce user-agent box. You can find the string
on the Reports : Logons screen in the User Agent column.
7-9
Chapter 7
Configuring web applications for minimal rewriting
You can use the minimal content rewriting feature to prevent rewriting of
your web application content. You can define minimal content rewriting
operation on the WebApplications : Master Group Settings screen.
There are several configuration requirements for using the Minimal
Content-Rewriting Bypass feature:
• The application must reside on a single server. The FirePass controller
cannot process URLs for separate servers when the Minimal
Content-Rewriting Bypass feature is enabled.
• You must configure cookie pass-through on FirePass controller in order
to use the Minimal Content-Rewriting Bypass feature if there is
client-side JavaScript that directly processes cookies.
• You cannot use automatic cookie pass-through with Minimal
Content-Rewriting Bypass.
You can configure the Minimal Content-Rewriting Bypass feature in only
one of two modes:
◆
Pattern-based
Provides a pattern-matching mechanism for URLs. You specify a
protocol, host, and path for the FirePass controller to match. If the
FirePass controller encounters a URL that has a defined Pattern-based
bypass rule, the FirePass controller does not modify URLs on the
returned page.
Implementing Pattern-based bypass requires no network changes, but
you must specify the protocol, host, and path that the application uses so
that the FirePass controller can match the incoming URLs.
◆
Alternative Host/Port-based
Provides a dedicated IP address and TCP port through which the FirePass
controller proxies connections to the application server. When
configuring the FirePass controller in Alternative Host/Port-based mode,
you must configure one FirePass controller port for each port the
application server uses. If your application uses SSL encryption, you
must also install on the FirePass controller the same SSL certificate and
private key that is installed on the application server.
Important
When you configure bypass, make sure to clear the box that enables
compatibility mode on the Global Settings screen. Minimal content
rewriting does not work in compatibility mode. To access the Global
Settings screen, in the navigation pane, click Portal Access, expand Web
Applications, click Content Processing, and click the Global Settings tab.
The option is Compatibility mode (enable legacy version of Web
Applications handler), and is provided to support web applications
configured using earlier versions (pre-5.4) of the FirePass controller
reverse proxy engine.
7 - 10
Note
The Minimal Content-Rewriting Bypass feature is available only if you have
the hotfix for FirePass 5.4.2, or if you are using FirePass 5.5 or later.
Configuring pattern-based bypass
Instead of having the FirePass controller reverse proxy rewrite URLs and
JavaScript, you can use the pattern-based bypass option. The pattern-based
bypass functionality replaces the target server name with a name you
specify, and processes requests based on the patterns you list. The pattern
searches are case-sensitive, so you might have to specify the same pattern in
upper- and lowercase. Patterns must be unique within the intranet to prevent
interference with other web applications.
When you use this feature, the FirePass controller replaces all references to
the target server’s protocol://address:port with the FirePass
protocol://address:port. For example, if a Web application consists of
URLs starting with /myapp/ and /myimages/, you would associate the
patterns /myapp/*,/myimages/* with the server. You must specify the
target server in the following form:
protocol://servername[:optional port]
An example target server is http://myserver
Important
The root directory of the server cannot be used as the pattern for the
pattern-based bypass mode, for example, you cannot specify http://, /, or /*.
You can find pattern-based bypass settings on the Master Group Settings
screen. To access the screen, in the navigation pane, click Portal Access,
expand Web Applications, and click Master Group Settings.
When you configure settings, first select from Master Group the master
group you want to have access to the application.
In the Minimal Content-Rewriting Bypass section, you can configure the
following options:
◆
Comma separated list of patterns
Contains a list of match patterns for the web application. In this box,
specify the application paths that you do not want the FirePass controller
to translate. Separate each directory with a comma.
For example, if you do not want FirePass to translate a set of URLs,
including all pages in the location:
https://tech.siterequest.com/appdir1/
https://tech.siterequest.com/appdir3/text.html
Type the following text:
/appdir1/*,/appdir2/*,/appdir3/text.html
7 - 11
Chapter 7
◆
http[s]://<IP Address/Name>[:Port]
Contains the target server. In this box, specify the protocol and host
portion of the URL for the application.
For example, if you do not want FirePass to translate the URL:
Type the following text:
https://tech.siterequest.com
You can specify a pattern using the wildcard characters asterisk ( * ), which
represents many characters, and question mark ( ? ), which represents a
single character. The patterns must be unique. When you specify a pattern,
you must include at least one subdirectory for each application.
Configuring the Alternative Host/Port-based type of bypass
The first step to configuring the Alternative Host/Port-based bypass type of
minimal content rewriting is to create a web service and enable WebAccess
Bypass. For information about creating web services, see Configuring web
services, on page 8-18. When you create the web service, if you want to use
the Alternative Host/Port-based bypass type of minimal content rewriting,
you check the WebAccess Bypass check box to indicate that the FirePass
controller uses the web service only for proxy pass-through operations. For
more information, see the following procedure.
Next, you configure alternative host/port-based minimal content-rewriting.
For more information, see Configuring web applications for minimal
rewriting, on page 7-10.
To enable WebAccess Bypass
Configuration, click Network Configuration, and then click the
Web Services tab.
2. From IP, select an available IP address to which users will connect
or create a new address using the IP Config tab.
3. Specify a port that is not already in use by another FirePass
controller web service.
4. Specify a host name.
If you add the host name to your DNS server, users can connect to
the application using the name of the host instead of having to use
the IP address.
5. Check the Enable SSL check box.
6. Click Add New.
The Web Service Configuration page opens.
7 - 12
7. From the Certificate list, select a certificate to use with the new
web service.
8. Check the WebAccess Bypass box.
Note: When you check the WebAccess Bypass check box, the
FirePass controller disables the user logon and administrator logon
to that service.
10. Click the Finalize tab.
11. Click the Finalize Changes button.
12. Wait while the finalize process completes.
13. If necessary, restart services.
Applications, and click Master Group Settings, to configure
Alternative Host/Port-based bypass options. For more information,
see Configuring Alternative Host/Port-based bypass, following.
Note
Depending on how your firewall is configured, if you specify a new port, you
might need to configure your firewall to allow communication on that port.
You might need to specify a new port if you have one internal side that
allows traffic through, or if you use servers outside the company on another
network (also known as one-armed configuration).
Configuring Alternative Host/Port-based bypass
When you use the Alternative Host/Port-based bypass feature, the FirePass
controller uses the proxy engine to make connections to the application
server through specified IP address and port combinations, and replaces a
specific internal host name with the name and port number you specify.
The Alternative Host/Port-based section on the Master Group Settings
screen contains a list of the web services with a checked WebAccess
Bypass option. The Alternative Host/Port-based section is empty if you
have not checked WebAccess Bypass for at least one existing web service.
In this case, the section contains a message, No Bypass Web Services
configured, along with a Click here to configure link that opens the
Device Management : Configuration : Network Configuration screen. From
there, you can add a new web service or configure an existing one by
checking Web Access Bypass on the associated Web Service Configuration
screen.
For a procedure of how to configure a web service for minimal-rewriting
bypass functionality, see Configuring web applications for minimal
rewriting, on page 7-10.
7 - 13
Chapter 7
In the box under Alternative Host/Port-based, type the URL for your
application, using the following format (where [ ] indicate optional values):
http[s]://<IP Address/Name>[:Port]
When you finish, make sure to click the Update button to have your settings
take effect.
Configuring NTLM and basic authentication proxy
NTLM uses a challenge-response mechanism for authentication, in which
clients prove their identities without sending the server a password. The
mechanism consists of three messages: Type 1, negotiation; Type 2,
challenge; and Type 3, authentication. Although Windows 2000 continues
to support the protocol, Microsoft Kerberos has replaced it as the standard.
You can enable NTLM and basic authentication proxy on the Master Group
Settings screen. To access the screen, click Portal Access, expand Web
Applications, and click Master Group Settings. The FirePass controller
supports sending through the proxy engine NTLM and basic authentication
over HTTP on behalf of the user, which provides several benefits:
• Prevents client browsers from caching basic or NTLM authentication
credentials.
• Allows client browsers not supporting basic or NTLM authentication to
authenticate against web sites requiring this, such as Microsoft Internet
Information Services (IIS).
• Allows automatic logon (single sign-on) to sites supporting basic or
NTLM authentication with user's FirePass credentials.
There is a security implication to running the FirePass controller without
checking the Proxy Basic and NTLM auth using FirePass user logon
form check box. The implication is that, depending on the application, after
logging off of an internal application configured for basic or NTLM
authentication, users might be able to regain access to the internal
application without entering logon information. This is because web
browsers commonly cache basic or NTLM user credentials.
When you configure the FirePass controller to send basic or NTLM user
credentials through the proxy engine, the controller replaces the basic or
NTLM browser dialog box with a form-based dialog box, which prevents
the web browser from caching user credentials.
NTLM and Basic Auth Proxy provides the following options:
◆
7 - 14
Proxy Basic and NTLM auth using FirePass user logon form
Indicates whether to use the FirePass controller to proxy HTTP basic and
NTLM authentication. If you enable this option, the FirePass controller
presents a user logon web form whenever a protected site needs logon
credentials. Basic and NTLM authentication proxying is enabled by
default.
◆
Auto-logon to Basic and NTLM protected sites using FirePass user
credentials
Controls whether the FirePass controller can pass along the user’s
FirePass controller logon credentials to automatically log on to protected
sites on the user’s behalf. If the user’s FirePass controller credentials do
not match those required for the protected site and you enabled Proxy
Basic and NTLM auth using FirePass user logon form, the FirePass
controller presents a user logon web form. Otherwise, the FirePass
controller presents an authentication dialog box. When you enable this
option, you can also configure the following options:
• NTLM Auth Domain (optional)
For protected sites requiring NTLM authentication, you can specify a
default domain to be used in conjunction with the auto-logon support.
• Basic Auth Domain (optional)
For protected sites requiring basic authentication, you can specify a
default domain to be used in conjunction with the auto-logon support.
When specified, this value is prepended to the user name during basic
authentication (for example: BASICDOMAIN\username).
Configuring split tunneling for Portal Access
You can define Portal Access split tunneling functionality on the Master
Group Settings screen. To access the screen, in the navigation pane, click
Portal Access, expand Web Applications, and click Master Group
Settings. You can use the split tunneling feature to specify which URLs
should be processed by the FirePass controller proxy engine and which
URLs should not. Split tunneling functionality helps:
• Improve controller performance by lowering processing overhead
• Make some web pages available (such as the performance-impacting
pages served by many public portal sites) that might not be compatible
with reverse-proxy technology
When you check Use URL patterns for split tunneling, the screen reveals
additional options.
◆
Rewrite
Contains a comma-separated list of patterns to compare with incoming
URLs. The FirePass controller proxies matching URLs. If the box is
empty, the FirePass controller rewrites all URLs. You can type an
asterisk ( * ) to specify that the FirePass controller rewrite all URLs.
◆
Bypass
Contains a comma-separated list of patterns to compare with incoming
URLs. URLs that match are accessed directly, bypassing the FirePass
controller reverse-proxy engine. If the box is empty, all URLs bypass the
reverse-proxy engine, meaning that rewriting is done for all URLs that
pass the test specified by patterns in the Rewrite box.
7 - 15
Chapter 7
You can use the wildcard characters asterisk ( * ), which represents many
characters, and question mark ( ? ), which represents a single character, in
both the Rewrite and Bypass boxes. The FirePass controller first processes
all patterns in the Rewrite box, and then all patterns in the Bypass box.
Example: http://*.siterequest.com/*
The format requires a slash separator ( / ) between the host information and
the path. For example, you must specify: http://server.siterequest.com/*
instead of http://server.siterequest.com* or http://www.*/*.com* instead
of http://www.*.com* for the filter to work.
The split tunneling filters apply to favorites, to direct browsing, and to the
links within a rewritten page. If you enable split tunneling, the FirePass
controller presents only web pages that satisfy one of these filters. It blocks
the others (although a blocked public site might still be available outside the
webtop). If you do not use split tunneling, the FirePass controller processes
all URLs through the reverse-proxy engine.
Split tunneling patterns ignore any part of the URL after the first pound sign
( # ) or question mark ( ? ) symbol; that is, anchors and URL variables are
ignored.
Note
The Network Access feature also provides split-tunneling functionality. The
functionality is slightly different, however. For more information, see
Introducing Network Access, on page 5-1.
Understanding access control lists for Portal Access
You can configure Portal Access Master Group Settings so that users can
only access favorites that you define. Even if you do so, however, the page
represented by the favorite might contain links to other locations. To prevent
users from accessing other locations, you can specify access control lists
(ACLs), making available only particular web servers and pages. ACLs
define locations the Portal Access connection users can access from within
the connection. Defining ACLs prevents users from navigating to locations
outside the ones you specifically define for the Portal Access connections
that access your network.
All Portal Access connections share access control lists for the duration of a
browser session.
You can configure options in the following areas:
• On the Portal Access : Web Applications : Master Group Settings screen
• On the Portal Access : Web Applications : Resources screen
• In the Allow list box specific to the Portal Access favorite you define
The system uses ACLs in the following order:
• At the master group level
• Overrides from the resource group
7 - 16
• Overrides from the favorite definition
• The default action specified on the Master Group Settings screen
That means that ACLs defined on the Master Group Settings screen cover
the entire master group, but you can specify resource-level overrides on the
Resources screen. In addition, ACLs defined on the Resources screen cover
the entire resource group, but you can specify connection-specific ACLs in
the Allow list box for the favorite. Next, ACLs defined at the favorite-level
override all other ACLs. Finally, the system uses the default Allow or Deny
action specified on the Master Group Settings screen.
The FirePass controller processes ACLs in the following manner:
• The FirePass controller first processes all URL patterns specified in the
Deny list boxes on the Master Group Settings and Resources screens.
• If there is a match to an entry defined in the Deny list, the system denies
access to the URL.
• If the boxes are empty or if there is no match, the FirePass controller
passes processing to URL patterns specified in the Allow list boxes on
the Master Group Settings and Resources screens, and in the Allow list
box for the favorite.
• If there is a match to an entry, the system allows access. If the boxes are
empty or if there is no match, the system applies the action specified in
the Default action box on the Master Group Settings screen.
In the Deny list and Allow list boxes, you can specify one URL pattern per
line. You can use the wildcard characters asterisk ( * ), which represents
many characters, and question mark ( ? ), which represents a single
character, in both the Deny list boxes on the Master Group Settings and
Resources screens. Each URL filter must specify a complete protocol and
path.
For example, the following specifies two URLs containing wildcards:
http://www.*.com/*.html
http://www.*.com/*.php
http://www.*.com:80/*.php\?a=1&*
If you do not specify a port, the system allows access from all ports.
The format requires a slash separator ( / ) between the host information and
the path. For example, you must specify: http://server.siterequest.com/*
instead of http://server.siterequest.com* or http://www.*/*.com* instead
of http://www.*.com* for the filter to work.
Preserving host names
You can define which host names to preserve on the Master Group Settings
screen. You might want to prevent the replacing of host names with the
FirePass controller name if you want to provide access to a web application
that uses the host name for a specific purpose. For example, preserving the
host name is useful for web applications that have JavaScript code that sets a
cookie based on the actual server name in the browser.
7 - 17
Chapter 7
To access the Master Group Settings screen, click Portal Access, expand
Web Applications, and click Master Group Settings.
When you check Preserve FirePass hostname when accessing Web
Applications, the screen reveals a box. Into the box you can specify a
comma-separated list of patterns to match against URLs. You can use the
wildcard characters asterisk ( * ), which represents many characters, and
question mark ( ? ), which represents a single character, in the box. This
option instructs the reverse-proxy engine not to replace Host in the HTTP
headers.
If the box is empty, the FirePass controller replaces the host name on all
URLs. For example, using the typical reverse-proxy operation, the Host
value gets replaced, as shown in the following example:
Host: firepass.siterequest.com
(client to FirePass controller)
Host: company_server.siterequest.com
(FirePass controller to internal web application)
When you check the Preserve FirePass hostname when accessing Web
Applications check box, the FirePass controller delivers the Host header to
the internal web application without alteration, as Host:
firepass.siterequest.com.
Configuring content processing for web applications
You can define Portal Access content processing functionality on the
Content Processing screen. To access the screen, click Portal Access,
expand Web Applications, and click Content Processing.
When sending connections through the proxy engine, the FirePass controller
uses an advanced, full-content rewrite engine to modify the URLs and other
links in the original HTML document. The modified path begins with f5-w-.
For example, The FirePass controller rewrite engine converts the link shown
in the following example to the string shown in the following result.
<a href='http://siterequest.com/...'>
<a href='https://firepass.siterequest.com/
f5-w-X8d676sba8c650337ebf0937652fd678ac8a7663628f8a7d9449c9/. '>
If a web site has very complex or poorly written code, it is possible that
some links will not be re-written, or will be re-written incorrectly.
Additionally, the FirePass controller may not always be able to fully parse
and patch advanced JavaScript code, which could result in improper display
and loss of functionality.
You can apply the content-processing features to address these conflicts.
7 - 18
Locating proxy conflicts
You can find the source of the problem by comparing a connection made
directly between a client and the web application to a connection made
through the FirePass controller.
The following tools are helpful in making this comparison:
• The web browser’s source-viewing functionality
• The network packet dump option, available on the Device Management :
Maintenance : Troubleshooting Tools screen
For more information about the network packet dump feature, see
Capturing network packets, on page 8-61.
• The Test Content Processing Settings feature, available on the Portal
Access : Web Applications : Content Processing screen
For more information, see Testing content processing settings, on page
7-23.
• The FirePass controller engine-trace function
For more information about the engine-trace function, see Chapter 13,
Using Web Applications Engine Trace.
Configuring processing scripts for content processing
You can use the Preprocessing Scripts screen for modifying web pages as
they pass through the reverse proxy. To access the screen, in the navigation
pane, click Portal Access, expand Web Applications, click Content
Processing, and then click the Preprocessing Scripts tab.
The FirePass controller can perform special-purpose processing of content
passing through Web Applications, using SED-based scripts. You can create
specialized SED scripts that modify intranet web pages to address issues
related to the proxying of unusual or incorrectly formatted content.
Adding a SED script
You can use SED scripts to modify intranet web pages to handle issues
related to proxying unusual or incorrectly formatted content. Here, you can
specify a URL pattern and an accompanying SED script for processing
content passing through Web Applications. You can specify a single URL
match pattern list for each processing type. For example, you can specify
response preprocessing, processing that occurs before patching; response
postprocessing, processing that occurs after patching; or request processing,
processing requests from a user before the FirePass controller sends it to the
web site.
The FirePass controller processes URL content using the first match it finds
in the list of defined entries (starting at the top of the list).
The first step in configuring content processing by adding a SED script is to
create a favorite.
7 - 19
Chapter 7
To add a favorite that uses a SED script
Applications, click Content Processing, and then click the
Preprocessing Scripts tab.
The Preprocessing Scripts screen opens.
The screen refreshes to reveal new options.
3. In Processing script name, type the name of the favorite.
This can be any string that can help you identify the specified
content processing functionality.
4. In URL match patterns, specify a comma-separated list of patterns
to compare with incoming URLs. The FirePass controller processes
matching URLs using the specified script.
If the box is empty, the FirePass controller does not process content
from any URL. You can use the wildcard characters asterisk ( * ),
which represents many characters, and question mark ( ? ), which
represents a single character, to specify the patterns, for example,
http://*.siterequest.com/*
5. In Content Type, specify the content-type HTTP header that the
FirePass controller should process with the script.
An empty field means that the FirePass controller processes text/*
content types, for example, text/plain, text/html, and so on. For
SED script processing, you can specify additional types, for
example, application/xhtml+xml that the FirePass controller
should process using the specified SED script. If a page to be
matched does not have a defined Content Type, you can specify
application/unknown.
6. In Sed processing script, specify the SED script the FirePass
controller should use for processing the web application request or
response data.
For example, if you specify s|HTTP://|http://|g the FirePass
controller performs a global search for HTTP://, and replaces each
instance it finds with a http:// string.
You can use much more complex scripts, and include regular
expressions, to search for and replace or modify content, and to
correct HTML errors on pages.
You can use the FP_ServiceAddr variable inside SED scripts.
Processing replaces this variable with the FirePass controller name.
You can also use content processing scripts to insert
<FP_DO_NOT_TOUCH> and </FP_DO_NOT_TOUCH> tags
around sections of code on pages that you do not want the rewrite
engine to rewrite.
Note: In certain cases, you must use the backslash character to
escape forward slash characters in the SED script.
7 - 20
7. From the Processing list, select where to apply the content
processing script. You can apply the SED script to the user request
or to the server response. If you elect to apply the script to the
response, you can apply the script before or after the reverse proxy
engine performs content patching. Options are:
• Pre-process response data (before content patching): Applies
the SED script to response data received from a web site before
the content is patched by the reverse proxy engine. In most cases,
you should select this default option of Pre-process response
data (before content patching).
• Post-process response data (after content patching): Applies
the SED script on response data after the content is patched by
web applications.
• Process request data: Processes request data from a user before
it is sent to the web site.
You can find more information about using SED scripts on the Ask F5 web
site by searching FirePass-controller-related Solutions.
Example 1 of using a SED script
In this example, we use a script to replace an applet. The problem the script
is solving is that a page with a video streaming applet does not work as
expected through Portal Access Web Applications.
The administrator used the tcpdump command to determine that the
problem is that the applet does not rely on URLConnection for streaming,
that instead, it uses sockets.
Note
The FirePass controller patches Java applets (when the option is enabled),
even those that use sockets, so this example is for illustrative purposes only.
In this case, the administrator developed a SED-based content processing
script to replace the applet with an image, using a different CGI for
displaying still images, along with a piece of JavaScript to reload the image
automatically. You can find the script in the section SED content processing
script for example 1, following.
In the source for the web application, HTML comments take the applet out
of the context. Then, the script injects an image named noapplet following
the </APPLET> tag, and provides the onload callback im_loaded. The
script injects the im_loaded implementation preceding the </HEAD> tag,
reloads the image immediately after the implementation loads, and adds a
time-based query parameter to ensure that the browser does not cache the
image.
The result is that the location that previously contained the non-working
applet now shows a static image.
7 - 21
Chapter 7
SED content processing script for example 1
This shows a SED script that performs content processing on a page that
contains a video streaming applet that does not work in web applications.
s@</HEAD>@ <script>function im_loaded(){d = newDate;document.images['notapplet'].
src="/axis-cgi/jpg/image.cgi?="+d.getMilliseconds();}</script></HEAD>@
s@<APPLET@<img onload = 'im_loaded()'name=notapplet
src='/axis-cgi/jpg/image.cgi' width='320'height='240'>@
In this example, we describe how to prevent the rewriting of certain URLs
by the reverse-proxy engine. The problem the script is solving is that an
intranet application dealing with XML data or XSL style sheets does not
work properly.
The FirePass controller attempts to determine which links on HTML pages
it should rewrite. However, the reverse proxy engine might not always
correctly analyze XML or XSL data and pages that make extensive use of
JavaScript. If you determine through analysis that proper operation requires
the preservation of some links that are being rewritten, you can use a SED
script to return content to its original condition. The result is that the URLs
that were previously rewritten are now returned to a usable state.
SED content processing script for example 2
The following section contains a SED script that performs content
processing on a page that contains XML or XSL content that does not work
in web applications.
To search for certain types of pages, you can specify a match pattern in
URL match pattern, for example */pathnet/XSLTS/* Then in the SED
processing script box, you can use a SED script such as
s|/f5-w-[^/]*|//|g
In this case, the FirePass controller should process content after performing
its patching, so from the Processing list on the Preprocessing Scripts screen,
select Post-process response.
This script removes the f5-w- information that reverse proxy adds. In
general, the page will work correctly after postprocessing, as long as the
links on the page are to the same host (or are relative links).
You can also specify a slightly more complex SED script than the one
described in Example 2 of using a SED script to remove rewriting from one
particular link on a page, or to a more selective set of links. The following
script requires a link containing /eerequest/ on the page to remove the f5-wreferences.
/eerequest/ {
s|/f5-w-[^/]*|//|g
}
For more information, see the SED man page.
7 - 22
Testing content processing settings
You can test the content of a processed web page under Test Content
Processing Settings on the Preprocessing Scripts screen. To access the
screen, in the navigation pane, click Portal Access, expand Web
Applications, click Content Processing, and then click the Preprocessing
Scripts tab.
Once you apply the SED scripts you want, you can use this functionality to
preview a page’s content as it would be delivered from the FirePass
controller. To test content, in the navigation pane, click Portal Access,
expand Web Applications, click Content Processing, and click the
Preprocessing Scripts tab.
When you specify a URL in the box and click the Test button in the Test
Content Processing Settings section, the FirePass controller fetches and
displays the HTML source that the FirePass controller delivers for the
configured URL. When the processing testing mechanism finds and displays
the page represented by the URL, the content also reflects any script
processing and content cleaning results. You can also click a link, View
processed page through Web Applications, to view how the page looks
when presented to the end user.
If the page is a valid URL, the results box, labeled Original URL source,
contains the page source. If the URL is not valid, the testing functionality
returns the message Invalid URL entered or Error fetching URL source.
You may also get the Error fetching URL source if the URL you are trying
to fetch requires authentication. If that happens, you can specify the
authentication you need by viewing the page and then trying the test again.
Troubleshooting web application failures
While there are a number of reasons that SED processing might fail on an
application accessed through the FirePass controller, the most common
reason is that a JavaScript tested the page’s content and either the test failed,
or the content did not match the script’s expectations. If the content fails the
JavaScript test, errors might be reported or the application could refuse to
allow further operations.
Some common JavaScript tests perform the following functions:
• Check the protocol of the URL to make sure it is http://
• Check the URL to make sure its host name matches the server name sent
in the JavaScript
• Perform a checksum on the page and make sure it matches the original
JavaScript tests frequently fail when the site is accessed through the
FirePass controller, because the FirePass controller modifies URLs to use
the HTTPS protocol and to contain the host name of the FirePass controller.
You can use one of the following solutions to work around this issue:
• Modify the application so that the tests allow for the changes made by
• Use a content processing script to modify or remove the JavaScript test.
7 - 23
Chapter 7
Note
You can use the Minimal Content Rewriting Bypass feature to avoid the full
content rewrite typically needed with Web Applications. Configuring this
feature helps deal with complex portal and web application content. For
more information, see Configuring the Alternative Host/Port-based type of
bypass, on page 7-12.
Cleaning web application content
You can have the FirePass controller use the HTML Tidy open-source
parser to reformat HTML content passing through Web Applications prior
to content patching. This may be necessary for some sites to deal with
proxying specially formatted HTML content.
Note
Content cleaning is a very processor-intensive operation. We recommend
not enabling this feature except for debugging purposes, to help with
troubleshooting content-rewrite issues.
You can specify a list of URLs under Web Applications Content Cleaning
on the Preprocessing Scripts screen. To access the screen, in the navigation
pane, click Portal Access, expand Web Applications, click Content
Processing, and then click the Preprocessing Scripts tab.
In the box under Web Applications Content Cleaning, you can use the
question mark ( ? ), which represents a single character, to specify URLs
that you want the FirePass controller to process for content cleaning. An
empty list means that the FirePass controller does not reformat content from
any URL.
Note
The content-cleaning function cannot fix severe coding or content errors.
Configuring global settings for content processing
The FirePass controller rewrites URLs, JavaScript, and Java applets on all
Portal Access web pages to resolve internal to external URLs.
You can use options on the Global Settings screen for changing the FirePass
controller behavior for processing web pages as they pass through the Portal
Access reverse-proxy engine.
• Present alternative browser User-Agent strings to specific application
hosts: For information, see Configuring enforce-user-agent strings on a
per-host basis, following.
• Suspend updating the FirePass user session for specified URLs: For
information, see Preventing session update, on page 7-26.
7 - 24
• Omit from some application pages the Home/Logout tab, which is
ordinarily added to all proxied web pages: For information, see
Configuring non-buffering uploads, on page 7-26.
• Perform non-buffering uploads to URLs that match specified patterns.
For more information, see .
• Suspend rewriting of Java byte code for specified URLs: For
information, see Preventing Java byte code rewriting, on page 7-26.
• Configure OWA and iNotes: For information, see Understanding the
Flash rewriting support, on page 7-27.
• Configure OWA and iNotes: For information, see Configuring OWA,
iNotes, and other specific web applications, on page 7-27.
• Specify global settings for web applications: For information, see
Configuring web applications global settings, on page 7-28.
Note
Configuration for most global settings requires a service restart.
To access the Global Settings screen, in the navigation pane, click Portal
Access, expand Web Applications, click Content Processing, and then
click the Global Settings tab.
Configuring enforce-user-agent strings on a per-host basis
The FirePass controller can present a specified User-Agent string to a
particular web site instead of the actual browser’s User-Agent. An
alternative User-Agent string is useful in downgrading content if content
patching errors are occurring.
You can also specify a per-host, user-agent string to use with content
processing on the Global Settings screen. To access the screen, click Portal
Access, expand Web Applications, click Content Processing, and click the
Global Settings tab. This feature provides the following options:
• Intranet Host
Contains the URL for the intranet server that communicates with the
FirePass controller. For example,
server.siterequest.com.
• Alternative User-Agent String
Contains the string the configured intranet host sends to the FirePass
controller. The specified user-agent string causes the intranet host to
impersonate the specified browser by sending the associated user-agent
string.
• List of browsers
Contains a list of the common browsers. Selecting a browser from this
list populates the associated user-agent-string box, which you can
modify, if you wish.
For more information about user-agent strings, see Specifying user-agent
strings, on page 7-8.
7 - 25
Chapter 7
Preventing session update
Some web applications pages loaded through Web Applications connections
contain JavaScript code that regularly refreshes the page or sends HTTP
requests, regardless of user activity or inactivity. A session that is
abandoned at such a site does not time out, because it appears to be active.
You can use the session update feature to prevent these sessions from
remaining active indefinitely, and you can specify sites whose session
activity is to be disregarded for purposes of computing idle time.
In the list, you can use the wildcard characters asterisk ( * ), which
single character, to specify URLs that should not update the FirePass
controller session. An empty list means all URLs update a session.
Configuring non-buffering uploads
The FirePass controller caches files before uploading them to a server. You
can use the non-buffering upload option to upload a large amount of data
(32 MB to 1024 MB), such as video or voice files to a server through the
FirePass controller without caching the file. This speeds the upload process.
To allow upload of large files, make sure to change the value in the Restrict
maximum upload size (32-1024 MB) option on the Portal Access : Content
Inspection screen. Then in the Non-buffering uploads section on the Portal
Access : Web Applications : Content Processing, specify a pattern that
represents the server to which the files are to be uploaded.
Configuring "Home/Logout" tab injection
The FirePass controller inserts into HTML pages a small amount of HTML
that contains the JavaScript that displays the Home and Logout navigation
links. In the box in the Home/Logout tab injection section, type the full URL
for the page into which you do not want the FirePass controller to insert
JavaScript. Pages generated without the JavaScript contain no Home or
Logout links.
Preventing Java byte code rewriting
You can use the Java Byte Code Rewriting feature to suspend rewriting of
Java classes, or .jar, .cab, or .zip archives for specified match patterns.
By default, the FirePass controller handles Java byte code so that all HTTP,
HTTPS, and socket-based network communication is sent to the FirePass
controller through secure HTTPS tunneling. This approach provides a
secure and portable proxy mechanism for web-based, client-server
applications that utilize client Java applets.
The reverse proxy rewriting engine supports most network-related classes
and methods. As long as the Java applet uses TCP, and the network traffic is
initiated from the client, the applet is supported. If the applet contains
server-initiated connections through the use of the ServerSocket class,
reverse proxy cannot process the applet. Reverse proxy rewrites and re-signs
only those Java applets that require patching.
7 - 26
Since reverse proxy modifies the byte code, the final applet delivered to the
end-user is different from the original applet. The FirePass controller
re-signs the applet with its own signing certificate. In some cases, this can
result in a browser warning being displayed to the client.
To prevent Java modification problems with reverse proxy, ensure that all
network-related classes conform to the Sun Java specification. The rewriting
functionality might not support class files written in a proprietary format. If
the class files do not contain standard byte code, then reverse proxy cannot
modify the content.
The FirePass controller caches rewritten Java applet for the next client
request. Because of the caching operation, if your application uses Java
applets, make sure to check the Enable Dynamic Cache on FirePass.
Generally improves WebApplications performance check box on the
Portal Access : Web Applications : Caching and Compression screen.
In the box in the Java Byte Code Rewriting section, you can use the
question mark ( ? ), which represents a single character, to specify URLs for
which the FirePass controller should not rewrite classes or .jar, .cab, or .zip
archives. An empty list means the FirePass controller rewrites all classes or
.jar, .cab, or .zip archives. For more information about the process of
rewriting, see Configuring web applications for minimal rewriting, on page
7-10.
Understanding the Flash rewriting support
The rewrite engine fully supports and rewrites Flash files, .swf, and Flash
ActionScript. Because of specific Flash file formatting, web application
connections through Portal Access cannot be configured to stream Flash
files. Instead, the FirePass controller fully downloads the Flash files from
the server, rewrites them, and then sends them to the user. If you plan to
deliver large Flash files, for example, Flash files containing a video stream,
users might experience a significant delay before the file displays the
stream.
Configuring OWA, iNotes, and other specific web applications
For effective access, some web applications, such as Microsoft Outlook
Web Access and IBM iNotes, require a special access mode. In the Feature
Web Applications section of the Content Processing screen, you can specify
the host name or comma-separated list of host names for which you want to
switch to special mode.
For each host you specify, the FirePass controller uses the optimal caching
and compression settings, overriding the global settings specified on the
Portal Access : Caching and Compression screen. You can also check
Automatically detect hosts for OWA and iNotes to have the FirePass
controller evaluate the hosts and switch to special mode automatically. For
more information, see Configuring caching and compression, on page 7-30.
7 - 27
Chapter 7
Configuring web applications global settings
You can configure cookie pass-through using the box in the Web
Applications Global Settings area. You might want to allow cookies to pass
from the client to specific web sites. With the setting, you can specify a
comma-separated list of patterns to compare with incoming URLs. If there
is no pattern, the FirePass controller blocks cookie pass-through for all
URLs. You can type an asterisk ( * ) to allow cookies to pass through for all
URLs. You can use the wildcard characters asterisk ( * ), which represents
character.
*://msnbc.msn.com*
*://www.yahoo.com*
*://www.ibm.com*
If your web site includes JavaScript that does any client-side cookie
manipulation, you must specify a pattern that allows the cookie to pass
through to the client browser. For security reasons, cookies are not passed
through by default. When troubleshooting or testing initial support for a web
portal or application, check the Do not block cookies at FirePass, pass
them to the browser for specified URL patterns check box, and type an
asterisk ( * ) in the box. This configuration instructs the FirePass controller
to pass all cookies through to the client browser. Then after testing, you can
restrict the cookies being passed.
Configuring Content Processing Global Settings requires a service restart,
and also provides the following options:
• Compatibility mode (enable legacy version of Web Applications
handler)
Allows you to continue to use the web applications routines that shipped
with earlier versions of the FirePass controller. Select this option only if
you have developed SED scripts tuned to the specific requirements of
your intranet, and you are satisfied with the functionality of Portal
Access Web Applications (formerly MyIntranet).
• Automatically patch Java Applets
Intercepts the Java applet and unwraps it if it is a .jar, .cab, or a .zip
archive. Next, each class is searched, and when the applet-rewrite
functionality finds an Applet, JApplet, Socket, or URL, or InetAddress
class, it rewrites it accordingly, along with rewriting its inheritance
definitions. Then, the applet is repacked and resigned, if necessary, using
the F5 signing certificate. The FirePass controller then passes the
transformed applets to the web client, and caches them, if the dynamic
cache option is set.
By specifying URLs under Java Byte Code Rewriting on the Content
Processing Global Settings screen, you can suspend rewriting for specific
URLs. For more information, see Preventing Java byte code rewriting,
on page 7-26 and Configuring the Alternative Host/Port-based type of
7 - 28
• Automatic MIME type recognition
Examines the content associated with a site to determine its Multipurpose
Internet Mail Extensions (MIME) type so the application can present the
information correctly.
• Block non-HTML data
Prevents download of files such as .doc and .pdf from being downloaded
from web applications. Only HTML content is allowed to pass through
the proxy.
• Remedy IE gzip compression bug by adding leading 2 kilobytes of
whitespace to HTML pages
Compensates for an Internet Explorer bug that strips off the leading two
kilobytes of server messages when it accesses a web page compressed
using gzip. It does so by adding 2K of leading, padding spaces. Selecting
this option does not affect the appearance of the application on other
browsers. Select this option if you enable compression on the Caching
and Compression screen, and if any of your users might connect using an
unpatched version of Internet Explorer 6. To access the Caching and
Compression screen, in the navigation pane, click Portal Access, expand
Web Applications, and click Caching and Compression.
• Do not block cookies at FirePass, pass them to the browser for
specified URL patterns
Allows the FirePass controller to pass cookies to the user’s web browser.
This option is useful for supporting web applications that use JavaScript
in the browser to manipulate cookies. We recommend that you specify a
pattern or list of patterns that allows cookie pass-through only for web
applications with URLs that match the pattern.
• Automatically add websites that require client side cookie
manipulation
Adds to the list the web sites that require client-side cookie manipulation
when the FirePass controller encounters them. By default, this feature is
enabled. F5 Networks strongly recommend disabling this option once the
learning phase is over.
• Encrypt hostnames
Uses AES encryption to modify the name of the host that is passed
through the proxy. When you select this option, the system does not use
dynamic cache, regardless of the state of the Enable Dynamic Cache on
FirePass. Generally improves WebApplications performance check
box on the Portal Access : Web Applications : Caching and Compression
screen. When Encrypt hostnames is not selected, the system passes host
names as hex-encoded strings.
• Obfuscate cleartext cookies
Obscures cookies sent in clear text format so users cannot read them. By
default, this feature is enabled.
• Translate hidden form parameters if they look like URLs
Select this option to translate hidden form parameters if they appear as a
URL, such as http://XXX. This option is useful when you have
JavaScript that manipulates hidden form parameters. F5 Networks
recommends limiting the effect of this option by specifying a list of URL
7 - 29
Chapter 7
patterns to match against. In the list, you can use the wildcard characters
asterisk ( * ), which represents many characters, and question mark ( ? ),
which represents a single character. An empty list means all URLs are
patched.
Configuring caching and compression
You can define caching and compression functionality on the Caching and
Compression screen. To access the screen, in the navigation pane, click
Portal Access, expand Web Applications, and click Caching and
Compression. Using options on this screen, you can configure settings that
determine caching and compression of files sent from the FirePass controller
to remote user’s web browsers, as well as the transmission of cookies and
file downloads from intranet servers to users.
When using dynamic cache, the FirePass controller does not distinguish
between static or dynamic content. It distinguishes between objects that the
remote server designates as those that the FirePass controller can and those
it cannot cache. The remote server indicates the object’s ability to be cached
by setting the appropriate cache control in the response’s HTTP headers. If
the remote server indicates that an object may be cached, and this option is
checked, the FirePass controller caches the object in its dynamic cache.
Note
You should not enable dynamic cache when you are using group-based
VLAN to access hosts with the same host name or IP address on different
VLANs.
The FirePass controller validates the currentness of cached objects by
sending an if-modified-since request-header to the remote server and
receiving either a (not modified) response or the modified object. This
ensures that objects in the cache remain fresh.
If client browsers request both compressed (gzip) and non-compressed
objects simultaneously, the FirePass controller stores each type into the
cache for maximum performance.
Caching errors do not affect web application functionality. When the
FirePass controller cannot cache an object for any reason, the FirePass
controller simply sends the object to the user. In other words, operation is
the same as if caching is turned off.
You can determine whether the FirePass controller has presented content to
a client from the cache, by checking the response headers in pages returned
to the browser for the presence of the following string:
X-Cache: HIT from your.firepass.hostname
7 - 30
Setting caching and compression
The Caching and Compression screen provides the following caching and
compression options:
• Enable Dynamic Cache on FirePass. Generally improves
WebApplications performance:
Caches content to prevent the need for repeated rewriting. You can also
clear the dynamic cache by clicking the Clear Cache button. If you
specify Encrypt hostnames, the FirePass controller does not use this
caching setting, even if you specify it.
• Enable Compression. Saves bandwidth, at the expense of server
resources:
Uses the gzip compression utility to substantially reduce the size of
generated content. The most noticeable improvement in speed occur
when accessing pages that contain big Java classes or other large
elements (images, scripts, and so on), but not when accessing pages that
reference Java packages (.jar files), class archives (.zip files), or
compressed images (.jpg, .png, and Compressed TIFF files).
For iNotes and other Java-based web mail packages, enabling
compression vastly improves the speed in which pages are loaded. You
can also specify a comma-separated list of URLs for the FirePass
controller not to compress, even when compression is turned on. In the
list, you can use the wildcard characters asterisk ( * ), which represents
character. Turning on gzip compression reduces FirePass controller
resources, which can affect scalability.
Configuring global caching and compression settings
You can select from several global caching and compression settings. Each
global setting caching option has an inherent trade-off between web
application performance and security. The global settings you can select
include:
• Don't cache anything, except Style Sheets and JavaScript includes
Provides a good compromise between security and performance. By
default, web applications mark every screen as non-cacheable with the
exception of JavaScript and style-sheet includes. The reason is that
typically, these sizeable includes are designed with caching in mind.
When caching is turned off, a high percentage of the traffic consists of
these includes. Given that the content of these includes is rarely
confidential, they are not marked as non-cacheable by default.
• Don't cache anything, except for images, style sheets and JavaScript
includes
Results in better performance than the first option, but less security.
• Cache nothing at the remote browser
Impacts performance more than the first two options, but provides better
security. OWA and iNotes require some caching, so select another option
when you are serving OWA and iNotes application pages.
7 - 31
Chapter 7
• Don't enforce no-cache
Provides the best performance of all options, but the least amount of
security. Use this option only with trusted terminals such as home
computers. This option caches according to the web browser settings. For
this setting, you can specify a comma-separated list of URLs for which
the FirePass controller should ignore no-cache. If there is no list
specified, no URLs are exempt from no-cache. When you specify the list,
you can use the wildcard characters asterisk ( * ), which represents many
characters, and question mark ( ? ), which represents a single character.
You would use this option in cases where the no-cache header causes
problems.
For example, if Cache nothing at the remote browser is set, when
proxying HTTP content, The FirePass controller automatically sets a
Cache-Control: no-cache header. The Cache-Control: no-cache header
can cause problems for some XML applications, mostly on Internet
Explorer browsers, because the client does not retrieve XSL files that are
not cacheable. When this occurs, the browser displays an error indicating
that the XSL file is not cacheable or is not available. You can work
around this issue by specifying http://*.siterequest.com/*.xsl in the box
so that the FirePass controller does not insert the cache control headers
into files that end with an .xsl extension.
Configuring intranet webtop options
You can specify an intranet web page to replace the webtop for a specific
master group on the Intranet Webtops screen. To access the screen, in the
navigation pane, click Portal Access, expand Web Applications, and click
Intranet Webtops. If you elect to use a web page, no other access functions
are available. Configured intranet webtops apply to all users in a master
group.
You would configure this feature when you want to replace the standard
FirePass controller webtop with an internal intranet portal front-page. An
intranet webtop completely replaces the standard FirePass controller
webtop, which typically displays administrator and user-defined favorites.
Note
In addition, you can create a custom replacement page that contains
JavaScript code that starts FirePass controller favorites. You can store the
replacement webtop page on the FirePass controller, using WebDAV, or on
an external server. For more information and code samples, see the online
help on the Device Management : Customization screen under Advanced
WebDAV customization.
7 - 32
Intranet webtops have the following properties and elements.
• Request
Indicates whether to transmit the URL and its accompanying arguments
in GET, or in a POST request. Using POST is a more secure way to
provide a user name and password for logging on to an intranet site,
because the variables are not visible on the URL line of the browser for
someone to see.
• URL
Indicates the intranet web server that serves the application. For example:
• URL variables
Contains variables to be either appended or sent in a GET command to
the specified URL. For more information and examples, see Working
with URL variables, on page 7-7.
• Enabled
Indicates whether the web application serves the specified page as the
webtop for users in the associated group. For additional information on
how to use a page as a customized webtop and run FirePass favorites, see
the online help on the Device Management : Customization screen.
Preserving page content
The FirePass controller supports the ability to present favorites on a custom
portal page located on the FirePass controller, using WebDAV, or from a
custom portal page stored on one of your own internal servers. You can use
the portal page as an alternative to the FirePass controller webtop.
For more information about WebDAV functionality, search for WebDAV in
the online help.
Once you have the portal page, you can configure it as a FirePass controller
webtop or define a reverse-proxy favorite. Then, users who log on to the
FirePass controller using that portal page can start favorites, such as
AppTunnels or Network Access connections, by clicking portal links.
If you have HTML, JavaScript, or CSS content that you want to preserve,
you can do so by placing a <FP_DO_NOT_TOUCH> tag at the beginning
and a </FP_DO_NOT_TOUCH> tag at the end of the code. The tags
prevent the code inside them from being rewritten.
Note
In earlier versions, the online help for the Device Management :
Customization screen in the WebDAV section, contained sample code that
you could use for this purpose. The new reverse-proxy engine rewrites some
of the content so that pages using the sample code no longer work. If you
are using the sample code, you can also use these tags to prevent the
rewriting.
7 - 33
Chapter 7
Configuring proxy options
You can specify proxy settings on the Proxies screen. To access the screen,
in the navigation pane, click Portal Access, expand Web Applications, and
then click Proxies. The FirePass controller can use HTTP and HTTPS
proxies for web access. The Set up optional HTTP and SSL proxies for
public Internet access section provides options for proxies for HTTP, SSL,
or both. In addition, you can elect to use basic proxy authorization,
specifying a user name and password to the proxy.
The FirePass controller web-access mechanism requires a proxy if there is
no outbound access to the Internet. Also, Web Applications functionality
might require proxy settings if the FirePass controller does not have direct
access to the web servers on the local network.
Proxy settings consist of an address and port number. You can also specify a
comma-separated list of addresses or subnets to which the FirePass
controller should allow direct access, that is, not through the proxy server.
When you check Enable HTTP proxy or Enable SSL proxy and click
Update and Test, the FirePass controller presents Address and Port boxes
for each type of proxy.You can also specify a list of the IP addresses to
which the FirePass controller should allow direct access rather than through
the proxy.
Note
The FirePass controller makes sure it can connect to a specified proxy
before committing the settings. Because of this, testing a new configuration
might take a minute or so if the settings are incorrect.
In the No proxy for the following addresses (comma separated) box, you
can specify the leading digits for IP addresses for resources to which you
want the FirePass controller to allow direct access. Use commas to separate
these addresses. You can use the X[.Y[.Z]] format for IP address templates,
for example, 19 or 192 or 192.168 or 192.168.200 or 192.168.200.12. If
there is no list of addresses, the FirePass controller uses a proxy for all
resource access.
Note
The FirePass controller does not support specifying a subnet mask using
24-bit (CIDR) addresses for the proxy exclusion list.
7 - 34
Configuring Windows files
You can configure Windows Files favorites that give users access to files in
network shared Windows folders. Once connected, users can view,
download, move, rename, and delete files. You can also specify global
settings that apply to all Windows files connections through Portal Access.
Configuring Windows Files favorites
You can use the Resources screen to configure favorites for the user’s
webtop. To access the Resources screen, in the navigation pane, click Portal
Access, and click Windows Files. To set other policies and behaviors, you
can use the Master Group Settings screen. For more information on master
group settings, see the online help.
When you click Add new favorite on the Resources screen, the screen
reveals additional options.
• Type
Indicates whether the link is a new configuration (Favorite) or a pointer
to an existing one in another master group (Alias). Alias is available as
an option only when there are Portal Access favorites configured in
another master group.
• Name
Contains the name for the intranet site that you are defining as a favorite.
This is the name the user sees on the webtop. The string you specify can
be any name; field format is not limited. For example:
Project management & "dailies"
• Path
Contains the Microsoft Universal Naming Convention (UNC) string. A
UNC name typically references a shared folder and file accessible over a
network rather than a drive letter and path. You can include path
arguments such as %username% to substitute for user’s logon and
%group% to substitute for the user’s master group name. For example
\\publicsrv.eng.siterequest.com
• Endpoint protection required
Provides a list of Protected Configurations defined on the Users :
Endpoint Security : Protected Configurations screen. If the user’s
endpoint protection does not satisfy the defined condition, the system
prevents access to the specified resource. For more information about
protected configurations, see Creating protected configurations, on page
3-27.
Important
The FirePass controller does not verify paths, so make sure the path is
specified correctly.
7 - 35
Chapter 7
Configuring Windows Files master group settings
You can specify options that apply to all Windows Files users on the Master
Group Settings screen. To access the Master Group Settings screen. in the
navigation pane, click Portal Access, expand Windows Files, and click
Master Group Settings.
The Master Group Settings screen provides a set of options that govern the
operation of Windows Files functionality through Portal Access
connections.
◆
Limit Windows Files Access to Favorites only (for Extranets, partner
and customer access, etc.)
Prevents master group members from browsing outside of folders
specified in favorites.
◆
Enable file upload
Controls the uploading files for users in the associated master group. To
specify the maximum file upload size, and set antivirus checks for
downloaded files, see Configuring buffer overflow protection, on page
7-46.
◆
NetBIOS Machine Name
Specifies the NetBIOS name of the FirePass controller, using 1 to 15
alpha-numeric characters. The default is the host name.
◆
Name Resolution Service Order
Specifies the sequence in which the FirePass controller attempts to
resolve NetBIOS names to IP addresses for Window-based file access.
List each options separated by a space. The default order is host wins
bcast, which represents the following options:
• host
Resolves a standard host name to an IP address, using the system
/etc/hosts, NIS, or DNS lookups,
• wins
Resolves WINS server names to an IP address. This option is valid
only when you configure a WINS server, as described in the WINS
Servers entry, following.
• bcast
Performs a broadcast on the servicing interface to resolve NetBIOS
names to IP addresses. Do not use this option when you define master
group-based policy routing for the user’s master group.
◆
7 - 36
WINS Servers
This setting is necessary for multi-segment networks, when the FirePass
controller and the LAN are on different network segments, or when the
LAN itself has multiple segments. You must specify WINS Servers for
networks structured as multi-segment LAN environments. When the
Name Resolution Service Order has the wins option specified, then you
must specify one or more valid WINS Servers in WINS Servers.
◆
Default Domain/Workgroup
Contains the name of the Windows domain or workgroup where the
FirePass controller resides. You must specify Default
Domain/Workgroup when the FirePass controller unit address is not on
the target LAN. We also recommend that you define the Default
Domain/Workgroup setting for multi-segment LAN environments.
◆
Auto-logon to Windows File shares using FirePass user logon
credentials
Directs the FirePass controller to use the user’s FirePass controller logon
name and password to automatically log on to Windows file servers and
shares.
◆
Click to change the status and/or webifyer position on the webtop
Opens the User Experience screen for the associated master group, where
you can change the location and operation of favorites on the user’s
webtop. For more information, see the online help for the screen.
In addition to these settings, the FirePass controller automatically enables
SMB signing for authentication when the connecting server requires it.
Also, the FirePass controller can access Windows file servers that support
DFS.
7 - 37
Chapter 7
Configuring Mobile E-Mail
You can configure the Portal Access : Mobile E-Mail feature to enable users
to access email from any client computer. The Mobile E-Mail feature
provides very lightweight access to multiple Post Office Protocol (POP) and
Internet Message Access Protocol (IMAP) mailboxes and address books,
using data from the FirePass controller’s internal database or from an LDAP
directory. You can configure different Mobile E-Mail settings for each
master group. There are several options for configuring logon options:
• Allowing the user to enter a logon name and password directly
• Using the FirePass database for logon information
• Querying an LDAP server to retrieve logon credentials.
Users can use any web browser to access the mailbox. In particular, users
who are away from the office can use browsers on mobile devices to quickly
browse through emails.
A user can configure any number of email accounts, but you can limit access
to only the corporate account you create, by checking the Limit E-Mail
Access to Corporate mail account only (for Extranets, partner and
customer access, etc.) check box. This limitation is useful for users logging
on from extranets, and for partner and customer access. You can also disable
the downloading of attachments, which can help prevent introduction of
untrusted material onto the client’s machine.
Configuring Mobile E-Mail includes the following options:
7 - 38
◆
Master Group
Presents a list of all master groups. Select the one you want to configure.
◆
Enable corporate mail account
Provides access to the user’s corporate email account.
◆
Account name
Represents the string users see as the name of the link on their webtop.
Corporate Mail is the default.
◆
Mail server
Represents the mail server name or IP address. For example,
mailserver.siterequest.com.
◆
Type
Presents the support options: POP and IMAP. Select the one you want.
◆
IMAP Folders
Represents the comma-separated list of folders that you want users to
see, if you are using an IMAP mail server. This list prevents the
confusion created by mail servers that display items that are not email
messages, such as contacts or calendars, as empty email folders. Users
can also add to the list themselves.
◆
logon Information
Presents a list of options for logging on to Mobile E-Mail.
• User supplies display and logon information during first logon:
Gets email information from users when they attempt to use Mobile
E-Mail for the first time.
• Use FirePass database for display and logon information:
Retrieves email address, logon name, and password from the FirePass
controller internal database.
• Use LDAP query for mail server, display, and logon information:
Queries an LDAP server to dynamically retrieve each user’s email
information. When you select this option, you must configure the
LDAP query. For descriptions of the query options, see Configuring
the LDAP query, following.
◆
Outgoing Mail server
Represents the outgoing email server name or IP address for the FirePass
controller to use when sending email. If you do not specify a server, the
FirePass controller uses the settings specified in Primary server on the
Device Management : Configuration : SMTP Server screen.
When you finish configuring all of the options, click the Update button.
Important
If you use LDAP authentication over SSL, specify a host name, and be sure
that the host name exactly matches the name on your LDAP server’s
certificate.
Configuring the LDAP query
When you select the Use LDAP query for mail server, display, and logon
information option on the Logon information list in the Corporate email
account section of the Mobile E-Mail screen, you must also specify the
following options:
• LDAP server
Represents the IP address or host name of the LDAP server.
• Port
Represents an LDAP port, such as 389.
• Use SSL connection
Provides support for using SSL for the connection.
• Protocol version
Presents a list of the LDAP protocol version (2 or 3) for you to select.
The default protocol version is 3. If you use Active Directory, you must
use version 3.
• Bind DN
Represents the distinguished name the FirePass controller should use to
bind to the LDAP directory.
• Bind password
Represents the password for the BIND DN. You can leave the box empty
to require no authentication.
7 - 39
Chapter 7
• Search base
Indicates the level of the entry in the tree to be used for the search, for
example:
cn=Recipients,ou=Exchange,o=FirePass
• Filter template
Contains the string to use when searching for the user. You can use %s
in the filter expression to have the FirePass controller insert a user logon,
for example:
(&(objectclass=person)(cn=*%s*))
• Attribute for mail server
Contains the attribute in the LDAP schema that stores the mail server
name.
• Attributes for user's display name, email address, and logon
Contains the attributes in the LDAP schema that stores the associated
information.
• Attribute for mail server
Represents the attribute in the LDAP schema that stores the mail server
name.
• Attribute for user’s display name
Represents the attribute in the LDAP schema that stores the name that
indicates who sent the email.
• Attribute for user’s email address
Represents the attribute in the LDAP schema that stores the originating
address of the email.
• Attribute for user’s logon
Represents the attribute in the LDAP schema that stores the name the
user types when logging on to the email server.
Configuring LDAP as the email address source
By default, Mobile E-Mail uses a list of users from the FirePass controller
database as an address book. You can elect instead to use an LDAP server as
the email address source. When you select Use LDAP server to obtain
addresses, you must also configure the following options:
• LDAP server
Represents the IP address or host name of the LDAP server.
• Port
Represents an LDAP port, such as 389.
• Use SSL connection
Provides support for using SSL for the connection.
• Protocol version
Presents a list of the LDAP protocol version (2 or 3) for you to select.
The default protocol version is 3. If you use Active Directory, you must
use version 3.
7 - 40
• Bind DN
Represents the distinguished name the FirePass controller should use to
bind to the LDAP directory.
• Bind password
Represents the password for the BIND DN. You can leave the box empty
to require no authentication.
• Search base
Indicates the level of the entry in the tree to be used for the search, for
example:
cn=Recipients,ou=Exchange,o=FirePass
• Filter template
Contains the string to use when searching for the user. You can use %s
in the filter expression to have the FirePass controller insert a user logon,
for example:
(&(objectclass=person)(cn=*%s*))
• Name attribute
Represents the attribute in the LDAP scheme that stores the user’s name.
• Address attribute
Represents the attribute in the LDAP scheme that stores the user’s email
address, which is typically mail.
Disabling email attachments
By default, email attachment downloads are enabled. You can disable
downloads by checking the Disable attachment download check box. This
can help you protect remote client computers by preventing the introduction
of content that may contain viruses.
Changing where Mobile E-Mail links appear on the webtop
You can customize the location of favorites on the user’s webtop. To access
the customization page, click the Click to change the status and/or
webifyer position on the webtop link on the user’s home page webtop.
7 - 41
Chapter 7
Configuring content inspection
You can configure several kinds of functionality to provide content
inspection. These are provided as tabs on the Content Inspection screen. To
access the screen, in the navigation pane, click Portal Access, and click
Content Inspection, and then click one of the tabs.
• XSS scripting
Represents cross site scripting, a type of attack that gathers data from a
user for unauthorized use of security vulnerabilities in web applications.
You can use options on this screen to aid in preventing such attacks. For
more information, see Configuring cross site scripting security,
following.
• SQL injection
Represents the unauthorized process of introducing SQL commands in
the command string to gather database information. You can use options
on this screen to test for such activity. For more information, see
Configuring SQL injection scanning, on page 7-44.
• Buffer overflow
Represents a security vulnerability that, when exploited, allows for
running unauthorized code on the user’s computer. You can use options
on this screen to reduce the possibility of this type of activity. For more
information, see Configuring buffer overflow protection, on page 7-46.
• Antivirus
Represents the activity of detecting and preventing the introduction of
viruses onto the user’s computer. You can use options on this screen to
configure virus scanning and to check uploaded files for viruses. For
more information, see Configuring anti-virus scanning of uploaded files,
on page 7-47.
Configuring cross site scripting security
You can use the XSS scripting screen to specify cross site scripting (also
called CSS or XSS). To access the screen, in the navigation pane, click
Portal Access, click Content Inspection, and then click the XSS scripting
tab.
The FirePass controller aids in preventing cross site scripting attacks on
vulnerable web servers. This is done by scanning URL arguments and form
POST data sent by users through Web Applications, and blocking the
request if it looks suspicious.
Note
The FirePass controller user webtop and administrative console interfaces
are already protected against cross site scripting attacks.
A web site may inadvertently include malicious HTML tags or script in a
dynamically generated web page, based on unvalidated input from
untrustworthy sources. This can happen when a web server does not
7 - 42
adequately ensure that generated pages are sufficiently encoded to prevent
unintended execution of scripts, and when input is not screened to prevent
malicious HTML from being presented to the user.
This vulnerability is used as the basis for cross site scripting attacks, and can
occur when a user relies on an untrustworthy source of information, such as
an external untrusted web site link or a link in an email message. For
example, an attacker may construct a malicious link such as:
<A HREF="http://siterequest.com/comment.cgi?mycomment=
<SCRIPT>malicious code</SCRIPT>"> Click Here</A>
When a user clicks this link, the URL sent to siterequest.com includes
malicious code. If the web server returns to the user a page that includes the
value of mycomment, that is, if the web server does not properly filter user
input or generated output, a vulnerable client might be able to execute the
malicious code.
Scanning for suspicious characters
Options in the Restricting web site input to allowed character set section
instruct the FirePass controller to scan user input data for suspicious
characters such as less than ( < ) and greater than ( > ), and their
URL-encoded equivalents of %3c and %3d. The FirePass controller bases
the definition for suspicious characters upon a defined allowed character set.
The default match pattern is:
'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*-If the operation detects any suspicious characters, the FirePass controller
blocks the user’s request.
The FirePass controller provides the following options for restricting input
to an allowed character set:
• Scan URL parameters for restricted characters
Inspects user input data in HTTP GET for suspicious characters within
URL arguments.
• Scan form POST data for restricted characters
Inspects user input data within URL-encoded form POST data for
suspicious characters.
• User defined allowed character set (advanced)
Provides an area for defining your own character set to use for scanning
URL arguments and form POST data. Checking this option populates the
box with the default list of characters, URL-encoded according to RFC
1738, which you can modify.
Scanning for embedded script code
Options in Scanning web site input for embedded script code instruct the
FirePass controller to scan user input data for suspicious strings such as
<SCRIPT and javascript: and their URL-encoded equivalents. The
7 - 43
Chapter 7
FirePass controller bases the definition of suspicious strings on a defined
script search element list. If the scan detects any suspicious active elements,
the FirePass controller blocks the user’s request.
The FirePass controller provides the following options for scanning for
embedded code:
• Scan URL parameters for embedded script code
Inspects user input data for active elements such as scripts within URL
arguments.
• Scan form POST data for embedded script code
Inspects user input data within URL-encoded form POST data for active
elements, such as scripts.
• User defined script search elements (advanced)
Provides an area for defining your own search elements. For example,
you can modify the active element set of strings used for scanning of
URL arguments and form POST data. Checking this option opens a box
containing the default list of elements. You can modify this value or
define your own.
<script <object <applet <embed <form javascript: vbscript: mocha:
livescript: about: onload= onmouseover= text/javascript script> &{
url( expression(
Excluding sites from XSS scanning
You can also specify a comma-separated list of URLs to exempt from
scanning operations. In the Web site exceptions list section, you can use the
question mark ( ? ), which represents a single character. If the box is empty,
it means that the FirePass controller scans requests to all sites. For example,
if a particular intranet web site supports entering HTML tags, you should
exclude this site from URL argument and form POST data scanning.
Configuring SQL injection scanning
You can use the SQL injection screen to specify virus scanning and database
update options. To access the screen, in the navigation pane, click Portal
Access, click Content Inspection, and then click the SQL injection tab.
SQL injection exposures allow attackers to modify calls to backend
databases by adding to or manipulating SQL statements. To exploit a SQL
injection flaw, the attacker embeds malicious SQL commands into the
content of a parameter intended to be part of an SQL call. Consequences can
range from trivial to severe.
The web application is responsible for detecting and blocking these attacks.
However, the FirePass controller offers additional lines of perimeter defense
against injection attacks initiated in web applications accessed through
Portal Access.
7 - 44
You can:
• Filter input URL parameters and form POST data for suspicious
characters
• Block requests with suspicious extended content.
Filtering for suspicious characters
Options in Filtering suspicious web site input instruct the FirePass controller
to scan and filter user input data for suspicious characters such as
apostrophe ( ’ ) , number sign ( # ), double-dashes ( -- ), and semi-colons ( ; )
and their URL-encoded equivalents %27, %23, and %3b. (There is no
encoding for double-dashes.) Because valid web site input can contain these
characters, you might want to limit the web site match list or only enable the
more-specific blocking options in Blocking suspicious web site input,
following.
shutdown|xp_).*-If the parser detects any of these characters, it removes the character from
the input string. It passes the rest of the string through to the application.
The FirePass controller provides the following options for filtering for
suspicious characters:
• Scan/filter URL parameters for suspicious characters
Inspects URL variables to determine the presence of suspicious
characters.
• Scan/filter form POST data for suspicious characters
Inspects form POST data to determine the presence of suspicious
characters.
• User defined block match regular expression (advanced)
Enables customization of the regular expression used in the filtering
operation. When you check this option, you can then modify the text
using standard regular expression (regex) syntax. You can restore the
default match pattern by clearing the option.
Note
This technique can prevent many attacks, but it also can result in many false
positives, and could alter valid input. For example, the name O'Hara would
be changed to OHara, and fail to match a valid record.
Blocking suspicious web site input
The blocking option performs a more sophisticated match for particular
types of SQL injection attacks, by identifying strings with complex
combinations. When the parser finds a match, it displays a warning and
blocks the page. The FirePass controller adds a warning message to the
FirePass System Log.
7 - 45
Chapter 7
shutdown|xp_).*-You can view and customize the default pattern by checking the User
defined block match regular expression (advanced) check box. You can
then modify the text using standard regular expression (regex) syntax. You
can restore the default match pattern by clearing the check box.
Excluding sites from SQL injection scanning
You can also specify a comma-separated list of URLs to exempt from
scanning operations. In the Web site exceptions list section, you can use the
question mark ( ? ), which represents a single character. If you select SQL
injection filtering or blocking and you leave this list empty, it means that the
FirePass controller scans all sites.
Configuring buffer overflow protection
You can use the Buffer overflow screen to specify virus scanning and
database update options. To access the screen, in the navigation pane, click
Portal Access, click Content Inspection, and then click the Buffer
overflow tab.
A buffer overflow attack is an attempt to corrupt the execution stack of a
web application by sending input that exceeds the length of the application’s
data buffer. By sending carefully crafted input to a web application, an
attacker could cause the web application to execute arbitrary code,
effectively taking over the machine. Even if the input string does not take
over the target system, an attacker can use a buffer overflow as a
denial-of-service attack.
Buffer overflow attacks exploit inputs of several types.
• Files uploaded using the Windows or UNIX file access features
• Form POST data input to web applications
• GET query strings input to web applications
Web applications, web servers, and the services they use all can contain
buffer overflow vulnerabilities. The best defense is to restrict the length of
any attempted input string to the appropriate maximum for the application.
While it is the responsibility of the application to parse input, you can
specify maximum levels for your environment, providing an outer perimeter
of defense against exploits such as these.
The FirePass controller provides the following options for applying buffer
overflow protection:
7 - 46
• Restrict maximum upload size (32-1024 Mb)
Constrains files that the user uploads to a specific size. The default value
is 32 MB.
• Restrict maximum length of a GET query string
Constrains the request string to the maximum specified. The default
value is 2048 bytes.
• Restrict maximum length of POST data
Constrains the response string to the maximum specified. The default
value is 16384 bytes.
If you check the Restrict maximum length of a GET query string check
box or the Restrict maximum length of POST data check box, you can
also specify a comma-separated list of URLs to exclude from buffer
overflow checks. In the web site exceptions box, you can use the wildcard
characters asterisk ( * ), which represents many characters, and question
mark ( ? ), which represents a single character. If you specify buffer
overflow options and you leave this list empty, it means that the FirePass
controller checks input to all sites accessed through Portal Access.
Configuring anti-virus scanning of uploaded files
You can use the Antivirus screen to configure Portal Access to check
uploaded files for virus infections. To access the screen. in the navigation
pane, click Portal Access, click Content Inspection, and click the
Antivirus tab. When the antivirus feature is active, it scans files that are
uploaded using any of the following Portal Access functions:
• Windows Files
• Web Applications
• Mobile E-Mail
The FirePass controller provides the following options for checking
uploaded files for viruses:
• Disable virus scanning
Does not perform virus scanning of uploaded files. We recommend that
you only select this option if you are sure that you have another service
performing virus scanning.
• Enable ICAP client
Instructs the FirePass controller to act as an Internet Content Adaptation
Protocol (ICAP) client and use it for inspection using the response
modification mode. For more information, see Enabling the ICAP client,
following.
• Enable standalone virus scanner
Activates scanning using the standalone virus scanner, the Open Source
Clam Antivirus running locally on the FirePass controller. For more
information, see Enabling the standalone virus scanner, following.
7 - 47
Chapter 7
Enabling the ICAP client
ICAP is an open standard for Internet proxy servers to communicate with
content servers. If your corporate antivirus protection is based on an
antivirus service that has ICAP capability, the FirePass controller can use an
ICAP client for upload inspection. When you select Enable ICAP Client
and click Update, the screen reveals additional options, in which you can
specify the host name, IP address, or path and port of the ICAP server.
You specify the path and port of the ICAP server using the following format
[icap: // ]<domain-name > [<:port >][/ path]
Following are some examples of how to specify the path and port of the
ICAP server:
• siterequest_domain.siterequest.com: Specifies the domain name.
• siterequest_domain.siterequest.com:1345: Specifies the domain name
and port.
• siterequest_domain.siterequest.com:1345/avscan: Specifies the
domain name, port, and path.
• siterequest_domain.siterequest.com/avscan: Specifies the domain
name and path.
• icap://siterequest_domain.siterequest.com:1345/avscan: Specifies the
ICAP protocol, domain name, port, and path.
Enabling the standalone virus scanner
You can use the default virus scanner, Clam AntiVirus, to detect viruses in
uploaded files. When you select Enable Standalone Virus Scanner and
click Update, the screen reveals additional options.
In the Virus DataBase Update section, you can specify how to update the
virus scanning files. You can update the Clam AntiVirus database manually,
by periodically uploading database files, or automatically, by a process that
runs on the FirePass controller to periodically checks the Clam AntiVirus
site for database updates.
The Virus Database section shows the most recent updates for the Clam
AntiVirus database.
Configuring for manual update
Clam AntiVirus stores virus information in two files: main.cvd and
daily.cvd. These are available for download from the following sources:
http://database.clamav.net/daily.cvd
http://database.clamav.net/main.cvd.
If you are using the manual update method, download these files to your
computer, and then upload them to the FirePass controller, using the Browse
button to locate the file.
7 - 48
Configuring for automatic update
When you select Automatic update and click Update, the FirePass
controller reveals additional options.
In Download site, you can specify a Clam AntiVirus mirror site. You can
select a site from http://www.clamav.net/mirrors.html, or specify
database.clamav.net (a round-robin record that allocates traffic among the
database mirrors). The default is database.clamav.net.
The update process uses the HTTP protocol. You can specify the frequency
of updates (as the number of Updates per day), number of Retry attempts
to download an update, and, if you use an HTTP proxy, any needed proxy
parameters.
7 - 49
Chapter 7
7 - 50
8
Managing and Monitoring the FirePass
Controller
• Configuring global FirePass controller settings
• Maintaining the network configuration settings
• Introducing realms
• Completing other configuration activities
• Performing maintenance
• Monitoring the FirePass controller
• Customizing the user’s webtop
Configuring global FirePass controller settings
You can configure several areas of the FirePass controller.
◆
Admin E-Mail
For more information, see Configuring Admin Email, on page 8-31.
◆
High scalability and availability
For more information, see Chapter12, Using FirePass Controllers in
Clusters and Chapter 11, Using FirePass Controllers for Failover.
◆
Network Configuration
For more information, see Maintaining the network configuration
settings, following.
◆
New Browsers
For more information, see Adding definitions for other types of browsers,
on page 8-32.
◆
RSA SecurID
For more information, see Configuring a new RSA SecurID
authentication server (for Native RSA authentication), on page 8-33.
◆
SMTP Server
For more information, see Specifying the SMTP email server, on page
8-37.
◆
SNMP
For more information, see Configuring an SNMP agent, on page 8-38.
◆
Proxies
For more information, see Specifying HTTP and SSL proxies, on page
8-39.
◆
Time
For more information, see Specifying the time, time zone, and NTP
server, on page 8-40.
8-1
Chapter 8
Maintaining the network configuration settings
Network configuration is the process of setting up the FirePass controller’s
network interfaces, IP addresses and corresponding netmasks, routing tables
and routing policies, Domain Name System (DNS) servers, static host name
mappings, web services, and other IP-to-service assignments. You configure
web services to allow communication with FirePass controller for the
following purposes:
• Administrator access to the Administrative Console
• User logon for access to FirePass controller features
• An HTTP server that redirects users to a secure logon page
• Failover pair and cluster synchronization
• Offloading SSL to a BIG-IP® local traffic manager
If you are configuring a failover pair or a cluster member, you also need to
configure an HTTP service for the synchronization agent. For more
information about failover configuration, see Understanding FirePass
controller high availability, on page 11-1. For more information about
clustering configuration, see Configuring FirePass controller clusters, on
page 12-2.
To access network configuration settings
1. On the navigation pane, click Device Management, expand
The Network Configuration screen opens with the IP Config tab
selected.
2. Click the tab whose settings you want to specify.
• Interfaces: Provides settings for configuring connections on the
physical ports on the FirePass controller device, such as interface
speed and duplex. For more information, see Understanding the
Interfaces tab settings, on page 8-5.
• VLAN: Provides settings for configuring VLAN tags and
interfaces. For more information, see Configuring VLAN settings,
on page 8-7.
• IP Config: Provides settings for adding, modifying, or deleting IP
addresses to interfaces. For more information, see Configuring IP
addresses and subnets, on page 8-8.
• Routing: Provides settings for determining how the FirePass
controller should forward IP traffic. For more information, see
Configuring routing tables and rules, on page 8-9.
• DNS: Provides settings for configuring the IP addresses and
domain suffixes that the FirePass controller uses. For more
information, see Configuring DNS, on page 8-16.
8-2
• Hosts: Provides settings for configuring the fully qualified
domain name (FQDN) for the FirePass controller, and for
specifying entries that FirePass should add to its static host name
mapping file. For more information, see Configuring host names,
on page 8-17.
• Web Services: Provides settings for configuring web services,
and for managing SSL server certificates. For more information
about web service configuration, see Configuring web services,
on page 8-18, and for more information about SSL server
certificates, see Understanding SSL server certificates, on page
4-1.
• Misc: Provides settings for configuring which IP source
addresses FirePass should use for other various functions. For
more information, see Configuring other network settings, on
page 8-23.
3. When you make configuration additions, edits, or deletions, a
Finalize tab appears. No additions, edits, or deletions take effect
until you click the Finalize tab and follow the instructions for
committing the changes. Some changes require a restart of the
FirePass controller. For more information, see Changing network
configuration settings that require reboot, on page 8-4.
Understanding the finalize process
Some changes to web services settings require a restart of the FirePass
controller as part of the finalize process. When you complete the finalize
operation, the new configuration becomes effective immediately, unless the
change requires a system restart. In that case, the FirePass controller
prompts you to restart the system. You can cancel the restart operation, but
the system cannot commit your changes until you restart the FirePass
controller.
All of the settings and operations described in this section refer to options
available in tabs on the Network Configuration screen. To access the screen,
click Device Management, expand Configuration, and click Network
Configuration. Then click the tab indicated in the section to find the
associated options.
Changing network configuration settings that do not require reboot
When you make the changes described in this section, you can finalize
changes without restarting the FirePass controller.
◆
VLAN tab
• Add, modify, and delete new or existing VLANs
• Assign IP addresses to new VLANs
8-3
Chapter 8
◆
Routing tab
• Add, modify, and delete new or existing routing tables
• Add, modify, and delete new or existing routes in routing tables
• Add, modify, and delete new or existing routing rules
◆
Hosts tab
• Add, modify, and delete new or existing static Hosts entries
◆
Misc tab
• Any change on the Misc tab
◆
IP Config tab
• Add, modify, and delete the IP address of an existing interface or
VLAN
Important
If there is a web service running on the interface or VLAN, then you must
reboot the system. If there is no web service associated with the IP address
being changed, then you do not need to reboot it.
You can make some other IP configuration changes without restarting the
FirePass controller, but some of the changes require one. For changes that
require a restart, the FirePass controller posts a prompt. For more
information, see Changing network configuration settings that require
reboot, following.
Changing network configuration settings that require reboot
When you make the changes described in this section, you must restart the
FirePass controller as part of the finalize process.
• Interfaces tab
Any change to the interface options
• DNS tab
Any change to the DNS options
• Web Services tab
Any change to the web service configuration options
• Failover tab
Any change to the failover configuration options
• Clustering tab
Any change to clustering configuration options
• Hosts tab
Changing the host name of the FirePass controller, if you have enabled
failover
8-4
Understanding the Interfaces tab settings
You can use settings on the Interfaces tab to specify the functionality of the
physical ports into the FirePass controller. Each port is an independent
network interface that you must connect to separate subnets. The number
and types of ports available varies, depending on the FirePass controller
model you have.
You can determine which ports you have on the Interfaces screen. To access
the screen, in the navigation pane, click Device Management, expand
Configuration, click Network Configuration, and click the Interfaces tab.
In addition to the built-in ports, the FirePass controller may also have
VLAN interfaces defined. You can find additional configuration options on
the Interfaces tab for these logical interfaces. For more information about
VLAN configuration, see Configuring VLAN settings, on page 8-7.
Important
Any additions, deletions, or configuration changes you make do not take
effect until you commit them using the Finalize tab. Some configuration
changes require that you restart the FirePass controller for them to take
effect. For more information, see Changing network configuration settings
that require reboot, on page 8-4.
8-5
Chapter 8
Specifying ports for the FirePass 4100
The FirePass 4100 provides the following network ports:
• The Management port, called Management in the configuration user
interface, provides a direct connection to the FirePass 4100’s
Administrative Console. It runs only administrative services.
• There are four 1000 mbit ports available on the FirePass 4100 controller.
These are labeled 1.1 - 1.4 on the controller chassis and eth1.1 - eth1.4 in
the configuration user interface.
The eth1.1 port connects the FirePass 4100 to your main network. It runs
user and administrative services.
We recommend that you use eth 1.1 to connect to your network.
You can use the eth 1.2, eth1.3, and eth 1.4 ports for other purposes, or for
additional segmentation as required by your network.
• The WAN port (PCI Ethernet card), called eth0 in the configuration user
interface, connects the FirePass controller to the WAN.
You can use eth0 as a WAN port to connect to the Internet. We
recommend that you use eth0 to connect to your network. The eth0 port
is a 10/100 mbit port that is not labeled on the controller chassis.
• The LAN port (the left port of the pair of ports), called eth1 in the
configuration user interface, connects the FirePass 4000 to your main
network. It runs user and administrative services.
The eth1 port is a 10/100 mbit port that is not labeled on the controller
chassis.
• You can use the right port of the pair of ports, called eth2 in the
configuration user interface, for another purpose, or for additional
segmentation as required by your network.
The eth2 port is a 10/100/1000 mbit port that is not labeled on the
controller chassis.
• The WAN port, called eth0 in the configuration user interface, provides a
direct connection to the FirePass 1000’s Administrative Console. It runs
only administrative services.
• The LAN port, called eth1 in the configuration user interface, connects
the FirePass 1000 to your main network. It runs user and administrative
services.
• You can use the DMZ port, called eth2 in the configuration user
interface, for other purposes, such as dedicating it to failover
synchronization.
8-6
The FirePass 1200 provides two 10/100 mbit ports. These are labeled 1 and
2 on the controller chassis and Port1 and Port2 in the configuration user
interface.
• The Port 1 port is used for primary user and administrative services. Use
this port to connect the FirePass controller to your network.
• The Port 2 port is available for other services, such as failover
synchronization, DMZ use, or protecting your wireless LAN.
Configuring VLAN settings
On the FirePass controller, you can configure virtual local area networks
(VLANs). Segmenting computers into VLANs has many advantages.
◆
Flexible configuration
VLANs are configured through software rather than hardware, which
makes them extremely flexible.
◆
Subnet-to-user-group mapping
Using VLANs, you can map incoming Network Access connections to
different subnets, based on the user’s master group.
◆
Performance improvement through broadcast domain restriction
Using VLANs reduces the size of broadcast domains, so requests for
MAC addresses can be handled within a smaller IP address space.
◆
Simplified administration
One of the biggest advantages of VLANs is that when a computer is
physically moved to another location, it can stay on the same VLAN
without any hardware reconfiguration.
For example, if the controller is connected to a VLAN-enabled Ethernet
switch on which two servers are connected on separate VLANs, you can
direct Group A to VLAN1-Server1 and Group B to VLAN2-Server1,
even if the two servers have the same IP addresses internally. In other
words, accessing the same IP address over Network Access connects
members of different groups to different physical servers in different
VLANs.
When you create a VLAN, you assign it a unique name and an identifying
tag that confirms to IEEE802.1Q standards. (The valid tag ranges are from 2
to 2010 and from 2015 to 4094.) Then you associate one or more FirePass
controller physical interfaces to the VLAN. The VLAN uses this interface
when communicating with other computers on the VLAN.
You can create associations for master group-to-VLAN Network Access
connections to limit packets to specific VLANs. That means that you can
configure a service on a specific IP address, and then specify that users’
group membership direct them to different physical servers.
8-7
Chapter 8
For specific steps, see the online help for the Network Configuration screen.
To access the screen, click Device Management, expand Configuration,
click Network Configuration, and click the VLAN tab.
Configuring IP addresses and subnets
A FirePass controller can be a member of several subnets, and it can have
several digital certificates. For those and many other reasons, it may need
more than one IP address. You can assign multiple IP addresses to each
interface.
To add, change, or delete the IP address and configure
subnets
Configuration, click Network Configuration.
The Network Configuration screen opens.
2. Click the IP Config tab.
The IP Config screen opens.
3. In the Add New IP area of the screen, add new IP addresses and
netmasks.
In the IP Configuration table, edit or delete existing IP addresses.
For each IP address, you can specify or edit the following settings:
• IP Address/Netmask
Enter the IP address in dotted-decimal notation, and the subnet
mask in CIDR notation. (Specify the netmask as the number of
bits to be masked.) For example, in dotted-decimal notation,
255.255.255.128 corresponds to a mask of 25.
For a table mapping bits notation to dotted-decimal and
hexadecimal notation, see online help for the IP Config screen.
(For access, click Device Management, expand Configuration,
click Network Configuration, and click the IP Config tab.)
• Interface
Indicate the interface associated with the IP address.
• Virtual
Indicates that this is a shared, virtual IP address.
The Virtual option is present only if you have failover enabled
on the Device Management : Configuration : Clustering and
Failover screen. Pairs of FirePass controllers configured for
failover share a virtual IP address, which enables the standby
controller to take over from the active controller if the active
controller fails, preventing interruption to remote client systems.
For more information, see Understanding FirePass controller
high availability, on page 11-1.
8-8
• Broadcast
Indicates the IP address the FirePass controller uses to send
broadcast messages. This is an optional setting. If you do not
specify a broadcast IP address, FirePass calculates a default
broadcast address from the IP address and mask.
4. When you are finished configuring IP addresses, click the Finalize
tab to commit your changes. The FirePass controller does not apply
the changes until you have finalized the configuration and restarted
the FirePass controller, if necessary.
WARNING
Be extremely careful when changing the FirePass controller’s IP
configuration settings. If you enter incorrect settings, the FirePass
controller might become inaccessible from the network. If the FirePass
controller becomes inaccessible, you must use the Maintenance Console to
reset the Firepass controller’s configuration to the default settings. For
more information, see the FirePass Controller Getting Started Guide,
available as a separate document on the F5 Networks Technical Support
Web site, http://tech.F5.com.
Configuring routing tables and rules
You can use the Routing tab on the Device Management : Configuration :
Network Configuration screen to add entries to the FirePass controller
routing table.
The Routing screen has two modes:
• light, where you can maintain the main routing table
For more information, see Using light mode to configure routing tables,
following.
• advanced, where you can add and maintain additional routing tables, and
you can maintain routing rules
For more information, see Using advanced mode to configure routing
tables and rules, on page 8-12.
Using light mode to configure routing tables
You can use light mode to modify the default gateway, and to add one or
many routes to the main routing table.
Adding one route in light mode
To add a single route in light mode
Configuration, click Network Configuration, and click the
Routing tab.
8-9
Chapter 8
2. Specify the default gateway.
The role of the default gateway is to provide the next-hop IP address
and interface for all destinations that are not located on one of the
controller’s local subnets, or for remote subnets that have an explicit
static route defined. In other words, the default gateway is used to
create a default route that directs packets addressed to networks not
explicitly listed in the routing table. This step is optional.
3. In the To (IP/Len) box, specify the destination IP address and
netmask.
Format IP addresses as dotted-decimal/length, for example
128.146.1.0/24
The Netmask (Len) is always expressed in bits notation. (That is,
the netmask is expressed as the number of bits to be masked.) For
example, a bits count of 25 corresponds to a mask of
255.255.255.128 in dotted-decimal notation.
If you specify all zeros in To (IP/Len), that is, 0.0.0.0/0, the
FirePass controller applies that route to any packet whose
destination IP address does not match that of another route.
For a table mapping bits notation to dotted-decimal and
hexadecimal notation, see the online help for the Routing screen. To
access the screen, click Device Management, expand
Routing tab.
4. In Metric, specify the number to use, from 1 to 15.
The number indicates the cost of the route, specified in number of
hops. You can represent computers on the local subnet by
specifying the number 1. For each router crossed after that, add one.
The value helps the FirePass controller determine which route to use
in the case of multiple, closest-matching routes to the same
destination address. For multiple routes to the same destination, the
route with the lowest cost metric is the most preferred route. This
step is optional.
5. From the Interface list, select the interface you want the FirePass
controller to use for the outgoing traffic.
Interface contains a list of all of the physical ports, <default>, lo,
and any VLANs you have configured. This step is optional. For
information about physical ports, see Specifying ports for the
FirePass 4100, on page 8-6, Specifying ports for the FirePass 4000,
on page 8-6, Specifying ports for the FirePass 1200, on page 8-7, or
Specifying ports for the FirePass 1000, on page 8-6, as appropriate.
6. In Via (IP), specify the gateway IP address.
7. From the Src (IP) list, select the Source IP address.
A blank source or destination IP address or Interface acts as a
wildcard and signifies all. This step is optional.
8. If this is a failover unit, select the For mode (Active Only, Standby
Only, or Always) during which this route is used. For definitions of
each option, see To configure a service, on page 8-20.
8 - 10
If you are deploying the FirePass controller in a failover
configuration, and you need the controller to use a shared IP address
as the source IP address for all the outgoing traffic from the FirePass
controller, you must specify two different default routes:
• One route for the active unit, using the redundant system’s shared
IP address. For this configuration, select the shared IP address as
the Src IP and Active Only as the mode. This causes the active
FirePass controller to always use the shared IP address as the
source IP address for all outgoing packets.
• Another route for the failover (or standby) unit, using the unit’s
device-specific, self IP address. For this configuration, select one
of the self IP addresses as the Src IP and Standby Only as the
mode. This causes the standby FirePass controller to use the self
IP address as the source IP address for all outgoing packets.
For more information about configuring web services for failover,
see Understanding FirePass controller high availability, on page
11-1.
9. In MTU and Window (Bytes), specify the size of the largest packet
to transmit.
The Maximum Transmission Unit (MTU) is a term for the
maximum represents the largest packet size allowed in a single
transmission. Windows (Bytes) represents the number of bytes a
sender can transmit without receiving an acknowledgement. It is
related to the size of the receiving buffer. This step is optional.
10. Click the Add route button.
The presence of an asterisk ( * ) next to a field name denotes a required
value.
Adding many routes in light mode
For convenience, you can add any number of blank lines to a routing table
and then edit them as a group.
To add multiple routes in light mode
Routing tab.
2. In Count, specify the number of routes you want to add.
3. Click the Add many routes button.
4. Once you have added the rows you want, you can edit the values
directly in the table, and click the Update button to have the
modifications take effect.
8 - 11
Chapter 8
Using advanced mode to configure routing tables and rules
You can use advanced mode to add one or many routes to any routing table,
to add and delete routing tables, and to add and delete routing rules.
Adding one route in advanced mode
To add a single route in advanced mode
Routing tab.
2. Select the table you want to modify from the Insert into table list.
3. In the To (IP/Len) box, specify the destination IP address and
netmask.
Format IP addresses as dotted-decimal/length, for example
128.146.1.0/24
For more information about IP address format, see step 3, on page
8-10, in the preceding procedure.
4. In Metric, specify the number to use, from 1 to 15.
For more information about the Metric option, see step 4, on page
5. From the Interface list, select the interface you want the FirePass
controller to use for the outgoing traffic.
Interface contains a list of all of the physical ports, <default>, lo,
and any VLANs you have configured. This step is optional. For
information about physical ports, see Specifying ports for the
FirePass 4100, on page 8-6, Specifying ports for the FirePass 4000,
on page 8-6, Specifying ports for the FirePass 1200, on page 8-7, or
Specifying ports for the FirePass 1000, on page 8-6, as appropriate.
6. In Via (IP), specify the gateway IP address.
7. From the Src (IP) list, select the Source IP address.
A blank source or destination IP address or Interface acts as a
wildcard and signifies all. This step is optional.
8. If this is a failover unit, select the Failover mode (Active Only,
Standby Only, or Always) during which this route is used.
For more information about this option, see step 8, on page 8-10, in
the preceding procedure, For more information about configuring
web services for failover, see Understanding FirePass controller
high availability, on page 11-1.
9. In MTU and Window (Bytes), specify the size of the largest packet
to transmit.
For more information about the Metric option, see step 9, on page
10. Click the Add route button.
8 - 12
The presence of an asterisk ( * ) next to a field name denotes a required
value.
Adding many routes in advanced mode
For convenience, you can add any number of blank lines to a routing table
and then edit them as a group.
To add multiple routes in advanced mode
Routing tab.
2. Click the Switch to advanced mode link to switch to the advanced
routing mode.
The Advanced Routing Mode screen opens.
3. In Add many empty routes, select the table you want to modify from
the Insert into table list.
4. In Count, specify the number of routes you want to add.
5. Click the Add many routes button.
6. Once you have added the rows you want, you can edit the values
directly in the table, and click the Update button to have the
modifications take effect.
Editing and deleting routes in advanced mode
If you are in light mode, switch to advanced mode by clicking the Switch to
advanced mode link.
To edit a route, change the value in the table and click the Update button.
To delete a route, check the check box to the left of the route or routes you
want to delete, and click the Delete Selected button at the bottom of the
table.
Adding, editing, and deleting routing tables in advanced mode
You can add up to 252 routing tables. The kernel reserves tables 254 and
255, and the FirePass controller reserves table 253. You can add tables 1
through 252. Routing table lookup order depends on IP rules priority, and
and does not rely on the routing table number.
To add a routing table
Routing tab.
8 - 13
Chapter 8
routing mode.
3. Scroll down to the Add new routing table section.
4. In the Name box, type the string to use to identify the routing table.
Routing table names can contain up to 512 alphanumeric and
underline ( _ ) characters. The string you specify cannot match the
name of an existing table.
5. In the Number box, specify a number from 1 to 252.
To edit a routing table
Routing tab.
routing mode.
1. Click the link to display the routing tables.
2. Change directly in the table the value for To (IP/Len), Metric,
Interface, Via (IP), Src (IP), MTU, or Window (bytes), as
described in the preceding procedure.
The presence of an asterisk ( * ) denotes a required value.
To delete a table
Routing tab.
routing mode.
1. Click the link to display the routing tables.
2. Click the delete icon
to the right of the table you want to delete.
WARNING
Routing table deletion occurs immediately, without a confirmation alert, so
be sure you are ready to delete the table when you click the delete icon.
8 - 14
Adding routing rules in advanced mode
You can specify rules that manage which routing tables to use, and in what
order, for particular routes or groups of routes. A blank source or destination
IP address signifies that FirePass routs all incoming traffic.
To add a rule
Routing tab.
routing mode.
1. In the From box, type the source IP address and netmask.
The FirePass controller applies the rule to incoming IP packets
matching the address and netmask specified.
2. In the To box, type the destination IP address and netmask.
The FirePass controller applies the rule to outgoing IP packets
matching the address and netmask specified.
3. From the Interfaces list, select the interface you want the FirePass
controller to apply the rule to.
Available interfaces include all of the physical interfaces and any
defined VLANs.
4. In Table, specify the target routing table for this rule.
When an incoming IP packet matches this rule, it is routed as
specified in this table.
5. In Priority, specify a number from 0 to 32765, with lower numbers
representing higher priority for this rule. The FirePass controller
assigns the main table the number 32766 and default the number
32767.
The value in the Priority field controls the order in which the
FirePass controller applies the rules. The lower the number, the
higher the priority, and the earlier the rule is evaluated during the
routing operation. The FirePass controller routes the traffic
according to the first match in the table.
Editing and deleting routing rules in advanced mode
You can edit rule values directly in the rules list.
To edit routing rules
Routing tab.
8 - 15
Chapter 8
routing mode.
1. Scroll to the Rules area of the screen.
2. Change directly in the list the value for To, From, Interface,
Table, and Priority, as described in Adding routing rules,
preceding.
The presence of an asterisk ( * ) denotes a required value.
3. Click the Update Table button.
To delete a routing rule
Routing tab.
routing mode.
3. Scroll to the Rules area of the screen.
4. Check the check box to the left of the rule or rules you want to
delete.
There is no check box next to the predefined rules, identifiable by
the priority values of main: 32766 and default: 32767, because you
cannot delete these rules.
5. Click the Delete Selected button at the bottom of the list.
Configuring DNS
You can change the IP addresses of the DNS you want the FirePass
controller to use. You also can specify the FirePass controller’s default
domain suffixes.
To configure the DNS
Configuration, click Network Configuration, and click the DNS
tab.
The DNS configuration screen opens.
2. In the Name Servers area of the screen, specify the IP addresses of
up to three DNS servers.
3. In the Default domain suffixes area of the screen, specify up to six
domain suffixes.
The FirePass controller uses these values to resolve incomplete
domain names. For example, if the domain suffix list contains the
8 - 16
entries f5.com and com, and a user submits the URL
http://www.support, the controller resolves the host names in the
following order:
http://www.support
http://www.support.f5.com
http://www.support.com
Important
effect until you commit them using the Finalize tab.
Configuring host names
You can specify the FQDN, add, edit, and delete static host names.
The FQDN specified here serves only to provide the unique identification of
the FirePass controller. Changing this field does not lead automatically to
any changes anywhere else (for example, web services configuration).
The FirePass controller stores static host names in a local table, and uses
them to augment or override the configured DNS. The FirePass controller
uses the local table to locate an IP address for a domain name, before
consulting the DNS.
Important
effect until you commit them using the Finalize tab.
Specifying the FirePass controller’s FQDN
To configure the FQDN
Configuration, click Network Configuration, and click the Hosts
tab.
The Hosts configuration screen opens.
2. In FQDN of the controller, specify the fully qualified domain
name, for example
fp4100.sales.siterequest.com
Note: Both nodes of a redundant system must have the same FQDN.
8 - 17
Chapter 8
Adding, editing, and deleting static host names
To add a static host name
Configuration, click Network Configuration, and click the Hosts
tab.
The Hosts configuration screen opens.
2. In Hostname, type the name of the static host.
3. In IP, type the IP address of the static host.
4. Click the Add New button to add the name to the list of local host
names.
Configuring web services
You can configure web services for several classes of operation.
• User logon and functionality
You must have at least one service configured to allow User access.
• Administrator logon
You must have at least one SSL-enabled service configured to allow
Administrator access.
• Web access bypass
• Offloading SSL to a BIG-IP local traffic manager
• Synchronization among clustered and failover units
If you have a clustering or failover configuration, you must configure for
use by the Synchronization Agent, at least one service that is not
redirected to an SSL service.
You can configure services to use different roles and different ports,
although they might also share roles and ports. A service consists of any
distinct combination of roles, functionality, and IP address/port assignment.
Understanding services configuration
You can configure services using options on the Network Configuration
screen. The screen presents a list of the currently configured services. You
can also add new web services. To view or modify current settings for a web
service, click its associated Configure link. The Web Server Configuration
details screen opens. For descriptions of each option, see To configure a
service, on page 8-20.
8 - 18
The Services column of the table of web services contains one or more of
the codes described in Table 8.1, following.
Code
Meaning
You must configure
A
Configured to allow administrator access
At least one
B
Configured for WebAccess Bypass
Optional
E
Configured to offload SSL processing to
BIG-IP system
Optional
S
Configured as a synchronization port
At least one, if you have
failover or clustering
configured
U
Configured to allow user access
At least one
Table 8.1 Web services codes and roles
Note
If you plan to configure clustering or failover, you must configure a service
for the Synchronization Agent to use. This service must allow HTTP access
and not redirect to an SSL service, so you do not typically use the same
service for synchronization and for user access. For more information, see
Chapter 11, Using FirePass Controllers for Failover, and Chapter 12,
Using FirePass Controllers in Clusters.
To add a service
The Web Services screen opens.
3. Scroll to the Add new service area.
4. From the list of IP addresses configured for the FirePass controller,
select the IP address to use for the new service.
You can add IP addresses using options on the IP Config tab. For
more information, see Configuring IP addresses and subnets, on
page 8-8.
5. In Port, specify the port to use for this service.
6. In Name, assign a name to the service, or specify the fully-qualified
domain name of the service listening on this port.
7. Check the SSL check box to specify encrypted communications.
F5 Networks recommends enabling SSL for all services other than
those that provide redirect, offload, or synchronization support, and
when you need to provide access to devices that do not support SSL.
8 - 19
Chapter 8
The new service now appears on the configured services table.
Configure it according to instructions in the following procedure.
To configure a service
1. Click the Configure link in the row next to the service you want to
modify.
The configuration detail screen opens.
2. In Hostname, specify the FQDN of the service.
This step is optional, depending on the IP address you are
configuring, and whether you have entries in your DNS
corresponding to the IP address.
For example, if you are configuring the self IP address on a failover
pair, you might not want to specify FQDN, but if you are
configuring the shared IP address on a failover pair, you do. For
more information about IP addresses for failover pairs, see
Configuring the active controller with a self IP address, on page
11-9, and Configuring the active controller with a shared IP
address, on page 11-10.
Note: The CN on the certificate should match the hostname of the
web service that the certificate is assigned to. You could have
multiple hostnames if you have multiple IP addresses configured.
3. In IP Address, select the IP address configured for the FirePass
controller.
You can add a new IP address using options on the IP Config tab.
For more information, see Configuring IP addresses and subnets, on
page 8-8.
4. In Port, modify the port number for this service.
5. Check Use SSL, to enable secure communication for this service.
The screen refreshes, revealing the following options:
• From the Certificate list, select an installed certificate.
To use SSL, you must have an SSL certificate installed on the
computer.
• You can also edit existing certificates, generate a request for a
new certificate, or generate a self-signed certificate using the
links provided.
Note: The FirePass controller includes a preconfigured, default SSL
server certificate for firepass.company.xyz. You can use this
certificate while configuring and testing a FirePass controller, but
the certificate is not unique, and the certificate’s server name will
not match the name you give to the FirePass controller, so anyone
connecting to the FirePass controller sees warning messages from
their web browser. Before you make the FirePass controller
available to external users, you should replace the default server
certificate with a signed certificate. For more information, see
Installing a server certificate, on page 4-6.
8 - 20
6. If you do not check Use SSL, you can also configure the following
options:
• In HTTPS URL to redirect to, specify the name of a server or
service to which to forward the session. You can leave this field
blank.
• Check the Do not redirect to HTTPS check box to permit access
to browsers that do not support SSL communication, for
example, mini-browsers on some Internet-enabled mobile phones
and PDAs.
7. Check the Synchronization Agent check box to indicate that you
want the synchronization agent to use this service for cluster or
failover configuration synchronization. A synchronization service:
• Must allow HTTP connections, without redirecting to an HTTPS
service.
• Must not be on a shared IP address if it is to be used for
synchronizing failover pairs for high availability.
• Must be on a virtual IP address if it is to be used for
synchronizing clusters of failover pairs.
Note: The Synchronization Agent option is visible only when
clustering or failover is configured. For more information, see
Chapter 11, Using FirePass Controllers for Failover, and Chapter
12, Using FirePass Controllers in Clusters.
8. Check User Logon to allow an end-user to log on using this web
service.
9. Check Admin Logon to allow administrators to log on using this
web service.
If this box is not checked, the FirePass controller redirects a logon
request to the standard end-user interface, so that even with a valid
administrator logon, the user does not have access to the
administrative functions.
10. Check WebAccess Bypass to restrict the service to web application
favorites that are configured to use the minimal content rewriting
bypass feature.
For more information about configuring for minimal content
rewriting, see Configuring the Alternative Host/Port-based type of
11. Check Offload SSL processing to a BIG-IP Local Traffic
Manager to use the BIG-IP local traffic manager to handle the SSL
processing that the FirePass controller normally performs as part of
processing the secure client request. For more information about
how to configure this feature, see Offloading SSL Processing to
BIG-IP system, following.
8 - 21
Chapter 8
12. From For Mode, select the failover option you want the web
service to use.
• Always: Indicates that this web service always runs, regardless of
the role configured for the controller.
Always is used for web services configured for synchronization
on the device-specific, self IP address.
• Active Only: Indicates that this web service runs only when the
controller is functioning in an active role.
Active Only is used for web services on the shared IP address
configured for failover.
• Standby Only: Indicates that this web service runs only if the
controller is in a standby state.
Standby Only is rarely used. It is used only for admin access to
the standby unit, without first having to check whether the first or
second unit is standby.
The For Mode list is visible only when you have failover
configured. For more information see Chapter 11, Using FirePass
Controllers for Failover.
Offloading SSL Processing to BIG-IP system
You can configure the FirePass controller to offload its processor-intensive
SSL transactions to a BIG-IP local traffic management (LTM) system,
version 9.x. When you enable this feature, the LTM system performs the
following functions:
• Accepts and processes any HTTPS connections sent by clients.
• Acts as a proxy between the requesting client and the FirePass controller.
• Establishes an HTTP connection with the FirePass controller.
• Delivers HTTP content to the FirePass controller.
This section includes the following topics:
◆
Understanding BIG-IP system, following
◆
Using virtual servers on BIG-IP system, on page 8-23
◆
Configuring offloading of SSL processing, on page 8-23
Understanding BIG-IP system
The LTM system is specifically designed to manage local network traffic.
Local traffic management refers to the process of managing network traffic
that comes into or goes out of a local area network (LAN), including an
intranet.
A commonly-used feature of the LTM system is its ability to intercept and
redirect incoming network traffic, for the purpose of intelligently tuning the
load on network servers. However, tuning server load is not the only type of
local traffic management. The LTM system includes a variety of features
that perform functions, such as inspecting and transforming header and
8 - 22
content data, managing SSL certificate-based authentication, and
compressing HTTP responses. In so doing, the LTM system not only directs
traffic to the appropriate server resource, but also enhances network security
and frees up server resources by performing tasks that web servers typically
perform.
Using virtual servers on BIG-IP system
When you create a virtual server, you specify its type, either a host virtual
server or a network virtual server. Then you can attach various properties
and resources to it, such as application-specific profiles, session persistence,
and user-written scripts called iRules that define pool-selection criteria.
When associated with a virtual server, the collection of properties and
resources determines how the LTM system manages local traffic.
For information about configuring virtual servers and managing SSL on the
BIG-IP LTM system, see the BIG-IP LTM documentation.
Configuring offloading of SSL processing
When you offload SSL processing, you configure the FirePass controller to
allow insecure access, so that you can establish an HTTP network
connection between the controller and BIG-IP system. Configuring the
offloading of SSL processing involves two tasks:
• Configuring the FirePass controller
• Configuring BIG-IP system
For more information about offloading to SSL, see the deployment guide
that describes configuring the FirePass controller and BIG-IP system, on the
Solution Center site at http://www.f5.com/solutions/.
Configuring other network settings
You can use options on the Misc tab on the Device Management :
Configuration : Network Configuration screen to select which IP address to
use for the NetBIOS network broadcasts, and NAS IP Address for RADIUS
Requests. The source addresses selected here should be those assigned to
interfaces facing your internal network. The screen presents the following
options
◆
NetBIOS broadcast source address
Represents the IP address that the Portal Access feature Windows Files
uses to browse Microsoft Windows file servers. Generally, you should
set this IP address to the internal address that the corporate LAN uses to
route data back to the FirePass controller.
◆
NAS IP Address for RADIUS Requests
Represents the IP address that the FirePass controller inserts as RADIUS
attribute 4, NAS-IP-Address for all of the requests the FirePass controller
makes to the RADIUS server. This value should match the
NAS-IP-address configured on the RADIUS server as a part of the
authentication policy.
8 - 23
Chapter 8
Important
Any changes you make do not take effect until you commit them using the
Finalize tab.
Configuring access scope
You can control access to App Tunnel and Web Applications resources by
specifying a list of hosts that the system allows end users to access. You can
specify access control lists in the following locations:
• On the Common tab, available on the Application Access : App Tunnels
: Master Group Settings screen
• On the Application Tunnel tab, available on the Application Access :
App Tunnels : Resources screen
• On the Application Tunnel tab, available on the Application Access :
App Tunnels : Resources screen
• On the Web Application Tunnel tab, available on the Application Access
: App Tunnels : Resources screen
• For each favorite you configure for Application Tunnels or Web
Application Tunnels in Application Access
You can specify an entry in the list using the following format, using a
return to separate each entry:
hostname [:port]
ip_address [:port]
• hostname
Represents the host name or IP address to which you want to allow the
user access. You can use the wildcard characters asterisk ( * ), which
single character. For example:
*.site*quest.com:23,80,443
*.siterequest*:23-25
• port
Represents a port number or a range of ports. If you do not specify a port,
the system allows connections on all ports.
For example:
www.siterequest.com:80
www.siterequest.com:23-25
www.siterequest.com:23-25,80,4
172.30.11.0/24:8
172.30.11.0/255.255.255.0:0-65535
You cannot specify a protocol or URI in any access scope list.
The system combines all entries from each list. The static, dynamic, and
web application tunnels then share the list during a session.
8 - 24
The entries you define in any access control or allow list fall outside the
scope of the Limit AppTunnels Access to Favorites only (for Extranets,
partner and customer access, etc.) and Allow Direct Connection options.
Specifying an entry in an allow list enables the user to access to that
location.
When you create a new resource group and select an existing resource group
to copy settings from, the system includes any entries in the access control
list.
You can have the system add an entry to the list based on a URL you type
when defining a favorite. This feature exists on the Web Application
Tunnels tab, available on the Application Access : App Tunnels : Resources
screen.
You can also specify an allow list on the Portal Access : Web Applications :
Resources screen. The system uses these entries for Portal Access Web
Applications only, and not for any App Tunnel connections.
To add an entry for Web Applications Tunnels in
Application Access
The Application Access : App Tunnels : Resources screen opens.
2. Click the Web Applications Tunnels tab.
The Web Applications Tunnels favorites screen opens.
4. In URL, type a URL.
5. Click the Add to allow list link.
The entry appears in the Allow list box.
To add an entry for Web Applications in Portal Access
Applications, and click Resources.
The Portal Access Resources screen opens.
3. In URL, type a URL.
4. Click the Add to allow list link.
The entry appears in the Allow list box.
To control visibility of the favorite’s allowed-hosts list, click the show
favorites allow list link on the Application Access : App Tunnels :
Resources screen, or on the Portal Access : Web Applications : Resources
screen.
8 - 25
Chapter 8
Introducing realms
An administrative realm is a complete set of roles, master groups, and
resource groups. The concept of realms extends the existing role-based
administration and simplifies FirePass controller administration by
providing an organizational structure for master groups and their associated
resource groups.
A FirePass controller realm consists of a set of defined master and resource
groups and realm administrators, with feature access delegated them by a
superuser. Superusers are users who have cross-realm access to all groups
and features. A superuser creates realm administrators, upgrading them from
FirePass controller users, and delegating full or restricted access to FirePass
controller functionality or groups. Realm administrators are users who can
create their own hierarchy of access to the groups and resources inside their
realm. In a typical setup, the master and resource groups of one realm are
not accessible to administrators of another realm, although superusers or
realm administrators can grant access across realms.
The FirePass controller provides a default realm named Full Access
containing a default superuser account named admin. Full Access gives
superusers complete access to realm-configuration. Everyone serving as
administrator in the Full Access realm is considered a superuser. Superusers
have a realm list in the menu bar of the Administrative Console that enables
navigation to other realms.
Superusers can grant users administrative access to the Full Access realm.
Realm administrators can grant users administrative access only to their own
realm. An administrator in one realm cannot be an administrator in any other
realm, including the Full Access realm.
Tip
Realms are particularly useful for managing groups with clear functional or
geographic divisions and in the service-provider scenario.
Configuring the Full Access realm
The first time the first superuser logs on to a FirePass controller, the screen
for Administrative Realms contains one realm, Full Access, and one
account, admin. The only actions available inside the Full Access realm are
adding and deleting administrators. To set feature and group access, the
superuser must first create a realm.
Only a superuser can add other superusers, create or delete realms, configure
default features and groups for a realm, and delete realms in the Full Access
realm.
A given user can serve as administrator in only one realm. If you have
administrators who need access to more than one realm, you can add them to
the Full Access realm, where they will have access to all realms.
8 - 26
Configuring the FirePass controller for realms
When you have a complete subset of users who need access to a specific set
of resources, realms can give you the higher-level grouping mechanism you
need. The following tasks encompass the general process for realm
configuration:
• Add superusers.
For step-by-step procedures for adding superusers, see the online help the
Device Management : Security : Administrative Realms screen.
• Create realms.
For step-by-step procedures for creating realms, see the online help the
• Specify realm administrators.
For step-by-step procedures for specifying realm administrators, see the
online help for the Device Management : Security : Administrative
Realms screen.
• Specify default features and groups for each realm.
For more information, see Configuring realm-specific settings,
following.
• Add administrators within the realm.
For more information, see Assigning administrative privileges to a user
accounts, on page 8-29.
• Restrict a realm administrator's access.
For more information, see Configuring realm-level group access,
following, and Configuring realm-level feature access, on page 8-28.
Configuring realm-specific settings
It is often difficult to determine which set of administrators should do
specific tasks, since each network setup is unique. But generally, realm
administrators do the realm-level configuration, that is, configuration
restricted to the associated administrator’s realm. However, depending on
the setup, a realm-level administrator might not have access to
administrative functions. In that case, an administrator from the Full Access
realm would also do the following tasks:
• Assign administrative privileges to a user account
• Add a superuser
• Create and delete a realm
• Add and delete a realm administrator
• Configure default features and groups for a realm
• Specify which groups and features are accessible in a realm
• Restrict a realm administrator's access
A realm administrator or superuser can perform these realm-based
operations using the Administrative Realms screen. To access the screen,
click Device Management, expand Security, and click Administrative
8 - 27
Chapter 8
Realms. Realm administrators or superusers can use the Edit link in the
Administrators column associated with the specific realm to add and delete
administrators for the realm.
WARNING
All delete operations occur immediately, without a confirmation alert, so be
sure you are ready to delete a realm or an administrator before you click
Delete.
Configuring realm-level group access
On the Device Management : Security : Administrative Realms screen,
realm administrators or superusers can use the Edit link in the Group access
column associated with the specific realm to specify which groups
administrators can access.
By default, the list presented represents the groups available in the
administrator’s Administrative Console. Administrators can restrict
accessibility to specific groups by clearing the Allow access to all groups
check box. After saving, administrators can use Edit again to specify which
groups the realm should contain.
Modifying access at this level affects all administrators in a realm. Realm
administrators or superusers can specify administrator-level restrictions
using the groups link in the Administrators column for the associated realm.
Note
If the groups link is not present, it means that the realm is not configured to
have access to any groups.
Configuring realm-level feature access
On the Device Management : Security : Administrative Realms screen,
realm administrators or superusers use the Edit link in the Feature access
column associated with the specific realm to specify which navigational
areas the administrators can access.
By default, the list presented represents the links in the navigation pane of
the FirePass controller’s Administrative Console. To control access in the
realm, administrators can check the Allow access to all features check box,
or check or clear the check box next to each feature.
Modifying access at this level affects all administrators in a realm. Realm
administrators or superusers can specify administrator-level restrictions
using the features link in the Administrators column for the associated
realm.
Note
If the features link is not present, it means that the realm is not configured
to have access to any features.
8 - 28
Configuring administrator-specific access
Providing they have access to the Device Management: Security :
Administrative Realms screen, realm administrators and superusers can use
the features or groups links associated with a realm administrator to grant or
restrict access to specific groups or features.
By default, the list presented when administrators click the features link
represents the navigation pane available to all users and administrators in the
realm.
The features link for a specific administrator is the one you use to restrict
access to administration tasks. When the realm administrator or superuser
clears the Administrative Realms check box, the navigation pane in the
associated administrator’s Administrative Console no longer displays the
Administrative Realms item.
Assigning administrative privileges to a user accounts
You can configure any existing user account with administrative privileges.
F5 Networks recommends giving administrative access to separate user
accounts rather than sharing a single account, in realms with more than one
administrator. That way, you can better track which administrator made a
change.
Important
Because superusers have cross-realm access and because they can add
other superusers, you should make sure to add only trusted sources as
administrators of the Full Access realm.
The FirePass controller logs all activities of any user with administrative
privileges in Application Logs. You can find Application Logs on the
Reports : App Logs screen.
Adding realm administrators
A superuser must add the first realm administrator. After that, any
administrator in the realm can do this, provided they have access to the
By default, the new administrator has access to all features and groups in the
realm. Any superuser or realm administrator can restrict access using the
features and groups links next to the administrator's name. We recommend
that you allow only superusers access to the Realms screen.
For more information, see Configuring administrator-specific access,
preceding, and procedures in the online help for the Device Management :
Security : Administrative Realms screen.
8 - 29
Chapter 8
Deleting realm administrators
A superuser and any administrator in the realm can delete a realm
administrator, provided they have access to the Device Management :
Security : Administrative Realms feature.
WARNING
Realm delete occurs immediately, without a confirmation alert, so be sure
you are ready to delete an administrator before you click Delete.
Upgrading with administrators configured in versions previous to
FirePass 5.4
Versions previous to FirePass 5.4 did not support realms. When you upgrade
to versions later than 5.4, the upgrade process creates a realm called
Administrators to contain each existing FirePass controller administrator.
Each account in the Administrators realm retains the group and feature
access assignments you configured in the previous version.
Using reports inside realms
Reports show only realm-specific statistics.
8 - 30
Completing other configuration activities
You can configure other admin-level functionality using options under the
Configuration item in the navigation pane.
◆
Specifying the FirePass administrator’s email address
For more information, see Configuring Admin Email, following.
◆
Adding definitions for other types of browsers
For more information, see Adding definitions for other types of browsers,
on page 8-32.
◆
Configuring a new RSA SecurID server
For more information, see Configuring a new RSA SecurID
authentication server (for Native RSA authentication), on page 8-33.
◆
Specifying the SMTP email server
For more information, see Specifying the SMTP email server, on page
8-37.
◆
Configuring an SNMP agent
For more information, see Configuring an SNMP agent, on page 8-38.
◆
Specifying HTTP and SSL proxies
For more information, see Specifying HTTP and SSL proxies, on page
8-39.
◆
Specifying the time, time zone, and NTP server
For more information, see Specifying the time, time zone, and NTP
server, on page 8-40.
Configuring Admin Email
You can specify the address and other information for the FirePass
controller to use when sending email security alerts and notifications to the
administrator. The Device Management : Configuration : Admin Email
screen contains several settings that you can specify.
◆
Admin E-Mail Address
Indicates the recipient address of the notification. This is the address that
the email contains in its “to” field.
◆
E-Mail From Name
Identifies the FirePass controller that generated the email. You can
specify %serialnumber% to insert the serial number of the FirePass
controller.
◆
E-Mail From Address
Indicates the sender of the email. This is the address that the email
contains in its “from” field. You can specify %serialnumber% to insert
the serial number of the FirePass controller.
◆
Reply-To E-Mail Address
Indicates email address that you want end users to use when replying to
notices that the FirePass controller sends.
8 - 31
Chapter 8
To configure Admin Email
Configuration, and click Admin Email.
The Administrator’s Email Address screen opens.
2. In Admin E-Mail address, specify the administrator’s email
address for the FirePass controller to send notifications to.
3. In E-Mail From Name, type the information that identifies the
FirePass controller that sent the email. You can use the variable
%serialnumber% along with any other identifying text. When you
use %serialnumber%, the FirePass controller replaces it with the
originating FirePass model and serial number when it generates the
email-from name.
For example, to indicate that an alert originated from a specific
FirePass controller in your branch office in Japan, you could type
FirePass 4100 %serialnumber% Japan branch office
4. In E-Mail From Address, specify the email address of the FirePass
controller that is sending the email. You can use the variable
%serialnumber% to include in the email address the model and
serial number of the originating FirePass controller.
For example, you could specify
support%serialnumber%@firepass.co.xyz or
support@%serialnumber%.co.xyz
5. In Reply To E-Mail Address, you can specify an email address
where recipients should reply when the FirePass controller sends
them email.
Although this is an optional field, specifying a value ensures that
replies to the email go to a valid recipient SMTP address, instead of
to the FirePass controller, which cannot receive SMTP mail.
Adding definitions for other types of browsers
You can add and classify definitions browsers, such as mini-browsers and
phones. All browsers do not support all functions on all devices. For
example, you cannot use caching on phones. So the FirePass controller
restricts some functionality to suitable browsers.
Browsers identify themselves by the user-agent field they send in their
HTTP headers, which classifies them as full browsers, mini-browsers, or
phone browsers. You can use options on the Device Management :
Configuration : New Browsers screen to configure additional browsers.
To add a definition for a browser
Configuration, and click New Browsers.
The Classify new browser type screen opens.
8 - 32
2. In the User Agent text box, type or paste the user-agent string
exactly as it appears in the HTTP header the browser sends in the
HTTP request.
For example, for Mozilla 1.7.8, the User-Agent is
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511
You can find other user-agent strings by referring to your browser’s
documentation, and by inspecting the user-agent HTTP header that
the browser sends.
3. From Type, select a browser type from the list.
• Desktop Browser
• Minibrowser
• i-mode phone
• HDML, or early WAP phone
• WAP 1.1+ phone
• Pocket PC browser
4. Check the Supports images and Supports color options according
to the capabilities of the browser.
5. Check the Supports UTF-8 option to enable UTF-8 support for
browsers that support UTF-8.
Note: The Desktop browser and Pocket PC browser provide built-in
support for UTF-8, so the system keeps this option selected for these
browsers.
The browser definition is added to the list on the Force New
Browser Type panel.
Configuring a new RSA SecurID authentication server (for Native
RSA authentication)
To enable communications between the FirePass controller and the RSA
Authentication Manager / RSA SecurID Appliance, you must add an agent
host record to the RSA Authentication Manager database. The agent host
record identifies the FirePass controller within its database and contains
information about communication and encryption.
The process of configuring the FirePass controller to work with an RSA
SecurID authentication server requires several tasks.
◆
On the RSA SecurID authentication server, configure the server to
recognize the FirePass controller as an agent host.
For more information, see Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an agent
host, following.
8 - 33
Chapter 8
◆
On the RSA SecurID authentication server, identify the users who are
authorized to use the FirePass controller.
For more information, see Step 2: On the RSA SecurID authentication
server, identify the users who are authorized to use the FirePass
controller.
◆
On the FirePass controller, import the server configuration file.
For more information, see Step 3: Configure the FirePass controller to
use the RSA SecurID authentication server, on page 8-35.
For more information about how to use the RSA SecurID authentication
method, see Setting up RSA SecurID authentication, on page 2-61.
You can also find information about setting up the RSA SecurID
authentication server on the Solution Center at
http://www.f5.com/solutions/.
Step 1: Configure the RSA SecurID authentication server to recognize the
FirePass controller as an agent host
To configure the RSA SecurID authentication server to recognize the
FirePass controller as an agent host, you must add the FirePass controller as
an agent host in the RSA Authentication Manager. To create the agent host
record, you must have the following information.
• The name of the FirePass controller
• The actual IP addresses for all network interfaces of the FirePass
controller, including all failover pairs and cluster members
If you use the RADIUS method, then configure the FirePass controller as a
Communication Server agent type on the RSA Authentication Manager
(RSA ACE/server). If you use the SecureID (Native RSA Protocol) method,
configure the FirePass controller as a UNIX agent. The RSA Authentication
Manager uses this setting is to determine how communication with the
FirePass controller occurs.
Important
Host names within the RSA Authentication Manager / RSA SecurID
Appliance must resolve to valid IP addresses on the local network.
To add the FirePass controller as an agent host on the RSA SecurID
authentication server
1. On the administrative interface of your RSA SecurID authentication
server, click the Agent Host tab, and select the Add Agent item.
2. In Name, specify a name for identifying the FirePass agent host
configuration.
This may or may not be a DNS-resolvable name. This name can be
different from the FQDN configured on the FirePass controller.
8 - 34
3. In Network address, type the IP address used by the FirePass
controller while communicating with the RSA SecurID Server.
This address must be the source IP address present in the IP packets
received by the RSA SecurID Server from the FirePass controller.
Note: You will need this address in Step 3: Configure the FirePass
controller to use the RSA SecurID authentication server, on page
8-35.
4. From the Agent Type list, select UNIX Agent.
5. For Encryption Type, select DES.
6. Clear the Node Secret Created check box, if it is available.
7. Check the Open to All Locally Known Users check box.
8. Clear the Search Other Realms for Unknown Users check box.
9. Check the Requires Name Lock check box.
10. Clear any selection from the check boxes Enable Offline
Authentication, Enable Windows Password Integration, and
Create Verifiable Authentication.
Note: These options became available on the agent host
configuration screen starting with RSA ACE/Server 6.0.
11. Click OK.
12. Click the Agent Host tab, and select the Generate Configuration
Files item.
The Generate Configuration File screen opens.
13. Select the One Agent Host option, and then select from the list the
FirePass controller agent host you just configured.
14. Save the agent host configuration file on your local system.
15. Click OK.
Step 2: On the RSA SecurID authentication server, identify the users who
are authorized to use the FirePass controller
See your RSA SecurID Server admin guide for information on how to
activate users on the agent host you created for the FirePass controller.
Step 3: Configure the FirePass controller to use the RSA SecurID
authentication server
1. In the navigation pane on the FirePass controller, click Device
Management, expand Configuration, and click RSA SecurID,
The Configure a New RSA SecurID Server screen opens.
2. In Name, type a name that identifies the RSA SecurID
authentication server configuration on the FirePass controller.
This name can be any arbitrary string.
8 - 35
Chapter 8
3. In Configuration file, type the path and name of the Configuration
File you created in Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an
agent host, on page 8-34, or click the Browse button to search for it.
4. In Source IP, type the IP address to be used for communicating
with RSA SecurID authentication server, or select it from the list.
If there is a NAT device in the network path between the FirePass
controller and the RSA SecurID authentication server, type the
address as translated by the NAT device.
Otherwise, select the IP address from among those configured on
In all cases, this IP address must match the SourceIP address in the
IP packets that the RSA SecurID server receives.
Note: Because the FirePass controller is a multihome appliance
with multiple IP addresses, this setting is very important. It must be
the same address as the IP address you specified in the Network
address field while configuring the FirePass controller as an agent
host on RSA SecurID server in Step 1: Configure the RSA SecurID
authentication server to recognize the FirePass controller as an
agent host, on page 8-34.
8 - 36
Using RSA SecurID on FirePass controllers configured for failover
There are some specific considerations for using RSA SecurID on FirePass
controllers that are configured for failover.
On the RSA SecurID authentication server:
• When you configure the FirePass controller as an agent host, use the
virtual IP address of the FirePass controller as the primary IP address.
• Configure each failover unit as a secondary node on the RSA SecurID
server, using the actual IP address, not the virtual IP address.
• If the FirePass controller is deployed in a failover configuration, define
all host name/IP addresses that resolve to the FirePass controller.
For more information about creating, modifying, and managing agent host
records and configuring secondary nodes, see the appropriate RSA Security
documentation.
On the FirePass controller:
• When you configure an RSA SecurID authentication server, use the
shared, virtual IP address of the FirePass controller failover pair as the
source IP address.
Specifying the SMTP email server
You can have the FirePass controller send email messages from the FirePass
controller administrator and users. You can configure the Simple Mail
Transfer Protocol (SMTP) server for this purpose on the Device
Management : Configuration : SMTP Server screen. The FirePass controller
uses the SMTP server to send all emails, including:
• Messages from users of the Portal Access : Mobile Email functionality.
• Messages from the FirePass controller administrator.
To specify an email server for the FirePass controller to use
Management, expand Configuration, and click SMTP Server,
The SMTP Server screen opens.
2. In Primary server, type the name of the email server you want to
use, such as mailserver.siterequest.com.
3. In Optional backup server, type the name of an SMTP server you
want the FirePass controller to use if the primary server is
unavailable.
8 - 37
Chapter 8
After you configure the SMTP server, you can test it.
Note
The FirePass controller does not support email sent using an SMTP server
that requires authentication.
To send a test email through the STMP server
Management, expand Configuration, and click SMTP Server,
The SMTP Server screen opens.
2. In the Send the test E-Mail area, specify an email address that you
want the FirePass controller to send the test email to.
3. Click the Send button.
4. Check the email account that you sent this email to verify that it
received a test message from the controller.
To determine the success of the test, check for the presence of the
message FirePass platform SMTP Test.
Configuring an SNMP agent
You can use a Simple Network Management Protocol (SNMP) agent to
monitor the FirePass controller. The SNMP agent uses a standard
NET-SNMP version 5.1 distribution to support the management information
base (MIB) modules. In addition to the standard MIB supported by the
NET-SNMP library, the FirePass controller supports its own enterprise
MIB: FIREPASS-SYSTEM-MIB, for managing FirePass
controller-specific features. For more information on the MIB modules that
the SNMP agent supports for the FirePass controller, see the online help for
the Device Management : Configuration : SNMP screen.
Important
When configuring fields described in the following procedure, F5 Networks
strongly recommended making sure that only the internal LAN has access to
the port configured in Run SNMP agent on port. In addition, we
recommend restricting the access location specified in Accessed from to
that of your SNMP Manager.
To configure an SNMP agent
Management, expand Configuration, and click SNMP,
The SNMP screen opens.
2. Check the Run SNMP agent on port check box and specify a port
number. The standard SNMP port is 161.
If you specify a nonstandard port in this procedure, make sure that
your SNMP Manager is configured appropriately.
8 - 38
3. In System name, specify a name to identify the SNMP agent for
this FirePass controller, such as the FirePass controller’s name.
Note: Each member of a cluster or failover pair must have a distinct
name. The SNMP names and locations are not synchronized
between failover pairs because each member is tracked separately
and must be uniquely identified.
4. In System location, type the FirePass controller’s location.
5. In System contact, specify an email address to contact, such as the
address for the FirePass controller administrator.
6. In Community name in the rocommunity, rwcommunity, and
Traps configuration sections, type the community name that
corresponds to your SNMP Manager configuration. Community
name is a standard SNMP access token.
7. In Accessed from in the rocommunity and rwcommunity sections,
type one of the following to indicate the access location.
• The string anywhere
• The string nowhere
• A list of space-separated host names, IP addresses, or
IPaddress/IPmask pairs
8. Check SNMPv1 traps, SNMPv2 traps, and SNMPv3 informs to
indicate the SNMP version for the associated list of host names.
You can check one or more check boxes as appropriate to your
configuration.
9. In the boxes in the Hosts section, specify a list of space-separated
trap destination host names or IP addresses. You can also configure
a port number by following the host name with a colon and the
number you want to use, for example
my.trap.host:162
The hosts should correspond to the configuration in your SNMP
Manager.
10. Click the Submit button.
Specifying HTTP and SSL proxies
You can configure the FirePass controller to use HTTP and SSL proxies for
web server access. Several situations require proxies.
• If the FirePass controller has no direct outbound access to the Internet,
you must configure the settings for the proxy server used to relay the
requests. This is also required for the mechanism used for the Online
Update functionality to work.
• If the FirePass controller does not have direct access to web servers on
the internal LAN, you might also have to configure a proxy for Web
Applications favorites to work.
8 - 39
Chapter 8
You can find settings for these features on the Proxies screen. To access the
screen, click Device Management, expand Configuration, and click
Proxies. For more information about proxies settings, see Configuring
proxy options, on page 7-34.
To specify HTTP or SSL proxies
Configuration, and click Proxies,
The Proxies screen opens.
2. To enable an HTTP proxy, check the Enable HTTP Proxy check
box. In the Address text box, type the HTTP proxy’s IP address,
and in the Port text box, specify the HTTP proxy’s port number.
3. To enable an SSL proxy, check the Enable SSL Proxy check box.
In Address, type the SSL proxy’s IP address, and in Port, specify
the SSL proxy’s port number.
4. To use basic proxy authorization, check the Use Basic Proxy
Authorization check box. In Username, type the user’s logon
name, and in Password and Validate, type the user’s password.
5. In the box at the bottom of the screen, specify a comma-separated
list of IP addresses or subnets to which you want the FirePass
controller to allow direct access.
If the box is empty, the FirePass controller uses a proxy for all
resource access.
The FirePass controller uses this setting for all connections that go
through a proxy, even web applications.
6. Click the Update and Test button.
The FirePass controller verifies that it can connect to the proxies
you specified before committing the settings.
Note
If the settings are incorrect, the test may take some time to complete.
Specifying the time, time zone, and NTP server
You can specify a time zone for the FirePass controller’s location, and you
can specify a Network Time Protocol (NTP) server for the FirePass
controller to use. You can also manually set the time.
To specify a time zone for the FirePass controller
Configuration, and click Time,
The Time screen opens.
2. To specify a time zone for the FirePass controller, select a time zone
from the list, and click the Apply button.
8 - 40
3. Click the click here to restart the FirePass services link to initiate
a restart of the FirePass controller services.
The Restart Services screen opens.
4. Click the Restart button to begin the restart operation.
When the operation completes, the new time appears at the top of
the screen.
To specify an NTP server for the FirePass controller
2. To specify an NTP server, specify the server name in the New NTP
Server box, and then click the Apply button.
When the operation completes, the new time appears at the top of
the screen.
Note
If you are using RSA or VASCO authentication, F5 Networks recommends
using an NTP server.
To specify date and time manually
2. Type the values you want to use in the box in the Set Date and Time
Manually area, using the format described in the following section.
3. Click the Apply button.
Time and date format
Use the following format to specify the time and date on the Time screen.
MMDDhhmm[[CC]YY][.ss]
• MM - month number in a year
• DD - day number in a month
• hh - hour number, in 24-hour format
• mm - minutes number
• CC - century (that is, the 21st century) minus 1
For the purposes of the FirePass controller, this value is 20.
• YY - the last two digits of the year. So CCYY is the full year
representation.
• .ss - seconds number
Notes
• Brackets indicate optional values.
8 - 41
Chapter 8
• If you do not specify CC and YY values, the FirePass controller uses the
current century and year. If the date you specify has not yet occurred in
the year, the FirePass controller uses the previous year.
• Make sure to type a period before the last two digits, if you want to set
seconds.
Example
To set the time to 11:30:45 AM on September 24, 2004, type the following
string: 092411302004.45
8 - 42
Performing maintenance
Maintenance for the FirePass controller includes the following activities:
◆
Activate License
For more information, see Managing FirePass controller licenses,
following.
◆
Backup/Restore
For more information, see Backing up and restoring the FirePass
◆
Local Update
For more information, see Upgrading controller software, on page 8-46.
◆
Logs
For more information, see Managing log files, on page 8-49.
◆
Accounting
For more information, see Configuring for RADIUS accounting, on page
8-56.
◆
Online Update
For more information, see Updating the software online, on page 8-48.
◆
Restart Services
For more information, see Shutting down and restarting the FirePass
◆
Troubleshooting Tools
For more information, see Using the troubleshooting tools, on page 8-59.
◆
User Session Lockout
For more information, see Locking out user sessions, on page 8-47.
Managing FirePass controller licenses
When you want to install, upgrade, or reactivate the FirePass controller
license, you can use items on the Device Management : Maintenance :
Activate License screen.
Obtaining a license for the first time
The FirePass controller already has an installation type, serial number, and
registration key assigned. You can check these values on the Current
Settings screen. To access the screen, in the navigation pane, click Device
Management, and click Current Settings.
Your FirePass controller was factory-equipped with a unique code, called a
base registration key. When you purchased the controller, a record was
created on the F5 Networks licensing server, indicating what features you
purchased. To operate your FirePass controller, you must activate your
license. The activation process connects this controller’s base registration
key with the licensing server record.
8 - 43
Chapter 8
Installing a new license or adding capacity or features to an existing license
You can automatically generate an encrypted license request to add
concurrent session capacity, and to activate the module registration key
when you purchase new features.
If, during the licensing process, you cannot connect to the licensing server
using the automatic method, check the FirePass controller’s gateway, DNS,
and proxy settings. Also make sure your firewall allows outgoing
connections to https://activate.f5.com. If you still cannot connect to the
licensing server, use the manual license activation method.
To install a new license or add features
Maintenance, and click Activate License.
The Activate License screen opens.
2. For each new feature you are adding, type or paste the module
registration key in the box provided, and click the Add button.
3. Select the Registration Method.
If your FirePass controller can resolve directly to the F5 Networks
licensing server, and it has outgoing SSL access to port 443, select
the Automatic method. Otherwise, or if you are not sure, select the
Manual method.
4. Click the Request License button.
5. If you selected the Automatic registration method:
a) Accept the End User License Agreement, and provide your
business email address and contact details at the prompts.
A screen opens, displaying your license file.
b) Click the Continue button to activate and install your license.
6. If you selected the Manual method, the Activate License screen
opens.
a) Select and copy all of the contents in the Product Dossier box.
b) Click the Click here to access F5 Licensing Server link.
The Activate F5 License screen opens in a new browser window.
c) Paste the contents you copied from Product Dossier in the
previous step to the Product Dossier box on the Activate F5
License screen.
d) On the Activate F5 License screen, click the Activate button.
e) Accept the End User License Agreement, and provide your
business email address at the prompt.
f) After a few moments, the licensing server displays your new
license file.
g) Select all of the text in the License File text box on the Activate
F5 License screen, and copy it to your system's clipboard.
8 - 44
h) Return to the FirePass controller browser window.
i) On the Device Management : Maintenance : Activate License
screen, paste into the License File box the text you copied from
the licensing server.
j) Click the Install License button.
Some confirmation messages appear.
7. Click the Continue button to activate and install your license.
It may take several seconds for the license to become valid, and in
certain cases, for example, for a new license, the process might
prompt you to restart the FirePass controller.
8. Log off, and log on again.
The FirePass controller presents the newly licensed features.
Important
If your license includes a FIPS or SSL-accelerator option, you must restart
the FirePass controller after activating the license.
Backing up and restoring the FirePass controller
You can back up and restore the current FirePass controller configuration,
including the users and groups portions of the FirePass controller
configuration, all favorites, most reports, and some non-network elements
included within Device Management. We recommend that you back up your
system before and after upgrading FirePass controller software.
You can transfer the FirePass controller configuration information to a
replacement controller if a hardware failure occurs, or for upgrading
purposes. The backup operation does not preserve network settings, so you
should configure the network settings before restoring a backup on a
different platform.
Important
Both the platform you use for backing up and the one you use for restoring
must run the same version of the FirePass controller software, including all
hotfixes.
To back up and restore FirePass controller configuration
information
Maintenance, and click Backup/Restore.
The Backup / Restore screen opens.
2. Do one of the following:
• To back up the current configuration, including user and group
accounts, global and master-group access settings, and favorites,
click the Create backup of your current configuration link.
8 - 45
Chapter 8
When the process posts the dialog box, click Save it to disk,
browse to a location where you want to store the backup file, and
click OK.
• To create a full backup of the configuration, including user and
group accounts, global and master-group access settings, and
favorites, click the Create backup of your current
configuration and log messages link. When the process posts
the dialog box, click Save it to disk, browse to a location where
you want to store the backup file, and click OK.
• To configure automated backups, check the Perform nightly
backups check box, check SCP or FTP, click Save, specify the
information requested, and click the Save or Backup Now
button.
• To restore a backed up configuration, click the Browse button in
the restore section, and select the backed up file. Then, click the
Restore your saved configuration link.
A FirePass controller backup file name appears similar to the
following:
backup-bip025328s-URM-5_5-20051021233816.zip, for a
partial backup, and
backup-full-bip025328s-URM-5_5-20051021235036.zip, for a
full backup.
The backed up files are protected with strong encryption, and are checked
for integrity prior to being restored.
WARNING
Backing up and restoring across FIPS-compliant systems only restores the
user accounts and groups configuration. It does not restore network settings
and certificates. This is a FIPS requirement.
Upgrading controller software
You can modify FirePass controller software from an installation file that
you download from the F5 Networks Technical Support Server. Typically,
you download these upgrade releases from the F5 Networks Technical
Support Server, or receive them directly. For more information, see
Upgrading from a downloaded file, on page 8-47.
You can also upgrade the FirePass controller online. For more information,
see Updating the software online, on page 8-48. Whenever you upgrade the
FirePass controller software, you must update all cluster and failover
members to the new version as well. When you update clusters and failover
pairs, make sure to apply the update to the primary or active member first;
otherwise, synchronization wipes out all upgrade activity.
Important
Always back up the FirePass controller before an upgrade. You can use the
Snapshot feature to back up the system. For more information, see Backing
up and restoring the FirePass controller, on page 8-45.
8 - 46
Preparing for download
To prepare for upgrading, you can prevent new users from logging on to a
FirePass controller, and you can stop currently active user sessions. You can
find both of these functions on the User Session Lockout screen. To access
the screen, click Device Management, expand Maintenance, and click
User Session Lockout.
Locking out user sessions
When you check the Lockout new user sessions check box, the FirePass
controller refuses all logons from users. Newly logging on users see the
message configured in the session-lockout message box. Currently logged
on users experience no interruption in service.
The default session-lockout message is The FirePass administrator has
placed this system in maintenance mode. Please try again later. You can
change the message and click the Update button to present your own
customized message to newly logging on users.
You can still log on as an administrator using the /admin/ URI.
Ending user sessions
You can stop all currently active sessions using the Kill all sessions (except
this one) link. When one or more sessions are active, the screen displays a
warning, indicating the number of sessions to be affected. Clicking the Kill
all sessions (except this one) link halts all sessions except the one you are
using when you click the link. Once all sessions halt, the screen displays a
message, There are no other sessions at this time.
Upgrading from a downloaded file
To download the upgrade file using a browser
The following instructions have been tested with Netscape, Mozilla, Internet
Explorer, and Safari. To access the FTP server with one of these browsers,
perform the following steps:
1. Type the following into the browser’s address field, where
<username> is your Ask F5 user name:
ftp://<username>@ftp.f5.com
2. When prompted for your password, type your Ask F5 account
password.
Note
Although some browsers allow you to include passwords as part of the URL,
F5 Networks recommends that you do not do so because of the possibility of
someone intercepting the password.
8 - 47
Chapter 8
To download the upgrade file using the command line
1. Type the following command:
ftp ftp.f5.com
2. When prompted for your password, type your Ask F5 account
password.
Now that you have the file, you can use the Local Update feature to upgrade
the software.
To update the FirePass controller from a local file
Maintenance, and click User Session Lockout.
The User Session Lockout screen opens.
2. Check the Lockout new user sessions check box.
If you wish, you can edit the message the controller presents to
newly logging on users. For more information, see Locking out user
sessions, following.
3. Click the Kill all sessions (except this one) link.
For more information, see Ending user sessions, on page 8-47.
4. In the confirmation alert, click OK to stop all user sessions, or
Cancel to halt the operation.
Maintenance, and click Local Update.
6. Click the Browse button, and select the file.
7. Click the Open button.
8. Type the password you received along with the update file.
The default password is F5Networks.
9. Click the Submit button.
The update screen displays progress indicators that show the
progress of the download, install, and reboot processes.
10. After reboot completes, you can verify that the update completed
successfully by navigating to the Device Management : Current
Settings screen. The Current Settings screen displays the version
and build number, and all hotfixes that have been applied.
Updating the software online
You can use the Online Update feature to upgrade the FirePass controller to
the most currently available version. To determine availability of a new
release, consult the Online Update screen. To access the screen, in the
navigation pane, click Device Management, expand Maintenance, and
click Online Update.
8 - 48
To upgrade to the new version, follow the instructions presented on the
screen. You can also review the release notes for any available version.
When you click a release, the FirePass controller downloads the update
package and restarts the controller.
Managing log files
You can view, archive, download, and purge FirePass controller logs
manually or automatically at specified intervals. Periodic purging and
archiving of logs is important to manage storage space on the FirePass
controller. You can:
• View the date of the most recent purge and the date of the next-scheduled
operation.
• Specify a log-purge schedule.
• Specify and configure the storage format for archives.
• Purge the temporary logs on the FirePass controller.
Purging files does not delete the log files, but rather moves them out of
current storage, and makes them available for archiving.
• Download and delete logs that exist in temporary storage.
• Specify a remote system log server for application and kernel messages.
• Delete system logs.
To archive data from purged logs, check the Create Archive check box. If
you do not check this option, purged data is permanently deleted.
Note
F5 Networks recommends that you do not keep the archives on the FirePass
controller. Delete the archive from the Temporary Archive Storage after you
have externally archived it.
Using system logs
You can configure system logs to integrate with your existing log
management process and tools. The FirePass controller provides support for
extensive syslog capability. The following list represents the types of
messages that are logged in the system log.
• User session log
Represents when the user logged on, when the user logged off, and other
messages related to logon operations.
• Application logs
Represents all favorites that end-users and administrators can access.
• Pre-logon check messages
Includes messages returned from pre-logon checking of client systems.
• System events
Includes events such as system up and system down, reboot, and others.
8 - 49
Chapter 8
For more information, see the online help for the Logs screen, available
under the Maintenance item in the navigation pane.
Understanding log files
The FirePass controller records logging information in the following files:
• fp_app_log
Application log: For more information, see Application log-specific
(fp_app_log) example and variables, on page 8-52.
• fp_browser_log
Browser log: For more information, see Browser log-specific
(fp_browser_log) example and variables, on page 8-52.
• fp_logon_log
Logon log: For more information, see Logon log-specific (fp_logon_log)
example and variables, on page 8-53.
• fp_sess_log
Session log: For more information, see Session log-specific (fp_sess_log)
• fp_usage_log
Usage log: For more information, see Usage log-specific (fp_usage_log)
When you configure the FirePass controller to transfer these files over a
network to a remote system, the system compresses these files into a single
archive (a .zip file). The FirePass controller names files using a specific
format, as shown in the following example.
logs-bipnnnnnns-URM-5_5-yyyymmddhhmmss.zip
Log names follow these conventions:
• bipnnnnnns - serial number, typically with bip as the first three
characters, followed by six digits and a final character of s.
• yyyy - year, in four-digit representation.
• mm - month, in two-digit representation, from 01 to 12.
• dd - day of month, in two-digit representation, zero padded for days 1-9.
• hh - hours, in two-digit representation, from 01 to 24.
• mm - minutes, in two-digit representation, from 00 to 60.
• ss - seconds, in two-digit representation, from 00 to 60.
A typical log name is logs-bip025328s-URM-5_5-20050922001003.zip.
Understanding the format of log data
The FirePass controller creates logs as ASCII text files, and terminates each
line with a single newline character (hexadecimal 0x0A, that is UNIX-style
line termination, not DOS-style). There are no header or footer lines. Each
line of text represents a single event, and (unless noted) has the following
format:
8 - 50
IP_address--[mm/dd/yyyy hh:mm:ss]"var1=value1;var2=value2"
The following example illustrates a typical log entry.
192.168.200.170--[08/18/2005 00:52:23]
"sid=1e9ce3c6ee9601562efddc41169f2937;logon=access;group=Default;
message=Entered Admin Console
The following list describes each part of the log entry.
◆
IP_address
Represents the IP address of the computer that generated the log entry.
◆
[mm/dd/yyyy hh:mm:ss]
Represents the timestamp of the event being logged. Rectangular
brackets enclose the timestamp. Forward slashes delimit the values for
month, day, and year values. Colons separate the values for hours,
minutes, and seconds. The fp_sess_log and fp_browser_log files each
have two consecutive timestamp fields, each separately bracketed. The
fp_app_log also has a second, bracketed field following the first
timestamp field. It contains a text string, described, following.
◆
"var1=value1, var2=value2, varN=valueN"
Represents a series of pairs consisting of the name that the FirePass
controller uses to describe the data and the data itself. Double quotes
enclose the varN=valueN pairs, as a group. The entries for each log
share some variables and contain some type-specific variables. The
Variables shared by all logs section, following, describes the options
common to more than one log. Subsequent sections describe the
type-specific variables, as well as present examples of typical entries. For
more information, see the following sections:
• Application log-specific (fp_app_log) example and variables, on page
8-52
• Browser log-specific (fp_browser_log) example and variables, on
page 8-52
• Logon log-specific (fp_logon_log) example and variables, on page
8-53
• Session log-specific (fp_sess_log) example and variables, on page
8-53
• Usage log-specific (fp_usage_log) example and variables, on page
8-55.
Variables shared by all logs
◆
sid
Indicates the FirePass controller session ID during which the event
occurred. The sid variable appears in fp_app_log, fp_browser_log,
fp_sess_log, and fp_usage_log.
◆
logon
Indicates the name of the logged on FirePass controller user associated
with the event. The logon variable appears in all logs.
8 - 51
Chapter 8
◆
group
Indicates the name of the FirePass controller master group that contains
the logged-on user. The group variable appears in fp_app_log,
fp_browser_log, fp_sess_log, and fp_usage_log.
Application log-specific (fp_app_log) example and variables
Format
Example
192.168.200.170--[08/24/2005 22:19:51]
"sid=347cb5ea4ee9a4f6bf184ff56b97ed28;logon=access;group=Default;
message=Entered Admin Console
Variables
◆
Shared variables, as described in Variables shared by all logs, preceding.
◆
message
Describes the action occurring in FirePass controller session.
Other messages typical of admin-related activity include:
• Access menu Welcome, param a = welcome, param click = 1
• Access menu Network Configuration, param a = ipconf
Other messages typical of client-related activity include:
• Network Access: dialing Click to connect to Network Access
• Network Access: dialing Connection to SA server
• Open Network Access Connection using remote IP address
192.168.192.6
• Network Access Connection terminated, Logged out
Browser log-specific (fp_browser_log) example and variables
Format
IP_address--[mm/dd/yyyy hh:mm:ss] [mm/dd/yyyy hh:mm:ss]
"var1=value1;var2=value2"
Example
192.168.200.170--[08/24/2005 22:19:51][08/24/2005 22:22:20]
agent_OS=WinXP;user_agent=Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; SV1)
For this item, the second timestamp indicates the ending time of the logged
activity.
8 - 52
Variables
◆
Shared variables, as described in Variables shared by all logs, on page
8-51.
◆
agent_OS
Indicates the operating system information of the client, taken from the
HTTP header user agent field.
◆
user_agent
Indicates the browser information of the client, taken from the HTTP
header user agent field.
Logon log-specific (fp_logon_log) example and variables
Format
Example
192.168.200.170--[08/24/2005 21:13:40]
logon=access;valid=yes;passed=yes;User-Agent=Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Variables
◆
8-51.
◆
valid
Indicates whether the logging on user’s computer presented a valid client
certificate. Possible values are yes and no.
◆
passed
Indicates whether the logging on user’s computer passed the active
pre-logon check. Possible values are yes and no.
◆
user_agent
Indicates the browser information of the client, taken from the HTTP
header user agent field.
Session log-specific (fp_sess_log) example and variables
Format
IP_address--[mm/dd/yyyy hh:mm:ss] [mm/dd/yyyy hh:mm:ss]
"var1=value1;var2=value2"N
Example
192.168.200.170--[08/24/2005 22:19:51][08/24/2005 22:22:20]
home_address=;protocol=HTTPS;nonstandard_port=0;content_type=
HTML;desktop_dns=;desktop_dns=;finish=:0;"0
8 - 53
Chapter 8
For this item, the second timestamp indicates the ending time of the logged
activity.
Variables
◆
8-51.
◆
home_address
Represents the IP address of the remote desktop using Desktop Access.
An empty value indicates no Desktop Access connection.
◆
protocol
Represents the protocol used to access the FirePass controller, either
HTTPS (typical) or HTTP (unsecured).
◆
nonstandard_port
Represents the port number used to access the remote desktop for
Desktop Access connections. An empty value indicates no Desktop
Access connection.
◆
content_type
Represents the content form used to communicate with the standalone
VPN client. For a Windows-based browser, the value is typically HTML
it could be WML, in the case of a wireless hand-held device (PDA, cell
phone), for example.
◆
desktop_dns
Indicates the IP address of the remote DNS used by the remote desktop
for Desktop Access connections. An empty value indicates no Desktop
Access connection.
◆
desktop_finish
Indicates the length of the session, in seconds (integer) for Desktop
Access connections. An empty value indicates no Desktop Access
connection.
◆
server_addr
Indicates a reserved value.
◆
N
Represents the status code of FirePass controller session, as indicated by
the following values.
Additional values
• 0 - Server session in progress.
• 1 - Logged out from server
• 2 - Server session timed out
• 3 - Redirecting to desktop
• 4 - Desktop session in progress
• 5 - Logged out from desktop
• 6 - Desktop session timed out
• 7 - Session handed off to failover box
8 - 54
Usage log-specific (fp_usage_log) example and variables
Format
[mm/dd/yyyy hh:mm:ss]
[internal_function]"var1=value1;var2=value2"
Example
[08/23/2005 19:32:10] [uroam_admin]
"sid=35351d251f1b7bda0c427ff2a0d65a10;logon=access;group=Default
;time=3549;
Variables
◆
8-51.
◆
time
Indicates the length of session, in seconds (integer), for the FirePass
controller connection.
◆
internal_function
Indicates the functionality used during FirePass controller session, as
indicated by the following values.
• uroam_admin - Admin Console
• uroam_mnemail - Mobile E-Mail
• uroam_mnfilemanager - Windows Files
• uroam_geekster - AppTunnels
• uroam_helppages - Help
• uroam_mnintranets - Web Applications
• uroam_mydesktop - Desktop Access
• uroam_nfs - UNIX Files
• uroam_terminal - Terminal Servers
• uroam_vault - Tools
• uroam_mnoptions - Account Details
• uroam_mndesktopupdate - Desktop Software Download
• uroam_look - Webtop settings
• uroam_mnsessions - View Current Sessions
• uroam_mnstats - System Statistics
• uroam_vpn - Network Access
• uroam_x11 - X Window System (X11) Access
8 - 55
Chapter 8
Configuring for RADIUS accounting
You can configure the FirePass controller to use RADIUS accounting
according to the standard described in RFC 2866, with certain exceptions.
The FirePass controller sends the following information to RADIUS
accounting server.
When a user logs on to the FirePass controller, it sends session start
information to the RADIUS accounting server. Session start information
consists of the RADIUS loginName, for example, joeu; the RADIUS
sessionId of the user’s session, for
example,123456789abcdefghijklmnopqrstuvy; and a RADIUS accounting
status start message, to indicate that the session has started.
Once the user finishes using the FirePass controller and terminates the
session by logging off of the controller, the FirePass controller sends session
end information to the RADIUS accounting server. Session end information
consists of the RADIUS login Name, for example, joeu; the RADIUS
session Id of the user’s session, for example,
123456789abcdefghijklmnopqrstuvy; a RADIUS accounting status stop
message, to indicate that the session has ended; and the RADIUS service
duration, for example, 300 seconds, which represents the total time for
which user session was active.
If the user does not log off of the controller, but simply closes the browser
window, the FirePass controller sends the RADIUS stop message when the
user’s session times out.
The FirePass controller sends the RADIUS accounting messages
asynchronously. It stores the user’s session start and session end information
in its database and sends it to the RADIUS accounting server periodically at
an interval of one minute.
Important
Be sure that the RADIUS accounting server is configured to recognize the
FirePass controller as a client.
To configure RADIUS-based accounting
Maintenance, and click Accounting.
The RADIUS Accounting screen opens.
2. Specify Timeout (in seconds) and Retries (number of retries).
We recommend setting both the timeout and number of retries to 3.
The allowable range for each field is 1 - 65535.
3. Specify the Service Type.
The FirePass controller uses this value as the RADIUS Attribute
Service Type (attribute number 6), and inserts the value for all the
requests the FirePass controller makes to the RADIUS Server.
4. Specify the Server, Port, and the Shared Secret.
Use the same shared secret in the RADIUS server configuration and
in the FirePass controller configuration.
8 - 56
5. If you have secondary and tertiary backup RADIUS servers, check
Use a secondary RADIUS server and Use a tertiary RADIUS
Accounting server, and then configure them the same way.
Shutting down and restarting the FirePass controller
You can use software options to restart the FirePass controller or its
services. To open the screen, In the navigation pane, click Device
Management, expand Maintenance, and click Restart Services.
Restarting the FirePass controller or services
You can restart the FirePass controller hardware using the Administrative
Console or the Maintenance Console. You can also restart all FirePass
controller software components by using the Administrative Console.
To restart the FirePass controller or services using the
Administrative Console
Maintenance, and click Restart Services.
2. Do one of the following:
• To restart the FirePass controller software components, click
Restart Services.
• To restart the FirePass controller hardware, click Restart
Controller.
3. Depending on the confirmation screen, do one of the following:
• On the Restart Services confirmation screen, click the Restart
button to initiate the restart, or click the Back to Device
Management : Maintenance : Restart Services page link to cancel
the operation.
The Restart Services operation does not affect active user
sessions.
• Restart Controller confirmation screen, review the warnings, if
there are any, and then click the Restart button to initiate the
restart, or click the Back to Device Management : Maintenance :
Restart Services page link to cancel the operation.
Restarting the FirePass controller ends any active user sessions.
To restart the FirePass controller hardware using the
Maintenance Console
1. To start a Maintenance Console session, in the navigation pane,
click Device Management, expand Maintenance, and click
Troubleshooting Tools.
The Troubleshooting Tools screen opens.
8 - 57
Chapter 8
2. Click the Please click here to start a console session to the
Maintenance Account link.
3. In the Maintenance Console, type maintenance, and press return.
4. On the first Configure FirePass Controller screen, type Y to accept
the agreement.
You can also type N to cancel the operation.
5. On the second Configure FirePass controller screen, type 9, labeled
Restart/shutdown controller.
6. On the Shutdown/Restart Controller screen, type 2, labeled Restart
FirePass Controller, and press return.
7. On the Restart confirmation screen, type Y to initiate the restart, or
N to cancel the operation.
Restarting the FirePass controller ends any active user sessions.
Shutting down the FirePass controller
You can shut down the FirePass controller using the Administrative Console
or the Maintenance Console.
Important
After shutting down, you must have physical access to the FirePass
controller device to start up the controller again. You cannot use the
browser interface to start up the FirePass controller.
To shut the FirePass controller down using the
1. On the navigation pane, click Device Management, expand
Maintenance, and click Restart Services.
2. Click the Shutdown Controller link.
3. On the Shutdown Controller confirmation screen, review the
warnings, if there are any.
Shutting down the FirePass controller ends any active user sessions.
4. Click the Shutdown button to initiate the restart, or click the Back
to Device Management : Maintenance : Restart Services page link to
cancel the operation.
To shut the FirePass controller down using the
Maintenance Console
1. To start a Maintenance Console session, in the navigation pane,
click Device Management, expand Maintenance, and click
Troubleshooting Tools.
8 - 58
2. Click the Please click here to start a console session to the
Maintenance Account link.
3. In the Maintenance Console, type maintenance, and press return.
4. On the first Configure FirePass Controller screen, type Y to accept
the agreement.
You can also type N to cancel the operation.
5. On the second Configure FirePass controller screen, type 9, labeled
Restart/shutdown controller, and press return.
6. On the Shutdown/Restart Controller screen, type 1, labeled
Shutdown FirePass Controller.
7. On the Shutdown confirmation screen, type Y to initiate the restart,
or N to cancel the operation.
Shutting down the FirePass controller ends any active user sessions.
Using the troubleshooting tools
You can use the tools provided to troubleshoot FirePass controller
installations. The FirePass controller provides several troubleshooting tools.
◆
Console access
Provides telnet access to the Maintenance Console. For more
information, see Accessing the console, following.
◆
F5 Support Diagnostic tool
Compiles a set of data for the F5 Support team to use. For more
information, see Using the F5 Support Diagnostic tool, on page 8-60.
◆
Network packet dump
Creates a packet of data to use for troubleshooting purposes. For more
information, see Capturing network packets, on page 8-61.
◆
Web Applications engine trace
Creates a set of files that provides settings that help troubleshoot
problems. For more information, see Understanding Web Applications
engine trace, on page 13-1.
Accessing the console
You can access the Maintenance Console from the Troubleshooting Tools
screen. To access the console, click the Please click here to start a console
session to the Maintenance Account link.
Important
Although you can access the Maintenance Console from the
Troubleshooting Tools screen, you can initiate operations that result in the
inability to access the FirePass controller over the network. For example,
when you initiate a Snapshot operation, the system boots into Maintenance
mode, and you cannot access the FirePass controller from the browser. To
continue, you must access the controller using the serial console connected
8 - 59
Chapter 8
directly to the physical device. Therefore, we recommend using caution
when initiating operations through the Maintenance Console. For more
information, see the FirePass Controller Getting Started Guide, available
as a separate document on the F5 Networks Technical Support Web site,
http://tech.F5.com.
Using the F5 Support Diagnostic tool
You can use this utility to capture a variety of support information from the
You can click the Capture a new dataset link to collect a new set of data.
The screen refreshes and posts the message Processing new dataset. Please
be patient as the operation completes.
Note
The FirePass controller stores the data in an encrypted format. The F5
Support team uses their support server to decrypt the password and extract
the text.
Once a dataset is captured, additional links appear, offering the options to
download the dataset, email it to F5 Support, or delete it.
You can click the Download existing dataset link to save the collected data
to your computer. Your browser’s download dialog appears. Save the file,
and send it to [email protected] using the support case number as the
subject of your email, unless instructed otherwise by F5 Support.
You can click the Email existing dataset to F5 Support link to email the
collected data directly from the FirePass controller to F5 Support. The
screen refreshes, and a confirmation of the sent message appears, or
notification of any error. The SMTP options, available on the Device
Management : Configuration : SMTP Server screen, must be configured
correctly for this option to work. In addition, your company might place
firewall restrictions on external emails originating from within your
network. In that case, you can download the dataset and email it directly.
You can delete a dataset to conserve storage. Before deleting a dataset,
confirm with F5 Support that they have received the files. Then click the
Delete existing dataset link to delete the dataset. The screen refreshes and
the options to download, email, and delete the dataset no longer appear.
Using the session variable dump tool
You can use this utility to capture a user’s session variable information from
You can enable the Save user’s session variables to Logon Report option
to have the system write a user’s session variables to the Logon report for
that user. Then you can view the variables on the Reports : Logon screen.
8 - 60
Capturing network packets
You can use the network-packet capture feature to troubleshoot networking
problems by capturing the network packets coming to and leaving from the
To configure for network-packet capture
Maintenance, and click Troubleshooting Tools.
2. From the Interface list, do one of the following:
• For the 1000, 2100, or 4000 platforms, select a network interface.
• For the 4100 platform, select either the Management interface or
one of the physical interfaces.
3. From the Packet type list, select the scope of packets to capture:
TCP, UDP, or All Types.
4. From the Max packet count list, select the number of packets to
capture.
5. Select one of the following options:
• Specify destination IP (empty for all traffic)
The destination IP address accepts alphanumeric characters and
the period ( . ), hyphen, ( - ), and underscore ( _ ).
• or expression (e.g.: host 172.16.1.2 and not udp port 443)
You can specify an expression, including alphanumeric
characters and the period ( . ), hyphen, ( - ), and underscore ( _ ).
An empty IP address or expression field means that all the traffic is
captured.
6. To filter out the traffic to your current browser, check the Exclude
this browser’s address check box.
Note: This option is useful when you do not specify the destination
IP address.
7. To filter out broadcast UDP packets and ARP requests, check the
Ignore broadcasts and Ignore ARP check boxes.
8. Click the Please click here to start sniffing the network traffic
link to start capturing the traffic.
A dotted line draws in a new window to indicate activity.
9. You can wait until the maximum packet count is reached, or click
the Click here to stop the capture and view the results link to halt
the operation.
A description of the captured packets appears in the window.
10. View the data inline, or click the Click here to download the data
link to save the file locally, so you can analyze the packet dump file
offline.
8 - 61
Chapter 8
11. Click the Click here to view the same data SSL-decoded link to
see the same data set with SSL sessions decoded.
The packet dump screen refreshes with the same dataset
SSL-decoded. You can then select one keypair to use to decrypt and
display the embedded application data, or click the Click here to
view the normal presentation of the same data link to return to the
previous view.
Note
You can use a protocol analyzer that supports reading network traces in
libpcap format to view the packet dump file offline.
Using the Web Applications engine trace
The FirePass Web Applications engine trace feature provides an easy way
for you to capture logs of user web sessions. The logs provide detailed
information about how the FirePass controller is translating the data stream.
Situations when you would use the Web Applications engine trace feature
include the following:
• When a user has trouble connecting to a Web site using a FirePass
controller Web Applications session.
• If a web page is not displaying properly on a client computer.
• If Java or JavaScript is not working on a client computer.
• When the web page contains non-HTML elements, such as XML, Flash,
or ActiveX components, and a client computer cannot access the page.
For more information about using the Web Applications engine trace
feature, see Understanding Web Applications engine trace, on page 13-1.
Monitoring the FirePass controller
You can view statistics, system health information, and near-real-time load
conditions on the FirePass controller. This section contains information on
all of these monitoring methods. You can also use the information in the
FirePass reports. For more information on reports, see Chapter 10, Using
FirePass Controller Reports.
Displaying FirePass controller statistics
You can view statistics and information for the FirePass controller, such as
total memory, average load, performance averages, and number of network
connections. To navigate to the Statistics screen, in the navigation pane,
click Device Management, expand Monitoring, and click Statistics. The
8 - 62
Statistics screen opens, containing measurement data, presented by
interface. You can check Refresh every 20 sec to have the data update and
redisplay every 20 seconds.
Figure 8.1, following, illustrates a typical Statistics screen for a FirePass
4100.
Figure 8.1 A typical Statistics screen for a FirePass 4100
Displaying FirePass controller system health
You can view system health information for the FirePass controller. The
System Health screen displays the measurements for various hardware
components. To navigate to the System Health screen, in the navigation
pane, click Device Management, expand Monitoring, and click System
Health. The System Health screen opens, containing measurement data,
presented by interface.
8 - 63
Chapter 8
You can configure the FirePass controller to send an email to the
administrator if any measured values fall outside of the minimum or
maximum limits. For minimum and maximum limits, see the online help for
the Device Management : Monitoring : System Health screen.
Figure 8.2, following, illustrates a typical System Health screen for a
FirePass 4100 configured for failover.
Figure 8.2 A typical System Health screen for a FirePass 4100
8 - 64
Monitoring the load on a FirePass controller
You can view system load information for the FirePass controller. The
System Load screen displays the measurements for various hardware
components.
Figure 8.3 illustrates a typical System Load screen for a FirePass 4100.
Figure 8.3 A typical System Load screen for a FirePass 4100
To monitor the load on the FirePass controller
Monitoring, and click System Load.
The System Load screen opens.
2. Scroll down to see more graphs of information.
8 - 65
Chapter 8
3. To select the reporting period, click one of the links near the top of
the screen (Last 3 Hours, Last Day, Last Week, and Last Month).
4. To have the data update and redisplay every 20 seconds, check
Refresh every 20 sec.
5. To delete all data from the monitoring database, click the link Click
here to zeroinit the load monitor database at the bottom of the
screen.
Customizing the user’s webtop
You can customize the appearance (logos, colors, and text) and functionality
of the user’s webtop. You can also specify which links are available and the
order in which they appear.
To customize the user’s home page
1. In the navigation pane, click Device Management and click
Customization.
The Customization screen opens.
2. Specify the settings you want.
3. Click the Update button associated with the section containing the
changed settings.
The online help for the Customization screen contains definitions of each
option and presents descriptions of how to use the available features. For
more information about the customization options, see online help for the
Customization screen.
8 - 66
Configuring for multiple languages
The FirePass controller supports multiple languages for user names and
favorites. The FirePass controller retrieves the value of the HTML
Accept-Language tag from the end user’s web browser when the user logs
on. The FirePass controller supports the following languages:
• English
• Japanese
• Simplified Chinese
• Traditional Chinese
• Korean
To set up multi-language support
1. In the navigation pane, click Device Management and click
Customization.
The Customization screen opens.
2. Click to Show Advanced Customization, if it is not already
expanded.
3. Check Choice of language in logon page.
4. From the list, select the language you want to use when presenting
the user’s webtop.
5. If applicable, select the order of the user’s name.
6. Using a localized Windows system, open a new browser instance
and log on to the FirePass controller using a user account.
The system presents the webtop in the language you specify.
Note
You can switch the webtop to English by clicking the Eng link at the top of
the webtop.
To create a user account with a localized user name
1. In the navigation pane, click Users and click User Management.
The User Management screen opens.
2. Create a local user account with a localized username.
3. After the user account is created, you can impersonate a user on the
Users : Impersonate User screen by typing the localized user name
and clicking OK.
8 - 67
Chapter 8
To create a localized favorite
1. In the navigation pane, click Application Access and click App
Tunnels.
The App Tunnels screen opens.
2. Create a favorite using a localized name.
3. Log on as a user, or impersonate a user to see the localized favorite.
Note
The user can switch the webtop to English by clicking the Eng link on their
webtop, but the localized favorite name is not affected by the switch.
8 - 68
9
Using FirePass Controller Client
Components
• Downloading client components
• Using Macintosh and Linux clients with the FirePass
controller
• Establishing client connections
• Understanding Network Access error messages on
Macintosh or Linux clients
• Controlling the client using the command-line
interface
• Using the command-line interface on the client
Downloading client components
The FirePass controller downloads components to the end user’s computer
at initial logon. The type of control downloaded differs depending on the
user’s operating system. For proper functionality, the controls require
certain conditions, as specified in Table 9.1.
Operating system
User authorities
Microsoft Windows
The user must have ActiveX or Java enabled for the
browser.
Either the user has Power User privileges on the
endpoint system, the Network Access client control is
already installed on the system, or the Component
Installer has been installed on the system.
For more information about downloading and installing
the client components, see the online help for the
Network Access : Client Downloads screen. For more
information about the Component Installer, see Using
the Component Installer, on page 9-4.
Apple Macintosh (OS X
only), Linux
The user must have Superuser authority, or the user
must supply the Administrative password at the time of
initial installation.
Table 9.1 Requirements for client component download
Installing client components on Windows systems
Installing and running a FirePass controller component on Windows
systems requires certain user rights. Table 9.2, contains a list of the endpoint
inspectors, and shows the user rights required for downloading and
installing the associated components. Preinstalling components provides
seamless upgrade after server upgrade. For information about preinstalling
components, see Using MSI to preinstall client components, on page 9-3.
You can also use the Component Installer feature to provide completely
transparent installation and upgrading of components, regardless of what
rights under which the user is running. For more information about the
Component Installer, see Using the Component Installer, on page 9-4.
FirePass controller
endpoint inspector
Guest rights
User rights
Power User
rights
Administrator
rights
Check for Google Desktop
No support
Preinstall component
OK
OK
Extended Windows and
Internet Explorer info
No support
OK
OK
Firewall check
No support
OK
OK
Table 9.2 User rights requirements for endpoint inspector support
9-1
Chapter 9
FirePass controller
endpoint inspector
Guest rights
User rights
Power User
rights
Administrator
rights
Check for Antiviruses
No support
OK
OK
Check Processes
No support
OK
OK
Check Registry
No support
OK
OK
Check Files
No support
OK
OK
Switch to PWS
No support
OK
OK
Check Time
OK
OK
OK
OK
Show virtual keyboard
OK
OK
OK
OK
UI mode
OK
OK
OK
OK
Check OS
OK
OK
OK
OK
Check client certificate
OK
OK
OK
OK
Write to Logon log
OK
OK
OK
OK
Send mail
OK
OK
OK
OK
External Far-end check
Varies based on
check required
Varies based on
check required
Varies based on
check required
Varies based on
check required
Table 9.2 User rights requirements for endpoint inspector support
For client systems that have the inspector component pre-installed using the
MSI package, the requirements are the same. In cases in which user rights
are insufficient, although the system cannot download the update, the
previously installed component still works.
You can use the Component Installer feature to provide completely
transparent installation and upgrading of components, regardless of what
rights under which the user is running. For more information about the
Component Installer, see Using the Component Installer, on page 9-4.
For the Java-based client adapters listed in the Table 9.3, Sun Java or
Microsoft Java must be installed on the user workstation.
FirePass controller component
User rights
Power User
rights
Admin rights
Cache cleanup
OK
OK
VT-xxxx legacy terminal (Java)
OK
OK
OK
Table 9.3 User rights requirements for installing and running other FirePass controller components
9-2
FirePass controller component
User rights
Power User
rights
Admin rights
VT-3270 legacy terminal (Java)
OK
OK
OK
TN-5250 legacy terminal (Java)
OK
OK
OK
VT-320 legacy terminal (Java)
OK
OK
OK
X11 UNIX adapter
OK
OK
Microsoft Terminal Server
OK
OK
Citrix Terminal Server
OK
OK
VNC
OK
OK
SSL-VPN connector
Preinstall
component
OK
Application connector
(host name)
OK, but system
cannot modify
Hosts file
OK
Application connector
(IP address)
OK
OK
Table 9.3 User rights requirements for installing and running other FirePass controller components
For client systems that have the components pre-installed using the MSI
package, the requirements are the same. In cases in which user rights are
insufficient, although the system cannot download the update, the
previously installed component still works.
Using MSI to preinstall client components
Your security policy may prohibit granting users the power user rights
needed to install ActiveX components, or your browser security policy may
prohibit downloading active elements. For these reasons, you might prefer
to preinstall components on your users’ Windows systems.
You can use the Device Management : Client Downloads screen to
configure and download a Microsoft Installer Package (MSI) containing the
Windows controls needed for the various FirePass controller functions. You
must also configure the MSI installer to run with elevated privileges so that
it can install the components for users with lesser privileges. For
information about configuring the MSI installer to run with elevated
privileges, see the documentation for your operating system.
This is valid only for Windows. There is no MSI functionality for installing
on client systems running other operating systems.
9-3
Chapter 9
The Client Downloads screen provides tabs for Customize Package,
Customize Client Components, and Download. On the Customize Package
tab, you can specify the components you want in the downloaded package.
On the Customize Client Components tab, you can specify options that
govern Windows logon integration and functionality of the standalone
Windows client. For more information, see the online help for the Device
Management : Client Downloads : Windows (x86) screen.
On the Download tab, you can review the selected components and start the
download operation. You can install downloaded packages onto client
computers, or you can copy the packages to a shared location so that
individual users can complete their own installation.
Using the Component Installer
You can use the Component Installer component to install and upgrade
client-side FirePass controller components for all kinds of user accounts,
regardless of the rights under which the user is running. This component is
especially useful for installing and upgrading client-side components when
the user has insufficient rights to install or upgrade the components directly.
You must use an account that has administrative rights to initially install the
Component Installer on the client computer as a part of Client Components
Package (MSI). Once installed and running, the Component Installer
automatically installs and upgrades client-side FirePass controller
components. It can also update itself.
The Component Installer requires that the installation or upgrade packages
be signed using the F5 Networks certificate or another trusted certificate. By
default, F5 Networks signs all components using the F5 Networks
certificate. You can add your own certificate and use it to sign the
components. For more information, see Adding your own trusted certificates
to the F5FirePassRoot certificate store, following.
Adding your own trusted certificates to the F5FirePassRoot certificate store
The Component Installer service works with components only if they are
signed by the F5 Networks certificates, or a certificate in the special system
store named F5FirePassRoot on the client computer. You can re-sign
components with your own trusted certificate and upload them on the
FirePass controller using the Code Signing tab on the Device Management :
Customization screen. When you add your trusted certificate to that store,
the installer service allows installation and upgrade of packages signed with
your certificate.
You can distribute the certificates to clients computers using the Windows
utility certmgr.exe, or another certificate-distribution utility. For example,
you can specify the following command at the Windows command line to
add one trusted certificate:
certmgr /add /all /c fptrusts.cer /s /r localMachine F5FirePassRoot
9-4
The fptrusts.cer file name represents the name of the certificate file you
received from your Certificate Authority. The rest of the command should
be typed exactly as it appears. You can add multiple certificates by
specifying the command once for each certificate you want to add.
Installing the F5 Networks VPN Client for Windows
Using the standalone client, remote users can access your corporate LAN
without using a Web browser. The client gives users access to these FirePass
controller features:
• Network Access
• Application Access
• Terminal Services
You can use the Client Downloads screen to download the following
components:
◆
F5 Networks VPN Client for Windows
The F5 Networks VPN Client for Windows is a program that allows a
user to initiate and uses Network Access, App Tunnel, and Terminal
Services sessions outside the context of an Internet browser. The F5
Networks VPN Client for Windows uses the FirePass controller API
◆
F5 Networks Client COM API library
The F5 Networks Client COM API library is a set of routines that you
can use to construct standalone applications that allow the user to access
FirePass controller services. The API is provided as a C++ library. The
F5 Networks VPN Client for Windows uses the FirePass controller API
to provide the following functionality:
• Log on to the FirePass controller
• Get a list of authorized, preconfigured favorites
• Select a favorite
• Show parameters of the selected favorite
• Establish a connection to one or more favorites
• Mark a selected favorite to be connected automatically in subsequent
sessions
• Close favorites
• Log out of the FirePass controller
You can find descriptions of optional settings in the online help for the
Customize Windows Client screen. To access the screen, click Device
Management, click Client Downloads, and click the Customize Windows
Client tab.
9-5
Chapter 9
Installing the Networks Client API
The F5 Networks Client API is a library that provides an interface and
methods for use by third-party applications. Using this API, the third-party
applications can access FirePass controller Network Access, App Tunnels,
and Terminal Server Connector favorites. Application vendors can use it to
provide seamless remote access from their proprietary application clients to
application servers inside a network accessible to the FirePass controller.
COM-aware third-party applications can invoke the F5 Networks Client
API. You can create COM-aware applications using any development
environment supporting COM and ActiveX controls; for example,
VisualBasic, VisualC++, and Delphi.
You can also use the F5 Networks Client API inside scripts, including
scripts of the following type: JavaScript, VBScript inside Internet Explorer,
and Windows Scripting Host.
For more information about using the F5 Networks Client API, and the
available interfaces, methods, and events, please visit F5 DevCentral at
http://devcentral.f5.com/. F5 DevCentral provides technical
documentation and tips, as well as a developer forum for posting feedback
and questions about using the F5 Networks Client API.
9-6
Using Macintosh and Linux clients with the FirePass
controller
The FirePass controller includes Network Access support for remote
Macintosh® and Linux® clients, so you can use the FirePass controller for
secure remote access in mixed-platform environments. As with the
Windows platform support, you do not need to preinstall or preconfigure
any client software when using FirePass controller with Macintosh and
Linux systems.
Introducing supported Network Access features
All of the primary Network Access features are supported on Macintosh and
Linux clients. For a list of Network Access features, see Configuring
Network Access resource group settings, on page 5-19. The FirePass
controller does not support Drive Mappings or Policy Checks features on
Macintosh and Linux systems.
For more information about Network Access and configuring Network
Access features, see Chapter 5, Configuring Network Access.
Features supported on Macintosh and Linux clients include:
• Secure remote access to your internal network, with support for IP-based
applications.
• Split tunneling, so only network traffic that you specify goes through the
• Packet-based and group-based IP filtering, giving you the ability to
restrict groups of users to specific addresses, ranges of addresses, and
ports.
• Compression, to reduce the amount of traffic passing between the remote
client and your internal network.
• Application launching.
You must configure the starting of remote client applications based on
the operating system on the remote computers. You can configure all
other features independent of the remote client operating systems. For
details, see Configuring the starting of applications on Macintosh or
Linux clients, on page 9-9.
9-7
Chapter 9
Using Macintosh clients
The current version of the FirePass controller has been verified for use with
the Macintosh platforms listed in Table 9.4, following.
OS X
version
Browser version
Java
version
Auto install
10.4.2
Safari 2.0
1.4.1
OK
10.4.2
Mozilla 1.7.8
1.3.1
No support
10.4.2
FireFox 1.0.6
1.3.1
No support
10.3.9
Safari 1.2
1.4.1
OK
10.3.9
Mozilla 1.7.8
1.3.1
No support
10.3.9
FireFox 1.0.6
1.3.1
No support
10.2.8
Mozilla 1.7.8
1.3.1
No support
Table 9.4 Macintosh Network Access compatibility
Using Linux clients
The current version of the FirePass controller has been verified for use with
the Linux platforms listed in Table 9.5, following.
Linux
version
Browser version
Auto
install
Redhat 9.0
Mozilla 1.7.11 and Mozilla 1.7.8
OK
SuSe 9.3 Professional
FireFox 1.0.1 and Mozilla 1.7.5
OK
FireFox 1.0 and Mozilla 1.7.2
OK
Mozilla 1.7.2
OK
Mozilla 1.4
OK
Fedora Core 4
FireFox 1.0.4
OK
Fedora Core 3
FireFox 1.0
OK
Fedora Core 2
Firefox 1.0.6 and Mozilla 1.7
OK
Debian® 3.1r0
Mozilla 1.6
OK
Table 9.5 Linux Network Access compatibility
9-8
Linux
version
Browser version
Auto
install
TurboLinux® Desktop 10
Mozilla 1.4
OK
Slackware 10.1
Mozilla 1.75
OK
Table 9.5 Linux Network Access compatibility
Configuring the starting of applications on Macintosh or Linux
clients
The launch application feature specifies a client application that starts when
the client begins a Network Access session. You can use this feature when
you have remote clients who routinely use Network Access to connect to an
application server, such as a mail server.
To configure the application start for Macintosh and Linux
1. In the navigation pane, click Network Access.
The Network Access Client Settings screen opens.
2. From the For the group list (above the tabs), select the group for
which you are configuring application launch settings.
The screen refreshes to display the information for the group you
selected.
Note: The group must already exist in order to configure Network
Access for that group. For information on creating groups, see
Managing user information in an external data store, on page 2-6.
3. Click the Launch Application tab near the top of the screen.
The Launch Applications screen opens.
4. In the App Path box, type the path of the application.
For example:
• For Macintosh, type open.
• For Linux, type /usr/bin/mozilla.
5. In the Parameters box, type any parameters you want to include.
For example:
• For Macintosh, type /Applications/ie.app http://www.f5.com.
• For Linux, type http://www.f5.com.
6. From the OS list, select an option.
• For Macintosh, select Mac.
• For Linux, select UNIX.
7. Click Add to add the configuration.
When remote users in the group make a Network Access
connection, the application you configured starts automatically.
9-9
Chapter 9
Installing the client on Macintosh and Linux systems
The first time a remote user starts Network Access, the FirePass controller
downloads a client component. This client component is designed to be
self-installing and self-configuring, but the user’s browser must have Java
enabled on Macintosh systems, or have Mozilla or Firefox to install a plugin
on Linux systems.
If the browser does not support this requirement, the FirePass controller
prompts the user to download the controller client component from the
controller and install it manually. Users can find instructions on
downloading the components manually on the Network Access Help page,
available on their webtop after they log on to the FirePass controller.
Important
The remote user must have superuser authority, or must be able to supply an
administrative password in order to successfully install the Network Access
client.
Both Macintosh and Linux systems must also include PPP support (this is
most often the case). When the user runs the Network Access client and
makes a connection for the first time, the client detects the presence of pppd
(the point-to-point protocol daemon), and determines whether the user has
the necessary permissions to run it. If pppd is not present, or if the user does
not have permissions needed to run the daemon, the connection fails.
After installation, the Macintosh client must restart the browser before
launching Network Access.
Note
If you have a firewall enabled on your Linux system, you need to enable
access on IP address 127.0.0.1 port 44444.
9 - 10
Establishing client connections
Users can initiate connections through Network Access from Windows,
Linux, and Macintosh OS X systems, using various browsers. They can also
use Network Access from Windows mobile versions on PDAs and Pocket
PC phones.
For a list of browsers that Network Access supports, see Using Macintosh
clients, on page 9-8, and Using Linux clients, on page 9-8. For a complete
list of the clients that the FirePass controller supports, see the most current
version of the release notes.
Important
When the user clicks a configured Network Access link, a small window
opens. It must remain open for the whole duration of the Network Access
session. If the user closes the window, it terminates the connection.
Note
On Microsoft Windows platforms, the user might also see a new network
connection icon in the system tray.
9 - 11
Chapter 9
Understanding Network Access error messages on
Macintosh or Linux clients
Macintosh or Linux clients might receive error messages while working
with Network Access connection. Table 9.6, following, contains a list of the
error messages as well as a description of their meaning and any
recommendations for resolving the error.
Error
code
1
Meaning
Another Network Access client is already running
The client is either running or is in its shutdown stage. Wait a few
seconds, and try connecting again.
2
Invalid version format
3
Control channel timeout on wait state during handshake
4
Null input received by control channel
5
Control channel timeout while in session
6
Unrecognized command from control channel while in session
7
Unrecognized command from control channel during handshake
8
Deadlock detected while acquiring lock
9
Unrecognized command from plugin during handshake
10
Invalid command for handling bytes transmitted
11
Invalid command for handling bytes received
12
Control channel does not receive initial handshake
13
Network Access client does not start
14
Timeout on reading initial configuration from the FirePass controller
15
Invalid format on parameters from the FirePass controller
16
Invalid local IP address on parameters from the FirePass controller
17
Invalid local port on parameters from the FirePass controller
18
Invalid session ID format on parameters from the FirePass controller
19
No session ID was specified
20
Cannot resolve the FirePass controller IP address
Table 9.6 Network Access error codes on Linux or Macintosh clients
9 - 12
Error
code
Meaning
21
The FirePass controller IP address was not specified
22
Control channel socket error
23
Control channel does not respond to default command
24
Control channel hangs on disconnection or does not respond
25
Unrecognized command from plugin while in session
26
Control channel window timeout
27
PPP daemon or the FirePass controller file descriptors have changed
28
SSL handshake with the FirePass controller failed
29
No DNS server was specified
30
Timeout while receiving command from plugin
31
Timeout while sending information to plugin
32
Signal caught
33
Invalid remote IP address on parameters from the FirePass controller
34
Timeout while writing to Network Access tunnel
Possible network reconfiguration caused the connection to the FirePass
controller to drop.
35
Timeout while reading from PPP daemon
36
Timeout while writing to PPP daemon
37
Timeout while reading from Network Access tunnel
38
Network Access client initialization error
39
Invalid split tunneling settings on parameters from the FirePass controller
40
Timeout while starting PPP daemon
41
PPP daemon does not exist on the host system
Verify that PPP daemon is installed or has been installed at the
non-standard location.
42
Cannot open pseudo terminal
Table 9.6 Network Access error codes on Linux or Macintosh clients
9 - 13
Chapter 9
Controlling the client using the command-line
interface
You can access and control the Windows Standalone Client interactively or
using an API. Using the command-line interface (CLI), you can employ
scripted applications to establish a Network Access connection, and to open
one or more App Tunnels.
The standalone client CLI supports the following commands:
• -start
Begins a FirePass controller session, logs on to the specified host, and
automatically runs the Network Access favorites specified in parameters.
For more information, see Using the -start command, following.
• -stop
Halts the specified session or specified favorite within a session. For
more information, see Using the -stop command, on page 9-17.
• -info
Posts to the screen information about sessions and favorites. For more
information, see Using the -info command, on page 9-19.
• -profile
Posts to the screen information about the profile specified. For more
information, see Using the -profile command, on page 9-23.
• -help
Posts to the screen information about the CLI commands. For more
information, see Using the -help command, on page 9-25.
Using the -start command
You can use the -start command to begin a session with the FirePass
controller, log on to the controller, and run one or more favorites. The
command returns a 0 (zero) when successful, and writes the assigned
session ID to stdout.
You can specify that -start run in one of two modes.
• Blocked
Returns on failure or upon completion of a specified operation (for
example, session establishment or favorite start).
• Nonblocked
Starts the specified operation and immediately returns a value, without
waiting for the operation to complete. You can use the -info command to
get operation status at a later time.
9 - 14
Overview of -start command arguments
The -start command provides arguments for using an ID to start a session or
favorite or a name to start a favorite. Table 9.7 contains a list of the
arguments that the -start command supports.
Parameter
Alias
Values
Description
Comment
/config
/c
String
Specifies the configuration
profile file name.
Uses the default program profile, if
/conf is not specified.
/nonblock
/nb
None
Turns on nonblocking mode.
Returns immediately.
/host
/h
[http|https]host[:port]
[/landing_uri]
Represents the FirePass
controller host name.
If no value is specified, uses the
default value from the program
profile or presents a dialog box.
/user
/u
String
Indicates the user name.
/password
/p
String
Indicates the password.
/userhex
/uh
String
Indicates the user name in
hex-encoded format.
/passwordhex
/ph
String
Indicates the password in
hex-encoded format.
/mode
/m
[simple|advanced]
Indicates the UI mode.
Simple is the default mode.
/sid
/s
String
Indicates the session ID.
Starts a favorite in an already
established session.
/sid is a required parameter. All
other parameters are optional.
You can use the -info command
to get the /sid value.
/fid
/f
String
Represents the favorite’s
unique ID.
to get the /fid value.
/fname
/n
name[:{vpn|apptunnel
|terminal}]
Indicates the name of the
favorite to affect.
You can also specify a type if the
name is not unique.
to get the /fname value.
/verbose
/v
None
Enables verbose output to
stdout.
/minimize
/t
None
Minimizes the window after
start.
Table 9.7 Command arguments for the -start command
9 - 15
Chapter 9
Process exit codes for the -start command
The process returns an exit code that indicates the status of the command.
Table 9.8 contains the value and description of each code that the -start
command returns.
Code
Description
0x0
Operation completed successfully.
0x1
User terminated operation.
0x2
Authentication attempt failed.
0x4
Autolaunch operation failed.
0x8
User attention requested.
0x10
Favorite start failed.
0x100
Error unknown.
0x200
Parameter unknown.
0x300
Parameter value incorrect.
0x400
Session ID unknown.
0x500
Favorite ID unknown.
Table 9.8 Process exit codes for the -start command
Examples of using the -start command
This section presents examples of possible -start command sequences.
Note
You can get session and favorite ID values using the -info command.
Description
Runs the standalone client in simple mode and does not send a return value
until the system authenticates the user and establishes the session.
Command
f5fpc -start /h firepass.com:443 /u joe
Output
session id: 15
9 - 16
Description
Establishes a session named corp and starts the favorite named sales in
nonblocking mode.
Command
f5fpc -start /nb /h firepass.com /u joe /p password /m advanced /n corp:vpn /n
sales:apptunnel
Output
session id: 15
Description
Starts the favorite named sales in the already established session with a
session ID of 15.
Command
f5fpc -start /s 15 /n sales:vpn
Description
Starts the favorite whose favorite ID is 1 in the already established session
with a session ID of 345.
Command
f5fpc -start /s 345 /f 1
Using the -stop command
You can use the -stop command to halt the session or specified favorite.
Note
9 - 17
Chapter 9
Overview of -stop command arguments
The -stop command provides arguments for using an ID to halt a session or
favorite, or using a name to halt a favorite. You must specify a session ID
for all -stop commands. Table 9.9 contains a list of the arguments that the
-stop command supports.
Parameter
Alias
Values
Description
Comment
/sid
/s
string
Halts the session as well as all
established favorites running in
the session.
/sid is a required parameter. All
other parameters are optional.
to get the /sid value.
/fid
/fname
/f
/n
string
unique ID.
|terminal}]
favorite to affect.
You must also include the /sid.
to get the /fid value.
name is not unique.
to get the /fname value.
Table 9.9 Command arguments for the -stop command
Process exit codes for the -stop command
Table 9.10 contains the value and description of each code that the -stop
command returns.
Code
Description
0x0
0x100
Error unknown.
0x200
Parameter unknown.
0x300
0x400
Session ID unknown.
0x500
Table 9.10 Process exit codes for the -stop command
9 - 18
Examples of using the -stop command
This section presents examples of possible -stop command sequences.
Note
Description
Closes the Network Access connection whose session ID is 15, and halts all
running favorites.
Command
f5fpc -stop /s 15
Description
Closes the Network Access connection whose name is corp, and halts all
running favorites.
Command
f5fpc -stop /s 15 /n corp:vpn
Description
Stops the favorite whose ID is 1 running in the session whose ID is 345.
Command
f5fpc -stop /s 345 /f 1
Using the -info command
The -info command provides information about sessions and favorites
running on the FirePass controller. You use the -info command to retrieve
session and favorite information to use in conjunction with the -start and
-stop commands.
Overview of -info command arguments
The -info command provides arguments for retrieving session or favorite
information and favorite names. The system presents information in the
following format:
session_id favorite_id favorite_type favorite_name status_code user_friendly_message
The following example illustrates a sample of the output that the -info
command returns.
15 1 vpn EMPLOYEE 0 available
9 - 19
Chapter 9
Table 9.11 contains a list of the arguments that the -info command supports.
Parameter
Alias
Values
Description
Comment
/sid
/s
string
For -info commands that do not
contain a value for /sid, the
operation returns a list of all
sessions and statuses.
For -info commands that contain a
value for /sid, the operation
returns a list of favorites and their
status codes.
For -info commands that do not
contain a value for /fid or /fname,
the operation returns a list of all
favorites and status codes.
For -info commands that contain a
value for /fid or /fname, the
operation returns information
about that favorite only.
/fid
/f
string
unique ID.
/fname
/n
|terminal}]
favorite to affect.
name is not unique.
Table 9.11 Command arguments for the -info command
Process exit codes for the -info command
Table 9.12 contains the value and description of codes that the -info
command returns.
Code
Description
0x0
0x100
Error unknown.
0x200
Parameter unknown.
0x300
0x400
Session ID unknown.
0x500
Table 9.12 Process exit codes for the -info command
Other codes returned depend on parameters specified.
9 - 20
Examples of using the -info command
This section presents examples of possible -info command sequences.
Description
Returns all active sessions.
Command
f5fpc -info
Output
there are 2 active sessions
session code status
15 1 session established
345 4 user should select host from presented list
Note
The code value returned represents the session status. For information
about session status codes, see Session status codes, following.
Description
Returns the status and list of favorites for session whose ID is 15.
Command
f5fpc -info /s 15
f5fpc -info /s 15 /f 1
session code status
15 1 session established
session favorite type name code status
15 1 vpn network1 1 established
15 2 apptunnel AS400 0 available
15 3 apptunnel SALES 0 available
Description
Returns information about the favorite whose ID is 1, which is running in
the session whose ID is 15.
Command
f5fpc -info /s 15 /f 1
9 - 21
Chapter 9
Return
15 1 vpn network1 1 established
Note
The code value returned represents the favorite status. For information
about favorite status codes, see Session status codes, following.
Description
Returns information about the favorite whose name is sales, which is
running in the session whose ID is 15.
Command
f5fpc -info /s 15 /n SALES:apptunnel
Return
15 3 apptunnel SALES 0 available
Note
The code value returned represents the favorite status. For information
about favorite status codes, see Favorite status codes, on page 9-23.
Session status codes
Table 9.13 contains the value and description of session codes that the -info
command returns.
code
status
0x1
Session established.
0x2
Logon in progress.
0x4
User must select the host from presented list.
0x8
Autolaunch in progress.
0x10
User attention required.
Table 9.13 Session status codes for the -info command
9 - 22
Favorite status codes
Table 9.14 contains the value and description of favorite status codes that
the -info command returns.
code
status
0x0
Favorite not active.
0x1
Favorite running.
0x2
Favorite connecting.
0x10
Process requires attention.
Table 9.14 Favorite status codes for the -info command
Using the -profile command
Returns information from the profile configuration file. The profile contains
information such as FirePass controller IP address and gateway IP
addresses,
Overview of -profile command arguments
The -profile command provides an argument for specifying the
configuration file name. Table 9.15 contains a list of the arguments that the
-profile command supports.
Parameter
Alias
Values
Description
Comment
/conf
/c
string
Represents the
configuration profile file
name.
If no /conf value is specified, the
operation uses the default current
program profile.
Table 9.15 Command arguments for the -profile command
9 - 23
Chapter 9
Process exit codes for the -profile command
Table 9.16 contains the value and description of codes that the -profile
command returns.
Code
Description
0x0
0x100
Error unknown.
0x200
Parameter unknown.
0x300
Table 9.16 Process exit codes for the -profile command
Examples of using the -profile command
This section presents examples of possible -profile command sequences.
Description
Returns information about the FirePass controllers configured in the default
profile file.
Command
f5fpc -profile
Return
Name Address Port Description
Main 44.58.251.1 443 The main gateway
Asia 28.45.13.22 443 Asia gateway
9 - 24
Using the -help command
Returns help for a specific command.
Overview of -help command arguments
The -help command provides an argument for specifying the configuration
file name Table 9.17 contains a list of the arguments that the -help
command supports.
Parameter
Alias
Values
Description
Comment
/help
-?
/?
string
Represents the command.
If no command is specified,
displays a list of all commands.
Table 9.17 Command arguments for the -help command
Examples of using the -help command
This section presents examples of possible -help command sequences.
Description
Returns a list of all standalone client CLI commands.
Command
f5fpc -help
f5fpc /?
Description
Returns help about the -start command.
Command
f5fpc -start /?
Description
Returns help about the -stop command.
Command
f5fpc -stop -help
9 - 25
Chapter 9
Using the command-line interface on the client
You can configure the FirePass Windows Client for download to a user’s
computer.
To configure the FirePass Windows Client for download
1. In the navigation pane, click Device Management, expand Client
Downloads, click Windows (x86), and click the Customize
Package tab.
2. Check the FirePass Windows Client check box.
3. Click the Download tab.
The Download screen opens.
4. Click the Download link, and save the f5fpcsetup.exe file to the
location you want.
To configure Network Access favorites.
1. In the navigation pane, click Network Access, and click Resources.
The Network Access Resources screen opens.
2. Configure Network Access favorites.
3. Click Application Access, click App Tunnels, and click
Resources.
The App Tunnels screen opens.
4. Configure App Tunnel favorites.
To configure Network Access favorites.
1. Log on to a client computer.
2. Double-click f5fpcsetup.exe, and follow the instructions to install
the FirePass Windows Client.
To use the FirePass Windows Client CLI
1. Log on to a client computer.
2. To open a Windows command window, click Start, select Run, and
type cmd in the box.
The Windows command window opens.
3. At the command prompt, type cd /d "C:\Program Files\F5 VPN"
Include the quotation marks in the string you type.
4. Run a command. The following are examples of commands you can
run.
9 - 26
• To list all FirePass controller Windows Client CLI commands, at
the command prompt, type f5fpc -help
• To list all options for the -info command, at the command
prompt, type f5fpc -info /?
• To open a Network Access session, at the command prompt, type
f5fpc -start /h <FirePass> /u <username> /p <password>
• To get information about the current Network Access session, at
the command prompt, type f5fpc -info
At this point, the Network Access session should not be active.
• To use the session ID returned in the previous command to get
more detailed information about this session, at the command
prompt type
f5fpc -info /s <session>
• To start Network Access using a favorite ID returned in the
previous command, type
f5fpc -start /s <session> /f <favorite-id>
• To view the status of the open App Tunnel, type
This time, the operation should report an established Network
Access connection.
• To use the session ID returned in the previous command to get
more information about the session, at the command prompt, type
• To open an App tunnel using a favorite ID returned in the
previous command, at the command prompt, type
f5fpc -start /s <session> /f <favorite-id>
• To view the status of the open App Tunnel, at the command
prompt, type f5fpc -info /s <session>
• To use the favorite ID to close the App Tunnel, at the command
prompt, type
f5fpc -stop /s <session> /f <favorite-id>
• To use the session ID returned in the previous command to close
the current session, including the Network Access connection, at
the command prompt, type f5fpc -stop /s <session>
• To get the session information again, and confirm that the session
has been closed, at the command prompt, type fpfpc -info
9 - 27
Chapter 9
9 - 28
10
• Overview of FirePass controller reports
• Using the App Logs report
• Using the Group report
• Using HTTP Log reports
• Using the Logons report
• Using the Sessions report
• Using the Summary report
• Using the System Logs report
Overview of FirePass controller reports
You can display and print reports that describe FirePass controller activity
and status. You can also download and save a report as a Microsoft® Excel
(.xls) file.
You can find several types of reports on the Reports screen. To access the
reports screen, in the navigation pane, click Reports.
◆
Application Logs (App Logs) report
Provides aggregate and per-user access logs. For more information, see
Using the App Logs report, on page 10-2.
◆
Group report
Provides a snapshot of the user-group distribution and group-based usage
averages. For more information, see Using the Group report, on page
10-4.
◆
HTTP and HTTPS Log report
Provides various types of server logs, such as a HTTP and HTTPS server
access logs, HTTP and HTTPS server error logs, and a SSL engine log.
For more information, see Using HTTP Log reports, on page 10-6.
◆
Logons report
Provides a list of all attempts to log on to the FirePass controller. For
more information, see Using the Logons report, on page 10-10.
◆
Sessions report
Provides a list of all active user sessions and a history of sessions, along
with the corresponding user names, logon names, times, and status. For
more information, see Using the Sessions report, on page 10-12.
◆
Summary report
Provides a summary of global or group-based user activity, including
statistics, and descriptions of browser-type usage over specified periods
of time. For more information, see Using the Summary report, on page
10-16.
◆
System Logs report
Displays local system logs. If you use an external syslog server, only
errors are logged locally. For more information, see Using the System
Logs report, on page 10-18.
For information about archiving and purging logs, see the online help for the
Device Management : Maintenance : Logs screen.
10 - 1
Chapter 10
Using the App Logs report
The App Logs report contains a list of entries that indicate actions that users,
administrators, and the FirePass controller superuser performed on the
FirePass controller. You can use the App Logs report to track user activity
on the FirePass controller.
To display the App Log report
1. In the navigation pane, click Reports, and click App Logs.
The App Logs report screen opens.
2. Choose the options you want or download the log.
For more information about App Logs report options, see Working
with the App Logs report, following.
Working with the App Logs report
You have several options when working with this particular report. You can
take any one of these actions, several of them, or all of them.
• To download and open the report as an Excel (.xls) file, click the
Download report data link.
The process starts the local or browser-based Excel application and
opens the report.
• To save the report locally on a Windows-based computer, right- click the
Download report data link, and then follow the instructions to save the
report to your local desktop.
• In reports that contain more than 20 records, navigate to other screens by
clicking the icons at the top of the screen for first , previous , next ,
and last .
• To filter the report for a specific user, click the link representing the
user’s name in the Logon column.
To show all users again, click the Show all records link at the top of the
report.
• To display details about a specific session, click a link in the Session ID
column.
To return to the App Logs screen, click the Back to Reports : App Logs
page link at the top of the screen.
10 - 2
Understanding entries in the App Logs report
Each entry in the App Logs report contains data that identifies one action or
operation by a user. The FirePass controller records all user operations. You
can use the contents of this log to monitor user activity on the FirePass
controller.
The log contains several types of data.
• Time
Represents the start date and time of the associated session. A typical
Time value looks similar to the following example: 10/25/2005 0:28.
• Source IP
Represents the IP address where the session originated. A typical Source
IP looks similar to the following example: 192.168.12.10.
• Logon
Represents the name for the logged on user who originated the session. A
typical Logon looks similar to the following example: joeu
• Session ID
Represents the unique identifier assigned to the session. A typical
Session ID looks similar to the following example: f8e63
• Record
Represents a single action recorded for the associated user. A typical
Record looks similar to the following example: [594330] Access menu
App Logs.
• User agent string
Represents the string the browser returns to identify itself. A typical User
agent string looks similar to the following example: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1).
10 - 3
Chapter 10
Using the Group report
The Group report provides a snapshot of the user-group distribution and
group-based averages. The FirePass controller records activity for each
group.
To work with the Group report
1. In the navigation pane, click Reports, and click Group Report.
The Group report screen opens.
For more information about Group report options, see Working with
the Group report, following.
Working with the Group report
opens the report.
• To specify a varying date range for the Group report:
• Select starting date from the Reporting period from lists.
• Select the ending date from the to (inclusive) lists.
• Click the
icon.
• To restrict the report to a predefined date range, click the Last Week,
Last 2 Weeks, Last Month, or Last Year links.
The dates in Reporting period from and to (inclusive) change to reflect
the predefined range.
Understanding entries in the Group report
Each entry in the Group report contains data that identifies how users from
the various master groups have used the FirePass controller. You can use the
contents of this log to determine the activity level of each master group on
the FirePass controller. If no users from a specific master group logged on
during the report interval, there is no entry for that group in the report.
10 - 4
The Group log contains several types of data.
• Group
Represents the name of the master group. A typical Group value looks
similar to the following example: Default.
• Users
Represents two variables: the number of user accounts in the master
group shown in the Group value, and the percentage of the total users in
all master groups. A typical Users entry looks similar to the following
examples: for user accounts: 9, and for percent of total: 67%.
• Sessions
Represents the two variables: the total number of logons by users in the
master group shown in the Group value, and a percentage of the total
logons for users in all groups. A typical Sessions entry looks similar to
the following examples: total: 15, and for percent of total: 92%.
• Avg. Time at
Shows a calculated average of time spent in Desktop Access or on the
FirePass controller webtop. The entry is a number representing the
average number of seconds in each mode during the reporting period.
• Favorite webifyer
Represents the unique identifier assigned to the session. Some possible
values include Windows Files, Terminal Servers, and Web Applications.
10 - 5
Chapter 10
Using HTTP Log reports
The HTTP Log report provides several types of server logs. You can use
entries the various logs to monitor the HTTP activity on the FirePass
controller.
• HTTP server access log
• HTTP server error log
• HTTPS server access log
• HTTPS server error log
• SSL engine log
The FirePass controller updates content in the logs in the HTTP Log report
on a daily basis. You can use an online calendar to select the day for which
you want to display a HTTP Log report.
To work with the HTTP Log report
1. In the navigation pane, click Reports, and click HTTP Logs.
The HTTP Logs report screen opens.
For more information about HTTP Log report options, see Working
with the HTTP Log report, following.
Working with the HTTP Log report
• To sort the list, click the Date, Class, IP, ID, or Text column at the top of
the report.
The column heading that the screen is using to sort the logs is not active.
• From the list at the top of the screen, select a log type, and then click the
the go button .
• To download the log, click the log name link at the top of the report, and
follow the instructions to open or save the report.
• To reveal the page-navigation and online calendar boxes, click the
icon. Then do any of the following:
• To display a specific page, type the page number in the Select Page
box, and then click the Go button.
• To specify the number of records per page, type the number of records
in the Records Per Page box, and then click the Go button.
• Click the Calendar link, and click the date for which you want to
display the report.
• To display additional records in the report, click the previous , or
next icons at the top or bottom of the report to view the previous or
next 20 records.
10 - 6
Understanding entries in the HTTP Logs report
The HTTP Logs report provides access to several logs containing different
types of data. Each entry in the HTTP Logs report contains data that
describes the HTTP commands that the FirePass controller runs. The HTTP
Logs report consist of several logs.
• Server access log (http)
• Server error log (http)
• Server access log (https)
• Server error log (https)
• SSL engine log
Understanding the Server access log (http) log
You can download extra-access_log to view the content of the Server
access log (http). To download the log, click the log name at the top of the
table.
The Server access log (http) contains several types of data.
• Date
Date value looks similar to the following example:
[24/Oct/2005:00:17:48 -0700].
• Class
Represents the class of event associated with the entry in the log. The
Server access log (http) does not have any associated Class values.
• IP
Represents the IP address where the session originated. A typical IP
looks similar to the following example: 192.168.12.10.
• ID
Represents the unique identifier assigned to the log entry. A typical ID
value looks similar to the following example: 400.
• Text
Represents the HTTP command that the FirePass controller processed. A
typical Text value looks similar to the following example: "GET
/vdesk/admincon/index.php?a=welcome&click=1 HTTP/1.1" 200
3095.
10 - 7
Chapter 10
Understanding the Server error log (http) log
You can download extra-error_log to view the content of the Server error
log (http). To download the log, click the log name at the top of the table.
The Server error log (http) contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
Represents the class of event associated with the entry in the log. A
typical Class value looks similar to the following example: notice.
• IP
• ID
• Text
Represents the HTTP command that the FirePass controller processed. A
typical Text value looks similar to the following example: "CONNECT
10.4.10.10:81 HTTP/1.0" 200 0.
Understanding the Server access log (https) log
You can download https.extra-access_log to view the content of the Server
access log (https). To download the log, click the log name at the top of the
table.
The Server access log (https) contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
Represents the class of event associated with the entry in the log. The
Server access log (https) does not have any associated Class values.
• IP
• ID
• Text
Represents the HTTPS command that the FirePass controller processed.
A typical Text value looks similar to the following example: "GET
/vdesk/admincon/stats.php?a=lo&exp=&newpage=29&newerrpp=20
&newfilen=2&sorttype=&go=1 HTTP/1.1" 200 13180.
10 - 8
Understanding the Server error log (https) log
You can download https.extra-error_log to view the content of the Server
error log (https). To download the log, click the name at the top of the table.
The Server error log (https) contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
typical Class value looks similar to the following example: notice.
• IP
Represents the IP address where the session originated. The Server error
log (https) does not show any IP values.
• ID
Represents the unique identifier assigned to the log entry. The Server
error log (https) does not show any ID values.
• Text
Represents the HTTPS command that the FirePass controller processed.
A typical Text value looks similar to the following example: Apache
configured -- resuming normal operations.
Understanding the SSL engine log
You can download ssl_engine_log to view the content of the SSL engine
log. To download the log, click the log name at the top of the table.
The SSL engine log contains several types of data.
• Date
[24/Oct/2005:00:17:48 -0700].
• Class
typical Class value looks similar to the following example: error.
• IP
Represents the IP address where the session originated. The SSL engine
log does not show any IP values.
• ID
• Text
Represents errors that the SSL engine sent to the FirePass controller. A
typical Text value looks similar to the following example: System: No
such file or directory (errno: 2).
10 - 9
Chapter 10
Using the Logons report
The Logon report provides a list of attempts to log on to the FirePass
controller, both successful and unsuccessful.
You can filter the report for unsuccessful attempts, which quickly provides
an audit trail for detecting access attempts by unauthorized sources. In
addition, the FirePass controller administrator receives a security alert
message if a specified number of unsuccessful attempts (default 20) to log
on occur within a configurable interval (default 5 minutes). You can change
the number of unsuccessful attempts and configure the interval on the User
Access Security screen, available under Security in the navigation pane.
To work with the Logons report
1. In the navigation pane, click Reports, and click Logons.
The Logons report screen opens.
For more information about Logons report options, see Working
with the Logons report, following.
Working with the Logons report
opens the report.
and last .
• To filter the report for unsuccessful logon attempts, click the Show
Failures link.
To show all logon attempts, click the Show All link.
To display details about a particular logon attempts, click the link for the
user’s name.
10 - 10
Understanding entries in the Logons report
Each entry in the Logons report contains data that describes the logons on
the FirePass controller. You can use the contents of this log to monitor logon
activity on the FirePass controller.
The Logons report contains several types of data.
• Logon
typical Logon looks similar to the following example: joeu.
• Valid user?
Indicates whether the user who attempted the logon operation was
recognized as a user on the FirePass controller. Values for Valid user?
are Yes and No.
• Passed?
Indicates whether the logon attempt succeeded. Values for Passed? are
Yes and No.
• Name
Represents the values from the First Name and Last Name fields in the
user’s details. If the FirePass controller cannot determine an associated
user, the Name field contains N/A.
• Time (<time_zone>)
Represents the start date and time of the associated session, represented
in the time zone configured for the controller. A typical Time value looks
similar to the following example: 10/25/2005 0:28.
• User agent
Represents the string the browser returns to identify itself. A typical User
agent string looks similar to the following example: Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511.
• From
Represents the IP address where the session originated. A typical From
value looks similar to the following example: 10.40.11.4.
10 - 11
Chapter 10
Using the Sessions report
The Sessions report provides various types of reports for user sessions and a
history of sessions, along with the corresponding user names, logons,
session duration, and status.
To display the Session report
1. In the navigation pane, click Reports, and click Sessions.
The Sessions report screen opens.
For more information about Sessions report options, see Working
with the Sessions report, following.
Working with the Sessions report
opens the report.
and last .
• To have the data update every 20 seconds, check the Refresh every 20
sec check box.
• To filter the list for a specific user, type a logon name in the Show
sessions for box, and then click the magnifying glass
.
To show all users, clear the Show sessions for box, and then click the
magnifying glass
.
• To show a list of currently active sessions, click the Currently active tab.
On the Currently active tab, you can halt a specific session by clicking
the associated Kill link at the end of the row.
• To show a list of the sessions for the current day, click the Today’s
sessions tab.
On the Today’s sessions tab, you can get details about a specific session
(such as browser type or IP address) by clicking a date link in the Start
column.
10 - 12
• To show a list of all sessions that have occurred, click the Complete
History tab.
On the Complete History tab, you can get details about a specific session
(such as browser type or IP address) by clicking a date link in the Start
column.
• To show daily aggregate session counts, click the Session Summary tab.
On the Session Summary tab, you can get details about a specific session
by clicking a link in the Date column.
Understanding entries in the Sessions report
Each entry in the Sessions report contains data that describes session activity
on the FirePass controller. You can use the contents of these logs to monitor
sessions on the FirePass controller.
The Sessions report provides access to several logs containing different
types of data.
Understanding the Currently active log
The Currently active log contains a list of the active connections to the
FirePass controller. The Currently active report contains several types of
data.
• Name
user’s details. If the FirePass controller cannot determine an associated
user, the Name field contains N/A.
• Logon
typical Logon looks similar to the following example: joeu.
• Start Time (<time_zone>)
in the time zone configured for the controller. A typical Start Time value
looks similar to the following example: 10/25/2005 01:21:54.
• Expiration Time (<time_zone>)
in the time zone configured for the controller. A typical Expiration Time
value looks similar to the following example: 10/25/2005 001:21:54.
• Status
Indicates the status of the associated session. A typical Status value looks
similar to the following example: Logged on server.
• Id
Represents the unique identifier assigned to the session. A typical Id
value looks similar to the following example: f8e63.
10 - 13
Chapter 10
Understanding the Today’s sessions log
The Today’s sessions log contains a list of the active connections to the
FirePass controller. The Today’s sessions report contains several types of
data.
• Start (<time_zone>)
in the time zone configured for the controller. A typical Start value looks
similar to the following example: 10/25/2005 01:21:54.
• User
Represents the logon name of the logged on user who originated the
session. A typical User value looks similar to the following example:
joeu.
• Name
user’s details.
• Duration
Represents the length of the session, in the format HH:MM:SS, where
HH represents the hour, in 24-hour format, MM represents the minutes,
from 1 through 60, and SS represents the seconds, from 1 through 60. A
typical Duration value looks similar to the following example: 00 24 43.
• From
• To
Indicates the type of connection requested. A typical To value looks
similar to the following example: MyNetwork.
• Status
Indicates the status of the session. A typical Status value looks similar to
the following example: Server session in progress.
Understanding the Complete history log
The Complete History log contains a list of the active connections to the
FirePass controller. The Complete History report contains several types of
data.
• Start (<time_zone>)
in the time zone configured for the controller. A typical Start value looks
similar to the following example: 10/25/2005 01:21:54.
• User
Represents the logon name of the logged on user who originated the
session. A typical User value looks similar to the following example:
joeu.
• Name
user’s details.
10 - 14
• Duration
Represents the length of the session, in the format HH:MM:SS, where
HH represents the hour, in 24-hour format, MM represents the minutes,
from 1 through 60, and SS represents the seconds, from 1 through 60. A
typical Duration value looks similar to the following example: 00 24 43.
• From
• To
Indicates the type of connection requested. A typical To value looks
similar to the following example: MyNetwork.
• Status
Indicates the status of the session. A typical Status value looks similar to
the following example: Logged out from server.
Understanding the Session summary log
The Session Summary log contains a list of the active connections to the
FirePass controller. The Session Summary report contains several types of
data.
• Date
Indicates the date of the session summary. A typical Date value looks
similar to the following example: 10/25/2005.
• Min
Indicates the smallest number of connections (greater than 0) that
occurred on the date indicated. The value in Min is a number.
• Avg
Indicates the average number of connections that occurred on the date
indicated. The value in Avg is a value calculated based on the number of
connections, divided by the number of hours in a day.
• Max
Indicates the largest number of simultaneous connections that occurred
on the date indicated. The value in Max is a number.
The Sessions Summary screen also contains the number of access requests
the FirePass controller processed as well as a visual representation of the
maximum number of simultaneous connections.
10 - 15
Chapter 10
Using the Summary report
The Summary report provides a summary of global or a group-based user
activity, including stats and descriptions of operating system and browser
type usage over specified periods of time. You can also display optional bar
graphs in the report.
To display the Summary report
1. In the navigation pane, click Reports, and click Summary Report.
The Summary report screen opens.
For more information about System Logs report options, see
Working with the Summary report, following.
Working with the Summary report
• From the For the group list, select the group that you want to create a
Summary report for.
opens the report.
• To specify a varying date range for the Summary report:
• Select starting date from the Reporting period from lists.
• Select the ending date from the to (inclusive) lists.
• Click the
icon.
• To include bar graphs in the report, check the Show graphs check box.
• To restrict the report to a predefined date range, click the Last Week,
Last 2 Weeks, Last Month, or Last Year links.
The dates in Reporting period from and to (inclusive) change to reflect
the predefined range.
10 - 16
Understanding entries in the Summary report
The Summary report screen provides a number of aggregated statistics of
various types. You can select varying reporting periods from the predefined
lists.
• Stats
Provides measurements of various activity, such as total sessions,
average FirePass controller session, and average number of sessions per
week.
• Daily Activation
Shows the breakdown of logon activity by day of the week, from Sunday
through Saturday.
• User Activity Totals
Shows the breakdown of user activity, from high activity to inactive,
including the number of users and the percentage of total users they
represent.
• Browser Type
Indicates the type of browser used to log on and the number of users who
used each type.
• OS Type
Indicates the type of operating system used to log on and the number of
users who used each type.
• Session terminations
Indicates the number of sessions that ended for each method of ending.
• Feature Access
Indicates how the users used the sessions with the FirePass controller. A
typical value in the Feature Access table is Administrative Console.
10 - 17
Chapter 10
Using the System Logs report
The System Logs report displays local system logs. If you use an external
syslog server, only errors are logged locally. You can use the Device
Management : Maintenance : Logs screen to specify and configure an
external syslog server.
To display the System Logs report
1. To access the System Logs report, in the navigation pane, click
Reports, and click System Logs.
The System Logs report screen opens.
For more information about System Logs report options, see
Working with the System Logs report, following.
Working with the System Logs report
• From the Period list, select the month to include when creating the
Summary report.
• From the Source list, select the category to include when creating the
Summary report, or select All to include all categories.
opens the report.
10 - 18
Understanding entries in the System Logs report
The System Logs report screen provides a number of aggregated statistics of
various types. You can select varying reporting periods from the predefined
lists.
• Date
Indicates the date on which the FirePass controller logged the entry. A
typical Date value looks similar to the following example: Oct-25.
• Time
Indicates the time, in 24-hour format, at which the FirePass controller
logged the entry. A typical Time value looks similar to the following
example: 1:30:08.
• Source
Indicates the origin of the logged entry. A typical Source value looks
similar to the following example: firepass
• Message
Indicates the type of activity the logged entry represents. A typical
Message value looks similar to the following example:
[-] FirePass service started on firepass.siterequest.com.
10 - 19
Chapter 10
10 - 20
11
• Understanding FirePass controller high availability
• Configuring the active FirePass controller
• Configuring the standby FirePass controller
• Post-configuration tasks
Understanding FirePass controller high availability
A failover configuration is ideal for providing high availability for one site
at a single location. High availability is the process of ensuring access to
resources despite any failures or loss of service in the setup. For hardware,
high availability is ensured by the presence of a redundant system, a
configuration that transfers service to another piece of hardware in the event
of failure on the first piece of hardware.
Two FirePass controllers have the capacity to act as a redundant system, or
failover pair: two identically configured controllers working together to
provide a higher degree of availability than a standalone controller for
remote users.
A redundant system of FirePass controllers is composed of one controller in
an active state, and one in a standby state, at any given moment. The active
controller serves all requests from users. If the active controller fails, the
standby controller takes over the active role. This process of transferring
control from one device to another is called failover.
You can configure a redundant system as a pair of newly acquired
controllers, or you can expand your current setup into a failover
configuration.
Important
If you plan to introduce a failover configuration into your environment, and
your configuration is already in production, you should review Introducing
a failover member into a production environment, on page 11-5 before
continuing.
For organizations with larger sites and multiple locations with FirePass
controllers, a cluster of FirePass controllers can provide additional
scalability of a high-availability configuration. For more information about
clustering, see Understanding FirePass controller clusters, on page 12-1.
Introducing failover configuration
This chapter assumes you already have installed the FirePass controllers and
have completed their initial network configuration by running Quick Setup.
For Quick Setup information, see the FirePass Controller Getting Started
Guide, available as a separate document on the F5 Networks Technical
Support Web site, http://tech.F5.com. For initial network configuration
information, see Configuring web services, on page 8-18 of this guide.
The procedures in this chapter guide you through the process of completing
failover configuration for a pair of FirePass controllers. Once the controllers
are properly configured for failover, you need to make subsequent
configuration changes only on the active controller. The active controller
synchronizes information on the standby controller, except network
configuration and SNMP configuration.
11 - 1
Chapter 11
These are the requirements for configuring failover for a pair of FirePass
controllers:
• You must have two FirePass 1000, 1200, 4000, or 4100 systems
available.
• Each member of the redundant system must be running the same
software version.
• Either both systems have identical features licensed, or one of the two
units is licensed as a failover-only FirePass controller.
Important
If you have a failover-only controller, you must configure it second. For
more information, see Configuring the standby FirePass controller, on
page 11-15.
Reviewing the configuration process
To configure the failover settings on the FirePass controllers, you need to
complete several tasks, in order.
This section presents an overview of the configuration process and links to
procedures containing specific steps.
The process for setting up failover has three main tasks.
• First you configure the active FirePass controller.
• Then you complete similar tasks to configure the standby FirePass
controller.
• Once both controllers are configured, you will want to verify the
configuration.
Important
If you plan to introduce a failover configuration into your environment, and
your configuration is already in production, you should review Introducing
a failover member into a production environment, on page 11-5 before
continuing.
11 - 2
Reviewing the configuration of the active failover member
The first part of the failover configuration process involves setting up the
active member of the redundant system.
◆
Enable failover
Enabling failover is the first task in configuring the active controller.
There are two parts to this task, each of which is covered in Enabling
failover on the active controller, on page 11-7.
• Activating failover.
You must activate the failover option and restart the controller to
enable additional failover screens.
• Configuring a fully qualified domain name (FQDN)
You must make sure that the controllers in a redundant system share a
name.
◆
Configure a device-specific, self IP address
This is part of the initial installation and configuration tasks, but if you
have not already done so, configure at least one device-specific (that is,
not virtual), self IP address for each interface and VLAN interface you
plan to use for failover. For more information, see Configuring the active
controller with a self IP address, on page 11-9.
Note: If you change an IP address on a VLAN interface, verify that the
configuration is using the new IP address on the synchronization agent
and for the heartbeat.
◆
Configure a shared, virtual IP address
Configure the active controller with a shared or virtual IP address. A
shared or virtual IP address is a shared identifier of a computer. The
active controller and the standby controller share this IP address, so that
either controller can assume the shared IP address when it is the active
controller. For more information, see Configuring the active controller
with a shared IP address, on page 11-10.
Then you must finalize the changes and restart the controller before
continuing. For more information, see To finalize the setup, on page
11-8, and To restart the controller or service, on page 11-8.
◆
Configure entries on your Domain Name Service (DNS) server
You complete this part of the process on your network’s DNS server, not
on the FirePass controllers.
On your DNS server, create an entry that maps the FQDN of the pair to
the shared IP address, and create entries for each device using the self IP
address.
The FirePass controller creates host names for each physical device by
appending numbers. You must create a DNS entry for each of these
names using each device’s self IP address. If the FQDN you are using is
Failover, the FirePass controller assigns Failover-1 to the first redundant
system member and Failover-2 to the second one. You will need DNS
entries for each.
11 - 3
Chapter 11
◆
Add and configure web services, and specify a synchronization
service
When you have configured a self IP and a shared IP address on the active
controller, you can configure web services associated with each IP
address. You also need to make some configuration changes and specify
a synchronization agent for web services on the self IP address. For more
information, see Configuring web services for the IP addresses of the
active controller, on page 11-10, and Configuring a web service as a
synchronization agent for the active controller’s self IP address, on page
11-12.
◆
Configure the heartbeat
The heartbeat is a activity indicator signal that the active controller
broadcasts to the subnet, where the standby controller receives it. For
information about configuring the heartbeat, see Configuring the active
controller’s heartbeat, synchronization, and miscellaneous settings, on
page 11-13.
◆
Finalize and restart the active controller
After configuring web services, you must finalize and restart the
controller.
Restarting the controller puts the failover configuration changes into
effect and reveals additional failover screens and settings. For more
information, see To finalize the setup, on page 11-8, and To restart the
controller or service, on page 11-8.
Reviewing the configuration of the standby failover member
The second part of the failover configuration process involves setting up the
standby member of the redundant system.
11 - 4
◆
Enable failover
Follow the procedure steps shown in Enabling failover on the standby
This is how you configure the controller that has the failover-only
license.
◆
Configure the self IP address
Follow the procedure steps shown in Configuring the standby controller
with a self IP address, on page 11-16.
◆
Configure a shared IP address
Follow the procedure steps shown in Configuring the active controller
◆
Check the FQDN
For more information, see Enabling failover on the active controller, on
page 11-7.
◆
Configure DNS server entries
For more information, see Configure entries on your Domain Name
Service (DNS) server, on page 11-3.
◆
service
Follow the procedure steps shown in Configuring web services for the IP
addresses of the active controller, on page 11-10, and Configuring a web
service as a synchronization agent for the active controller’s self IP
◆
Follow the procedure steps shown in Configuring the active controller’s
heartbeat, synchronization, and miscellaneous settings, on page 11-13.
◆
For more information, see To finalize the setup, on page 11-8, and To
restart the controller or service, on page 11-8.
Reviewing the verification process
When you have configured both the active and standby controllers, verify
that the configuration is working correctly. For more information, see
Verifying the failover configuration, on page 11-19.
WARNING
If you are configuring failover in a production environment, the order in
which the pair of controllers restart is very important, and can result in data
loss if the two controllers do not restart in the correct order. For more
information, see Introducing a failover member into a production
environment, following.
Introducing a failover member into a production environment
If you are creating a redundant system by configuring one new controller
and one existing controller, make sure to carefully watch when the units
restart so that you never let the new, potentially partially configured
controller take over accidentally. Restarting the active controller causes the
standby to take over, which erases all configuration on the previously active
controller.
Note
Always back up any production controller before configuring failover. You
can read more about backing up the FirePass controller in Backing up and
restoring the FirePass controller, on page 8-45.
Once you enable failover and configure the IP addresses for the active and
standby controllers, the process of restarting one controller fails-over
automatically to the other one. Failover configuration requires a system
restart.
11 - 5
Chapter 11
A good strategy to follow when deploying a FirePass high availability
configuration has three parts:
• Configure one FirePass controller for failover, typically, the existing one
you have in production, and then shut it down.
• Configure the second FirePass controller, and then shut it down.
• Restart the controller that you want to serve as the active failover
member, and then start the standby controller.
You can use the backup and restore feature to set up redundant system.
Backup and restore transfers settings to a one or more FirePass controllers.
Even though you transfer settings, you must still complete other
configuration tasks. For more information, see Reviewing the configuration
process, on page 11-2.
Important
When you restore the backup, do not restore the network settings to the
standby controller.
Note
For more information on using the backup and restore feature, see Backing
up and restoring the FirePass controller, on page 8-45. For more
information about using the backup and restore feature to transfer identical
settings to a number of FirePass controllers, see the Configuring the
BIG-IP System with FirePass Controllers for Load Balancing and SSL
Offload document on the Solution Center at the F5 corporate web site,
11 - 6
Configuring the active FirePass controller
When setting up a failover configuration, your first set of tasks are
performed on the active controller.
Before configuring failover settings on the active controller, make sure both
the active and standby controllers are configured with the same FQDN.
After confirming this, enable failover on the active controller, create a
virtual IP address, and configure web services for that IP address.
You must configure the following IP addresses for each failover controller:
◆
A dedicated self IP address and port on each controller. The IP address
and port setting required is the self IP address and port of the interface or
VLAN interface on the controller. This address must be unique for each
controller in the redundant system. The self IP addresses for the two
failover controllers must be on the same IP subnet. Typically, you
configure synchronization for the same port, but using a different IP
address.
◆
At least one shared IP address for the redundant system. This shared IP
address is what establishes the association between the members of a
redundant system.
Important
If you are configuring failover in a production environment, or on an
existing FirePass controller, make a full backup of the controller before
making any configuration changes. For information about backing up a
FirePass controller, see Backing up and restoring the FirePass controller,
on page 8-45.
Enabling failover on the active controller
You need to enable failover on the active FirePass controller before
continuing with the configuration tasks. When you enable failover the
system prompts you to restart the controller. After you restart the controller,
the navigation pane and the Web Services configuration screen present
additional failover configuration screens and options.
Note
If the screen does not show the Failover tab or other failover-related menu
items after you enable failover, refresh the view in your web browser.
To enable failover on the active FirePass controller
2. Click the Hosts tab at the top of the screen.
The Hosts screen opens.
11 - 7
Chapter 11
3. Confirm that the name of the controller in the FQDN of the
controller box is the name you want to use for the redundant
system. These names must match on both the active and standby
controllers.
4. In the navigation pane, click Clustering and Failover.
The Clustering and Failover screen opens.
5. Scroll down to the Failover (High-Availability) Configuration area,
and make these changes:
a) Check the Enable Failover Configuration check box.
b) From the Failover Pair Member list, select First.
c) Copy the value from the Failover ID box.
Paste this value into a text file or write it down. You will need
this value for configuring the standby FirePass controller.
6. In the Clustering/Failover Global ID area, copy the value from
Cluster/Failover Global ID box.
Paste this value into a text file or write it down. You will need this
value to configure the standby FirePass controller.
7. To commit the settings, click Apply Clustering/Failover Settings.
8. Finalize the setup, and restart the controller.
For more information, see Finalizing the configuration, following,
and Restarting the controller or services after configuration,
following.
Finalizing the configuration
Many web services configuration changes require a finalize step. You can
use steps in this procedure for all finalize operations described in these
procedures.
To finalize the setup
1. Click the Finalize tab at the top of the screen.
2. Review the changes.
3. Click the Finalize Changes button.
Restarting the controller or services after configuration
Some configuration changes also require a controller restart or services
restart. You can use steps in this procedure for all restart operations
described in these procedures.
To restart the controller or service
1. Click the indicated text.
2. Confirm the restart.
11 - 8
Configuring the active controller with a self IP address
For the failover process to work, each active and standby FirePass controller
must have an IP address that it uses to communicate with the other. This IP
address, the self IP address, uniquely identifies each FirePass controller
interface or VLAN interface for the purpose of synchronization.
You created a self IP address during the initial configuration process. If you
want to use that self IP address for failover, you can skip this procedure. If
you want to use an interface other than the recommended one, you can
create a new self IP address on another interface. If you do so, you must also
connect the two FirePass controller interfaces using a separate straight or
crossover cable.
WARNING
Be extremely careful when changing the FirePass controller’s IP
configuration settings. If you enter incorrect settings, the FirePass
controller might become inaccessible from the network. If that happens, you
must have physical access to the FirePass controller device to start up the
controller again. You cannot use the browser interface to start up the
FirePass controller, you must use the Maintenance Console connected to
the device.
To configure the active controller’s self IP address
Configuration, click Network Configuration, and click the IP
Config tab.
2. Under Add New IP in the IP Address /Netmask box, type the IP
address in dotted-decimal notation, and the subnet mask in bits
notation.
In the online help for this screen, you can find a table that shows the
mapping between bits, dotted-decimal, and hexadecimal netmask.
3. In Broadcast IP, type the IP for the controller to use to send
messages to the subnet. If you do not specify a broadcast IP address,
the FirePass controller calculates a default broadcast address from
the IP address and mask.
4. From the Interface list, select the device-specific interface or
VLAN interface associated with the IP address.
You can configure web services so that all the traffic goes through a
single interface, or you can use one interface for synchronization
and another for other traffic.
For FirePass 1000 controllers, we recommend that the public subnet
be associated with the eth0 interface, and the private subnet be
associated with the eth1 interface. For FirePass 4100 controllers we
recommend that you associate the public subnet with the eth1.1
interface.
5. Click Add New to add the self IP address.
11 - 9
Chapter 11
The Finalize Settings screen opens.
7. Review the changes, and click the Finalize Changes button.
Configuring the active controller with a shared IP address
The redundant system of failover controllers shares a virtual IP address.
Sharing this IP address makes it possible for the standby controller to take
over the network traffic in the event of a failure.
To configure a shared, virtual IP address on the active
FirePass controller
2. In the Add New IP area, in the IP Address/Netmask box, type a
new IP address and subnet mask for the shared IP address.
3. Check the Virtual check box.
The Virtual check box is present only after you have enabled the
unit for failover.
4. Leave the Broadcast IP box empty for the shared IP address.
5. Select the appropriate network interface from the Interface list.
6. Click Add New to add the shared IP address.
7. Finalize the changes, and restart if necessary.
For specific steps, see Finalizing the configuration, on page 11-8,
and Restarting the controller or services after configuration, on
page 11-8.
Configuring web services for the IP addresses of the active
controller
After adding a self IP address and a shared IP address to the active
controller, you need to configure their web services. Which services you
configure, and the ports you use, depend on how your local network and
firewall are set up, and on what FirePass controller features you use.
Configuring secure web services on port 443 for the active controller
The secure web services on port 443 is the one users log on to. In a typical
configuration, you configure web services on port 443 using SSL. Because
this unit represents one member of a redundant system, you configure web
services on the shared IP address.
11 - 10
To configure web services on port 443 of the shared IP
address for the active controller
2. Click the Web Services tab at the top of the screen.
3. In the Add new service area, from the IP list, select the shared IP
address.
4. In the Port box, type 443.
5. In the Name box, type the FQDN of the FirePass controller.
6. From the For Mode list, select ActiveOnly.
This setting causes the controller to load web services only when it
is the active controller in a redundant system.
7. Check the SSL check box.
8. To add the new service, click Add New.
The Web Service Configuration for <hostname> screen opens for
the new service.
9. From the Certificate list, select the certificate.
10. Check the User Logon check box.
11. If you want, check the Admin Logon check box.
If you check this option, you can log on to the controller’s
Administrative Console. Otherwise, you are redirected to the active
failover member.
12. Leave all other options unchecked.
13. To commit the settings, click Update.
page 11-8.
Configuring web services on port 80 for the active controller
Port 80 is not required, though you may need to configure it based on your
network configuration. Because the web service you configure on port 80 is
not secure, you should not allow communication of sensitive information on
this shared IP address.
To configure web services on port 80 of the shared IP
address for the active controller
11 - 11
Chapter 11
3. In the Add new service area, from the IP list, select the shared IP
address.
You can configure web services for any port, not just port 80.
6. From the For Mode list, select ActiveOnly.
This setting causes the controller to load web services only when it
is the active controller in a redundant system.
the new service.
8. In the HTTPS URL to redirect to box, type the URL of the
HTTPS Web service (port 443) on the shared IP address that you
configured in Configuring secure web services on port 443 for the
active controller, in the preceding procedure.
9. Check the User Logon check box.
page 11-8.
Configuring a web service as a synchronization agent for the active
controller’s self IP address
After configuring web services for the active controller’s virtual IP address
you need to also configure a synchronization service for the controller’s
physical IP address.
Note
You can configure synchronization for any port, not just port 81.
To create a web service as a synchronization agent on port
81 of the self IP address for the active controller
11 - 12
3. From the IP list, in the Add new service area, select a self IP address
of the active controller.
You can configure synchronization for any port, not just port 81.
You can leave Name blank if the self IP address does not have a
domain name specified in DNS, or if you want to use the self IP
address as the name.
6. From the For Mode list, select Always.
This setting causes the controller to keep a web service active on the
self IP and port specified. You must select Always for the
synchronization service.
the new service.
8. Check the Do not redirect to HTTPS check box.
9. Check the Synchronization Agent check box.
For Synchronization Agent to be active, you must check Enable
Failover Configuration on the Device Management : Configuration :
Clustering and Failover screen.
page 11-8.
Configuring the active controller’s heartbeat, synchronization, and
miscellaneous settings
The active and standby controllers communicate with each other using a
heartbeat. The heartbeat is a signal sent at 100-millisecond intervals that
notifies the standby node that the active node is running. If the standby node
does not receive a heartbeat within 200 milliseconds of the expected arrival
time, the standby node considers its peer inactive, assumes its virtual IP
address, and becomes the active member of the redundant system.
Heartbeat settings specify the interface and port a controller uses while it is
the active member of the redundant system.
Synchronization settings consist of the self IP address of the active
controller and the self IP address of the standby controller. To use a port, it
must be configured as a synchronization service. A synchronization service
is a web service that is enabled for HTTP and configured as a
synchronization agent.
11 - 13
Chapter 11
For a procedure to follow, see Configuring a web service as a
synchronization agent for the active controller’s self IP address, on page
11-12.
To configure the active controller’s heartbeat,
synchronization settings, and miscellaneous settings
2. Click the Failover tab at the top of the screen.
The Failover Configuration screen opens.
3. From Network Interface to use for the heartbeat, select the
interface you want to use for transmitting the heartbeat.
4. In UDP port to use for heartbeat, specify the port number you
want to use for transmitting the heartbeat. The default is 694.
If you want to use a different port for UDP, specify that value
instead. You must specify the same value on the standby controller.
5. In IP address and port on this machine to use for
synchronization, select the self IP address and port you configured
for the active controller in Configuring the active controller with a
self IP address, on page 11-9.
6. In IP address and port on the other member of this failover pair
to use for synchronization, specify the self IP address and port of
the other member of the redundant system. You configure this
setting in Configuring the active FirePass controller, on page 11-7.
The standby controller uses this IP address and port for
synchronization with the active controller.
7. Click the Misc tab at the top of the screen.
The Misc screen opens.
8. From the Local X11 server source address list, select the shared IP
address.
9. From the NetBIOS broadcast source address list, select the shared
IP address.
10. From the Network Access source address list, select the shared IP
address.
11. From the NAS IP Address for RADIUS Requests list, select the
shared IP address.
page 11-8.
11 - 14
Configuring the standby FirePass controller
After you have configured the active FirePass controller, you must
configure the standby controller so that it can take over in the event of a
failure of the active controller.
The basic process consists of the following tasks
◆
Enable failover
Follow the procedure steps shown in Enabling failover on the standby
This is how you configure the controller that has the failover-only
license.
◆
Configure the self IP address
Follow the procedure steps shown in Configuring the standby controller
with a self IP address, on page 11-16.
◆
Configure a shared IP address
Follow the procedure steps shown in Configuring the active controller
◆
Check the FQDN
page 11-7.
◆
Configure DNS server entries
For more information, see Configure entries on your Domain Name
Service (DNS) server, on page 11-3.
◆
service
◆
◆
For more information, see To finalize the setup, on page 11-8, and To
restart the controller or service, on page 11-8.
The configuration process is similar to the one you followed when you
configured the active controller, with two exceptions.
◆
Configure standby settings on the Clustering and Failover Settings
screen.
For more information, see To configure standby settings on the
Clustering and Failover Settings screen, following.
◆
Specify the self IP address for the standby controller.
For more information, see To specify the self IP address for the standby
11 - 15
Chapter 11
Enabling failover on the standby controller
Enabling failover on the standby controller is almost the same as enabling
failover on the active controller, so you may find it useful to review the
procedure for configuring the active controller, Enabling failover on the
active controller, following.
To configure standby settings on the Clustering and
Failover Settings screen
Configuration, and click Clustering and Failover.
2. From the Failover Pair Member list, select Second.
You select Second when you are configuring a failover member that
is licensed as failover only, and when you are configuring the
second fully licensed member of a redundant system.
3. In the Failover ID box, type or paste the failover ID you recorded in
step 5 of To enable failover on the active FirePass controller, on
page 11-7.
4. In the Clustering/Failover Global ID area in the Cluster/Failover
Global ID box, type or paste the Cluster/Failover Global ID you
recorded in step 6 of To enable failover on the active FirePass
Configuring the standby controller with a self IP address
Before continuing with this task, make sure to review the associated
procedure for configuring the active controller, Configuring the active
controller with a self IP address, on page 11-9.
To specify the self IP address for the standby controller
Configuration, and click Network Configuration, and click the
Failover tab.
The Failover Settings screen opens.
2. In the IP address and port on this machine to use for
synchronization box on the Failover Settings screen, select the self
IP address and port you configured for the standby controller in
Configuring the active controller with a self IP address, on page
11-9.
3. In IP address and port on the other member of this failover pair
to use for synchronization, specify the self IP address and port of
the other member of the redundant system. You configure this
setting in Configuring the active FirePass controller, on page 11-7.
The standby controller uses this IP address and port for
synchronization with the active controller.
11 - 16
Configuring a shared IP address
Follow the procedure steps shown in Configuring the active controller with
a shared IP address, on page 11-10.
Checking the FQDN
page 11-7.
Configuring DNS server entries
For more information, see Configure entries on your Domain Name Service
(DNS) server, on page 11-3.
Adding and configuring web services, and specify a synchronization
service
Configuring the heartbeat
Finalizing and restarting the active controller
For more information, see To finalize the setup, on page 11-8, and To restart
the controller or service, on page 11-8.
11 - 17
Chapter 11
Accessing a standby controller
If you want to log on to a standby controller that is already a member of a
redundant system, you must log on using https://standby-self-IP/admin/.
Logging on to the standby unit
The presence of the trailing /admin/ designation in the URL enables access
to the standby controller directly. If you do not specify the trailing /admin/,
you are redirected to the active failover member.
For example, to access a physical device named fail2 that has an IP address
of 10.4.1.2.198, you could specify one of the following in the browser
address bar, and then log on as usual.
https://fail2.siterequest.com/admin/
https://10.4.12.198/admin/
These examples assume that you created a DNS entry for the standby
controller using its self IP address.
Making changes on the standby unit
Although you can access the FirePass controller configured as the standby
unit, you should not make any configuration changes. The failover process
synchronizes configuration information from the active controller to the
standby controller in a redundant system.
On the standby member of a redundant system, you cannot use the link
Please click here to start a console session to the Maintenance Account
on the Device Management : Maintenance : Troubleshooting Tools screen.
This is to help prevent changes to the standby controller of a redundant
system.
11 - 18
Post-configuration tasks
After you have configured both FirePass controllers for failover, confirm
that the failover configuration is working.
Starting failover controllers
If both failover controllers are turned off, the first controller that you start
automatically assumes the role of active controller, and the second
controller you start becomes the standby controller. The two controllers
remain in this state until either the active controller fails and the standby
controller takes over, or you restart the active controller, and the standby
controller becomes the active controller.
If a pair of failover controllers is started simultaneously, the controller
configured as First on the Failover settings screen becomes the active
controller, and the controller configured as Second on the Failover settings
screen becomes the standby controller. You can determine which controller
is first and which is second by checking the value in the Failover Pair
Member box on the Clustering and Failover screen. To access the screen,
click Device Management, expand Configuration, and click Clustering
and Failover. The first one is designated First, and the second one is
designated Second.
Verifying the failover configuration
After configuring the active and standby FirePass controllers, verify that the
configuration is properly working.
To verify that your failover configuration is working
1. In the navigation pane, click Failover.
The Failover : Settings screen opens.
2. Verify that the failover controllers are properly configured:
a) Confirm that the current controller is active by looking at the
value of This node.
If the controller is active, it contains the designation (active).
b) Confirm that the two controllers are communicating by looking
at the status line that indicates how many seconds have passed
since the active controller synchronized data with the standby
controller.
If the interval has been too long, the screen displays a warning.
Synchronization might take more time if a lot of data has to be
transferred, for example, if you make significant changes on the
primary controller.
11 - 19
Chapter 11
3. Restart the current, active controller so that the standby controller
fails over.
a) Click Restart This Node, Make <standby controller> Active
to restart the current controller.
The current controller restarts and becomes the standby
controller, and the standby controller takes over as the active
controller.
b) After restart, check the identity of each controller. For more
information, see Verifying controller identity, following.
Verifying controller identity
You can determine the identity of the controllers by logging on to each one.
To verify the identity of the controller
1. Log on to the active controller directly.
2. Verify that the Welcome screen indicates that the device is the
standby controller.
The screen presents the following message:
This node is in failover active mode
3. Log on to the standby controller directly.
For more information, see Configuring the standby FirePass
4. Verify that the Welcome screen indicates that the device is the
standby controller.
The screen presents the following message:
This node is in failover standby mode
Triggering manual failover
You can manually trigger a failover to verify that the configuration of the
redundant system is correct. You might also need to manually trigger a
failover if you need to make changes to your active controller.
To manually trigger a failover to a standby controller
1. In the navigation pane, click Failover, and then click Settings.
The Failover Settings screen opens.
2. Click Restart This Node, Make <standby controller> Active.
The current controller restarts and becomes the standby controller,
while the standby controller takes over as the active controller.
You can also trigger failover manually using the Restart Controller link on
the Restart Services screen. To access the screen, in the navigation pane,
click Device Management, expand Maintenance, and then click Restart
Services.
11 - 20
12
• Understanding FirePass controller clusters
• Configuring FirePass controller clusters
• Enabling clustering
• Configuring clustering synchronization
• Configuring load balancing
• Verifying the load balancing configuration
• Managing a cluster configuration
Understanding FirePass controller clusters
You can set up FirePass 4000 or 4100 controllers in a cluster configuration
to support large numbers of concurrent connections without performance
degradation. A cluster is a group of FirePass controller nodes that provide
common user services, and can distribute the load of active sessions across
all controllers in the cluster. The process the primary node uses to distribute
user sessions among all the nodes in the cluster is called Load balancing.
A cluster node represents one station in a cluster, and can consist of a single
FirePass controller, or a failover pair of controllers. A cluster consists of one
primary (or master) node and up to a maximum of nine secondary (or slave)
nodes. The primary node first handles incoming connections, and then
redirects each session to an available secondary node, or services the
connection itself. The primary node maintains configurations for all user
groups and user resources the cluster supports. Each secondary node
services user sessions as requested by the primary node, and independently
maintains its own network configuration.
Clustering is ideal for large enterprises and service providers, and allows for
easy scalability, with increased performance and fault tolerance across all
cluster nodes. For large deployments, a FirePass 4100 cluster can contain up
to ten nodes, supporting up to 20,000 concurrent connections, though there
is no limit on the number of user accounts.
As an alternative, you can specify that the user select the cluster node if you
do not want the primary node to balance the load, or you can use an external
load-balancing method. For information about using the BIG-IP Local
Traffic Manager as the load-balancing mechanism, see the associated
deployment guide on the F5 Networks web site Solution Center at
Understanding synchronization in clusters
The primary node plays the central role in a cluster for all the user-related
configuration (user groups and user resource settings). You create and
configure user groups and resource group favorites on the primary node.
When load balancing is enabled, the primary node distributes user sessions
to each secondary node, and each secondary node handles user sessions
delegated to it by the primary node of the cluster. The secondary nodes get
this information from the primary node during the synchronization process.
Synchronization is the process used by the primary node to synchronize
data with the secondary nodes of the cluster.
Load balancing operations require synchronized data on the cluster
members. The synchronization process makes it possible for any primary or
secondary controller to service a user’s logon request and subsequent
session. To synchronize resource information across all cluster nodes, the
primary node distributes configuration updates to each secondary node. Data
synchronized from the primary node to each secondary node includes: user
and group data (including authentication parameters), and favorites.
12 - 1
Chapter 12
Once a user is logged on, the secondary node reports its updates to the
primary node as an input to the primary node’s load-balancing decision.
Because users can perform operations that change user-specific data, the
FirePass controller synchronizes some data from the secondary nodes back
to the primary node. These updates include password changes, additions and
changes to personal favorites, and modifications to other account settings.
For more information about synchronizing web services, see Configuring
clustering synchronization, on page 12-7.
Installing FirePass controllers as a cluster
To complete procedures in this chapter, you must already have installed the
FirePass controllers and have completed the initial network and web service
configuration. For setup information, see the FirePass Controller Getting
Started Guide, available as a separate document on the Ask F5 web site at
http://tech.f5.com. For initial network configuration information, see
Configuring web services, on page 8-18.
Important
Always back up any FirePass controller before configuring clustering. For
more information on backup operations, see Backing up and restoring the
FirePass controller, on page 8-45.
Configuring FirePass controller clusters
Once you have set up each member of your cluster, you can configure the
clustering settings for each controller. The procedures in this section guide
you through the process of setting up FirePass controller cluster members.
Here are the requirements for configuring cluster members:
• You must have multiple FirePass 4000 or 4100 systems available.
• Each system must be running the same software version and must have
the same hot-fixes, if any, installed.
• Every cluster member must have its own individual license that supports
identical features and the same number of concurrent users, except for
any failover-only members, which should have the failover-only license
activated.
• Each node in the cluster must have a valid certificate and be publicly
accessible from outside the LAN using its own unique IP address or
fully-qualified domain name (FQDN).
12 - 2
To ensure the highest level of availability, you should use multiple pairs of
FirePass controllers as cluster nodes. If this is not possible, F5 Networks
recommends at a minimum, that you make the primary node a failover pair.
Note
Any cluster node can represent a redundant system of pairs of FirePass
controllers. If you plan to use redundant systems as nodes in the cluster,
configure them before configuring clusters. For more information about
configuring failover pairs, see Chapter 11, Using FirePass Controllers for
Failover.
Making configuration changes in clusters
You can change some configuration settings only on the primary node:
• User account information and master group settings
• Favorites for Network Access, Portal Access, and Application Access
• Customization options
When you connect to a secondary node, you are limited to changing network
settings and clustering configuration options that the primary node does not
control. For example, because you cannot change user and group account
information on secondary nodes, the secondary node presents no user or
group options. These options are not available on any secondary node to
prevent conflicts during synchronization.
Understanding the configuration process
To configure FirePass controllers as a cluster, you need to complete several
tasks in a specific order.
◆
Enable clustering
The first task in configuring a cluster of controllers is to enable clustering
on each node. When you configure the primary node, record the specified
Cluster ID and the Cluster/Failover Global ID for use in configuring the
secondary nodes. For more information, see Enabling clustering, on page
12-5.
◆
Specify log consolidation settings
The next task is to determine whether you want to consolidate logs for
nodes in the cluster. For more information, see Consolidating logs, on
page 12-4.
◆
Set up synchronization
The third task is to configure synchronization, which consists of two
parts:
• Create a synchronization service
In order for clustered controllers to remain synchronized, you must
configure at least one synchronization service on each controller in
12 - 3
Chapter 12
the cluster. This should be a different web service from the one you
create for user access. For more information about configuring
synchronization services, see Configuring a synchronization service,
on page 12-7.
• Configure synchronization
When you configure synchronization, you associate an IP address and
port on the primary node with an IP address and port on each of the
secondary nodes. For more information on configuring
synchronization, see Configuring synchronization, on page 12-8.
◆
Verify that the cluster configuration is working
After you have configured the cluster nodes, but before allowing remote
clients to access the cluster, verify that all controllers are working
properly. For more information, see Verifying the cluster configuration,
on page 12-13.
◆
Enable Load balancing
If you want to use the cluster for load balancing, you must define at least
one user service on the primary node and at least one on each secondary
node. The user service must be configured to allow HTTP and HTTPS
access so that users can access the service from outside the network. For
more information, see Configuring load balancing, on page 12-11.
Note
As an alternative, you can use a BIG-IP Local Traffic Manager for load
balancing a cluster. For more information, see the associated deployment
guide on the F5 Solution Center at http://www.f5.com/solutions/.
Consolidating logs
You can use log consolidation settings to view information about all cluster
members in a single location on the primary node. Consolidating logs
simplifies the monitoring process for cluster node members. In order to have
the primary node receive log information from the secondary nodes, you
must enable log-consolidation settings on the Device Management :
Configuration : Clustering and Failover screen. For procedures containing
these steps, see Enabling clustering, following.
You can view consolidated logs on the primary node in Reports. Logs that
contain consolidated data include a Cluster Node column in the report. The
report contains data for each cluster node, including the primary node.
You can get node-specific statistics on the Device Management :
Monitoring : System Load screen by selecting an IP address from the
Cluster Node list.
12 - 4
Enabling clustering
Enabling clustering involves specifying the number of nodes in the cluster,
designating one as the primary node, and standardizing the Cluster ID and
Clustering/Failover Global ID on each of the nodes to be used in the cluster.
After you have enabled clustering and restarted the controller, you can make
additional configuration changes on newly available clustering screens.
Tip
If you are enabling clustering on a pair of controllers in a failover
configuration, set up clustering on the active controller.
Configuring the primary node
For the primary node, complete the following procedure.
To enable clustering on the primary node
2. In the Clustering (Load-Balancing) Configuration area, check the
Enable Clustering Configuration check box.
3. In the Total Number of Cluster Nodes box, specify the number of
nodes the cluster contains.
A node can consist of a single FirePass controller or a redundant
system of a pair of controllers.
4. From the Cluster Node Master/Slave list, select Master.
5. To enable the consolidation of logs from the secondary nodes, check
Enable Log Consolidation.
To complete log consolidation, you must also check Synchronize
Log to Master on each secondary node. For more information, see
Consolidating logs, on page 12-4.
6. Copy the value from the Cluster ID box.
value to configure the secondary nodes.
7. In the Clustering/Failover Global ID area, copy the value from the
Cluster/Failover Global ID box.
value when you configure the secondary nodes.
8. To commit the settings, click the Apply Clustering/Failover
Settings button.
9. When prompted to restart the controller, click the indicated text,
here.
10. Continue with configuring the secondary nodes, following.
12 - 5
Chapter 12
Configuring the secondary nodes
For each secondary node, complete the following procedure.
To enable clustering on a secondary node
2. In the Clustering (Load-Balancing) Configuration area, check the
Enable Clustering Configuration check box.
3. In the Total Number of Cluster Nodes box, specify the number of
nodes the cluster contains.
4. From the Cluster Node Master/Slave list, select Slave.
5. To pass log information back to the primary node, check
Synchronize Log to master.
To complete log consolidation, you must also check Enable Log
Consolidation on the primary node. For more information, see
Consolidating logs, on page 12-4.
6. Into the Cluster ID box, paste the value you copied from this field
on the primary node in step 6 in To enable clustering on the primary
node, preceding.
7. Into the Cluster/Failover Global ID box in the Clustering/Failover
Global ID area, paste the value you copied in step 7 in To enable
clustering on the primary node, preceding.
Settings button.
here.
Important
Whenever you turn on a cluster member, always start the primary node
first. If the primary node is not available when the remaining cluster
members start up, the cluster cannot function properly. For this reason, we
recommend that the primary node be a redundant system.
12 - 6
Configuring clustering synchronization
After you have enabled clustering on each node, you can configure
synchronization. All traffic goes to the primary node first. The primary node
manages cluster synchronization and, if load balancing is enabled,
distributes user-session processing among the secondary nodes. For more
information about load balancing, see Configuring load balancing, on page
12-11.
Configuring a synchronization service
To configure the primary and secondary nodes of a cluster for
synchronization, you must designate a synchronization service and
configure synchronization on each node.
The following requirements affect how you configure the synchronization
service.
• The service must allow HTTP connections. For this reason, you should
not configure it on a port that is also configured for user services.
• The service cannot be redirected to another service (for example,
HTTPS).
• If the service is on a redundant system (failover pair), you should
configure it on the pair’s shared, virtual IP address.
• You can use the same synchronization port as the one configured for
failover synchronization.
Configuring the synchronization service
Complete the following procedure on the primary node first, then complete
the procedure on each secondary node.
To configure a synchronization service
Configuration, and click Network Configuration, and click the
Web Services tab at the top of the screen.
2. In the Add new service area, from the IP list, select an IP address:
• If the port is also configured for failover synchronization, select a
shared, virtual IP address for the failover web service.
• Otherwise, select a self IP address.
Make a note of the IP address for the primary node and for each
secondary node. You will need them for configuring
synchronization parameters.
3. In the Port box, type an unused port number.
For example, type 82 in the Port box.
12 - 7
Chapter 12
4. In the Name field, type the FQDN of the FirePass controller.
5. If the service is to be used for controllers in a redundant system,
from the For Mode list, select ActiveOnly for the failover web
service running on the shared, virtual IP address, or Always for the
failover web service running on the dedicated, self IP address.
Selecting the ActiveOnly setting causes the controller to load web
services only when it is the active member in the redundant system.
For more information about configuring redundant systems see
Reviewing the configuration process, on page 11-2.
6. To add the service, click Add New.
The Web Service Configuration for <Hostname or IP Address>
screen opens.
7. On the Web Service Configuration for <Hostname or IP Address>
screen:
a) Check the Do not redirect to HTTPS check box.
b) Check the Synchronization Agent check box.
c) Leave all other options unchecked.
8. To update the web service configuration, click Update.
Important
Although the settings do not take effect until you complete the finalize
operation and restart the controller, the FirePass controller cannot compete
the finalize operation until all clustering settings are fully configured.
Tip
You can use a single web service for both cluster synchronization and
failover synchronization. For more information about configuring a web
service for failover, see Configuring a web service as a synchronization
agent for the active controller’s self IP address, on page 11-12.
Configuring synchronization
After you configure a synchronization service, you must associate the
primary service with the corresponding service on each secondary node.
12 - 8
Configuring synchronization on the primary node
Now, you complete the procedure on the primary node.
To configure synchronization parameters on the primary
node
1. In the navigation pane, click Clustering.
The Clustering Settings screen opens.
2. Click the Please click here to set up the cluster network
configuration link.
The Device Management : Configuration : Network Configuration
screen opens with the Clustering tab selected.
3. In the Internal Synchronization area, from the Service On Master
list, select the IP address and port number of the synchronization
service you configured.
4. In Service on Slave N, type the IP address and port of the
corresponding synchronization service settings for each secondary
node.
5. To update the synchronization settings, click Update Table.
7. Click Finalize Changes to finalize the configuration.
8. When prompted, restart the controller.
Configuring synchronization on the secondary nodes
Now, you complete the procedure on each secondary node. The process is
almost the same as configuring the primary node, except for the differences
in the Internal Synchronization parameters.
To configure synchronization parameters on a secondary
node
1. In the navigation pane, click Clustering.
configuration link.
screen opens with the Clustering tab selected.
3. In the Internal Synchronization area, from the Service On Slave list,
select the IP address and port number of the synchronization service
you configured.
4. In Service on Master, type the corresponding IP address and port of
the synchronization service on the primary node.
5. To update the synchronization settings, click Update Table.
12 - 9
Chapter 12
Configuring a synchronization interval
If you have a large number of FirePass controllers with clustering enabled,
you can greatly reduce the clustering traffic by modifying the cluster
synchronization interval. Before synchronization can work, you must enable
clustering and configure synchronization settings.
For more information, see Enabling clustering, on page 12-5 and
Configuring clustering synchronization, on page 12-7.
To specify a synchronization interval
2. In Synchronization Interval, specify the length of time you want to
leave between the start of synchronization operations.
The default interval is ten seconds, which should work for most
configurations. If there is a large amount of data to synchronize, the
process might not complete in ten seconds, so you should specify a
longer interval. You can watch the Stats screen to determine how
long synchronization takes. Then you can set an interval sufficiently
large to make sure that the operation completes. We recommend
300 seconds as a reasonable interval for most configurations.
Settings button.
here.
5. Repeat this process for each secondary node.
12 - 10
Configuring load balancing
For clustering to work, you must also configure the load balancing feature of
FirePass controller clusters. Balancing the load guarantees that no single
controller becomes overloaded while another controller goes under used. By
default, load balancing is turned off. With load balancing enabled, the
primary node assigns sessions randomly among the secondary controllers.
Note
As an alternative, you can use a BIG-IP Local Traffic Manager for load
balancing a cluster. For more information, see the associated deployment
guide on the F5 Solution Center at http://www.f5.com/solutions/.
Configuring load balancing on the primary node
After you enable load balancing on the primary node, you must associate its
HTTP and HTTPS-enabled, User web service with the corresponding
service on each secondary node.
To configure load balancing on the primary node
1. In the navigation pane, click Clustering, and click Settings.
configuration link.
screen opens with the Clustering tab active.
The Load Balancing table contains a row for each HTTP-enabled
and HTTPS-enabled, User web service on the primary node, and
each row contains columns representing each secondary node.
• Service On Master
Represents the primary node.
• Service On SlaveN
Represents each secondary node in the cluster.
3. For each column, type the IP address and port of the HTTP-enabled
and HTTPS-enabled, User-access configured web service on the
corresponding secondary node.
4. To commit the settings, click Update Table.
12 - 11
Chapter 12
Configuring load balancing on the secondary node
After you enable load balancing on each secondary node, you must associate
its HTTP and HTTPS-enabled, User web service with the corresponding
service on the primary node.
To configure load balancing on the secondary nodes
1. In the navigation pane, click Clustering, and click Settings.
configuration link.
screen opens with the Clustering tab active.
The Load Balancing table contains a row for each HTTP-enabled
and HTTPS-enabled, User web service on the primary node, and
each row contains columns representing each secondary node.
• Service On Slave
Represents the secondary node you are logged on to.
• Service On Master
Represents the primary node.
In this column, type the IP address and port number representing
the primary node’s web service you want to associate with the
secondary node.
3. To commit the settings, click Update Table.
Activating load balancing
Before you can activate load balancing, you must first enable clustering and
configure synchronization. For more information, see Enabling clustering,
on page 12-5 and Configuring clustering synchronization, on page 12-7.
To activate load balancing
1. In the navigation pane, click Clustering, and then click Settings.
The Clustering : Settings screen opens.
2. From the Load Balancing list, select Random.
Random represents an unstructured and irregular assignment of
user sessions among the cluster members. If you select Off, no load
balancing occurs, and the user selects a node at logon time.
3. Check the Allow optional manual logon to slave nodes from
master logon page while configuring load balancing algorithm
check box to have the FirePass controller present users a list from
which they can select the node they want to log on to.
12 - 12
Verifying the cluster configuration
After configuring the primary and secondary nodes, you must verify
clustering functionality before allowing access to any remote users.
To verify that your cluster configuration is working
1. In the navigation pane of the primary node, click Clustering, and
then click Stats.
The Current cluster stats screen opens.
2. On the Stats screen, in the Last Sync column, verify that the primary
and secondary controllers are synchronizing using the interval you
specified in Configuring a synchronization interval, on page 12-10.
Tip
To update values on the Stats screen, click Stats in the navigation pane.
Verifying the load balancing configuration
After configuring load balancing on the primary and secondary nodes, you
should verify that the feature works properly before allowing access to any
remote users.
To verify that load balancing is working
1. In the navigation pane, click Clustering, and then click Stats.
The Current clustering stats screen opens.
2. Verify that the value shown in the Last Sync column does not
exceed the interval you specified in Configuring a synchronization
interval, on page 12-10.
3. Leave the administrator session active in one instance of the
browser, and use another instance of the browser to log on as a user.
4. From the Preferred Node list on the user logon page, select each
clustering node.
Make sure that the same user can log on to each node.
5. From the Preferred Node list on the user logon page, select
Autoselect, and log on and off repeatedly.
6. In the administrative session, view the statistics to determine
whether the primary controller has redirected the user session to a
randomly selected secondary node. Because the primary controller
can also serve user sessions, the user session might remain on the
primary node even when load balancing is correctly configured. If
the user session is not redirected, log on as a second user, and check
the statistics again.
7. Check the logs on the primary node for errors.
If the primary node cannot redirect the session, it creates an entry in
the system logs. You can check the system logs to determine the
error and correct it, if possible. To access the logs, in the navigation
screen, click Reports.
12 - 13
Chapter 12
Managing a cluster configuration
After you have configured the FirePass controller cluster and verified that it
is working properly, you can manage the cluster and make additional
configuration changes.
Accessing a secondary controller’s configuration
There are several ways to access a secondary controller.
◆
In a web browser’s address bar, type <IP address/admin/> or
<fully qualified domain name/admin/>.
◆
Select the secondary node you want to access from the Preferred node
list when you log on to the primary node.
◆
Use the logon page on the primary controller, if the Allow optional
manual logon to slave nodes from master logon page setting is
checked.
◆
Access the secondary node from within the primary node.
• In the navigation pane of the primary node, click Clustering, and then
click Slave Admin.
• Click the link for the secondary controller that you want to access, and
then log on.
Tip
To return to the primary controller, type the FQDN for the primary
controller in your web browse’s address bar, and then log on.
Once you log on to a secondary node, you can check the system logs and the
logon reports for entries that can help you troubleshoot problems. To access
the reports, in the navigation screen, click Reports.
Displaying statistics for a FirePass controller cluster
You can display operational statistics for a controller cluster in near-real
time.
To display statistics for a FirePass controller cluster
1. Log on to the primary FirePass controller in the cluster.
2. In the navigation pane, click Clustering, and then click Stats.
The Clustering : Stats screen opens.
Statistics presented include the number of sessions active on each node, the
associated CPU load, the number of TCP/IP connections, and the interval
since the most recent primary-secondary synchronization operation.
12 - 14
13
• Understanding Web Applications engine trace
• Using the Web Applications engine trace feature
• Analyzing Web Applications engine traces
Understanding Web Applications engine trace
The FirePass controller Web Applications engine trace feature provides an
easy way for you to capture logs of user sessions through the Web
Applications feature of Portal Access. You can use the trace feature when a
user has trouble using a web applications favorite or direct connection. The
logs provide detailed information about how the FirePass controller is
altering the data stream.
Situations when you would use the Web Applications engine trace feature
include the following:
• A web page does not display properly on a client computer when the user
accesses the application through a FirePass controller Portal Access
connection, but the web page does display correctly when the user
accesses the application in another way.
• Java or JavaScript does not work on a client computer when the user
accesses the application through a FirePass controller Portal Access
connection, but Java or JavaScript normally does work when the user
accesses the application in another.
• Non-HTML elements on a web page do not work on a client computer
when the user accesses the application through a FirePass controller
Portal Access connection, and the non-HTML elements might or might
not normally work when the user accesses the application in another
way.
For example, a web page might include XML, Flash, or ActiveX
components that prevent a client computer from accessing the page.
13 - 1
Chapter 13
Using the Web Applications engine trace feature
The trace feature creates logs that you can use to help identify the causes of
problems with web pages.
Note
If you plan to send the logs to F5 Networks Technical Support, open the logs
in a text editor, review them, and delete passwords and sensitive
information. For more information about reviewing Web Applications
engine trace logs, see Analyzing Web Applications engine traces, on page
13-5.
Important
Dynamic caching on the FirePass controller must be disabled when using
the Web Applications engine trace, unless you are troubleshooting a
problem with the dynamic cache. If dynamic caching is not disabled, items
that are served out of the cache are not included in the backend trace and
you will be unable to compare the response received from the backend to the
response sent to the client. You should also ask the user to clear the browser
cache first, unless the problem occurs only when content is already cached
by the browser.
To use the Web Applications engine trace
1. Have the user who is experiencing problems log on to the controller,
but do not have the user access the problematic web application yet.
2. Connect to the FirePass controller’s Administrative Console using a
web browser, and log on.
The Device Management Welcome screen displays.
Maintenance, and click Troubleshooting Tools.
The Troubleshooting Tools screen displays.
4. In the User box in the Web Applications engine trace area, type the
user’s name whose session you want to trace.
5. To get a list of active sessions for the user, click Get user sessions.
The user’s session ID and status information display in the table.
6. Begin the trace operation by clicking the Connect link that is
associated with the user session.
The trace begins, and the Connect link changes to a Download link.
7. Have the user start a Web Application session and navigate to the
web page that manifests the problem.
8. After the user experiences the problem and the page finishes
loading, click Download, and save the trace file to your local hard
drive.
13 - 2
Note: If the web page does not fully load, the trace file may be
empty. To capture content, be sure to connect to the user session,
then have the user perform the actions you want to trace, and wait
for the user’s browser to finish loading the content or time out.
Understanding trace files
The Web Applications engine trace creates a zipped file with a default name
of ur_debug.zip. Table 13.1 lists the files contained in the zipped file.
File name
Contents
<nnn>.log
Messages from the web applications modules on the FirePass controller itself.
Content in these files is intended for use by F5 Networks Technical Support, and
probably is of limited value for non-F5 personnel.
backend_<nnnn>.html
Messages representing the request and response exchange between the
FirePass controller and the web server containing the request for the page, and
the content before web applications engine parses the content.
backend_<nnnn>.(gif | jpg | ...)
Images referenced in the associated backend_<nnnn>.html file, received by the
FirePass controller from the application’s web server.
frontend_<nnnn>.html
Messages representing the request and response exchange between the
FirePass controller and the client requesting the page.
This is the data from the application’s web server accessed by the user session,
after the FirePass controller has processed it and added state-change information.
frontend_<nnnn>.(gif | jpg | ...)
Images referenced in the associated frontend_<nnnn>.html file, sent to the client
by the FirePass controller.
https.extra-error_log
index.html
Content that formats the data for presentation in a browser window. Each file
represents one specific client request.
The .zip file contains one summary index.html, and one index.html file
representing each client request in the trace. After extraction, you can find the
summary file in the root extraction directory, and each client-request specific file in
its associated directory.
list.html
Content representing each client request in the trace.
The web applications trace engine generates the content of this file during the
active trace operation.
log.html
Data that the content processing engine and content processing scripts changed.
This is a commented list of the reverse-proxy actions the FirePass controller
performed on the associated client request.
ur_debug.log
This is a flag file and it is always empty.
Table 13.1 Contents of the Web Applications engine trace .zip file
13 - 3
Chapter 13
Extracting these files results in a directory structure that contains a summary
index.html and the list.html at the top, with each client request extracted
into a unique directory, named using a sequence number assigned by Web
Applications engine trace. For example:
• REQ_00000000
• REQ_00000001
• … REQ_nnnnnnnn
where nnnnnnnn represents the number of client requests recorded in the
web trace.
At a minimum, each client request directory contains the following files:
• backend<nnnn>.html
• frontend<nnnn>.html
• index.html
• log.html
Each of the files in the client request directory is associated with one
specific client request.
The browser loads these files into different frames in the window,
depending on how you open the files. For more information, see Analyzing
Web Applications engine traces, on page 13-5.
13 - 4
Analyzing Web Applications engine traces
The files created by the Web Applications engine trace contain data you can
look at using a web browser. Many of the files contain only unreadable code
or image data, but one or more should contain content that might help in
troubleshooting issues. For example, you can debug a connection problem
by comparing the backend<nnnn>.html file (data coming into the FirePass
controller from the accessed web server) and the frontend<nnnn>.html file
(the same data after the FirePass controller has processed it), locating the
place at which processing fails, and repairing it.
When you open the summary index.html file (the index.html file in the
top-level directory), the browser loads list.html into the top frame of the
browser window. Then, depending on which link you select in the top
frame, the browser loads the associated files into the appropriate frame in
the browser window.
When you open an index.html that resides in a client-request directory, the
browser loads the associated files into the appropriate frame in the browser
directory.
• Loads log.html into the top frame
If you are viewing the window from the summary index.html, the
browser loads log.html in the second horizontal frame.
• Loads frontend<nnnn>.html into the lower-left frame
• Loads backend<nnnn>.html into the lower-right frame
For more information about the extracted Web Applications engine trace
files, see Understanding trace files, on page 13-3.
You can also open these files in any text editor.
Tip
We recommend using Internet Explorer as the browser because it shows
data with additional highlighting that can help you as you debug the
problem.
To compare trace file content
The FirePass controller processing converts all URLs and anchor tags.
Processed URLs contain the host name of the FirePass controller, as well as
converted paths. The paths are converted to hide their true locations. A
converted path starts with f5-w-. If you are running the reverse proxy in
compatibility mode, the converted path starts with i-tr-.
1. Open the summary index.html or an index.html that resides in a
client-request directory.
2. Compare the incoming data (the backend<nnnn>.html file) with
the processed data (frontend<nnnn>.html), focusing on URLs and
anchor tags (<a href=...>).
13 - 5
Chapter 13
3. Find the point at which the FirePass controller stops processing
URLs or paths.
The problematic code usually exists immediately prior to this point.
Once you have made this comparison, and located the point where controller
processing stops, you can use this information to find and fix several types
of problems.
Fixing common problems
If you are able to identify the place in the trace where the problem occurs,
you may be able to fix the problem.
Most problems are caused by one of three things:
• HTML syntax errors
For more information, see Fixing HTML syntax errors, following.
• Complex Java applet code
For more information, see Java applet code issues, on page 13-9.
• JavaScript restrictions
For more information, see JavaScript restrictions, on page 13-9.
Fixing HTML syntax errors
HTML syntax errors are common. Frequently they are invisible or cause
only minor problems with a web page’s appearance, but web pages with
syntax errors can also result in significant problems in certain browsers or
when accessed through a Portal Access favorite.
To find HTML syntax errors
1. Start with the comparison you made of the frontend<nnnn>.html
and backend<nnnn>.html in Analyzing Web Applications engine
traces, preceding, locating the point at which the FirePass controller
stopped converting the URLs.
2. Look at the HTML source code immediately preceding the error
point.
This is where you find HTML syntax errors that can cause
problems.
If you find an HTML syntax error, you can correct it in one of several ways:
• Edit the source HTML directly on the web page
For more information, see Fixing HTML syntax errors by editing the
source HTML, following.
• Use the FirePass controller’s content cleaning feature
For more information, see Using the Web Applications content cleaning
feature to fix HTML syntax errors, on page 13-7.
• Use a SED script to correct the HTML error
For more information, see Using Web Applications content processing
scripts to fix HTML syntax errors, on page 13-8.
13 - 6
Fixing HTML syntax errors by editing the source HTML
The easiest way to fix HTML syntax errors is to correct them on the web
page at its source. To do this you need access to the web server and the
source web pages. If you have this access, correct the error directly on the
page.
Errors include:
• Missing quotation marks
• Doubled quotation marks
• Tags that have no corresponding close tag
Using the Web Applications content cleaning feature to fix HTML syntax errors
If you cannot correct the syntax error on the source HTML page, you can
use the FirePass controller content cleaning feature to fix the syntax error.
The content cleaning feature only works on HTML and plain text.
To use the content cleaning utility
1. In the navigation pane, click Portal Access, and click Content
Processing.
The Content Processing screen opens with the Preprocessing Scripts
tab selected.
2. In the Web Applications Content Cleaning area, type the URL for
the page that contains the HTML syntax error.
You can specify a comma-separated list of URLs to process for
content cleaning. You can use the wildcard characters asterisk ( * ),
represents a single character. An empty list means that the content
cleaning functionality does not clean any content.
3. Click Update.
The URL’s patterns are saved.
4. To verify that the cleaning utility worked, compare front-end
response files from before and after using the cleaning utility.
Tip
For a faster way to test content cleaning, type the complete URL of the web
application page into the text field under Test Content Processing Settings,
and click the Test button. This runs content cleaning on the page, and
returns four pieces of data: original URL source, content cleaning warnings
and errors, modified URL source, and modified URL source difference.
13 - 7
Chapter 13
Using Web Applications content processing scripts to fix HTML syntax errors
If the problem continues after you use the content cleaning feature, you can
create a SED script to fix specific HTML errors dynamically. SED is a
scripting language that you can use to locate a pattern in an incoming web
page, and modify the match before sending the web page to the client. For
more information about content processing, see Configuring processing
scripts for content processing, on page 7-19, and Adding a SED script, on
page 7-19.
Note
The web applications module processes the list of content processing scripts
until it finds a match. After that, it stops examining scripts. To replace
several things on one page, you must replace all content in a single content
processing script.
To fix an HTML error using a SED script
1. In the navigation pane, click Portal Access, and click Content
Processing.
The Content Processing screen opens with the Preprocessing Scripts
tab selected.
2. In the Web Applications Content Processing Scripts area, click Add
New Favorite to add a new SED script.
The editing fields for the SED script display.
3. In the Processing script name box, type a name that identifies the
script.
4. In the URL match patterns box, type a URL for the web page that
is causing problems.
You can specify a comma-separated list of URLs to process for
content processing. You can use the wildcard characters asterisk (*),
represents a single character, for example,
http://*.siterequest.com/*. An empty list means that the content
processing functionality does not process any content.
5. If you want your script to process content other than text-based
(plain text, HTML), type the additional content type in the Content
Type box. For example, you could type application/javascript.
An empty field indicates a text file.
6. In the Sed processing script box, type the script.
7. From the Processing list, select an option.
The option specifies when the script will run to process the content.
For more information, see Configuring content processing for web
applications, on page 7-18.
8. To add the new SED script and processing configuration, click Add
New.
13 - 8
Using SED scripts: recommendations and other considerations
Once a particular SED script pattern match has been made, only the
associated SED script run. No SED scripts that follow will run.
SED scripts are most easily written with an exclamation point ( ! ) as a
separator, since this greatly reduces the need to escape characters in the
script.
Start with a single SED script that makes a minor change to content first.
Then modify from there. The SED script test button is useful as is a Linux
system with SED for testing.
Java applet code issues
A signed Java applet is an applet containing a signature that verifies the
source of the applet. If a signed Java applet refers to an Internet site other
than the one the applet came from, the FirePass controller cannot make the
appropriate host name or path substitutions in the URL, because making
substitutions invalidates the applet signature. For more information about
Java applet resigning, see Preventing Java byte code rewriting, on page
7-26.
In these situations, you cannot use a Portal Access connection to access the
web site. Instead, use Application Access (App Tunnels) or Network
Access.
JavaScript restrictions
Web pages can have JavaScript programs embedded in them. Sometimes
JavaScript programs have requirements that do not work inside a FirePass
controller Web Application connection.
For example, if a JavaScript program tests URLs to verify that they begin
with http://, this can cause a problem for a Web Application connection
because every URL that goes through the connection goes over a secure
connection, and a secure connection requires that URLs start with https://.
If you identify a JavaScript problem caused by a requirement such as this,
you can use a SED script to modify the JavaScript. Or, you can use
Application Access (App Tunnels) or Network Access instead of a Portal
Access connection.
For more information about Java script issues, see Scanning for embedded
script code, on page 7-43.
For detailed instructions on how to identify and respond to specific
problems you encounter, see Solution SOL3084 on the Ask F5 technical
support site.
13 - 9
Chapter 13
13 - 10
A
How-To Examples
• Introducing how-to scenarios
• Denying access to users running Google Desktop
Search
• Denying and allowing logons from specific operating
systems and requiring certificates
How-To Examples
Introducing how-to scenarios
The how-to scenarios covered in this appendix are based on real-world use.
You can find a description of the how-to scenario at the beginning of each
section.
Each scenario covers one step-by-step operation, and each one can stand on
its own (that is, the scenarios do not build on each other), so you can start
anywhere.
Note
Although each section can stand alone, the more complex scenarios might
require existing knowledge. In that case, the content points you to
appropriate sections in the FirePass Controller Administration Guide or
pages in the FirePass controller online help.
You can check your progress against screenshots provided at a number of
steps. The intention is to keep you on track without overburdening you with
screenshots.
When you complete the steps, you will have a working version of the
functionality the scenario covers. All information you need to deploy the
working model is provided, including any hints, best practices,
requirements, or warnings.
A-1
Appendix A
Denying access to users running Google Desktop
Search
This how-to scenario describes, step-by-step, creating a pre-logon sequence
to manage inbound access to the FirePass controller. This is a relatively
simple pre-logon sequence. For steps on creating a more complex pre-logon
sequence, see Denying and allowing logons from specific operating systems
and requiring certificates, on page A-10.
Google Desktop Search lets users search documents, spreadsheets, email,
instant messages, and web pages that have been visited by that PC. To
enable this, the software creates cached versions of the content. Depending
on the rights of the user accessing the information, this can include
corporate information stored on servers accessed using a web browser.
Although Google Desktop Search is not intended to be used in a
shared-computer environment, the software may be running on publicly
available computers. This scenario describes how to create a pre-logon
sequence that blocks logons from computers running the Google Desktop
Search engine.
Creating the Google Desktop Check pre-logon sequence
A sequence is a set of actions and rules that act in concert to collect
information about the end-user's system before granting or denying access to
the FirePass controller. Inspectors activated in the sequence perform the
functionality of gathering the information when a user attempts to logon.
You can read more about sequences and inspectors in Creating a pre-logon
sequence, on page 3-16.
In this example, we create a pre-logon sequence called Google Desktop
Check that tests for the presence of the Google Desktop Search software
prevents logon from any computer running Google Desktop Search.
To create a new sequence
1. Log on to the FirePass controller using an administrative account.
then click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens, as shown in Figure A.1, on
page A-3.
A-2
How-To Examples
Figure A.1 FirePass controller Pre-Logon Sequence screen
3. In the New Sequence section in the Create new sequence box, type
Google Desktop Check.
4. From the box titled Based on, select template: Empty.
The screen should look similar to Figure A.2, on page A-4.
A-3
Appendix A
Figure A.2 Creating the Google Desktop Search sequence
5. Click Create.
6. Under Select Sequence to Use, click the edit link for Google
Desktop Check.
The visual policy editor opens, as shown in Figure A.3.
Figure A.3 The visual policy editor, for creating pre-logon sequences
A-4
How-To Examples
Adding the Google Desktop Check action to the pre-logon
sequence
Now that the pre-logon sequence exists, it needs an action to check for and
act on Google Desktop Search.
Figure A.4 Cursor positioned on the connecting line, with add action icon
active
To check for the presence of Google Desktop Search
1. On the screen containing the Google Desktop Check sequence you
created, position the cursor on the connecting line between
Sequence Start and Logon Allowed Page.
A small plus icon
appears, as shown in Figure A.4.
2. Click the add action icon
.
3. The CHANGE SEQUENCE panel opens in the visual policy editor.
4. Under Predefined actions, select Check for Google Desktop.
5. Click the Apply changes button at the bottom of the panel.
The visual policy editor adds Check for Google Desktop to the
sequence, as shown in Figure A.5, on page A-5.
Figure A.5 The visual policy editor after adding the Check for Google Desktop action.
A-5
Appendix A
The Check for Google Desktop action contains a predefined rule that, by
default, prevents access to users running Google Desktop Search. The rule
uses the value returned from the check operation to determine access. To
open the rule, click the link named Click here to show rules. The Edit rules
area opens, as shown in Figure A.6, on page A-6.
Figure A.6 The visual policy editor with the Edit rules section open
In this case, the rule uses the value in session.google_desktop_check.result
!= 1 to prevent access to users running Google Desktop Search.
Tip
You can force Google Desktop Search to close but still allow logon by
changing the end page to Logon Allowed Page.
You can click the I icon
next to Checks for presence of Google
Desktop Search product under Inspectors in the Edit Action panel to open
the details page, as shown in Figure A.7, on page A-7.
A-6
How-To Examples
Figure A.7 The Google Desktop Search inspector details page
Informing users of the reason that they are prevented from logging on helps
them correct the condition and try logging on again. The next step guides
you through the process of creating a logon-denied message.
Customizing the Google Desktop Check logon-denied message
In this step, we create a message to present to users who are denied access
because they have Google Desktop Search running.
To create a logon-denied message
1. Click the Logon Denied Page box.
The END PAGE PROPERTIES panel opens in the visual policy
editor, as shown in Figure A.8, on page A-7.
Figure A.8 The End Page Properties panel open in the visual policy editor
A-7
Appendix A
2. Into the Message for failed logons box, type the following text for
the message:
The FirePass controller cannot log you on because you
have Google Desktop Search running. Halt the software and
try logging on again.
4. In the upper right corner, click the Back to console link to return to
the Pre-Logon Sequence Page.
5. Under Select Sequence to Use, select Google Desktop Check and
click the Apply button, as shown in Figure A.9.
Figure A.9 Pre-Logon Sequence screen with Google Desktop Check selected and applied
A-8
How-To Examples
You have created a pre-logon sequence that checks for and prevents logon
by users running Google Desktop Search. As long as you keep the Google
Desktop Check pre-logon sequence selected, users who are running Google
Desktop Search cannot log on to the associated FirePass controller.
Note
You can modify any pre-logon sequence to contain different functionality. If
you do, you should also change the sequence name to reflect any changes
you make. You can change the name by selecting the sequence from the
Rename sequence box, typing the new name, and clicking the Rename
button.
A-9
Appendix A
Denying and allowing logons from specific operating
systems and requiring certificates
This how-to scenario describes, step-by-step, creating a pre-logon sequence
to manage inbound access to the FirePass controller. This is a relatively
complex pre-logon sequence, For steps on creating a simpler pre-logon
sequence, see Denying access to users running Google Desktop Search, on
page A-2.
The pre-logon sequence created meets the following requirements:
• Denies logon from Windows 95, Windows 98, and Windows Me
connections.
• Requires Windows NT and Windows 2000 users to log on using the
virtual keyboard.
• Allows connection only from Windows XP, Linux, Pocket PC, and
Macintosh systems that have a valid client certificate.
Rule 1 – Deny Windows 95, Windows 98, and Windows Me
connections
For the purpose of this how-to scenario, we create a pre-logon sequence that
tests for the client’s operating system and prevents logon from computers
running Windows 95, Windows 98, and Windows Me. We also create a
logon-denied message to inform users of the cause of the denial of logon.
Creating the Corporate Access Check pre-logon sequence
In this example we create a pre-logon sequence called Corporate Access
Check that prevents logon from any computer running Windows 95,
Windows 98, or Windows Me.
To create a new sequence
1. Log on to the FirePass controller using an administrative account.
2. In the left navigation pane, click Users, expand Endpoint Security,
and then click Pre-Logon Sequence.
The Pre-Logon Sequence screen opens, as shown in Figure A.10, on
page A-11.
A - 10
How-To Examples
Figure A.10 FirePass controller Pre-Logon Sequence screen
3. Under the New Sequence section, in the Create new sequence box,
type Corporate Access Check.
4. From the box titled Based on, select template : Empty.
5. Click Create.
6. Under Select Sequence to Use, click the edit link for Corporate
Access Check.
The visual policy editor opens, as shown in Figure A.11, on page
A-12.
A - 11
Appendix A
Figure A.11 The visual policy editor, for creating pre-logon sequences
Adding the Check OS action to the pre-logon sequence
Now that the pre-logon sequence exists, it needs an action to check for the
operating systems of clients logging on.
active
To check the client operating system
1. On the screen containing the Corporate Access Check sequence you
created, position the cursor on the connecting line between
Sequence Start and Logon Allowed Page.
A small plus icon
.
4. Under Predefined actions, select Check OS.
The visual policy editor adds Check OS to the sequence, as shown
in Figure A.13, on page A-13.
A - 12
How-To Examples
Figure A.13 The visual policy editor after adding the Check OS action
The default Check OS action denies access to users logging on using the
associated operating systems.
Informing users of the reason that they are prevented logon helps them
correct the condition and try logging on again. The next step guides you
through the process of creating a logon-denied message.
Customizing the Windows 9.x logon-denied message
In this step, we create a message to present to Windows 95, Windows 98,
and Windows Me users who are denied logon access.
1. Click the Logon Denied Page box to the right of Windows 9x
family.
editor.
the message:
This FirePass controller does not support client
computers running Windows 98, Windows 95, or Windows Me.
Supported client operating systems include Windows 2000,
Windows NT, Windows XP, and Windows 2003.
Contact the help desk for more information.
The visual policy editor should now appear similar to the screen
shown in Figure A.14, on page A-14.
A - 13
Appendix A
Figure A.14 The END PAGE PROPERTIES panel with the logon-denied message for Windows 9.x users
Rule 2 – Require Windows NT and Windows 2000 clients to log
on using the virtual keyboard
Next we modify the Windows NT Based action so that it requires Windows
NT and Windows 2000 clients to logon using the virtual keyboard.
The virtual keyboard is a floating keyboard that requires mouse clicks to
enter a password. After each click, the virtual keyboard repositions itself on
the screen. Use of the virtual keyboard aids in preventing unauthorized
recording of logon information by key loggers and other software.
Changing the Windows NT based action
Because the rule we are creating should apply only to clients logging on
using Windows NT and Windows 2000, the first step is to change the
Windows NT Based action to remove the occurrence of Windows XP.
To modify the Windows NT based action
1. Click Windows NT based link in the Corporate Access Check
sequence.
The UPDATE RULE panel opens in the visual policy editor, as
A - 14
How-To Examples
Figure A.15 The UPDATE RULE panel for the Windows NT Based action
2. Delete the session.os.platform == "WinXP" OR condition.
3. In Name, type Windows NT and 2000.
4. Click Update.
You can find a complete set of the session variables generated by inspectors
for action rule expressions in the online help for Users : Endpoint Security :
Pre-Logon Sequence.
Adding the Show Virtual Keyboard action
Now we add the action to require use of the virtual keyboard for Windows
NT and 2000 connections.
To add the Show Virtual Keyboard action
1. On the sequence containing the Corporate Access Check sequence
you created, position the cursor on the connecting line between
Windows NT Based and Logon Allowed Page.
A small plus icon
appears, as shown in Figure A.16, on page
A-16.
A - 15
Appendix A
active.
.
4. Under Predefined actions, select Show Virtual Keyboard.
The visual policy editor adds Show Virtual Keyboard to the
sequence, as shown in Figure A.17.
Figure A.17 The visual policy editor after adding the Show Virtual Keyboard action
Now, any users who are running Windows NT or Windows 2000 must use
the virtual keyboard to enter their password when they log on to the FirePass
controller.
Rule 3 – Allow logons only from Windows XP, Linux, Pocket PC,
and Macintosh computers that have a valid certificate.
Next, we want to allow logon only when the connecting client operating
system is of a certain type and that has a specified client certificate. To
accomplish that, we use the subsequence feature in the visual policy editor.
A - 16
How-To Examples
Creating a subsequence for Corporate Access Check
For this rule, we create a subsequence that maps several conditions in the
Check OS action. Subsequences are sequences that perform self-contained
actions. You can use subsequences to refine what actions occur in response
to certain conditions.
To create a subsequence for Corporate Access Check
1. Click the Open subsequences management link in the
Subsequences area of the screen.
The SUBSEQUENCES panel opens in the visual policy editor, as
shown in Figure A.18.
Figure A.18 The visual policy editor with the SUBSEQUENCES panel open
2. In the box under Add new subsequence in the SUBSEQUENCES
panel, type Certificate Check to name the subsequence.
3. Click the Add subsequence button.
The Subsequence:certificate check appears in the visual policy
editor, as shown in Figure A.19, on page A-18.
A - 17
Appendix A
Figure A.19 The visual policy editor after adding the certificate check subsequence
Adding the Client certificate check action
Next, we add the Client certificate check action to the certificate check
subsequence. The Client certificate check gathers information about
certificates on client computers and compares that information with the
configuration that you specify in the rule.
Note
You must configure and enable client certificate checking before the
FirePass controller can request and check users’ client certificates. For
more information, see Setting up client-certificate-based authentication, on
page 2-55.
To add the Client certificate check action
1. On the certificate check subsequence you created, position the
cursor on the connecting line between Subsequence:certificate
check and Logon Denied Page.
A small plus icon
appears, as shown in Figure A.20, on page
A-19.
A - 18
How-To Examples
active
.
4. Under Predefined actions select Check client certificate.
The visual policy editor adds Check client certificate to the
subsequence, as shown in Figure A.21, on page A-19.
Figure A.21 The visual policy after adding the Check client certificate action to the subsequence
Changing the end page for the subsequence
To complete the certificate check subsequence, we change the final action to
allow logons when the client computer has a valid certificate. In this case,
we change Logon Denied Page to Logon Allowed Page.
A - 19
Appendix A
To change the subsequence’s final action
1. Click the top Logon Denied Page box for the certificate check
subsequence.
editor.
2. In the Type box in the END PAGE PROPERTIES panel, select
Logon Allowed Page.
The end page changes to Logon Allowed Page, as shown in Figure
A.22.
Figure A.22 The subsequence after changing the final action to Logon Allowed Page.
Informing users of the reason that they are prevented from logging on helps
them correct the condition and try logging on again. The next step guides
you through the process of creating a logon-denied message.
Customizing the logon-denied message for the subsequence
In this step, we create a message to present to Windows XP, Linux, Pocket
PC, and Macintosh users who are denied logon access because they lack a
client certificate.
A - 20
How-To Examples
1. Click the Logon Denied Page box to the right of the fallback rule in
the subsequence.
The UPDATE RULE panel opens in the visual policy editor.
the message:
The FirePass controller cannot log you on because you do
not have a valid client certificate.
Contact the help desk to get a valid client certificate,
and try to logon again.
3. Click the Update button:
shown in Figure A.23.
Figure A.23 The END PAGE PROPERTIES panel with the logon-denied message for users without valid
certificates
A - 21
Appendix A
Adding a Windows XP rule to the sequence
In this step, we create a Windows XP-related rule and map the Windows
XP, Pocket PC, and Mac OS rules to the Certificate Check subsequence.
To create the Windows XP-related rule
1. On the sequence, position the cursor on the connecting line between
Windows 9x family and Linux.
A small plus icon
Figure A.24 Cursor positioned on the connecting line, with add rule icon
active
2. Click the add rule icon
.
3. The INSERT RULE panel opens in the visual policy editor.
4. In Name, type Windows XP.
5. In the box under Name, type session.os.platform == "WinXP".
6. Click the Insert Rule button.
You can find a complete set of the session variables generated by inspectors
for action rule expressions in the online help for Users : Endpoint Security :
Pre-Logon Sequence.
A - 22
How-To Examples
Figure A.25 The sequence after adding the Windows XP file.
Next, we map the Windows XP, Pocket PC, and Mac OS rules to the
Certificate Check subsequence.
To map the Windows XP rule to the subsequence
1. On the sequence, position the cursor on the connecting line between
Windows XP and Logon Denied Page.
A small plus icon
active
.
A - 23
Appendix A
4. In the CHANGE SEQUENCE panel in the Change sequence box,
select Replace action (deletes branch after).
Options in CHANGE SEQUENCE update to include a
Subsequences section.
5. In Subsequences, select Subsequence: certificate check.
The visual policy editor adds Check client certificate to the
subsequence, as shown in Figure A.27.
Figure A.27 The sequence after adding Check client certificate.
7. Repeat the steps in this procedure to map Linux, Pocket PC, and
Mac OS to the subsequence.
The final Corporate Access Check pre-logon sequence screen
should appear similar to Figure A.28, on page A-25.
A - 24
How-To Examples
Figure A.28 The final visual policy editor for the Corporate Access Check pre-logon sequence
Activating the Corporate Access Check pre-logon sequence
In this step, we activate the pre-logon sequence we just created.
To activate the pre-logon sequence
1. From the visual policy editor, click the Back to console link in the
upper right of the screen.
2. Under Select Sequence to Use, select Corporate Access Check and
click the Apply button, as shown in Figure A.29, on page A-26.
A - 25
Appendix A
Figure A.29 The Pre-Logon Sequence screen with Corporate Access Check selected and applied
You have now completed creating a pre-logon sequence that checks for and
prevents logon by users running Windows 95, Windows 98, and Windows
Me, requires virtual keyboard for logon from Windows NT- and Windows
2000-based clients, and requires a valid certificate for logon from Windows
XP, Linux, Pocket PC and Macintosh computers.
Tip
You can modify any pre-logon sequence to contain different functionality. If
you do, you should also change the sequence name to reflect any changes
you make. You can change the name by selecting the sequence from the
Rename sequence box, typing the new name, and clicking the Rename
button.
A - 26
Glossary
Glossary
active unit
In a redundant system, the active unit is the system that currently load
balances connections. If the active unit in the redundant system fails, the
standby unit assumes control and begins to load balance connections. See
also redundant system.
The Administrative Console is the browser-based application that you use to
configure the FirePass controller.
certificate
A certificate is an online credential signed by a trusted certificate authority
and used for SSL network traffic as a method of authentication.
cluster
A cluster is a group of FirePass controller nodes that provide common user
services, and can distribute the load of active sessions across all controllers
in the cluster.
domain name
A domain name is a unique name that is associated with one or more IP
addresses. Domain names are used in URLs to identify particular Web
pages. For example, in the URL http://www.siterequest.com/index.html,
the domain name is siterequest.com.
Domain Name System (DNS)
The Domain Name System (DNS) is a system that stores information
associated with domain names, making it possible to convert IP addresses
such as 192.168.16.8, into more easily understood names such as
www.siterequest.com.
Dynamic Host Configuration Protocol (DHCP)
DHCP is a protocol for assigning dynamic IP addresses to devices on a
network. With dynamic addressing, a device can be assigned a different IP
address every time it connects to the network.
failover
Failover is the process whereby a standby unit in a redundant system takes
over when a software failure or a hardware failure is detected on the active
unit. See also active unit and standby unit.
failover pair
See redundant system.
FirePass® Controller Getting Started Guide
Glossary - 1
Glossary
favorite
A favorite is a webtop link defined by the FirePass controller administrator
or the user that contains all of the information needed for the client
computer to access a location, file share, or application on the company
network.
FIPS compliant
Federal Information Processing Standards (FIPS) are publicly announced
standards developed by the U.S. Federal government for use by all
(non-military) government agencies and by government contractors. The
FirePass controller can be configured with FIPS 140-encryption hardware,
which stores all certificates and private keys in the FIPS hardware.
FQDN
See fully qualified domain name.
fully qualified domain name
The fully qualified domain name (FQDN) is an unambiguous domain name
that specifies a node’s position in the DNS tree hierarchy absolutely, for
example, myfirepass.siterequest.com. See also domain name.
high availability
High availability is the process of ensuring access to resources despite any
failures or loss of service in the setup. For hardware, high availability is
ensured by the presence of a redundant system. See also redundant system.
interface
A physical port on an F5 system is called an interface.
IP address
An IP address (Internet Protocol address) is a unique number that identifies
a single device and enables it to use the Internet Protocol standard to
communicate with another device on a network.
IPsec
IPsec (Internet Protocol Security) is a communications protocol that
provides security for the network layer of the Internet without imposing
requirements on applications running above it.
Management Console
The Management Console is a utility that provides administrative access to
the FirePass controller. You can access the Management Console from the
Administrative Console or from a workstation that is directly connected to
Glossary - 2
Glossary
Management interface
The Management interface is a port on the FirePass 4100 that is intended
solely for administrative operations performed from a workstation that is
directly connected to the FirePass controller.
master group
A master group is a collection of users that contains authentication settings,
overall security configuration settings for groups of users, network access
filtering policies, user experience, and user accounts.
name resolution
Name resolution is the process by which a name server matches a domain
name request to an IP address, and sends the information to the client
requesting the resolution.
NAT (Network Address Translation)
A NAT is an alias IP address that identifies a specific node managed by the
FirePass system to the external network.
Network Access
Network Access is a FirePass controller feature that provides secure access
to corporate applications and data using a standard web browser.
Quick Setup
The Quick Setup wizard is a program that you can run from the
Administrative Console that guides you through the initial configuration
tasks for the FirePass controller.
port
A port is a number that is associated with a specific service supported by a
host.
redundant system
Redundant system refers to a pair of units that are configured for failover. In
a redundant system, there are two units, one running as the active unit and
one running as the standby unit. If the active unit fails, the standby unit takes
over and manages connection requests.
snapshot
A snapshot is a compressed set of files that represent the FirePass
controller’s system settings. You can create and restore a snapshot using the
Management Console. See also Maintenance Console.
SSL (Secure Sockets Layer)
SSL is a network communications protocol that uses public-key technology
as a way to transmit data in a secure manner.
FirePass® Controller Getting Started Guide
Glossary - 3
Glossary
standby unit
A standby unit in a redundant system is a unit that is always prepared to
become the active unit if the active unit fails.
webifyer
A webifyer is a FirePass controller feature that uses a browser to provide
nonbrowser-based application functionality. The FirePass controller uses
webifyers to present the Portal Access applications Windows Files and
Mobile E-Mail, as well as the Application Access applications Legacy
Hosts, Terminal Servers, and more.
webtop
The webtop is the user’s home page, which contains links that are
configured as favorites for that user’s master group. Along the left side of
the webtop are icons representing various functionality. Depending on how
the webtop is configured, users may be able to add their own favorites by
clicking an icon and adding links.
Glossary - 4
Index
Index
A
access control
and examples 3-32
configuring scope 7-16
access control lists 8-24
accessibility
and full network access 1-6
and options 1-6
action pane
described 3-22
action-checking operation
and action pane 3-22
actions
and internal structure for 3-20
and pre-logon sequence 3-16
and rules 3-23
using in pre-logon sequences 3-19
active connections
and Complete history log 10-14
and Currently active log 10-13
and Session summary log 10-15
and Today’s sessions log 10-14
active controller 11-1
and synchronization 11-12
configuring heartbeat synchronization 11-14
See also failover.
See also redundant systems.
verifying identity 11-20
Active Directory
and mapping groups dynamically 2-27
defined 2-55
active failover members
reviewing configuration 11-2
ActiveX controls
and endpoint security 3-10
and inspectors 3-11
activity reports 10-16
Admin Email
configuring 8-31
administrative privileges
assigning to users 8-29
administrators
and full access 8-27
and realm-level configurations 8-27
configuring administrator-specific access 8-29
advanced mode
See Routing screen modes.
agent host
and RSA SecurID authentication server 8-34
agent host records 8-33
alias to a favorites
See favorites.
allow list 8-24
Alternative Host/Port-based bypass
configuring 7-13
antivirus
and content inspection 7-42
antivirus detection
antivirus scanning
and Portal Access 7-47
App Logs report
described 10-1
understanding entries 10-3
using 10-2
App Tunnel access control 8-24
App Tunnels
and best practices for customizing 6-14
and configurable applications 6-2
and IPsec VPN clients 6-2
and Network Access 6-2
configuring customized master group settings 6-22
configuring master group settings 6-22
configuring settings for webifyer status 6-23
configuring to open automatically 6-16
customizing 6-14
defined 2-64
defining favorites 6-7
for resource groups 2-67
mapping network drive 6-16
understanding 6-2
understanding master group settings for 6-22
appearance of home page, customizing 8-66
Application Access
configuring Legacy Hosts keyboard mapping 6-27
defining Legacy Host favorites 6-26
introducing 6-1
application access
application launch
configuring for Macintosh or Linux 9-9
Application Logs report
See App Logs report.
application tunnel access
described 1-6
See App Tunnels.
applications
and App Tunnels 6-2
Ask F5
and support 1-15
attempts to log on, report 10-10
Index - 1
Index
authentication 2-46
and dynamic group mapping 2-58
and external user management 2-6
and extra policy layer of protection 2-57
and master groups 2-12, 2-46
and NTLM 7-14
and passwordless auto-login 2-58
and pre-logon sequence processing 2-58
and resource protection 2-59
and two-factor authentication 2-57
choosing an authentication scheme 2-46
configuring a RADIUS server 2-49, 2-50
configuring a Windows domain server 2-54
configuring Active Directory 2-55
configuring client certificates 2-57
configuring HTTP for 2-55
configuring LDAP server 2-51
configuring passwordless automatic-login 2-59
configuring RSA SecurID authentication server 8-33
converting the method for master group 2-49
determining a method 2-47
overview 2-46
specifying a method for a group 2-47
authentication methods 2-4
authentication modes
and Windows domain server 2-54
authentication settings for a group of users
See master groups.
authorization 2-46
B
backups
and automatic 8-46
and manual 8-46
and restoring configurations 8-46
best practices
and client certificates 4-12
and clustered controllers 12-2, 12-6
for certificate revocation lists 4-12
for certificates 4-2
for customizing App Tunnels 6-14
for external authentication 2-6, 2-14
for LDAP authentication 7-39
for managing users 2-3
for Online Certificate Status Protocol 4-13
for protected configurations 3-8, 3-31
for RSA and VASCO authentication 8-41
for specifying ports 8-6
for upgrades 8-45
BIG-IP system
and offloading SSL processing 8-23
and virtual servers 8-23
described 8-22
Index - 2
bitrate
configuring parameters for bitrate evaluator 5-18
determining value 5-18
browser definitions, adding 8-32
browser usage
See Summary reports.
browsers
adding definitions for 8-32
and requirements for endpoint security 3-26
installing certificates 4-8
using to upgrade 8-47
buffer overflow
buffer overflow attacks
and exploited inputs 7-46
and options 7-46
C
cache and compression
configuring 7-30
configuring global settings 7-31
CA-signed certificates 4-6
See also certificates.
understanding 4-2
using 4-2
cert.zip file
and self-signed certificate 4-6
certificate
and status 4-3
certificate revocation list
and best practices 4-12
and limitation 4-12
described 4-11
Certificate Signing Request
CertRequest.zip files 4-6
sending as an email attachment 4-6
specifying type 4-6
submitting 4-6
certificate store 9-4
certificates
accessing server certificate information 4-3
and browser warnings 4-1
and extra policy later of protection 2-57
and FIPS hardware 4-7
and Online Certificate Status Protocol 4-13
and types of 4-6
associating with a web service 4-8
deleting 4-10
generating Certificate Signing Request 4-4
generating self-signed certificates 4-7
installing a signed server certificate 4-6
installing on client browser 4-8
installing self-signed certificates 4-7
overview 4-1
Index
sending a Certificate Signing Request as an email
attachment 4-6
specifying type for Certificate Signing Request 4-6
submitting a Certificate Signing Request 4-6
understanding CA signed certificates 4-2
understanding self-signed certificates 4-2
understanding SSL server certificates 4-1
updating server certificates 4-9
using client certificates 2-56
using self-signed certificates 4-2
viewing 4-3
CertRequest.zip files
and Certificate Signing Request 4-6
chaining certificates
See also intermediate certificates.
See CA-signed certificates.
Citrix MetaFrame servers
and Terminal Server favorites 6-30
Citrix Web Client
and Application Access 6-33
specifying location 6-33
Clam AntiVirus
configuring for automatic update 7-49
configuring for manual update 7-48
enabling 7-48
client applications
client browsers
installing certificates 4-8
client certificates
and certificate revocation list updates 4-12
and Online Certificate Status Protocol 4-13
authenticating users 2-59
configuring for authentication 2-57
requesting during logon 2-56
using 2-56
client components
and security policy 9-1
downloading 9-1
client connections
establishing 9-11
client cookies
See cookies.
client root certificates
overview 4-11
client system checking
implementing 3-15
clientless mode 3-1
cluster controllers
requirements for setup 12-2
clustered controllers
accessing secondary from primary 12-15
and benefits 12-1
and best practices 12-2, 12-6
and certificates 12-2
and domain names 12-2
displaying operational statistics 12-15
overview of 12-1
starting 12-6
synchronizing 12-1
clustered controllers, primary 12-1
clustered controllers, secondary 12-1
clustered servers
synchronizing 12-7
clustering
See clustered controllers.
clusters
See clustered controllers.
collection of resources
See also master groups.
See resource groups.
command line
using to upgrade 8-48
command syntax conventions 1-13
common operations, following recommended path 1-9
common problems
fixing with Web Applications engine trace 13-6
troubleshooting 8-59
Complete history logs
understanding 10-14
configuration of failover 11-5
configuration settings for a group of users
See master groups.
configurations
and scenarios 1-10
backing up and restoring 8-45
restoring FIPS systems 8-46
console, accessing 8-59
content inspectors
and types 7-42
configuring 7-42
content processing
configuring for web applications 7-18
configuring scripts for 7-19
testing settings 7-23
context-sensitive online help 1-15
control restrictions 8-24
cookies
specifying cookie passthrough 7-5
Corporate Access Check pre-logon sequence 3-12
CRL
See certificate revocation list.
Index - 3
Index
cross site scanning
excluding sites from 7-44
cross site scripting
configuring 7-42
CSR
See Certificate Signing Request.
CSS scripting
See cross site scripting.
Currently active log, understanding 10-13
custom messages
and options 5-30
custom variables
creating 3-9
D
date format, specifying 8-41
default gateway
modifying using light mode 8-9
default group
See also default master groups.
default keyboard mapping 6-28
default master groups
deleting 2-12
See master groups.
using 2-8
default server certificate 4-3
definitions for browsers, adding 8-32
deployment solutions
connecting FirePass controller to internal LAN 5-9
connecting FirePass controller to separate LAN
5-10
DMZ subnet
and NAPT communication 5-10
and static routes 5-10
DNS
configuring 8-16
understanding options 5-22
domain scripts
running 5-24
dynamic caching
and Web Applications engine trace 13-2
dynamic group mapping
and authentication 2-58
and master mapping table 2-22
and related request configurations 2-26
and resource mapping tables 2-22
and tasks for configuring 2-22
configuring 2-25
enabling 2-23, 2-24
optimizing 2-16
See also group mapping.
See group mapping.
understanding 2-16
Index - 4
dynamic master group mapping
and examples 2-20
dynamic resource groups
See resource groups.
dynamically mapped resource group
defined 2-65
See also resource groups.
E
email
and security alerts and notifications 8-31
configuring Admin Email 8-31
configuring LDAP as email address source 7-40
configuring system health notifications 8-64
disabling email attachments 7-41
See also Mobile E-Mail.
email attachments
disabling 7-41
email notification for system health, configuring 8-64
email server, specifying 8-37
endpoint security
and actions 3-16
and actions to correct client computer 3-7
and ActiveX controls 3-10
and antivirus detection 3-9
and browser requirements 3-26
and clientless mode 3-1
and extra policy layer of protection 2-57
and file version 3-9
and implementation tasks 3-15
and inspectors 3-9
and internal structure for an action 3-20
and JavaScript 3-10
and Linux 3-1
and MacOS X 3-1
and McAfee 3-8
and MD5 signature 3-9
and Norton AntiVirus 3-8
and operating system detection 3-9
and protected configurations 3-8, 3-11
and risk-factor/safety feature associations table
3-27
and rule examples 3-23
and rule syntax 3-23
and scans 3-9
and session variables 3-24
and visual policy editor 3-11
assigning a protected configuration to a favorite
3-19
collecting information 3-1
configuring post-logon protection 3-32
creating a pre-logon sequence 3-16
Index
creating a pre-logon sequence rule 3-24
creating protected configurations 3-27
creating subsequent pre-logon sequence 3-25
defining rules and actions in pre-logon sequence
3-23
exempting master groups from safety checks 3-27
implementing access control example 3-32
implementing client system checking 3-15
performing remediation 3-7
protecting resources 3-8
understanding 3-1
understanding protection limitations 3-10
understanding protection options 3-8
external groups
importing 2-13
mapping 2-13
external user management
authentication 2-6
external users
configuring master groups for 2-6
maintaining 2-6
extra policy layer of protection
and client 2-57
extra-access log
See Server access log (http) log.
extra-error log
See Server error log (http) log.
F
F5 Technical Support, contacting 1-15
F5FirePassRoot certificate store 9-4
failover
and clustered controllers 12-6
and fully qualified domain names 11-7
and RSA SecurID 8-37
and shared IP addresses 11-7
configuring active controller 11-7
enabling on active controller 11-7
See also redundant system.
switching to standby controller 11-20
triggering manually 11-20
failover configuration
configuring 11-7
verifying 11-19
failover configuration strategy 11-5
failover controllers
installing 11-1
overview 11-1
starting 11-19
failover member
introducing into production 11-5
failover shared IP address 11-7
failover-only controller 11-2
fake status, for certificates 4-3
fallback
for rules 3-20
favorites
assigning a protected configuration to 3-19
configuring for resource groups 2-66
configuring for terminal servers 6-30
defined 2-1
defining for App Tunnels 6-7
defining for Legacy Hosts 6-26
defining Portal Access 7-6
using a SED script 7-20
file names
for log files 8-50
file shares
mapping App Tunnels 6-16
file version
and inspectors 3-9
files
configuring antivirus scanning 7-47
FIPS
and certificates 4-7
FIPS systems
and backups 8-46
FirePass 1000
described 1-3
specifying ports 8-6, 8-7
FirePass 4000
specifying ports 8-6
FirePass 4100
described 1-3
specifying ports 8-6
FirePass controller
finding software version 1-4
overview 1-1
FirePass models 1-3
FIREPASS-SYSTEM-MIB
and controller-specific features 8-38
firewall detection
Flash rewriting
and Flash files 7-27
understanding 7-27
FlashActionScript 7-27
FQDN
configuring in failover 11-7
specifying 8-3
full access realm administrator
and tasks 8-27
full network access
described 1-6
fully qualified domain names, See FQDN.
Index - 5
Index
G
H
general master group settings
and App Tunnel connections 6-22
for legacy host connections 6-29
for terminal server connections 6-32
global packet filter rules
applying to Network Access traffic 5-10
global packet filters
See global packet filter rules.
global settings
and Windows files 7-35
configuring for cache and compression 7-31
configuring for content processing 7-24
configuring for web applications 7-28
for FirePass controller 8-1
Google Desktop Search
described A-2
Google Desktop Search users
denying access A-2
group mapping
adding mapping table resources 2-65
and master mapping table 2-22
and related request configurations 2-26
and resource groups 2-65
associating your local network groups 2-6
mapping based on Landing URI 2-39
mapping based on RADIUS groups 2-39
mapping based on virtual host 2-42
optimizing 2-16
setting and changing priority 2-45
specifying a method 2-26
understanding 2-17
group mapping <nopage> See also dynamic group
mapping 2-17
Group Names
and master groups 2-11
Group report
described 10-1
using 10-4
group-based averages report
See Group report.
group-level packet filtering rules
applying for specific resource groups 5-25
groups
and default master group 2-14
and Group report 10-4
authenticating externally 2-6
overview 2-1
See also master groups and resource groups.
hardware
monitoring load 8-65
restarting 8-57
shutting down 8-58
health
monitoring 8-65
heartbeat
configuring for active controller 11-14
configuring for standby controller 11-17
defined 11-13
for redundant systems 11-13
help
finding 1-15
locating online help 1-15
high availability
accessing standby controller 11-18
and failover configuration 11-1
and heartbeat 11-13
configuring heartbeat synchronization for active
controller 11-14
configuring heartbeat synchronization for standby
controller 11-17
configuring standby controller 11-15, 11-16
enabling failover on active controller 11-7
introducing failover member 11-5
reviewing active failover member configuration
11-2
reviewing active standby member configuration
11-4
triggering manual failover 11-20
understanding
verifying controller identity 11-20
verifying failover configuration 11-19
home page appearance, customizing 8-66
host names
adding a static host name 8-18
configuring 8-3
preserving 7-17
See also FQDN.
host names, static 8-17
how A-1
how-to
creating a subsequence mapping to several condition
actions A-16
denying access to Google Desktop Search users
A-2
denying access to Windows users A-10
requiring Windows users to log on with virtual
keyboard A-14
Index - 6
Index
HTML syntax errors
and options for fixing 13-6
fixing with SED scripts 13-8
fixing with Web Applications content cleaning
feature 13-7
HTTP activity
and HTTP Log report 10-6
HTTP and HTTPS Log report
described 10-1
HTTP basic authentication 2-4
HTTP form-based communication
using for authentication 2-4
HTTP Log report
and options 10-6
using 10-6
HTTP proxies
using 8-39
HTTPS
https.extra-access log
See Server access log (https) log.
https.extra-error_log file
See Server error log (https) log.
I
ICAP
described 7-48
inspectors
and antivirus detection 3-9
and browser requirements for endpoint security
3-26
and file version checking 3-9
and firewall detection 3-9
and Java plug-ins 3-11
and MD5 signature 3-9
and operating system detection 3-9
and pre-logon sequences 3-11
and protected configurations 3-27
and scans 3-9
creating custom variables 3-9
See also content inspectors.
See also pre-logon sequence. 3-27
understanding protection limitations 3-10
installed certificates
viewing 4-3
intermediate certificates 4-7
internal LAN
and NAPT communication 5-9
and static routes 5-9
internal user management 2-8
configuring 2-8
IP addresses
adding on the FirePass controller 8-8
changing for DNS 8-16
changing on the FirePass controller 8-8
configuring for NetBIOS broadcasts 8-23
configuring for the FirePass controller 8-8
configuring NAS IP addresses for RADIUS requests
8-23
configuring overlapping IP address pools 5-12
deleting from the FirePass controller 8-8
IP Group Filters
and options 5-25
understanding 5-25
IPsec VPN clients
and App Tunnels 6-2
J
Java applets
Java plug-ins
and inspectors 3-11
JavaScript
K
Kerberos
See Active Directory.
kernel
and reserved routing tables 8-13
keyboard map
and default 6-28
defined 6-27
keyboard redirection
configuring 6-33
L
LAN
connecting FirePass controller to internal 5-9
connecting FirePass controller to separate 5-10
LDAP
configuring as email address source 7-40
mapping based on group object 2-34
mapping based on user object 2-27, 2-33
mapping groups dynamically 2-32
using for authentication 2-4, 2-51
LDAP authentication
LDAP query
configuring 7-39
legacy host connections
and master group settings 6-29
Index - 7
Index
Legacy Hosts
and Application Access 6-25
and general master group settings 6-29
and supported terminal types 6-25
configuring access to 6-25
configuring mapping 6-27
creating favorites for resource groups 2-67
defining favorites for 6-26
understanding 6-25
license
adding features 8-44
installing 8-44
license request
generating 8-44
licenses
managing 8-43
light mode
See Routing screen modes.
Linux
and supported Network Access features 9-7
and supported platforms for Network Access 9-8
configuring application launch 9-9
installing client on 9-10
load balancing
activating 12-12
and random mode 12-12
deactivating 12-12
local traffic management
described
See also BIG-IP system.
log files
and App Logs report 10-3
and RADIUS 8-56
and shared variables 8-51
and Summary report 10-16
and System Logs reports 10-18
and typical name 8-50
managing 8-49
transferring 8-50
understanding 8-50
understanding format 8-50
logon-denied messages
customizing A-7, A-13
Logons report
and options 10-10
described 10-1
understanding 10-10
logos
customizing webtop to display 8-66
Index - 8
LTM
See BIG-IP system.
M
Mac OS X
Macintosh
and supported Network Access features 9-7
and supported platforms for Network Access 9-8
configuring application launch 9-9
maintenance
performing on the FirePass controller 8-43
Maintenance Console
accessing 8-59
mapping
See also dynamic group mapping.
See group mapping.
mapping tables
adding or modifying 6-28
See also master mapping tables.
See also resource mapping tables.
understanding 6-28
master controllers
See primary controllers.
master group
preserving host names 7-17
master group settings
configuring for App Tunnel webifyer status settings
6-23
configuring for legacy host connections 6-29
configuring for terminal server connections 6-32
configuring Terminal Servers webifyer status in
6-34
for the Legacy Hosts webifyer status 6-29
specifying split tunneling options 6-23
understanding 6-22
master groups
and access control lists 7-16
and authentication settings 2-14
and default 2-14
and general master group settings 6-22
and Group Names 2-11
and group report 10-4
and max concurrent sessions 2-12
and resource groups 2-12
and routing tables 2-12
and signup template 2-12
and users 2-12
and Windows Files 7-36
associating routing tables 5-15
configuring 2-11, 5-15
Index
configuring customized settings for App Tunnels
connections 6-22
configuring for external users 2-6
configuring for internal users 2-8
configuring Network Access settings 5-37
configuring routing for 5-15
converting the authentication method 2-49
creating on the FirePass controller 2-8
defined 2-1
defining 5-16, 5-17
determining authentication method 2-47
exempting from safety checks 3-27
managing 2-13
managing internally 2-8
mapping based on information from LDAP group
object 2-34
mapping based on information from LDAP user
object 2-27, 2-33
mapping based on Windows domain groups 2-30
mapping dynamically based on Active Directory
controller 2-27
mapping dynamically based on Landing URI 2-39
mapping dynamically based on LDAP information
2-32
mapping dynamically based on RADIUS groups 2-39
mapping dynamically based on virtual host 2-42
mapping dynamically based on Windows domain
controller 2-27
populating with users 2-13
settings for App Tunnels 6-22
specifying an authentication method 2-47
using list screen 2-11
master mapping table
defined 2-22
max concurrent sessions
McAfee, and endpoint security 3-8
MD5 signature
and inspectors 3-9
Microsoft Terminal Servers
mini-browsers
See browsers.
minimal content rewriting
configuring 7-10
Mobile E-Mail
and Portal Access
configuring 7-38
configuring LDAP as email address source 7-40
disabling email attachments 7-41
monitoring server 8-62
N
NAPT communication
and routing 5-9
choosing 5-6
enabling 5-8
using to connect to internal LAN 5-9
using to connect to separate network 5-10
NAS IP addresses
for RADIUS requests 8-23
Native RSA authentication
See RSA SecurID authentication server.
NetBIOS broadcasts
and IP address to use 8-23
Network Access
adding group-level packet filtering rules 5-25
and Application Tunnels 6-2
and client customization 5-29
and favorites 5-19
and functionality supported 5-1
and IP Group Filters 5-25
and Linux support 9-7
and Macintosh support 9-7
and point-to-point protocol 5-3
configuration overview 5-6
configuring bitrate evaluator parameters 5-18
configuring favorites for resource groups 2-67
configuring master group settings 5-37
configuring policy-fallback rules 5-26
configuring resource settings 5-19
establishing client connections 9-11
overview 5-1
understanding 5-3
using client applications with 5-4
using Windows power management 5-30
Network Address Port Translation
See NAPT communication.
network configuration settings
and web services 8-2
defined 8-2
maintaining 8-2
network drives
mapping for App Tunnels 6-16
network file shares
mapping App Tunnels for 6-16
network files
configuring access to users 7-35
network packets
capturing 8-61
network resources
controlling access to 3-31
network settings
and NAS IP addresses for RADIUS request 8-23
Network Time Protocol Server
See NTP server.
Index - 9
Index
Norton AntiVirus, and endpoint security 3-8
NTLM
configuring 7-14
NTP server
and best practices for RSA and VASCO
authentication 8-41
specifying for controller 8-41
specifying time zone 8-40
O
OCSP
See Online Certificate Status Protocol.
one-click logon 2-59
Online Certificate Status Protocol
described 4-12
using 4-13
online help 1-15
online updates
See upgrades.
operating system detection
and inspectors 3-9
operating system usage
See Summary reports.
overlapping IP address pools
and special considerations 5-12
configuring 5-12, 5-14
P
password
setting a strong password 2-54
passwordless auto-login
phone browsers
See browsers.
point-to-point protocol (PPP)
policy check messages, configuring 5-30
policy checks
and policy fallback rules 5-26
policy fallback rules
configuring 5-26
port 443
and web services on active controller 11-10
port 80
and web services on active controller 11-11
Portal Access
and App Tunnels 7-1
and client applications 5-4
and default virus scanner 7-48
and features 7-1
and Java applets 13-9
and JavaScript 13-9
Index - 10
and security 7-1
and Windows Files 7-36
blocking SQL injection attacks 7-45
blocking suspicious characters 7-45
configuring access control 7-16
configuring Alternative Host/Port-based bypass
7-13
configuring Clam AntiVirus for automatic update
7-49
configuring Clam AntiVirus for manual update 7-48
configuring minimal content rewriting 7-10
configuring Mobile E-Mail 7-38
configuring SSL injection scanning 7-44
configuring WebAccess ByPass 7-12
defining favorites 7-6
enabling ICAP client 7-48
enabling standalone virus scanner 7-48
excluding sites from XSS scanning 7-44
filtering suspicious characters 7-45
introducing 7-1
protecting against buffer overflow attacks 7-46
scanning for embedded script code 7-43
scanning for suspicious characters 7-43
specifying user-agent strings 7-8
updating virus scanning files 7-48
working with URL variables 7-7
Portal Access access control 8-24
ports
and best practices for specifying 8-6
configuring ports for Synchronization Agent 8-21
specifying for FirePass 1000 8-6, 8-7
specifying for FirePass 4000 8-6
specifying for FirePass 4100 8-6
specifying range for App Tunnels 6-14
post-configuration tasks 11-19
post-logon protection
configuring 3-32
PPP
See point-to-point protocol.
pre-logon sequence
and actions 3-16, 3-19
and Corporate Access Check 3-12
and elements 3-14
and inspector 3-27
and internal structure for an action 3-20
and Java plug-ins 3-11
and protected configurations 3-8, 3-11, 3-15, 3-27,
3-31
and protected resources 3-8
and rule examples 3-23
and rule syntax 3-23
checking for Google Desktop Search A-5
Index
checking operating system for users logging on
A-12
creating 3-16
creating a rule for 3-24
creating subsequences 3-25
creating to inspect client systems for a protected
workspace 3-16
defining rules and actions 3-23
A-2
described 3-11
understanding 3-13
understanding the flow 3-12
pre-logon sequence elements 3-14
pre-logon sequence processing
primary controllers
defined 12-1
synchronizing 12-3
primary node
See primary controllers.
protected configuration
and extra policy of protection 2-57
described 3-16
protected configurations
and associated protection criteria 3-27
and best practices 3-8, 3-31
and risk factors 3-27
3-27
assigning 3-19
assigning to a favorite 3-19
creating 3-18
defined 3-27
described 3-8, 3-11, 3-31
implementing access control example 3-32
using data collected 3-18
protected workspace
and creating a pre-logon sequence for 3-16
protection assignment
understanding 3-32
protection limitations 3-10
protection options
understanding 3-8
proxies
and HTTP and SSL 8-39
configuring options 7-34
locating conflicts 7-19
requirements for FirePass controller 7-34
specifying HTTP or SSL 8-40
specifying settings 7-34
R
RADIUS
and NAS IP addresses 8-23
and RADIUS accounting server 8-56
configuring accounting for 8-56
RADIUS server
setting up 2-49, 2-50
RADIUS server query
using for authentication 2-4
random load balancing mode 12-12
realm administrators
adding 8-29
deleting 8-30
overview 8-27
realm-based operations
and tasks 8-27
realm-level
configuring access for a group 8-28
configuring access to features 8-28
configuring administrator access for users 8-29
redundant pair
definition 11-1
redundant system
accessing standby controller 11-18
and shared IP address 11-7
configuring heartbeat synchronization for active
controller 11-14
controller 11-17
configuring manual failover 11-20
configuring standby controller 11-15, 11-16
configuring standby controller with self IP address
11-16
configuring synchronization service on active
controller 11-12
configuring web services on active controller 11-10
enabling failover on active controller 11-7
heartbeat 11-13
introducing failover member 11-5
overview 11-1
reviewing active failover member configuration
11-2
reviewing standby failover member configuration
11-4
verifying controller identity 11-20
verifying failover configuration 11-19
redundant system heartbeat 11-13
regex
See standard regular expression.
release notes 1-15
Index - 11
Index
remote user access
using Application Access 6-1
remote-access technologies 1-1
reports
and Logons report 10-10
and Server access log (https) log 10-8
and Server error log (http) log 10-7
and Sessions report 10-12, 10-13
and SSL engine log 10-9
and System Logs report 10-18
and the App Logs report 10-2
and Today’s sessions log 10-14
overview 10-1
saving 10-1
requirements for cluster setup 12-2
resource groups
applying group-level packet filtering rules 5-25
assigning a resource groups 2-65
creating App Tunnel favorites 2-67
creating Legacy Host favorites 2-67
creating Network Access favorites 2-67
creating Terminal Server favorites 2-67
creating Web Application favorites 2-66
creating Windows Files favorites 2-66
editing 2-66
mapping dynamically 2-65
mapping dynamically based on Active Directory
controllers 2-27
mapping dynamically based on Windows domain
controllers 2-27
mapping statically 2-65
understanding 2-1
resource mapping tables
defined 2-22
resource protection
and levels of 3-31
understanding protection assignment 3-32
resources
and IP Group Filters 5-25
and users accessing 3-15
protecting 3-31
risk-factor/safety feature associations table 3-27
routing
configuring for master groups 5-15
understanding 5-9
routing rules
adding and editing in advanced mode 8-15
configuring 5-17
Index - 12
Routing screen mode
adding a single route in advanced mode 8-12
Routing screen modes 8-9
adding a single route in light mode 8-9
adding multiple routes in advanced mode 8-13
adding multiple routes in light mode 8-11
adding routing rules routes in advanced mode 8-15
deleting routing tables in advanced mode 8-13
editing multiple routes in advanced mode 8-13
routing tables
and kernel 8-13
associating with master groups 5-15
configuring in advanced mode 8-13
configuring in light mode 8-9
RSA authentication
RSA SecurID authentication server
configuring 8-33
configuring FirePass controller as agent host 8-34
RSA SecurID technology
using on FirePass controllers 8-37
rule syntax
and using 3-23
rules
and actions in pre-logon sequence 3-19
and examples 3-23
and fallback 3-20
and policy fallback 5-26
and session variables 3-24
and syntax elements 3-23
checking for Google Desktop Search A-5
creating a pre-logon sequence rule 3-24
See also sequence rules.
S
saving reports 10-1
scans
and inspectors 3-9
scenarios
creating a subsequence mapping to several condition
actions A-16
A-2
denying access to Windows users A-10
requiring Windows users to log on with virtual
keyboard A-14
secondary node
See secondary controllers.
secure remote access 1-1
security
and cross site scripting 7-42
Index
and ICAP 7-48
3-27
and self-signed certificates 4-7
blocking SQL injection attacks 7-45
blocking suspicious characters 7-45
7-49
configuring email for alerts and notifications 8-31
configuring SSL injection scanning 7-44
excluding sites from SQL injection scanning 7-46
excluding sites from XSS scanning 7-44
filtering suspicious characters 7-45
for user accounts 2-3
implementing client system checking 3-15
protecting against buffer overflow attacks 7-46
restricting input to an allowed character set 7-43
scanning for embedded script code 7-43
scanning for suspicious characters 7-43
supported by FirePass 1-5
SED scripts
adding 7-20
and examples 7-21, 7-22
troubleshooting failures 7-23
using to fix HTML syntax errors 13-8
self-signed certificates
and cert.zip file 4-6
installing 4-6
understanding files generated by 4-6
self-signed server certificates, using 4-2
sequence rules
defining 3-23
using session variables 3-24
server
monitoring, statistics, health 8-62
Server access log (http) log
and extra-access_log 10-7
understanding 10-8
server certificates
and default 4-3
installing 4-6, 4-9
See also certificates.
See also self-signed server certificates.
viewing 4-3
Server error log (http) log
understanding 10-7
Server error log (https) log
and https.extra-error_log file 10-9
understanding 10-9
services
restarting 8-57
Session summary logs
understanding 10-15
session updates
preventing 7-26
Sessions report
and options 10-12
described 10-1
using 10-12
viewing 10-12
sessions variables
described 3-24
shared files
configuring access to users 7-35
shared IP addresses
and failover pair 11-7
signed server certificate
See self-signed server certificate. 4-2
signup templates
using to add users 2-14
using when managing users locally 2-14
Simple Mail Transfer Protocol
See SMTP.
Simple Network Management Protocol
See SNMP.
single-click logon
See one-click logon.
slave controller
See secondary controller.
SMTP email server
configuring for FirePass controller 8-37
SNMP agent
configuring for FirePass controller 8-38
SNMP agent, using 8-38
software upgrades
See upgrades.
software version, finding 1-4
split tunneling
configuring for Portal Access 7-15
defined 5-20
setting for Dynamic Tunnels 6-23
SQL injection
blocking attacks 7-45
excluding sites from scan 7-46
SQL injection scanning
configuring 7-44
Index - 13
Index
SSL engine log
understanding 10-9
SSL processing
offloading to a BIG-IP system 8-22
SSL proxies
See also proxies.
using 8-39
SSL server certificates
associating with a web service 4-8
See also security certificates.
understanding 4-1
ssl_engine log
See SSL engine log.
standalone VPN Client
installing 9-5
supported features 9-5
standalone VPN client
using to remotely access corporate LAN 9-5
standard regular expression
and blocking suspicious web site input 7-46
standby controller 11-1
accessing 11-18
configuring 11-15
controller 11-17
enabling failover 11-16
See also failover.
verifying identity 11-20
standby failover member 11-4
static host names 8-17
adding 8-18
static host options 5-22
static resource groups
defined 2-65
static routes
using to connect to internal VLAN 5-9
using to connect to separate network 5-10
statistics
displaying 8-62
for clustered controllers 12-15
statistics for server, viewing 8-62
stratefy for configuring failover 11-5
streaming video
and Flash rewriting 7-27
strong password
and LDAP directory 2-54
described 2-54
stylistic conventions 1-12
subnets
configuring for the FirePass controller 8-8
Index - 14
subsequences
creating to map to several conditions A-16
described 3-25
Summary report
described 10-1
Summary reports
activity 10-16
and browser type usage 10-16
and operating system usage 10-16
and options 10-16
using 10-16
viewing 10-16
superuser
and tasks 8-27
support
and Ask F5 1-15
contacting F5 Networks Technical Support 1-15
emailing collected data 8-60
suspicious characters
blocking 7-45
filtering 7-45
synchronization
configuring addresses and ports 8-18
described 12-1
Synchronization Agent
configuring 8-18
configuring ports for 8-21
synchronization service
and requirements 12-7
configuring on active controller 11-12
system health
configuring email notification 8-64
viewing 8-63
system load
monitoring 8-65
System Logs report
described 10-1
System Logs reports
and options 10-18
using 10-18
system, redundant 11-1
T
Technical Support at F5, contacting 1-15
templates
signup 2-14
terminal server connections
configuring master group settings for 6-32
understanding general master group settings for
6-32
Index
Terminal Servers
and application access 2-64
configuring favorites 6-30
configuring webifyer status in 6-34
terminals
supported by Legacy Hosts feature 6-25
time and date format, specifying 8-41
time and time zone
specifying for NTP server 8-40
Today’s sessions logs
understanding 10-14
token-based authentication
See two-factor authentication. 1-1
tools
for troubleshooting 8-59
troubleshooting
and Java applet code 13-9
and JavaScript 13-9
and tools 8-59
capturing network packets 8-61
identifying problems with Web Applications engine
trace 13-6
using Web Applications engine trace for 8-62
troubleshooting tools
accessing Maintenance Console 8-59
using the F5 Support Diagnostic tool 8-60
trusted certificates, adding your own 9-4
two-factor authentication 1-6
and features for FirePass controller 1-1
U
UDP application traffic
and App Tunnels 6-2
unsuccessful attempts to log on, reports 10-10
updates
See upgrades.
upgrades
and FirePass controller 8-46
backing up and restoring 8-45
ending user sessions 8-47
from a downloaded file 8-47
from the command line 8-48
getting online 8-48
locking user sessions 8-47
preparing for 8-47
using a browser 8-47
URL variables
user accounts
assigning administrative privileges 8-29
configuring signup templates 2-14
searching for 2-15
working with 2-3
user activity reports 10-16
user agent strings
configuring per host 7-25
user authentication with client certificates 2-59
user groups
determining requirements 2-9
user sessions
ending 8-47
locking 8-47
user sessions, report 10-12
user-agent strings
specifying for Portal Access 7-8
user-group distribution report
See Group report.
users
accessing network remotely 6-1
accessing resources 3-15
activating 2-15
and best practices for managing 2-3
and master groups 2-9, 2-12
associating with a resource group 2-65
authenticating externally 2-6
configuring user access to resources 2-15
creating 2-15
deactivating 2-15
deleting 2-15
exporting user information to a file 2-15
importing groups of users 2-15
maintaining on an external server 2-6
managing in master groups 2-8
managing locally 2-15
monitoring activity 10-3
moving to another group 2-15
V
valid status, for certificates 4-3
VASCO authentication
version of software, finding 1-4
virtual IP addresses
viruses
7-49
Index - 15
Index
visual policy editor
and subsequences 3-25
described 3-11
understanding 3-12
VLAN settings
configuring 8-7
segmenting computers 8-7
VNC servers
W
web applications
and special access mode 7-27
cleaning content 7-24
configuring 7-4
configuring content processing for 7-18
troubleshooting failures 7-23
Web Applications access control 8-24
Web Applications content cleaning feature
fixing HTML syntax errors 13-7
Web Applications engine trace
analyzing traces 13-5
and dynamic caching 13-2
and HTML syntax errors 13-6
and Internet Explorer 13-5
and when to use 13-1
comparing trace file content 13-5
fixing common problems 13-6
overview 8-62, 13-1
sending files to F5 Networks Technical Support
13-2
understanding files 13-3
using 13-2
using with Web Applications engine trace 13-5
Web browser definitions, adding 8-32
web services
and classes of operation 8-18
and codes 8-19
and network configuration settings 8-2
and synchronization agent 11-12
associating with an SSL server certificate 4-8
configuring a service 8-20
configuring as synchronization agent 11-12
configuring on port 80 for active controller 11-11
configuring port 443 for active controller 11-10
understanding configuration options 8-18
Index - 16
WebAccess Bypass
configuring 7-12
webifyer Glossary-4
webifyers
customizing available features 8-66
webtop
and favorites 2-1
changing where Mobile E-Mail links appear 7-41
configuring intranet options 7-32
customizing 8-66
Windows Active Directory server query
Windows domain
mapping based on Windows domain 2-30
mapping groups dynamically 2-27
Windows domain server
configuring for authentication 2-54
using query for authentication 2-3, 2-4
Windows Files
configuring master group settings for 7-36
providing access to users 7-35
Windows key combinations
configuring keyboard redirection 6-33
Windows power management
configuring Network Access for 5-30
Windows users
denying access A-10
requiring users to log on with virtual keyboard A-14
Windows XP desktops
X
XSS scanning
excluding sites from 7-44
XSS scripting
See cross site scripting.
Z
zero-click logon 2-59

FirePass Controller Handbook

Transcription

Similar documents

DSC100

Series 965 Retrofit Guide

Always in control, no matter where you are

control 2013 - Inspec Inc.

AGE DEFY BALANCING ADDITIVES

game console cd/mp3/Game Cube® laptop/soundcard

SDN-PANDA: Software-Defined Network Platform for ANomaly

A Magical A - PlayStation