| < Free Open Study > |
|
NFuse must demonstrate it can overcome several hurdles, including secure access to corporate applications through a public network, providing support for a wide variety of client devices and server platforms and providing a single point of access for all users.
NFuse provides some industry standard techniques for securing information across communication channels in addition to providing added security of its own, allowing secure communication between all three tiers. NFuse also provides a large number of client devices and server platforms to participate within this Web-enabled technology. In addition, server-side scripting and configuration can create a single point of access for all users connecting to NFuse.
Two important considerations that an administrator must consider before publishing applications via an Internet or intranet site are security and design. Designing a three-tiered solution should allow for efficient and secure access to published applications.
Using industry-standard security practices in addition to some Citrix-provided safeguards, administrators can provide robust security for all three communication tiers.
Many secure Web servers rely on a technology developed by Netscape Communications called Secure Sockets Layer (SSL). SSL is an open, non-proprietary, industry-standard Web protocol designed to provide secure server authentication, data encryption, message integrity, and optional client authentication. By combining the SSL technology with HTML, HTTPS was created. SSL and therefore HTTPS use the TCP port 443, by default, for its communications.
With NFuse, HTTPS can create a secure tunnel in which users can pass credentials posted in the NFuse login page. All items passed between the Web server and Web browser travel through this secure tunnel, including ICA files, cookie information, and HTML data.
Virtually all Web servers and Web browsers are optimized to use HTTPS. The use of HTTPS is transparent to both NFuse and the Web browser, so no special configuration is required. For more information on how to implement HTTPS on a Web server, visit: http://www.verisign.com.
Previous versions of NFuse, by default, placed user credential information within the ICA file it sent to the ICA Client devices. An attacker, able to intercept the file, would be able to use the ICA file to gain access to a Citrix server. Enabling the ticketing technology eliminates this risk. By default, all custom Web sites built with the Web Site Wizard have ticketing enabled.
All Citrix MetaFrame XP for Windows 1.0 servers support the ticketing technology. All Citrix MetaFrame for Windows 1.8 must have SP2 and FR1 licensed and activated for ticketing to function. Citrix MetaFrame for Unix Operating Systems 1.1 does not support ticketing at this time. In order for ticketing to work, all servers in the server farm must have ticketing support.
Ticketing works like this:
When a user selects an application to run from the NFuse application set page, the Web servers NFuse Java objects request from the server farm a ticket for that user. (A ticket is a 30-character string generated by the server farm that correlates the user to their credentials but does not contain the credentials themselves. Tickets have a configurable expiration time and are valid only for a single ICA session.)
The server farm passes this ticket to the Web server.
The Web server places this ticket in the ICA file sent to the ICA Client device.
The ICA Client authenticates itself to the server farm using the ticket.
The server farm compares the ticket to the user's actual credentials and if it matches, will log the user in.
SSL Relay works much the same as the SSL technology enabled between a Web server and a Web browser except that now the secure tunnel is being passed between the Web server and a Citrix server farm. SSL Relay is a default component of Citrix MetaFrame XP for Windows 1.0 and Citrix MetaFrame 1.8 with SP2 and FR1 licensed and activated. By default, SSL Relay uses TCP port 443 for its SSL communication.
To install and configure SSL Relay on a Citrix server, use the Citrix SSL Relay Configuration Tool. On a Web server, a Web site must be configured to use SSL Relay. This information is configurable when creating a custom Web site with the Web Site Wizard.
SSL Relay works like this:
The Web server first verifies the identity of the SSL Relay server by checking the SSL Relay server's certificate against a list of trusted certificate authorities.
Once this has completed, the Web server and the SSL Relay server negotiate an encryption method for the session.
The Web server then sends all information requests to the SSL Relay server encrypted.
The SSL Relay server decrypts the requests and passes them to a configured Citrix server.
The Citrix server passes all information requested back to the SSL Relay server.
The SSL Relay server passes all request information back to the Web server for decryption.
RC5 is an encryption algorithm that Citrix employs to encrypt session information from ICA Client devices to Citrix MetaFrame for Windows servers. RC5 encryption uses the RC5 encryption algorithm developed by RSA Data Security, Inc. and the Diffie-Hellman key agreement with a 1024-bit key to generate RC5 public and private keys. RC5 encryption supports 40-, 56-, and 128-bit encryption that can be enforced by Citrix administrators on a per-connection basis. In addition, minimum encryption levels can be used to enforce encryption if a connection is to be made.
Clients that support RC5 encryption include: all version 6.0 clients or later, ActiveX Control, 16-bit Plug-in, 32-bit Plug-in, DOS32 and DOS16.
A firewall is a security system installed within a network. It prohibits any kind of information that is not authorized to pass from one network to another, chiefly the public Internet and a private network.
To use Citrix, several ports must be opened on a firewall for certain communication to work. Commonly, port 80 for HTTP traffic, port 443 for HTTPS traffic and port 1494 for ICA session traffic are all opened on a firewall for inbound access.
Exam Watch | Make sure you know the ports that need to be opened up on a firewall for proper communication to work |
Most firewalls have the ability to use a technology called Network Address Translation (NAT). Using NAT with Citrix, each MetaFrame server receives an alternate IP address. Only ICA Clients that know the alternate address will pass through the firewall. In addition, only those ICA Clients that request the alternate address will be able to connect successfully.
To assign an alternate address, the command altaddr is used. For example: altaddr/set 4.60.224.251.
Designing the three tiers effectively can result in better performance when it comes to running applications remotely.
The bandwidth requirements between a Web server and a Citrix server farm are generally not heavy, but can make a difference in overall performance. If possible, have the Web server and the Citrix server farm running on the same local area network (LAN). If the Web server and Citrix server farm must be separated by a wide area network (WAN) link, ensure that the link speed is at least 128K, allotting a minimum 64K of the bandwidth for ICA connection traffic.
The bandwidth requirements between an ICA Client device and either a Web server or Citrix server farm are minimal. A 14.4k modem is required, but a 56K connection or better is recommended.
On The Job | Frame Relay, DSL, or ISDN operating at the same 56k speed as a modem will be far faster due to the 12-15 percent overhead that 56K dial-up users may experience. |
When possible, dedicate a separate server to act as the Web server. Citrix servers are designed to host applications with as little unnecessary overhead as possible, and by running the Web services on the Citrix server, precious resources are being used.
This first design scenario concerns a small implementation that hosts applications via an NFuse Web site on their Intranet. Because of money constraints, this is a single server solution, where the Web server and Citrix MetaFrame XP for Windows 1.0 server have been installed on the same machine (see Figure 11-15).
Figure 11-15: An example of a small NFuse deployment
All traffic is passed on the LAN. No special security considerations are necessary in this configuration.
The Citrix server will have more overhead introduced onto it because the Web server is also hosted on the same machine. No special bandwidth considerations are needed because all traffic is kept within the LAN.
The second design scenario has been built to host published applications via an NFuse Internet site. Within this scenario, ten Citrix MetaFrame XP for Windows 1.0 servers comprise a single farm on the same LAN as a single Web server running IIS 5.0 with the NFuse Web Extensions and an SSL digital certificate (see Figure 11-16).
Figure 11-16: An example of a medium-sized NFuse deployment
Traffic passing between remote locations through the public Internet and the corporate LAN are a reason to implement a firewall in this scenario. Ports on the firewall that will need to be opened for inbound communication are TCP ports 80 for HTTP, 443 for SSL, and 1494 for ICA traffic. In addition, to ensuring secure communications between the ICA Client device and the Citrix servers, RC5 encryption will be used.
A separate Web server has been introduced to take the burden off a Citrix server from incurring the overhead introduced. All traffic between the Web server and Citrix servers is on the LAN, so no bandwidth concerns are introduced.
In this final scenario, published applications will be presented via an NFuse page for remote connectivity through the public Internet. On the back end, a single Web server runs Windows 2000 with IIS 5.0 and the NFuse Web Server Extensions, while an SSL digital certificate resides on the same LAN as two separate twenty-server Citrix server farms running Window 2000 with Citrix MetaFrame XP for Windows 1.0. The NFuse Web site has been configured to allow the application sets of two farms to appear in one page (see Figure 11-17).
Figure 11-17: An example of a large NFuse deployment
An SSL digital certificate has been installed on the Web server to allow secure traffic between the ICA Client devices and the Web server.
A firewall has been installed to further secure all communication between remote clients and the corporate LAN. Ports open on the firewall are TCP ports 80 for HTML, 443 for SSL, and 1494 for ICA traffic.
NAT is being used for additional firewall security.
Between the Web server and the Citrix servers, an SSL Relay server has been configured on both server farms, enabling encryption between the Web server and the Citrix servers.
Ticketing has been built into the Web site so secure authentication information can be passed between all three tiers.
128-bit encryption has been set as a minimum requirement for all ICA communication between the ICA Client devices and the Citrix servers.
A separate Web server has been installed to take the burden off a Citrix server from incurring the overhead that would be introduced from the HTTP and SSL traffic.
Two Citrix server farms exist, one local to the Web server and one remote. The traffic that will pass between the Web server and remote Citrix server farm has created the need for a WAN link. The WAN link used in this scenario is 384K to allow for expansion.
To allow for secure communication between the Web server and the two server farms, especially the remote server farm, a single SSL Relay server has been set up on each of the Citrix server farms.
In order for SSL to work through a firewall, what port must be opened? | TCP port 443 |
HTTP (Web) traffic uses what port by default? | TCP port 80 |
What program do you run to configure the SSL Relay on a Citrix server? | Citrix SSL Relay Configuration Tool |
Now that designing the three tiers has been covered, here are some possible scenario questions and their answers:
One of the benefits of the Citrix NFuse technology is that it can be run on nearly any device on virtually every platform. The following section lists the minimum requirements for each of the three Citrix Web components.
NFuse supports the following MetaFrame platforms:
Citrix MetaFrame XP for Windows version 1.0
Citrix MetaFrame for Windows version 1.8
Citrix MetaFrame for Unix Operating Systems version 1.1
Additional software requirements for Citrix MetaFrame for Windows version 1.8 servers:
Citrix MetaFrame 1.8 servers must have SP2 installed
Citrix MetaFrame 1.8 servers must have an installed and activated Feature Release 1 (FR1) license
Additional software requirements for Citrix MetaFrame for Unix Operating Systems version 1.1:
The Citrix XML Service for Unix Operating Systems must be installed on at least one server in the farm. This server will act as the primary contact point between the Web server and the server farm
Optionally, additional servers may have the Citrix XML Service installed. These will act as backups for the primary server.
General requirements:
Citrix MetaFrame servers must be a part of a server farm.
They must have published applications that are created in the server farm management scope.
On The Job | During installation, the option to install NFuse on the Citrix server is presented. This will only install, however, if the server is running IIS 4.0 or IIS 5.0 and the Microsoft Java Virtual Machine (JVM). |
NFuse is supported on the following Web server/platform combinations as seen in Table 11-2.
Web Server | Platform |
---|---|
Microsoft Internet Information Server 4.0 | Windows NT 4.0 Server, Windows NT 4.0 Terminal Server Edition |
Microsoft Internet Information Server 5.0 | The Windows 2000 Server family |
Netscape Enterprise Server 3.6 | Solaris 7, Solaris 8 |
iPlanet Web Server 4.0 with Service Pack 4 | Solaris 7, Solaris 8 |
iPlanet Web Server 4.1 | Solaris 7, Solaris 8 |
Apache Server 1.3.9 | Red Hat Linux 6.0, Solaris 7 and Solaris 8 using Sun Java Development Kit 1.2.2, Apache Jserv 1.1, and GNUJSP 1.0 |
This is a list that contains all tested and supported Web server/platform combinations. It may be possible, however, to use other Web servers that support Java servlets and/or JavaServer Pages.
To use NFuse, the ICA Client device must be using a supported Web browser in combination with a supported ICA Client. All ICA Clients that ship on the ICA Client CD are supported, with the exception of ICA Clients that cannot be launched with a Web browser (an example would be any of the ICA DOS clients).
Additionally, some previously released ICA Clients are capable of running NFuse. Table 11-3 lists all the ICA Clients and Web browsers supported.
ICA Client | Version | Supported Web browsers |
---|---|---|
Win32 | 4.21.779 and later | Netscape Navigator 4.01 and later, Internet Explorer 4.0 and later |
Unix | 3.0 and later | Netscape Navigator 4.01 and later, Netscape Communicator 4.61 and later |
Linux | 3.0 and later | Netscape Navigator 4.01 and later, Netscape Communicator 4.61 and later |
ActiveX Control | 4.21.779 and later | Netscape Navigator 4.01 and later, Internet Explorer 4.0 and later |
Netscape Plug-in | 4.21.779 and later | Netscape Navigator 4.01 and later, Internet Explorer 4.01 and later |
Win16 | 4.21.779 and later | Netscape Navigator 4.08 and later, Internet Explorer 4.01 and later |
Java-Applet | 4.11 and later | Netscape Navigator 4.01 and later, Internet Explorer 4.0 and later |
Java-Application | 4.11 and later | Netscape Navigator 4.01 and later, Internet Explorer 4.0 and later |
Macintosh | 4.10.23 and later | Netscape Navigator 4.01 and later, Netscape Communicator 4.61 and later |
Providing users with a single Web page from which they can access their applications has many benefits; one of which is a single point of access for published applications. With NFuse, Web server-side scripting can allow all ICA Client options to be configured using server-side scripts and custom-created ICA files. Users with local ICA Clients no longer need to configure server location information to access their application sets.
To allow users to connect to published applications via the LAN through an NFuse Web site, no special configuration is needed with any of the three NFuse components. In this example, an ICA Client device connects to a single server running both the NFuse Web component and the Citrix server component (see Figure 11-18).
Figure 11-18: An example of a single server LAN deployment
By creating a custom Web site using the NFuse Web Site Wizard, with no special configuration being done on either the Web side or Citrix server side, the following ICA file is presented to the ICA Client device to initiate an ICA session (see Figure 11-19).
Figure 11-19: The customized ICA file for a single server deployment
In this second example, an ICA Client device connects to a remote NFuse Web site through a firewall where it receives its published application information (see Figure 11-20). Security is a concern in this scenario, so the administrator has required a minimum of 128-bit encryption for any published application to be launched.
Figure 11-20: An example of a single server deployment through a firewall without NAT
As can be seen in Figure 11-21, the ICA file passed to the user in this scenario contains the external address of the server, 4.17.233.25, in addition to adding a new ICA parameter, EncryptionLevelSession=EncRC5-128.
Figure 11-21: A customized: ICA file requiring 128-bit encryption
In the third scenario, an ICA Client device connects to a remote NFuse Web site through a firewall using NAT. All applications have been configured to require 128-bit encryption as a minimum (see Figure 11-22).
Figure 11-22: An example of a single server deployment through a firewall with NAT
For the ICA Client device to communicate successfully with the Citrix server, the ICA Client must request the alternate address of the Citrix server. Should the ICA Client not request the alternate address, the Web server would create an ICA file that would identify the Citrix server at 192.168.0.192. This is a non-routable IP address, and the connection would fail. Instead, if the ICA Client were to request the alternate address to be given, the Web server would generate an ICA file with the Citrix server's alternate address, and communication between the two would be successful.
A change must be made to the template.ica file within the NFuse Web site to force ICA Client devices to request alternate addresses. Replace the line: Address=[NFuse_IPV4Address] with Address=[NFuse_IPV4AddressAlternate].
Exercise 11-2: Configuring NFuse to Use an Alternate Address
This exercise will demonstrate how to configure NFuse to specify an alternate address for remote ICA Client devices.
Run the altaddr command on the Citrix server to specify an alternate address. The syntax is: altaddr /set AlternateIPAddress (see Figure 11-23).
Figure 11-23: Running the altaddr command
Locate and edit the template.ica file within your NFuse Web site.
Locate the line that reads: Address=[NFuse_IPV4Address] (as seen in Figure 11-24).
Figure 11-24: The template ICA file before alternate address support
Replace it with: Address=[NFuse_IPV4AddressAlternate] (as seen in Figure 11-25).
Figure 11-25: The template ICA file after alternate address support
Exam Watch | It is important to know how, why, and when you would need to specify an alternate address. |
The NFuse objects are Java objects that are Component Object Model (COM) compliant. COM is a method for different software components to communicate with one another, regardless of hardware, operating system, or language being used.
Java objects perform the following tasks:
Authenticate users to a Citrix server farm
Retrieve application set data from a server farm per-user
Provide the capability of modifying properties of any published application before presenting them to users.
Create dynamic Web pages with application set information and hyperlinks to allow the ICA Client device to launch ICA sessions.
Table 11-4 lists the NFuse Java objects and their corresponding functions:
Java Object | Description |
---|---|
CitrixWireGateway | Creates a communication link between the Web page requesting a user's application information and the server farm containing the applications. |
ClearTextCredentials | Encapsulates user credentials for transference to the server farm. |
GroupCredentials | Contains a list of group names with an associated domain for use in retrieving applications for user groups. |
AppEnumerator | Provides an interface for accessing a user's application set information. |
App | Represents a single application in the application set and contains the properties of an application. |
AppSettings | Represents an application property container that allows property modifications to be made. |
AppDataList | Contains a list of App objects that can be quickly accessed to determine application set lists for users. |
AppListCache | Caches AppDataList objects on a Web server so the Citrix server farm does not need to be repeatedly contacted. |
TemplateParser | Performs the substitution tag processing on text files. This allows for the customizing of ICA files before being presented to users. |
The two most common questions I hear regarding Citrix MetaFrame are: What is NFuse, and What are the benefits of using it? With the robust features of NFuse combined with the solid foundation of the Citrix MetaFrame technology, most new (and current) MetaFrame deployments should take a hard look at what NFuse can do for them.
One of the largest and perhaps most important feature of NFuse in my mind is the consistency of the environment. In a mixed computing environment where Unix workstations, desktop PCs running DOS, 16- and 32-bit Windows, and Macintoshes reside, with NFuse deployed, you have a single, consistent portal to access all of your applications no matter where you are. The single largest praise I have heard about NFuse to date has been that accessing the applications from home in the same manner as in at work is an absolute blessing.
Web-based ICA Client installation is another large factor in the ease of using the environment. Little to no work is needed on nearly every platform supported to get up and running with your published applications in little time.
The ease of use ties in with the consistency of the environment. Most people know how to surf the Internet. Because of this, they need little to no additional training to run their applications from any device capable of supporting NFuse.
Secure, quick responding applications for remote access users. With all of the security features that can be tied in with all three tiers of the NFuse model, gaining access to your applications from anywhere, with very little threat of compromising corporate data, is another large plus for NFuse.
For large enterprises, the need for Web- enabling many of the existing applications becomes a moot point. Corporations no longer need to spend thousands of dollars and man-hours working to rewrite applications for Web access.
It's free! If you already operate a Citrix MetaFrame environment that is running under a supported platform, NFuse can be easily integrated at no additional cost!
NFuse has support for many additional advanced functions. The most popular implementation of one of these advanced features is the multiple farm display. A single NFuse page can combine application data from multiple farms.
These benefits, I believe, justify NFuse to be used in almost every situation of any new MetaFrame deployment. With all of the current capabilities of NFuse, this free technology alone can make a very strong point for deploying Citrix MetaFrame in any environment, and it's only going to get better.
-Craig Luchtefeld, MCSE, MCP+I, CCEA
| < Free Open Study > |
|