Client Device Security - Citrix MetaFrame XP

Client devices often pose one of the biggest security risks because they are inherently the least secure.

Client devices often pose one of the biggest security risks because they are inherently the least secure. This stems from the fact that clients are scattered throughout the world and are generally unprotected. Poorly configured client devices are much more susceptible to a security breach then a network connection any day.

The main thing that people worry about concerning client devices are the "leave behinds." These are the remnants of a MetaFrame XP ICA session that can be left on a client device after a user is done using it, potentially allowing other users to access the same MetaFrame XP ICA sessions with the permissions of the first user.

Another security risk associated with client devices is that often users are able to change the settings of their clients. While this doesn't usually allow them to access things that they normally wouldn't be able to, it does increase the risk that they could change a setting and lessen the security of their client device.

Saving User Credentials on ICA Client Devices

It is possible for ICA clients to be configured to save the user's credentials so that a user does not have to type in his username and password each time his ICA client is launched. When a user saves his user credentials, the credentials are encrypted and written to an INI file (appsrv.ini for custom connections and pn.ini for application sets) on the client computer.

While it is generally not possible to decrypt the credentials stored in these files, it is possible that the files could be used by another user to gain the access rights of the first user. These INI files are stored in each user's profile. If a non-secure operating system is used, like Windows 98, any user could copy the files from one user's profile into his own. They could then connect to MetaFrame XP servers as the original user. Even worse, an advanced attacker could use the credentials saved in the INI configuration files to create ICA sessions to other MetaFrame XP servers.

Saving User Credential Security Risks

  • User credentials could be compromised.

If security is a top priority in your environment, you should not allow your users to save the credentials for their ICA client applications.

Using Local ICA Files to Connect to ICA Applications

ICA files are a convenient way to allow users to access MetaFrame XP servers and published applications-especially when those users are connecting from different computer networks in many locations. Often it is easy for an administrator to send a remote user an ICA file, encouraging them to "just double-click the file" to launch their ICA session.

Because many of these remote users are often in different domains than the MetaFrame XP servers, it is tempting to embed the logon credentials into the ICA file to prevent the user from having to enter a second set of credentials to launch the ICA application.

As with all aspects of computing, ease-of-use is inversely proportional to security. In this case, you need to carefully evaluate the security risk of passing out ICA files with embedded logon credentials. Remember that once ICA file is given to an end user, it could end up anywhere. Because the file will automatically launch an ICA session, end users tend to pass these files to each other. This can enable other users to get access to inappropriate applications.

Since ICA files are easy to edit and understand, it is easy to modify an ICA file to point to another server or application and to use the embedded user credentials to log onto that server or application.

Local ICA File Security Risks

  • Not secure.
  • End users can pass the files to friends.
  • Files can be modified to use the embedded credentials to connect to other applications or servers.

If you want to create the most secure environment possible, you should not pass out preconfigured ICA files to anyone. Ever.

Pass-Through Authentication

Pass-through authentication allows users with Windows clients to start Program Neighborhood without having to retype their usernames or passwords. When pass-through authentication is enabled, the Citrix ICA client software is able to extract their user credentials from the local workstation.

While pass-through authentication seems convenient, there are several issues that must be considered. The main security risk is derived from the manner in which pass through authentication works. At logon time, a process called ssonsrv.exe is started with three command-line parameters: username, domain, and password. These parameters are not encrypted, and any shareware debugger program can be used to view them.

The second issue with pass-through authentication has to do with the method by which it determines the current logged on user. The pass-through authentication engine looks at the last logged on user when Program Neighborhood is started. The problem with this is that some interactive services confuse the pass-through authentication service. For example, if SMS is installed, the SMS client service can sometimes start (and log on) after the user logs on. When this happens, the Citrix pass-through authentication engine will use the SMS account instead of the user account to log in to Program Neighborhood. In some cases the SMS account has more rights than the user, allowing users to launch inappropriate ICA sessions as that account.

Pass Through Authentication Security Risks

  • User credentials can be exposed.
  • Doesn't always work.

Even if you disable pass-through authentication on a client, there is a chance that the user could re-enable it. To prevent this, you should either install the "gray version" of Program Neighborhood (described next), or delete the files that pass-through authentication uses. These files are ssoncom.exe, ssonstub.dll, and ssonsvr.exe. They are located in the ICA client installation directory.

Preventing Users from Changing Their Client Settings

One of the big security problems with ICA clients is that users can change the settings of their client software. For example, even if it is your policy not to save passwords, users can access the options menu and change that option. In fact, just about everything in your ICA client can be changed or modified by the end user. Fortunately, there are a few tricks that MetaFrame administrators have learned over the years that will prevent users from breaking their ICA clients. These can be broken into two options/

Option 1. Do Not Use a Full Program Neighborhood ICA Client

The easiest way to prevent users from changing client settings is to use an ICA client that does not have a local Program Neighborhood interface. This would include the web clients that are used with NFuse or the Program Neighborhood Agent. With both of these clients, the configuration information is maintained and controlled on the NFuse web server, where local users cannot access it or change it. See Chapter 11 for the full details of these two clients.

Advantages of Not Using the Full Program Neighborhood

  • You can enforce client settings with no loopholes.
  • NFuse is becoming the de facto standard for accessing MetaFrame environments.

Disadvantages of Not Using the Full Program Neighborhood

  • An NFuse server is required.
  • Program Neighborhood Agent requires Feature Release 1 and Windows 32-bit clients.

Option 2. Use the "Gray Version" of Program Neighborhood

Another easy way to prevent users from being able to change ICA client settings is to remove their ability to set anything via the menus of Program Neighborhood. If configuration menu items are "grayed out," the users will not be able to change anything. In order to do this, you can download a "gray version" of Program Neighborhood. This gray version has all of the configuration menu items disabled.

The gray version of Program Neighborhood is available from Jim Kenzig who edits the regular pn.exe file and disables certain menu items. He posts the gray version With the download, you simply get one file: pn.exe. To use it, replace the client's original pn.exe with the newly-downloaded version. There is a different gray version pn.exe for each ICA client version.

Of course, once you copy over the original pn.exe with the gray version, you will not be able to make any configuration changes on that client via Program Neighborhood. If you need to make changes after you install the gray version, you can either edit the INI files directly or temporarily use the original pn.exe. (You should probably name the original executable something like goodpn.exe so it's there if you ever need to make a change.) See Chapter 10 for the details of ICA client configuration.

The gray version of Program Neighborhood is not technically supported by Citrix, but they don't seem to mind it. It's kind of a "don't ask, don't tell" thing. In the real world, probably 75% of companies that use the full Program Neighborhood client replace the default pn.exe with the gray version.

One thing that's important to keep in mind when using the gray version of Program Neighborhood is that users can still change their settings if they edit the INI files directly. The gray version of Program Neighborhood simply removes the GUI interface (and the easy way) for changing client settings.

Advantages of Using the Gray Version of Program Neighborhood

  • Easy to use.
  • No additional cost.
  • Works with any version of MetaFrame.

Disadvantages of Using the Gray Version of Program Neighborhood

  • Users can get around it by editing INI files.
  • Users can get around it by downloading a new ICA client.
  • Not "technically" supported by Citrix.

Client Web Browser Security

Today, most MetaFrame XP environments are accessed through NFuse web portals which means that the client devices connect via a web browser. In order to secure the client devices in these situations, you need to look at ways to secure the local client web browser. There are means by which this can be accomplished:

  • Understand browser cookies.
  • Use NFuse ticketing.
  • Remove credentials from ICA files.
  • Prevent browsers from caching ICA files.
  • Permit users to only connect from certain IP addresses.
  • Control the amount of access that remote MetaFrame XP applications have to local client drives through web browsers.

Understanding Browser Cookies

Client-side browser cookies might seem like an easy way to remember a user's credentials from page to page within NFuse-based websites that you create, but be aware that cookies are generally not secure. There are two areas of concern with browser cookies.

The first concern is a factor if an NFuse website stores permanent cookies on the client device. Many websites use these types of cookies to automatically log users in when they connect to a site. If these cookies are used in an NFuse environment, it's possible that anyone who accesses the website will be automatically logged in with the stored cookie information. By default, NFuse does not do this. If you change the NFuse web pages to allow this, you need to be aware of the security risks that it introduces.

The other concern with cookies is the data (user credentials) stored within the cookies. Because it's possible that someone could read the values of the stored cookies, usernames and passwords could be compromised. Again, this is not a risk with the default NFuse pages, but if you create your own NFuse web pages it's best to maintain user information from page to page without using client-side cookies, such as using web server session variables.

The default web pages that come with NFuse 1.7 do use client cookies to hold user credentials during their visit to the web site. Fortunately, those default pages use a 512-bit session key to encrypt the visitor's password. That password encryption process is very interesting and worth studying. Here's how it works:

Figure 15.19: NFuse encrypted cookie creation

  1. When the web browser session is started with the web server, the web server creates a random 512-character session key which is stored as a session object on the web server.
  2. The client sends user credentials to the web server.
  3. The web server creates a cookie with the user credentials.
  4. The web server encrypts the cookie with session key.
  5. The web server sends the encrypted cookie to the client.

After the encrypted cookie is stored on the client, the following process takes place when the client retrieves an application list or launches an application.

Figure 15.20: Web clients use of the encrypted cookie

  1. The web server requests user credentials.
  2. The client browser sends the encrypted cookie to the web server.
  3. The web server executes code to decrypt the cookie, retrieving the user credentials.
  4. The web server sends the credentials to the MetaFrame XP server.

It's important to note that the default NFuse web site that uses cookie data encryption does not replace the need for SSL encryption between the web server and the client web browser. As you can clearly see, the user credentials are sent across the network in clear text before the encrypted cookie is created. This cookie encryption is designed to prevent people on the client device from reading the credentials. It does not offer network protection.

Using NFuse Ticketing

NFuse ticketing was covered in depth earlier in this chapter as it related to Citrix Secure Gateway. Standalone NFuse 1.7 Classic websites also make use of NFuse ticketing. By default, ticketing is enabled in NFuse environments. NFuse ticketing is configured at the NFuse server in the same way that most NFuse system components are configured-the NFuse.conf INI file. The following line dictates the expiration time of the NFuse ticket, in seconds:


Also, the template.ica file must contain the following two lines:


The AutologonAllowed line allows the MetaFrame XP server to receive user credentials from the ICA file. The NFuse_Ticket substitution tag is the segment of the template ICA file that the NFuse server replaces with the actual 30-character ticket when the template.ica file is parsed for an end user.

Advantages of NFuse Ticketing

  • Very cool.
  • Protects ICA files from users' friends.
  • Tickets are only valid once.
  • Tickets expire after a configurable amount of time.
  • Clear text user credentials are not placed in the ICA files.
  • Clear text user credentials are not passed across the network when ICA sessions are launched.

Disadvantages of NFuse Ticketing

  • Unencrypted data is still sent over the network once.
  • Ticketing does not replace the need for SSL encryption from browser to web server.

Removing User Credentials from ICA Files

If you cannot use ticketing (perhaps with MetaFrame for UNIX) or if you need extra security, you can remove user credentials from NFuse-generated ICA files altogether by deleting the AutologonAllowed=ON and [NFuse_Ticket] entries in the template.ica file. Of course, if you choose to do so, your users will need to manually log into each ICA session in addition to logging into the NFuse web page. This loss of convenience is the price you pay for higher security.

Preventing Browsers from Caching ICA Files

As an additional security precaution, you can write your web pages so that they do not allow web clients to cache the ICA files. Again, this is a feature of the web scripting languages, not NFuse itself. In order to do this, add the code to the web page that actually creates the ICA file (launch.asp or launch.jsp).

For example, if you are using active server pages, you should add the following two lines of code after the Response.ContentType="application-x/ica" line.

Response.AddHeader "Pragma","no-cache"

Adding these lines will create dynamic ICA files containing instructions for the local browser not to cache the file.

There is one other cache-related security item that you should be aware of. Whenever a user connects to an ICA session through an NFuse web page, a temporary file will be written to that user's hard drive. This file will be named ica*.tmp. Whenever your session is closed, that file will be deleted. However, if the ICA session is not terminated properly, that file night not be deleted. If this happens, the file could be read, exposing the logged on user's username and the IP address of the MetaFrame XP server. In actuality this security risk is not that significant, but it is a risk nonetheless.

Permitting Users to Only Connect from Certain Client Devices

As an added security measure, you can configure your MetaFrame XP servers or your NFuse web servers so that they only accept incoming connections from certain IP addresses.

For MetaFrame XP servers, this is accomplished by configuring a Load Evaluator to be available with MetaFrame XPa or XPe. Specific load evaluators can be configured that only allow users to connect to published applications if the client's IP address falls within a specified range. From a security standpoint, this can be useful in mandating that users connect to applications from certain machines or certain sites. For example, this load evaluator can be useful if you want to allow users to log on from their homes, but you also have some sensitive applications that you want them to only be able to run from the office. By using the IP address-based Load Evaluator, you can still publish all the applications to the users and have the Load Evaluator check to make sure that they are connecting from a valid IP address. More detail on this configuration is available in Chapter 4.

Additionally, you can configure your web server to only allow connections from certain IP address or to deny connections from certain IP addresses. Because this security is configured at your web server-level, you can stop unauthorized users before they ever see an NFuse login page.

Controlling Local Drive Access through Web Browsers

Since the ICA protocol allows MetaFrame XP remote applications to access local hard drives through the web, many of people became concerned that this was a security hole, because users were taught that the websites could not directly access, change, or delete their local files. While this is technically not true (because the web browser actually launches the local ICA client software, as discussed in Chapters 10 and 11), Citrix decided to modify the behavior of the ICA client when it is used to access MetaFrame XP applications through web sites.

With the current version of the ICA client, each user can specify the amount of access he wants a remote MetaFrame XP application to have to his local hard drive. This is done through a pop-up box that appears the first time the user accesses an ICA session launched via their web browser. This box allows him to choose "No Access," "Read Access," or "Full Access" to the local hard drives for the application. Additionally, the user can select to "Always ask me once per connection," "Never ask me again for this application," or "Never ask me again for any application."

The choices that the user enters into this security dialog box are saved locally on his client device in a file called "webica.ini." This file is stored in the Windows directory. Let's take a look at a sample webica.ini file now.

CurrentConnection=MS WORD10.1.1.2
MS WORD10.1.1.2=405

Figure 15.21: A Sample webica.ini file

The CurrentConnection= line always lists the last server connection that was made. This list includes the published application name (MS WORD in this case) and the IP address of the MetaFrame XP server where the application was executed ( in this case).

For the remaining lines in the webica.ini file, there are four different values that can be configured.

 The security setting has not been configured.
 No access.
 Read access.
 Full access.

Figure 15.22: Security values for webica.ini files

The GlobalSecurityAccess line controls the behavior of the popup security window for all web sites. By default, this value is not set (-1) and the popup windows always appears. However, if the user selects the "Never ask me again for any application" button, then the GlobalSecurityAccess line changes to the value that corresponds to the user's selection. For example, if the user chooses to give the remote ICA applications read only access to local drives, the line would read GlobalSecurityAccess=404. When this value is set, the rest of the webica.ini file is ignored and the GlobalSecurityAccess setting is used for all applications and all servers.

Further down in the file, the line MS WORD10.1.1.2=405 contains the user's preference for the MS WORD published application on the MetaFrame XP server with the IP address of If MS WORD is load balanced between multiple servers, load balancing will randomly pick a server for a user, causing the user to sometimes get the popup window (when they are routed to and sometimes not get the popup window (when they are routed to a server other than To get around this, you could manually add lines for the other MetaFrame XP servers that are running the MS WORD published application, which might be something like MS WORD10.1.1.3=405 and MS WORD10.1.1.4=405. Otherwise, the user will need to specify the connection security preferences manually.

Navigating Client-Side Proxy Servers

32-bit Windows ICA clients can automatically configure their proxy settings based on the settings in Internet Explorer 4.0 or Netscape Navigator 4.76 or newer. This prevents you from having to manually configure the proxy server on your client devices.

If you're using NFuse 1.7, you can use NFuse to send proxy server settings to the client that will override the automatic configuration (NFuse Admin Web Pages | Client-Side Firewall). These settings work in the same way as the network address translation maps. You can apply default settings that will apply to all clients or specific settings that will only apply to clients whose IP addresses match a defined prefix.

Any client-side proxy settings that you configure via NFuse are added into the ICA file that NFuse dynamically creates and passed down to the client device at application launch.


Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.