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:
1) Assessment
2) Design
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.
Resource Delivery
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 Considerations
In 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 Architect
Simplifying 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 Design
Some 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 Architect
Appropriately 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 Architect
Architects 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?
VPN Access
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 Mode
A 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 Architect
Because 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 Mode
A 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 Architect
Two-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 Availability
Architects 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. 
No comments:
Post a Comment