This is my 50th blog. A milestone for me.
Lets refresh where we are! We are discussing about architecting a Citrix environment from Architects perspective. There are 2 parts to it:
Assessment is further divided into
Design is further divided into
· Access Design
· Delivery Optimization
In this blog, we will discuss design of Access Design .
During the design of the virtualization environment, the architect must design the access strategy for applications and desktops. The design should focus on easy and secure access to resources by internal and, potentially, external users.
Resource Access Design Scenario
A Citrix Certified Integration Architect has been given the task of designing a desktop virtualization solution for a company. After completing the design, the architect was asked to design a solution for users accessing those resources internally.
During the assessment, the architect documented the following information:
- The solution must be redundant and easy to use.
- The transition to virtual desktops should be as seamless as possible and require minimal user training.
- Users should be able to access published applications through desktop icons, like they currently do.
- Administrators should be able to access production and test XenDesktop and XenApp farms.
- Users should not be aware that they are using XenDesktop hosted desktops and should not be able to access the native endpoint desktop.
- Servers will be members of the organization domain.
- Web servers should be load balanced with a hardened solution.
An architect can use the information gathered during an assessment and the information in the following topics to assist in designing an access solution.
For many organizations, a XenApp website is the access point for virtualized resources. Architects must determine whether the design should allow users to access both virtual desktops and applications from a single URL or whether the use of multiple URLs is acceptable.
Single URL Design Considerations
Architects may recommend a single XenApp Web or XenDesktop Web site that aggregates both applications and desktops. This option provides a completely integrated solution that allows the users to decide if they want a full desktop or just need an application. With a single site for desktops and applications, all users, regardless of whether they have access to a virtual desktop or not, will use the same URL. With a single site design, there is a chance that a user may navigate to the XenApp Web of XenDesktop Web site within the virtual desktop and launch another virtual desktop session. This risk can be mitigated by using the Citrix XenApp plugin to launch virtualized applications within virtual desktops.
A recommended best practice is to pre-install the Citrix XenApp plugin in virtual desktops. If the user launches a virtual desktop, the Citrix XenApp plugin will automatically connect to the XenApp Services site and enumerate the user's set of applications. However, enabling Workspace Control can cause a feedback loop that essentially breaks the ICA connection in a single-site Web Interface design. When a user launches a virtual desktop, the Citrix XenApp plugin starts automatically and authenticates to the Web Interface. The Citrix XenApp plugin then initiates a Workspace Control trigger that attempts to move the user's ICA session from the physical client device into the virtual desktop session, ultimately breaking the user's connection to the virtual desktop. This potential issue can be overcome by not aggregating XenApp Services and XenDesktop Services sites or by using a multiple web site design.
Multiple URL Design ConsiderationsIn a multiple site design, users access one site for desktops and another site for applications. Users connectsto the desktop site and are presented with their virtual desktop. Upon connection to their virtual desktop, the Citrix XenApp plugin automatically receives the available applications from the XenApp Services site. The second site helps reduce confusion for virtual desktop users because it only contains applications and eliminates the risk of a user starting a virtual desktop from within a virtual desktop. The multiple site design places an additional burden on users as they will need to remember different web addresses or processes.
Although two different sites are created for each resource type, this does not require additional Web Interface servers. A single Web Interface server can include numerous site configurations.
From the ArchitectSimplifying the access to the virtual desktop infrastructure is critical in order for users to easily and quickly access their resources and can be critical for user acceptance and broad adoption of desktop virtualization within the organization. However, some user training may be necessary if the environment design dictates new user behavior. For example, users who typically launch applications through a XenApp Web site may require training on launching applications through a Citrix XenApp plugin when using virtual desktops.
Web Interface Load Balancing Considerations
Regardless of whether architects recommend a single or multiple Web Interface site design, simply directing users to a Web Interface address could result in users going to a failed server. To prevent this, Web Interface servers should be load balanced.
A hardware load balancing solution such as Citrix NetScaler typically provides the best performance and scalability. When properly configured, a hardware load balancer not only load balances traffic, but also validates Web Interface server availability before directing traffic. If a hardware load balancer cannot be used, the organization should consider Microsoft Network Load Balancing (NLB). Unlike round robin DNS (RRDNS), NLB load balances traffic based on NIC traffic loads.
Load balancing can be done with RRDNS, although this solution does not validate that the Web Interface is functioning before directing the user to the serv
External Access DesignSome members of the user community may be remote and need to connect over public and unsecured Internet links. These users have the same requirements as internal users and should have the most appropriate delivery approach possible regardless of whether a virtual desktop or application is needed. Because these users are external to the environment and connecting over unsecured links, architects should design a solution that provides secure access to virtualized resources through an SSL VPN appliance such as Access Gateway.
From the ArchitectAppropriately determining an organization's access scenarios is crucial to both the design of the Access Gateway implementation and the success of the remote access project. Architects should be thorough when identifying the environment's requirements and explaining how Access Gateway automatically can provide the appropriate level of access depending on parameters such as the user, device or connection location. When designing the appropriate solution, architects should describe the user connection process for each access scenario that will be implemented.
Citrix Secure Gateway Mode
Access Gateway can be configured in Citrix Secure Gateway (CSG) mode to function as an SSL proxy device for ICA traffic. CSG Mode can be appropriate for securing external access to XenDesktop hosted desktops and XenApp applications. However, this configuration does not provide VPN access into the network, so users will not be able to access any internal resources beyond those hosted on XenDesktop and XenApp.
Although a Web Interface-only configuration is inherently more restrictive, organizations may want to set ICA virtual channel restrictions for connections coming from unmanaged devices. For example, if a user does not have the latest antivirus software, that user might be granted access to published applications, but cannot map client drives within XenApp sessions. Architects should determine whether the organization requires endpoint analysis scans, which can restrict virtual channels such as client drive mapping, client printer mapping and clipboard mapping.
From the ArchitectArchitects should recommend CSG mode for all users, except for administrators and any other group that might require VPN access. CSG mode provides secure, encrypted remote access for XenDesktop and XenApp ICA connections without the complexity of configuring VPN access for the environment. CSG mode also allows the Access Gateway to easily co-exist alongside any other VPN solution used within the organization.
Access Gateway or Secure Gateway
Both Access Gateway and Citrix Secure Gateway can function as an SSL proxy device for ICA connections to virtual desktops and applications. Access Gateway is a hardened SSL VPN solution available as a hardware appliance or virtual machine. Secure Gateway is a software-based SSL proxy that runs on Microsoft Windows Server operating systems. Depending on the appliance model, Access Gateway can support as many as 10,000 concurrent SSL connections. Due to SSL overhead and connection persistence, Secure Gateway is limited to 1,500 concurrent connections total.
Citrix Secure Gateway provides SSL encryption only for ICA connections. Unlike Access Gateway, Secure Gateway does not support VPN access.
From the Architect
Access Gateway generally is recommended over Secure Gateway as it is a hardened appliance providing better security and greater scalability. However, architects can use the following types of questions to design the appropriate solution:
- How many external users may connect to the environment concurrently?
- Does the organization currently have a VPN solution?
- Can Access Gateway appliances be purchased?
- Is VPN access required for any users?
- Can servers running Windows Server be deployed in the DMZ?
Full VPN access scenarios are often appropriate for employees connecting remotely using managed devices, such as corporate laptops, or users requiring varying, unpredictable access to numerous internal network resources. VPN access allows users to work remotely while providing the same level of access and a similar user experience as working locally on the network.
Even though users should be connecting from managed devices, an organization may want to implement endpoint analysis scans to verify domain membership, check for a particular antivirus version or scan for some other type of requirement before allowing access. Users who fail an endpoint analysis scan may be quarantined and provided access to only limited resources. For example, users who fail an antivirus endpoint analysis scan may be provided with access to an antivirus server, where they can obtain the latest antivirus version. For more information about Access Gateway VPN access and endpoint analysis scans, see Citrix Education course CAG-200-1I Implementing Citrix Access Gateway 9.0 Enterprise Edition.
Access Gateway Deployment Modes
Access Gateway offers architects flexible options for deploying the appliance into an existing network. In general, the organization's networking team will dictate how Access Gateway is deployed based on the existing network design. Typically, the goal should be to minimize any network redesign or interruption.
One-Arm ModeA one-arm deployment uses only one NIC or NIC bond on the Access Gateway appliance. The Access Gateway connects to a switch in the DMZ and all traffic enters and leaves through the same physical interface. In this scenario, the backend resources that are logically located behind the Access Gateway are directly accessible from endpoints within the DMZ. Only incoming connections from outside the DMZ are directed through Access Gateway
From the ArchitectBecause one-arm mode deployments require only one subnet and average networking knowledge, they are ideal for simple network designs, Access Gateway proof of concepts and pilot projects. A downside of one-arm deployments is that the single NIC or NIC bond must share the traffic volume of all incoming and outgoing traffic requests, which potentially can result in a slower response time. However, this can be mitigated with link aggregation.
Two-Arm ModeA two-arm, or inline, deployment uses two NICs or NIC bonds on the Access Gateway appliance. One interface of the Access Gateway connects to an external-facing switch or router in the DMZ, and a second interface connects to an internal-facing switch or router in the DMZ. Traffic enters the Access Gateway through the external interface and leaves through the internal interface. In this scenario, the backend resources that are physically located behind the Access Gateway are indirectly accessible. Incoming connections from within the DMZ are directed through Access Gateway
From the ArchitectTwo-arm mode deployments enable better traffic segregation and often are used in production environments and sophisticated network designs. While two-arm deployments typically use two different subnets for the external and internal IP addresses, Access Gateway supports single-subnet, two-arm designs.
Web Interface Deployment Considerations
The Web Interface server can be deployed in the DMZ behind the Access Gateway or within the internal network. If Web Interface servers are deployed within the DMZ, these servers should be located logically behind the Access Gateway so that all incoming external connections must be directed through Access Gateway. Alternatively, the Web Interface servers can be deployed within the internal network, which would allow internal endpoints to contact the Web Interface servers directly without crossing the internal firewall into the DMZ.
If Web Interface servers are deployed within the internal network, authentication should occur on the Access Gateway appliance. Otherwise, if authentication is disabled on the Access Gateway, users will be directed to the Web Interface servers in the internal network before they have been authenticated, which may be a security risk
High AvailabilityArchitects should ensure that the access design provides redundancy and high availability for all components. Access Gateway appliances should be deployed as a high-availability pair. Several Web Interface servers should be deployed for high availability as well. In addition, Multiple Secure Ticket Authority (STA) servers should be specified on the Access Gateway appliance and within the Web Interface settings. Several XML servers also should be specified within the Web Interface settings.