XenDesktop 5

NetScaler Access Gateway Enterprise Edition Training May 2011 Draft 21Learn AGEE as it pertains to XenApp / XenDesktopImplement VPX in small/lab environmentsProvide Hands-on ExperienceInstallation ProceduresConsoles & Initial Admin TasksIntegration with XACommunicate Consulting Best PracticesIA TopicsDesign Principles

Training GoalsCitrix Confidential - Do Not DistributeDraft 2Purpose: Go over training goals

This course assumes thatYou know about NetScaler and what it does (in theory)May or may not have hands-on experienceYou are not a network expert, but knows basics (terms like IP, VLAN, packet)

Topics NOT coveredOSI in depthCore networking VLANs, RoutingCore NS features NS kernel, Compression, Caching, Content Switching, App Firewall, HTML InjectionAdvanced NS/XA features - GSLB2Training GoalsNetScaler TypesArchitecture & Deployment OptionsAdministration OverviewLoad Balancing

Agenda (1 of 2)Citrix Confidential - Do Not DistributeDraft 2Purpose: Break down the topics that will be covered during training

Course will be primarily lab focused, and less PPT

Product Overview and Types Define terms like NetScaler, AGEE, VPX, Access Gateway, ICA Proxy, Load BalancingArchitecture & Deployment Options Where a NS is situated in a network, one-arm vs two-armAdministration Overview GUI, CLI, PuTTY, WinSCPLab 1 Importing VPX and IPingLoad Balancing Methods, persistenceLab 2 WI/XML/XD load balancingAccess Gateway & XA Integration All components of NS that are required to integrate with XA/XDLab 3 ICA proxy with XA, incl cert, auth, profiles, Web Interface, etc.GSLB Brief review, the goal here is to maybe introduce some new terms to get a little deeperWI on NS Review of this new featureBest Practices IA Top 10Lab 5 Access Gateway VPX as another method of ICA proxyLab 6 A couple labs with minimal instruction

3Access Gateway & XenApp IntegrationGlobal Server Load BalancingWeb Interface on NetScalerNS Best PracticesAccess Gateway VPXAgenda (2 of 2)Citrix Confidential - Do Not DistributeDraft 2Purpose: Break down the topics that will be covered during training

Course will be primarily lab focused, and less PPT

Product Overview and Types Define terms like NetScaler, AGEE, VPX, Access Gateway, ICA Proxy, Load BalancingArchitecture & Deployment Options Where a NS is situated in a network, one-arm vs two-armAdministration Overview GUI, CLI, PuTTY, WinSCPLab 1 Importing VPX and IPingLoad Balancing Methods, persistenceLab 2 WI/XML/XD load balancingAccess Gateway & XA Integration All components of NS that are required to integrate with XA/XDLab 3 ICA proxy with XA, incl cert, auth, profiles, Web Interface, etc.GSLB Brief review, the goal here is to maybe introduce some new terms to get a little deeperWI on NS Review of this new featureBest Practices IA Top 10Lab 5 Access Gateway VPX as another method of ICA proxyLab 6 A couple labs with minimal instruction

4NetScaler Hardware and FeaturesDraft 2Review NS platformsTalk about what is the difference between NS and AGEE?5

MPX 5500MPX 7500 and MPX 9500MPX 10500/12500/15500

MPX 17500/19500/21500NetScaler HardwareVPX

List differentiating features here.

5500 aimed at the many XenApp deployments where load balancing and GSLB of its various services including XML brokers, web interface servers, etc.7500/9500 larger enterprise needs and some mid-size Internet-centric operations10500/12500/ 15500/17000 fill the need for larger enterprises and mid-size Internet-centric, social networking, e-commerce and other operations.17500/19500/21500 added horsepower to the new datacenters. Large Internet-centric operations including social networking and search, cloud computing providers with multi-tenant demands, very large enterprises with private cloud operations, service providers and telcos all demand the utmost in performance.

VPX lab/test environments, development environments, Datacenter-in-a-box, CPU-intensive workloads, Frequently moved apps, Fast/remote deployment

Three main differences exist between NS MPX and VPX:System capacityPerformanceTagged VLAN ConfigurationNetScaler VPX system capacity:No hardware SSL accelerationProcessing not offloaded to dedicated siliconDifferences Between MPX and VPXCitrix Confidential - Do Not DistributeTalk to your Networking Consultant if clients are asking for more info. Most AGEE deployments use MPX5500, VPX for lab. See next slide.7When to Use Which?NetScaler AppliancesNetScaler VPX Gig+ performance High volume SSL Offload >100 SSL VPN CCUs FIPS requirements Physical device security Labs/test environments Development environments Datacenter-in-a-box CPU-intensive workloads Frequently moved apps Fast/remote deployment

So where do customers use a dedicated hardware appliance vs. server based version? This table provides guidelines on when to use a physical appliance vs. when to use a virtual appliance. Physical appliances are the clear choice in situations where high throughput is required, or when the physical security of the device is paramount.

NetScaler VPX is perfect for non-production environments, situations where it is desirable to have as much of the infrastructure virtualized as possible (e.g., datacenter in a box, and anytime fast/rapid deployment is a requirement. Also, NetScaler VPX may make the most economic sense when high CPU web app delivery workloads are required.8NetScaler SDX Announcing at Synergy

Instances, not partitionsComplete CPU isolationComplete memory isolationVersion independenceHigh availability independenceLifecycle independenceIntroducing NetScaler SDXUse case large cloud providers.. Like a physical VPX950 Gb/sSingle VIP50 Gb/s16 instancesUp to 18Gbps per instance8M packets/secondNetScaler MPX 21500NetScaler SDX 21500

Note the highlighted throughput and blue aura, which a major differentiator

10NetScaler FeaturesCitrix Confidential - Do Not Distribute

Draft 2Features required for AGEE areAccess GatewayAAA

Switch license you will get everything except Integrated Caching AG with lic for 5 users

Other common ones to add are Load Balancing and GSLB11NetScaler MPXNetScaler VPXAccess Gateway Enterprise Edition

Access Gateway Standard EditionAccess Gateway VPX

Secure GatewayICA Proxy for AllCitrix Confidential - Do Not Distribute

Draft 2Purpose: Transition into how this all relates to Core CCS ICA Proxy aka Secure Gateway

Introduce the concept of different NetScalers / Access Gateways out there and different code bases

All these things will do Secure Gateway1st - Secure Gateway for Windows: Free, not secure because of IIS2nd - Access Gateway: turns SG into appliance, can charge for licenses3rd - NetScaler: SG appliance on a better platform and a LOT more features (LB with monitors)12IP & RoutingLicensingHAAuthenticationAuthorizationCertificatesWeb InterfaceSSL VPNSession PoliciesLogging & Monitoring~10 Steps to Typical AGEECitrix Confidential - Do Not DistributeDraft 2Purpose: Discuss the technical concepts to setting up an AGEE environment. Typical means regular ICA proxy, nothing fancy.

13Architecture & Deployment OptionsDraft 2Purpose: Discuss NS architecture. So where does it go in a network?14AG in a Secure NetworkAG in DMZ with WIWI behind AGAG parallel to WIAG in DMZ with WI internallyAG in Double-Hop

Citrix Confidential - Do Not DistributeDeployment Options

Draft 2AG in Secure Network Some clients have an appliance in the DMZ but then want SSL for internal clients. This is generally not recommended because it causes excess traffic on the firewall to the DMZ. Larger deployments should have a dedicated pair in the internal network (or two-arm configuration but this usually isnt allowed)AG in DMZ, WI behind AG Authentication can happen either at WI or AG. AG proxies the WI page. Less common.AG in DMZ, AG parallel to WI Authentication happens at WI or AG. Users can access WI page directly, and then gateway direct settings route ICA sessions through AG.AG in DMZ, WI internal Most common. AG proxies WI page, authentication at AG before directing to internal resource. Authentication at AG not recommended to auth at WIAG in Double-Hop For specific customer scenario15Citrix Confidential - Do Not DistributePhysical Deployment ModesOne-Arm

One interface, no risk of bridge loopsCan utilize LANs with 802.1q taggingCan utilize Link Aggregation to satisfy bandwidth requirementsDraft 2One-arm is by far the most common. In the normal inline mode, multiple network interfaces are connected to different Ethernet segments and the NetScaler is placed between the clients and the servers. The NetScaler has a separate network interface to each client network and a separate network interface to each server network. The NetScaler and the servers can exist on different subnets in this configuration. It is possible for the servers to be in a public network and the clients to directly access the servers through the NetScaler, with the NetScaler transparently applying the L4-L7 features. Usually, vServers (described later) are configured to provide an abstraction of the real servers. The following diagram illustrates a typical inline deployment.16Citrix Confidential - Do Not DistributePhysical Deployment ModesTwo-ArmAccommodates topologies in situations where one-armed does notAllows layer 3 (routed) deployments with split subnets (as shown)Allows layer 2 (bridged) deployments with one subnet on both sides

Draft 2Two-arm is much less common.17NetScaler IP (NSIP) Management IPMapped IP (MIP) Used for server-side connection, replaces Source IP with the MIPSubnet IP (SNIP) Same as a MIP. SNIP were introduced in newer releases of code. Virtual IP (VIP) IP address associated with a Virtual Server

Citrix Confidential - Do Not DistributeNetScaler TermsDraft 2A NetScaler is usually deployed in front of a server farm and functions as a transparent TCP proxy between clients and servers, without requiring any client-side configuration. This basic mode of operation is called Request Switching technology and is the core of NetScaler functionality. Request Switching enables a NetScaler to multiplex and offload the TCP connections, maintain persistent connections, and manage traffic at the request (application layer) level.

NetScaler IP address (NSIP). The NSIP is the IP address for general system and management access to the NetScaler itself.Mapped IP address (MIP) outdated, less common. The MIP is used for server-side connections. It is not the IP address of the NetScaler. In most cases, when the NetScaler receives a packet, it replaces the source IP address with the MIP before sending the packet to the server. With the servers abstracted from the clients, the NetScaler manages connections more efficiently.Subnet IP address (SNIP). When the NetScaler is attached to multiple subnets, SNIPs may be configured for use as MIPs providing access to those subnets. If NS has to directly communicate with an IP in a subnet different from the subnet of NSIP, a subnet IP has to be created Virtual server IP address (VIP). A VIP is the IP address associated with a vserver. It is the public IP address to which clients connect. A NetScaler managing a wide range of traffic may have many VIPs configured.18Administration OverviewDraft 2Brief topic on how administration occurs, in preparation for first lab19Access the GUI by going to NSIPAccess the CLI through SSH client (PuTTY)Access file system through SFTP client (WinSCP)

Citrix Confidential - Do Not DistributeGUI / CLIDraft 2GUI used for point-and-click administration of NSCLI done either though console or SSH connection, with access to more commandsSFTP used to transfer files20> show run> show route> show ns feature> show ns mode > show ha node > show license

Citrix Confidential - Do Not DistributeKey CLI CommandsDraft 221ns.conf loaded on startupChanges reflected in running configChanges must be commited to saved configCitrix Confidential - Do Not DistributeRunning Config, Saved ConfigDraft 2This applies to most networking appliances; changes must be committed. A reboot without saving will revert to the last saved config.22Lab 1 VPX Initial Configuration

Objectives: Import VPX Configure IP and Licensing Configure HA Run basic CLI commandsDraft 223What items need to be planned in advance for a NS VPX POC?

Citrix Confidential - Do Not DistributeLab 1 DiscussionDraft 224Load BalancingDraft 2Now that weve covered the models, features and architecture, were going to dive into the two features that matter to us: Load Balancing and Access Gateway.25Servers, Services, vServers, MonitorsLoad Balancing applies to TCP or UDP and HTTP/HTTPsA load balancing virtual server is bound to services "listeners" on ports

Citrix Confidential - Do Not DistributeLoad Balancing PrimerDraft 2The Load Balancing functionality is one of the core features of the NetScaler Application Switch. Configuring load balancing is done with the following entities:

Servers: These entities are internal aliases for servers on the network. They can refer to the hosts directly by IP, or by name (using DNS to resolve the name to an IP address).Services and service groups: These entities are configured as references to protocol- and port- specific services listening on the servers.Virtual servers (vServers): These entities are configured with the IP address and port to which clients initiate connections, and are protocol-specific. The NS claims the IP on the network, and the virtual server configuration governs client-side timeouts and other client-side flow/connection parameters.Monitors: These entities are configured to probe a service (or a designated alternate location) to verify that a service is available and healthy. If a probe attempt fails to receive the expected result, the monitor will take the service to which it is bound DOWN. A service in the DOWN state will not receive traffic from the load balancing functionality.

Associating one configured entity with another is called binding. The services/service groups are bound to the vServer; requests from the clients to the vServer can be forwarded only to the services bound to the vServer, with the NS serving as the proxy. Each service or service group is also bound to at least one monitor to determine service health. There are default monitors for each service type, automatically bound to the service at service creation:Ping (default): All non-TCP service types, e.g., ANY, UDP, DNSTCP (default): All TCP-based service types, e.g., TCP, SSL, HTTP, FTPExplicitly binding another monitor to a service automatically disables the default monitor.

A load-balancing virtual server can be configured to support any one of a number of traffic types. Multiple load-balancing servers can be configured on the same virtual IP address but for different services.

HTTP, FTP DNS, NNTP and HTTPS can all be configured at the application layer; this means that the application switching will be done at the request level rather than the connection level. This allows for a much greater granularity in the load-balancing process. The SSL setting represents HTTPS and will instruct the virtual server to terminate and decrypt the HTTPS connection. An administrator can configure a load-balancing server as type SSL and associate it with a service of type HTTP. In this case the traffic from the user would be encrypted to the NetScaler system, and then plain text HTTP traffic would be forwarded from the NetScaler system to the backend server.

The load-balancing server can also be associated with a generic session protocol, either TCP or UDP. TCP based protocols, other than HTTP, can also be secured using SSL. If the incoming traffic is SSL encrypted, but not HTTP, a virtual server of type SSL_TCP would be created. This server will decrypt the traffic on arrival and forward it based on the protocols defined on the services bound to it.

If there is a requirement that the encrypted SSL traffic must remain encrypted as it crosses the NetScaler system, then a virtual server of type SSL_BRIDGE should be chosen. This server will not decrypt the SSL data as it is received; rather it will just forward the traffic unaltered to the backend services.

26Least Connections (default)Round RobinWeighted Round RobinLeast Response TimeLeast BandwidthLeast PacketsLRTMTokenCitrix Confidential - Do Not DistributeLB MethodsURL HashDomain Name HashSource IP HashDestination IP HashSource/Dest IP HashLB using SNMPSASP/Call ID Hash

Draft 2Why do we care about this? LB method must be defined on our LB vServer to say how traffic will be dispersed between its members.Point of this slide is to say there are a lot of types just talk about the first couple

Least Connections Available for all protocols (TCP, HTTP, HTTPS, SSL_TCP and UDP). When this method is configured the Connection Request is forwarded to the service that has the fewest connections. Connections include established active connections and connections waiting in the surge queue. For UDP connections included in the calculation would be all sessions between the client and a physical service.

Round Robin and Weighted Round Robin incoming requests are distributed to services in rotation regardless of load. For weighted Round Robin, weights are assigned to services and requests are allocated according to how much weighting has been set.

Least Response Time New connection requests are sent to the service with the minimum average response time. Response time is the elapsed time between sending a request packet and receiving the first byte of the response.

Least Bandwidth New connection requests are sent to the service that is currently serving the least amount of traffic in MBPS.

Least Packets New connection requests are sent to the service that is serving the fewest packets per second.

Token New request load balancing decisions are based on a value extracted from the client request, for subsequent requests containing the same token, the same physical server is used. The token operates differently for different service types (TCP, HTTP, HTTPs etc.)

URL hashing (default behavior) New connection requests are LB based on a hash of the first 80 bytes of the URL.

Domain Name hashing New connections are LB based on the hashed value of the domain name in the HTTP request.

Source IP Hashing and Destination IP Hashing - LB on the hashed value of the corresponding IP address.

Source IP/Destination IP Hashing is a symmetric hash between the source and destination IP addresses yielding the same value if they are reversed. This method is primarily used in IDS (Intrusion Detection System) Load balancing configurations.

LRTM (Least Response Time Monitoring) Takes advantage of the monitoring probes sent by the NetScaler to the services to determine their state. This method works with both HTTP and non-HTTP based services.The Load balancing functions of the NetScaler have been enhanced to include support for Load Balancing on various server parameters that are exposed through SNMP.

These parameters include CPU and memory so the load balancing decision is based on the Hardware performance of the backend servers.

SASP Support for Dynamic Weight Calculation is newly added load-balancing support for IBMs Server Application State Protocol (SASP). So the NetScaler can now make LB decisions based on the weights assigned to services by the Enterprise Workload Manager (EWLM). An EWLM agent runs on each of the backend servers which relays performance data to the EWLM and the EWLM then uses this data to dynamically calculate the weight for each back-end server and updates the NS with the calculated weights on 30 sec intervals27Source-IP (w/ netmask)Cookie Insert (HTTP/SSL only)SSL Session-IDURL passiveCustom Server IDDestination IPRuleCitrix Confidential - Do Not DistributeSession PersistenceDraft 2Why do we care about this? Different types of persistence are set between WI and XML. WI persistence used to be a big deal as it was typically mis-configured and users would get inconsistent session state errors

How to Set the Timeout Value for the COOKIEINSERT Persistence on a NetScaler Appliance - CTX108883http://community.citrix.com/display/ocb/2010/06/01/Configuring%2C+Verifying+and+Monitoring+Persistence+on+NetScalerPlanning Guide: Load Balancing Web Interface with Netscaler - http://support.citrix.com/article/CTX128563

After load balancing the initial request, there are reasons to ensure that subsequent requests from the same client are directed to the same server. This behavior is called persistence, and it is configured through the virtual server.

There are a number of methods to maintain persistent connections. It can be tracked based on the clients IP address and mask. This is not always the most efficient method because of the nearly universal use of NAT/PAT in corporate environments. All users passing through the same NAT device would appear to originate from the same IP address and hence would be directed to the same server even though they represent different requests that could be more efficiently load balanced. Each new source IP address would be tracked in a persistence table on the Citrix NetScaler.

A more elegant and granular solution is to insert a cookie into the clients request that identifies the server responsible for it. The client would then include this cookie with future requests and would be directed to the correct server. The advantage here is two fold; First, it allows us to differentiate between different users coming from the same source IP address; secondly, it does not require any resources on the Citrix NetScaler to track the session. The disadvantage of this method is that it only works on clients that accept cookies. IF the client choose not to accept the cookie from the Citrix NetScaler, then there will be no persistence implemented on there future connections.

SSL Session ID can be used to enforce persistence on secure communications. It will require entries to be placed in the persistence table, but it is considerably more granular than source IP methods.

Passive URL and Custom Server ID persistence rely on the server being able to pass some unique ID through the URL that the client is requesting. This ID would designate the server to receive the persistent client traffic either through a hexadecimal IP address and port in the case of URL Passive or through a server ID string in the Custom Server ID method. It may not be possible in all cases for the application running on the server to be modified to present this additional information.

Finally, rules can be written to base persistence on other values in the client request as defined by the user. This method would be applicable only in very specific environments. For example, if the application required uses of particular browsers to continue to connect to the same server a rule could be written based on the HTTP user-agent field.

The persistence table can maintain a maximum of 256K entries (262,144) at any one time. The entry time out can range from the default of 2 minutes to a maximum value of 1 day. If the server designated by the persistence method is unavailable, the request is passed back through the load balancing method and a new persistent server is found. Cookie Insertion persistence is the only method that does not require any use of the persistence table.

The persistence method is configured either during the load balancing virtual servers creation, or after the face through the set lb vserver persistancetype command.

28Reverse Network Address Translation & Use Source IP requiredUSIP provides client IP to backend (TFTP) serversDefault gateway for TFTP (on PVS) needs to point to NS SNIPhttp://support.citrix.com/article/CTX110459Citrix Confidential - Do Not DistributeLoad Balancing TFTPDraft 2This article describes how to load balance a Trivial File Transfer Protocol (TFTP) server using Reverse Network Address Translation (RNAT) and Use Source IP (USIP).

TFTP is simple file transport protocol. It uses User Datagram Protocol (UDP) port 69 as a transport protocol and is typically implemented on private networks. Once a connection is established, data transfer occurs over a separate data connection initiated by the server back to the client.To overcome the challenges presented with load balancing TFTP servers, RNAT and USIP modes can be implemented. These modes allow the server to which the initial connection was made to connect back to the client with the new data connection using the Virtual IP (VIP) as the source IP

29Lab 2 Load Balancing

Objectives: Manually create LB VIP for WI & XML Use wizard for WI & XMLDraft 230When would you need SSL_BRIDGE type of LB?What do you do without a hardware load balancer?Who uses XML LB? Advantages/disadvantages?

Citrix Confidential - Do Not DistributeLab 2 DiscussionDraft 21 SSL_BRIDGE when backend server is SSL and you dont terminate at NS. For example, if WI has a cert. Or if you are doing LB for XML when SSL Relay is enabled.2 software load balancing via MS NLB, DNS round robin, NS backup vServers (http://support.citrix.com/article/CTX125511)3 discuss

31Access Gateway and XA/XD IntegrationDraft 2Access Gateway vServersauth, session pol, session profile, certsWI Configuration for SGDiving into the Callback URLSmartAccessLogin Page Customization

32Access Gateway virtual servers bind withCertificatesAuthenticationPoliciesProfilesSTA

Citrix Confidential - Do Not DistributeAccess Gateway Components

Draft 2Overview of the components we are about to talk about33Full SSL VPN requires client componentICA Proxy WI integration with SSL for ICAClientless Connections web application proxyCitrix Confidential - Do Not DistributeAccess Gateway Configuration OptionsDraft 2NetScaler started with SSL VPN, and we integrated additional functionality (ICA Proxy, NavUI, clientless, etc.). However this is all under the bucket of Access Gateway

Full SSL Tunnel connections requiring a client component installed on the end user device.If you leave homepage blank you will see NavUIICA Proxy connections which integrate with the Web Interface portal and AAC authentication mechanism and allow you to proxy ICA connections through an SSL connection to the AGEE appliance.Clientless connections which allow you to proxy general web based applications through an SSL connection to the AGEE appliance all the while obfuscating the hostnames of the resources you are internally accessingDefault is homepage.html (3 pane NavUI)34Default settings applied to all AG sessionsCitrix Confidential - Do Not DistributeGlobal Settings

Draft 2The configuration options as described before are defined by global settings and policies

The settings defined in AGEE Global settings are applied to all VPN sessions regardless of VPN Vserver unless they are overridden by a higher priority policy. You can view the global settings in the GUI the slow way or the sh vpn parm command as demonstrated in the graphics.

35Customizes the session behavior

ICA Proxy ON tells AGEE not to launch the Secure Access ClientURL to the Web Interface site e.g. http://wiserver/citrix/xenapp Embedded Web Interface display formatFull or CompactSingle Sign-On Domain specifies the users domain is logged on toCitrix Confidential - Do Not DistributeSession Profile

Draft 2Instructor: Recap Policy vs Profile on this slide. Ask the audience the difference again.Instructor: Reiterate the difference between ICA Proxy ON and OFF. Ask audience to think about why you would use these options. Provide ExamplesSmartAccessNT Domain name: is the NT Domain name when the UPN is not extracted from AD

36Define the conditions to invoke a session profileCitrix Confidential - Do Not DistributeSession Policies

Draft 2Session Policies are the main tool for customizing each session. They are used to override the majority of the global defaults and can be applied based on group membership, destination IP (bound to VIP), or the results of a client side end point analysis scan. Here you can define home pages, client type, and security scans for the use with Quarantine groups in a reduced access type of scenario

37add vpn sessionAction prof_smart_phone -sessTimeout 30 -splitTunnel ON -defaultAuthorizationAction ALLOW -clientIdleTimeout 30 -SSO ON -icaProxy ON -wihome "https://sfdc.com/Citrix/XenApp/PNAgent/config.xml" -ntDomain SFDCadd vpn sessionPolicy pol_smart_phone "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" prof_smart_phonebind vpn vserver sfm-cxi-ag1.salesforce.com -policy pol_smart_phone -priority 10Citrix Confidential - Do Not DistributePolicy + Action + vServerDraft 23 lines from a ns.conf file, showing how policies bind to actions, and how AG vServers bind to policies. Same thing goes for authentication policies, pre-auth, etc.38ns_trueREQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiverREQ.HTTP.HEADER Host == access.citrix.comCLIENT.FILE('C:\\\\file.dat').TIMESTAMP == 7dy -frequency 5CLIENT.SVC('Symantec\\ AntiVirus').VERSION == 10.0 -frequency 5CLIENT.APPLICATION.PROCESS(notepad.exe) EXISTSCLIENT.OS(winxp) EXISTSCitrix Confidential - Do Not DistributePolicy ExpressionsDraft 239Results aggregated from all true policiesPriority determines result in the event of conflictLowest bind point wins with policies bound to different bind points (Global > Virtual Server > Group > User)Citrix Confidential - Do Not DistributePolicy PriorityDraft 2Policy results are aggregated from all policies that are true. When the policy settings conflict, priority wins. When policy settings do not conflict, the results are cumulative from all policies that are trueWhen policies are bound to different bind points with the same priority the lowest bind point wins (Global > Virtual Server > Group > User)40Home pagewww.citrix.comResulting ConfigurationHome pagewww.sales.comSplit TunnelONSingle Sign-on-not set-Split Tunnel OFFSingle Sign-onONVirtual ServerPolicy BPriority 100Home pagewww.google.comSplit Tunnel-not set-Single Sign-onOFFGroupPolicy CPriority 100 Home pagewww.sales.comSplit TunnelOFFSingle Sign-onONGlobalPolicy APriority 100Policy Priority ExerciseCitrix Confidential - Do Not DistributeDraft 2The reason we want to talk about this is because people configure things at the Global level and also at the vServer level. This is the precedence.

Policy results are aggregated from all policies that are true. When the policy settings conflict, priority wins. When policy settings do not conflict, the results are cumulative from all policies that are trueWhen policies are bound to different bind points with the same priority the lowest bind point wins (Global > Virtual Server > Group > User)41Home pagewww.citrix.comResulting ConfigurationHome pagewww.citrix.comSplit Tunnel-not set-Single Sign-on-not set-Split Tunnel OFFSingle Sign-onOFFVirtual ServerPolicy BPriority 20Home pagewww.google.comSplit Tunnel-not set-Single Sign-onOFFGroupPolicy CPriority 30Home pagewww.sales.comSplit TunnelOFFSingle Sign-onONGlobalPolicy APriority 10Policy Priority ExerciseCitrix Confidential - Do Not DistributeDraft 2The reason we want to talk about this is because people configure things at the Global level and also at the vServer level. This is the precedence.

Policy results are aggregated from all policies that are true. When the policy settings conflict, priority wins. When policy settings do not conflict, the results are cumulative from all policies that are trueWhen policies are bound to different bind points with the same priority the lowest bind point wins (Global > Virtual Server > Group > User)42Home pagewww.citrix.comResulting ConfigurationHome pagewww.google.comSplit TunnelONSingle Sign-onOFFSplit Tunnel OFFSingle Sign-onONVirtual ServerPolicy BPriority 90Home pagewww.google.comSplit Tunnel-not set-Single Sign-onONGroupPolicy CPriority 100Home pagewww.sales.comSplit TunnelOFFSingle Sign-on-not set-GlobalPolicy APriority 100Policy Priority ExerciseCitrix Confidential - Do Not DistributeDraft 2The reason we want to talk about this is because people configure things at the Global level and also at the vServer level. This is the precedence.

Policy results are aggregated from all policies that are true. When the policy settings conflict, priority wins. When policy settings do not conflict, the results are cumulative from all policies that are trueWhen policies are bound to different bind points with the same priority the lowest bind point wins (Global > Virtual Server > Group > User)43Define authentication sourceLocalRADIUSLDAPTACACSNT4CERTCitrix Confidential - Do Not DistributeAuthentication Policies

Draft 2Authentication policies are used to define the source for authenticating your users. Currently the AGEE supports the following Authentication Types:Local used to authenticate users defined locally on the AGEE RADIUS (RSA, Safeword)LDAP used for LDAP directory authentication (MS Active Directory, Novell E-Directory)TACACS UNIX based remote authentication protocolNT4 Used to authenticate to old Microsoft NT 4 domainsCERT Used to enforce client certificate authentication. You are able to extract user or group names with these to use for other authentication mechanisms.

44Citrix Confidential - Do Not DistributeGroups

Define user groups to apply policies and settingsDraft 2Groups are typically defined on the AGEE unit for group extraction. Group extraction is a way of parsing the response of a remote authentication request (i.e. Radius, LDAP) for the groups that a particular user is a member of. If one of the groups in the response matches one defined on the AGEE, then the user is bound to any policies and authorizations that are defined for the group. Like the VPN Virtual Server, the Group serves mostly as a bind point for policies.45

Citrix Confidential - Do Not DistributeWeb Interface Configuration

Draft 2Web Interface needs specific configuration to interact with AG

Emphasize the difference between direct mode and AAC mode.

Important points to remember:WI can point to any vpn vserver, not necessarily the one where users connect. WI must be able to resolve the FQDN of the virtual serverWI must be able to route to the virtual server IP over HTTPSWI must trust the SSL certificate from a machine level.

46WI makes a callback to the SSL VPN VIPRetrieves information over HTTPS such as farm, vServer entity name, the session policy used etcValues are sent on the XenApp server to generate the Smart Access control setCitrix Confidential - Do Not DistributeThe CallbackDraft 2Information contained in the SmartAccess CallbackCitrix Confidential - Do Not DistributeThe Callback 10.90.148.9 test-sslvpn 10.90.196.74 d5a2c72094481373296b02 WI-AccessDraft 2POST /scripts/wpnbr.dll HTTP/1.1Content-Type: text/xmlHost: 10.90.147.45:8080Content-Length: 1518Connection: Keep-Alive

rade-offline-mode permissions all ica30 rade content student01 OGCKPLCMOADNKJCN RONAN WI_yzUcBlqqnEbfoJgv_ 10.90.148.9 MSAM 1 test-sslvpn 10.90.196.74 d5a2c720944c4d37828a781373296b02 WI-Access SETVPNPARAMS_POL

48External

WorkstationLDAP

WIInternal DMZSTA and XML44380/443389/636AGEE returns EPA results to WISession policy EPA check results returned to AGEE Web Interface sends credentials & EPA results to Citrix XML Service which validates them and returns users smart access application set to Web Interface.Web Interface generates Smart Access application set page and sends the web page back to user.Access Gateway passes credentials to Directory Service for validation. EPA ActiveX sends results back to AGEEOn Pre-Authentication EPA success AGEE returns login pagePost-AuthN AGEE Session policy EPA checks done with the existing EPA ActiveX Web Interface Authenticates credentials provided via custom SSO AGCitrixBasic HeaderAGEE Pre-AuthN EPA ActiveX download & client scanAGEE does a HTTP redirect to the website configured in -homepage option2) Web Interface returns a 401 and AGEE detects that this is a Web Interface server.User supplies credentials to logon page.User accesses AGEE VPN Virtual Server3) Access Gateway next performs pass-through SSO to Web Interface via a custom AGCitrixBasic HTTP Header4) A SessionToken is also providedWI makes a XML callback to a preconfigured-on-WI AGEE VPN Virtual Server URL with the previously provided SessionToken to get the EPA Results XenApp

SmartAccess WorkflowAGEE

Citrix Confidential - Do Not DistributeDraft 2User points browser to the AGEE VPN VserverPre-Authn EPA ActiveX control gets downloadedIf Pre-Authn EPA is successful, user gets the login pageAGEE authenticates user against configured authentication serverIf Post-Authn EPA policies are configured, EPA ActiveX is downloaded againAGEE sends a redirect to the WI homepageWI returns a 401. After the 401 handshake is successful, AGEE hands off previously collected EPA results to WIWI then talks to the XenApp and returns application list to the userUser can now click on icons to launch published applications

49STA must be configured on Access Gateway Citrix Confidential - Do Not DistributeSTA Configuration

Draft 2Instructor: Explain why we need to define a STA server on AGEE?The STA Server ID and State are monitored by AGEE

Multiple STA Servers can be defined for failover

Note, list of STAs should be exactly the same50STA and XML

External

XenAppWIInternal DMZ44380/44380/4431494/2598User clicks application icon. Request is sent to Web Interface.Web Interface contacts Citrix XML Service to determine least loaded XenApp server hosting application. XML Service returns XenApp IP address.Web Interface contacts STA to exchange XenApp IP address for ticket.Web Interface generates ICA file that includes Access Gateway FQDN and STA ticket. ICA file is sent back to client device.ICA Client sends ICA request to Access Gateway. Access Gateway contacts STA to validate ticket and exchange the ticket for the XenApp IP address. Access Gateway contacts XenApp to initiate ICA session. ICA session is established.

Workstation

AGEE

Published Application Launch ProcessCitrix Confidential - Do Not DistributeDraft 2Following successful Authentication and EPA scan, the user is presented with the list of published applications User clicks an application icon Web Interface requests a ticket from the Secure Ticket Authority Web Interface sends a ticket to the user in a ICA file The ICA client launches and sends secure ICA traffic to Access Gateway Access Gateway validates the ticket against the STA The ICA session is established

51Lab 3 Access Gateway

Objectives: Configure components for AG Launch application using SSL Configure EPA and SmartAccessDraft 252What other authentication methods are relevant to us?What does clientless access really mean?Citrix Confidential - Do Not DistributeLab 3 DiscussionDraft 2Authentication LDAP-S, RadiusClientless - 53Global Server Load BalancingDraft 2Load balance services between separate locationsTypical uses include:Distribution of network traffic across multiple sitesDistribution of server load across multiple sitesDisaster recoveryRelies on DNS for directing client requestsShare the state & status of various geographically distributed servers

Citrix Confidential - Do Not DistributeGSLB OverviewDraft 2Level set what people should know already

Load balance between multiple data centers, typically for DROperates under many of the same general principles as LB but relies on DNS for directing client requests

Extends its traffic management capabilities to include distributed Internet sites and global enterprises. Whether installations are spread across multiple network locations or multiple clusters in a single location, the system maintains availability and distributes traffic across them. It then makes intelligent DNS decisions to prevent users from being sent to a site that is down or overloaded. When the proximity-based GSLB method is enabled, it allows the system to make load-balancing decisions based on the proximity of the clients Local DNS Server (LDNS) in relation to different sites. The main benefit of the proximity-based GSLB method is faster response time resulting from the selection of the closest available site

The Global Server Load Balancing (GSLB) feature allows you to configure the system to direct DNS requests, from a client, to the best performing GSLB Site (Site) in a distributed Internet environment. This feature is DNS-based and enables the system to make intelligent decisions. For instance, if a Site fails, the system detects the failure and directs traffic to another available Site. This feature prevents client requests from being sent to a Site that is down or over-loaded. The following entity diagram illustrates a typical GSLB deployment.55Citrix Confidential - Do Not DistributeGSLB Typical DesignFloridawww.testlab.comVgslbVslbA

192.168.100.11:80172.206.65.10:80172.206.65.11:80AtlantaVslbB

192.168.100.12:80

svc1asvc2asvc1bsvc2bPrivate IP172.22.8.100:80Private IP172.22.8.200:80Public IP1.1.1.1Public IP2.2.2.2Draft 2Global Server Load Balancing (GSLB) addresses the needs of a distributed Internet environment with Citrix NetScaler systems located in different geographic locationsAllows to configure the system to direct DNS requests, from a client, to the best performing GSLB Site in a distributed Internet environment56Similar to Load Balancing componentsGSLB entities (descending hierarchy)GSLB domainGSLB siteGSLB vServerGSLB servicevServerServiceServerCitrix Confidential - Do Not DistributeGSLB EntitiesDraft 2Talk through this slide from the bottom. So far we are familiar with Server, Services, vServer all the GSLB ones are new.

GSLB domain: Publicly resolvable domain (zone) the GSLB deployment responds asGSLB site: Top level entity for linking remote sites, sharing monitoring data. IP needs to be an NS owned address (MIP, SNIP)GSLB vServer: Linked to GSLB services, is the decision intermediary for directing clients requests to one of the sites LB vservers.GSLB service: Monitoring link to the vServer to be load balanced vServer: Represents the servers and services being LBd to clientsservice: Links to & monitors the service/server (http, https, etc) fronted by the vserver

57Step 1: Client sends a DNS request to the local DNS (LDNS) serverStep 2: The LDNS server sends the request to the ADNS service/DNS vServer on the systemStep 3: The ADNS service/DNS vServer responds with the IP address of the LB vServer on the best-performing Site

Citrix Confidential - Do Not DistributeDNS & GSLBDraft 21) The stub resolver (a software program running on the client computer) makes a request to the assigned local DNS server, which in this example is in the clients Internet Service Provider (ISP) DNS server farm in Atlanta, Georgia. The client must receive either an answer, or an error. This is called a recursive query. Note: the stub resolver program is not capable of digging through the Internet to find the answer. That is the job of a DNS server.2) The clients DNS server performs an iterative resolution on behalf of the client, querying the root name servers and eventually ending up at the authoritative name server for www.trapster.net. In this case the GSLB device is that authoritative name server.3) The GSLB device performs some sort of communications with software or devices at each site, gathering information such as site health, number of connections, and response time.4) The software or device at each site optionally performs some sort of dynamic performance measurement, such as a round trip time (RTT), or topographical footrace, or BGP hop count, back to the clients DNS server.5) Using the information gathered in steps 3 and 4, the GSLB device makes a determination as to the preferred site, and returns the answer to the clients DNS server. The answer is either IP address 1.1.1.1 or IP address 2.2.2.2. If the time to live (TTL) is not set to zero, the answer is cached at the clients DNS server, so that other clients that share the server will make use of the previous calculation (and not repeat steps 2 through 4).6) The DNS answer is returned to the clients stub resolver.

58

Citrix Confidential - Do Not DistributeGSLB EntitiesLDNSDraft 2Talk through 1) the steps 2) ADNS vs LDNS 3) repeat the components in a site 4) MEP description

Step1: Client sends a DNS request to the local DNS (LDNS) server.Step 2: The LDNS server sends the request to the ADNS service/DNS vServer on the system.Step 3: The ADNS service/DNS vServer responds with the IP address of the LB vServer on the best-performing Site.

As an Authoritative DNS (ADNS) server, the system resolves DNS requests for all types of DNS records. For the system to function as an ADNS server, you need to configure an ADNS service on the system.! Implications: To enable GSLB you need to work with the LDNS and see if they support LDNS subdomain delegation

The Site is the central entity in a GSLB deployment. It is represented by a name and an IP address. The IP address of the Site is a system-owned IP address. You can use a MIP or an SNIP. In addition, you can also create a new IP address for the Site called the GSLB Site IP address. The Site is a logical aggregation of the following entities:GSLB vserver: Is an entity that performs load balancing for the domains bound to it by returning the IP address of the best GSLB service.GSLB service: This is the representation of the LB/CS vserver.LB vserver: This entity load balances incoming traffic by identifying the best back-end server and sending directing traffic to the corresponding service.Multiple services: These entities represent the back-end servers.Domain: The domain name for which the system is the authoritative DNS server.

MEP: Metric Exchange ProtocolNetScaler Internal Protocol to exchange state and health information over a TCP session, enabled by default.The system uses the proprietary Metric Exchange Protocol (MEP) to exchange the Site metrics, network metrics, and persistence information between Sites. Once a connection is established between two Sites, all metric information is exchanged across this single long-lived connection. The Site with the lower Site IP address initiates the connection with the site with the higher Site IP address. By default, this connection is made from the NSIP to the Site IP address. However, you can configure the system to use an alternate IP address other than the NSIP. 59Web Interface on NetScalerDraft 2Feature is available on 9.3 (RTW 3/30)MPX and nCore VPX not available on classicWeb Interface version 5.4There are two packages that need to be installed on NS1. Web Interface files 2. Java Runtime Environment

Citrix Confidential - Do Not DistributeWeb Interface on NetScalerDraft 2Integrated Web Interface on NetScalerWeb Interface for NetScaler is available as a General Availability feature in NetScaler Release 9.3.The solution requires the use of NetScaler MPX or VPX models with nCore.The WI version supported for this is WI 5.4.

Download and InstallWeb Interface requires two components be installed on the NetScaler to start it: (1) A Java Runtime Environment (JRE), and (2) The Web Interface core. Both pieces are available as individual downloads on this page. You must download and install both components to make Web Interface work.

To begin, download the following software files. For faster installation, copy these tar files to a local workstation or to the /var directory of the NetScaler appliance.

Download the Java Diablo Latte JRE 1.6.0.7 install file for FreeBSD 6.x (amd64) platform after accepting the license agreement terms for it. Get it free here. Download the Web Interface on NetScaler package (nswi-1.3.tgz) below. This is a set up file for installing Web Interface on NetScaler. Download the 9.3 Release Build 47.5 below. Next, upgrade the NetScaler MPX or VPX to the 9.3_47.5.nc build below.

Web Interface on NetScaler requires installation of the Web Interface package (nswi-1.3.tgz) and the JRE version 1.6.0.7 for FreeBSD 6.x (amd64) platforms. These files install all the Web Interface components and JRE on the NetScaler hard drive, and configure automatic startup of the Tomcat Web server with Web Interface at NetScaler startup time.

Once the NetScaler upgrade to 9.3 Build 47.5 is completed, you are ready to install Web Interface on NetScaler. At the NetScaler command prompt, type:ns> install wi package -wi URL -jre URL

Example when files are remote from the NetScaler:install wi package -wi "sftp://username:password@10.102.47.4/var/nswi-1.3.tgz" -jre"sftp://username:password@10.102.47.4/var/diablo-latte-freebsd6-amd64-1.6.0_07-b02.tar.bz2"

or

install wi package -wi "http://10.102.29.12/nswi-1.3.tgz" -jre "http://10.102.1.14/diablo-latte-freebsd6-amd64-1.6.0_07-b02.tar.bz2"

Example when files are local on the NetScaler:

install wi package -wi "file:///var/tmp/nswi-1.3.tgz" jre "file:///var/tmp/diablo-latte-freebsd6-amd64-1.6.0_07-b02.tar.bz2"

From the NetScaler GUI, expand the System > Web Interface tab > Install Web Interface and browse to the location of the Web Interface on NetScaler package and the location of the JRE install file.

For detailed instructions on adding web interface site(s) and binding sites to the XenApp farm(s), reference the NetScaler Administration Guide 9.3 in the section Web Interface. Examples are provided using the NetScaler command line and the configuration utility (GUI).

61The feature is only licensed on NetScaler Standard, Enterprise, and PlatinumIt is not licensed on CAG-EENot visible in the GUI license window yetCitrix Confidential - Do Not DistributeWIonNS LicensingDraft 2JSP with JAVA Servlet supportFunctionally equivalent except for the authentication limitations listed belowCase sensitive sitesManual site customizationLimited on-box authenticationKerberos, Smart Card, RSA Windows Password Integration, or Pass-Through authentication methods are not supportedLimited Scale on low-end platforms

Citrix Confidential - Do Not DistributeLimitationsDraft 2Citrix Confidential - Do Not DistributeWIonNS Firewall Changes

BeforeAfterDraft 2Notes:The number of firewall configuration points are reduced since we have fewer port opening required.By following best practice guidelines, you can further reduce the SRC port requirements by using a LB Vserver for the XML/STA broker traffic64Lab 4 Web Interface on NetScaler

Objectives: Configure WI on NSDraft 265What are the pros/cons to WI on NS?Citrix Confidential - Do Not DistributeLab 4 DiscussionDraft 266Best PracticesDraft 2WI Load Balancing Cookie insert with timeout of 0XML Load Balancing No persistenceUse built-in WI/XML monitorDisable unused features and modesFor load balancing, have a Switch license

Citrix Confidential - Do Not DistributeIA Top 10Draft 2Load Balancing Configuration for Web Interface includes Least Connection as the Load Balancing Method with Persistence Cookie Insert with a timeout of 0. This ensures a session cookie is used for Web Interface without a manual timerLoad Balancing Configuration for XML/DDC should also use Least Connection as the Load Balalancing method but there should be no persistence configured.Use the Citrix built in Web Interface monitor and XML monitor to monitor the respective services behind the NetScaler. Ensure that the site name is specified correctly for Web Interface and an application is provided for the XML monitor. Its a good idea to have a dummy consistent monitor XMLDisable unused features and modes on the NetScaler.Ensure a Switch license is available along with the Access Gateway Enterprise License if features like Load Balancing are used.Redirection for the VPN Virtual Server from Port 80 to Port 443 should always be configured.GSLB for AGEE is recommended especially when the customer has multiple datacenters across various regions.End Point Analysis should be used in conjunction with smart access to distinguish between external clients using AGEE and internal clients using Web InterfaceSplit DNS should/can be used for internal access to the same VPN Virtual Server URL to automatically provide access to the Web Interface Server VIP (Load Balanced Configuration on the NetScaler) with external access referencing the public IP Address of the VPN Virtual Server. In general, internal access should never go through the AGEE VPN Virtual Server configuration.The NetScaler IP and Subnet IP Address should always be internal to the AGEE without direct external access. The AGEE can communicate with Web Interface server situated in either the DMZ or the internal network. Ensure appropriate firewall rules are in place for AGEE communication with Web Interface and DDC servers.

68Redirect 80 to 443 for AG vServerUse GSLB for multiple data centers across various regionsEPA used with SmartAccessUse split DNS for internal access to AGNo external access to NSIP and SNIP

Citrix Confidential - Do Not DistributeIA Top 10, continuedDraft 2Load Balancing Configuration for Web Interface includes Least Connection as the Load Balancing Method with Persistence Cookie Insert with a timeout of 0. This ensures a session cookie is used for Web Interface without a manual timerLoad Balancing Configuration for XML/DDC should also use Least Connection as the Load Balancing method but there should be no persistence configured.Use the Citrix built in Web Interface monitor and XML monitor to monitor the respective services behind the NetScaler. Ensure that the site name is specified correctly for Web Interface and an application is provided for the XML monitor. Its a good idea to have a dummy consistent monitor XMLDisable unused features and modes on the NetScaler.Ensure a Switch license is available along with the Access Gateway Enterprise License if features like Load Balancing are used.Redirection for the VPN Virtual Server from Port 80 to Port 443 should always be configured.GSLB for AGEE is recommended especially when the customer has multiple datacenters across various regions.End Point Analysis should be used in conjunction with smart access to distinguish between external clients using AGEE and internal clients using Web InterfaceSplit DNS should/can be used for internal access to the same VPN Virtual Server URL to automatically provide access to the Web Interface Server VIP (Load Balanced Configuration on the NetScaler) with external access referencing the public IP Address of the VPN Virtual Server. In general, internal access should never go through the AGEE VPN Virtual Server configuration.The NetScaler IP and Subnet IP Address should always be internal to the AGEE without direct external access. The AGEE can communicate with Web Interface server situated in either the DMZ or the internal network. Ensure appropriate firewall rules are in place for AGEE communication with Web Interface and DDC servers.

69/var/log/ns.log General Informationcat /tmp/aaad.debug pipe Authentication Issues when using AGEE or AAA VServer

Citrix Confidential - Do Not DistributeTroubleshooting

Draft 2Lab 5 Putting It All TogetherDraft 271AG Pre-Installation Checklist - http://support.citrix.com/article/CTX109588How to Configure a Backup VServer - http://support.citrix.com/article/CTX125511Configuring and Monitoring Persistence on NetScaler Planning Guide: Load Balancing Web Interface with NetScaler - http://support.citrix.com/article/CTX128563Does Use Source IP Mode Work in a NetScaler One-arm Mode Deployment? - http://support.citrix.com/article/CTX110459NetScaler VPX Licensing Guide - http://support.citrix.com/article/CTX122426Web Interface 5.3 Reports Error Pertaining to HTTP Header 'User-Agent - http://support.citrix.com/article/CTX124858Planning Guide: Load Balancing Web Interface with NetScaler http://support.citrix.com/article/CTX128563How to Configure the Redirect URL Feature - http://support.citrix.com/article/CTX108946

Citrix Confidential - Do Not DistributeReferenced LinksDraft 272Draft 273