Citrix Access Gateway Standard Edition Administrator s Guide. Citrix Access Gateway 4.6, Standard Edition Model 2000 Series

Transcription

1 Citrix Access Gateway Standard Edition Administrator s Guide Citrix Access Gateway 4.6, Standard Edition Model 2000 Series

2 Copyright and Trademark Notice Use of the product documented in this guide is subject to your prior acceptance of the End User License Agreement. A printable copy of the End User License Agreement is included with the installation media. Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Citrix Systems, Inc Citrix Systems, Inc. All rights reserved.. Citrix and ICA (Independent Computing Architecture) are registered trademarks and Citrix Access Gateway is a trademark of Citrix Systems, Inc. in the United States and other countries. RSA Encryption RSA Security Inc., All Rights Reserved. This product includes software developed by Expat XML Parser This product includes software developed by Internet Systems Consortium This product includes software developed by Free Software Foundation, Inc This product includes software developed by the Independent JPEG Group This product includes software developed by libpng.org This product includes software developed by the OpenLDAP Foundation This product includes software developed by the OpenSSL Project This product includes zlib software developed by Jean-loup Gailly and Mark Adler This product includes software developed by SilverStripe Limited Licensing: Portions of this documentation that relate to Globetrotter, Macrovision, and FLEXlm are copyright Macrovision Corporation and/or Macrovision Europe Ltd. All rights reserved. Apache Software Foundation Copyright 2009 Citrix System, Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Trademark Acknowledgements Adobe, Acrobat, and PostScript are trademarks or registered trademarks of Adobe Systems Incorporated in the U.S. and/or other countries. Java, Sun, and SunOS are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Solaris is a registered trademark of Sun Microsystems, Inc. Sun Microsystems, Inc has not tested or approved this product. Portions of this software are based in part on the work of the Independent JPEG Group. Portions of this software contain imaging code owned and copyrighted by Pegasus Imaging Corporation, Tampa, FL. All rights reserved. Macromedia and Flash are trademarks or registered trademarks of Macromedia, Inc. in the United States and/or other countries. Microsoft, MS-DOS, Windows, Windows Media, Windows Server, Windows NT, Win32, Outlook, ActiveX, Active Directory, and DirectShow are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Netscape and Netscape Navigator are registered trademarks of Netscape Communications Corp. in the U.S. and other countries. Licensing: Globetrotter, Macrovision, and FLEXlm are trademarks and/or registered trademarks of Macrovision Corporation. All other trademarks and registered trademarks are the property of their respective owners. Document Code: March 20, 2009 (KKW)

3 CONTENTS Contents Chapter 1 Chapter 2 Chapter 3 Introduction How to Use This Guide Document Conventions Getting Service and Support Subscription Advantage Knowledge Center Alerts Education and Training Terminology Changes Introducing Citrix Access Gateway Access Gateway Technologies Access Gateway Modes of Operation Functions of the Access Gateway New Features in this Release Changes to Access Gateway Functions Planning Your Deployment Deploying the Access Gateway Access Gateway in the Network DMZ Installing the Access Gateway in the DMZ Access Gateway Connectivity in the DMZ Access Gateway in a Secure Network Access Gateway Connectivity in a Secure Network Planning for Security with the Access Gateway Configuring Secure Certificate Management Authentication Support Deploying the Access Gateway with Citrix XenApp or Citrix XenDesktop Deploying the Access Gateway in a Double-Hop DMZ Deploying Additional Appliances for Load Balancing and Failover Deploying Access Gateway Appliances behind a Load Balancer

4 4 Citrix Access Gateway Standard Edition Administrator s Guide Deploying Access Gateway Advanced Edition Configuring Multiple Servers in an Access Server Farm Chapter 4 Chapter 5 Installing the Access Gateway for the First Time Getting Ready to Install the Access Gateway Materials and Information Needed for Installation Setting Up the Access Gateway Hardware Configuring TCP/IP Settings for the Access Gateway Configuring TCP/IP Settings Using the Serial Console Configuring TCP/IP Settings Using Network Cables Configuring TCP/IP Settings for a Double-Hop Deployment Restarting the Access Gateway Configuring the Access Gateway for Your Network Environment Installing Licenses Access Gateway License Types Finding Licensing Statistics Obtaining Your License Files Configuring Licenses for Multiple Appliances Downloading License Logs Refreshing Licensing Information Updating Existing Licenses Licensing Grace Period Testing Your License Installation Creating and Installing Certificates Overview of the Certificate Signing Request Installing a Certificate and Private Key from a Windows Computer Installing Root Certificates on the Access Gateway Installing Multiple Root Certificates Configuring Additional Network Settings Configuring Name Service Providers Editing the HOSTS File Configuring Dynamic and Static Routes Configuring the Date and Time on the Access Gateway Configuring a Network Time Protocol Server Using the Default Portal Page Configuring Network Access

5 5 Citrix Access Gateway Standard Edition Administrator s Guide Chapter 6 Chapter 7 Configuring Authentication and Authorization Choosing When to Configure Authentication on the Access Gateway Configuring Authentication on the Access Gateway Configuring the Default Realm Creating Additional Realms Configuring Local Authentication Configuring Local Users Adding Users to Multiple Groups Changing Password for Users Configuring LDAP Authentication and Authorization Configuring LDAP Authorization LDAP Authorization Group Attribute Fields Using Certificates for Secure LDAP Connections Determining Attributes in your LDAP Directory Configuring RADIUS Authentication and Authorization RADIUS Authorization Choosing RADIUS Authentication Protocols Configuring RSA SecurID Authentication Configuring RSA Settings for a Cluster Resetting the Node Secret Configuring Secure Computing SafeWord Authentication Configuring SafeWord Settings on the Access Gateway Configuring Authorization with SafeWord Configuring Gemalto Protiva Authentication Configuring Gemalto Protiva Settings Configuring NTLM Authentication and Authorization Configuring NTLM Authorization Configuring Advanced Options for Authentication Configuring the User Name Prefix Configuring Authentication to use One-Time Passwords Hiding the Verify Response Prompt Configuring Double-Source Authentication Changing Password Labels Configuring Network Access and Group Resources Configuring Network Routing Providing Network Access to Users Enabling Split Tunneling and Accessible Networks

6 6 Citrix Access Gateway Standard Edition Administrator s Guide Configuring User Groups Configuring Access Control Lists Creating Local User Groups Configuring Resource Groups Creating User Groups Default Group Properties Configuring Resources for a User Group Configuring User Membership in Multiple Groups Configuring Network Resources Allowing and Denying Network Resources and Application Policies Setting Application Policies Configuring Endpoint Policies and Resources Building an Endpoint Policy for a Group Setting the Priority of Groups Configuring Pre-Authentication Policies Configuring the Access Gateway to work with Citrix Branch Repeater Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in System Requirements Operating Systems Web Browsers How User Connections Work Establishing the Secure Tunnel Tunneling Private Network Traffic over Secure Connections Terminating the Secure Tunnel and Returning Packets to the Client Supporting the Access Gateway Plug-in Configuring Proxy Servers for the Access Gateway Plug-in Installing the Access Gateway Plug-in Using the Microsoft Installer (MSI) Package 122 Installing the MSI Package Using Group Policy Installing the MSI Package Using Advertisement Configuring Single Sign-on with Windows Operating System Connecting with Earlier Versions of the Access Gateway Plug-in Upgrading Earlier Versions of the Access Gateway Plug-in Connecting Using a Web Address Logging on Using the Access Gateway Plug-in Installing the Access Gateway Plug-in for Linux Configuring Authentication Requirements after Network Interruption

7 7 Citrix Access Gateway Standard Edition Administrator s Guide Configuring Other Group Properties Enabling IP Pooling Enabling Split DNS Enabling Internal Failover Enabling Domain Logon Scripts Enabling Access Gateway Plug-in Session Time-Outs Configuring Web Session Time-Outs Requiring Client Certificates for Authentication Defining Client Certificate Criteria Using Client Certificates with Access Gateway Advanced Edition Installing Root Certificates Obtaining a Root Certificate from a Certificate Authority Installing Root Certificates on a Client Device Selecting an Encryption Type for Client Connections Chapter 9 Chapter 10 Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in Configuring Access Gateway Logon Pages Enabling Logon Page Authentication Customizing the Logon Page Access Gateway Portal Page Templates Downloading and Working with Portal Page Templates Installing Custom Portal Page Files Choosing a Portal Page for a Group Configuring a Portal Page with Multiple Logon Options Logging On When Pre-Authentication Policies are Configured Maintaining the Access Gateway Access Gateway Administration Tools The Administration Tool The Administration Portal Upgrading the Access Gateway Software Installing the Software Upgrade Reinstalling the Access Gateway Software Reinstalling the Software on the Model Reinstalling the Software on the Model Saving and Restoring the Access Gateway Configuration Restarting and Shutting Down the Access Gateway Restarting the Access Gateway Shutting Down the Access Gateway

8 8 Citrix Access Gateway Standard Edition Administrator s Guide Initializing the Access Gateway Allowing ICMP Traffic Configuring Third-Party Personal Firewalls McAfee Personal Firewall Plus Norton Personal Firewall Sygate Personal Firewall (Free and Pro Versions) Tiny Personal Firewall ZoneAlarm Pro Chapter 11 Appendix A Appendix B Installing Additional Access Gateway Appliances Creating a Cluster of Access Gateway Appliances Configuring Multiple Appliances to Use a Load Balancer Configuring Load Balancing Configuring Access Gateway Appliances to Operate behind a Load Balancer Configuring Load Balancing with Advanced Access Control Configuring Access Gateway Failover Monitoring the Access Gateway Viewing and Downloading System Message Logs Viewing Access Gateway Plug-in Connection Logs Forwarding System Messages to a Syslog Server Enabling and Viewing SNMP Logs Multi Router Traffic Grapher Example Viewing System Statistics Monitoring Access Gateway Operations Securing Connections with Digital Certificates Introduction to Security Protocols, Cryptography, and Digital Certificates Introduction to Security Protocols Introduction to Cryptography Digital Certificates and Certificate Authorities Getting Certificates If Your Organization Is its Own Certificate Authority If Your Organization Is not its Own Certificate Authority Getting Server Certificates Digital Certificates and Access Gateway Operation

9 9 Citrix Access Gateway Standard Edition Administrator s Guide Using Windows Certificates Unencrypting the Private Key Converting to a PEM-Formatted Certificate Combining the Private Key with the Signed Certificate Generating Trusted Certificates for Multiple Levels Requiring Certificates for Internal Connections Using Wildcard Certificates Appendix C Appendix D Examples of Configuring Network Access Configuration Examples Scenario for Configuring LDAP Authentication and Authorization Preparing for the LDAP Authentication and Authorization Configuration Configuring the Access Gateway to Support Access to the Internal Network Resources Scenario for Creating Guest Accounts Using the Local Users List Creating a Guest User Authentication Realm Creating Local Users Creating and Assigning a Network Resource to the Default User Group Scenario for Configuring Local Authorization for Local Users Troubleshooting the Access Gateway Troubleshooting Web Interface Connections Web Interface Appears without Typing Credentials Applications do not Appear after Logging On Users are Sent to a Logon Page that Asks to Start the Access Gateway Plug-in. 222

10 10 Citrix Access Gateway Standard Edition Administrator s Guide Other Issues License File Does not Match Access Gateway Defining Accessible Networks Subnet Restriction Virtualization Software ICMP Transmissions Ping Command LDAP Authentication Endpoint Policies Network Resources Internal Failover Certificate Signing Certificate Revocation Lists Network Messages to Non-Existent IPs The Access Gateway Does not Start and the Serial Console Is Blank The Administration Tool Is Inaccessible Devices Cannot Communicate with the Access Gateway Using Ctrl-Alt-Delete to Restart the Access Gateway Fails SSL Version 2 Sessions and Multilevel Certificate Chains H.323 Protocol Certificates Using 512-Bit Keypairs Unable to Restrict Drive Mapping with an Application Policy Citrix Access Gateway Plug-in Access Gateway Plug-in Connections with Windows XP DNS Name Resolution Using Named Service Providers Auto-Update Feature Client Connections from a Windows Server NTLM Authentication WINS Entries Using Third-Party Client Software

11 CHAPTER 1 Introduction How to Use This Guide This user guide is intended for system administrators responsible for installing and configuring the Access Gateway. This document assumes that the Access Gateway is connected to an existing network and that the administrator has experience configuring that network The configuration steps in this document assume that the Access Gateway is deployed as a standalone appliance and that users connect directly to the Access Gateway. This user guide also has information for configuring the Access Gateway to work with Access Gateway Advanced Edition. For more information, see Deploying Access Gateway Advanced Edition on page 26. Document Conventions Access Gateway documentation uses the following typographic conventions for menus, commands, keyboard keys, and items in the program interface: Convention Boldface Italics %SystemRoot% Monospace Meaning Commands, names of interface items such as text boxes, option buttons, and user input. Placeholders for information or parameters that you provide. For example, filename in a procedure means you type the actual name of a file. Italics also are used for new terms and the titles of books. The Windows system directory, which can be WTSRV, WINNT, WINDOWS, or other name you specify when you install Windows. Text displayed in a text file. { braces } A series of items, one of which is required in command statements. For example, { yes no } means you must type yes or no. Do not type the braces themselves.

12 12 Citrix Access Gateway Standard Edition Administrator s Guide Convention [ brackets ] Optional items in command statements. For example, [/ping] means that you can type /ping with the command. Do not type the brackets themselves. (vertical bar) A separator between items in braces or brackets in command statements. For example, { /hold /release /delete } means you type /hold or /release or /delete. (ellipsis) Getting Service and Support Citrix provides technical support primarily through the Citrix Solutions Network (CSN). Our CSN partners are trained and authorized to provide a high level of support to our customers. Contact your supplier for first-line support or check for your nearest CSN partner at In addition to the CSN channel program, Citrix offers a variety of self-service, Web-based technical support tools from its Knowledge Center at Knowledge Center features include: A knowledge base containing thousands of technical solutions to support your Citrix environment An online product documentation library Interactive support forums for every Citrix product Access to the latest hotfixes and service packs Security bulletins Meaning You can repeat the previous item or items in command statements. For example, /route:devicename[, ] means you can type additional devicenames separated by commas. Online problem reporting and tracking (for organizations with valid support contracts) Another source of support, Citrix Preferred Support Services, provides a range of options that allows you to customize the level and type of support for your organization s Citrix products.

13 Chapter 1 Introduction 13 Subscription Advantage Your product includes a one-year membership in the Subscription Advantage program. The Citrix Subscription Advantage program gives you an easy way to stay current with the latest software version and information for your Citrix products. Not only do you get automatic access to download the latest feature releases, software upgrades, and enhancements that become available during the term of your membership, you also get priority access to important Citrix technology information. You can find more information on the Citrix Web site at On the home page, click Support > Subscription Advantage. You can also contact your sales representative, Citrix Customer Care, or a member of the Citrix Solutions Advisors program for more information. Knowledge Center Alerts The Citrix Knowledge Center allows you to configure alerts, which notify you when the topic you are interested in is updated. You can set an alert on product categories. When there are updates to the product, you are notified of the update. To set up an alert, log on to the Citrix Support Web site at After you are logged on, under Products, select a product. Under Alerts, click Add to your Alerts. To remove an alert, go to the Knowledge Center product and click Remove from your Alerts. Education and Training Citrix offers a variety of instructor-led training and Web-based training solutions. Instructor-led courses are offered through Citrix Authorized Learning Centers (CALCs). CALCs provide high-quality classroom learning using professional courseware developed by Citrix. Many of these courses lead to certification. Web-based training courses are available through CALCs, resellers, and from the Citrix Web site. Information about programs and courseware for Citrix training and certification is available from

14 14 Citrix Access Gateway Standard Edition Administrator s Guide Terminology Changes There are several name changes you need to be aware of for client software and Citrix product names. The following list contains updated terminology used in this document. From Access Gateway with Advanced Access Control Access Suite Console Secure Access Client Citrix Presentation Server Citrix Presentation Server Clients Citrix Presentation Server Console Web Client Program Neighborhood Agent Citrix WANScaler WANScaler Client To Access Gateway Advanced Edition Access Management Console Access Gateway Plug-in Citrix XenApp Citrix XenApp Plug-ins Citrix XenApp Configuration Citrix XenApp Web Plug-in Citrix XenApp (plug-in) Citrix Branch Repeater Repeater Plug-in Related Documentation For additional information about the Access Gateway, refer to the following guides: Getting Started with Citrix Access Gateway Standard Edition Citrix Access Gateway Standard Edition Pre-Installation Checklist Citrix Access Gateway Standard Edition Integration Guide with Citrix XenApp and Citrix XenDesktop Citrix Access Gateway Standard Edition Readme

15 CHAPTER 2 Introducing Citrix Access Gateway Citrix Access Gateway is a secure application access solution that provides administrators granular application-level policy and action controls to secure access to applications and data while allowing users to work from anywhere. It gives IT administrators a single point of control and tools to help ensure compliance with regulations and the highest levels of information security across and outside the enterprise. At the same time, it empowers users with a single point of access optimized for roles, devices, and networks to the enterprise applications and data they need. This unique combination of capabilities helps maximize the productivity of today s mobile workforce. In This Chapter Access Gateway Technologies Access Gateway Modes of Operation Access Gateway Technologies The Access Gateway is quick and easy to deploy and simple to administer. The most typical deployment configuration is to locate the Access Gateway behind your firewall or in the demilitarized zone (DMZ). More complex deployments, such as with a server load balancer or in a double-hop DMZ, are also supported. The first time the Access Gateway is started, use the Access Gateway Administration Tool to configure the basic settings that are specific to your internal network, such as the IP address, subnet mask, default gateway IP address, and DNS address. After you complete the basic connection, you then configure the settings specific to Access Gateway operation, such as the options for authentication, authorization, and group-based access control, endpoint resources and polices, portal pages, and IP pools. For more information about installing the Access Gateway, see Getting Started with Citrix Access Gateway Standard Edition or Installing the Access Gateway for the First Time on page 29.

16 16 Citrix Access Gateway Standard Edition Administrator s Guide Access Gateway Modes of Operation The Access Gateway can be used in one of three ways: Connections through the appliance only. In this scenario, the Access Gateway is installed as a standalone appliance in the DMZ. Users connect directly to the Access Gateway using Citrix Access Gateway Plug-in and then have access to network resources, such as and Web servers. Connections using the Web Interface, Citrix XenApp or Citrix XenDesktop. In this scenario, users log on to the Web Interface and then are connected to their applications on XenApp or published desktops on XenDesktop. Depending on how the Access Gateway is deployed with XenApp, users can connect with just Citrix XenApp Plug-ins (the new name for Citrix Presentation Server Clients), Access Gateway Plug-in, or have simultaneous connections using both plug-ins. Users connect to published desktops using Citrix Desktop Receiver. For more information, see Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop. Note: Installation of either the Desktop Receiver or the Desktop Receiver Embedded Edition on the same computer as XenApp plug-ins (client-side software for Citrix XenApp) is not supported. If you want your users to be able to access both virtual desktops and virtual applications from the same computer, Citrix recommends installing XenApp plug-ins on the virtual desktops that you create with XenDesktop. This allows your virtual desktops to receive virtual applications. Connections using Access Gateway Advanced Edition. In this scenario, the Access Gateway is installed in the DMZ. Initial TCP/IP settings for the appliance are configured during installation of the appliance. Advanced settings to manage the Access Gateway are configured using the Access Management Console included with Access Gateway Advanced Edition. For more information, see Deploying Access Gateway Advanced Edition on page 26 or the Citrix Access Gateway Advanced Edition Administrator s Guide. Functions of the Access Gateway The Access Gateway performs the following functions: Authentication Termination of encrypted sessions

17 Chapter 2 Introducing Citrix Access Gateway 17 Access control (based on permissions) Data traffic relay (when the first three functions are met) As a standalone appliance in the DMZ, the Access Gateway operates as follows: A remote user downloads the Access Gateway Plug-in by connecting to a secure Web address and providing authentication credentials. After downloading the Access Gateway Plug-in, the user logs on. When the user successfully authenticates, the Access Gateway establishes a secure tunnel. As the remote user attempts to access network resources across the VPN tunnel, the Access Gateway Plug-in encrypts all network traffic destined for the organization s intranet and forwards the packets to the Access Gateway. The Access Gateway terminates the SSL tunnel, accepts any incoming traffic destined for the private network, and forwards the traffic to the private network. The Access Gateway sends traffic back to the remote computer over a secure tunnel. New Features in this Release This release of Access Gateway Standard Edition includes the following new features: New Operating System. The operating system on the Access Gateway is updated. Important: With this update, upgrading from earlier versions of the Access Gateway is not supported. You must perform a clean installation of Version 4.6 on the Access Gateway appliance. For more information, see Reinstalling the Access Gateway Software on page 158. Improved Management of the Access Gateway. The Administration Desktop is incorporated into the Administration Tool, allowing easier and faster monitoring of client connections. Support for Citrix XenDesktop. You can configure the Access Gateway to allow users to connect to published desktops. You configure the Access Gateway the same way as you would for Citrix XenApp, providing the Web Interface information configured on XenDesktop. For more information, see the Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop.

18 18 Citrix Access Gateway Standard Edition Administrator s Guide Support for Gemalto Protiva Authentication. You can configure an authentication realm to support Gemalto Protiva authentication using RADIUS-based authentication. Users log on using a code provided by a Gemalto token. New Access Gateway Plug-in MSI Package. Allows for centralized management and policy-based distribution of the Access Gateway Plug-in. Updated Access Gateway Plug-in for Linux. The Access Gateway Plugin for Linux allows connections to the Access Gateway from any supported Linux-based client device. The plug-in supports Linux kernel 2.6.x. Support for XenDesktop Connection Licenses. You can install license files that only allow connections to Citrix XenDesktop. When users connect, they can only establish the session using the Citrix Desktop Receiver. Connections using the Access Gateway Plug-in are prevented. XenDesktop Connection licenses are included with Citrix XenDesktop Standard, Advanced and Enterprise editions as of June XenDesktop Platinum Edition includes the Access Gateway Universal license, which enables all Access Gateway features. Administration Tool Backward Compatibility. When you install the Administration Tool for Access Gateway Standard Edition Version 4.6 and you have earlier versions of the appliance installed in your network, the Version 4.6 Administration Tool allows you to configure settings on the earlier version of the appliance. Changes to Access Gateway Functions The following Access Gateway features are removed from the Access Gateway: Kiosk mode Desktop sharing Administration Desktop and Real-Time Monitor

19 CHAPTER 3 Planning Your Deployment This chapter discusses deployment scenarios for the Access Gateway. You can deploy the Access Gateway at the perimeter of your organization s internal network (or intranet) to provide a secure single point-of-access to the servers, applications, and other network resources residing in the internal network. All remote users must connect to the Access Gateway before they can access any resources on the internal network. This section also discusses deploying the Access Gateway with Citrix XenApp or Citrix XenDesktop. If your deployment includes Citrix XenApp, you can deploy the Access Gateway in a single-hop or double-hop DMZ configuration. A doublehop deployment is not supported with Citrix XenDesktop. For more information about deploying the Access Gateway with a server farm, see the Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop. In This Chapter Deploying the Access Gateway Access Gateway in the Network DMZ Access Gateway in a Secure Network Planning for Security with the Access Gateway Deploying the Access Gateway with Citrix XenApp or Citrix XenDesktop Deploying the Access Gateway in a Double-Hop DMZ Deploying Additional Appliances for Load Balancing and Failover Deploying Access Gateway Advanced Edition Deploying the Access Gateway This section discusses the following Access Gateway deployments: Deploying the Access Gateway in the network demilitarized zone (DMZ)

20 20 Citrix Access Gateway Standard Edition Administrator s Guide Deploying the Access Gateway in a secure network that does not have a DMZ Deploying additional Access Gateway appliances to support load balancing and failover Access Gateway in the Network DMZ Many organizations protect their internal network with a DMZ. A DMZ is a subnet that lies between an organization s secure internal network and the Internet (or any external network). When the Access Gateway is deployed in the DMZ, users access it using Citrix Access Gateway Plug-in or Citrix XenApp Plug-ins (the new name for Citrix Presentation Server Clients). Access Gateway deployed in the DMZ Installing the Access Gateway in the DMZ In this configuration, you install the Access Gateway in the DMZ and configure it to connect to both the Internet and the internal network. Follow the instructions in Installing the Access Gateway for the First Time on page 29 to perform installation and configuration.

21 Chapter 3 Planning Your Deployment 21 Access Gateway Connectivity in the DMZ When you deploy the Access Gateway in the DMZ, client connections must traverse the first firewall to connect to the Access Gateway. By default, connections use Secure Sockets Layer (SSL) on port 443 to establish this connection. To support this connectivity, you must allow SSL on port 443 through the first firewall. Note: You can change the port client devices use to connect to the Access Gateway by altering the port setting in the Administration Tool. This port setting is discussed in Configuring TCP/IP Settings Using Network Cables on page 34. The Access Gateway decrypts the SSL connections from the device and establishes a connection on behalf of the client to the network resources behind the second firewall. The ports that must be open through the second firewall are dependent on the network resources that you authorize external users to access. For example, if you authorize external users to access a Web server in the internal network, and this server listens for HTTP connections on port 80, you must allow HTTP on port 80 through the second firewall. The Access Gateway establishes the connection through the second firewall to the HTTP server on the internal network on behalf of the external client devices. The Access Gateway administrative tools available on the Access Gateway also listen for connections on these ports: Port Connections to the Administration Portal occur on this port Port Connections to the Administration Tool occur on this port Access Gateway in a Secure Network You can install the Access Gateway in the secure network. In this scenario, there is typically one firewall between the Internet and the secure network. The Access Gateway resides inside the firewall to control access to the network resources.

22 22 Citrix Access Gateway Standard Edition Administrator s Guide Access Gateway deployed in a secure network Access Gateway Connectivity in a Secure Network When an Access Gateway is deployed in the secure network, Access Gateway Plug-in connections must traverse the firewall to connect to the Access Gateway. By default, client connections use the SSL protocol on port 443 to establish this connection. To support this connectivity, you must open port 443 on the firewall. Note: You can change the port on which client devices connect to the Access Gateway by altering the port setting in the Administration Tool. This port setting is discussed in Configuring TCP/IP Settings Using Network Cables on page 34. Planning for Security with the Access Gateway When planning any type of Access Gateway deployment, there are basic security issues associated with certificates, authentication, and authorization that you should understand. Configuring Secure Certificate Management By default, the Access Gateway includes a self-signed SSL server certificate that enables it to complete SSL handshakes. Self-signed certificates are adequate for testing or sample deployments, but are not recommended for production environments. Before you deploy the Access Gateway in a production environment, Citrix recommends that you request and receive a signed SSL server certificate from a known Certificate Authority and upload it to the Access Gateway.

23 Chapter 3 Planning Your Deployment 23 If you deploy the Access Gateway in any environment where the Access Gateway must operate as the client in an SSL handshake (initiate encrypted connections with another server), you must also install a trusted root certificate on the Access Gateway. For more information about root certificates, see Installing Root Certificates on the Access Gateway on page 50. For example, if you deploy the Access Gateway with Citrix XenApp and the Web Interface, you can encrypt connections from the Access Gateway to the Web Interface with SSL. In this configuration, you must install a trusted root certificate on the Access Gateway. For more information, see Creating and Installing Certificates on page 46 and Securing Connections with Digital Certificates on page 185. Authentication Support You can configure the Access Gateway to authenticate users and control the level of access (or authorization) that users have to the network resources on the internal network. Before deploying the Access Gateway, your network environment should have the directories and authentication servers in place to support one of these authentication types: LDAP RADIUS RSA SecurID NTLM Secure Computing SafeWord products Gemalto Protiva If your environment supports none of the authentication types listed above, or you have a small population of remote users, you can create a list of local users on the Access Gateway and configure the Access Gateway to authenticate users against this local list. With this configuration, it is not necessary to maintain user accounts in a separate, external directory. For more information about authentication and authorization, see Examples of Configuring Network Access on page 199 and Configuring Authentication and Authorization on page 61.

24 24 Citrix Access Gateway Standard Edition Administrator s Guide Deploying the Access Gateway with Citrix XenApp or Citrix XenDesktop When deploying the Access Gateway to provide secure remote access to Citrix XenApp or XenDesktop, the Access Gateway works with the Web Interface and the Secure Ticket Authority (STA) to provide access to published applications and desktops hosted in a server farm. The configuration of your organization s network determines where you deploy the Access Gateway when it operates with a server farm. There are two options: If your organization protects the internal network with a single DMZ, deploy the Access Gateway in the DMZ. If your organization protects the internal network using two DMZs, deploy one Access Gateway in each of the two network segments in a double-hop DMZ configuration. This configuration is only supported with Citrix XenApp. For more information about deploying the Access Gateway with a server farm or in a double-hop DMZ, see the Citrix Access Gateway Standard Edition Integration Guide with Citrix XenApp and Citrix XenDesktop. Deploying the Access Gateway in a Double-Hop DMZ Some organizations use three firewalls to protect their internal networks. The three firewalls divide the DMZ into two stages to provide an extra layer of security for the internal network. This network configuration is called a doublehop DMZ. You can deploy the Access Gateway in a double-hop DMZ configuration to provide a single point-of-access to a server farm residing in an internal network. With this configuration, you must deploy two Access Gateway appliances: one in the first stage of the DMZ and one in the second stage of the DMZ. Important: When the Access Gateway is deployed in a double-hop scenario, users can only access resources on a server farm using Citrix XenApp Plug-ins. Users cannot use the Access Gateway Plug-in to access internal network resources in a double-hop DMZ scenario. Only ICA traffic is supported.

25 Chapter 3 Planning Your Deployment 25 Deploying Additional Appliances for Load Balancing and Failover You can install multiple Access Gateway appliances into your environment for one or both of these reasons: Scalability. If you have a large remote user population, install additional Access Gateway appliances to accommodate the user load. High Availability. If an Access Gateway fails, you can install additional Access Gateway appliances to ensure that the internal network remains available to remote users. Note: To support only high availability, you can configure one Access Gateway as the primary Access Gateway and one (or more) Access Gateway appliance as a failover device. If the primary Access Gateway fails, client connections are directed to the failover Access Gateway. For more information about this configuration, see Installing Additional Access Gateway Appliances on page 167. Deploying Access Gateway Appliances behind a Load Balancer To support both scalability and high availability, you can install a load balancer and then install multiple Access Gateway appliances behind the load balancer. Deploying multiple appliances behind a load balancer enables you to support a large population of remote users and maintain high availability of the internal network to the users.

26 26 Citrix Access Gateway Standard Edition Administrator s Guide Multiple Access Gateway appliances deployed behind a load balancer For detailed information about deploying multiple Access Gateway appliances behind a load balancer, see Installing Additional Access Gateway Appliances on page 167. Deploying Access Gateway Advanced Edition Citrix Access Gateway Advanced Edition is a product that is comprised of the Access Gateway appliance and the Advanced Access Control software. If you purchased Access Gateway Advanced Edition, you must configure the Access Gateway to communicate with the Advanced Access Control software. Use the Administration Tool to switch the Access Gateway to use Advanced Access Control that is then used to manage settings for the gateway cluster(s). After you configure Advanced Access Control, use the Administration Tool to manage appliance-specific settings only.

27 Chapter 3 Planning Your Deployment 27 Caution: When you select Advanced Access Control for managing the Access Gateway, the corresponding settings in the Administration Tool are deactivated. If you configured these settings with the Administration Tool before selecting Advanced Access Control, you must configure these settings again using the Access Management Console. For more information about configuring these settings in the console, see the Citrix Access Gateway Advanced Edition Administrator s Guide. If you disable administration with Advanced Access Control, settings in the Access Management Console are deactivated and existing configuration values are removed. Settings that were previously configured on the Access Gateway are restored. To enable Advanced Access Control 1. On the Access Gateway Cluster tab, select an Access Gateway and click the Advanced Options tab. 2. Click Advanced Access Control. 3. In Server running Advanced Access Control, type the IP address or fully qualified domain name (FQDN) of the server that is running the Access Management Console. 4. To encrypt communication between the Access Gateway and the server running Advanced Access Control, select Secure server communication. 5. Click Submit. The server or servers that are configured to connect to the Access Gateway appear in Servers Running Advanced Access Control. To remove a server from the list, select the server and then click Remove. Configuring Multiple Servers in an Access Server Farm If the Access Gateway is configured to establish connections with multiple servers running Access Gateway Advanced Edition, the servers are checked to make sure they are active before the Access Gateway sends a request to them. If the Access Gateway detects that one server is not active, it can check at a specified interval to see if the server is back online. You can specify the interval period, in seconds, when the Access Gateway checks the server. The minimum amount of time that can be set is 60 seconds.

28 28 Citrix Access Gateway Standard Edition Administrator s Guide To specify the retry interval for a server running Advanced Access Control 1. Click the Access Gateway Cluster tab and then click the Advanced Options tab. 2. Type the value in Retry invalid server in access server farm every number of seconds seconds, where number of seconds is the text box and click Set.

29 CHAPTER 4 Installing the Access Gateway for the First Time The Access Gateway can be installed in any network infrastructure without requiring changes to the existing hardware or back-end software. It works with other networking products such as server load balancers, cache engines, firewalls, routers, and IEEE wireless devices. Citrix recommends installing the Access Gateway in the demilitarized zone (DMZ). When installed in the DMZ, the Access Gateway participates on two networks: a private network and a public network with a publicly routable IP address. Typically, the private network is the internal network and the public one is the Internet. You can also use the Access Gateway to partition local area networks internally in the organization for access control and security. You can create partitions between wired or wireless networks and data and voice networks. In This Chapter Getting Ready to Install the Access Gateway Setting Up the Access Gateway Hardware Configuring TCP/IP Settings for the Access Gateway Getting Ready to Install the Access Gateway To install the Access Gateway, verify that the contents of the box match the packing list. If an item on the packing list is missing from the box, contact Citrix Customer Care. If you are installing the Access Gateway in a rack, see Getting Started with Citrix Access Gateway Standard Edition for instructions. Materials and Information Needed for Installation Before installing the Access Gateway, collect materials for the initial configuration and for the connection to your network.

30 30 Citrix Access Gateway Standard Edition Administrator s Guide For initial configuration, use one of the following setups: A cross-over cable and a Windows computer Two network cables, a network switch, and a Windows computer A serial cable and a computer with terminal emulation software For a connection to a local area network, use the following items: One network cable to connect the Access Gateway inside of a firewall or to a server load balancer Two network cables to connect the Access Gateway located in the demilitarized zone (DMZ) to the Internet and private networks Citrix recommends that you use the Access Gateway Standard Edition Pre- Installation Checklist to collect the following network information for appliances: The Access Gateway internal IP address and subnet mask The Access Gateway external IP address and subnet mask The Access Gateway FQDN for network address translation (NAT) The IP address of the default gateway device The port to be used for connections If connecting the Access Gateway to a server load balancer, you need the following information: The Access Gateway IP address and subnet mask. The settings of the server load balancer as the default gateway device (if required). See the load balancer manufacturer s documentation for more information. The FQDN of the server load balancer to be used as the external public address of the Access Gateway. The port to be used for connections. Note: The Access Gateway does not work with Dynamic Host Configuration Protocol (DHCP). The Access Gateway requires the use of static IP addresses.

31 Chapter 4 Installing the Access Gateway for the First Time 31 Setting Up the Access Gateway Hardware This section provides procedures for setting up the Access Gateway for the first time. To physically connect the Access Gateway 1. Install the Access Gateway in a rack if it is rack-mounted. For more information about installing the Access Gateway in a rack, see Getting Started with Citrix Access Gateway Standard Edition. 2. Connect the power cord to the AC power receptacle. 3. Connect either the serial cable to a Windows computer, a cross-over cable to a Windows computer, or an RJ-45 network cable to a network switch and the Access Gateway. 4. Configure the TCP/IP settings using the instructions in Configuring TCP/ IP Settings for the Access Gateway on page 31. Access Gateway connection options using a cross-over cable, a network switch, or terminal emulation Configuring TCP/IP Settings for the Access Gateway The preconfigured IP address of the Access Gateway is The IP address can be changed using a serial cable and a terminal emulation program, or by connecting the Access Gateway using network cables and the Administration Tool.

32 32 Citrix Access Gateway Standard Edition Administrator s Guide Configuring TCP/IP Settings Using the Serial Console You can use the serial console to set the IP address and subnet of the Access Gateway Interface 0, as well as the IP address of the default gateway device. All other configuration must be done using the Administration Tool. You can also use the serial console to test a connection with the ping command. If you want to reach the Access Gateway through the serial console before making any configuration settings, use a serial cable to connect the Access Gateway to a computer that has terminal emulation software. The serial console provides the following options for configuring the Access Gateway: [0] Express Setup configures the TCP/IP settings for Interface 0 on the Access Gateway Cluster > General Networking tab [1] Ping is used to ping other network devices to check for connectivity [2] Link Modes is used to set the duplex mode and speed mode for Interface 0 on the Access Gateway Cluster > General Networking tab [3] External Administration Port enables or disables connections to the Administration Tool from a remote computer [4] Display Log displays the Access Gateway log [5] Reset Certificate resets the certificate to the default certificate that comes with the Access Gateway [6] Change Administrative Password allows you to change the default administrator password of rootadmin Important: Citrix recommends changing the administrator password before connecting the Access Gateway to your network. The new password can be six to 127 characters long and cannot begin or end with a space. [7] Help displays help information [8] Log Out logs off from the Access Gateway Note: Citrix recommends using both network adapters on the appliance. After configuring the TCP/IP settings for Interface 0, use the Administration Tool to configure TCP/IP settings for Interface 1.

33 Chapter 4 Installing the Access Gateway for the First Time 33 To configure TCP/IP settings using a serial cable 1. Connect the serial cable to the 9-pin serial port on the Access Gateway and connect the cable to a computer that is capable of running terminal emulation software. 2. On the computer, start a terminal emulation application such as HyperTerminal. Note: HyperTerminal is not automatically installed on Windows 2000 Server, Windows Server 2003 or Windows Server To install HyperTerminal, use Add or Remove Programs in the Control Panel. 3. Set the serial connection to 9600 bits per second, 8 data bits, no parity, 1 stop bit. Hardware flow control is optional. 4. Turn on the Access Gateway. The serial console appears on the computer terminal after about three minutes. 5. If using HyperTerminal, press the Enter key. 6. On the serial console, enter the default administrator credentials. The user name is root and the password is rootadmin. Important: Citrix recommends changing the administrator password. You can do this using the Administration Portal or the serial console. 7. To set the IP address and subnet mask and the default gateway device for Interface 0, type 0 and press Enter to choose Express Setup. After you respond to the prompts, the information you entered appears. To commit your changes, type y; the Access Gateway restarts. 8. To verify that the Access Gateway can ping a connected network device, type 1 and enter the IP address of the device. 9. Remove the serial cable and connect the Access Gateway using either a cross-over cable to a Windows computer or a network cable to a network switch. Additional Access Gateway settings are configured using the Administration Tool.

34 34 Citrix Access Gateway Standard Edition Administrator s Guide Configuring TCP/IP Settings Using Network Cables The Access Gateway has two network adapters installed. One network adapter communicates with the Internet and client devices that are not inside the secure network. The other network adapter communicates with the internal network. Citrix recommends that both network adapters be configured for maximum security. If only one network adapter is used, it has to be routable for internal resources using Network Address Translation (NAT). Also, if only one network adapter is used, throughput of network traffic is cut in half and can cause a bottleneck of network traffic. You can install the Access Gateway and configure TCP/IP settings using network cables, such as two RJ-45 Ethernet network cables, or cross-over cables. The Ethernet cables are connected to a network switch and to the Access Gateway. The cross-over cables are connected to a Windows computer and the Access Gateway. To configure the Access Gateway using cross-over or Ethernet cables, you first install the Administration Tool and then configure your settings. To install the Administration Tool 1. Power on the Access Gateway. After about three minutes, the Access Gateway is ready for its initial configuration with your network. 2. Open a Web browser and type to open the Administration Portal. Use the default user name and password of root and rootadmin. 3. On the Downloads tab, under Access Gateway Administration Tool, click Install the Access Gateway Administration Tool. Follow the prompts to complete installation. After the Administration Tool is installed, you can then configure your network settings. To configure network settings using the Administration Tool 1. Log on to the Administration Tool using the default user name and password. 2. On the Access Gateway Cluster tab, open the window for the Access Gateway. 3. On the General Networking tab, under Interface 0 and Interface 1, next to IP address, type the new IP addresses of the appliance.

35 Chapter 4 Installing the Access Gateway for the First Time 35 Citrix recommends selecting Use both interfaces. 4. In Subnet mask, enter the subnet mask that is appropriate for the IP address entered for the interface(s). 5. In External FQDN, type the fully qualified domain name. Important: The FQDN must match what is on the digital certificate and the license for the Access Gateway. 6. In Duplex mode select the direction of the transmission data. The default setting is auto. You can also select full duplex or half duplex. 7. In Speed mode select the network speed of the adapter. The default setting is Auto. You can also select 10 Mbps, 100 Mbps, or 1000 Mbps. 8. In Maximum transmission unit (MTU), select the maximum transmission unit that defines the maximum size of the transmitted packet. The default setting is In Port, select the incoming port that is used for connections. The default is To configure a default gateway, under Default Gateway, in IP address, type the IP address of the gateway. In Interface, select the network adapter on the Access Gateway with which the Default Gateway communicates. The IP address is for the default gateway device, such as the main router, firewall, or server load balancers, depending on your network configuration. This address should be the same as the Default Gateway setting used for computers on the same subnet. For information about the relationship between the Default Gateway and dynamic or static routing, see Configuring Additional Network Settings on page Click Submit to save your configuration settings. After you configure your network settings on the Access Gateway, you need to restart the appliance. For more information, see Restarting the Access Gateway on page 37.

36 36 Citrix Access Gateway Standard Edition Administrator s Guide Note: You do not need to restart the Access Gateway until you complete all configuration steps. These include configuring network access for the appliance and installing certificates and licenses. For more information about configuring additional network settings, see Configuring the Access Gateway for Your Network Environment on page 39. Redirecting Connections on Port 80 to a Secure Port By default, the Access Gateway does not accept unsecure connections on port 80. If a user attempts to connect to the Access Gateway using HTTP on port 80, the connection attempt fails. You can configure the Access Gateway to automatically redirect HTTP connection attempts on port 80 to be secure connections on port 443 (or another secure port). If a user attempts an unsecure connection on port 80, the Access Gateway automatically converts this connection attempt into a secure (SSL-encrypted) connection on port 443. To redirect unsecure connections 1. Click the Access Gateway Cluster tab and open the window for the Access Gateway. 2. Click the General Networking tab. 3. Click Advanced. 4. Click Redirect any requests for port 80 to a secure port and click OK. Note: If you use the default setting of Do not accept connections on port 80, all user connection attempts on port 80 fail and there is no attempt to redirect them to port 443. Configuring TCP/IP Settings for a Double-Hop Deployment The Access Gateway can be installed in a double-hop DMZ scenario to provide access to a server farm. For more information about this deployment, see the Citrix Access Gateway Standard Edition Integration Guide with Citrix XenApp or Citrix XenDesktop.

37 Chapter 4 Installing the Access Gateway for the First Time 37 Restarting the Access Gateway After configuring your network settings, restart the Access Gateway. To restart the Access Gateway 1. In the Administration Tool, click the Access Gateway Cluster tab and open the window for the Access Gateway. 2. On the Administration tab, next to Restart the appliance, click Restart. -or- Click the Action menu and click Restart appliance name, where appliance name is the name of the Access Gateway. You can also restart the Access Gateway from the Administration Portal. To restart the Access Gateway from the Administration Portal In the Administration Portal, click Maintenance. Next to Restart the Server, click Restart.

38 38 Citrix Access Gateway Standard Edition Administrator s Guide

39 CHAPTER 5 Configuring the Access Gateway for Your Network Environment After the initial TCP/IP settings are configured on the Access Gateway, you then need to configure the appliance for your network environment. In this Chapter Installing Licenses Installing Licenses Creating and Installing Certificates Configuring Additional Network Settings Configuring the Date and Time on the Access Gateway Using the Default Portal Page Access Gateway licensing limits the number of concurrent user sessions to the number of licenses purchased. If you purchase 100 licenses, you can have 100 concurrent users logged on at any time. When a user logs off, that license is released for the next user. A user who logs on to the Access Gateway from more than one computer counts as two users and occupies two licenses. When all of the licenses are in use, no additional connections can be opened until a user logs off or the administrator uses the Administration Tool to close a connection, thereby releasing a license. Licenses for the Access Gateway are installed using the Administration Tool. License files are generated based on the host name, using the fully qualified domain name (FQDN) of the Access Gateway. The Access Gateway where the licenses are installed, also called the license server, processes the installed license files and disregards invalid license files.

40 40 Citrix Access Gateway Standard Edition Administrator s Guide If you have multiple appliances in your network, one Access Gateway is the licensing server, allocating licenses to the other appliances. When a user logs on to an appliance on the network, the license is pulled from the Access Gateway that is the licensing server. If you have a cluster, the installed licenses are not published to the other appliances. For more information about using licenses with multiple appliances, see Configuring Licenses for Multiple Appliances on page 43. Important: The host name in the license file must match exactly the host name on the Access Gateway, including letter case. If you are using Access Gateway Advanced Edition, licensing functionality is handled by the Citrix License Server. For more information about licensing with Access Gateway Advanced Edition, see Getting Started with Citrix Licensing and the Access Gateway Advanced Edition Administrator s Guide. Access Gateway License Types There are three types of licenses that can be installed on the Access Gateway: The standard license is installed on Access Gateway Standard Edition only and determines the number of users that can log on with the Access Gateway Plug-in, Citrix XenApp plugins, or Citrix Desktop Receiver. The universal license is installed on Access Gateway Standard Edition, Access Gateway Advanced Edition and Access Gateway Enterprise Edition and determines the number of users that can log on with the Access Gateway Plug-in, Citrix XenApp plugins, or Citrix Desktop Receiver. The Universal license is also used for clientless access connections through Access Gateway Advanced Edition and Access Gateway Enterprise Edition. The XenDesktop Connection license is installed on the Access Gateway and determines the number of ICA connections to Citrix XenDesktop that are allowed. These licenses are only included with XenDesktop Standard, Advanced and Enterprise as of June This license type is not for use with Citrix XenApp. Finding Licensing Statistics The Administration Tool shows the number of licenses in use by users. This includes licenses that are in use by the Access Gateway Plug-in and XenDesktop connections. You can find licensing information on the Access Gateway Cluster by opening the Access Gateway window and then clicking the Licensing and Statistics > Global tabs.

41 Chapter 5 Configuring the Access Gateway for Your Network Environment 41 Information on the Licensing Tab On the Licensing tab, under Information about the licensing server, the information shown is from the Access Gateway that is acting as the license server. When users connect to the Access Gateway and use either an Access Gateway or XenDesktop Connection license, it appears on this tab. If you have multiple Access Gateway appliances in the cluster, the license information from all appliances is aggregated on this tab. The information on the Licensing tab contains the following information: Total licenses available. The number in this field represents the total number of Access Gateway (Standard and Universal) and XenDesktop Connection licenses that are installed on the Access Gateway. Total licenses in use. This number represents all of the current licenses currently in use. This includes Access Gateway and XenDesktop Connection licenses. ICA licenses available. This is the total amount of XenDesktop Connection licenses that are installed on the Access Gateway. ICA licenses in use. This is the total number of XenDesktop Connection licenses currently in use. Access Gateway licenses available. This is the total number of Standard and Universal licenses installed on the Access Gateway. Access Gateway licenses in use. This is the total number of Access Gateway licenses that are in use. The Licensing tab also show information about the licenses installed on the Access Gateway. This includes total number of Access Gateway and XenDesktop Connection licenses, the Subscription Advantage expiration date, the issue and expiration dates of the licenses, the license type and the supported feature. If you have two licenses installed that have the same serial number, the files are not counted separately. The appliance that is the license server chooses one of the license files to allocate licenses to users. Information on the Statistics Tab The licensing information on the Statistics tabs show Access Gateway and XenDesktop Connection licenses that are currently in use for the Access Gateway appliance you are currently viewing. The information on this tab might not match the information on the Licensing tab.

42 42 Citrix Access Gateway Standard Edition Administrator s Guide Obtaining Your License Files After you install the Access Gateway, you are ready to obtain your license files from Citrix. This process involves going to to access your available licenses and generating a license file. When the license file is generated, download it to the computer where the Administration Tool is installed. After the license file is on the computer, you can then upload it to the Access Gateway. Before going to the Citrix Web site, you need the following information: The license code. You can find the code on the Access Gateway CD, in an you receive from Citrix, or from My Citrix. If you are upgrading from an older version of the Access Gateway, you can continue to use the existing license, if the license was obtained from the Subscription Advantage Management-Renewal-Information system (SAMRI) and the Subscription Advantage date is not expired. Your user ID and password for My Citrix. You can register for this password on My Citrix. Note: Care. If you cannot locate either of these items, contact Citrix Customer The FQDN of the Access Gateway. The entry field for this name on MyCitrix is case-sensitive so ensure that you copy the FQDN exactly as it appears on the Access Gateway Cluster > General Networking tab. How many licenses you want to include in the license file. You do not have to download all of the licenses you are entitled to at once. For example, if your company purchases 100 licenses, you can choose to download 50. At a later date, you can allocate the rest in another license file. Multiple license files can be installed on the Access Gateway. To obtain your license file 1. From a Web browser, go to and click on My Citrix. 2. Enter your user name and password. If this is your first time logging on to the site, you are asked for additional background information. 3. In My Tools, point to Choose a Toolbox and then click Activation System/Manage Licenses > View Licenses > Click to Allocate. 4. Follow the instructions to obtain your license file.

43 Chapter 5 Configuring the Access Gateway for Your Network Environment 43 After you successfully download the license file to your computer, you can then install it on the Access Gateway. To install a license on the Access Gateway 1. On the Access Gateway Cluster tab, open the window for the Access Gateway. 2. Click the Licensing tab. 3. Select Use this appliance as the license server. 4. Next to Install a license file, click Browse, navigate to the license file, and then click Open. 5. On the General Networking tab, click Submit after the license file is uploaded to the Access Gateway. Important: Citrix recommends that you retain a local copy of all license files that you receive. When you save a backup copy of the configuration file, all uploaded license files are included in the backup. If you need to reinstall the Access Gateway server software and do not have a backup of the configuration, you will need the original license files. Configuring Licenses for Multiple Appliances If you installed multiple appliances in your network, select one Access Gateway to be the license server. Install the licenses on that Access Gateway, which then becomes the license server. The other appliances obtain their licenses from this Access Gateway. The other appliances on your network do not have to be a part of a cluster to connect to the license server and obtain a license. License allocation occurs for appliances regardless of their individual status in the network. To obtain licenses from the license server 1. On the Access Gateway Cluster tab, open the window for the Access Gateway that is not the license server. 2. Click the Licensing tab. 3. Select Use a different appliance as the license server. 4. In FQDN or IP address, type the FQDN or IP address of the license server. 5. In Manager port and Vendor port change the port numbers or leave the defaults as and Click Submit.

44 44 Citrix Access Gateway Standard Edition Administrator s Guide 7. Repeat this procedure for each Access Gateway in your network. Repeat this procedure for each Access Gateway in the cluster that is not the license server. The manager port makes the initial contact from the remote Access Gateway and passes it to the license server. Then, it passes communication from the manager port to the vendor port. The vendor port runs on the license server and grants the license using port number The port numbers can be changed depending on your firewall configuration. The manager port tracks the licenses that are checked out and which Access Gateway is using them. You might need to create new firewall rules to allow network access to the license server ports. Downloading License Logs You can download license logs that provide you with detailed information about license use. When the logs are downloaded, they are in a compressed file named license_logs.zip. To download license logs 1. On the Access Gateway Cluster tab, select an Access Gateway and click the Licensing tab. 2. Under Information about this Access Gateway, next to Download licensing logs, click Download All. 3. Select the location to download the.zip file and then click Save. Once the.zip file is saved to your computer, you can extract the license logs using a compression utility such as WinZip. You can open the license files (with file extension.lic) using Notepad. Refreshing Licensing Information When you make changes to licensing on the Access Gateway, you can refresh the information that is displayed on the Licensing tab. To refresh licensing information Under Information about the licensing server, click Refresh All Information. Updating Existing Licenses If you are a current Subscription Advantage member, you can exchange, or migrate, your existing Access Gateway licenses to update your license files.

45 Chapter 5 Configuring the Access Gateway for Your Network Environment 45 Licensing Grace Period When the Access Gateway is first installed, there is a four day grace period where you are entitled to two licenses. Your license must be installed on the appliance by the end of this grace period. If it is not, users cannot log on. If the Access Gateway licensing server fails, the other appliances in the cluster have a 30-day grace period. The Access Gateway keeps the date when it last contacted the license server. Users can continue to log on during this grace period. When the license server is detected by the remote appliance, the 30-day grace period is reset. If the license server fails again, users have another 30-day grace period. Testing Your License Installation To test that licensing is configured correctly, create a test user and then log on using Citrix Access Gateway Plug-in and credentials that you set up for the user. To test your configuration 1. Open the Administration Tool. 2. Click the Access Policy Manager tab. 3. Right-click the Local Users folder in the left pane and click New User. 4. In the New User dialog box, in User Name, type a user name, and in Password and Verify Password, type the same password in each field, and click OK. 5. In a Web browser, type the address of the Access Gateway using either the IP address or fully qualified domain name (FQDN) to connect to either the internal or external interface. The format should be either or 6. On the Citrix Access Gateway page, type the user credentials. 7. On the portal page, click Citrix Access Gateway. If this is the first time a user connects, the Access Gateway Plug-in is downloaded and installed on the client device. After installation is complete, users must log on again using either the Web portal page or from the Start menu. The initial configuration is complete. After completing the initial configuration, you can configure accessible networks so you can connect to all of your network resources, such as , Web servers, and file shares as if you are in the office. To test your configuration, try connecting to the applications and resources that are available from the secure network.

46 46 Citrix Access Gateway Standard Edition Administrator s Guide Creating and Installing Certificates The Access Gateway includes a digital certificate that is not signed by a trusted Certificate Authority (CA). Install a digital X.509 certificate that belongs to your company and is signed by a Certificate Authority on the Access Gateway. Your company can operate as its own Certificate Authority, or you can obtain a digital certificate from a commercial Certificate Authority such as Verisign and Thawte. Caution: Operating the Access Gateway without a digital certificate signed by a Certificate Authority can subject VPN connections to malicious attacks. The Access Gateway accepts a Privacy Enhanced Mail (PEM) format certificate file. PEM is a text format that is the Base-64 encoding of the Distinguished Encoding Rules (DER) binary format. The PEM format specifies the use of text BEGIN and END lines that indicate the type of content that is being encoded. There are two ways to install a secure certificate and private key on the Access Gateway: Generate a Certificate Signing Request using the the Administration Tool. When the request is generated, a certificate and private key are created. The private key remains on the Access Gateway and the certificate is sent to a CA for signing. When the certificate is received back, it is installed on the appliance. During installation it is paired with the password-protected private key. Citrix recommends using this method to create and install secure certificates. Install a PEM certificate and private key from a Windows computer. This methods uploads a signed certificate and private key together. The certificate is signed by a CA and it is paired with the private key. Overview of the Certificate Signing Request Before you can upload a certificate to the Access Gateway, you need to generate a Certificate Signing Request (CSR) and private key. The CSR is created using the Certificate Signing Request included in the Administration Tool. The Certificate Signing Request is a tab that creates a.csr file. When the file is created, it is ed to the Certificate Authority for signing. The Certificate Authority signs the certificate and returns it to you at the address you provided. When it is received, you can install it on the Access Gateway. To provide secure communications using SSL/TLS, a server certificate is required on the Access Gateway. The steps required to obtain and install a server certificate on the Access Gateway are as follows:

47 Chapter 5 Configuring the Access Gateway for Your Network Environment 47 Generate a CSR (myserver.csr) using the Certificate Signing Request tab in the Administration Tool. the myserver.csr file to an authorized certificate provider. When you receive the signed certificate file from your Certificate Authority, upload the certificate using the Administration Tool. The Administration Tool automatically converts the certificate to the PEM format, which is required by the Access Gateway. Password-Protected Private Keys Private keys that are generated with the Certificate Signing Request are stored in an encrypted and password-protected format on the Access Gateway. When creating the Certificate Signing Request, you are asked to provide a password for the private key. The password is used to protect the private key from tampering and it is also required when restoring a saved configuration to the Access Gateway. Passwords are used whether the private key is encrypted or unencrypted. To create a Certificate Signing Request 1. Click the Access Gateway Cluster tab and open the window for the appliance. 2. On the Certificate Signing Request tab, type the required information in the fields and then click Generate Request. Note: In the field Access Gateway FQDN, type the same FQDN that is on the General Networking tab. In Password, type the password for the private key. 3. A.csr file is created. Save the certificate request on the local computer. 4. the certificate to your Certificate Authority The certificate provider returns a signed certificate to you by . When you receive the signed certificate, install it on the Access Gateway. Note: When you save the Access Gateway configuration, any certificates that are already installed are included in the backup. After you create the certificate request and send it to the Certificate Authority, refrain from performing the following tasks on the Access Gateway until you receive the signed certificate back and install it on the appliance:

48 48 Citrix Access Gateway Standard Edition Administrator s Guide Generating another Certificate Signing Request Uploading a saved configuration file Publishing configuration settings from another appliance in the cluster Important: When the certificate is generated and sent to the Certificate Authority, do not create another Certificate Signing Request. The Access Gateway stores one private key. If the Certificate Signing Request is run again, the private key is overwritten and the signed certificate will not match. To install a certificate file using the Administration Tool 1. Click the Access Gateway Cluster tab and open the window for the appliance. 2. On the Administration tab, next to Upload a.crt signed certificate, click Browse. This button is used only when you are installing a signed certificate generated on the Certificate Signing Request tab. 3. Locate the file you want to upload and click Open. You can also upload the certificate using the Administration Portal. To install a certificate using the Administration Portal 1. On the Administration Portal main page, click Maintenance. 2. Next to Upload a signed certificate (.crt), click Browse. 3. Navigate to the certificate and upload the file. Resetting the Certificate to the Default Setting The Access Gateway comes with a certificate that is not digitally signed by a Certificate Authority. If you need to reimage the appliance, you can reset the certificate to the default certificate that came with the Access Gateway. You can do this by using the serial console and selecting the option to reset the certificate. To reset the default certificate 1. Connect the serial cable to the 9-pin serial port on the Access Gateway and connect the cable to a computer that is capable of running terminal emulation software. 2. On the computer, start a terminal emulation application such as HyperTerminal.

49 Chapter 5 Configuring the Access Gateway for Your Network Environment 49 Note: HyperTerminal is not installed automatically on Windows 2000 Server, Windows Server 2003 or Windows Server To install HyperTerminal, use Add or Remove Programs in Control Panel. 3. Set the serial connection to 9600 bits per second, 8 data bits, no parity, 1 stop bit. Hardware flow control is optional. 4. Turn on the Access Gateway. The serial console appears on the computer terminal after about three minutes. 5. If using HyperTerminal, press the Enter key and log on using the default user name and password root and rootadmin. 6. To reset the default certificate, type 5 and press Enter. Installing a Certificate and Private Key from a Windows Computer If you are using a load balancer or you have a signed digital certificate with the private key that is stored on a Windows computer, you can upload this to the Access Gateway. If the Access Gateway is not behind a load balancer, the certificate must contain the FQDN of the Access Gateway. If the Access Gateway is behind a load balancer, each appliance must contain the same certificate and private key. For more information, see Configuring Multiple Appliances to Use a Load Balancer on page 171. To install a certificate and private key from a Windows computer 1. Click the Access Gateway Cluster tab and open the window for the appliance. 2. Click the Administration tab. 3. Next to Upload a.pem private key and signed certificate, click Browse. 4. Navigate to the certificate and then click Open. When you upload the certificate to the Access Gateway, you are asked for a password to encrypt the private key.

50 50 Citrix Access Gateway Standard Edition Administrator s Guide Installing Root Certificates on the Access Gateway Root certificates are provided by the CA and are used by SSL clients to validate certificates presented by an SSL server. When an SSL client attempts to connect to an SSL server, the server presents a certificate. The client device consults its root certificate store to see if the certificate that the SSL server presented is signed by a CA that the root certificate trusts. If you deploy the Access Gateway in any environment where the Access Gateway must operate as the client in an SSL handshake (initiate encrypted connections with another server), install a trusted root certificate on the Access Gateway. For example, if you deploy the Access Gateway with Citrix XenApp and the Web Interface, you can encrypt connections from the Access Gateway to the Web Interface with SSL. In this configuration, you must install a trusted root certificate on the Access Gateway. The root certificate that is installed on the Access Gateway has to be in PEM format. On Windows, the file extension.cer is sometimes used to indicate that the root certificate is in PEM format. If you are validating certificates on internal connections, the Access Gateway must have a root certificate installed. To install a root certificate on the Access Gateway 1. On the Access Gateway Cluster tab, open the window for an appliance. 2. On the Administration tab, next to Manage trusted root certificates, click Manage. 3. On the Manage tab, click Upload Trusted Root Certificate. 4. Navigate to the file and then click Open. To remove the root certificate, click Remove Trusted Root Certificate. Installing Multiple Root Certificates Multiple root certificates can be installed on the Access Gateway, however they must be in one file. For example, you can create a text file in a plain text editor (such as Notepad) that contains all of the root certificates. Open each root certificate in another plain text editor window and then copy and paste the contents of each certificate below the last line in the new text window. When all of the certificates are copied to the new file, save the text file in PEM format, and then upload the file to the Access Gateway.

51 Chapter 5 Configuring the Access Gateway for Your Network Environment 51 Creating Root Certificates Using a Command Prompt You can also create PEM-formatted root certificates using a DOS command prompt. For example, if you have three PEM root certificates, you can use the following command to create one file that contains all three certificates: type root1.pem root2.pem root3.pem > current-roots.pem If you want to add additional root certificates to an existing file, use the following command: type root4.pem root5.pem >> current-roots.pem When this command is executed, all five root certificates are in the file currentroots.pem. The double greater than symbol (>>) appends the the contents of root4.pem and root5.pem to the existing contents of current-roots.pem. Configuring Additional Network Settings After you have installed your license(s) and certificate(s) on the Access Gateway, there are additional configuration steps you might need to complete so the Access Gateway can work with your network. These include: Configuring Name Service Providers that allow you to configure up to three DNS servers and one WINS server Editing the HOSTS file to bypass DNS and resolve specific IP addresses to specific host names Configuring dynamic and static routing that listen for the routes published by your routing server(s) or using specified static routes Configuring the date and time Configuring the default logon page for the Access Gateway Plug-in Configuring Name Service Providers Name resolution is configured on the Name Service Providers tab. You can specify the settings for up to three DNS servers and one WINS server. To specify DNS and WINS servers 1. On the Access Gateway Cluster tab, open the window for an appliance. 2. Click the Name Service Providers tab. 3. In First DNS server, Second DNS Server, or Third DNS server, type the IP address of each server. 4. In DNS suffixes, type the suffixes of the servers.

52 52 Citrix Access Gateway Standard Edition Administrator s Guide These are the DNS suffixes of the servers. Each entry in the list is separated by a space. Each entry should follow the format of site.com. Do not precede a suffix with a dot (. ), such as.site.com. By default, the Access Gateway checks a user s remote DNS only. If you want to allow failover to a user s local DNS, you need to enable split DNS. For more information see Enabling Split DNS on page In WINS Server, type the IP address of the server. 6. Click Submit. Editing the HOSTS File You can add entries to the Access Gateway HOSTS file from the Name Service Providers tab. The Access Gateway uses the entries in the HOSTS file to resolve FQDNs to IP addresses. When the Access Gateway attempts to translate an FQDN to an IP address, the Access Gateway checks its HOSTS file before connecting to DNS to perform the address translation. If the Access Gateway can translate the FQDN to an IP address using the information in the HOSTS file, it does not use DNS to perform the address translation. You might want to add entries to the HOSTS file in an Access Gateway deployment where the network configuration prevents the Access Gateway from connecting to DNS to perform address translations. Also, adding entries to the HOSTS file can optimize performance because the Access Gateway does not have to connect to a different server to perform the address translations. To add an entry to the HOSTS file 1. On the Access Gateway Cluster tab, open the window for an appliance. 2. Click the Name Service Providers tab. 3. Under Edit the HOSTS file, in IP address, enter the IP address that you want to associate with an FQDN. 4. In FQDN, enter the FQDN you want to associate with the IP address you entered in the previous step and click Add. The IP address and HOSTS name pair appears in the Host Table. To remove an entry from the HOSTS file 1. Under Host Table, click the IP address and HOSTS name pair you want to delete. 2. Click Remove.

53 Chapter 5 Configuring the Access Gateway for Your Network Environment 53 Configuring Dynamic and Static Routes You can configure the Access Gateway to support dynamic routing or static routing. The Access Gateway supports dynamic routing based on the Routing Information Protocol (RIP and RIP 2). Enabling Dynamic Routing When you enable dynamic routing on the Access Gateway, the following occurs: The Access Gateway listens for routing information published through RIP UDP packets. The Access Gateway populates its routing table using the RIP information. Any existing static routes are disabled. With dynamic routing, you can enable the dynamic gateway to allow RIP to specify the default gateway used by the Access Gateway. When this is selected, the Access Gateway does not use the default gateway that is specified on the General Networking tab of the selected appliance on the Access Gateway Cluster tab of the Administration Tool. To enable dynamic routing 1. On the Access Gateway Cluster tab, open the window for an appliance. 2. Click the Routes tab. 3. In Select routing type, select Dynamic routing (RIP). 4. Click Enable dynamic gateway to use the default gateway provided by the routing server(s). 5. In Routing Interface, choose the Access Gateway network adapter(s) to be used for dynamic routing. Typically, your routing server(s) are inside your firewall, so you would choose the internal network adapter (Interface 1) for this setting. 6. Click Submit. Dynamic routes do not appear in the Access Gateway routing table. Enabling RIP Authentication for Dynamic Routing To enhance security for dynamic routing, you can configure the Access Gateway to support RIP authentication. Note Your RIP server must transmit RIP 2 packets to use RIP authentication. RIP 1 does not support authentication.

54 54 Citrix Access Gateway Standard Edition Administrator s Guide To support RIP authentication, both the RIP server and the Access Gateway must be configured to use a specific authentication string. The RIP server can transmit this string as plain text or encrypt the string with MD5. If the RIP server encrypts the authentication string with MD5, you must also select the MD5 option on the Access Gateway. You can configure the Access Gateway to listen for the RIP authentication string on Interface 0, Interface 1, or both interfaces. To enable RIP authentication for dynamic routing 1. On the Access Gateway Cluster tab, open the window for an appliance. 2. Click the Routes tab. 3. In Routing Interface, select either Interface 0, Interface 1, or Both to specify the interface(s) on which the Access Gateway listens for the RIP authentication string. 4. Select RIP Authentication String for Interface. 5. In the text box, type a text string that is an exact, case-sensitive match to the authentication string transmitted by the RIP server. 6. Select Enable RIP MD5 Authentication for Interface if the RIP server transmits the authentication string encrypted with MD5. Do not select this option if the RIP server transmits the authentication string using plain text. 7. Click Submit. Changing from Dynamic Routing to Static Routing Before you change from dynamic routing to static routing, you may want to save your dynamic routes to the static route table. Selecting this option saves the current RIP dynamic routing information as static routes. If you change from dynamic routing to static routing, and you previously created static routes, the static routes reappear in the Access Gateway routing table. If these static routes are no longer valid, or if no static routes were created previously, you might lose remote access to the Administration Tool and users could lose access to the internal network resources until you manually configure the static routes. Saving the current RIP dynamic routing information as static routes when you switch from dynamic routing to static routing allows you to maintain connectivity until you properly configure the static routes.

55 Chapter 5 Configuring the Access Gateway for Your Network Environment 55 To save dynamic routes to the static route table 1. On the Access Gateway Cluster tab, open the window for the appliance. 2. Click the Routes tab. 3. Click Save to static routes. After you save the dynamic route, you can switch to static routing. Configuring a Static Route When setting up communication with another host or network, a static route might need to be added from the Access Gateway to the new destination if you do not use dynamic routing. Set up static routes on the Access Gateway adapter that is not used by the Default Gateway specified on the General Networking tab. For an example static route setup, see Static Route Example on page 56. To add a static route 1. On the Access Gateway Cluster tab, open the window for the appliance and click the Routes tab. 2. In Select routing type, select Static routing. 3. Under Add a static route, in Destination LAN IP address, type the IP address of the destination local area network. 4. In Subnet mask, type the subnet mask for the gateway device. 5. In Gateway, type the IP address for the default gateway. If you do not specify a gateway, the Access Gateway can access content only on the local network. 6. In Interface, select the network adapter for the static route. The default is Interface Click Add. The route name appears in the Static routes list on the Routes tab. To test a static route 1. In the Administration Tool, on the Access Gateway Cluster tab, open the window for the appliance. 2. On the Net Tools > Ping tabs, in Host address, type the IP address of the network or device you want to test and click Ping.

56 56 Citrix Access Gateway Standard Edition Administrator s Guide If you are successfully communicating with the other device, messages indicate that the same number of packets were transmitted and received, and zero packets were lost. If you are not communicating with the other device, the status messages indicate that zero packets were received and all the packets were lost. To correct this, repeat the procedure to add a static route. To remove a static route 1. On the Access Gateway Cluster tab, open the window for the appliance. 2. Click the Routes tab. 3. In the Static Routes table, select each route that you want to delete. 4. Click Remove Route. Static Route Example Suppose the IP address of Interface 0 on your Access Gateway is and there is a request to access information at to which you currently do not have a path. You can create a static route through the network adapter that is not set as your Access Gateway default gateway, and out to the requested network address, as shown in the following figure: Network topology showing a static route. The diagram shows the following connections: The Interface 0 adapter ( ) leads to the default gateway ( ), which connects to the rest of the network.

57 Chapter 5 Configuring the Access Gateway for Your Network Environment 57 The Interface 1 adapter ( ) is set to communicate with the network and its gateway ( ). Through this gateway, Interface 1 can communicate with the network and the server at IP address To set up the static route, you need to establish the path between Interface 1 and the IP address To set up the example static route 1. On the Access Gateway Cluster tab, open the window for the appliance. 2. Click the Routes tab. 3. If necessary, in Select routing type, select Static routing. 4. In Destination LAN IP address, set the IP address of the destination LAN to In Subnet mask, set the subnet mask for the gateway device. 6. In Gateway, set the IP address of the default gateway to In Interface, select Interface 1 as the gateway device adapter and click Add. Configuring the Date and Time on the Access Gateway The system time appears on the Date tab in the Administration Tool. To change the system date and time 1. On the Access Gateway Cluster tab, open the window for the appliance. 2. Click the Date tab. 3. In Synchronization mode, click Manual. 4. In Date, type the date and time. 5. In Time zone, select a time zone and click Submit. Configuring a Network Time Protocol Server The Network Time Protocol transmits and receives time over TCP/IP networks. The Network Time Protocol is useful for synchronizing the internal clock of computers on the network to a common time source. If you have a Network Time Protocol server in your secure network, you can use the Administration Tool to configure the Access Gateway to synchronize the time with the Network Time Protocol server.

58 58 Citrix Access Gateway Standard Edition Administrator s Guide To synchronize the Access Gateway with a Network Time Protocol server 1. On the Access Gateway Cluster tab, open the window for the appliance. 2. Click the Date tab. 3. In Synchronization Mode, select Network Time Protocol (NTP). 4. In NTP server, type the FQDN of the server. 5. In Synchronization interval, select a schedule to perform updates and click Submit. Using the Default Portal Page The default portal page is an HTML page that enables a user to choose the type of connection to be established from a remote computer. Users can either connect from the Web portal page or they can use the Access Gateway Plug-in that is installed on their computer from the logon page. For more information about logon pages and the different ways users can connect, see Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in on page 143. From the Web portal page, the user starts the Access Gateway Plugin. The Access Gateway Plugin is intended for connections from a private computer because data is transferred from the network to which the user is connecting to the user s computer. To connect using the default portal page 1. In a Web browser, type the Web address of the Access Gateway; for example: 2. On the logon page, type the user name and password and then click Login. The default portal page opens. Note: If Enable logon page authentication is not selected on the Global Cluster Policies tab, users do not log on before receiving the connection portal page as described in Step To connect using the Access Gateway Plug-in from a secure computer, do the following: Click Citrix Access Gateway. The first time a connection is made using the Web browser, the client device is asked to install the Access Gateway Plug-in.

59 Chapter 5 Configuring the Access Gateway for Your Network Environment 59 Click Run twice, click Next and then follow the instructions in the Access Gateway Plug-in Setup Wizard. The Access Gateway Plug-in is installed on to the client device. When the plug-in is installed, the user can subsequently start the Access Gateway Plug-in without going through the Web logon and portal pages. To connect, click Start > All Programs > Citrix > Citrix Access Clients > Citrix Access Gateway. 4. To log on to the Web Interface, click Citrix XenApp. Users type their user name and password and then click Log On. Users have access to published applications on Citrix XenApp and can use applications such as Word and Outlook as if they were installed locally on their computers. If you configured the Access Gateway Plugin to log on automatically with Windows, the plug-in starts after users enter their Windows logon credentials, which are also used for the Access Gateway Plugin. Thus, when the client device starts, users do not have to reauthenticate to establish the connection, provided that they have a network connection and can log on to Windows. For more information about configuring single sign-on with Windows, see Configuring Single Sign-on with Windows Operating System on page 124. Configuring Network Access After you configure the appliance to operate in your network environment, the next step is to configure network access for the appliance and for groups and users. The steps to configure network access are: Step 1: Configuring networks to which clients can connect. By default, clients cannot connect to any networks. The first step in configuring network access is to specify the networks that clients can connect to, using the Global Cluster Policies tab. Step 2: Configuring authentication and authorization. Authentication defines how users log on and is configured using realms. Authentication types include local, NTLM, LDAP, RADIUS, RSA SecurID, Gemalto Protiva, and Secure Computing SafeWord. Authorization types include local, LDAP, RADIUS, NTLM, or no authorization. For more information about configuring authentication and authorization, see Configuring Authentication and Authorization on page 61. Step 3: Configuring user groups. User groups are used in conjunction with authentication and authorization. For example, if your users are connecting using LDAP, create an LDAP authentication realm, and then

60 60 Citrix Access Gateway Standard Edition Administrator s Guide create a group. The names of the user group must be the same as that on the LDAP server. In addition, you can create local users on the Access Gateway for local authentication. Local users are then added to user groups. For information about configuring local users, see Configuring Local Users on page 68. Step 4: Configuring network access for groups. After you configure your user groups, you then configure network access for the groups. This includes the network resources users in the group are allowed to access, application policies, and endpoint policies. For more information about configuring accessible networks, user groups, and network access for users, see Configuring Network Access and Group Resources on page 93. Before configuring network access for the appliance, Citrix recommends that you read the scenarios in Examples of Configuring Network Access on page 199.

61 CHAPTER 6 Configuring Authentication and Authorization The Access Gateway supports several authentication types for authenticating users. You can configure authentication realms on the Access Gateway that contain the settings for your authentication type. The Default realm is configured automatically for local authentication. You can change the Default realm to support other authentication types. You can also configure authorization types for users. These include local, NTLM, LDAP, and RADIUS authorization. In This Chapter Choosing When to Configure Authentication on the Access Gateway Configuring Authentication on the Access Gateway Configuring the Default Realm Configuring Local Authentication Configuring Local Users Configuring LDAP Authentication and Authorization Configuring RADIUS Authentication and Authorization Configuring RSA SecurID Authentication Configuring Secure Computing SafeWord Authentication Configuring Gemalto Protiva Authentication Configuring NTLM Authentication and Authorization Configuring Advanced Options for Authentication Configuring Double-Source Authentication Changing Password Labels

62 62 Citrix Access Gateway Standard Edition Administrator s Guide Choosing When to Configure Authentication on the Access Gateway If a user belongs to a group that is not configured to use one of these authentication methods, the local user authentication database on the Access Gateway is used to check credentials and allow the client connection. Authentication is configured on the Access Gateway in the following scenarios: The Access Gateway is deployed in the DMZ or secure network and users are connecting directly to the appliance The Access Gateway is deployed in the DMZ and the Web Interface is also in the DMZ behind the Access Gateway The Access Gateway is deployed in the DMZ and the Web Interface is deployed in the secure network If the Web Interface is parallel to the Access Gateway, or if the appliance is configured to use Citrix XenApp Plug-ins and the Web Interface to connect to published applications in a server farm, authorization does not have to be configured on the Access Gateway; however, you can choose to do so. Configuring Authentication on the Access Gateway By default the Access Gateway authenticates users against a user list stored locally on the Access Gateway. You can configure the Access Gateway to use LDAP, RADIUS, RSA SecurID, Secure Computing SafeWord, Gemalto Protiva or NTLM (Windows NT 4.0) authentication servers. The Access Gateway supports realm-based authentication to accommodate sites with more than one LDAP or RADIUS server or with a combination of authentication servers.

63 Chapter 6 Configuring Authentication and Authorization 63 Communication between the Access Gateway and authentication servers. If a user is not located on an authentication server or fails authentication on that server, the Access Gateway attempts to authenticate the user against the local user list if the check box Use the local user database on the Access Gateway is selected on the Authentication > Settings tab. Communication between the client device, the Access Gateway, and the local user account when authentication fails on the authentication server.

64 64 Citrix Access Gateway Standard Edition Administrator s Guide After a user is authenticated, the Access Gateway performs a group authorization check by obtaining the user s group information from either an LDAP server, a RADIUS server, a Windows NT 4.0 server (for NTLM authorization), or the local group file (if not available on the LDAP or RADIUS server). If group information is available for the user, the Access Gateway then checks the network resources allowed for the group. LDAP authorization works with all supported authentication methods. The group names obtained from the LDAP server are compared with the group names created locally on the Access Gateway. If the two group names match, the properties of the local group apply to the group obtained from the LDAP servers. Configuring Authentication without Authorization The Access Gateway can be configured to authenticate users without requiring authorization. When users are not authorized, the Access Gateway does not perform a group authorization check. The settings from the Default user group are assigned to the user. To remove authorization requirements from the Access Gateway 1. On the Authentication tab, open an authentication realm. 2. On the Authorization tab, in Authorization type, select No authorization and click Submit. Configuring the Default Realm The Access Gateway has a permanent realm named Default. The Default realm is preconfigured for local authentication. If you want to change the authentication method of the Default realm, it must be deleted and then immediately replaced with a new Default realm. The Default realm is assumed when a user enters only a user name when logging on to the Access Gateway. For any other realm, the user must specify a realm name when logging on. Thus, if most users are logging on to a non-local authentication realm, change the authentication type of the Default realm. To change the authentication type of the Default realm, remove the Default realm and then immediately create a new realm with the appropriate authentication configuration. Note: If the removed Default realm is not immediately replaced with a new Default realm, the original realm is restored automatically.

65 Chapter 6 Configuring Authentication and Authorization 65 To remove and create a Default realm 1. Click the Authentication tab. 2. Open the window for the Default realm. 3. On the Action menu, select Remove Default realm. A warning message appears. Click Yes. 4. Under Add an Authentication Realm, in Realm name, type Default. Important: When creating a new Default realm, the word Default is case-sensitive and an uppercase D must be used. 5. Do one of the following: If configuring one authentication type, select One Source and click Add. If configuring double-source authentication, select Two Source and click Add. 6. In Authentication type, select the type of authentication and then click OK. 7. Configure the authentication settings. For more information, see: Configuring Local Authentication on page 67 Configuring LDAP Authentication and Authorization on page 69 Configuring RADIUS Authentication and Authorization on page 77 Configuring RSA SecurID Authentication on page 80 Configuring Secure Computing SafeWord Authentication on page 84 Configuring Gemalto Protiva Authentication on page 86 Configuring NTLM Authentication and Authorization on page 87

66 66 Citrix Access Gateway Standard Edition Administrator s Guide Creating Additional Realms You can create realms in addition to the Default realm. For example, you want the Default realm to be used for authentication to an LDAP server. If you want to use additional authentication methods for users, such as RADIUS, SafeWord, RSA SecurID, NTLM, or locally on the appliance, you can create realms for each of these. When the user logs on to realms that are not the Default realm, they need to type the realm name and their user name, such as realm name\user name. Note: Citrix recommends that realm names map to their corresponding domain names. This enables users to log on using either realm name\user name or user name@realm name. To create a realm 1. On the Authentication tab, under Add an Authentication Realm, in Realm name, type the name of the realm. 2. Do one of the following: If users have one authentication type, click One Source. -or- If users have two authentication types, click Two Source. 3. Click Add. 4. In Authentication type, select the authentication method, and click OK. If you are configuring double-source authentication, in Primary authentication type, select the type that users will log on to first. In Secondary authentication type, select the type that users will log on to second. For more information, see Configuring Double-Source Authentication on page Configure the settings for the realm and then click Submit. Configuring Single Sign-On to the Web Interface If you are configuring single sign-on to the Web Interface, you must use the Default realm for authentication. If you use any other realm for single sign-on to the Web Interface, users cannot log on. For more information, see the Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop.

67 Chapter 6 Configuring Authentication and Authorization 67 Removing Realms If you are retiring an authentication server or removing a domain server, you can remove any realm except for the Default realm. You can remove the Default realm only if you immediately create a new realm named Default. For more information, see Configuring the Default Realm on page 64. To remove a realm 1. On the Authentication tab, open the realm you want to remove. 2. On the Action menu, click Remove realm name realm. The realm is removed. Configuring Local Authentication For a new installation, the Default realm is set to local authentication. This enables users to log on to the Access Gateway without having to enter a realm name. If some users authenticate only against the local user list on the Access Gateway, you can keep the Default realm set to local authentication. Alternatively, you can create a new realm for local authentication and use the Default realm for another authentication type. If all users authenticate against authentication servers, you do not need a realm for local authentication. The Access Gateway can check the local user database on the appliance for authentication information if a user fails to authenticate on another authentication server. For example, if you are using LDAP and the authentication fails, users can log on using the local user database. To authenticate using the local user list on the Access Gateway 1. On the Authentication tab, open the authentication realm on which you want to configure local authentication. 2. Click the Settings tab. 3. Click Use the local user database on the Access Gateway and click Submit. Note: This check box is unavailable if the realm is configured for local authentication

68 68 Citrix Access Gateway Standard Edition Administrator s Guide Configuring Local Users You can create user accounts locally on the Access Gateway to supplement the users on authentication servers. For example, you might want to create local user accounts for temporary users, such as consultants or visitors, without creating an entry for those users on the authentication server. In that case, you add the user to the Access Gateway local user list. To add a user to another group, under Local Users, click and drag the user to the appropriate user group. If a user is not a member of a group or groups you defined on the Access Gateway, the user receives the settings for the Default user group. If a user is part of a group other than the Default group, the user inherits only the settings of the Default group if the group is configured to receive those settings. For more information, see Default Group Properties on page 100. To create a user on the Access Gateway 1. Click the Access Policy Manager tab. 2. In the left-pane, right-click Local Users and then click New User. 3. In User Name, type a user name. User names can contain spaces. Note: User names are not case-sensitive. Do not use a forward slash (/) or the at (@) symbol in the user name or password. Passwords cannot begin or end with a space. 4. In Password and Verify Password, type the password for the user and click OK. A user enters this password when logging on. A password must be six or more characters up to a maximum of 127 characters. To delete a user from the Access Gateway 1. Click the Access Policy Manager tab. 2. In the left pane, right-click the user in the Local Users list and click Remove. Adding Users to Multiple Groups After creating the local user list, you can then add the users to groups that you created on the Access Gateway. If you associate more than one group with a user account, the properties of the first group that you select on the Group Priority tab is used for the user.

69 Chapter 6 Configuring Authentication and Authorization 69 To add a user to a group Click the user in the Local Users list and drag it to a group. Changing Password for Users You can change the password for a user in the Administration Tool. To change a user s password 1. On the Access Policy Manager tab, right-click a user, and click Set Password. 2. Type the password twice and then click OK. Configuring LDAP Authentication and Authorization You can configure the Access Gateway to authenticate user access with one or more LDAP servers. If a user is not located in an LDAP directory or fails authentication on a server, the Access Gateway checks the user against the user information stored locally on the Access Gateway. LDAP authorization requires identical group names in Active Directory, on the LDAP server, and on the Access Gateway. The characters and case must also be the same. By default, LDAP authentication is secure using SSL/TLS. There are two types of secure LDAP connections. With one type, the LDAP server accepts the SSL/TLS connection on a port separate from the port used to accept clear LDAP connections. After users establish the SSL/TLS connection, LDAP traffic can be sent over the connection. The second type allows both unsecure and secure LDAP connections and is handled by a single port on the server. In this scenario, to create a secure connection, the client first establishes a clear LDAP connection. Then, the LDAP command StartTLS is sent to the server over the connection. If the LDAP server supports StartTLS, the connection is converted to a secure LDAP connection using TLS. The port numbers for LDAP connections are: 389 for unsecured LDAP connections 636 for secure LDAP connections 3268 for Microsoft unsecure LDAP connections 3269 for Microsoft secure LDAP connections

70 70 Citrix Access Gateway Standard Edition Administrator s Guide LDAP connections that use the StartTLS command use port number 389. If port numbers 389 or 3268 are configured on the Access Gateway, it tries to use StartTLS to make the connection. If any other port number is used, connection attempts are made using SSL/TLS. If StartTLS or SSL/TLS cannot be used, the connection fails. Note: If this is a new installation of the Access Gateway, or you are creating a new LDAP realm, LDAP connections are secure by default. When configuring the LDAP server, the letter case must match on the server and on the Access Gateway. If the root directory of the LDAP server is specified, all of the subdirectories are also searched to find the user attribute. In large directories, this can affect performance. For this reason, Citrix recommends that you use a specific organizational unit (OU). The following table contains examples of user attribute fields for LDAP servers: LDAP Server User Attribute Case Sensitive Microsoft Active Directory Server samaccountname No Novell edirectory cn Yes IBM Directory Server uid Yes Lotus Domino CN Yes Sun ONE directory (formerly iplanet) uid or cn Yes This table contains examples of the base dn: LDAP Server Microsoft Active Directory Server Novell edirectory IBM Directory Server Lotus Domino Sun ONE directory (formerly iplanet) Base dn DC=citrix, DC=local dc=citrix,dc=net cn=users OU=City, O=Citrix, C=US ou=people,dc=citrix,dc=com

71 Chapter 6 Configuring Authentication and Authorization 71 The following table contains examples of bind dn: LDAP Server Microsoft Active Directory Server Novell edirectory IBM Directory Server Lotus Domino Sun ONE directory (formerly iplanet) Bind dn CN=Administrator, CN=Users, DC=citrix, DC=local cn=admin, dc=citrix, dc=net LDAP_dn CN=Notes Administrator, O=Citrix, C=US uid=admin,ou=administrators, ou=topologymanagement,o=netscaperoot Note: For further information regarding LDAP server settings, see Determining Attributes in your LDAP Directory on page 76. To create an LDAP authentication realm 1. Click the Authentication tab. 2. Under Add an Authentication Realm, in Realm name, type a name for the authentication realm. If your site has multiple authentication realms, you might use a name that identifies the LDAP realm for which you specify settings. Realm names are case-sensitive and can contain spaces. Note: If you want the Default realm to use LDAP authentication, remove the Default realm as described in To remove and create a Default realm on page Select One Source and click Add. 4. In Select Authentication Type, in Authentication type, choose LDAP authentication and click OK. The Realm dialog box opens. After creating the realm, configure LDAP authentication. To configure LDAP authentication 1. In IP Address or FQDN, type the IP address or Web address of the LDAP server. 2. In Port, type the port number.

72 72 Citrix Access Gateway Standard Edition Administrator s Guide The LDAP server port defaults to 389. If you are using an indexed database, such as Microsoft Active Directory with a Global Catalog, changing the LDAP server port to 3268 significantly increases the speed of the LDAP queries. If your directory is not indexed, Citrix recommends that you use an administrative connection rather than an anonymous connection from the Access Gateway to the database. Download performance improves when you use an administrative connection. 3. Do one of the following: To allow unsecure LDAP connections, select Allow unsecure connection. To secure LDAP connections, clear Allow unsecure connection. When this check box is clear, all LDAP connections are secure. 4. In Administrator bind DN, type the administrator bind DN for queries to your LDAP directory. The following are examples of syntax for bind DN: domain/user name ou=administrator,dc=ace,dc=com [email protected] (for Active Directory) cn=administrator,cn=users,dc=ace,dc=com For Active Directory, the group name specified as cn=groupname is required. The group name that is defined in the Access Gateway must be identical to the group name that is defined on the LDAP server. For other LDAP directories, the group name either is not required or, if required, is specified as ou=groupname. The Access Gateway binds to the LDAP server using the administrator credentials and then searches for the user. After locating the user, the Access Gateway unbinds the administrator credentials and rebinds with the user credentials. 5. In Administrator password, type the password. 6. In Base DN (location of users), type the base DN under which users are located. Base DN is usually derived from the Bind DN by removing the user name and specifying the group where users are located. Examples of syntax for base DN: ou=users,dc=ace,dc=com cn=users,dc=ace,dc=com

73 Chapter 6 Configuring Authentication and Authorization In Server logon name attribute, type the attribute under which the Access Gateway should look for user logon names for the LDAP server that you are configuring. The default is samaccountname. If you are using other directories, use cn. Click Submit. The Access Gateway can be configured to authenticate user access with one or more LDAP servers. If a user is not located in an LDAP directory or fails authentication on a server, the Access Gateway checks the user against the user information stored locally on the Access Gateway if Use the local user database on the Access Gateway is selected on the Settings tab. LDAP authorization requires identical group names in Active Directory, on the Access Gateway, and on the LDAP server. The characters and case must also be the same. Note: For further information to determine the LDAP server settings, see Determining Attributes in your LDAP Directory on page 76. Configuring LDAP Authorization The following is a discussion of LDAP group membership attributes that will and will not work with Access Gateway authorization. You can use the following authorization types with LDAP authentication: Local authorization LDAP authorization No authorization If you are using double-source authentication, authorization is based on the primary authentication method, not the secondary authentication method. Note: If you have added the same users to a local group on the Access Gateway and to an LDAP or Active Directory group, the Access Gateway uses the properties of both groups for authorization. The authorization type used is based on group priority. Group Memberships from Group Objects Working Evaluations LDAP servers that evaluate group memberships from group objects indirectly work with Access Gateway authorization.

74 74 Citrix Access Gateway Standard Edition Administrator s Guide Some LDAP servers enable user objects to contain information about groups to which they belong, such as Active Directory or edirectory. A user s group membership can be computable attributes from the user object, such as IBM Directory Server or Sun ONE directory server. In some LDAP servers, this attribute can be used to include a user s dynamic group membership, nesting group membership, and static group membership to locate all group memberships from a single attribute. For example, in IBM Directory Server, all group memberships, including the static, dynamic, and nested groups, can be returned using the ibm-allgroups attribute. In Sun ONE, all roles, including managed, filtered, and nested, are calculated using the nsrole attribute. Group Memberships from Group Objects Non-Working Evaluations LDAP servers that evaluate group memberships from group objects indirectly will not work with Access Gateway authorization. Some LDAP servers enable only group objects such as the Lotus Domino LDAP server to contain information about users. The LDAP server does not enable the user object to contain information about groups. For this type of LDAP server, group membership searches are performed by locating the user on the member list of groups. LDAP Authorization Group Attribute Fields The following table contains examples of LDAP group attribute fields. Microsoft Active Directory Server Novell edirectory IBM Directory Server Sun ONE directory (formerly iplanet) memberof groupmembership ibm-allgroups nsrole To configure LDAP authorization 1. Click the Authorization tab. 2. In Authorization type, select LDAP authorization. 3. In IP address or FQDN, type the IP address or Web address of the LDAP server. 4. In Port, type the port number. The default port number is Do one of the following:

75 Chapter 6 Configuring Authentication and Authorization 75 To allow unsecure LDAP connections, select Allow unsecure connection. To secure LDAP connections, clear Allow unsecure connection. When this check box is clear, all LDAP connections are secure. 6. In Administrator bind DN, type the administrator bind DN for queries to your LDAP directory. The following are examples of syntax for Bind DN: domain/user name ou=administrator,dc=ace,dc=com [email protected] (for Active Directory) cn=administrator,cn=users,dc=ace,dc=com For Active Directory, the group name specified as cn=groupname is required. The group name that is defined in the Access Gateway must be identical to the group name that is defined on the LDAP server. For other LDAP directories, the group name either is not required or, if required, is specified as ou=groupname. The Access Gateway binds to the LDAP server using the administrator credentials and then searches for the user. After locating the user, the Access Gateway unbinds the administrator credentials and rebinds with the user credentials. 7. In Administrator password, type the password. 8. In Base DN (location of users), type the base DN under which users are located. Base DN is usually derived from the bind DN by removing the user name and specifying the group where users are located. The following are examples of syntax for Base DN: ou=users,dc=ace,dc=com cn=users,dc=ace,dc=com 9. In Server logon name attribute, type the attribute under which the Access Gateway should look for user logon names for the LDAP server that you are configuring. The default is cn. If Active Directory is used, type the attribute samaccountname. 10. In Group attribute, type the name of the attribute. The default is memberof. This attribute enables the Access Gateway to obtain the groups associated with a user during authorization. Click Submit.

76 76 Citrix Access Gateway Standard Edition Administrator s Guide Using Certificates for Secure LDAP Connections You can use a secure client certificate with LDAP authentication and authorization. To use a client certificate, you must have an enterprise Certificate Authority, such as Certificate Services in Windows Server 2003, running on the same computer that is running Active Directory. You can create a client certificate using the Certificate Authority. To use a client certificate with LDAP authentication and authorization, it must be a secure certificate using SSL. Secure client certificates for LDAP are uploaded to the Access Gateway. To upload a secure client certificate for LDAP 1. On the Access Gateway Cluster tab, open the window for the Access Gateway, and click the Administration tab. 2. Next to Upload a.pem private key and signed certificate, click Browse. 3. Navigate to the client certificate and click Open. Determining Attributes in your LDAP Directory If you need help determining your LDAP directory attributes, you can easily look them up with the free LDAP browser from Softerra. You can download the LDAP browser from the Softerra LDAP Administrator Web site at After the browser is installed, set the following attributes: The host name or IP address of your LDAP server. The port of your LDAP server. The default is 389. The base DN field can be left blank. The information provided by the LDAP browser can help you determine the base DN needed for the Authentication tab. The Anonymous Bind check determines if the LDAP server requires user credentials to connect to it. If the LDAP server requires credentials, leave the check box cleared. After completing the settings, the LDAP browser displays the profile name in the left pane and connects to the LDAP server.

77 Chapter 6 Configuring Authentication and Authorization 77 Configuring RADIUS Authentication and Authorization You can configure the Access Gateway to authenticate user access with one or more RADIUS servers. For each RADIUS realm that you use for authentication, you can configure both primary and secondary RADIUS servers. If the primary RADIUS server is unavailable, the Access Gateway attempts to authenticate against the secondary RADIUS server for that realm. If a user is not located on the RADIUS servers or fails authentication, the Access Gateway checks the user against the user information stored locally on the Access Gateway if the Use the local user database on the Access Gateway check box is selected on the Settings tab of the realm. The Access Gateway software also includes RADIUS authorization, which is configured using Remote Access Policy in Microsoft Internet Authentication Service (IAS). During configuration of the Access Gateway, the following information needs to be provided: Vendor ID is the vendor-specific code number that was entered in IAS. Type is the vendor-assigned attribute number. Attribute name is the type of attribute name that is defined in IAS. The default name is CTXSUserGroups=. Separator is defined if multiple user groups are included in the RADIUS configuration. A separator can be a space, a period, a semicolon, or a colon. If IAS is not installed on the RADIUS server, you can install it from the Add/Remove Programs in Control Panel. For more information, see the Windows online Help. To configure IAS, use the Microsoft Management Console (MMC) and install the snap-in for IAS. Follow the wizard, making sure you select the following settings: Select local computer. Select Remote Access Policies and create a custom policy. Select Windows-Groups for the policy. Select Encrypted Authentication (CHAP) and Unencrypted Authentication (PAP and SPAP). Do not select MS-CHAP v2 and MS-CHAP. Select the Vendor-Specific Attribute. The Access Gateway needs the Vendor-Specific Attribute to match the users defined in the group on the server with those on the Access Gateway.

78 78 Citrix Access Gateway Standard Edition Administrator s Guide This is done by sending the Vendor-Specific Attributes to the Access Gateway. Make sure you select RADIUS=Standard. The RADIUS default is 0. Use this number for the vendor code. The vendor-assigned attribute number is 0. This is the assigned number for the User Group attribute. The attribute is in string format. Select String for the Attribute format. The Attribute value requires the attribute name and the groups. For the Access Gateway, the attribute value is CTXSUserGroups=groupname. If two groups are defined, such as sales and finance, the attribute value is CTXSUserGroups=sales;finance. Separate each group with a semicolon. Remove all other entries in the Edit Dial-in Profile dialog box, leaving the one that says Vendor-Specific. When you are finished configuring the Remote Access Policy in IAS, go to the Access Gateway and configure the RADIUS authentication and authorization. To configure RADIUS authentication 1. Click the Authentication tab. 2. In Realm name, type a name for the authentication realm, select One Source, and then click Add. Note: If you want the Default realm to use RADIUS authentication, remove the Default realm as described in To remove and create a Default realm on page 65. If your site has multiple authentication realms, use a name that identifies the RADIUS realm for which you will specify settings. Realm names are case-sensitive and can contain spaces. 3. In Authentication type, choose RADIUS authentication and click OK. The dialog box for the authentication realm opens. 4. In IP address, type the IP address of the RADIUS server. 5. In Port, type the port number. The default port number is In Server secret, type the RADIUS server secret.

79 Chapter 6 Configuring Authentication and Authorization 79 The server secret is configured manually on the RADIUS server and on the Access Gateway. Important: Make sure you use a strong server secret. A secret is one that is at least eight characters and includes a combination of letters, numbers, and symbols. 7. If you use a secondary RADIUS server, enter its IP address, port, and server secret. To configure Advanced Options, see Configuring Advanced Options for Authentication on page 89. RADIUS Authorization You can use the following authorization types with RADIUS authentication: RADIUS authorization Local authorization LDAP authorization No authorization To configure RADIUS authorization 1. Click the Authentication tab and open the realm for which you want to configure RADIUS authorization. 2. Click the Authorization tab and in Authorization type, select RADIUS authorization. 3. Complete the settings using the attributes defined in IAS. 4. Click Submit. Note: If you are using Microsoft Internet Authentication Service (IAS) as a RADIUS server and receive a bad user name or password error message when the Access Gateway sends a request to the configured RADIUS server, in IAS Remote Access Policies, under the applied policy s properties on the Authentication tab, select Unencrypted Authentication (PAP, SPAP).

80 80 Citrix Access Gateway Standard Edition Administrator s Guide Choosing RADIUS Authentication Protocols The Access Gateway supports implementations of RADIUS that are configured to use the Password Authentication Protocol (PAP) for user authentication. Other authentication protocols such as the Challenge-Handshake Authentication Protocol (CHAP) are not supported. If your deployment of Access Gateway is configured to use RADIUS authentication and your RADIUS server is configured to use PAP, you can strengthen user authentication by assigning a strong shared secret to the RADIUS server. Strong RADIUS shared secrets consist of random sequences of uppercase and lowercase letters, numbers, and punctuation and are at least 22 keyboard characters long. If possible, use a random character generation program to determine RADIUS shared secrets. To further protect RADIUS traffic, assign a different shared secret to each Access Gateway appliance. When you define users on the RADIUS server, you can also assign a separate shared secret to each user. If you do this, you must configure separately each Access Gateway realm that uses RADIUS authentication. If you synchronize configurations among several Access Gateway appliances in a cluster, all the appliances are configured with the same secret. Shared secrets are configured on the Access Gateway when a RADIUS realm is created. Note: If you are using Access Gateway Advanced Edition, before you assign RADIUS shared secrets, you must configure a RADIUS authentication profile on the servers running the Advanced Access Control software that use RADIUS to authenticate users. For more information about authentication profiles, see the Access Gateway Advanced Edition Administrator s Guide. Configuring RSA SecurID Authentication If your site uses an RSA ACE/Server and RSA SecurID for authentication, you can configure the Access Gateway to authenticate user access with the RSA ACE/Server. The Access Gateway acts as an RSA Agent Host, authenticating on behalf of the users who use Citrix Access Gateway Plug-in to log on. Multiple RSA realms can be configured on the Access Gateway. Each RSA realm must use the same sdconf.rec file and point to one RSA ACE/Server.

81 Chapter 6 Configuring Authentication and Authorization 81 The Access Gateway supports RSA ACE/Server Version 5.2 and higher. The Access Gateway also supports replication servers. Replication server configuration is completed on the RSA ACE/Server and is part of the sdconf.rec file that is uploaded to the Access Gateway. If this is configured on the RSA ACE/Server, the Access Gateway attempts to connect to the replication servers if there is a failure or network connection loss with the primary server. Note: If you are running a RADIUS server on an RSA server, configure RADIUS authentication as described in Configuring RADIUS Authentication and Authorization on page 77. If a user is not located on the RSA ACE/Server or fails authentication on that server, the Access Gateway checks the user against the user information stored locally on the Access Gateway if the check box Use the local user database on the Access Gateway is checked on the Settings tab. The Access Gateway supports Next Token Mode. If a user enters three incorrect passwords, the Access Gateway Plug-in prompts the user to wait until the next token is active before logging on. The RSA server can be configured to disable a user s account if a user logs on too many times with an incorrect password. To contact the RSA ACE/Server, the Access Gateway must include a copy of the ACE Agent Host sdconf.rec configuration file that is generated by the RSA ACE/Server. The following procedures describe how to generate and upload that file. Note: The following steps describe the required settings for the Access Gateway. Your site might have additional requirements. Refer to the RSA ACE/ Server product documentation for more information. When creating the sdconf.rec file, use the following information as a guideline for the settings: Create an Agent Host. Create a descriptive name for the Access Gateway, which is the Agent Host for which you are creating the configuration file. Use the internal Access Gateway IP address for the the network address. The agent type is UNIX Agent. When you are creating the Agent Host, make sure that the Node Secret Created check box on the RSA ACE/Server is cleared. The RSA ACE/ Server sends the Node Secret to the Access Gateway the first time that it authenticates a request from the Access Gateway. After that, the Node

82 82 Citrix Access Gateway Standard Edition Administrator s Guide Secret Created check box is selected. By clearing the check box and generating and uploading a new configuration file, you can force the RSA ACE/Server to send a new Node Secret to the Access Gateway. There are two ways you can indicate which users can be authenticated through the Access Gateway: Configure the Access Gateway as an open Agent Host that is open to all locally known users Select the users to be authenticated by editing the Agent Host and selecting the users to be activated After you have created the settings on the RSA server, create the sdconf.rec file. The file that you generate (sdconf.rec) is uploaded to the Access Gateway. For more information about configuring settings on the RSA server, see the manufacturer s documentation. To configure RSA SecurID authentication 1. Click the Authentication tab. 2. Under Add an Authentication Realm, in Realm Name, type a name to identify the RSA ACE/Server. 3. Select One Source and click Add. Note: If you want the Default realm to use RSA authentication, remove the Default realm as described in To remove and create a Default realm on page In the Select Authentication Type dialog box, in Authentication type, select RSA SecurID authentication and click OK. Caution: If an invalid sdconf.rec file is uploaded to the Access Gateway, it might cause the Access Gateway to send out messages to non-existent IP addresses. This might be flagged by a network monitor as network spamming. 5. To upload the sdconf.rec file that you generated in the previous procedure, on the Authentication tab, click Upload sdconf.rec File and navigate to the file, and then click Open. The sdconf.rec file is typically written to ace\data\config_files and to windows\system32.

83 Chapter 6 Configuring Authentication and Authorization 83 The file status message indicates whether or not an sdconf.rec file was uploaded. If one was uploaded and you need to replace it, click Upload sdconf.rec file. Navigate to the file and click Open to upload the file. The first time that a user is successfully authenticated, the RSA ACE/Server writes some configuration files to the Access Gateway. If you subsequently change the IP address of the Access Gateway, click Remove ACE Configuration Files, restart when prompted, and then upload a new sdconf.rec file. The files that are removed are sdconf.rec, securid, and sdstatus. 6. Click Submit. You can use the following authorization types with RSA SecureID authentication: RADIUS authorization Local authorization LDAP authorization No authorization Configuring RSA Settings for a Cluster If you have two or more appliances configured as a cluster, the sdconf.rec file needs to contain the FQDNs of all the appliances. The sdconf.rec file is installed on one Access Gateway and then published. This allows all of the appliances to connect to the RSA server. You can also limit connections to the RSA server from user connections. For example, you have three appliances in your cluster. If the FQDNs of the first and second appliances are included in the sdconf.rec file and the third appliance is not, users can connect only to the RSA server using the first two appliances. Resetting the Node Secret If you reimaged the Access Gateway, giving it the same IP address as before, and restored your configuration, you must also reset the Node Secret on the RSA ACE/Server. Because the Access Gateway was reimaged, the Node Secret no longer resides on it and an attempt to authenticate with the RSA ACE/Server fails. After you reset the server secret on the RSA ACE/Server, the next authentication attempt prompts the RSA ACE/Server to send a Node Secret to the Access Gateway.

84 84 Citrix Access Gateway Standard Edition Administrator s Guide Configuring Secure Computing SafeWord Authentication The Secure Computing SafeWord product line provides secure authentication using a token-based passcode. After the passcode is used, it is immediately invalidated by SafeWord and cannot be used again. If the Access Gateway is replacing the Secure Gateway in a Secure Gateway and Web Interface deployment, you can choose to not configure authentication on the Access Gateway and continue to allow the Web Interface to provide SafeWord authentication for incoming HTTP traffic. For more information about configuring the Web Interface, see the Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop. The Access Gateway supports SafeWord authentication to the following Secure Computing products: SafeWord PremierAccess SafeWord for Citrix SafeWord RemoteAccess Configuring the Access Gateway to authenticate using Secure Computing s SafeWord products can be done in several ways: Configure authentication to use a PremierAccess RADIUS server that is installed as part of SafeWord PremierAccess and allow it to handle authentication. Configure authentication to use the SafeWord IAS agent, which is a component of SafeWord RemoteAccess, SafeWord for Citrix, and SafeWord PremierAccess 4.0. Install the SafeWord Web Interface Agent to work with the Citrix Web Interface. Authentication does not have to be configured on the Access Gateway and can be handled by the Citrix Web Interface. This configuration does not use the PremierAccess RADIUS server or the SafeWord IAS Agent. Configuring SafeWord Settings on the Access Gateway When configuring the SafeWord server, you need the following information: The IP address of the Access Gateway. This should be the same as what is configured on the RADIUS server client configuration. A shared secret. This secret is also configured on the Authentication tab on the Access Gateway.

85 Chapter 6 Configuring Authentication and Authorization 85 The IP address and port of the SafeWord server. Configure a SafeWord realm to authenticate users. The Access Gateway acts as a SafeWord agent authenticating on behalf of users logged on using the Access Gateway Plug-in. If a user is not located on the SafeWord server or fails authentication, the Access Gateway checks the user against the local user list if Use the local user database on the Access Gateway is selected on the Settings tab. To use SafeWord as the Default realm, remove the current Default realm and create a new one as described in To remove and create a Default realm on page 65. To configure SafeWord on the Access Gateway 1. In the Administration Tool, click the Authentication tab. 2. Under Add an Authentication Realm, in Realm name, type a name. 3. Select One Source and then click Add. 4. In Authentication type, select SafeWord authentication and click OK. 5. For the Primary SafeWord server Settings, enter the following settings: In IP address, type the IP address of the SafeWord server. In Port, type the port number for the SafeWord RADIUS server. The default is This port must match the number you configured on the RADIUS server. In Server secret, enter a RADIUS shared secret. The shared secret must match what is configured on the RADIUS server. 6. If there is a second SafeWord server, configure the settings in Secondary SafeWord Server Settings. Configuring Authorization with SafeWord If you are using SafeWord for authentication, you can use the following authorization types: LDAP Local user list RADIUS No authorization

86 86 Citrix Access Gateway Standard Edition Administrator s Guide To configure LDAP authorization, see Configuring LDAP Authorization on page 73. To configure RADIUS authorization see Configuring RADIUS Authentication and Authorization on page 77. SafeWord can be configured to return the group membership attributes by configuring the SafeWord server. For more information, see the product documentation. Configuring Gemalto Protiva Authentication Protiva is a strong authentication platform that was developed to use the strengths of Gemalto s smart card authentication. With Protiva, users log on with a user name, password, and one-time password generated by the Protiva device. Similar to RSA SecurID, the authentication request is sent to the Protiva Authentication Server and the password is either validated or rejected. Configuring Gemalto Protiva Settings To configure Gemalto Protiva to work with the Access Gateway, use the following guidelines: Install the Protiva server. Install the Protiva Internet Authentication Server (IAS) agent plug-in on a Microsoft IAS RADIUS server. Make sure you note the IP address and port number of the IAS server Configure a realm on the Access Gateway to use RADIUS authentication and enter the settings of the Protiva server. To configure a Gemalto Protiva realm 1. In the Administration Tool, click the Authentication tab. 2. Under Add an Authentication Realm, in Realm name, type a name. 3. Select One Source and then click Add. Note: If you are configuring double-source authentication, click Two Source and then click Add. For more information about configuring double-source authentication, see Configuring Double-Source Authentication on page In Select Authentication Type, next to Authentication type, select Gemalto authentication and click OK. 5. In IP address type the IP address of the RADIUS IAS server.

87 Chapter 6 Configuring Authentication and Authorization In Port, type the port number. 7. In Server secret, type the node secret of the RADIUS IAS server and click Submit. Configuring NTLM Authentication and Authorization You can configure the Access Gateway to use Windows NT LAN Manager (NTLM) authentication to authenticate users against the user database on a Windows NT 4.0 domain controller. If a user is not located in the user database on the Windows NT 4.0 domain controllers, or fails authentication, the Access Gateway can check for the user name in the Local Users list on the Access Gateway and authenticate the user against the local list if Use the local user database on the Access Gateway check box is selected on the Settings tab. A Windows NT 4.0 domain controller maintains domain user accounts in a database on the Windows NT 4.0 server. A domain user account includes a user name and password and other information about the user. To configure NTLM authentication, you create an NTLM authentication realm that includes the address and port that the Access Gateway uses to connect to the Windows NT 4.0 domain controller. You also specify a time-out value in which an authentication attempt to the server must complete. When a user logs on to the Access Gateway, the user enters the user name and password maintained in the domain user account on the Windows NT 4.0 server. The Access Gateway connects to the Windows NT 4.0 server and passes these credentials to the server. The server authenticates the user. To configure NTLM authentication 1. Click the Authentication tab. 2. Under Add an Authentication Realm, in Realm name, type a name for the authentication realm. If your site has multiple authentication realms, you might use a name that identifies the NTLM realm for which you specify settings. Realm names are case-sensitive and can contain spaces. Note: If you want the Default realm to use NTLM authentication, remove the Default realm as described in To remove and create a Default realm on page Select One Source and click Add.

88 88 Citrix Access Gateway Standard Edition Administrator s Guide 4. In Select Authentication Type, in Authentication type, choose NTLM authentication and click OK. 5. In the realm dialog box, in IP address or FQDN, type the IP address of the Windows NT 4.0 domain controller. 6. In Port, type the port number on which the Windows NT 4.0 domain controller listens for the NTLM authentication connection. The default port entry for NTLM authentication connections is 139. Note: When 0 (zero) is entered as the port, the Access Gateway attempts to automatically detect a port number for this connection. 7. In Time-out (in seconds), enter the number of seconds within which the authentication attempt must complete. If the authentication does not complete within this time interval, it fails and click Submit. Configuring NTLM Authorization A Windows NT 4.0 domain controller maintains group accounts. A group account is a collection of individual user domain accounts (and other accounts). To configure NTLM authorization, you click the Authorization tab in the authentication realm and enter the address and port that the Access Gateway uses to connect to the Windows NT 4.0 domain controller. You also specify a time-out value in which an authorization attempt to the Windows NT server must complete. After a user successfully authenticates, the domain controller returns to the Access Gateway a list of all global groups of which the authenticated user is a member. The Access Gateway then looks for a user group name on the Access Gateway that matches the name of a Windows NT 4.0 global group to which the user belongs. If the Access Gateway finds a match, the user is granted the authorization privileges to the internal networks that are associated with the user group on the Access Gateway. To configure NTLM authorization 1. Click the Authentication tab and open the authentication realm for which you want to enable NTLM authorization. 2. Click the Authorization tab. 3. In Authorization type, select NTLM authorization.

89 Chapter 6 Configuring Authentication and Authorization In Server IP Address or FQDN, type the FQDN or IP address of the Windows NT 4.0 domain controller that will perform the NTLM authorization. 5. In Server Port, type the port number. The default port entry for NTLM authentication connections is 139. Note: When 0 (zero) is entered as the port, the Access Gateway attempts to automatically detect a port number for this connection. 6. In Time-out (in seconds), enter the number of seconds within which the authorization attempt must complete before the authentication attempt is abandoned. 7. Click Submit. Configuring Advanced Options for Authentication If you are configuring RADIUS, SafeWord or Gemalto Protiva authentication, you can configure advanced options for these authentication types. Advanced options include: Configuring the user name prefix Configuring one-time passwords Hiding the verify response prompt These options are configured within the authentication realm for each authentication type. Configuring the User Name Prefix You can configure the authentication policy to have users log on using the user principle name (UPN)) with a format of [email protected]. If you are configuring the UPN for LDAP authentication, in the LDAP authentication realm, in Administrator bind DN, type [email protected], where domainname.com is the name of your domain. In Server logon name attribute, type UserPrincipalName. If you are using RADIUS, SafeWord, or Gemalto Protiva, in the authentication realm, under Advanced Options, type [email protected].

90 90 Citrix Access Gateway Standard Edition Administrator s Guide Configuring Authentication to use One-Time Passwords If authentication on the Access Gateway is configured to use a one-time password with RADIUS, such as provided by an RSA SecurID token, the Access Gateway attempts to reauthenticate users using the cached password. This occurs when changes are made to the Access Gateway using the Administration Tool or if the connection between the Access Gateway Plug-in and the Access Gateway is interrupted and then restored. This can also occur when user connections are configured to use Citrix XenApp Plug-ins and connect to the Web Interface using RADIUS or LDAP. When a user starts an application and uses it, then returns to the Web Interface to start another application, the Access Gateway uses cached information to authenticate the user. You can prevent the storage of one-time passwords in the cache, which forces the user to enter their credentials again. If you are using RSA SecurID, Gemalto Protiva or SafeWord as your authentication type, this setting is enabled by default and cannot be changed. If you are using RADIUS, this setting is disabled by default and you can enable it. To prevent caching of one-time passwords 1. In the Administration Tool, click the Authentication tab. 2. Open the authentication realm that uses the one-time password. 3. Select Use the password one time and click Submit. Hiding the Verify Response Prompt If you are using RADIUS authentication and your deployment includes a user challenge response, users can receive two verification prompts for the response. You can prevent the second prompt from appearing using this setting. This includes RADIUS deployments with SafeWord and Gemalto Protiva. To hide the response prompt In the RADIUS, SafeWord, or Gemalto Protiva authentication realm, under Advanced Options, select Hide the Verify Response prompt and click Submit. Configuring Double-Source Authentication The Access Gateway supports double-source authentication that requires users to log on using two authentication types. On the Authentication tab, you can configure two types of authentication, such as LDAP and SafeWord for one realm.

91 Chapter 6 Configuring Authentication and Authorization 91 The Default realm can be configured for double-source authentication. There can be a mix of single and double-source authentication realms. For example, you can have one or more realms for single authentication and then have one or more realms configured for double-source authentication. In a mixed authentication environment, when users log on they see two password fields. If users log on using only one authentication type, the second password field is left blank. To create and configure a double-source authentication realm 1. Click the Authentication tab. 2. Under Add an Authentication Realm, in Realm name, type a name. 3. Select Two Source and then click Add. 4. In the Select Authentication Type dialog box, select the authentication types in Primary authentication type and Secondary authentication type. Click OK. 5. On the Primary Authentication tab, configure the settings for the first authentication type and click Submit. 6. On the Secondary Authentication tab, configure the settings for the second authentication type and click Submit. 7. On the Authorization tab, in Authorization type, select the authorization type you want to use, configure the settings, and click Submit. Double-source authentication checks the primary authentication first. If that passes, then the secondary authentication type is checked. For example, if you configured RSA SecurID on the Secondary Authentication tab and LDAP on the Primary Authentication tab, when users log on, they type their LDAP password in the first password field and the RSA SecurID personal identification number (PIN) and passcode in the second password field. When users click Connect, the Access Gateway authenticates using the LDAP password first and then the RSA SecureID PIN and passcode second.

92 92 Citrix Access Gateway Standard Edition Administrator s Guide Changing Password Labels You can change the password labels to accurately reflect the authentication type with which the user is logging on and to provide the correct prompt for what the user needs to type. This is useful when the Access Gateway is configured to support third-party authentication types. For example, if users are required to authenticate using LDAP and Gemalto Protiva strong authentication system (RADIUS), you can change the password labels to reflect what the user needs to type in the fields. Instead of the labels, Password and Secondary Password, the labels could be Windows domain password and Gemalto Protiva passcode. The labels can be changed if you are using one-source or double-source authentication. To change the password labels 1. Click the Authentication tab, and under Add an Authentication Realm, click Advanced. 2. In Password label and Secondary password label, type the values for the labels. 3. Click OK When users log on, they see the new password labels.

93 CHAPTER 7 Configuring Network Access and Group Resources Users connect to internal resources using network access. You can grant or deny access to any subnet on your network. For example, you can allow a user access to one file share on your network, or allow the user complete access to all the resources on the network. When you configure network access and group resources, you are configuring access control lists (ACLs). Based on these, you can control the resources users can access when connecting to your secure network. In This Chapter Configuring Network Routing Providing Network Access to Users Configuring User Groups Configuring Resources for a User Group Configuring Network Resources Setting Application Policies Configuring Endpoint Policies and Resources Setting the Priority of Groups Configuring the Access Gateway to work with Citrix Branch Repeater Configuring Network Routing To provide access to internal network resources, the Access Gateway must be capable of routing data to the internal networks. The networks to which the Access Gateway can route data are determined by the configuration of the Access Gateway routing table and the default gateway specified for the Access Gateway.

94 94 Citrix Access Gateway Standard Edition Administrator s Guide When the Access Gateway receives a packet, it checks its routing table. If the destination address of the packet is within a network for which a route exists in the routing table, the packet is routed to that network. If the Access Gateway receives a packet, and its routing table does not contain a route for the destination address of the packet, the Access Gateway sends the packet from authenticated users to the Default Gateway. The routing capabilities of the Default Gateway then determine how the packet is routed. The Access Gateway routing table must contain the routes necessary to route data to any internal network resource that a user may need to access. You control how the Access Gateway routing tables are configured. You can select a Routing Information Protocol (RIP) option so that the routes are configured automatically by a RIP server, or you can select a static routing option and manually configure the routes. For more information, see Configuring Dynamic and Static Routes on page 53. Providing Network Access to Users The network resources that you allow users to access must reside in a network to which the Access Gateway can route data. You can configure the Access Gateway to use either dynamic or static routes to route data to the internal network resources. With the Access Gateway, you can take a granular approach to providing access to network resources for the users. You control user access to network resources as follows: You create network resource groups. A network resource group includes one or more network locations. Generally, a network resource group is some subset of all of the network resources to which the Access Gateway can route data. For example, a resource group might provide access to a single application, a subset of applications, a range of IP addresses, or an entire intranet. What you include in a network resource group depends largely on the different access requirements of your users. You might want to provide some user groups with access to many resources and other user groups with access to smaller subsets of resources. By allowing and denying a user group access to network resource groups, you create an access control list (ACL) for that user group. You specify whether or not any user group without an ACL has full access to any resource in a network to which the Access Gateway can route data. By default, user groups without an ACL have access to any resource in any network to which the Access Gateway can route data. This default

95 Chapter 7 Configuring Network Access and Group Resources 95 operation provides simple configuration if most of your user groups are to have full network access. By retaining this default operation, you need to configure an ACL only for the user groups that require more restricted access. The default operation can also be useful for initial testing of your deployment. You can change the default operation so that user groups are denied network access unless they are specifically allowed access to one or more network resource groups. You configure ACLs for user groups by specifying which network resources are allowed or denied per user group. By default, all network resource groups are allowed and network access is controlled by the Deny Access without access control list (ACL) option on the Global Cluster Policies tab. When you allow or deny one resource group, all other resource groups are denied automatically and the network access for the user group is controlled only through its ACL. If a resource group includes a resource that you do not want a user group to access, you can create a separate resource group for just that resource and deny the user group access to it. The options just discussed are summarized in the following table. ACL set for user group? Deny access without ACL? User group can access: No No Any network accessible to the Access Gateway Yes No Allowed resource groups No Yes Nothing on the network Yes Yes Allowed resource groups When configuring network access, the most restrictive policy must be configured first and the least restrictive last; for example, you want to allow access to everything on the 10.0.x.x network, but need to deny access to the x network. Configure network access to x first and then configure access to the 10.0.x.x network. Enabling Split Tunneling and Accessible Networks You can enable split tunneling on the Global Cluster Policies tab to prevent the Access Gateway Plug-in from sending unnecessary network traffic to the Access Gateway.

96 96 Citrix Access Gateway Standard Edition Administrator s Guide When split tunneling is not enabled, the Access Gateway Plug-in captures all network traffic originating from a client device, and sends the traffic through the VPN tunnel to the Access Gateway. If you enable split tunneling, the Access Gateway Plug-in sends only traffic destined for networks protected by the Access Gateway through the VPN tunnel. The Access Gateway Plug-in does not send network traffic destined for unprotected networks to the Access Gateway. When you enable split tunneling, you must enter a list of accessible networks on the Global Cluster Policies tab. The list of accessible networks must include all internal networks and subnetworks that the user may need to access with the Access Gateway Plug-in. The Access Gateway Plug-in uses the list of accessible networks as a filter to determine whether or not packets transmitted from the client device should be sent to the Access Gateway. When the Access Gateway Plug-in starts, it obtains the list of accessible networks from the Access Gateway. The Access Gateway Plug-in examines all packets transmitted on the network from the client device and compares the addresses within the packets to the list of accessible networks. If the destination address in the packet is within one of the accessible networks, the Access Gateway Plug-in sends the packet through the VPN tunnel to the Access Gateway. If the destination address is not in an accessible network, the packet is not encrypted and the plug-in routes the packet appropriately. Note: If users are going to connect to published applications in a server farm using Citrix XenApp Plug-ins, split tunneling does not need to be configured. To enable split tunneling and accessible networks 1. Click the Global Cluster Policies tab. 2. Under Access options, click Enable split tunneling. 3. In Accessible networks, type the list of networks that contain network resources that users must access with the Access Gateway Plug-in. Use a space or carriage return to separate the list of networks. 4. Click Submit.

97 Configuring User Groups Chapter 7 Configuring Network Access and Group Resources 97 User groups define the resources the user has access to when connecting to the secure network through the Access Gateway. Groups are associated with the local users list. After adding local users to a group, you can then define the resources they have access to on the Access Policy Manager tab. For more information about configuring local users, see Configuring Local Users on page 68. When you enable authorization on the Access Gateway, user group information is obtained from the authentication server after a user is authenticated. If the group name that is obtained from the authentication server matches a group name created locally on the Access Gateway, the properties of the local group are used for the matching group obtained from the authentication servers. Important: Group names on authentication servers and on the Access Gateway must be identical and they are case-sensitive. Configuring Access Control Lists Each user should belong to at least one group that is defined locally on the Access Gateway. If a user does not belong to a group, the overall access of the user is determined by using access control lists (ACLs) that are defined by the Deny access without access control list (ACL) setting as follows: If the Deny Access option is enabled, the user cannot establish a connection If the Deny Access option is disabled, the user has full network access To deny access to user groups without an ACL 1. Click the Global Cluster Policies tab. 2. Under Access options, select Deny access without access control list (ACL) and click Submit. Creating Local User Groups You can also add local groups that are not related to groups on authentication servers. For example, you might create a local group to set up a contractor or visitor to whom you want to provide temporary access without having to create an entry on the authentication server. For information about creating a local user, see Configuring Local Users on page 68.

98 98 Citrix Access Gateway Standard Edition Administrator s Guide Note: If you create a user group that has more than 127 characters and then delete that user group, it still appears on the Group Priority tab after deletion. To resolve this problem, user group names should have fewer than 127 characters. Any characters over this limit are truncated. Configuring Resource Groups Several aspects of Access Gateway operation are configured at the group level. These are separated between group properties and group resources. Group properties include: Groups that inherit properties from the Default group. Requiring users to log on again if there is a network interruption or if the computer is coming out of standby or hibernate. Enabling single sign-on to Windows. Enabling single sign-on to the Web Interface. Running logon scripts when a user logs on using domain credentials. Denying application access to the network that does not have a defined application policy. Access configuration to specify the length of time a session is active. There are three types of session time-outs: User session time-out, which specifies the length of time a user can stay logged on, whether there is activity or not. The specified time is absolute. If the user has a 60 minute session time-out, the session ends at 60 minutes. Users are given a one minute warning that their session is about to end. Network activity time-out where the user is logged off after a specified amount of time, during which network activity from the client device over the VPN tunnel is not detected. Network activity from the local area network is not considered. Idle session time-out where network activity is detected, but user activity is not detected. User activities are keyboard strokes or mouse movement. Enabling split DNS where the client device sends name resolution requests to the Access Gateway DNS server as well as the client s local DNS server.

99 Chapter 7 Configuring Network Access and Group Resources 99 IP pooling where a unique IP address is assigned to each client. Logon and portal page usage that defines the page the user sees when logging on. The logon page can be a page provided by Citrix and can be modified for individual companies. If your company is using Citrix XenApp or Citrix XenDesktop, the logon page can be the Web Interface. If you want to give the user options of how to log on, use the client choices page. For more information, see Configuring a Portal Page with Multiple Logon Options on page 148. Group resources include: Network resources that define the networks to which users can connect. Application policies that define the applications users can use when connected. In addition to selecting the application, you can further define which networks the application has access to and if any endpoint policies need to be met when connecting. Endpoint resources and policies that define the required and optional parameters that must be on the user s computer when logging on. If a user belongs to more than one group, group policies are applied to the user based on the group priorities set on the Group Priority tab, as described in Setting the Priority of Groups on page 111. Creating User Groups User groups are created on the Access Policy Manager tab. Multiple user groups can be created and configured. When a new group is created, the properties page appears that allows you to configure the settings for the group. After the settings are complete, resources can be added to the group. To create a local user group on the Access Gateway 1. Click the Access Policy Manager tab. 2. In the left pane, right-click User Groups and then click New Group. In Group Name, type a descriptive name for the group, such as Temp Employees or accounting and then click OK. Important: If you want the group s properties to be used for authentication obtained from authentication servers, the group name must match the authentication server group name, including case and use of spaces. A dialog box for the added group appears.

100 100 Citrix Access Gateway Standard Edition Administrator s Guide 3. To configure the group, see Configuring Resources for a User Group on page 100. To remove a user group On the Access Policy Manager tab, in the left-pane, right-click a group and then click Delete. Default Group Properties If the only group that is configured on the Access Gateway is the Default user group, all local users receive the settings configured for this group. You can control access to the Default user group settings by configuring additional groups on the Access Gateway and then restricting access to the Default user group. For example, two users are part of a group for contractors. They are allowed to connect to specific internal resources, such as an Exchange server and a file server. If they inherit the settings from the Default group, you might have unintentionally configured these users to have access to resources that are only for permanent employees. You can allow or deny users to inherit the Default group settings in the user group properties. This check box is not available for the Default group. To enable or disable Default group properties 1. Click the Access Policy Manager tab. 2. In the left pane, right-click the user group and click Properties. 3. On the General tab, do one of the following: To prevent users from inheriting the Default group settings, clear Inherit properties from the Default group To allow users to inherit the Default group settings, select Inherit properties from the Default group 4. Click OK. Configuring Resources for a User Group Resources for user groups are configured in the right pane on the Access Policy Manager tab. The resources include: Network Resources Application Policies Endpoint Resources

101 Chapter 7 Configuring Network Access and Group Resources 101 Endpoint Policies After you configure settings, drag the resource policy to the group in the left pane. For example, you configured and saved a network resource specifying the networks to which users can connect. If you have a restricted group for contractors, drag the resource to this group and then deny access from the Default group. If you created an endpoint policy, you can add it to Pre-Authentication Policies and Endpoint Policies for a group in the left pane. For each user group, you can create an access control list (ACL) by specifying the resources that are to be allowed or denied for the group as described in Providing Network Access to Users on page 94. ACLs for all groups that users are a part of are combined and applied to the user. Unless you want to provide all users with full access to all accessible networks, you must associate user groups with resource groups. Configuring User Membership in Multiple Groups When a user is a member of multiple groups, some group settings are unioned together. These settings are: Network Resources Application Policies Endpoint Policies Exceptions to the unioned settings are: Deny applications without policies. If any of the groups that a user is a member of has the Deny applications without policies check box selected, the user inherits that setting. IP pooling. Users assume the IP address from the highest priority group that has IP pools enabled. Inherit Default group settings. If any of the groups that a user is a part of has the Inherit properties from the Default Group check box selected, the user inherits the Default group settings. Settings that are not unioned are based on group priority. These include: Authenticating after network interruption or on system resume Enabling single sign-on to Windows Running logon scripts Session time-out

102 102 Citrix Access Gateway Standard Edition Administrator s Guide Split DNS Access Gateway portal page Configuring Network Resources Network resources define the locations on the secure network that authorized users can access. Resource groups are associated with user groups to form resource access control policies. Network topology for resource groups and authentication. Suppose that you want to provide a user group with secure access to the following: The x.x subnet The x subnet The IP addresses of and To provide that access, create a network resource group by specifying the following IP address/subnet pairs: / / / /

103 Chapter 7 Configuring Network Access and Group Resources 103 You can specify the mask in Classless Inter Domain Routing (CIDR) notation. For example, you could specify /32 for the last entry. Additional tips for working with resource groups follow. You can further restrict access by specifying a port, a port range, and protocol for an IP address/subnet pair. For example, you might specify that a resource can use only port 80 and the TCP protocol. When you configure resource group access for a user group, you can allow or deny access to any resource group. This enables you to exclude a portion of an otherwise allowed resource. For example, you might want to allow a user group access to /24 but deny that user group access to Deny rules take precedence over allow rules. The easiest method to provide all user groups with access to all network resources is to not create any resource groups and to disable the Deny access without access control list (ACL) option on the Global Cluster Policies tab. All user groups then have access to any network resource that is accessible through the Access Gateway. If you have one or more user groups that should have access to all network resources, create a resource group for / and allow that one resource group for those user groups. For all other user groups, you will need to allow or deny individual resource groups as needed. To create and configure a network resource 1. Click the Access Policy Manager tab. 2. In the right pane, right-click Network Resources and then click New Network Resource. 3. Type a name for the group and click OK. 4. In Network and subnet mask, type the IP address/subnet pair for the resource in the Subnets field. You can use CIDR notation for the mask. Use a space to separate entries. 5. In Port or port range, enter the port or ports that the Access Gateway can use to establish connections with the network resource(s). You have these options when entering ports: Enter a 0 (zero) to use all ports. Enter a single port or multiple ports that are not in a range. If you enter multiple ports, separate each port with a comma. For example, to allow connections on ports 22, 80, and 8088, type: 22, 80, 8080

104 104 Citrix Access Gateway Standard Edition Administrator s Guide Enter a range of ports. Separate the starting and ending ports in the range with a hyphen (-). For example, to allow connections on any port from 110 through 120, type: You can also enter a combination of single ports and a port range. For example, to allow connections on ports 22, 80, 8088 and 110 through 120, type: 22, 80, 8080, In Protocol, select the protocols that can be used to establish connections on the specified ports and click OK. To add a network resource to a group On the Access Policy Manager tab, in the right-pane, under Network Resources, click the resource you want to add and then drag it to the user group in the left pane. Allowing and Denying Network Resources and Application Policies By default, all network resources and application policies are allowed. When you deny one resource group, all other resource groups are denied automatically and the network access for the user group is controlled only through its ACL. The Access Gateway interprets allow or deny as follows: The Access Gateway denies access to any network resource or application policy that is not explicitly allowed. Thus, if you want to provide a particular user group with access to only one resource group, you allow access only to that resource group. Deny rules take precedence over allow rules. This enables you to allow access to a range of resources and to also deny access to selected resources within that range. For example, you might want to allow a group access to a resource group that includes /24, but need to deny that user group access to To handle this, you create two network resources; one that includes the /24 subnet and a group that includes Access to that resource is denied unless you specifically allow it. To configure resource access control for a group 1. Click the Access Policy Manager tab. 2. In the right pane, configure the group resources.

105 Chapter 7 Configuring Network Access and Group Resources 105 When the resource is configured, click the resource and drag it to the group in the left pane. 3. To allow or deny a resource, in the left pane, right-click the network resource or application policy and then click Allow or Deny. To remove a resource from a user group 1. Click the Access Policy Manager tab. 2. In the left pane, expand the group to show the resources for that group and then expand the policy node. 3. Right-click the resource you want to remove and then click Remove. Setting Application Policies Application policies put constraints on the network path applications can access. For example, a user uses Microsoft Outlook for . You can configure Outlook to use a specific network path to the Microsoft Exchange Server. After the network resource is defined, when Outlook tries to start, it checks for the network resource and endpoint policy (if defined). If it passes, the user can log on and check . If it fails, Outlook does not start. If the application is open before connecting to the Access Gateway, the application remains open; however, the policies take effect and the user might not be able to use the application. If an application policy does not have a network resource or endpoint policy configured, and if the check box Deny applications without policies is selected on the General tab of the group properties, the application is denied access to the network. To configure an application policy 1. Click the Access Policy Manager tab. 2. In the right pane, right-click Application Policies and then click New Application Policy. 3. Type a name for the resource and click OK. 4. In Application, type the name of the application or click Browse to navigate to and select the application. The MD5 field is populated automatically with the binary sum of the application. 5. To restrict the application to specific networks or require an endpoint policy, under Application policies do one or both of the following:

106 106 Citrix Access Gateway Standard Edition Administrator s Guide To add a network resource to the application policy, in the left pane, under Network Resources, click the resource and drag it to Application network policies. To add an endpoint policy to the application policy, under End Point Policies, click the policy and drag it to Application end point policies. 6. Click OK. Application policies limit network access further by assigning individual network resources to specific applications. Application policies define the network path and endpoint policies for a specific application. To add an application policy to a group 1. On the Access Policy Manager tab, in the right-pane, under Application Policies, click the application policy you want to add and then drag it to the user group in the left pane. 2. To allow or deny access, right-click the application policy and then click Allow or Deny. When an application policy is created and then added to a user group, the application can use only the specified network path and endpoint policy. This does not prevent other applications from using these resources. To prevent applications from using these network resources, you can deny access to the network. To deny applications without policies 1. On the Access Policy Manager tab, right-click a user group and click Properties. 2. On the General tab, under Application options, select Deny applications without policies. You can deny one application access to the network, while allowing access to all other applications. To deny one application network access 1. On the Access Policy Manager tab, right-click a user group and click Properties. 2. On the General tab, under Application options, clear Deny applications without policies. 3. Click OK and close the Properties dialog box.

107 Chapter 7 Configuring Network Access and Group Resources In the right pane, right-click Application Policies and then click New Application Policy. 5. Type a name for the policy and click OK. 6. Under Application resource, in Application, type the application name or click Browse to navigate to and select the application. When this field is complete, the MD5 field is populated automatically. 7. To restrict the application to a specific network path, in the left pane, under Network Resources, click a network resource and drag and drop it on Application network policies. Other configured network resources must already be added to a user group and set to deny. To do so, in the left pane, under Network Policies in the group, right-click a network resource, click Deny and click OK. 8. Click the application policy and drag it to the user group to which it applies. A user can get access to all internal networks that were assigned, but the application is denied access to the network. You can also deny all applications access to the network, but allow one to have restricted access to a specific network path. The procedure is the same as To deny one application network access on page 106. The difference is instead of clearing the check box Deny applications without policies, it is selected. This check box denies all applications access to the secure network. To allow one application network access, configure the application policy to accept the application, following the steps in the previous procedure. Users obtain access to the application only to the internal site that is specifically allowed. No other applications from the client device are allowed access to the internal network. Configuring Endpoint Policies and Resources Endpoint resources provide another layer of security, helping to ensure that users are connecting to the Access Gateway on a computer that meets certain criteria. For example, you can require that a computer has particular registry entries, files, and/or active processes. Each endpoint rule specifies that a computer must have one, some, or all of the following: A registry entry that matches the path, entry type, and value that you specify. A file that matches the path, file name, and date that you specify. You can also specify a checksum for the file.

108 108 Citrix Access Gateway Standard Edition Administrator s Guide A running process that you specify. You can also specify a checksum for the process. Endpoint policies are applied to each group by specifying a Boolean expression that uses endpoint resource names. For more information, see Building an Endpoint Policy for a Group on page 109. To create an endpoint resource 1. Click the Access Policy Manager tab. 2. In the right pane, right-click End Point Resources and then click New End Point Resource. 3. Type a name and then click OK. To create a process rule 1. Click Process rule. 2. In Process name, type the name of the process or click Browse to navigate to the file. The MD5 field is automatically completed when a process name is entered and click OK. To create a file rule 1. Click File rule. 2. In File name, type the path and file name or click Browse to navigate to the file. The MD5 field is completed automatically when a file name is entered. 3. In Date, type the date in mm/dd/yyyy format. This is the date the file was created and click OK. To create a registry rule 1. Click Registry rule. 2. In Registry path, type the path and select a key type. 3. In Registry entry, type the key name. 4. In Registry value, type the value to which that key must be set and click OK. To delete an endpoint resource 1. Click the Access Policy Manager tab.

109 Chapter 7 Configuring Network Access and Group Resources In the right-pane, right-click the endpoint resource you want to remove and then click Remove. Building an Endpoint Policy for a Group You can construct a Boolean expression by dragging and dropping endpoint resources into the End Point Policy Expression Generator. When you drag and drop resources into the generator, the expression is created automatically for you. Expressions can be modified at any time. To configure an endpoint policy for a group, you specify an expression containing the endpoint resources that you want to apply to the group. Suppose that you create the following endpoint policies: CorpAssetRegistryEntry AntiVirusProcess1 AntiVirusProcess2 Your endpoint policy expression might specify that a registry check must verify that the resource attempting to connect is a corporate asset and that the resource must have one of the antivirus processes running. That Boolean expression is: (CorpAssetRegistryEntry & (AntiVirusProcess1 AntiVirusProcess2)) Valid operators for endpoint policy expressions are as follows: ( ) - used to nest expressions to control their evaluation & - logical AND - logical OR! - logical NOT For users without administrative privileges, endpoint policies fail if the policy includes a file in a restricted zone (such as C:\Documents and Settings\Administrator) or if the policy includes a restricted registry key. If a user belongs to more than one group, the endpoint policy applied to the user is the union of the expression for each of the user s groups. To create an endpoint policy for a group 1. Click the Access Policy Manager tab. 2. In the right pane, right-click End Point Policies and then click New End Point Policy. 3. Type a name and click OK.

110 110 Citrix Access Gateway Standard Edition Administrator s Guide When the policy is created, create the expression by dragging and dropping the endpoint resources into the expression builder. To build an endpoint policy expression 1. Click the Access Policy Manager tab. 2. In the right pane, right-click an endpoint policy and click Properties. The property page opens and the resources pane moves to the left. 3. Under End point policy expression, select Automatically build expression. 4. Under Build an end point policy (at the top of the dialog box), click and drag a resource to Add end point resources. 5. The expression is built using the AND identifier. To change the identifier, right-click one of the resources and then select the identifier from the menu. Click OK. The endpoint policy expression is configured automatically. If you want to manually edit the expression, clear Automatically build expression. Citrix recommends that this check box remain selected to prevent errors in the expression. Changing the Endpoint Policy Operator When you build an endpoint policy expression, it is configured automatically using the AND operator. You can change the operator by right-clicking on the endpoint resource and then selecting the operator you want, as shown in the following illustration:

111 Chapter 7 Configuring Network Access and Group Resources 111 Creating an endpoint policy expression Setting the Priority of Groups For users who belong to more than one group, you can determine which group s policies apply to a user by specifying the priority of groups. For example, suppose that some users belong to both the sales group and the support group. If the sales group appears before the support group in the User Groups list, the sales group policies apply to the users who belong to both of those groups. If the support group appears before the sales group in the list, the support group policies take precedence. The policies that are affected by the Group Priority setting are as follows: Portal page configuration, which determines the portal page the user sees when making a connection. The portal page can be the template provided with the Access Gateway or it can point to the Web Interface. User time-outs that specify the length of time a session can stay active. Time-outs include:

112 112 Citrix Access Gateway Standard Edition Administrator s Guide Session time-outs where the connection is closed after a specified amount of time Network activity time-outs where the Access Gateway Plug-in does not detect network traffic for a specified amount of time Idle session time-out where the Access Gateway Plug-in does not detect mouse or keyboard activity for a specified amount of time Enabling split DNS that allows failover to the user s local DNS Forcing the user to log on again if there was a network interruption or when the computer comes out of hibernate or standby The Access Gateway looks at all of the user groups. If a user is a member of multiple groups and if the Deny applications without policies check box is selected in one group, the user s applications will be denied regardless of the settings in the other groups. If users are members of multiple groups, and IP pooling is enabled in one of those groups, the Access Gateway allocates an IP address from the pool for the first group that has IP pooling enabled. Groups are initially listed in the order in which they are created. To set the priority of groups 1. Click the Group Priority tab. 2. Select a group that you want to move and use the arrow keys to raise or lower the group in the list. The group at the top of the list has the highest priority. Configuring Pre-Authentication Policies Users can be restricted from logging on to the Access Gateway using preauthentication policies. When users use a Web browser to connect to the Access Gateway, before they receive the logon dialog box, the pre-authentication policy scans the client device. If the scan fails, users are prevented from logging on. To log on to the Web portal, the user needs to install the correct applications. To create pre-authentication policies 1. Click the Access Policy Manager tab. 2. Under End Point Policies, click the configured policy and drag it to Pre- Authentication Policies in the left pane (located under the Global Policies node).

113 Chapter 7 Configuring Network Access and Group Resources 113 To create and configure endpoint resources and policies, see Configuring Endpoint Policies and Resources on page 107. Configuring the Access Gateway to work with Citrix Branch Repeater The Access Gateway works with Citrix Branch Repeater to support application acceleration. Citrix Branch Repeater enhances Common Internet File System (CIFS) and HTTP connections and accelerates traffic through the Access Gateway. The Access Gateway is installed in the DMZ and the Citrix Branch Repeater appliance is installed behind the Access Gateway in the secure network. Users connect through the Access Gateway and Citrix Branch Repeater to resources in the secure network. Two settings must be configured to support Citrix Branch Repeater acceleration: Preserve TCP options for each network that is configured on the Access Gateway. You configure network resources and then for each network that is to have TCP settings preserved, you apply the policy for that network. Configure the Access Gateway to communicate with the Citrix Repeater Plug-in. When this is configured, the Access Gateway sends a filter list to the Repeater Plug-in with the settings for Citrix Branch Repeater optimization. To configure TCP optimization on the Access Gateway 1. In the Administration Tool, click the Global Cluster Policies tab. 2. Under Advanced options, select Enable application acceleration with the Accelerator Plugin and click Submit. 3. On the Access Policy Manager tab, in the right pane, under Network Resources, double-click a configured network resource, or create a new resource. 4. Select Preserve TCP options and click OK. 5. Drag the network policy to the user group to which the policy applies.

114 114 Citrix Access Gateway Standard Edition Administrator s Guide

115 CHAPTER 8 Configuring User Connections for Citrix Access Gateway Plug-in This chapter discusses user connections and the methods by which users can connect to the Access Gateway and internal resources using the Citrix Access Gateway Plug-in. Users connections are made using secure connections in one of two ways: Using a Web browser to connect to the Access Gateway Using the Access Gateway Plug-in that is installed on the client device When a connection is made, a secure tunnel is created to the secure network and the SSL handshake is handled by the Access Gateway. In This Chapter System Requirements How User Connections Work Supporting the Access Gateway Plug-in Configuring Proxy Servers for the Access Gateway Plug-in Installing the Access Gateway Plug-in Using the Microsoft Installer (MSI) Package Configuring Single Sign-on with Windows Operating System Connecting with Earlier Versions of the Access Gateway Plug-in Connecting Using a Web Address Logging on Using the Access Gateway Plug-in Installing the Access Gateway Plug-in for Linux Configuring Authentication Requirements after Network Interruption Configuring Other Group Properties

116 116 Citrix Access Gateway Standard Edition Administrator s Guide Requiring Client Certificates for Authentication Installing Root Certificates Selecting an Encryption Type for Client Connections System Requirements The Access Gateway Plug-in is supported on the following operating systems and Web browsers. Operating Systems The Access Gateway Plug-in is supported on the following Windows operating systems: Windows XP Home Edition Windows XP Professional Windows 2000 Server Windows Server 2003 Windows Vista (32-bit) Web Browsers The Access Gateway Plug-in is supported on the following Web browsers: Microsoft Internet Explorer, Versions 6.x and 7.x Mozilla Firefox Version 1.5 and later versions How User Connections Work The Access Gateway operates as follows: When a user first connects using a Web address, users log on and then select the Access Gateway Plug-in, which is downloaded and installed onto the client device. After the first download and installation of the Access Gateway Plug-in, the user logs on again. When the user successfully authenticates, the Access Gateway establishes a secure tunnel. If the Access Gateway Plug-in is already installed on the client device, when users log on again using the Web address, the Access Gateway Plug-in checks for updates and then users are logged on.

117 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 117 As the remote user attempts to access network resources across through the appliance, the Access Gateway Plug-in encrypts all network traffic destined for the organization s internal network and forwards the packets to the Access Gateway. The Access Gateway terminates the SSL tunnel, accepts any incoming traffic destined for the private network, and forwards the traffic to the private network. The Access Gateway sends traffic back to the client device over a secure tunnel. When users log on using the Access Gateway Plug-in, the Access Gateway prompts the user for authentication. The Access Gateway authenticates the credentials using an authentication type such as local authentication, RSA SecurID, SafeWord, LDAP, NTLM, or RADIUS. If the credentials are correct, the Access Gateway finishes the handshake with the plug-in. This logon step is required only when a user initially downloads the Access Gateway Plug-in. If the user is behind a proxy server, the user can specify the proxy server and authentication credentials. For more information, see Configuring Proxy Servers for the Access Gateway Plug-in on page 121. The Access Gateway Plug-in is installed on the client device. After the first connection, users can log on using a Web browser or from the Start menu. The Advanced Options dialog box, which is used to configure client device settings, can also be opened from the Start menu or right-clicking the logon dialog box. To open the Advanced Options dialog box from the Start menu Click Start > All Programs > Citrix > Citrix Access Clients > Citrix Access Gateway - Properties. Establishing the Secure Tunnel After the Access Gateway Plug-in is started, it establishes a secure tunnel over port 443 (or any configured port on the Access Gateway) and sends authentication information. When the tunnel is established, the Access Gateway sends configuration information to the Access Gateway Plug-in describing the networks to be secured and containing an IP address if you enabled IP pooling. For more information about IP pooling see Enabling IP Pooling on page 133. Tunneling Private Network Traffic over Secure Connections When the Access Gateway Plug-in is started and the user is authenticated, all network traffic destined for specified private networks is captured and redirected over the secure tunnel to the Access Gateway.

118 118 Citrix Access Gateway Standard Edition Administrator s Guide The Access Gateway intercepts all network connections made by the client device and multiplexes/tunnels them over SSL to the Access Gateway, where the traffic is demultiplexed and the connections are forwarded to the correct host and port combination. The connections are subject to administrative security policies that apply to a single application, a subset of applications, or an entire intranet. You specify the resources (ranges of IP address/subnet pairs) that remote users can access through the VPN connection. For more information, see Configuring Network Access and Group Resources on page 93. All IP packets, regardless of protocol, are intercepted and transmitted over the secure link. Connections from local applications on the client device are securely tunneled to the Access Gateway, which reestablishes the connections to the target server. Target servers view connections as originating from the local Access Gateway on the private network, thus hiding the client device. This is also called reverse Network Address Translation (NAT). Hiding IP addresses adds security to source locations. Locally, on the client device, all connection-related traffic (such as SYN-ACK, PUSH, ACK, and FIN packets) is recreated by the Access Gateway Plug-in to appear from the private server. Operation through Firewalls and Proxies Users of the Access Gateway Plug-in are sometimes located inside another organization s firewall, as shown in the following illustration. Client connection through two internal firewalls.

119 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 119 NAT firewalls maintain a table that allows them to route secure packets from the Access Gateway back to the client device. For circuit-oriented connections, the Access Gateway maintains a port-mapped, reverse NAT translation table. The reverse NAT translation table enables the Access Gateway to match connections and send packets back over the tunnel to the client device with the correct port numbers so that the packets return to the correct application. The Access Gateway tunnel is established using industry-standard connection establishment techniques such as HTTPS, Proxy HTTPS, and SOCKS. This operation makes the Access Gateway firewall accessible and allows remote computers to access private networks from behind other organizations firewalls without creating any problems. For example, the connection can be made through an intermediate proxy, such as an HTTP proxy, by issuing a CONNECT HTTPS command to the intermediate proxy. Any credentials requested by the intermediate proxy are in turn obtained from the remote user (by using single sign-on information or by requesting the information from the remote user) and presented to the intermediate proxy server. When the HTTPS session is established, the payload of the session is encrypted and carries secure packets to the Access Gateway. Terminating the Secure Tunnel and Returning Packets to the Client The Access Gateway terminates the SSL tunnel and accepts any incoming packets destined for the private network. If the packets meet the authorization and access control criteria, the Access Gateway regenerates the packet IP headers so that they appear to originate from the Access Gateway s private network IP address range or the client-assigned private IP address. The Access Gateway then transmits the packets to the network. The Access Gateway Plug-in maintains two tunnels: an SSL tunnel over which data is sent to the Access Gateway and a tunnel between the client device and local applications. The encrypted data that arrives over the SSL tunnel is then decrypted before being sent to the local application over the second tunnel. If you run a packet sniffer such as Ethereal on the client device where the Access Gateway Plug-in is running, you will see unencrypted traffic that appears to be traveling between the client device and the Access Gateway. That unencrypted traffic, however, is not over the tunnel between the client and the Access Gateway but rather the tunnel to the local applications.

120 120 Citrix Access Gateway Standard Edition Administrator s Guide When an application client connects to its application server, certain protocols may require that the application server in turn attempt to create a new connection with the client. In this case, the client sends its known local IP address to the server by means of a custom client-server protocol. For these applications, the Access Gateway Plug-in provides the local client application a private IP address representation, which the Access Gateway uses on the internal network. Many real-time voice applications and FTP use this feature. Users can access resources on the secure network by connecting through the Access Gateway from their own computer or from a public computer. Supporting the Access Gateway Plug-in To enable users to connect to and use the Access Gateway, you need to provide them with the following information: Access Gateway Web address, such as The authentication realm name required for logon (if you use realms other than the realm named Default). Path to any network drives that the users can access, which is done by mapping a network drive on the client device. Any system requirements for running the Access Gateway Plug-in if you configured endpoint resources and policies. Depending on the configuration of the client device, you might also need to provide additional information: To start the Access Gateway Plug-in, Windows XP users must be a local administrator or a member of the Administrators group to install the Access Gateway Plug-in for the first time. Users do not need to be an administrator for upgrades. If a user runs a firewall on the client device, the user might need to change the firewall settings so that it does not block traffic to or from the IP addresses corresponding to the resources for which you granted access. The Access Gateway Plug-in automatically handles Internet Connection Firewall in Windows XP and Windows Firewall in Windows XP Service Pack 2 and Windows Vista. For information about configuring a variety of popular firewalls, see Configuring Third-Party Personal Firewalls on page 163. Users who want to send traffic to FTP over the Access Gateway connection must set their FTP application to perform passive transfers. A passive transfer means that the client device establishes the data connection to your

121 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 121 FTP server, rather than your FTP server establishing the data connection to the remote computer. Because users work with files and applications just as if they were local to the organization s network, no retraining of users or configuration of applications is needed. An template is provided that includes the information discussed in this section. The template is available from the Downloads page of the Administration Portal. Citrix recommends that you customize the text for your site and then send the text in an to users. Configuring Proxy Servers for the Access Gateway Plugin When the Access Gateway Plug-in connects, before downloading polices from the Access Gateway, the plug-in queries the operating system for client proxy settings. If auto-detection is enabled, the Access Gateway Plug-in automatically changes client proxy settings to match settings stored in the operating system. The Access Gateway Plug-in attempts to connect to the Access Gateway, download pre-authentication policies, and then prompt the users for their logon credentials. If the Access Gateway Plug-in cannot automatically detect the client proxy settings, it resorts to a straight connection without using the proxy server. Automatic detection of the proxy settings is configured in the Advanced Options dialog box in the Access Gateway Plug-in. During installation, an installation log file, called CAG_Plug-in.log, is installed in the %TEMP% directory on the client device. You can use this log file to troubleshoot the installation. Users can also manually configure a proxy server from the Access Gateway Plugin. When a proxy server is manually configured, this disables the automatic detection of proxy settings. To manually configure a proxy server 1. On the client device, click Start > All Programs > Citrix > Citrix Access Clients > Citrix Access Gateway - Properties. 2. In the Citrix Access Gateway Options dialog box, under Proxy settings, select Manually configure proxy server. 3. In IP address and Port, type the IP address and port number. 4. If authentication is required by the server, select Proxy server requires authentication.

122 122 Citrix Access Gateway Standard Edition Administrator s Guide Installing the Access Gateway Plug-in Using the Microsoft Installer (MSI) Package You can install the Access Gateway Plug-in on a client device using an MSI package. The Access Gateway Plug-in is installed on a per-machine basis. When you create the package, you can designate which installations occur with elevated privileges, allowing non-administrative users to install the plug-in. You can create the package by downloading the file CitrixAGP.exe from the Access Gateway appliance. When the executable file is downloaded, you can run the file to automatically unpack and install the MSI file. To download and install the MSI package 1. In a Web browser, go to where AccessGatewayFQDN is the fully qualified domain name of the Access Gateway. 2. Click Save to save the file to your computer. 3. Double-click CitrixAGP.exe to unpack and install the MSI file. There are two ways you can distribute the MSI file to users who are not administrative users on the client device: Use an Active Directory Group Policy (or similar tool) to push installation of the package to the client device Advertise the installation package to the client device Installing the MSI Package Using Group Policy For users who connect to Active Directory from within the internal network, you can download and install the Access Gateway Plug-in using a Group Policy. The software installation feature of the group policy automatically installs or upgrades the Access Gateway Plug-in whenever the client device connects to the domain. The procedure for installing the MSI package using Group Policy is similar to that of advertising a package. The CitrixAGP.exe package should be extracted. If the default installation configuration needs to change, run the administrative installation and create an administrative image. Place either the original MSI or the administrative image on a shared network location. Assign the package to computers using Group Policy and reference the shared network location. To deploy the Access Gateway Plug-in using a Group Policy 1. On the Windows server, create and open a temporary directory.

123 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in On the Access Gateway appliance, in the Administration Tool, on the Global Cluster Policies tab, under Access options, select Do not upgrade earlier versions of the Access Gateway Plugin 3. At a command prompt, type CitrixAGP -extract to extract the MSI file and related files into the new directory created in Step Publish the MSI and appropriate files using Group Policy. Installing the MSI Package Using Advertisement To advertise the client installation, you need to extract the CAGSE.MSI and *.MST files. When you create the image, you need to provide a path to the image and specify the language. You then use a command-line switch to the MSIEXEC utility to advertise the package. The Windows Installer only considers the advertised file path to be trusted. If users try to install CAGSE.MSI from a CD or a local path that is different from the advertised path, the installation fails. To extract the MSI and MST files and create an administrative image 1. In the Access Gateway Administration Tool, on the Global Cluster Policies tab, under Access options, select Do not upgrade earlier versions of the Access Gateway Plugin. 2. At a command prompt, type: CitrixAGP -extract This command unpacks the files to the server share you specify. To unpack and install the Access Gateway Plug-in, type CitrixAGP. 3. To create a configured administrative image, at a command prompt type: msiexec /a CAGSE.MSI 4. When the image is created, advertise the product to all users on the client device. To do so, on the client device, at a command prompt type: misexec /jm path to administrative image\cagse.msi This command advertises the Access Gateway Plug-in but does not install it on the client device. The plug-in appears to be installed; an entry appears in Add or Remove Programs and the Start menu shortcuts are present, however no files are copied to the client device. 5. To install the Access Gateway Plug-in, at a command prompt type: msiexec /i path to administrative image\cagse.msi You can also start the installation by clicking on the shortcut on the Start menu.

124 124 Citrix Access Gateway Standard Edition Administrator s Guide Initial installation of the Access Gateway Plug-in on the client is done using this method. When an upgrade to the plug-in is available, you can upgrade the package on the file share. When users connect to the Access Gateway, users navigate to the share and runs cagsetup.exe to upgrade. If the Access Gateway Plug-in runs logon scripts, the script can check for the upgrade and install the plug-in. You can also send an to users that the upgrade is available and provide a link to the file share with the updated version of cagsetup.exe, the.msi and.mst files. Configuring Single Sign-on with Windows Operating System By default, Windows users open a connection by starting the Access Gateway Plug-in from the Start menu. You can specify that the plug-in start automatically when the user logs on to Windows by enabling single sign-on. When single signon is configured, users Windows logon credentials are passed to the Access Gateway for authentication. Enable single sign-on only if the client device is logging on to your organization s domain. If single sign-on is enabled and a user connects from a client device that is not on your domain, the user is prompted to log on. If the Access Gateway Plug-in is configured for single sign-on with Windows, it automatically starts after the user logs on to Windows. The user s Windows logon credentials are passed to the Access Gateway for authentication. Enabling single sign-on for the Access Gateway Plug-in facilitates operations on the client device such as installation scripts and automatic drive mapping. To configure the Access Gateway Plug-in for Windows single sign-on 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a group and then click Properties. 3. On the General tab, under Session options, click Enable single sign-on with Windows and click OK. Note: If you configured double-source authentication, you cannot use single sign-on.

125 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 125 Connecting with Earlier Versions of the Access Gateway Plug-in You can configure the Access Gateway to accept connections from earlier versions of the Access Gateway Plug-in. For example, you can configure the Access Gateway Version 4.6 to accept connections from the Access Gateway Plug-in Version 4.5. If you allow earlier versions of the Access Gateway Plug-in to connect to the Access Gateway, select either 3DES or RC4 as the encryption type for client connections. Earlier versions of the Access Gateway Plug-in do not support the AES encryption type and cannot connect if AES is selected. To enable earlier versions of the Access Gateway Plug-in to connect to the Access Gateway 1. Click the Global Cluster Policies tab. 2. Select Allow connections using earlier versions of Access Gateway Plug-in. 3. Click Submit. Upgrading Earlier Versions of the Access Gateway Plug-in You can control how you want to upgrade the Access Gateway Plug-in from an earlier version. You can select if the Access Gateway Plug-in is upgraded or not. If you want the latest version of the plug-in to be installed on a client device, you can force the upgrade or prompt users to allow the upgrade. If you don t want users to upgrade, you can select the setting that does not allow automatic upgrades. This setting has no effect for Access Gateway Plug-in versions earlier than 4.5. These clients are hard-coded to prompt the user to upgrade when connecting to a later version of the Access Gateway. If you choose to have users upgrade the plug-in, the user is prompted to upgrade if both of the following conditions exist: The Access Gateway Plug-in available with Access Gateway Version 4.5 is replaced with an updated version at some point in the future A user connects to the Access Gateway with Access Gateway Plug-in Version 4.5

126 126 Citrix Access Gateway Standard Edition Administrator s Guide To force or prompt to upgrade earlier versions of the Access Gateway Plugin 1. Click the Global Cluster Policies tab. 2. Do one of the following: Select Prompt to upgrade earlier versions of Access Gateway Plug-in - or - Select Force upgrade to earlier versions of the Access Gateway Plug-in 3. Click Submit. If you do not want users to upgrade the Access Gateway Plug-in, select Do not upgrade earlier versions of the Access Gateway Plug-in. Connecting Using a Web Address If users are connecting using a Web page, they are either prompted to log on or are taken directly to a portal page where they can connect using Access Gateway Plug-in. If the Access Gateway is configured to have users log on before making a connection with Access Gateway Plug-in, they type their user name and password and then log on. A portal page appears that provides the choice to log on using Access Gateway Plug-in or a Citrix XenApp plug-in. If a user chooses to log on using Access Gateway Plug-in, the connection provides full access to the network resources that the user s group(s) have permission to access. The access granted by the security policies enables users to work with the remote system just as if they are logged on locally. For example, users might be granted permission to applications, including Web, client-server, and peer-to-peer applications such as Instant Messaging and video conferencing. Users can also map network drives to access allowed network resources, including shared folders and printers. While connected to the Access Gateway, remote users cannot see network information from the site to which they are connected. For example, while connected to the Access Gateway, type the following at a command prompt: ipconfig/ all or route print You will not see network information from the secure network. When the user connects uses a Web browser to log on for the first time, they install the Access Gateway Plug-in from the portal page. When users click Citrix Access Gateway on the portal page, the following occurs:

127 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 127 It downloads and starts installation automatically of the plug-in from the Web page instead of having to manually download the executable and then start the installation of the Access Gateway Plug-in. If a pre-authentication policy is configured on the Access Gateway, the Citrix Prescan plug-in is installed and the plug-in performs preauthentication checks on the client device. The Prescan plug-in is installed before the Access Gateway Plug-in. It provides single sign-on with Windows for the full plug-in. When the Access Gateway Plug-in is started from the Web page, the plug-in does not prompt the user to log on again. Logging on Using the Access Gateway Plug-in When the Access Gateway Plug-in is loaded, users are prompted to log on to the Access Gateway to establish the connection. The Access Gateway administrator determines the type of authentication using the Authentication tab of the Administration Tool, as described in Configuring Authentication and Authorization on page 61. If double-source authentication is configured on the Access Gateway and the users are logging on using full access, they type their user name and passwords for each type of authentication. For example, users are configured to use LDAP authentication and RSA SecurID. They would type their password, their RSA SecurID personal identification number (PIN), and RSA SecureID code. Note: If you are using Citrix Access Gateway Plug-in for Linux, the connection window does not include the options described in the following procedure. The Access Gateway Plug-in is installed the first time the user logs on to the portal Web page. To install the Access Gateway Plug-in 1. In a Web browser, type the Web address of the Access Gateway, for example, 2. If the Access Gateway requires the user to log on, type the user name and password and click Log On. 3. On the Citrix Access Gateway portal page, click Citrix Access Gateway and follow the prompts to install the Access Gateway Plug-in. After installation, users must log on again using the icon on the Start menu.

128 128 Citrix Access Gateway Standard Edition Administrator s Guide To log on to the Access Gateway using the Access Gateway Plug-in 1. Click Start > All Programs > Citrix > Citrix Access Clients > Citrix Access Gateway. 2. In the Citrix Access Gateway dialog box, users enter their logon credentials. If the Access Gateway is configured with more than one authentication realm and users need to connect to a realm other than the Default, enter the realm name before your user name (realmname\username). If your site uses Secure Computing SafeWord products, type the passcode. 3. If the Access Gateway requires double-source authentication, type the user name and the password for each authentication type. If your site uses RSA SecurID authentication, your password is your PIN plus the number displayed in the RSA SecurID token.. The Access Gateway dialog box showing double-source authentication 4. If the user needs to change settings, right-click the dialog box and then click Advanced Options. You can change the following settings: Web address of the appliance. This also displays the last 10 IP addresses or FQDNs to which the user connected. Proxy settings for the client device. Users can configure automatic proxy server detection or manually configure a proxy server. Enabling split DNS. This setting can be set in the Administration Tool. If it is unavailable, the setting cannot be changed. For more information about split DNS, see Enabling Split DNS on page 134.

129 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 129 Disabling security certificate warnings. If you did not install a secure certificate signed by a Certificate Authority, users see a certificate warning when they log on. This setting disables the warning. The Access Gateway dialog box with the pop-up menu 5. You can show or hide the secondary password field. To do so, do one of the following: If the secondary password is showing in the dialog box, right-click anywhere in the box and in the menu, select Hide Secondary Password. If the secondary password is not showing, in the dialog box, rightclick anywhere in the box and in the menu, select Show Secondary Password. Note: The password labels in the Citrix Access Gateway dialog box can be changed on the Authentication tab in the Administration Tool. If you changed the password labels, the text appears in the Citrix Access Gateway dialog box and on the logon Web page. The menu item for showing and hiding the password labels does not change. For more information, see Changing Password Labels on page Click Connect.

130 130 Citrix Access Gateway Standard Edition Administrator s Guide Note: If a digital certificate signed by a Certificate Authority is not installed on the Access Gateway, you will see a Security Alert. For more information, see Creating and Installing Certificates on page 46 and Securing Connections with Digital Certificates on page 185. When the connection is established, a status window briefly appears and the Access Gateway Plug-in window is minimized to the notification area. The icon indicates whether the connection is enabled or disabled and displays any status messages. To view Access Gateway Plug-in status properties when users are logged on Double-click the Access Gateway connection icon in the notification area. Alternatively, right-click the icon and choose Properties from the menu. The Citrix Access Gateway dialog box appears. The properties of the connection provide information that is helpful for troubleshooting. The properties include: The General tab displays connection information. The Details tab displays server information and a list of the secured networks the clients are allowed to access. The Access Lists tab displays the access control lists (ACLs) that are configured for the user connection. This tab does not appear for users who are not in a group or if an ACL is not configured for a group. To close the window, click Close. To disconnect the Access Gateway Plug-in Right-click the Access Gateway icon in the notification area and choose Disconnect from the menu. Installing the Access Gateway Plug-in for Linux The Access Gateway Plug-in supports Linux kernel 2.6. If users connect using the Access Gateway Plug-in for Linux, Citrix recommends using the plug-in for external connections (such as from the Internet) and not from within the internal network. If connecting from a Linux computer, click the Download button to start the download and view instructions about how to install the Access Gateway Plug-in for Linux.

131 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 131 Important: For the Access Gateway Plug-in for Linux to work correctly, enable split tunneling on the Access Gateway. Before installing the Access Gateway Plug-in for Linux, make sure that the Linux TUN/TAP driver is installed on the client device. If it is not installed, in the kernel configuration, select Device Drivers > Network device support > Universal TUN/TAP device drive support. After this is selected, recompile the kernel. In addition, the stat utility must also be installed on the client device. You can install the stat utility from the coreutils package of the Linux system. In addition to the command cagvpn --login, which starts the logon procedure for the Access Gateway Plug-in for Linux, you can also type cagvpn --help to see a list of other command-line options. If you lose the connection, the VPN daemon may be stopped. The Access Gateway Plug-in for Linux requires a running VPN daemon to connect to the Access Gateway. To check the status of the VPN daemon, type the following at a command prompt: /etc/init.d/cagvpnd status If the daemon is not running, type the following: /etc/init.d/cagvpnd start To restart a stopped daemon, type the following: /etc/init.d/cagvpnd restart To remove the Access Gateway plug-in for Linux 1. At a command prompt, type the following: cagvpn_uninstall This removes all the binaries and other file related to the Access Gateway Plug-in for Linux. For more information, see the CitrixVPN_ReadMe.txt in the root directory. If the client device is running a firewall, users might need to disable or change the settings. Firewall rules might interfere with the packet handling mechanism of the Access Gateway Plug-in for Linux. For more information, see the firewall manufacturer s documentation. Note: The ICMP protocol is not currently supported for the Access Gateway Plug-in for Linux.

132 132 Citrix Access Gateway Standard Edition Administrator s Guide Configuring Authentication Requirements after Network Interruption By default, if a user s network connection is briefly interrupted, the user does not have to log on again when the connection is restored. You can require that users log on after interruptions such as when a computer comes out of hibernation or standby, when the user switches to a different wireless network, or when a connection is forcefully closed. Note: The Access Gateway attempts to authenticate users using the cached password. If users log on using a one-time password, such as used by an RSA SecurID token, authentication on the Access Gateway fails and the user can be locked out and unable to log on. To prevent the use of one-time passwords, the Access Gateway can be configured to force users to log on again after a network interruption. For more information, see Configuring Authentication to use One-Time Passwords on page 90. To require users to log on after a network interruption or on system resume 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a group and click Properties. 3. On the General tab, under Session options, select one or both of the following: Authenticate after network interruption. This option forces a user to log on again if the network connection is briefly interrupted. Authenticate upon system resume. This option forces a user to log on again if the user s computer awakens from standby or hibernation. This option provides additional security for unattended computers. 4. Click OK. Note: If you want to close a connection and prevent a user or group from reconnecting automatically, you must select the Authenticate after network interruption setting. Otherwise, users immediately reconnect without being prompted for their credentials.

133 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 133 Configuring Other Group Properties To further specify how users access the network, you can configure additional group policies, which include: Enabling IP Pooling Enabling Split DNS Enabling Internal Failover Enabling Domain Logon Scripts Enabling Access Gateway Plug-in Session Time-Outs Configuring Web Session Time-Outs Enabling IP Pooling In some situations, users connecting using the Access Gateway Plug-in need a unique IP address for the Access Gateway. For example, in a Samba environment, each user connecting to a mapped network drive needs to appear to originate from a different IP address. When you enable IP pooling for a group, the Access Gateway can assign a unique IP address alias to each client. You can specify the gateway device to be used for IP pooling. The gateway device can be the Access Gateway itself or some other device. If you do not specify a gateway, an Access Gateway interface is used, based on the General Networking settings, as follows: If you configured only Interface 0 (the Access Gateway is inside your firewall), the Interface 0 IP address is used as the gateway. If you configured Interfaces 0 and 1 (the Access Gateway is in the DMZ), the Interface 1 IP address is used as the gateway. Interface 1 is considered the internal interface in this scenario. IP pooling configuration needs to be done consistently on all of the same Access Gateway appliances in the cluster. If a cluster contains Appliance1, Appliance2, and Appliance3 configure IP pooling on the appliance that publishes settings. When the settings are published, the IP pooling information is replicated to the other appliances in the cluster. If you are adding an Access Gateway to a cluster that has IP pooling information configured the information is removed. If you configure IP Pooling on the new appliance after it has joined the cluster, users never receive the pooled addresses.

134 134 Citrix Access Gateway Standard Edition Administrator s Guide To configure IP pooling for a group 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a user group and click Properties. 3. Click the Network tab and click Enable IP pools. 4. Under IP pool configuration, right-click a gateway and then click Change the IP Address Pool. 5. In Starting IP Address, type the starting IP address for the pool. 6. In Number of IP addresses, type the number of IP address aliases. You can have as many as 2000 IP addresses total in all IP pools. 7. In Default gateway, type the gateway IP address. If you leave this field blank, an Access Gateway network adapter is used, as described earlier in this section. If you specify some other device as the gateway, the Access Gateway adds an entry for that route in the Access Gateway routing table. 8. Click OK twice. Enabling Split DNS By default, the Access Gateway checks a user s remote DNS only. You can allow failover to a user s local DNS by enabling split DNS. A user can override this setting using the Connection Properties dialog box from the Access Gateway dialog box. To enable split DNS 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a group and click Properties. 3. On the Network tab, click Enable split DNS and click OK. The Access Gateway fails over to the local DNS only if the specified DNS servers cannot be contacted but not if there is a negative response. Enabling Internal Failover Configuring the client s local DNS settings enables the Access Gateway Plug-in to connect to the Access Gateway from inside the firewall. When this is configured, the client will failover to the internal IP address of the Access Gateway if the external IP address cannot be reached.

135 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 135 To enable internal failover 1. Click the Global Cluster Policies tab. 2. Under Advanced Options, select Enable internal failover. When this check box is selected, the internal IP address of the Access Gateway is added to the failover list. If you disabled external administrator access, port 9001 is unavailable. If you want to connect to port 9001 when you are logged on from an external connection, configure IP pools and connect to the lowest IP address in the IP pool. Enabling Domain Logon Scripts In your network, you may have logon scripts that run on the client device after a successful logon. If logon scripts are enabled on the Access Gateway, after authentication, the Access Gateway establishes the connection, obtains Windows logon scripts from the domain controller, and then runs the logon scripts to perform operations such as automatic drive mapping. Note: Users that want to use single sign-on to Windows XP and logon scripts must be logged on as a Power User or be a member of the Power Users group. The Access Gateway can run logon scripts that are defined in the user s Windows profile. Logon scripts that are defined in Active Directory are not supported and do not run. If the domain controller cannot be contacted, the Access Gateway connection is completed but the logon scripts are not run. Important: logon scripts. The client device must be a domain member in order to run domain To enable logon scripts 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a group and click Properties. 3. On the General tab, under Session options, select Run logon scripts. Click OK. Note: Logon script support is restricted to scripts that are executed by the command processor, such as executables and batch files. Visual Basic and JavaScript logon scripts are not supported

136 136 Citrix Access Gateway Standard Edition Administrator s Guide Enabling Access Gateway Plug-in Session Time- Outs You can configure the Access Gateway Plug-in to force a disconnection with the Access Gateway if there is no activity on the connection for a specified number of minutes. One minute before a session times out (disconnects), the user receives an alert indicating the session will close. If the session closes, the user must log on again. There are three different options when configuring a session time-out value: User session time-out. If you enable this setting, the Access Gateway Plug-in disconnects after the time-out interval elapses regardless of what the user is doing. There is no action the user can take to prevent the disconnection from occurring when the time-out interval elapses. Network inactivity time-out. If you enable this setting, the Access Gateway Plug-in disconnects if no network packets are sent from the client device to the Access Gateway for the specified interval. Idle session time-out. If you enable this setting, the user session times out if there is no mouse or keyboard activity on the client device for the specified interval. You can enable any of these settings by entering a value between 1 and to specify a number of minutes for the time-out interval. You can disable any of these settings by entering a 0 (zero). If you enter a 0, the time-out session is not activated and the setting has no effect on client connections. If you enable more than one of these settings, the first time-out interval to elapse closes the client connection. To enable session time-outs 1. Click the Access Policy Manager tab. 2. In the left pane, right-click a group and then click Properties. 3. On the General tab, under Session options, type the number of minutes in any of these settings: User session time-out Network inactivity time-out Idle session time-out 4. Click OK.

137 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 137 Configuring Web Session Time-Outs When users are logged on to the Access Gateway using the logon page, cookies are set to determine if a user s Web session is still active on the Access Gateway. If the Access Gateway cookie expires and logon page authentication is enabled, the end user is prompted to enter authentication credentials to resume the Web session. This provides a measure of security for limiting the amount of time network attacks could occur during an unattended Web session. To enable Web session time-outs 1. Click the Global Cluster Policies tab. 2. Under Access options, type the number of minutes in Web session timeout. To disable Web session time-outs, type 0 in the text box. Requiring Client Certificates for Authentication If you want additional authentication, you can configure the Access Gateway to require client certificates for authentication. The Access Gateway can authenticate a client certificate that is stored in either of these locations: In the certificate store of the Windows operating system on a client device. In this case, the client certificate is installed separately in the certificate store using the Microsoft Management Console. In a smart card or a hardware token. In this case, the certificate is embedded within the smart card and read from a smart card reader attached to the network. Note: The Access Gateway is configured in the same way regardless of whether the certificates are stored in the Windows operating system or on a smart card. No special configurations are required to support client certificates stored in either of these locations. If you configure the Access Gateway to require client certificates, every user who logs on through the Access Gateway must present a secure client certificate. The certificate can originate from the certificate store in Windows or a smart card. To require client certificates 1. Click the Global Cluster Policies tab.

138 138 Citrix Access Gateway Standard Edition Administrator s Guide 2. Under Select security options, select Require secure client certificates and click Submit. Defining Client Certificate Criteria To specify criteria that client certificates must meet, use a Boolean expression. To belong to a group, the user must meet the certificate criteria in addition to passing all other authentication rules that are configured for that group. For example, the following criteria requires that the subject field of the client certificate provided by a user has the Organization Unit (OU) set to Accounting and the Common Name (CN) attribute set to a value matching the user s local user name on the Access Gateway. client_cert_end_user_subject_organizational_unit= Accounting and username=client_cert_end_user_subject_common_name. Valid operators for the client certificate are as follows: and logical AND = equality test Valid constants for the criteria are: true logical TRUE Valid variables for the criteria are: username local user name on the Access Gateway client_cert_end_user_subject_common_name CN attribute of the Subject of the client certificate client_cert_end_user_subject_organizational_unit OU attribute of the Subject of the client certificate client_cert_end_user_subject_organization O attribute of the Subject of the client certificate Values for the client certificate criteria require quotation marks around them to work. Correct and incorrect examples are: The Boolean expression client_cert_end_user_subject_common_name= clients.gateways.citrix.com is valid and it works. The Boolean expression client_cert_end_user_subject_common_name=clients.gateways.citrix.com is not valid and does not work To specify client certificate configuration 1. On the Access Policy Manager tab, right-click a group that is not the default group and click Properties.

139 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 139 Note: group. Client certificate configuration is not available for the default user 2. On the Client Certificate tab, under Client certificate criteria expression, type the certificate information and click OK. Using Client Certificates with Access Gateway Advanced Edition The Access Gateway and the servers running Advanced Edition can both be required to use secure client certificates. Use the following guidelines when configuring for client certificate use: The Access Gateway Plug-in can read certificates from the Windows user s profile, from a smart card, or a hardware token that supports the Microsoft Crypto API. The client certificate does not authenticate the user, it serves only as an additional client requirement, such as an endpoint scan. Users still have to type in their password or token code. Installing Root Certificates A root certificate must be present on every client device that connects to the secure network through the Access Gateway. Support for most trusted root authorities is already built into the Windows operating system and Internet Explorer. Therefore, there is no need to obtain and install root certificates on the client device if you are using these CAs. However, if you decide to use a different CA, you need to obtain and install the root certificates yourself. Obtaining a Root Certificate from a Certificate Authority Root certificates are available from the same Certificate Authorities (CAs) that issue server certificates. Well-known or trusted CAs include Verisign, Baltimore, Entrust, and their respective affiliates. Certificate authorities tend to assume that you already have the appropriate root certificates (most Web browsers have root certificates built-in). However, if you are using certificates from a CA that is not already included on the client device, you need to specifically request the root certificate.

140 140 Citrix Access Gateway Standard Edition Administrator s Guide Several types of root certificates are available. For example, VeriSign has approximately 12 root certificates that they use for different purposes, so it is important to ensure that you obtain the correct root certificate from the CA. Installing Root Certificates on a Client Device Root certificates are installed using the Microsoft Management Console (MMC) in Windows. When installing a root certificate to the MMC, use the Certificate Import wizard. The certificate is installed in the Trusted Root Certification Authorities store for the local computer. For information about root certificate availability and installation on platforms other than 32-bit Windows, refer to product documentation appropriate for the operating system you are using. Selecting an Encryption Type for Client Connections All communications between the Access Gateway Plug-in and the Access Gateway are encrypted with SSL. The SSL protocol allows two computers to negotiate encryption ciphers to accomplish the symmetric encryption of data over a secure connection. You can select the specific cipher that the Access Gateway uses for the symmetric data encryption on an SSL connection. Selecting a strong cipher reduces the possibility of malicious attack. The security policies of your organization may also require you to select a specific symmetric encryption cipher for secure connections. Note: If you are using the Access Gateway to provide access to Citrix XenApp, ICA traffic transmitted to the Access Gateway is also encrypted using these ciphers. You can select RC4, 3DES, or AES encryption ciphers for SSL connections. The default setting is RC4 128-bit. The MD5 or SHA hash algorithm is negotiated between the client and the server. The Access Gateway uses RSA for public key encryption in a secure connection. The encryption ciphers and hash algorithms that you can select for symmetric encryption are listed below: RC4 128-bit, MD5/SHA 3DES, SHA AES 128/256-bit, SHA

141 Chapter 8 Configuring User Connections for Citrix Access Gateway Plug-in 141 To select an encryption type for client connections 1. Click the Global Cluster Policies tab. 2. Under Select security options, in Select encryption type for client connections, select the bulk encryption cipher you want to use for secure connections and click Submit.

142 142 Citrix Access Gateway Standard Edition Administrator s Guide

143 CHAPTER 9 Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in The Access Gateway can be configured to use both logon pages and portal pages. The logon page requires users to enter their credentials first and then they are connected to the portal page, where users can log on using the Access Gateway Plug-in or the Web Interface. In This Chapter Configuring Access Gateway Logon Pages Access Gateway Portal Page Templates Configuring a Portal Page with Multiple Logon Options Logging On When Pre-Authentication Policies are Configured Configuring Access Gateway Logon Pages The Access Gateway logon page requires users to log on before they connect using Access Gateway Plug-in or with the Web Interface. You can choose to use the default logon page that comes with the Access Gateway, or you can customize the logon page with your company logos, a cascading stylesheet, and an HTML footer with text you write. Enabling Logon Page Authentication By default, a user must log on to the logon page and then again to the Access Gateway Plug-in or the Web Interface. You can eliminate the logon page using either of the following methods: You can set a global policy that disables authentication for the logon page and that specifies the logon page that appears for all users. This global policy overrides any logon page selections for groups.

144 144 Citrix Access Gateway Standard Edition Administrator s Guide To enable logon page authentication 1. Click the Global Cluster Policies tab. 2. Under Advanced options, select Enable logon page authentication and click Submit. If the Enable logon page authentication check box is clear, the users do not log on, but go directly to the custom portal page. Customizing the Logon Page To customize the logon page, upload your own images, stylesheet, and text. When these are uploaded, the users receive the customized logon page instead of the default page. To customize the logon page on the Access Gateway 1. Click the Portal Page Configuration tab. 2. On the Logon Page tab, next to Logon page type, select Customized Logon Page. 3. If you are installing a customized portal page, complete the appropriate tasks below: To upload an image, under Primary logo image, click Upload New Primary Image, browse to the image file, and then click Open. Note: The primary graphic image file should be 14 KB with dimension of 300 pixels wide by 62 pixels high. If the image file size is between 14 and 50 KB, some green color appears in the background in the Administration Tool, while the entire image appears with a scrollbar on the logon page. If the image file size is larger than 50 KB, a gray box appears in the Administration Tool, while the entire image appears on the logon page. To upload another image file, under Secondary logo image, click Upload New Secondary Image.

145 Chapter 9 Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in 145 Note: The secondary graphic image file does not have dimension restrictions and the image appears without a scrollbar on the portal logon page in all instances. If the image file size is between 14 and 50 KB, some green color appears in the background in the Administration Tool, while the entire image appears on the logon page. If the image file size is larger than 50 KB, a gray box appears in the Administration Tool, while the entire image appears on the logon page. If you are using a stylesheet, under Style sheet, you can either download the current stylesheet or upload a new stylesheet. To create a footer, under HTML footer, type the text and after all steps are completed, click Apply at the top of the page. After installing the customized portal page, select the portal page for users. For more information, see the following: To use the default portal page that comes with the appliance, see Access Gateway Portal Page Templates on page 145 To allow users the choice of logging on with either the Access Gateway Plug-in or the Web Interface, see Configuring a Portal Page with Multiple Logon Options on page 148 If a pre-authentication policy is configured, see Logging On When Pre- Authentication Policies are Configured on page 149 Access Gateway Portal Page Templates When a user starts the Access Gateway Plug-in using a Web browser, users see the Citrix Access Gateway logon page. After users log on, they are directed to a portal page providing the choice of connecting using either Access Gateway Plug-in or Web Interface. Citrix provides portal page templates that can be customized. Customizing the default portal page can be as simple as replacing the logo. The text for Citrix Access Gateway uses a variable to insert the text into the template. The text cannot be changed. Note: If you want to add text to the template or make format changes, you need to consult with someone who is familiar with HTML. Changes to the templates other than those described in this section are not supported.

146 146 Citrix Access Gateway Standard Edition Administrator s Guide Downloading and Working with Portal Page Templates The portal page templates are available from the Downloads page of the Administration Portal. The portal page templates include variables that the Access Gateway replaces with the current user name and with a link to start the Access Gateway Plug-in. The variables that can be used in templates are described in the following table. Variable $citrix_username; $citrix_portal_full_client_only; Content inserted by variable Name of logged on user. Link to the Access Gateway Plug-in only. To download the portal page templates to your local computer 1. In the Administration Portal, click Downloads. 2. Under Download a sample portal page template that includes, rightclick A link for the Access Gateway Plug-in, click Save Target as, and specify a location in the dialog box. To customize the template 1. Determine how many custom portal pages that you need. You can use the same portal page for multiple groups. 2. Make a copy of each template that you will use and name the template, using the extension.html. 3. Open the file in Notepad or an HTML editing application. 4. To replace the Citrix image: A. Locate the following line in the template: <img src= citrix-logo.gif /> B. Replace citrix-logo.gif with the file name of your image. For example, if your image file is named logo.gif, change the line to: <img src= logo.gif /> An image file must have a file type of GIF or JPG. Do not change other characters on that line. 5. Save the file.

147 Chapter 9 Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in 147 Installing Custom Portal Page Files Custom portal pages and referenced image files must be installed on the Access Gateway. To select a portal page 1. On the Portal Page Configuration tab, click the Portal Pages tab and click Add File. 2. In File title, type the title of the file you are adding. The file title can help you easily associate the portal page with a group. For example, you might have a primary portal page used by many groups and a separate portal page used only by guests. In that case, you might identify the files as Primary Logon and Guest Logon, respectively. Alternatively, you might have several logon pages that correspond to user groups and use names such as Admin Logon, Student Logon, and IT Logon. 3. In File type, select the type. Portal pages must be an HTML file. Any images referenced from an HTML page must be either GIF or JPG files. 4. Click Upload File. 5. Navigate to the file and click Open. The file is installed on the Access Gateway. To remove a portal file from the Access Gateway On the Portal Pages tab, select the page identifier in the list and click Remove Selected File. Choosing a Portal Page for a Group By default, all users log on to the Access Gateway using the Access Gateway Plug-in from the default portal page or by downloading and installing the Access Gateway Plug-in on the client device. You can load custom portal pages on the Access Gateway, as described in Installing Custom Portal Page Files on page 147, and then select a portal page for each group. This enables you to control which Access Gateway client software is available by group. Note: Disabling logon page authentication on the Global Cluster Policies tab overrides the logon page setting for all groups. For more information, see Enabling Logon Page Authentication on page 143.

148 148 Citrix Access Gateway Standard Edition Administrator s Guide To specify a portal page for a group 1. On the Access Policy Manager tab, under User Groups, right-click a group and click Properties. 2. On the Gateway Portal tab, under Portal configuration, click Use this custom portal page, select the page and click OK. Configuring a Portal Page with Multiple Logon Options Users can have the option to log on using Access Gateway Plug-in or the Web Interface from one Web page. This portal page cannot be configured like the default portal page. The user is presented with two icons and users can choose which method they want to use to log on to the Access Gateway. These choices are: Citrix Access Gateway. This icon starts the Access Gateway Plug-in. After the user is logged on, the Web Interface appears. Citrix XenApp. This icon redirects the user to the Web Interface to log on. This portal page is displayed only when the Redirect to Web Interface and Use the multiple logon option page check boxes are selected on the Gateway Portal tab. To configure multiple logon options 1. On the Access Policy Manager tab, right-click a group in the left pane and then click Properties. 2. On the Gateway Portal tab, select Redirect to Web Interface. 3. In Path, type the path of the server that is hosting the Web Interface. The default site path for Citrix Presentation Server 4.2 is Citrix/MetaFrame/ auth/login.aspx. The default site path for Citrix Presentation Server 4.5 is /Citrix/ AccessPlatform. The default site path for Citrix XenApp 5.0 is /Citrix/XenApp. 4. In Web server (IP address or FQDN), type the IP address or FQDN of the server that is hosting the Web Interface. 5. To secure the connection, select Use a secure connection. 6. To provide Access Gateway Plug-in log on, select Use the multiple logon option page and click OK.

149 Chapter 9 Configuring Logon and Portal Pages for Citrix Access Gateway Plug-in 149 Note: The Web Interface must be configured to support connections from the Access Gateway to complete this configuration. For more information about configuring the Web Interface, see the Citrix Access Gateway Standard Edition Integration Guide for Citrix XenApp and Citrix XenDesktop. Logging On When Pre-Authentication Policies are Configured If a pre-authentication policy is configured on the Access Gateway, when the user connects using a Web address or from the Start menu, the Citrix Prescan plug-in is downloaded and installed on the client device. If the client device passes the pre-authentication policy check, users are then connected to the logon page where they can connect to the Access Gateway using their credentials. If the preauthentication policy check fails, the users receive an error message instructing them to contact their help desk or system administrator. For more information, see Configuring Pre-Authentication Policies on page 112.

150 150 Citrix Access Gateway Standard Edition Administrator s Guide

151 CHAPTER 10 Maintaining the Access Gateway This chapter describes Access Gateway maintenance settings and the tools used to configure them. All submitted configuration changes are applied automatically to the Access Gateway and do not cause a disruption for users connected to the appliance. Policy changes take effect immediately; if a connection violates a new policy, it is closed. In This Chapter Access Gateway Administration Tools Upgrading the Access Gateway Software Reinstalling the Access Gateway Software Saving and Restoring the Access Gateway Configuration Restarting and Shutting Down the Access Gateway Allowing ICMP Traffic Configuring Third-Party Personal Firewalls Access Gateway Administration Tools Access Gateway administration uses a combination of the Administration Portal and the Administration Tool to administer the appliance and monitor network connections. The Administration Tool contains all Access Gateway configuration controls, except for administrative user account management, which is available only from the Administration Portal and the serial console. The Administration Portal provides downloads and administration of some Access Gateway settings.

152 152 Citrix Access Gateway Standard Edition Administrator s Guide The Administration Tool The Administration Tool allows you to configure global settings once and then publish them to multiple Access Gateway appliances on your network. You can also view appliance statistics and monitor network usage from the Administration Tool. The left pane of the Administration Tool window displays Help information for the current tab. The online Help corresponds to the task you are completing. There is also an Alerts box located above the online help. Alerts inform you when there is a problem with the Access Gateway, such as a missing license or certificate. The Administration Tool is downloaded and installed from the Administration Portal. Important: If you upgrade from a previous version of the Access Gateway, you must uninstall the Administration Tool using Add or Remove Programs in Control Panel and then install the latest version from the Administration Portal. To install and start the Administration Tool 1. In the Administration Portal, click Downloads. 2. Under Access Gateway Administration Tool, click Install the Access Gateway Administration Tool and click Run. 3. To install the Administration Tool, follow the instructions in the wizard. 4. To start the Administration Tool, click Start > All Programs > Citrix > Access Gateway Administration Tool 4.6 > Access Gateway Administration Tool 4.6 or click the icon on your desktop. 5. In the Administrator Login dialog box, in Host (IP or FQDN), type the IP address of the Access Gateway. 6. In Administrator Username, type root. 7. In Administrator Password, type the default password rootadmin or the new password if it was changed using the serial console or Administration Portal and click Connect.

153 Chapter 10 Maintaining the Access Gateway 153 Administering Multiple Versions of the Access Gateway If you have multiple appliances in your network and they are different versions, you can install multiple instances of the Administration Tool on your computer. You can use the Access Gateway Version 4.6 Administration Tool to administer earlier versions of the Access Gateway appliance. You can use the Access Gateway Version 4.6 Administration Tool to administer earlier versions of the Access Gateway appliance. To find out which version of the tool you are using, on the Access Gateway Cluster tab, click the Statistics tab and then the System tab. If you are connecting to an older version of the Access Gateway, new features are not supported. The Administration Tool does not disable those settings, but discards them without any warning. The following are unsupported features when connecting to earlier versions of the Access Gateway: Access Gateway Version Feature That is Not Supported or earlier Enable application acceleration with Citrix Branch Repeater or earlier Incorrect password caching Load balancing initial logon requests to Access Gateway Advanced Edition or earlier Prompt to upgrade earlier versions of the Access Gateway Plug-in Name change from Secure Access Client to Access Gateway Plug-in In addition, the network monitoring tools that are incorporated on the Access Gateway Cluster tab in Version 4.6 are not supported in earlier versions of the Access Gateway. The Administration Portal The Administration Portal provides a Web-based interface for administrators. There are several tabs in the Administration Portal that provide a convenient place to do some administrative tasks of the Access Gateway. To open the Administration Portal 1. In a Web browser, type 2. Type the administrator user name and password. The default is root and rootadmin.

154 154 Citrix Access Gateway Standard Edition Administrator s Guide The Administration Portal opens. Below is a description of the tasks you can perform with the Administration Portal. Downloading Tools and Documentation On the Downloads page, you can do the following: Download the Administration Tool Download the Access Gateway documentation Download a portal page template Download a sample for users Download Access Gateway-specific SNMP data Configuring the Administrator Password The Access Gateway has a default administrator user account with full access to the appliance. To protect the Access Gateway from unauthorized access, change the default password during your initial configuration. The Access Gateway is preconfigured with the default user name of root and password of rootadmin. The administrator password can be changed in the Administration Portal or the serial console. Citrix recommends that you change the administrator password using the serial console when the appliance is first installed. For more information, see Configuring TCP/IP Settings Using the Serial Console on page 32. Note: To reset the root administrative password to its default, you must reinstall the Access Gateway server software. The new password can be six to 127 characters in length. The password cannot begin or end with a space. To change the administrator password in the Administration Portal 1. In the Administration Portal, on the Administration tab, click Admin Password. 2. Under Administrator Password, type the new password in the fields provided. 3. Click Change Password.

155 Chapter 10 Maintaining the Access Gateway 155 Viewing Logging Information The Logging page displays the log for the Access Gateway. This is the same log that is accessed from the Administration Tool on the Access Gateway Cluster > Logging/Settings tab. You can also locate the build version of the Access Gateway on this tab. Performing Maintenance Tasks You can perform administrative tasks on the Maintenance page. These include: Uploading a signed certificate (.crt) Uploading a private key and certificate (.pem) Typing the password for a private key Uploading a saved configuration or appliance upgrade Checking for appliance upgrades Saving the appliance configuration Restarting and shutting down the appliance You can also log off from the Administration Portal by clicking Log Out. Managing External Connections to the Administration Portal By default, if the Access Gateway is configured to use both network adapters, the external adapter can be used to access the Administration Portal from the Internet. To block access to the Administration Portal from the Internet, clear the check box for this option. To block external access to the Administration Portal 1. In the Administration Tool, click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Access management, clear Enable external administration. 3. Click Apply Change.

156 156 Citrix Access Gateway Standard Edition Administrator s Guide Upgrading the Access Gateway Software The software that resides on the Access Gateway can be upgraded when new releases become available. You can check for updates from the Administration Portal. You can upgrade to a new release only if your Access Gateway licenses are under the Subscription Advantage program when the update is released. Subscription Advantage can be renewed at any time. For more information, see the Citrix Support Web site at Important: The Linux operating system for Access Gateway Version 4.6 is upgraded to a new version. To install Version 4.6 on the Access Gateway, you must reimage the appliance and then install the software. For more information about reimaging the appliance, see Reinstalling the Access Gateway Software on page 158. To check for software updates 1. Open the Administration Portal and click Maintenance. 2. Click Check for Server Upgrade. The Citrix Support Web site opens and you can download the upgrade from the Web site. This version of the Access Gateway can read saved configurations from earlier versions of the appliance. When a saved configuration from an earlier version is restored to Access Gateway Version 4.6, it is automatically converted to the new format. When upgrading from an older version of the Access Gateway to this release, it is important that you save your current configuration before upgrading. When you upgrade to Version 4.6 and save the configuration file, it cannot be used on earlier versions of the Access Gateway. If you attempt to upload the Version 4.6 configuration file to an earlier version, the Access Gateway becomes inoperable. If you need to restore an earlier version of the software, the appliance must be completely reimaged. After reimaging the appliance, you can restore the saved configuration. Important: The Access Gateway has a default administrator password of rootadmin. If you change the administrator password, it must be six or more characters in length.

157 Chapter 10 Maintaining the Access Gateway 157 Restoring Saved Certificate Private Keys The private keys of certificates that are generated with Access Gateway Version 4.5 or later are encrypted and password-protected. The new private keys are not backward compatible with earlier versions of the Access Gateway software. Therefore, it is important that you save your current configuration before upgrading. When a saved configuration is restored to the appliance, the private key password is not required. The password is also not required when saving the appliance configuration. When a certificate is installed or created using Access Gateway Version 4.6, the password is required. If you are uploading a new certificate generated using Version 4.5 or restoring a saved configuration from an earlier version of the software, the password is requested. If the private key of the certificate is encrypted, the password is used to decrypt the key. If the private key is not encrypted, the password is used to encrypt it. If you are upgrading from a previous version of the Access Gateway, and the private key does not have a password, a random password is generated and the private key is encrypted with it. Installing the Software Upgrade To upload the new software to the appliance, use the Administration Tool. Before installing the upgrade, read the documentation that accompanies the software. Note: When you upload a server upgrade, the Access Gateway drops the active sessions, so it is best to upgrade the server when network traffic is at a minimum. To upgrade the Access Gateway 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. Click the Administration tab. 3. Under Upgrade and configuration management, next to Upload an upgrade or saved configuration, click Browse. 4. Locate the upgrade file that you want to upload and click Open. The file is uploaded and you are prompted to restart the Access Gateway. Note: You can also upgrade the Access Gateway software using the Maintenance page in the Administration Portal

158 158 Citrix Access Gateway Standard Edition Administrator s Guide When you upgrade the Access Gateway, all of your configuration settings are saved. For information about saving and restoring a configuration, see Saving and Restoring the Access Gateway Configuration on page 160. Reinstalling the Access Gateway Software If you need to perform a clean installation of the Access Gateway software, you can do so using the original software that came with the appliance. If you want to keep your configuration settings, it is important to backup your configurations before reinstalling the software. Reinstalling the Software on the Model 2000 The Access Gateway Model 2000 uses the Restore CD-ROM to reinstall the software. To reinstall the Access Gateway server software on the Model Save the Access Gateway configuration setting as described in Saving and Restoring the Access Gateway Configuration on page Make sure that a computer capable of hosting terminal emulation software is connected to the Access Gateway; turn on both systems. 3. Insert the Access Gateway Restore CD-ROM in the CD drive of the Access Gateway to start the installation program. When installation is complete, the serial console displays the message Installation successful. 4. Remove the Restore CD-ROM and turn off the Access Gateway. 5. Turn on the Access Gateway. 6. Restore the configuration settings as described in Saving and Restoring the Access Gateway Configuration on page 160. Reinstalling the Software on the Model 2010 On the Model 2010, the Access Gateway software is installed using a USB storage device. The software is downloaded to your Windows computer and then copied to the storage device. You then plug the storage device into the Access Gateway and reinstall the software.

159 Chapter 10 Maintaining the Access Gateway 159 Caution: When the Access Gateway software is copied to the USB storage device, any data on the device is erased. Make sure you are using a USB storage device that does not contain critical information. In addition, if you restart your computer or the Access Gateway with the USB storage device in the USB port, the storage device attempts to reimage the computer or Access Gateway. System Requirements To create the installation package on a USB storage device, you need the following: One gigabyte (GB) USB storage device.net Framework 1.0 One of the following Windows operating systems: Windows 2000 Server Windows 2000 Professional Windows Server 2003 Windows XP Windows Vista USB port on the computer running Windows Access Gateway CD Appliance Software Imaging Tool available from the Citrix Support Web site. Note: The Access Gateway Model 2010 supports Version or later of the Access Gateway software only. To reinstall the Access Gateway server software on the Model Save the Access Gateway configuration settings as described in Saving and Restoring the Access Gateway Configuration on page Make sure that a computer capable of hosting terminal emulation software is connected to the Access Gateway; turn on both systems. 3. Download the Access Gateway software from the Citrix Support Web site to your computer and then copy the image to a USB storage device using

160 160 Citrix Access Gateway Standard Edition Administrator s Guide the Appliance Software Imaging Tool that is also available on the Support Web site. Caution: After copying the Access Gateway software to the USB storage device, remove the device and the Access Gateway CD from the computer immediately. If you restart your computer with the device in the USB port, or the CD in the drive, it could erase information on your computer. 4. Insert the USB storage device in the USB port of the Access Gateway to start the installation program. When installation is complete, the serial console displays the message Installation successful. 5. Remove the USB storage device and turn off the Access Gateway. 6. Turn on the Access Gateway. 7. Restore the configuration settings as described in Saving and Restoring the Access Gateway Configuration on page 160. Saving and Restoring the Access Gateway Configuration When you upgrade the Access Gateway, all of your configuration settings, including uploaded certificates, licenses, and portal pages, are restored automatically. However, if you reinstall the Access Gateway software, you must manually save and then restore your configuration settings. Note: You can also save and restore configuration settings from the Maintenance tab of the Administration Portal. To save the Access Gateway configuration 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Upgrade and configuration management, next to Save the current configuration, click Save Configuration. 3. Save the file, named config.restore, to your computer. The entire Access Gateway configuration, including system files, installed licenses, and installed server certificates, is saved.

161 Chapter 10 Maintaining the Access Gateway 161 After installing the Access Gateway software, you can restore your saved configuration. To restore a saved configuration 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Upgrade and configuration management, next to Upload an upgrade or saved configuration, click Browse. 3. Locate the file named config.restore and click Open. After the configuration file is uploaded, restart the Access Gateway. All of your configuration settings, licenses, and certificates are restored. If you use RSA SecurID authentication, you must reset the node secret on the RSA ACE/Server, as described in Resetting the Node Secret on page 83. Because the Access Gateway settings were restored, the node secret no longer resides on the appliance and attempts to authenticate with the RSA ACE/Server fail until the node secret is reset. Restarting and Shutting Down the Access Gateway You can restart and shut down the Access Gateway from either the Administration Portal or the Administration Tool. Restarting the Access Gateway After making changes to the Access Gateway, you might need to restart the appliance. To restart the Access Gateway 1. From the Administration Tool, click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Access Gateway management, next to Restart the appliance, click Restart. -or- On the Action menu, click Restart Access Gateway name, where Access Gateway name is the name of the appliance. You can also restart the Access Gateway from the Administration Portal.

162 162 Citrix Access Gateway Standard Edition Administrator s Guide To restart the Access Gateway using the Administration Portal On the Maintenance tab and next to Restart the Server, click Restart. Shutting Down the Access Gateway Never shut down the Access Gateway by powering it off. Use the command in the Administration Tool or in the Administration Portal to shut down the appliance. Use the power switch only to power on the appliance. To shut down the Access Gateway 1. From the Administration Tool, click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Access Gateway management, next to Shut down the appliance, click Shut down the appliance. - or - On the Action menu, click Shut down Access Gateway name, where Access Gateway name is the name of the appliance. The Access Gateway can also be shut down using the Administration Portal. To shut down the Access Gateway using the Administration Portal On the Maintenance tab, next to Shut down the Server, click Shut down. Initializing the Access Gateway After changing some administration settings, you must initialize the Access Gateway for the changes to take effect. When it is necessary to initialize the Access Gateway, a message appears in the Alerts panel of the Administration Tool. Initializing the Access Gateway disconnects all users from the Access Gateway. Perform this procedure when Access Gateway usage is at its lowest. To initialize the Access Gateway On the Administration tab, under Access Gateway management, next to Initialize the appliance, click Initialize. - or - On the Action menu, click Initialize Access Gateway name, where Access Gateway name is the name of the appliance.

163 Allowing ICMP Traffic Chapter 10 Maintaining the Access Gateway 163 Internet Control Message Protocol (ICMP) traffic to the Access Gateway is disabled by default. To enable ICMP traffic, use the Access Gateway Cluster > Administration tab. When ICMP traffic is enabled, users can ping servers on the internal, secure network. The Access Gateway itself cannot receive ICMP traffic. To enable ICMP traffic 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. On the Administration tab, under Access management, select Allow ICMP traffic and click Apply Change. Configuring Third-Party Personal Firewalls If a user cannot establish a connection to the Access Gateway or cannot access allowed resources, it is possible that the firewall software on the user s computer is blocking traffic. The Access Gateway works with any personal firewall, provided that the application allows the user to specify a trusted network or IP address for the Access Gateway. Citrix recommends that the user s personal firewall allow full access for the Citrix Access Gateway Plug-in. If you do not want to allow full access, the following UDP and UDP/TCP ports need to be open on the client device: (UDP) (UDP/TCP) (UDP) (UDP) Personal firewalls need to be configured to allow traffic to and from the Access Gateway IP address or FQDN. To find out which ports are open, use the Access Gateway Plug-in Properties page that is accessible from the connection icon in the notification tray. The ports that are open are listed on the Details tab. If you are installing the Access Gateway Plug-in on a client device that does not have administrative rights, users cannot modify firewall rules to allow access. Users must log on as an administrator or with administrator rights to modify firewall rules. If the client device is running Windows Firewall, installation of the Access Gateway Plug-in tries to add automatically an exception in the firewall rules. If the client device is using a third-party firewall, you need to manually configure the correct ports.

164 164 Citrix Access Gateway Standard Edition Administrator s Guide To view Access Gateway Plug-in status properties Double-click the Access Gateway connection icon in the notification area. Alternatively, right-click the icon and choose Properties from the menu. The Citrix Access Gateway dialog box appears. The properties of the connection provide information that is helpful for troubleshooting. The properties include: The General tab displays connection information. The Details tab displays server information and a list of the secured networks users are allowed to access. The Access Lists tab displays the access control lists (ACLs) that are configured for the user connection. This tab does not appear for users who are not in a group or if an ACL is not configured for a group. The following are suggestions for using some popular firewalls with the Access Gateway. Note: For complete instructions about configuring firewalls, see the manufacturer s documentation. McAfee Personal Firewall Plus McAfee Personal Firewall Plus settings enable the Access Gateway Plug-in to reach the Internet and the resources allowed by the Access Gateway. The settings assume that you are using the Standard security level. Make sure that you add the IP address or range of allowed resources as trusted IP addresses. In the System Services list, select each service that you plan to use over the VPN connection. Note: By default, when Citrix Access Gateway Plug-in is installed, Personal Firewall Plus prompts you to grant or block access for the application. Select Grant Access. Norton Personal Firewall If you are using the default Norton Personal Firewall settings, you can simply respond to the Program Control alerts the first time that you attempt to start the Access Gateway Plug-in or when you access a blocked location or application. When you respond to such an alert, you can select to always permit or deny the action. You want to permit the action.

165 Chapter 10 Maintaining the Access Gateway 165 Sygate Personal Firewall (Free and Pro Versions) Each time the Sygate Personal Firewall encounters new activity for which it does not have a rule, it displays a prompt. Grant access to the applications and locations that you want to access through the Access Gateway Plug-in. Select yes when the prompt appears. Tiny Personal Firewall Tiny Personal Firewall settings enable the Access Gateway Plug-in to reach the Internet and the resources allowed by the Access Gateway. To configure the settings, open the Tiny Personal Firewall administration window and change the settings for filter rules. Note: One method to configure Tiny Personal Firewall is to respond to the prompts displayed when the firewall encounters new activity for which it does not have a rule. Configure Tiny Personal Firewall before installing the Access Gateway Plug-in. After you apply the configuration changes and start the Access Gateway Plug-in, Tiny Personal Firewall displays several Incoming Connection Alerts related to the Access Gateway Plug-in. For each alert, you want to permit the connection. ZoneAlarm Pro To enable the Access Gateway Plug-in to reach the Internet and the resources allowed by the Access Gateway, you need to define the FQDN of the appliance as a trusted zone.

166 166 Citrix Access Gateway Standard Edition Administrator s Guide

167 CHAPTER 11 Installing Additional Access Gateway Appliances You can install multiple Access Gateway appliances in your network. The additional appliances can be in a cluster, behind a load balancer, or configured to failover to another Access Gateway on the network. When Access Gateway appliances operate as a cluster, the settings that control user access to the internal network resources are identical on each Access Gateway in the cluster. A user can connect to any Access Gateway in the cluster and receive the same access privileges to the internal network resources. You can install multiple Access Gateway appliances for one or both of these reasons: Scalability. If the size of your user population exceeds the capacity of a single Access Gateway, you can install multiple appliances to accommodate the user load. High availability (failover). You can install multiple appliances so that an Access Gateway is always available to handle the connections if one Access Gateway fails. This configuration provides a high availability of the internal network to the remote users. If you want to support both scalability and failover, deploy a load balancer in front of the Access Gateway appliances. A load balancer deployment is usually suitable for larger organizations that have many remote users. For more information, see Configuring Multiple Appliances to Use a Load Balancer on page 171. To support only failover, you can deploy two (or more) Access Gateway appliances, and use the Administration Tool to configure one appliance to failover to up to three other appliances. If an Access Gateway fails, users are connected to another Access Gateway. This deployment does not require a load balancer. For more information, see Configuring Access Gateway Failover on page 175. When you configure load balancing and failover, appliances can be added to the cluster, but it is not required.

168 168 Citrix Access Gateway Standard Edition Administrator s Guide This chapter assumes you completed the following tasks: Configured the TCP/IP settings on the General Networking tab on each Access Gateway. Installed a license on one Access Gateway in the network, called the license server. One Access Gateway in the network can act as a license server. The license is installed on one appliance and then the rest of the appliances are configured to obtain their licenses from the license server. Configured the other appliances to connect to the license server to obtain licenses. The other appliances installed in the network do not have to be part of the cluster to obtain a license. For more information about licensing, see Installing Licenses on page 39. Installed a signed, secure certificate from a Certificate Authority on each Access Gateway. Each appliance in the cluster must have its own unique FQDN. If the appliances in a cluster are deployed behind a load balancer, each appliance must have the same SSL server certificate installed that has the same FQDN. If the appliances in a cluster are configured to support failover (but are not deployed behind a load balancer), each appliance must have a unique SSL server certificate installed. If the appliances are clustered, configure the settings on at least one appliance in the network using the following tabs in the Administration Tool: Access Policy Manager Authentication, Global Cluster Policies Portal Page Configuration Group Priority Creating a Cluster of Access Gateway Appliances If you have multiple appliances in your network and each one requires the same settings, you can create a cluster. The settings that can be published are configured on one Access Gateway and then published to the rest of the appliances. All of the appliances in the cluster appear on the Access Gateway Cluster tab in the Administration Tool. This provides ease-of-use and saves time when configuring and maintaining the appliances on your network.

169 Chapter 11 Installing Additional Access Gateway Appliances 169 The settings on the Access Gateway Cluster tab apply to individual Access Gateway appliances. These settings are not published to the cluster. These include: General Networking Logging Administration Certificates Licensing Routes Name Service Providers Failover Date and Time Statistics The settings on the following tabs in the Administration Tool are published to each appliance in the cluster. Access Policy Manager Authentication Global Cluster Policies Portal Page Configuration Group Priority Publishing these settings to the other appliances ensures that all appliances in the cluster have identical settings to control user access to the internal network resources. Note: All Access Gateway appliances in the cluster must be the same version. For example, if you install one appliance with Version 4.6 all other appliances must have Version 4.6 Before adding each appliance to the cluster, the Access Gateway is installed using the procedures in Chapter 4, Installing the Access Gateway for the First Time on page 29 and then add the appliance to the cluster.

170 170 Citrix Access Gateway Standard Edition Administrator s Guide Important: Each appliance in the cluster must have the same administrator password. If an Access Gateway has a different administrator password, it cannot be administered in the cluster. Citrix recommends changing the administrator password during installation of the Access Gateway using the serial console. For more information, see Configuring TCP/IP Settings Using the Serial Console on page 32 and Configuring the Administrator Password on page 154. The administrator password can be 6 to 127 characters in length. Passwords cannot start or end with a space. To add appliances to the cluster 1. Open the Administration Tool on the primary Access Gateway. 2. Click the Access Gateway Cluster tab. 3. Under Add an Access Gateway to the Cluster, in FQDN, type the FQDN of an additional Access Gateway, and click Add. 4. Repeat Steps 1 to 3 to add all of the appliances to the cluster. After all of the appliances are added to the cluster, you can then publish the settings from the primary Access Gateway to the cluster. To publish the settings from one appliance to the other appliances in the cluster 1. From the Administration Tool on the first Access Gateway that you installed (the primary appliance), click the Publish tab. 2. Click Publish. The settings on the first Access Gateway are published to all of the Access Gateway appliances in the cluster. 3. Click the Access Gateway Cluster tab and then click the Administration tab. 4. Under Access Gateway management, next to Restart the appliance, click Restart. After you publish the configuration settings to all of the appliances in the cluster, you must restart each Access Gateway appliance for the changes to take effect. Each Access Gateway that is in the cluster is listed on the Publish tab. The following synchronization messages appear in the Synchronization Status field for each appliance: In Sync. The Access Gateway configuration is successfully published. Not in Sync. A change was made in the settings but is not published.

171 Chapter 11 Installing Additional Access Gateway Appliances 171 Sync Failed. Unable to synchronize the Access Gateway. Check the appliance and try the synchronization again. Unknown Status. The status of the Access Gateway cannot be determined. Check the appliance and try the synchronization again. Configuring Multiple Appliances to Use a Load Balancer You can deploy multiple Access Gateway appliances behind a load balancer to support a large population of remote users and maintain high availability of the internal network to the users. The load balancer you deploy with the appliances must support load balancing based on the Source IP (Src IP).. Multiple Access Gateway appliances deployed behind a load balancer The load balancer is configured with a unique IP address or FQDN. This address is used by the Citrix Access Gateway Plug-in or a Web browser to connect to the load balancer. The load balancer distributes the client connections evenly among the appliances deployed behind it. Upon receiving a client connection, the load balancer uses an algorithm to select one of the appliances from the list and directs the client connection to the selected Access Gateway. In addition to an equal distribution of the client connections, a load balancer also provides high availability of the internal network. To provide high availability, some load balancers can detect when appliances deployed behind them are failing. If the load balancer detects that an appliance is

172 172 Citrix Access Gateway Standard Edition Administrator s Guide failing, the load balancer removes the appliance from the list of available appliances and redirects client connections to the remaining active appliances. When the Access Gateway comes back online, the load balancer adds it back to the list of active appliances. This approach ensures that all client connections have continuous access to the internal network if one Access Gateway fails. Configuring Load Balancing Use the manufacturer s documentation to install and configure the load balancer in the network DMZ. Be sure to perform each of these configurations on the load balancer to enable it to work with the Access Gateway appliances: Configure the load balancer to load balance connections to the Access Gateway appliances based on the Source IP. Configure the load balancer with an FQDN that is used by the Access Gateway when establishing a connection to the load balancer. Configure the load balancer so that it does not terminate the SSL encryption. The SSL connection must be passed to the Access Gateway and the Access Gateway must terminate the SSL encryption. Configuring Access Gateway Appliances to Operate behind a Load Balancer After you install and configure the load balancer, do the following for the Access Gateway appliances deployed behind the load balancer: For each Access Gateway, connect the network cables so that Interface 0 connects to the load balancer and Interface 1 connects to the internal network. Configure the Access Gateway appliances deployed behind a load balancer to operate as a cluster. Creating a cluster ensures that each Access Gateway is configured to support access to network resources in an identical way. The load balancer can connect the user to any Access Gateway in the cluster and the user receives the same access privileges. For more information, see Creating a Cluster of Access Gateway Appliances on page 168. Create a single SSL server PEM-formatted certificate and private key and upload this same certificate and key to each of the Access Gateway appliances. For more information, see Creating a Certificate for Appliances Deployed behind a Load Balancer on page 173.

173 Chapter 11 Installing Additional Access Gateway Appliances 173 Creating a Certificate for Appliances Deployed behind a Load Balancer When you deploy Access Gateway appliances behind a load balancer, you must deploy the same SSL server certificate and private key on each appliance. Important: Do not use the Certificate Signing Request feature available from the Access Gateway Cluster tab of the Administration Tool to create the SSL server certificate request. This feature creates an individual private key on the Access Gateway on which it is run. When Access Gateway appliances are deployed behind a load balancer, each Access Gateway must use the same private key and SSL certificate. To create an SSL server certificate and private key 1. Use an OpenSSL tool, such as Keytool, to create the SSL server certificate request and private key. (To learn more about OpenSSL and available tools, browse to Create the server certificate request in the PEM format. When creating the server certificate request, use the FQDN of the load balancer as the server name in the request. Do not use the FQDN of any of the Access Gateway appliances in the request. Optionally, you can use an asterisk for the server name in the FQDN that you enter in the server certificate request. For example, you can create an SSL server certificate request for a server name in this format: *.domain.com Create the private key separately from the server certificate request. 2. Send the SSL server certificate request to a Certificate Authority (CA) to be signed. Send only the server certificate request in the PEM format. Do not send the private key. 3. When you receive the signed SSL server certificate request from the CA, manually add the private key to the top of the signed certificate. For more information about combining a private key with a signed certificate, see Combining the Private Key with the Signed Certificate on page Upload the SSL server certificate and private key to each of the Access Gateway appliances deployed behind the load balancer: A. Click the Access Gateway Cluster tab and expand the window for the Access Gateway.

174 174 Citrix Access Gateway Standard Edition Administrator s Guide B. Click the Administration tab. C. Under Secure certificate management, next to Upload a.pem private key and signed certificate, click Browse. D. Navigate to and select the file containing the combined private key and signed PEM certificate and click Open. Repeat Step 4 to upload the private key and PEM certificate to each Access Gateway deployed behind the load balancer. Specifying a Load Balancer as the Default Gateway Some load balancers or network configurations might require you to specify the load balancer as the Default Gateway for the Access Gateway. If you specify the load balancer as the Default Gateway, configure static routes on the Access Gateway so that all traffic destined for the secure network is routed to an internal network that can successfully route all internal traffic. If the Access Gateway receives a packet destined for an unknown IP address, it sends the packet to the Default Gateway address. If the load balancer is configured as the Default Gateway, the Access Gateway can use static routing to ensure that packets destined for internal locations are delivered. If the Access Gateway receives a packet destined for an internal address, and the static routing table does not include an appropriate route for the packet, the packet might be lost. For example, assume the load balancer is specified as the Default Gateway and the following conditions exist: You have three internal networks: , , and The network can route packets to networks and However, the and networks cannot route packets to other networks. In this environment, you must create static routes associated with Interface 1 on the Access Gateway. These static routes must direct all traffic destined for the and networks to the network through Interface 1 of the Access Gateway. For more information, see Configuring Dynamic and Static Routes on page 53.

175 Chapter 11 Installing Additional Access Gateway Appliances 175 Configuring Load Balancing with Advanced Access Control When Advanced Access Control is selected, this check box enables or disables load balancing for logon requests. The check box is selected by default when there are two servers running Advanced Access Control. The load balancing method is Round Robin where the system distributes incoming requests to each server in rotation, regardless of the load on the servers. If there is only one server running Advanced Access Control, the check box is not available. To configure load balancing with Advanced Access Control 1. In the Administration Tool, on the Access Gateway Cluster tab, expand the window for the Access Gateway and click Advanced Options. 2. Click Load Balance initial Logon requests and click Submit. Note: The Access Gateway appliance must be configured to use Access Gateway Advanced Edition to enable this setting. Configuring Access Gateway Failover To ensure high availability of your internal network to remote users, you can deploy two or more Access Gateway appliances and configure failover between them. This deployment ensures that an alternate Access Gateway is available if another Access Gateway fails. Because Access Gateway failover is active/active, you can use each Access Gateway as a primary gateway for a different set of users. Multiple Access Gateway appliances deployed to support failover

176 176 Citrix Access Gateway Standard Edition Administrator s Guide When an Access Gateway is configured to support failover, the Access Gateway provides the Access Gateway Plug-in with a failover list. During the initial connection from the Access Gateway Plug-in, the Access Gateway provides the failover list to the client device. If the client device loses the connection to the primary Access Gateway, it iterates through the list of failover appliances. If the primary Access Gateway fails, the client device tries to reconnect for 20 seconds. If the attempt is unsuccessful, it references the failover list to make the connection. The client device performs a DNS lookup for the first failover appliance and tries to connect. If the first failover Access Gateway is not available, the client device tries the next failover appliance. When the client device successfully connects to a failover Access Gateway, the client device is prompted to log on. You can enter up to three Access Gateway appliances in the failover list. To configure failover 1. Click the Access Gateway Cluster tab and then click the Failover Servers tab. 2. In First failover appliance, Second failover appliance, and/or Third failover appliance, type the external IP address or the FQDN of the Access Gateway to be used for failover operation. The Access Gateway appliances are used for failover in the order listed. 3. In Port, type the port number. The default is 443. Click Submit. Note: When multiple Access Gateway appliances are deployed to support failover, you must install a different SSL server certificate on each Access Gateway. You can use the Certificate Signing Request feature of the Administration Tool to create the SSL certificate request for each Access Gateway that supports failover. For more information, see Creating and Installing Certificates on page 46.

177 APPENDIX A Monitoring the Access Gateway The Administration Tool provides Access Gateway monitoring tools. Tools that were in the Administration Desktop in earlier versions of the Access Gateway are incorporated into the Administration Tool. You can view network activity on the Access Gateway using the Logging tab on the Access Gateway Cluster tab. You can view appliance statistics on the Access Gateway Cluster tab. On the Statistics tab, you can do the following tasks: View Access Gateway system information. View global statistics that are a group of counters that track parameters such as user logon and license usage. These counters are reset every time the Access Gateway is restarted. View current users that are logged on using the Access Gateway Plug-in, Citrix XenApp Plug-ins or Citrix Desktop Receiver. On the Net Tools tab, you can perform several tasks to monitor the health of the Access Gateway and your network. These tasks include ping, trace route, port scanning and packet capturing. In This Chapter Viewing and Downloading System Message Logs Enabling and Viewing SNMP Logs Viewing System Statistics Monitoring Access Gateway Operations

178 178 Citrix Access Gateway Standard Edition Administrator s Guide Viewing and Downloading System Message Logs There are two types of logging for the Access Gateway. All of the logs are stored locally and can be viewed from either the Administration Tool or the Administration Portal. Optionally, this same information can be sent to a syslog server. System message logs contain information that can help Access Gateway support personnel assist with troubleshooting or forensics. By reviewing the information provided, you can track changes that can affect the stability and performance of the Access Gateway. System message logs are archived on the Access Gateway for 30 days. The oldest log is then replaced with the current log. To keep log files longer, use a syslog server. You can download one or all logs at any time. You can also have system messages forwarded to your syslog server, as described in Forwarding System Messages to a Syslog Server on page 179. Note: If you cannot connect to the Access Gateway using the Administration Tool, go to the Administration Portal and click the Logging tab. To view and filter the system log 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. Click the Logging/Settings tab. 3. Click Show Log File. The log for today s date appears. To display the log for a prior date, select the date in the Log Archive list and click View Log. 4. To download a log: Select a log in the Log Archive list and next to Selected Log File, click Download. The log file name defaults to yyyymmdd.log. To download all of the logs, next to All Log Files, click Download. The file name defaults to log_archive_yyyymmdd.tgz. To download logs from the Access Gateway, you must have a data compression utility, such as WinZip, installed on your computer. The logs are downloaded as.tgz files and that data must be extracted. After the file downloads, it can be unzipped to access the individual log files.

179 Appendix A Monitoring the Access Gateway 179 Viewing Access Gateway Plug-in Connection Logs The Access Gateway Connection Log contains real-time connection information that is particularly useful for troubleshooting Access Gateway Plug-in connection issues. The connection log is located using the Access Gateway icon from the client device. The user can send you this information when troubleshooting a connection. To view the Connection Log 1. Right-click the Access Gateway Plug-in icon in the notification area. 2. Choose Connection Log from the menu. The Connection Log for the session appears. Note: The Connection Log is written to the user s computer at %Temp%\cag_plugin_connection_log.txt. The log is overwritten each time a new Access Gateway connection is established. Citrix recommends that when you are getting the Connection Log from the user, that the user turns on verbose mode, which provides detailed information for troubleshooting, such as certificate verification. To turn on verbose mode in the client connection log 1. Right-click the Access Gateway icon and click Connection Log. 2. On the Options menu, click Verbose Mode. Forwarding System Messages to a Syslog Server The Access Gateway archives system messages, as described in Viewing and Downloading System Message Logs on page 178. You can also have the Access Gateway forward system messages to a syslog server. To forward Access Gateway system messages to a syslog server 1. Click the Access Gateway Cluster tab and expand the window for the Access Gateway. 2. Click the Logging/Settings tab. 3. Under Syslog settings, in Server, type the IP address of the syslog server. 4. In Facility, select the syslog facility level.

180 180 Citrix Access Gateway Standard Edition Administrator s Guide 5. In Broadcast interval (minutes), type a broadcast frequency in minutes. If the broadcast frequency is set to 0, logging is continuous. 6. Click Submit. Enabling and Viewing SNMP Logs When Simple Network Management Protocol (SNMP) is enabled, the Access Gateway reports the MIB-II system group ( ). The Access Gateway does not support Access Gateway-specific SNMP data. You can configure an SNMP monitoring tool, such as the Multi Router Traffic Grapher, to provide a visual representation of the SNMP data reported by the Access Gateway in response to queries. For a sample of Traffic Grapher output, see Multi Router Traffic Grapher Example on page 180. To enable logging of SNMP messages 1. Click the Access Gateway Cluster tab and then click the Logging/Settings tab. 2. Under SNMP settings, select Enable SNMP. 3. In Location, type the SNMP location. This field is informational only. 4. In Contact, type the contact. This field is informational only. 5. In Community, type the community. This field is informational only. 6. In Port, type the port. 7. Click Submit. Multi Router Traffic Grapher Example The Multi Router Traffic Grapher is a tool used to monitor SNMP data, such as traffic load. Multi Router Traffic Grapher generates HTML pages containing PNG images that provide a visual representation of the traffic. Multi Router Traffic Grapher works under UNIX, Windows 2000 Server, and Windows Server Note: The information in this section provides a general overview of working with Multi Router Traffic Grapher. For information about obtaining and using this tool, visit the Multi Router Traffic Grapher Web site at

181 Appendix A Monitoring the Access Gateway 181 To obtain SNMP data for the Access Gateway through Multi Router Traffic Grapher (in UNIX) 1. Configure the Access Gateway to respond to SNMP queries as discussed in To enable logging of SNMP messages on page Create Multi Router Traffic Grapher configuration files in /etc/mrtg. Each configuration file specifies the object identifiers that the grapher daemon is to monitor, specifies the target from which to obtain SNMP data, and defines the grapher output. The Multi Router Traffic Grapher configuration file. 3. Modify /etc/crontab to perform an SNMP query every five minutes, resulting in graphed data. The various.cfg files listed generate a separate output. 4. View the output in a Web browser. The grapher stores HTML output in the Workdir specified in the configuration file. The output file name that corresponds to the configuration file in Step 2 is vpn.myorg.com.tcpcurrestab.html. Viewing System Statistics To obtain general system statistics, click the Access Gateway Cluster tab, expand the window for the Access Gateway, and then click the Statistics tab. There are three tabs that provide system, global, and user statistics. The statistical information provides an overview of the Access Gateway and includes: The version of the Access Gateway. Length of time the Access Gateway has been running. Memory usage.

182 182 Citrix Access Gateway Standard Edition Administrator s Guide Maximum and used connections. Maximum connections represent the number of licenses that are available for use with the Access Gateway. Logon information for administrators, Access Gateway Plug-in connections, and ICA connections. Current users that are logged on. Licensing information that is specific to the Access Gateway appliance you are viewing. Monitoring Access Gateway Operations The Access Gateway includes a variety of monitoring applications so that you can conveniently access the applications from one location. The monitoring applications are located in the Administration Tool. When you select the Net Tools tab on the Access Gateway Cluster tab, you can monitor network connections. To open the network monitoring tab In the Access Gateway Administration Tool, on the Access Gateway Cluster tab, open the window for the Access Gateway and click the Net Tools tab. On the Net Tools tab, you can perform the following functions: Ping. Allows you to test the availability of Web addresses and IP addresses. Traceroute. Combines the functionality of the traceroute and ping commands in one network diagnostic tool. As traceroute starts, it investigates the network connection between the Access Gateway and the destination host that you specify. After it determines the address of each network hop between the devices, it sends a sequence ICMP ECHO request to each one to determine the quality of the link to each device. As it does this, it prints running statistics about each device. Port Scan. Allows you to determine the DNS servers in the network and the ports that are open. Packet Capture. Enables you to interactively capture packet data from a live network or from a previously saved capture file. When using network monitoring tools on a client device, you might see inbound TCP connections from the Access Gateway on random high ports. These connections are not actually taking place on the wire and are initiated by the NDIS shim component.

183 Appendix A Monitoring the Access Gateway 183 For this reason, IP firewall rules running on the client device must be set to allow traffic to and from the Access Gateway plus traffic to destination IP addresses. Locally, on the client device, all connection-related traffic (such as SYN-ACK, PUSH, ACK and FIN packets) are recreated by the Access Gateway Plug-in to appear from the private server. The client only sends physical traffic to the gateway on port 443. Five UDP socket connections are visible at client initialization. These are: UDP controls information between the network driver and port forwarder TCP/UPD is the payload data UDP is Domain Name Services UDP is ICMP UDP is reserved for future use

184 184 Citrix Access Gateway Standard Edition Administrator s Guide

185 APPENDIX B Securing Connections with Digital Certificates This chapter provides conceptual information about the security technologies used in the Access Gateway solution, helps you identify the number and type of certificates required, and helps you decide how and where to obtain and install them. In This Chapter Introduction to Security Protocols, Cryptography, and Digital Certificates Getting Certificates Getting Server Certificates Using Windows Certificates Requiring Certificates for Internal Connections Using Wildcard Certificates Important: When configuring certificates do not use 512-bit keypairs. They are subject to brute force attacks. Introduction to Security Protocols, Cryptography, and Digital Certificates This section introduces the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, and provides an overview of cryptography and Public Key Infrastructure (PKI). Introduction to Security Protocols SSL and TLS are the leading Internet protocols providing security for e-commerce, Web services, and many other network functions.

186 186 Citrix Access Gateway Standard Edition Administrator s Guide The SSL protocol is today s standard for securely exchanging information on the Internet. Originally developed by Netscape, the SSL protocol became crucial to the operation of the Internet. As a result, the Internet Engineering Taskforce (IETF) took over responsibility for the development of SSL as an open standard. To clearly distinguish SSL from other ongoing work, the IETF renamed SSL as TLS. The TLS protocol is the descendant of the third version of SSL; TLS 1.0 is identical to SSL 3.1. Some organizations, including United States government organizations, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography. The SSL/TLS protocol allows sensitive data to be transmitted over public networks such as the Internet by providing the following important security features: Authentication. A client can determine a server s identity and ascertain that the server is not an impostor. Optionally, a server can also authenticate the identity of the client requesting connections. Privacy. Data passed between the client and server is encrypted so that if a third party intercepts messages, it cannot unscramble the data. Data integrity. The recipient of encrypted data knows if a third party corrupts or modifies that data. Introduction to Cryptography The SSL/TLS protocol uses cryptography to secure communications. Cryptography provides the ability to encode messages to ensure confidentiality. Cryptography is also used to authenticate the identity of a message source and to ensure the integrity of its contents. A message is sent using a secret code called a cipher. The cipher scrambles the message so that it cannot be understood by anyone other than the sender and receiver. Only the receiver who has the secret code can decipher the original message, thus ensuring confidentiality. Cryptography allows the sender to include special information in the message that only the sender and receiver know. The receiver can authenticate the message by reviewing the special information. Cryptography also ensures that the contents of a message are not altered. To do this, the sender includes a cryptographic operation called a hash function in the message. A hash function is a mathematical representation of the information, similar to the checksums found in communication protocols. When the data arrives at its destination, the receiver calculates the hash function. If the receiver s hash function value is the same as the sender s, the integrity of the message is assured.

187 Appendix B Securing Connections with Digital Certificates 187 Types of Cryptography There are two main types of cryptography: Secret key cryptography Public key cryptography In cryptographic systems, the term key refers to a numerical value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information. Secret key cryptography is also known as symmetric key cryptography. With this type of cryptography, both the sender and the receiver know the same secret code, called the key. Messages are encrypted by the sender using the key and decrypted by the receiver using the same key. This method works well if you are communicating with only a limited number of people, but it becomes impractical to exchange secret keys with large numbers of people. In addition, there is also the problem of how you communicate the secret key securely. Public key cryptography, also called asymmetric encryption, uses a pair of keys for encryption and decryption. With public key cryptography, keys work in pairs of matched public and private keys. The public key can be freely distributed without compromising the private key, which must be kept secret by its owner. Because these keys work only as a pair, encryption initiated with the public key can be decrypted only with the corresponding private key. The following example illustrates how public key cryptography works: Ann wants to communicate secretly with Bill. Ann encrypts her message using Bill s public key (which Bill made available to everyone) and Ann sends the scrambled message to Bill. When Bill receives the message, he uses his private key to unscramble the message so that he can read it. When Bill sends a reply to Ann, he scrambles the message using Ann s public key. When Ann receives Bill s reply, she uses her private key to unscramble his message. The major advantage asymmetric encryption offers over symmetric key cryptography is that senders and receivers do not have to communicate keys up front. Provided the private key is kept secret, confidential communication is possible using the public keys.

188 188 Citrix Access Gateway Standard Edition Administrator s Guide Combining Public Key and Secret Key Cryptography. The main disadvantage of public key cryptography is that the process of encrypting a message, using the very large keys common to PKI, can cause performance problems on all but the most powerful computer systems. For this reason, public key and secret key cryptography are often combined. The following example illustrates how this works: Bill wants to communicate secretly with Ann, so he obtains Ann s public key. He also generates random numbers to use just for this session, known as a session key. Bill uses Ann s public key to scramble the session key. Bill sends the scrambled message and the scrambled session key to Ann. Ann uses her private key to unscramble Bill s message and extract the session key. When Bill and Ann successfully exchange the session key, they no longer need public key cryptography communication can take place using just the session key. For example, public key encryption is used to send the secret key; when the secret key is exchanged, communication takes place using secret key encryption. This solution offers the advantages of both methods it provides the speed of secret key encryption and the security of public key encryption. Digital Certificates and Certificate Authorities In the above scenarios, how can Ann be sure that Bill is who he says he is and not an impostor? When Ann distributes her public key, Bill needs some assurance that Ann is who she says she is. The ISO X.509 protocol defines a mechanism called a certificate that contains a user s public key that is signed by a trusted entity called a Certificate Authority (CA). Certificates contain information used to establish identities over a network in a process called authentication. Like a driver s licence, a passport, or other forms of personal identification, certificates enable servers and clients to authenticate each other before establishing a secure connection. Certificates are valid only for a specified time period; when a certificate expires, a new one must be issued. The issuing authority can also revoke certificates. To establish an SSL/TLS connection, you require a server certificate at one end of the connection and a root certificate of the CA that issued the server certificate at the other end.

189 Appendix B Securing Connections with Digital Certificates 189 Server certificate. A server certificate certifies the identity of a server. The type of digital certificate that is required by the Access Gateway is called a server certificate. Root certificate. A root certificate identifies the CA that signed the server certificate. The root certificate belongs to the CA. This type of digital certificate is required by a client device to verify the server certificate. When establishing an SSL connection with a Web browser on a client device, the server sends its certificate to the client device. When receiving a server certificate, the Web browser (for example, Internet Explorer) on the client device checks to see which CA issued the certificate and if the CA is trusted by the client. If the CA is not trusted, the Web browser prompts the user to accept or decline the certificate (effectively accepting or declining the ability to access this site). Now when Ann receives a message from Bill, the locally stored information about the CA that issued the certificate is used to verify that it did indeed issue the certificate. This information is a copy of the CA s own certificate and is referred to as a root certificate. Certificates generally have a common format, usually based on ITU standards. The certificate contains information that includes the: Issuer. The organization that issues the certificates. Subject. The party that is identified by the certificate. Period of validity. The certificate s start date and expiration date. Public key. The subject s public key used to encrypt data. Issuer s signature. The CA s digital signature on the certificate used to guarantee its authenticity. A number of companies and organizations currently act as CAs, including VeriSign, Baltimore, Entrust, and their respective affiliates. Certificate Chains Some organizations delegate the responsibility for issuing certificates to resolve the issue of geographical separation between organization units, or that of applying different issuing policies to different sections of the organization. Responsibility for issuing certificates can be delegated by setting up subordinate CAs. The X.509 standard includes a model for setting up a hierarchy of CAs. In this model, the root CA is at the top of the hierarchy and has a self-signed certificate. The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates signed by the subordinate CAs.

190 190 Citrix Access Gateway Standard Edition Administrator s Guide The hierarchical structure of a typical digital certificate chain. CAs can sign their own certificates (that is, they are self-signed) or they can be signed by another CA. If the certificate is self-signed, they are called root CAs. If they are not self-signed, they are called subordinate or intermediate CAs. If a server certificate is signed by a CA with a self-signed certificate, the certificate chain is composed of exactly two certificates: the end entity certificate and the root CA. If a user or server certificate is signed by an intermediate CA, the certificate chain is longer. The following figure shows the first two elements are the end entity certificate (in this case, gwy01.company.com) and the certificate of the intermediate CA, in that order. The intermediate CA s certificate is followed by the certificate of its CA. This listing continues until the last certificate in the list is for a root CA. Each certificate in the chain attests to the identity of the previous certificate.

191 Appendix B Securing Connections with Digital Certificates 191 Getting Certificates A typical digital certificate chain. Certificate Revocation Lists From time to time, CAs issue certificate revocation lists (CRLs). CRLs contain information about certificates that can no longer be trusted. For example, suppose Ann leaves XYZ Corporation. The company can place Ann's certificate on a CRL to prevent her from signing messages with that key. Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use. Before you trust a public key, make sure that the certificate does not appear on a CRL. Certificate Expiration and Renewal Certificates are issued with a planned lifetime and explicit expiration date. After it is issued, a certificate is considered valid until its expiration date is reached. After the expiration date, the certificate cannot be used to validate a user session. This policy improves security by limiting the damage potential of a compromised certificate. These expiration dates are set by the CA that issued the certificate. Usually, you need to renew a certificate before it expires. Most CAs offer a well documented process for certificate renewal. Consult the Web site of your CA for detailed instructions about renewing certificates. When you identify the number and type of certificates required for your Access Gateway deployment, you must decide where to obtain the certificates. Where you choose to obtain certificates depends on a number of factors, including: Whether or not your organization is a CA, which is likely to be the case only in very large corporations Whether or not your organization has already established a business relationship with a public CA The fact that the Windows operating system includes support for many public Certificate Authorities The cost of certificates, the reputation of a particular public CA, and so on

192 192 Citrix Access Gateway Standard Edition Administrator s Guide If Your Organization Is its Own Certificate Authority If your organization is running its own CA, you must determine whether or not it is appropriate to use your organization s certificates for the purpose of securing communications in your Access Gateway installation. Citrix recommends that you contact your organization s security department to discuss this and to get further instructions about how to obtain certificates. If you are unsure if your organization is a CA, contact your organization s security department or security expert. If Your Organization Is not its Own Certificate Authority If your organization is not running its own CA, you need to obtain your certificates from a public CA such as VeriSign. Obtaining a digital certificate from a public CA involves a verification process in which: Your organization provides information so the CA can verify that your organization is who it claims to be. The verification process may involve other departments in your organization, such as accounting, to provide letters of incorporation or similar legal documents. Individuals with the appropriate authority in your organization are required to sign legal agreements provided by the CA. The CA verifies your organization as a purchaser; therefore your purchasing department is likely to be involved. You provide the CA with contact details of suitable individuals who they can call if there are queries. Getting Server Certificates Your organization s security expert should have a procedure for obtaining server certificates. Instructions for generating server certificates using various Web server products are available from the Web sites of popular CAs such as Verisign and others. For more information about generating a certificate request, see Creating and Installing Certificates on page 46.

193 Appendix B Securing Connections with Digital Certificates 193 Note: Several CAs offer Test Server Certificates for a limited trial period. It might be expedient to obtain a Test Certificate to test the Access Gateway before deploying it in a production environment. If you do this, be aware that you need to download matching Test Root Certificates that must be installed on each client device that connects through the Access Gateway. Digital Certificates and Access Gateway Operation The Access Gateway uses digital certificates to encrypt and authenticate traffic over a connection. If the digital certificate installed on the Access Gateway is not signed by a Certificate Authority, the traffic is encrypted but not authenticated. A digital certificate must be signed by a Certificate Authority to also authenticate the traffic. When traffic over a connection is not authenticated, the connection can be compromised through a man in the middle attack. In such an attack, a third party intercepts the public key sent by the Access Gateway to the Access Gateway Plug-in and uses it to impersonate the Access Gateway. As a result, the user unknowingly sends authentication credentials to the attacker, who could then connect to the Access Gateway. A certificate that is signed by a Certificate Authority works to prevent such attacks. If the certificate installed on the Access Gateway is not signed by a Certificate Authority, Access Gateway Plug-in users see a security alert when attempting to log on. Access Gateway Plug-in users see security warnings unless you install a certificate that is signed by a Certificate Authority on the Access Gateway and a corresponding certificate on users computers. Users can also disable the Security Alert through the Secure Access Connection Properties dialog box. Using Windows Certificates The Access Gateway includes the Certificate Request Generator to automatically create a certificate request. After the file is returned from the Certificate Authority, it can be uploaded to the Access Gateway. When the file is uploaded, it is converted automatically to the correct format for use. If you do not want to use the Certificate Request Generator to create the signed certificate, Citrix recommends using Win32 OpenSSL to administer any certificate tasks. To find out more about Win32 OpenSSL, visit the OpenSSL Web site at Binaries for Win32 OpenSSL can be downloaded from

194 194 Citrix Access Gateway Standard Edition Administrator s Guide If you are familiar with certificate manipulation, you can use other tools to create a PEM-formatted file. The certificate that you upload to the Access Gateway must have the following characteristics: It must be in PEM format and must include a private key. The signed certificate and private key must be unencrypted. An encrypted private key can be used if there is a password to decrypt it. Unencrypting the Private Key Follow this procedure only if the method you use to generate the private key results in an encrypted key. To unencrypt the private key 1. At the $ prompt, enter the command: openssl rsa If you enter this command without arguments, you are prompted as follows: read RSA key 2. Enter the name of the password to be encrypted. You can enter the openssl rsa command with arguments if you know the name of the private key and the unencrypted PEM file. For example, if the private key file name is my_keytag_key.pvk and the unencrypted file name is keyout.pem, enter openssl rsa -in my_keytag_key.pvk -out keyout.pem. For more information, see the Open SSL Web site at docs/apps/rsa.html#examples. For information about downloading OpenSSL for Windows, see the SourceForge Web site at showfiles.php?group_id=23617&release_id= Converting to a PEM-Formatted Certificate The signed certificate file that you receive from the Certificate Authority might not be in a PEM format. If the file is in binary format (DER), convert it to PEM format as follows: openssl x509 -in certfile -inform DER -outform PEM -out convertedcertfile If the certificate is already in a text format, it may be in PKCS format. You will receive a PKCS formatted certificate if you specified that the certificate will be used with a Microsoft rather than Apache operating system. The following command results in an error message if the certificate is not in PEM format. The certfile should not contain the private key when you run this command.

195 Appendix B Securing Connections with Digital Certificates 195 openssl verify -verbose -CApath /tmp certfile If that command results in the following error message, the file is not in PEM format. certfile: unable to load certificate file 4840:error:0906D064:PEM routines:pem_read_bio:bad base64 decode:pem_lib.c:781: To convert the certificate from PKCS7 to PEM format 1. Run the command: openssl pkcs7 -in./certfile -print_certs The output will look like this: subject= BEGIN CERTIFICATE Server Certificate END CERTIFICATE----- subject= BEGIN CERTIFICATE Intermediate Cert END CERTIFICATE Combine the server certificate data and the intermediate certificate data (if it exists) from the output with the private key as specified in Combining the Private Key with the Signed Certificate on page 195 and Generating Trusted Certificates for Multiple Levels on page 196. Combining the Private Key with the Signed Certificate You must combine the signed certificate with the private key before you can upload it to the Access Gateway. To combine the private key with the signed certificate 1. Use a text editor to combine the unencrypted private key with the signed certificate in the PEM file format. The file contents should look similar to the following: -----BEGIN RSA PRIVATE KEY----- <Unencrypted Private Key> -----END RSA Private KEY BEGIN CERTIFICATE-----

196 196 Citrix Access Gateway Standard Edition Administrator s Guide <Signed Certificate> -----END CERTIFICATE Save and name the PEM file; for example, AccessGateway.pem. Generating Trusted Certificates for Multiple Levels You must determine whether or not your certificate has more than one level and, if it does, handle the intermediate certificates properly. Caution: Any certificate for the Access Gateway that has more than one level must include all intermediate certificates or the system may become unusable. To generate trusted root certificates for multiple levels 1. Open Internet Explorer and access a Web page through the Access Gateway. For example, enter an address similar to the following: where: ipaddress is the IP address of your Access Gateway httpport is the Access Gateway port number 2. Double-click the Lock symbol in the bottom right corner of the browser. 3. Switch to the Certificate Path window pane at the top of the screen. 4. Double-click the first path level to bring up the certificate information for the first level and then go to the Details screen. 5. Click the Copy to File button at the bottom. 6. After the Certificate Export wizard appears, click Next. 7. Click the format Base-64 encoded and then click Next. 8. Enter a file name; for example, G:\tmp\servercert.cer. Review the information and note the complete file name. Click Finish. 9. Click OK to close the Certificate Information window for the first level. 10. Repeat Steps 4 10 for all levels except the last level. 11. Insert all certificates in one file and make sure that any intermediate certificates are part of any certificate file you upload. The file to be uploaded should be in the following format:

197 Appendix B Securing Connections with Digital Certificates 197 private key Server Certificate Intermediate Certificate 0 Intermediate Certificate 1 Intermediate Certificate 2 Requiring Certificates for Internal Connections To increase security for internal connections originating from the Access Gateway, you can require the Access Gateway to validate SSL server certificates. Validating SSL server certificates is an important security measure because it can help prevent security breaches, such as man-in-the-middle attacks. This setting determines if SSL server certificates are validated for connections initiated from the Access Gateway to the internal network. This validates SSL server certificates presented by the Web Interface and the Secure Ticket Authority. Requiring validation of the SSL server certificates increases security for the connections between the Access Gateway and servers running Access Gateway Advanced Edition. These connections are security-sensitive because they are used to configure the Access Gateway and grant or deny access to network resources using session policies. The Access Gateway requires installing the proper root certificates that are used to sign the server certificates. For more information about root certificates, see Installing Root Certificates on the Access Gateway on page 50. To require server certificates for internal client connections On the Global Cluster Policies tab, under Select security options, select Validate secure certificates for internal connections. Using Wildcard Certificates The Access Gateway supports validation of wildcard certificates for Access Gateway Plug-in. The wildcard certificate has an asterisk (*) in the certificate name. Wildcard certificates can be formatted in one of two ways, such as *.mycompany.com or www*.mycompany.com. When a wildcard certificate is used, users can choose different Web addresses, such as www1.mycompany.com or The use of a wildcard certificate allows several Web sites to be covered by a single certificate.

198 198 Citrix Access Gateway Standard Edition Administrator s Guide

199 APPENDIX C Examples of Configuring Network Access After the Access Gateway is installed and configured to operate in your network environment, use the Administration Tool to configure user access to the servers, applications, and other resources on the internal network. Configuring user access to internal network resources involves defining accessible networks for split tunneling, configuring authentication and authorization, creating user groups, creating local users, and defining the access control lists (ACLs) for user groups. Note: An ACL is a set of policies that determines the level of access that users have to the network resources. The Access Gateway supports several different authentication and authorization types that can be configured in a variety of combinations and used with policies to control user access to the internal network. Because of the number of options and possibilities involved with configuring user access to the internal network, this aspect of Access Gateway configuration is covered in four different sections of this book: This appendix provides example user access scenarios and includes stepby-step instructions for configuring the Access Gateway to support the access scenarios. These scenarios are intended as tutorials to help you understand how to use the features of the Administration Tool to configure user access, and are not examples of real-world configurations. After you read these examples and understand the basics of configuring user access, use the information provided in the chapters listed below to

200 200 Citrix Access Gateway Standard Edition Administrator s Guide configure user access to the Access Gateway in your production environment: Chapter 6, Configuring Authentication and Authorization. This chapter discusses the different authentication and authorization options and how to configure them. Chapter 7, Configuring Network Access and Group Resources. This chapter discusses how to work with user groups, network resources, and various policies to define access control lists (ACLs) on the Access Gateway. Chapter 8, Configuring User Connections for Citrix Access Gateway Plug-in. This chapter discusses client connectivity to the Access Gateway. Configuration Examples Before reading the examples in this chapter, you should become familiar with the settings on three tabs of the Administration Tool. The settings on these tabs control user access to internal network resources: Global Cluster Policies Authentication Access Policy Manager The user access configuration examples discussed in this chapter are listed below. Scenario for configuring LDAP authentication and authorization. This stepby-step example illustrates how an administrator might provide access to internal network resources in an LDAP environment. Scenario for creating guest accounts using the Local Users list. This example extends the scenario for configuring LDAP authentication and authorization to illustrate the concept of local users. Scenario for configuring local authorization. This example illustrates the concept of local authorization by slightly altering the configuration discussed in the scenario for creating guest accounts using the Local Users list.

201 Appendix C Examples of Configuring Network Access 201 Scenario for Configuring LDAP Authentication and Authorization This example shows how an administrator might use the settings in the Administration Tool to configure user access in the following example scenario: The organization uses a single LDAP directory as the user repository Remote users working for the Sales department must have access to an server, a Web conference server, a Sales Web application, and several file servers residing on the internal network Remote users working for the Engineering department must have access to an server, a Web conference server, and several file servers residing on the internal network Three servers are operating in the internal network, but the administrator wants remote users to access only one of these servers To configure access to the internal network resources in this scenario, the administrator completes two basic tasks: Preparing for the LDAP authentication and authorization configuration Configuring the Access Gateway to support access to the internal network resources Each of these tasks is discussed below. Preparing for the LDAP Authentication and Authorization Configuration Preparing for the LDAP authentication and authorization configuration is the first of two tasks the administrator performs in the scenario for configuring LDAP authentication and authorization. In this task, the administrator assembles the information needed to configure the Access Gateway to support LDAP authentication and authorization. This task includes these procedures: Determining the internal networks that include the needed resources Determining the Sales and Engineering users who need remote access Collecting the LDAP directory information

202 202 Citrix Access Gateway Standard Edition Administrator s Guide Determining the Internal Networks that Include the Needed Resources Determining the internal networks that include the needed resources is the first of three procedures the administrator performs to prepare for the LDAP authentication and authorization configuration. In this procedure, the administrator determines the network locations of the resources that the remote users must access. As noted earlier: Remote users working for the Sales department must have access to an server, a Web conference server, a Sales Web application, and several file servers residing on the internal network Remote users working for the Engineering department must have access to an server, a Web conference server, and several file servers residing on the internal network Three servers are operating in the internal network, but the administrator wants remote users to access only one of these servers To complete this procedure in this example, we assume the administrator collects the following information: The Web conference server, servers, and file servers that the remote Sales and Engineering users must access all reside in the network / 24 The server containing the Sales Web application resides in the network /24 The single server that remote users must access has the IP address Determining the Sales and Engineering Users Who Need Remote Access Determining the Sales and Engineering users who need remote access is the second of three procedures the administrator performs to prepare for LDAP authentication and authorization configuration. Before an administrator can configure the Access Gateway to support authorization with an LDAP directory, the administrator must understand how the Access Gateway uses groups to perform the authorization process. Specifically, the administrator must understand the relationship between a user s group membership in the LDAP directory and a user s group membership on the Access Gateway.

203 Appendix C Examples of Configuring Network Access 203 Note: The Access Gateway also relies on user groups in a similar way to support authorization types such as RADIUS. When a user in an LDAP directory connects to the Access Gateway, the following basic authentication and authorization sequence occurs: After a user enters authentication credentials from the LDAP directory, the Access Gateway looks the user up in the LDAP directory, verifies the user s credentials, and logs the user on. After a user successfully authenticates, the Access Gateway examines an attribute in the user s LDAP directory Person entry to determine the LDAP directory groups to which the user belongs. For example, if the Access Gateway operates with the Microsoft Active Directory, the Access Gateway checks the memberof attribute in the Person entry to determine the groups to which a user belongs. In this example, we assume that the group membership attribute indicates that a user is a member of an LDAP directory group named Remote Sales. The Access Gateway then looks for a user group configured on the Access Policy Manager tab of the Administration Tool that has a name that matches the name of an LDAP directory group to which the user belongs. In this example, the Access Gateway looks for a user group named Remote Sales configured on the Access Gateway. If the Access Gateway finds a user group configured on the Access Gateway that has the same name as an LDAP directory group to which the user belongs, the Access Gateway grants the user with the access privileges (authorization) assigned to the user group on the Access Gateway. In this example, the Access Gateway provides the user with the access levels associated with the Remote Sales user group on the Access Policy Manager tab of the Administration Tool. Therefore, before the administrator can authorize the Sales and Engineering users to access internal network resources through the Access Gateway, the administrator must know the LDAP directory groups to which these users belong.

204 204 Citrix Access Gateway Standard Edition Administrator s Guide At this point in this user access scenario, the administrator must accomplish one of two things regarding the group membership of the users: Identify groups on the LDAP directory that contain all of the members who need remote access to the internal networks If there are no existing groups that contain all of the appropriate members, the administrator can create new groups in the LDAP directory and add the appropriate members to these groups In this example, we assume that the administrator creates groups named Remote Sales and Remote Engineers in the LDAP directory and populates these groups with the Sales and Engineering users that need remote access to the internal network resources. Collecting the LDAP Directory Information Collecting the LDAP directory information is the last of three procedures the administrator performs to prepare for the LDAP authentication and authorization configuration. In this example scenario, the organization uses a single LDAP directory as its user repository. Before the administrator can configure the Access Gateway to support authentication and authorization with an LDAP directory, the administrator must collect information about the LDAP directory. This information is used in a later procedure to configure the Access Gateway to connect to the LDAP directory to perform user and group name lookups. Note: To determine the information needed to configure a particular authentication or authorization type, consult the Access Gateway Standard Edition Pre-Installation Checklist, or click the Authentication tab in the Administration Tool and create a test authentication realm that includes the authentication and authorization types that you must support. Collect the information needed to complete the fields for the selected authentication and authorization types. In this procedure, the administrator collects the following information about the LDAP directory. LDAP Server IP address. The IP address of the computer running the LDAP server. LDAP Server port. The port on which the LDAP server listens for connections. The default port for LDAP connections is port 389.

205 Appendix C Examples of Configuring Network Access 205 LDAP Administrator Bind DN and LDAP Administrator Password. If the LDAP directory requires applications to authenticate when accessing it, the administrator must know the name of the user account that the Access Gateway should use for this authentication and the password associated with this account. LDAP Base DN. The base object of the directory (or level of the directory) where user names are stored. All remote users must have a Person entry at this level of the directory. Some example values are: ou=users,dc=ace,dc=com cn=users,dc=ace,dc=com LDAP Server login name attribute. The attribute of an LDAP directory Person entry that contains a user s name. The following table contains examples of the user name attribute fields for different LDAP directories: LDAP Server User Attribute Case Sensitive Microsoft Active Directory Server samaccountname No Novell edirectory cn Yes IBM Directory Server uid Lotus Domino CN Sun ONE directory (formerly iplanet) uid or cn Yes LDAP Group attribute - The attribute of a user s Person entry that lists the groups to which a user belongs; for example, memberof. The LDAP Group attribute is used only for LDAP authorization. At this point, the administrator has completed all of the procedures needed to prepare for the LDAP authentication and authorization configuration task. When this task is complete, the administrator has the following information: The specific network locations of all network resources that the remote Sales and Engineering users must access The names of the user groups in the LDAP directory that contain the Sales and Engineering users who require remote access ( Remote Sales and Remote Engineers in this example) The specific LDAP directory information needed to configure the Access Gateway to operate with the LDAP directory With this information available, the administrator is now ready to configure the Access Gateway to provide access to the internal network resources for the Sales and Engineering users.

206 206 Citrix Access Gateway Standard Edition Administrator s Guide Configuring the Access Gateway to Support Access to the Internal Network Resources Configuring the Access Gateway to support access to the internal network resources is the last of two tasks the administrator performs in the scenario for configuring LDAP authentication and authorization. In this task, the administrator uses the information gathered in the previous task to configure the settings in the Administration Tool that enable the remote users to access the internal network resources. This task includes these five procedures: Configuring accessible networks Creating an LDAP authentication realm Creating the appropriate groups on the Access Gateway Creating and assigning network resources to the user groups Creating an application policy for the server Each of these procedures is discussed in detail below. Configuring Accessible Networks Configuring accessible networks is the first of five procedures the administrator performs to configure access to the internal network resources in the configuring LDAP authentication and authorization scenario. In this procedure, the administrator specifies the internal networks that contain the network resources that users must access using the Access Gateway Plug-in. In the previous task, the administrator determined that the remote Sales and Engineering users must have access to the resources on these specific internal networks: The Web conference server, file servers, and server residing in the network /24 The server containing the Sales Web application residing in the network /24 The administrator specifies these networks as accessible networks. Specifying the accessible networks enables the Access Gateway Plug-in to support split tunneling.

207 Appendix C Examples of Configuring Network Access 207 When a user logs on to the Access Gateway, the Access Gateway sends this list of networks to the Access Gateway Plug-in on the user s computer. The Access Gateway Plug-in uses this list of networks as a filter to determine which outbound packets should be sent to the Access Gateway and which should be sent elsewhere. The Access Gateway Plug-in transmits only the packets bound for the Access Gateway through the secure tunnel to the Access Gateway. Note: If you do not want to support split tunneling, you do not need to configure accessible networks. To configure accessible networks 1. Open the Administration Tool. 2. Click the Global Cluster Policies tab. 3. If necessary, under Access options, select Enable split tunneling. 4. In the Accessible networks box, enter all of the internal networks that the Access Gateway must access. Separate each network entered with a space or a carriage return. In this example access scenario, the administrator would make these entries: / /24 5. Under Advanced options, select Enable logon page authentication. This setting requires users to authenticate when accessing t the Access Gateway with a Web browser. To simplify this example, assume the administrator clears all other check boxes that appear on the Global Cluster Policies tab. For more information about split tunneling, see Enabling Split Tunneling and Accessible Networks on page 95. For more information about the Deny Access without ACL setting, see Access Control Lists on page 92. Creating an LDAP Authentication and Authorization Realm Creating an LDAP authentication and authorization realm is the second of five procedures the administrator performs to configure access to the internal network resources in this scenario. In this scenario, all of the Sales and Engineering users are listed in the LDAP directory. To authenticate users listed in an LDAP directory, the administrator must create an authentication realm that supports LDAP authentication.

208 208 Citrix Access Gateway Standard Edition Administrator s Guide To authorize users listed in LDAP directory groups to access the internal network resources, the administrator selects LDAP Authorization as the authorization type of the realm. Because all of the users authenticate to the LDAP directory, the administrator sets up the Default authentication realm to support LDAP authentication and authorization. To set up the Default realm to support LDAP authentication, the administrator first deletes the existing Default realm and then immediately creates a new Default realm that supports LDAP authentication. This new realm includes the address, port, and other LDAP directory information that the Access Gateway needs to connect to the LDAP directory server and resolve searches for names in the directory. Note: The existing Default realm on the Access Gateway is configured for local authentication. By deleting the existing Default realm and creating a new Default realm for LDAP, the administrator simplifies the logon process for the end user. Users who authenticate using the Default realm do not need to enter the realm name as part of their logon credentials. For more information about realms, authentication, and authorization, see Configuring Authentication and Authorization on page 61. To complete this procedure, the administrator must have available the LDAP directory information gathered in the Collect the LDAP Directory Information procedure in the previous task. To delete the existing Default realm and create a new Default realm that supports LDAP authentication and authorization 1. In the Access Gateway Administration Tool, click the Authentication tab. 2. Open the window for the Default realm. 3. On the Action menu, select Remove Default realm. A warning message appears. 4. Click Yes. 5. In Realm name, type Default. 6. Select One Source and click Add. 7. At Select Authentication Type, select LDAP authentication and then click OK. The new Default realm window opens.

209 Appendix C Examples of Configuring Network Access On the Authentication tab of the new Default realm window, complete the fields that enable the Access Gateway to access the LDAP server. (Use the information gathered in the Collecting the LDAP Directory Information procedure in the previous task to complete these fields). 9. Select the Authorization tab. 10. In Authorization type, select LDAP authorization. 11. On the Authorization tab, complete the fields that enable the Access Gateway to access the LDAP server. 12. Click Submit. For more information about creating realms, see Configuring the Default Realm on page 64. Creating the Appropriate Groups on the Access Gateway Creating the appropriate groups on the Access Gateway is the third of five procedures the administrator performs to configure access to the internal network resources in the configuring LDAP authentication and authorization scenario. In this step, the administrator creates user groups on the Access Gateway that have names that match the groups the administrator identified or created in the LDAP directory. In an earlier task, the administrator created LDAP directory groups named Remote Sales and Remote Engineers in the LDAP directory. In this step, the administrator must now create user groups named Remote Sales and Remote Engineers on the Access Gateway. To create user groups on the Access Gateway 1. Click the Access Policy Manager tab. 2. In the left pane, right-click User Groups and then click New Group. In Group Name, type a name that is an exact case-sensitive match to an LDAP directory group that was identified or created in the earlier procedure. For example, type Remote Sales and then click OK. 3. At this point, a Group Properties window appears that includes several tabs. To simplify this example, accept all of the default settings for the Group Properties and click OK.

210 210 Citrix Access Gateway Standard Edition Administrator s Guide The group properties provide additional settings that affect user access. For more information, about group properties and creating local groups, see Configuring User Groups on page 97. Creating and Assigning Network Resources to the User Groups Creating and assigning network resources to the user groups is the fourth of five procedures the administrator performs to configure access to the internal network resources in the configuring LDAP authentication and authorization scenario. In this step, the administrator specifies the network resources (network segments or individual computers) that users can access and then assigns those resources to the user groups on the Access Gateway. To complete this step, the administrator does the following: Creates a network resource named Sales Resource and assigns this resource to the Remote Sales user group Creates a network resource named Engineering Resource and assigns this resource to the Remote Engineers user group Creating and Assigning Network Resources to the Sales Users This section briefly discusses how the administrator creates a network resource for the Sales users and assigns it to those users. As noted earlier, the Sales users need access to these systems: An server, Web conference server, and several file servers in the /24 network. A Sales Web application in the /24 network. To create a network resource named Sales Resource for the Sales users 1. Click the Access Policy Manager tab. 2. In the right pane, right-click Network Resources and then click New Network Resource. 3. Type Sales Resources as the Network Resource Name, and click OK. 4. In Network/Subnet, type these two IP address/subnet pairs for the resources. Separate each of these IP address/subnet pairs with a space: / /24 5. To simplify this example, the administrator accepts the default values for the other settings on the Network Resource window and clicks OK.

211 Appendix C Examples of Configuring Network Access 211 After creating the Network Resource named Sales Resource, the administrator uses the procedure below to add this network resource to the ACL of the Remote Sales user group. 1. In the Access Gateway Administration Tool, click the Access Policy Manager tab. 2. In the left-pane, expand User Groups, and then expand the Remote Sales user group. 3. In the right pane, expand Network Resources. 4. Click the Sales Resource network resource and drag it to Network Policies beneath the Remote Sales user group in the left-hand pane. With this action, the administrator grants the users associated with the Remote Sales user group access to the systems defined in the network resource named Sales Resources. Note: In the procedure above, the administrator assigned the Sales Resource network resource to the access control list (ACL) of the Remote Sales user group. The administrator creates ACLs on the Access Gateway by adding resources to the network policies, application policies, and endpoint policies associated with the user group. The ACL is comprised of all policies that are assigned to a user group on the Access Gateway. Creating and Assigning Network Resources to the Engineering Users This section briefly discusses how the administrator creates a network resource and assigns it to the Engineering users. This procedure is essentially the same as the procedure completed for the Sales users in the previous step, except the administrator does not provide the engineering users with access to the Sales Web application in the /24 network. As noted earlier, the Engineering users need access to a Web conference server, an server, and several file servers. All of these servers reside in the network /24. To provide the Engineering users with access to the network: 1. From the right pane of the Access Policy Manager tab in the Access Gateway Administration Tool, create a new network resource named Engineering Resources. Specify only the /24 network when creating this resource. 2. In the left pane, expand the Remote Engineers user group.

212 212 Citrix Access Gateway Standard Edition Administrator s Guide 3. Drag the Engineering Resources network resource from the right pane of the Access Policy Manager tab to the Network Policies of the Remote Engineers group in the left pane. The Engineering Resources Network Resource is now part of the ACL for the Remote Engineers group. Note: In more complex environments, it may be necessary to restrict access to a particular segment of a larger network. For example, an administrator may need to deny access to the x network while allowing access to everything else in the 10.0.x.x network. The administrator creates a network resource for the x network and a network resource for the 10.0.x.x network and assigns both network resources to the user group. The administrator then right-clicks each of the resources to deny access to the x resource and allow access to the 10.0.x.x resource. In these cases, configure the policy denying access to x first and then configure the policy allowing access to the 10.0.x.x network second. Always configure the most restrictive policy first and the least restrictive policy last. Creating an Application Policy for an Server Creating an application policy for an server is the last of five procedures the administrator performs to configure access to the internal network resources in the configuring LDAP authentication and authorization scenario. In this example, the network /24 contains three servers, but the administrator wants the remote Sales and Engineering users to have access to only one of these servers. The server that remote users must access has the IP address /32. To enable users to access only a single server, the administrator creates an application policy on the Access Gateway that enables the users to access only the application on the /32 server. Note: An administrator uses application policies to require a client application to access a specific internal server or to require a client device to meet specific requirements before it is allowed to access an internal server. To create an application policy to restrict access to one server, the administrator must perform three actions: Create a network resource that includes only the server

213 Appendix C Examples of Configuring Network Access 213 Create an application policy that specifies the application on the server and assign the network resource containing the server to this application policy Assign the application policy to the user groups in the Access Gateway In this example, the administrator creates a network resource named Server that includes only IP address /32 (the server). The administrator then creates an application policy named Application Policy that specifies the application that remote users can access. The administrator assigns the Server network resource to this application policy. Next, the administrator adds the Application Policy to the Remote Sales and Remote Engineers groups. Adding the policy to those groups ensures that those groups always access the application on the specific server specified by the administrator in the application policy. To implement the application policy for the server 1. In the right pane of the Access Policy Manager tab in the Access Gateway Administration Tool, create a new network resource named server. For this Network Resource, specify only the IP address of the server that users are allowed to access (for example, /32). This is the same basic procedure that was used to define the network resources for the Sales users and Engineering users in the previous procedures. 2. In the right pane, right-click Application Policies and then click New Application Policy. 3. In Application Resource Name, type Application Policy and click OK. 4. Browse to and select the application located on the server that has the IP address /32. The MD5 field is populated automatically with the binary sum of the application. 5. In the left pane, click the server network resource you just created and drag it to Application network policies listed under Application policies in the right pane and click OK. 6. In the left pane, expand both the Remote Sales user group and the Remote Engineers user group. 7. In the right pane, under Application Policies, click the Application Policy and drag it to Application Policies under the Remote Sales user group in the left pane, so that the Application Policy is part of the Remote Sales ACL.

214 214 Citrix Access Gateway Standard Edition Administrator s Guide 8. In the right pane, under Application Policies, click the Application Policy and drag it to Application Policies under the Remote Engineers user group in the left pane, so that the Application Policy is part of the Remote Engineers ACL. Note: In the procedure above, the administrator could also add an application endpoint policy to the application policy to require every client device to meet specific requirements when accessing the server. For more information, see Setting Application Policies on page 105. This procedure concludes the scenario for configuring LDAP authentication and authorization. When this procedure is complete, the administrator has configured all of the following: Users can authenticate to the LDAP directory specified in the Default authentication realm using their LDAP directory credentials. Users are authorized to access the internal network resources based on their group memberships in the LDAP directory and on the Access Gateway. Only users who are members of the Remote Sales group and the Remote Engineers group are authorized to access resources on the internal network. (Each of these groups must exist both in the LDAP directory and on the Access Gateway.) Users in the Remote Sales group are authorized to access the Web conference server and file servers in the /24 network and the Sales Web application in the /24 network. The Sales users can access the application on the server with the IP address, but cannot access the application on other servers in the allowed networks. The Sales users can also access other network resources located in the two allowed networks. Users in the Remote Engineering group can access the Web conference server and the file servers in the /24 network (and other network resources located in this network). The Engineering users can also access the application on the server with the IP address, but cannot access the application on other servers in the allowed networks. To understand the purpose of local users on the Access Gateway and to understand how to enable authentication and authorization for the local users, continue to the Scenario for Creating Guest Accounts Using the Local Users List on page 215.

215 Appendix C Examples of Configuring Network Access 215 Scenario for Creating Guest Accounts Using the Local Users List This example illustrates how local users work on the Access Gateway and shows one way in which an administrator can support authentication and authorization for the local users. In the previous example, users were authenticated and authorized based on their LDAP directory credentials and group memberships. An administrator can also create a list of local users on the Access Gateway and configure the Access Gateway to provide authentication and authorization services for these users. This list of local users is maintained in a database on the Access Gateway and not in an external directory. Local users are especially useful if the administrator wants to do any of the following: Grant access to users who are not listed in any directory for authentication Grant access to users who are listed in a directory to which the Access Gateway does not connect Provide a small number of users with a special level of access to the internal network resources without creating a new group in the directory for these users This example assumes the following: Silvio Branco and Lisa Marth are consultants that do not work for the corporation and are not listed in any directory for authentication Silvio Branco and Lisa Marth must have remote access to the Web conference server on the internal network to participate in conferences with the Sales and Engineering users who are employed by the organization The administrator has already completed the previous LDAP authentication with LDAP authorization example scenario earlier in this chapter to provide Sales and Engineering users with access to the Web conference server The Web conference server IP address is Note: In this example, Silvio Branco and Lisa Marth are referred to as guest users because they are not employed by the corporation and are not listed in any directory for authentication.

216 216 Citrix Access Gateway Standard Edition Administrator s Guide To provide Silvio Branco and Lisa Marth with access to the Web conference server, the administrator performs these three procedures: Creates a guest user authentication realm Creates local users Creates and assigns a network resource to the Default user group on the Access Gateway Creating a Guest User Authentication Realm Creating a guest user authentication realm is the first of three procedures the administrator performs in the scenario for creating guest accounts using the Local Users list. In the previous scenario for configuring LDAP authentication and authorization, the administrator created a Default authentication realm to support authentication and authorization of the users listed in the LDAP directory. Because Silvio Branco and Lisa Marth are not listed in the LDAP directory, the administrator creates a separate authentication realm for them that supports the following: Local Authentication. This option in an authentication realm ensures that users are authenticated against a Local Users list on the Access Gateway, and not an external directory No Authorization. This option in an authentication realm ensures that users of this realm are provided with the access levels associated with the Default user group on the Access Gateway. To create a guest authentication realm for the guest users 1. In the Access Gateway Administration Tool, click the Authentication tab. 2. In Realm Name, type Guest. 3. Select One Source and click Add. 4. At Select Authentication Type, in Authentication type, select Local authentication only and then click OK. 5. In the Authorization tab, select No authorization. 6. Click Submit. Note: If the guest realm is not the Default realm, users need to log on using the realm name, such as Guest/user name.

217 Appendix C Examples of Configuring Network Access 217 Creating Local Users Creating local users is the second of three procedures the administrator performs in the scenario for creating guest accounts using the Local Users list. In this procedure, the administrator creates local user accounts for Silvio Branco and Lisa Marth on the Access Gateway and provides each user with a password. To add the local users 1. Click the Access Policy Manager tab. 2. Right-click Local Users and select New User. 3. In User Name, type Lisa Marth. 4. In the Password and Verify Password fields, enter a password for Lisa Marth and click OK. 5. Repeat Steps 2 through 4 for to create a local user account for Silvio Branco. Creating and Assigning a Network Resource to the Default User Group Creating and assigning a network resource to the Default user group is the last of three procedures in the scenario for creating guest accounts using the Local Users list. In this step, the administrator creates a network resource that specifies only the Web conference server and then assigns this resource to the Default user group. 1. In the right pane of the Access Policy Manager tab in the Administration Tool, create a new network resource named Guest Resource. Specify only the IP address of the Web conference server when creating this network resource (for example /32). 2. In the left pane, expand the Default user group. 3. Drag the Guest Resource network resource from the right pane of the Access Policy Manager tab to the Network Policies of the Default group in the left pane. Note: If a user logs on and cannot get group information, the user will always use the Default group settings. When this procedure is complete, the administrator has accomplished the following:

218 218 Citrix Access Gateway Standard Edition Administrator s Guide Silvio Branco and Lisa Marth can enter the user credential Guest\Silvio Branco or Guest\Lisa Marth to authenticate to the Guest realm on the Access Gateway. Silvio and Lisa must include the realm name as part of their user name credential when authenticating because they authenticate to a realm that is not the Default authentication realm. Silvio and Lisa also use the passwords that the administrator specified for them to authenticate to the Access Gateway. The administrator entered these passwords when creating Silvio and Lisa as local users on the Access Gateway. Silvio and Lisa are authorized to access any resource defined in the ACL of the Default user group because No Authorization is specified as the authorization type of the Guest realm. In this example, Silvio and Lisa can access only the Web conference server on the internal network because that is the only network resource defined for the Default user group. Scenario for Configuring Local Authorization for Local Users By slightly altering the configuration discussed previously in the Scenario for Creating Guest Accounts Using the Local Users List, the administrator can provide local users (Lisa Marth and Silvio Branco) with the same level of access to the internal network resources as either the Sales or the Engineering users. This scenario illustrates the concept of local authorization for local users. Assume the administrator wants to provide Lisa and Silvio with the same level of access as the Engineering users. To accomplish this, the administrator could perform two procedures: Change the authorization type of the Guest realm to Local Authorization Assign the local users Lisa Marth and Silvio Branco to the Remote Engineers group on the Access Gateway To assign local users Lisa Marth and Silvio Branco to the Remote Engineers group on the Access Gateway, the administrator performs this procedure: 1. Click the Access Policy Manager tab. 2. Expand User Groups and then expand Local Users. 3. Under Local Users, click the name Lisa Marth and drag her name to Local Group Users underneath the Remote Engineers user group.

219 Appendix C Examples of Configuring Network Access Under Local Users, click the name Silvio Branco and drag his name to Local Group Users underneath the Remote Engineers user group. When this procedure is complete, both of the following are true: Silvio Branco and Lisa Marth can enter the user credential Guest\Silvio Branco or Guest\Lisa Marth to authenticate to the Guest realm on the Access Gateway. Silvio and Lisa are authorized to access any resource defined in the ACL of the Remote Engineers user group because Local Authorization is specified as the authorization type of the Guest realm. When Local Authorization is specified, local users receive the authorization associated with the user group on the Access Gateway to which they are assigned. They do not receive the authorization associated with the Default user group on the Access Gateway, as is the case when No Authorization is selected for the Guest authentication realm.

220 220 Citrix Access Gateway Standard Edition Administrator s Guide

221 APPENDIX D Troubleshooting the Access Gateway The following information explains how to deal with problems you might encounter when setting up and using the Access Gateway. Troubleshooting Web Interface Connections This section describes issues you might have with connecting to the Web Interface. Web Interface Appears without Typing Credentials If you typed the Web address for the Access Gateway, the Web Interface appears without asking for the user name and password. The problem is that you have portal page authentication disabled. In the Administration Tool, on the Global Cluster Policies tab, under Advanced options, select Enable logon page authentication. If this is disabled, unauthenticated network traffic is sent to the Web Interface. This is a valid configuration; however, make sure the Web Interface is located in the DMZ. Applications do not Appear after Logging On When users log on to the Access Gateway, they cannot see their applications. The Message Center states that a domain was not specified. By default, the Access Gateway passes only the user name and password to the Web Interface. To correct this, in the Access Management Console, configure a default domain or a list of domains to which users can log on. The Web Interface uses the first one in the list as the default domain. When users log on to the Access Gateway, they are sent to the Web Interface but their applications are not displayed. The Message Center states that the users credentials are invalid.

222 222 Citrix Access Gateway Standard Edition Administrator s Guide The most likely cause of this error message is that the users logged on to the Access Gateway with non-ldap credentials from a different domain from the one the Web Interface is set up to accept. To resolve this issue, make sure that the default domain on the server running the Web Interface is the same as the Default realm in the Access Gateway. In addition, make sure that the Access Gateway is configured to use LDAP authentication and that the LDAP server is a domain controller in the same domain as the Web Interface. Users could also log on using a realm in the Access Gateway but the realm name is not the same as the domain name. Realm names must match the corresponding Active Directory domain names. To allow users to log on with a realm name that is not the Default realm, type the realm name and user name, such as realm name\user name. When users log on to the Access Gateway, the realm name and user name are passed to the Web Interface. The Web Interface converts the realm name and user name to the domain name and user name. Users are Sent to a Logon Page that Asks to Start the Access Gateway Plug-in In the Default group, or highest priority group of the user logging on, the Use the multiple logon option page is selected on the Gateway Portal tab of the group properties. If you do not want to give the user access to the Access Gateway Plugin, do not select this check box. For more information, see Configuring a Portal Page with Multiple Logon Options on page 148. To disable the multiple options logon page 1. On the Access Policy Manager tab, right-click a group, and then select Properties. 2. On the Gateway Portal tab, clear Use the multiple logon option page and click OK. Other Issues This section describes known issues and solutions for the Access Gateway. License File Does not Match Access Gateway If you are trying to install a license file on the Access Gateway, you might receive the error message License file does not match any Access Gateway s. A license file is already installed on the Access Gateway. To upload a new license file, the old license needs to be removed.

223 Appendix D Troubleshooting the Access Gateway 223 To install a new license file on the Access Gateway 1. On the Access Gateway Cluster tab, open the window for the Access Gateway to which you want to add the license. 2. On the Licensing tab, next to Remove all license files, click Remove All. 3. Restart the Access Gateway. 4. On the Licensing tab, next to Install a license file, click Browse and navigate to the license file. 5. Click Open to install the file. 6. Restart the Access Gateway. Defining Accessible Networks Subnet Restriction In the Accessible networks field on the Global Cluster Policies tab, up to 24 subnets can be defined. If more than 24 subnets are entered, the Access Gateway ignores the additional subnets. Virtualization Software If a single user logs on to the Access Gateway from two computers that are running virtualization software, such as Xen, VMWare, or Hyper-V, and the virtualization software uses the same MAC address for both computers, the Access Gateway does not allow both instances of the client software to run simultaneously. The Access Gateway uses the MAC address to manage licenses and does not allow more than one user session at a time per MAC address. ICMP Transmissions The Access Gateway returns a Request timed out error message if an ICMP transmission fails for any reason. The Access Gateway always sends a standard ICMP packet to the remote destination host when a user tries to ping it. Any options such as increasing the size of the ICMP payload are not recognized by the Access Gateway and are not sent to the remote host. Ping Command The Access Gateway always sends out the same ping command, regardless of the options specified with the ping command from a client device. LDAP Authentication When the Access Gateway is configured to use LDAP authentication and authorization, the LDAP group information is not used to automatically populate the group field in the Administration Tool.

224 224 Citrix Access Gateway Standard Edition Administrator s Guide Endpoint Policies When the Access Gateway is evaluating the union of a group s endpoint policies, it does not consider the group priorities and, therefore, might not resolve conflicting policies correctly. The last policy appended in an expression is the policy that takes effect. For example, one group has policy ProcessA and another group has policy!processa. If the union of the policies is ProcessA and!processa, the!processa takes effect. Network Resources For added network resources, the Access Gateway does not recognize the CIDR notation address ipaddress/0. For example, to add a resource group that provides access to all resources, specify / instead of /0. Internal Failover If internal failover is enabled and the administrator is connected to the Access Gateway, the Administration Tool cannot be reached over the connection. To resolve this problem, enable IP pooling and then connect to the lowest IP address in the pool range on port For example, if the IP pool range starts at , connect to the Administration Tool using :9001. For information about configuring IP pools, see Enabling IP Pooling on page 133. Certificate Signing Several Citrix server components support SSL/TLS, such as the Access Gateway, Secure Gateway, and SSL Relay. All of these components support server certificates issued either by a public Certificate Authority (CA) or by a private Certificate Authority. Public CAs include organizations such as Verisign and Thawte. Private CAs are implemented by products such as Microsoft Certificate Services. Certificates signed by a private CA are sometimes described as enterprise certificates or self-signed certificates. In this context, the term self-signed certificate is not technically accurate; such certificates are signed by the private CA. True self-signed certificates are not signed by any CA and are not supported by Citrix server components, because there is no CA to provide a root of trust. However, as described above, certificates issued by a private CA are supported by Citrix server components because the private CA is the root of trust.

225 Appendix D Troubleshooting the Access Gateway 225 Certificate Revocation Lists Certificate Revocation Lists (CRLs) cannot be configured by the administrator. When a user connects to the Access Gateway using a client certificate, the Access Gateway uses the CRLDistributionPoints extension in the client certificate, if it is present, to locate relevant CRLs using HTTP. The client certificate is checked against those CRLs. Network Messages to Non-Existent IPs If an invalid sdconf.rec file is uploaded to the Access Gateway, this might cause the Access Gateway to send out messages to non-existent IPs. A network monitor might flag this activity as network spamming. To correct the problem, upload a valid sdconf.rec file to the Access Gateway. The Access Gateway Does not Start and the Serial Console Is Blank Verify that the following are correctly set up: The serial console is using the correct port and the physical and logical ports match The cable is a null-modem cable The COM settings in your serial communication software are set to 9600 bits per second, 8 data bits, no parity, and 1 stop bit The Administration Tool Is Inaccessible If the Access Gateway is offline, the Administration Tool is not available. You can use the Administration Portal to perform tasks such as viewing the system log and restarting the Access Gateway. Devices Cannot Communicate with the Access Gateway Verify that the following are correctly set up: The FQDN specified on the General Networking tab in the Access Gateway Administration Tool is available outside of your firewall Any changes made in the Access Gateway serial console or Administration Tool were submitted

226 226 Citrix Access Gateway Standard Edition Administrator s Guide Using Ctrl-Alt-Delete to Restart the Access Gateway Fails The restart function on the Access Gateway is disabled. You must use the Administration Tool to restart and shut down the device. SSL Version 2 Sessions and Multilevel Certificate Chains If intermediate (multilevel) certificates are part of your secure certificate upload, make sure that the intermediate certificates are part of the certificate file you are uploading. SSL Version 2 does not support certificate chaining. Any certificate that has more than one level must include all intermediate certificates or the system may become unusable. For information about how to add intermediate certificates to the uploaded certificate file, see Securing Connections with Digital Certificates on page 185. H.323 Protocol The Access Gateway does not support the H.323 protocol. Applications that use the H.323 protocol, such as Microsoft s NetMeeting, cannot be used with the Access Gateway. Certificates Using 512-Bit Keypairs When configuring certificates, do not use 512-bit keypairs. They are subject to brute force attacks. Unable to Restrict Drive Mapping with an Application Policy You cannot use an application policy to restrict a user activity such as drive mapping that is handled directly within the Windows operating system. You must use a group network policy to restrict this type of activity. For example, if you want to prevent users in the Default user group from using Windows Explorer to map to drives in the /24 subnet, you must create a group resource that specifies this subnet and assign it to the Default group. Then deny access to the network resource. You cannot restrict access by creating an application policy for Windows Explorer, embedding a network resource within the application policy, and then denying access to the network resource.

227 Appendix D Troubleshooting the Access Gateway 227 Citrix Access Gateway Plug-in The following are issues with Citrix Access Gateway Plug-in. Access Gateway Plug-in Connections with Windows XP If a user makes a connection to the Access Gateway using Windows XP, logs off the computer without first disconnecting the Access Gateway Plug-in, and then logs on again, the Internet connection is broken. To restore the Internet connection, restart the computer. DNS Name Resolution Using Named Service Providers If users without administrative privileges use Windows 2000 Professional or Windows XP to connect to the Access Gateway, DNS name resolution may fail if the client is using the Name Service Provider. To correct the problem, connect using the IP address of the computer instead of the DNS name. Auto-Update Feature The Access Gateway Plug-in auto-update feature does not work if the client is configured to connect through a proxy server. Client Connections from a Windows Server 2003 If a connection to the Access Gateway is made from a Windows Server 2003 computer that is its own DNS server, local and public DNS resolution does not work. To fix this issue, configure the Windows Server 2003 network settings to point to a different DNS server. NTLM Authentication The Access Gateway Plug-in does not support NTLM authentication to proxy servers. Only Basic authentication is supported for proxy servers. WINS Entries When the Access Gateway Plug-in is disconnected, WINS entries are not removed from the computer that is running the plug-in. Dial-up users do not receive WINS server assignments. To fix the problem, manually set the internal WINS address or use a Microsoft DNS server to set the domain to perform WINS lookups

228 228 Citrix Access Gateway Standard Edition Administrator s Guide Using Third-Party Client Software If a user s computer is running Access Gateway Plug-in, and also has a thirdparty VPN software application installed on the computer, and connections are not correctly crossing the Access Gateway, make sure the third-party application is disabled or turned off. When the third-party application is disabled or off, try the Access Gateway Plug-in connection again.

229 INDEX Index A access control list 101 allow and deny rules 104 deny access 97 deny access without ACL 95 in Access Gateway Plug-in properties 130 Access Gateway Administration Tools 151 connections 16 initializing 162 licensing, multiple appliances 43 maintenance 151 modes of operation 16 monitoring 182 reinstalling software 158 restarting 37, 161 shut down 162 statistics 181 upgrading 156 Access Gateway Advanced Edition 16, 26 client certificates 139 inactive server 27 Access Gateway Plug-in 16 access control list 130 auto-update feature 227 configuring a proxy server 121 connecting with earlier versions 125 connection log 179 force upgrade 126 installing 127 installing using Group Policy 122 IP pooling 133 Linux support 130 logging on 127, 148 MSI installation 122 MSI package 18 operation with proxy servers 121 prevent upgrade 126 prompt upgrade 126 proxy server setup 128 split DNS 134 status 164 system requirements 116 third-party VPN software 228 upgrading from earlier versions 125 using with firewalls 118 using with proxies 118 Windows 2003 Server 227 Windows XP 227 Access Gateway Plug-in for Linux 18, 130 accessible networks 95 configuration examples 206 limitations 223 ACL, see access control list Administration Desktop 17 18, 177 Administration Portal 153 Administration Tool 151 administrator password 154 available downloads 154 certificates, installing 48 disabling external access using the Administration

230 230 Citrix Access Gateway Standard Edition Administrator s Guide Tool 155 disabling external access using the serial console 32 logging 155 maintenance 155 port 21 Administration Tool backward compatiblity 18 downloading 154 inaccessible 225 installation 34, 152 internal failover 224 logging 155 multiple versions 153 port 21 administrator password 154 Administration Portal 154 serial console 32 advanced options authentication 89 application policies 99, 105 allow and deny 104 configuration example 212 unable to restrict drive mapping 226 archive of system log 178 asymmetric encryption 187 authentication 78 advanced options 89 certificates 188 configuring 62 default realm 64 disabling logon page 147 double-source 90 enabling logon page 143 enabling RSA SecurID 82 Gemalto Protiva 18, 86 LDAP 69, 117 LDAP configuration example 201, 207 local 67, 117 local users 68 network interruption 132 no authorization 64 NTLM 87, 117, 227 RADIUS 77, 117 realms 66 RSA SecurID 80, 117 SafeWord 84, 117 user group 97 authentication types 23 authorization 64 LDAP 69, 73 LDAP configuration example 201 local users 68 NTLM 88 RADIUS 77, 79 SafeWord 85 B Branch Repeater 113 C CAs. See Certificate Authorities Certificate Authorities 189 private 192 public 192 subordinate 189 Certificate Authority root certificate, obtaining 139 Certificate Revocation Lists 191, 225 Certificate Signing Request overview 46 certificates 22, 185, bit keypairs 226 authentication 188 certificate chains 189 certificate signing request 46 chain 189 client combining with private key 195 content 189 converting to PEM format 194 creating multiple root certificates using command

231 Index 231 prompt 51 expiration 191 generating for multiple levels 196 hierarchy 189 installation 46, 193 installing from a Windows computer 49 installing using Administration Portal 48 installing using Administration Tool 48 intermediate 190 LDAP connections 76 multilevel and SSL version private 192 private key password 47 private key, unencrypting 194 renewal 191 resetting to default certificate 48 revocation lists 191 root 50, 139, 189 root, installing on Windows 140 root, multiple 50 serial console, resetting default 32 server 189 setting 47 signing 224 subordinate 190 test 193 trial period 193 verification process 192 with Access Gateway Advanced Edition 139 chain certificates 189 ciphers description 186 Citrix Branch Repeater 113 Repeater Plug-in 113 Citrix education 13 Citrix Preferred Support Services 12 Citrix Presentation Server Clients, see Citrix XenApp Plug-ins Citrix Repeater Plug-in 113 Citrix Solutions Advisers 12 Citrix XenApp 16, 99 deployment 24 split tunneling 96 Citrix XenApp Plug-ins 16 Citrix XenDesktop 17 deployment 24 client access IP pooling 99 portal page 147 resource access control 104 session time-out 98 split DNS 98 client certificates 137 setting criteria 138 with Access Gateway Advanced Edition 139 client connection logs 179 clients root certificates 139 cluster creating 168 RSA SecurID 83 command prompt creating multiple root certificates 51 computer hibernate 132 suspend 132 configuration application policy 105 authentication without authorization 64 default gateway 35 endpoint policy 109 endpoint resource 107 local users 68 network resource 103 pre-authentication policies 112 resource groups 98 split tunneling 96 user groups 97, 99 configuration examples accessible networks 206 application policy 212 LDAP authentication realm 207 local authorization 218 local users 215 network access 200 providing group access 209 configuring for a group 109 connection log Access Gateway Plug-in 179

232 232 Citrix Access Gateway Standard Edition Administrator s Guide connections Access Gateway Advanced Edition 16 Access Gateway only 16 client cannot connect 225 hardware 31 LDAP certificates 76 simultaneous 16 single DMZ 21 using a Web address 126 Web Interface 16 CRLs, see Certificate Revocation Lists cross-over cables 29, 34 cryptography asymmetric encryption 187 public key 187 secret key 187 symmetric key 187 understanding 185 D date setting 57 default certificate resetting 48 default gateway configuring 35 default portal page 58 Default realm 64 deny access without access control list 95, 97 deployment Access Gateway Advanced Edition 26 authentication support 23 Citrix XenApp 24 Citrix XenDesktop 24 cluster 168 double-hop DMZ 24 failover 25, 175 load balancer 25, 171 multiple Access Gateway appliances 167 secure network 21 security considerations 22 single DMZ 20 Web Interface 24 deployment options 19 desktop sharing 18 directory attributes LDAP 76 DNS failover to local 51 in Access Gateway Plug-in window 130 name resolution 227 server settings 51 DNS/WINS see Name Service Providers documentation downloading 154 documentation, product 12 domain logon scripts 135 double-hop DMZ 24 TCP/IP settings 36 double-source authentication 90 downloads Access Gateway documentation 154 Administration Tool 154 from Administration Portal 154 portal page templates 154 drive mapping restricting access 226 duplex mode 35 dynamic routing enabling RIP authentication 53 saving to static route table 54 E education 13 encryption asymmetric 187 public key 188 selecting encryption ciphers 140 endpoint policy 109 build expression 110 creating 109 troubleshooting 224 valid operators 109 endpoint resource configuring 107 removing 108 Ethereal Network Analyzer unencrypted traffic 119 express setup serial console 32

233 Index 233 F failover 25 configuring 175 deployment 175 DNS servers 51 internal 134 firewall licensing 44 McAfee Personal Firewall Plus 164 Norton Personal Firewall 164 Sygate Personal Firewall 165 Tiny Personal Firewall 165 using with Access Gateway Plug-in 118 ZoneAlarm Pro 165 FTP configuring for use with client 120 G Gemalto Protiva 18, 86 Gemalto Protiva authentication 23 grace period licenses 45 group access configuration examples 209 group attributes LDAP authorization 74 Group Policy installing Access Gateway Plug-in 122 group priority 99, 111 group properties 98 group resources 99 groups adding users 101 H hardware installing 31 host check rules, see endpoint resource HOSTS file editing 52 HyperTerminal 33, 48 H.323 protocol 226 I IAS, see Internet Authentication Server ICMP transmissions 223 ICMP, see Internet Control Message Protocol idle session time-out 98, 136 IEEE support 29 IETF, see Internet Engineering Taskforce inactive server Access Gateway Advanced Edition 27 initializing the Access Gateway 162 installation 34 Access Gateway 29 Access Gateway Plug-in 127 Access Gateway Plug-in for Linux 130 Access Gateway Plug-in using MSI package 122 Administration Tool 34, 152 certificates certificates, Administration Portal 48 cross-over cables 34 hardware 31 licenses 43 materials network cables 34 portal pages 147 root certificates 50 root certificates, multiple 50 single DMZ 20 internal failover 134 Administration Tool 224 Internet Authentication Server RADIUS 77 Internet Control Message Protocol Internet Engineering Taskforce 186 Internet security protocols 185 IP pooling 99, 133 ISO X.509 protocol 188 K kiosk mode 18 logging on 148 Knowledge Center 12 Knowledge Center Alerts 13 L LDAP authentication 23, 69, 117 certificates 76 configuration examples 201, 207 configuring 71 finding directory attributes 76 group memberships 73 ports 69 LDAP authorization 69, 73 configuration examples 201 configuring 74 group attributes 74

234 234 Citrix Access Gateway Standard Edition Administrator s Guide LDAP Browser 76 license refresh information 44 statistics 40 updating 44 license logs 44 license server 39, 43 license types 40 licenses file does not match error 222 grace period 45 installing 39, 43 multiple appliances 43 obtaining 42 ports 44 testing 45 licensing firewall rules 44 XenDesktop 18 link modes serial console 32 Linux support (client) 130 checking status 131 command-line options 131 removing client 131 restarting 131 load balancer deploying appliances with 171 installation and configuration issues 172 setting as default gateway 174 load balancing 25 local authentication 67, 117 local authorization configuration examples 218 local user groups 97 local users 97 configuration example 215 configuring 68 multiple user groups 99 logging 178 Administration Portal 155 Administration Tool 155 client connection logs 179 serial console 32 logon page 99 disabling authentication 147 enabling authentication 143 logon scripts 135 M maintenance Administration Portal 155 Administration Tool 152 materials Access Gateway installation 30 maximum transmission unit 35 McAfee Personal Firewall Plus 164 modes of operation 16 monitoring tools 182 MSI installation Access Gateway Plug-in 18, 122 MTU, see maximum transmission unit Multi Router Traffic Grapher 180 multiple log on options portal page 148 N Name Service Providers 51, 227 name resolution, troubleshooting 227 NetMeeting 226 network connection failure 225 flooding 225 route tracing 182 spamming 225 split tunneling 95 network access configuration examples 200 configuring 59 providing to users 94 routing 93 network activity time-out 98 network adapters configuring TCP/IP settings 34 network cables 29 configuring TCP/IP 34 installation 34 network inactivity time-out 136 network interruption authentication 132 network monitoring packet capture 182 port scan 182 network resource adding to a group 104 CIDR not recognized 224 creating 103

235 Index 235 network resources 16, 99 allow and deny 104 configuring 102 network routing 93 network speed setting 35 Network Time Protocol 57 networks accessible to Access Gateway Access Gateway Plug-in window 130 new product names 14 node secret 83 Norton Personal Firewall 164 NTLM authentication 23, 87, 117, 227 NTLM authorization 88 NTP, see Network Time Protocol O optimization using Citrix Branch Repeater 113 P packet capture 182 packing list 29 password administrator 154 password fields 129 password labels 92, 129 passwords administrator 32, 154 certificate private keys 47 ping command 223 network monitoring ping 182 serial console 32 ping command 32 PKI, see Public Key Infrastructure policies IP pooling 133 logon pages 143 port licensing 44 port redirection 36 port scan 182 portal page 99 configuring 147 connecting to 58 customization 146 default 58 downloading templates 146, 154 installing 147 multiple log on options 148 templates 145 user name variables 146 ports Administration Portal 21 Administration Tool 21 LDAP connections 69 redirection 36 single DMZ 21 pre-authentication policies configuring 112 logging on 149 Presentation Server Clients, see Citrix XenApp Plug-ins preserve TCP options Citrix Branch Repeater 113 private Certificate Authorities 192 private key combining with signed certificate 195 installation from a Windows computer 49 password-protected 47 unencrypting 194 product documentation 12 properties Access Gateway Plug-in 164 group 98 user groups 100 proxy server configuring 121 configuring for Access Gateway Plug-in 121, 128 public Certificate Authorities 192 public key encryption 188 Public Key Infrastructure 185 R RADIUS authentication 23, 77, 117 configuring 78 configuring Internet Authentication Server 77 using SafeWord 84 RADIUS authorization 77 configuring 79 realm-based authentication Default realm 64

236 236 Citrix Access Gateway Standard Edition Administrator s Guide realms creating 66 removing 67 Real-Time Monitor 18 redirection ports 36 reinstalling software 158 removing realms 67 resource groups 102 configuring 98 removing from user group 105 resources configuring for a user group 104 restarting the Access Gateway 37, 161, 226 restoring system configuration 161 retry interval Access Gateway Advanced Edition 27 RIP authentication 53 root certificates 139, 189 creating using command prompt 51 installing 50, 140 installing multiple 50 routes configuring dynamic routing configuring static routing static 55 routing network access 93 RSA ACE/Server resetting node secret 83 uploading sdconf.rec file 82 RSA SecurID authentication 23, 80, 117 cluster 83 configuring 82 IP address setup 83 S SafeWord authentication 23, 84, 117 configuration 84 supported products 84 SafeWord authorization 85 saving system configuration 161 sdconf.rec file cluster 83 invalid file 225 replacing 83 uploading 82 Secure Socket Layer 117, 185 selecting encryption type (cipher) 140 Secure Ticket Authority 24 security 22 certificate management 22 security concepts 185 serial cable 29 serial console administrator password 32 configuring TCP/IP settings enabling or disabling administration port 32 options 32 troubleshooting 225 server certificate 189 installation 193 service 12 session time-out 98, 136 shared secret 83 shutting down the Access Gateway 162 single sign-on Windows 124 SNMP 180 logs, enabling and viewing 180 MIB groups reported 180 settings 180 speed mode 35 split DNS 98, 134 split tunneling 95 Citrix XenApp 96 configuring 96 SSL, see Secure Socket Layer standalone deployment 16 standard license 40 static routes adding 55 example 56 removing 56 testing 55 static routing testing 55 statistics 181 licensing 40 status Access Gateway Plug-in 164 Subscription Advantage 13 support Sygate Personal Firewall 165 syslog server, forwarding system log to 179 system configuration restoring 161 saving 161

237 Index 237 system log archive 178 downloading 178 filtering 178 forwarding to syslog server 179 viewing 178 system requirements Access Gateway Plug-in 116 USB storage device 159 system statistics 181 T TCP/IP settings configuring using network cables 34 configuring using serial console 33 for double-hop DMZ 36 serial console 32 technical support 12 templates downloading from portal page 146 from Administration Portal 154 portal page 145, 154 portal page customization 146 terminology changes 14 test certificates 193 time setting 57 synchronizing time-out idle session 98, 136 network inactivity 98, 136 user session 98, 136 Web session 137 Tiny Personal Firewall 165 TLS, see Transport Layer Security traceroute tool 182 training 13 Transport Layer Security 117, 185 troubleshooting Web Interface 221 U universal license 40 unsecure connections redirecting 36 updating licenses 44 upgrading 13, 17 Access Gateway Plug-in 125 Access Gateway software 156 USB storage device installation system requirements 159 user connections Access Gateway Plug-in 115 user groups authentication 97 configuring 97 creating 99 enable session time-out 136 IP pooling 133 local 97 multiple 99 overview 97 portal page 147 properties 100, 133 removing 100 resource access control 104 resources 101 spit DNS 134 users 97 user groups information 97 user name variable for portal page 146 user session time-out 136 users adding to multiple groups 101 network access 94 network resources 102 V VMWAre 223 W Web Interface 16, 99 access without credentials 221 applications not available 221 deployment 24 logging on 148 troubleshooting 221 Web session time-out 137 Windows logon scripts 135 single sign-on 124 Windows NT LAN Manager, see NTLM authentication Windows XP Access Gateway Plug-in 227 WINS troubleshooting 227 WINS server in Access Gateway Plug-in window 130 setting 51

238 238 Citrix Access Gateway Standard Edition Administrator s Guide X XenDesktop 17 licenses 18 XenDesktop Connection license 40 X.509 standard 189 Z ZoneAlarm Pro 165

239 Index 239

240 240 Citrix Access Gateway Standard Edition Administrator s Guide