Citrix MetaFrame XP Security Design

Written on Oct 31 2002 Filed under: Citrix XenApp, Security, Citrix 29,612 views, 1 comment

---

by Brian Madden

Note: This paper is excerpted from the book, Citrix MetaFrame XP: Advanced Technical Design Guide, Including Feature Release 2. Diagrams and figures are only available in the PDF download.

 

A major part of any computing environment is security. As you have probably noticed, we have not dwelled much on security in the preceding chapters. That’s due to the fact that when you focus on the security of your MetaFrame XP environment, you need to do it from end-to-end. You can’t just “do a little security here, and a little there.” For example, it would have done no good to talk about security of NFuse in the NFuse chapter because even if you did everything NFuse–related to tighten security you might have overlooked a major security hole somewhere else.

To prevent this, we will analyze the security elements of a complete MetaFrame XP system in this chapter. We will systematically analyze every MetaFrame XP component, taking note of what the potential security risks are and what to do to minimize each of them.

Let’s begin by reviewing all of the components that make up a MetaFrame XP system. This will help us design the components of our security plan. We can represent the individual components as layers in the complete MetaFrame XP system, as shown in Figure 15.1. (These layers are kind of like the OSI model applied to MetaFrame.)

Figure 15.1 MetaFrame XP layers

 

Using the MetaFrame XP components outlined in the Figure 15.1 as our guide, we can methodically step through each one, analyzing the security as we go along. We’ll start from the server layer and move our way down to the user layer, touching on the security aspects of each component.

After we study the security requirements and techniques related to each of these technical components, we’ll look at what it takes to build a secure administrative environment.

One thing that you must remember as you read this chapter is that it focuses primarily on the security of the MetaFrame XP components. This chapter is not meant to be an end-to-end security manual. Your MetaFrame XP environment is only as secure as its weakest link, and often human elements are involved that no technical manual can prepare you for.

Security Configuration Layers

Before diving into the technical details of the security options, we need to take another look at the different layers in which many of the security-related settings can be made. For example, the encryption level of an ICA session can be configured as a property of the server connection, the ICA client, a Citrix user policy (with Feature Release 2), or the published application. Beyond that, applications launched via an ICA file can also have the level of encryption configured within the ICA file itself.

Figure 15.2 Example security parameter configured at multiple layers

 

When a single parameter is configured in multiple locations with conflicting settings, the most restrictive configuration will always take precedence. Referring to Figure 15.2, if the client device and the published application were configured for a minimum of 40-bit encryption, but the server connection was set to a minimum of 128-bit, no session connecting via that connection would be able to connect at anything less than 128-bit. Even though the client and application are set lower, they must still traverse the connection configured for the 128-bit minimum.In this example, we can say that the “client layer” was set to 40-bit encryption, and the “connection layer” and “published application layer” were encryption was set to 128-bit.

Figure 15.3 shows all of the possible layers where one security parameter can be configured. Of course, not every security parameter can be configured at every layer. It’s important to look at the MetaFrame XP settings and determine the proper layer that the security parameter should be applied. Do all users require 128-bit encryption or only users connecting to certain applications? Maybe only users coming from specific IP addresses need encryption?

Figure 15.3 Various configuration scope layers

Level Scope

Farm Every MetaFrame XP server in the entire server farm.

Server All users connecting to one server.

Application All users connecting to one particular published application, even across multiple servers.

Connection All users attaching via one defined server connection. Multiple connections can exist on one server.

Client All users connecting from one ICA client device, regardless of the user rights or the server or farm hosting the ICA session.

Citrix User Policy All users to which the policy is applied.

Users User profile settings. These settings follow the user, regardless of the farm, server, or connection used.

ICA File Settings affect anyone using the ICA file, regardless of settings in other locations.

Throughout this chapter we’ll look at dozens more security settings configurable at all layers. Beyond that, the appendix of this book contains a “MetaFrame XP Component Configuration” chart detailing every setting within the MetaFrame XP environment and listing the layer where it can be configured.

Server Security

In order to adequately analyze server security in MetaFrame XP environments, we need to break up the servers into their multiple roles and then look at the security of each server role separately. We’ll examine each of the following three MetaFrame XP server roles:

 MetaFrame XP application servers.

 IMA data store servers.

 NFuse Classic web servers.

MetaFrame XP Application Server Security

Since the MetaFrame XP servers are where the actual user sessions are executed, it makes sense that there are several things to look at when it comes to security. To begin with, let’s outline the basic points that you must consider when you are securing your MetaFrame XP servers. These security points are as follows:

 Use the NTFS file system.

 Configure NTFS file permissions.

 Do not install MetaFrame XP on a domain controller.

 Disable the “RunAs” Service.

 Do not use Windows RAS or VPNs for ICA–only sessions.

 Delete the MetaFrame XP installation log file.

 Apply hotfixes and service packs.

Use the NTFS File System

Remember, each user that runs a session on a MetaFrame XP server is essentially running a remote control console session. Without an NTFS file system, you will not be able to set any file–level security permissions. This will allow any user that is logged in to be able to access files in use by other users. Even worse, there would be no mechanism to prevent users from deleting key system files, potentially crashing the server!

There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an ICA session, even if his ICA client is running on an operating system that cannot support NTFS, like Windows 95.

Configure NTFS File Permissions

Just using the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your MetaFrame XP servers or if you plan to only run published applications, you should secure the basic file system.

If you’re using Windows 2000, as you install Terminal Services in application mode you are asked whether you want to use permissions that are compatible with Terminal Services 4.0 or Windows 2000. This “permissions compatibility” has nothing to do with your domain configuration or your Active Directory environment. It only affects the level of security that users are given when they access your server via a Terminal Services or Citrix ICA session. There are a few differences between the two settings:

  Permissions compatible with Windows 2000. This setting results in Terminal Services users having the same permissions as regular members of the local users group. This is very secure, because regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose this W2K permissions compatibility, you should thoroughly test your applications before enabling them for any users.

 Permissions compatible with Terminal Server 4.0 Users. This setting results in Terminal Services users having more access on the server than regular users because Terminal Service and Citrix ICA users will have full access to the registry and system files. This is not very secure, but it lets some older applications run.

To understand the difference between the two permissions modes, you need to understand the “Terminal Server Users” group. Whenever you install Terminal Services in applications mode on a Windows 2000 server, a local group called “Terminal Server Users” is created. Members of this group have the ability to access the critical registry keys and system files. Regardless of the permissions compatibility mode that you choose, this group always exists with its advanced permissions.

The only technical difference between the two permissions compatibility settings is whether the “Terminal Server Users” local group is used. If you set permissions compatibility to “TSE 4.0,” users are added to the “Terminal Server Users” local group while they are logged on and are removed from the group when they log off. On the other hand, if you set your permissions compatible to “Windows 2000,” users are not added to the “Terminal Server Users” group when they log on. The use of this group is how the two modes can provide different levels of access.

There are some situations in which it would be nice to give users “special” permissions while they were logged onto a MetaFrame XP Server. It seems that the “Terminal Server Users” group is perfect for this, except that by default, it has all sorts of advanced permissions already set throughout the server. In order to effectively use this group for your own purposes, you need a way to strip the “Terminal Server Users” group permissions from the server. Fortunately, Microsoft thought of this and there is an easy way to do it. In the %systemroot%\Security\Templates\ folder, there is a security template, notssid.inf, that you can apply to a Terminal Server to remove the permissions of the “Terminal Server Users” local group. You can apply this security template with the secedit.exe security command line tool, with the command “secedit.exe /configure /db notssid.sdb /cfg notssid.inf.” For more details about using this tool, see Microsoft article Q216735.

After you use the security template to remove the default permissions of the “Terminal Server Users” local group, there will effectively be no difference on the server between the W2K permission compatibility and the TSE 4.0 permission compatibility because the “Terminal Server Users” group will not have any special rights or permissions assigned to it. From there, you can manually set any permissions for the “Terminal Server Users” group that you want. If you later decide that you would like to reinstate the default “Terminal Server User” permissions, you can use the included defltsv.inf security template.

Even after you select the “permissions compatibility” mode during the installation of Terminal Services, you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:

Key: HKLM\System\CurrentControlSet\Control\ Terminal Server\

Value: TSUserEnabled

Type: REG_DWORD

Data: 1 = Unsecured TSE 4.0 permissions (use the Terminal Server User group). 0 = Secured W2K permissions (do not use the Terminal Server Users group).

Do Not Install MetaFrame XP on a Domain Controller

Individual domain controllers cannot be managed separately from each other. For example, in order for a user to be able to log on to MetaFrame XP sessions they must have “log on interactively” (called “log on locally” in Windows 2000) rights. If the MetaFrame XP server is a domain controller, granting a user “log on interactively” rights on the server will allow that user to log on to any domain controller, even ones that are not MetaFrame XP servers.

Also, domain controllers in Active Directory environments must be located in the “Domain Controllers” OU. This means that you can’t use OU-based Group Policy Objects if your MetaFrame XP servers are installed on domain controllers.

Lastly, there are several security holes associated with the operation of the Local System Account on domain controllers. In order to have a secure environment, you should never have users log onto a domain controller. Installing MetaFrame XP on a domain controller makes it difficult to follow this recommendation.

Disable the “RunAs” Service

Windows 2000 introduced a secondary logon ability which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select “Run as...” from the context menu. Alternately a user can use the “runas” command from the command line. With this service, a user could connect to an anonymous application and then launch additional processes with his native user account, bypassing the anonymous user security that you configured on the server. This secondary logon ability can be disabled at the server by stopping and disabling the “RunAs” service.” It is important to disable the service after you stop it, or the system will start it again when it is needed.

Do not use RAS or VPNs for ICA-only access

Often times, users will connect into a company’s computer system with a Windows RAS or VPN connection and launch MetaFrame XP applications on internal company servers. If you choose this setup for your environment, remember that the users of those RAS or VPN sessions are usually not limited to running only MetaFrame XP sessions. Once a user establishes a connection, they are able to access any network resource, even outside of the MetaFrame XP environment.

If you have users that need dial-in access to MetaFrame XP servers and nothing else, you should consider establishing ICA dial-in sessions or using MetaFrame XP via the Internet and having users connect via their own local ISP. That way, you can ensure that users do not connect to inappropriate servers or services in your environment.

Delete the MetaFrame XP Installation Log File

During the installation of MetaFrame XP, everything is captured in a setup log file. If your data store is on a SQL Server with SQL authentication, and if you’re not using the newest version of the Windows Installer (part of Windows 2000 Service Pack 3), the database login credentials will be contained in the installation log file. The easiest way to fix this is to delete the log file once MetaFrame XP is installed. It is located at the following path: %systemroot%\Imainxxxxxx.log (“xxxxxx” is a time stamp). You should delete this file from every one of your MetaFrame XP servers.

Apply Hotfixes

As in any computer environment, maintaining security means that you must frequently check for new hotfixes that address security issues, even if you keep your servers up to date with the latest service packs.

For example, just two weeks after Service Pack 1 was released for MetaFrame XP, Citrix released a Security Bulletin (ID# CTX654124) and hotfix that addressed a denial-of-service attack. In this case, an attacker could send malformed ICA packets to a MetaFrame XP server, spiking the server at 100% CPU utilization. The only remedy after this happened was a reboot.

You should check for new hotfixes from Microsoft and Citrix at least once a week. However, because history has shown that neither Microsoft nor Citrix has had a perfect track record for creating bug-free hotfixes, you should also check with an online discussion group (such as The THIN List at http://thethin.net) to see if there are any issues surrounding new hotfixes that are released.

To help maintain your hotfix environment, Microsoft has released at security hotifx checker utility (detailed in article Q303215). This utility will allow you to quickly and easily check the status of hotfixes on multiple Windows NT 4.0 or Windows 2000 servers.

IMA Data Store Server Security

The IMA Data Store contains most of the critical configuration information for your MetaFrame XP server farm. The risk of compromising sensitive data from the data store is low. Opening the database natively does not reveal much useful information and even with the Citrix SDK it is not possible to directly access the database.

However, it is possible that someone with database administration rights could delete key portions of the database. While your environment should be designed so that the database is backed up and could be restored in case of a loss (see Chapter 17), this is an inconvenience that you probably want to avoid.

To address this security risk, ensure that the database account used by your MetaFrame XP servers is secure. By default, all MetaFrame XP servers access MS Access-based IMA Data Stores with the username “citrix” and the password “citrix.” (SQL, Oracle, and DB-2 data stores ask for the credentials when MetaFrame XP is installed.) This can be changed with the “dsmaint” command line utility (dsmaint config /user:username /pwd:password). Using the dsmaint utility on a MetaFrame XP server does not change the permissions of the database itself. Dsmaint merely changes the account that the local MetaFrame XP server uses to access the data store. To create a new account or change the account permissions of the database itself, use your native database tools.

For extra security, you can restrict the database rights that you grant to the account that the MetaFrame XP servers will use to access the IMA data store. For example, if your IMA data store is on a Microsoft SQL server, the account that your MetaFrame XP servers use to access the database must have “db_owner” rights to the IMA data store database. Some people choose to not give the MetaFrame XP database account “db_owner” rights, instead simply granting read and write access to the database. If you set the security like this, MetaFrame XP will still function. However, you will not be able to install any service packs or feature releases because the database account that MetaFrame XP is configured for would not have the permissions to change the layouts of any tables.

NFuse Server Security

Fortunately, NFuse behaves like a standard web application. This is good when it comes to applying security because you don’t have to do anything out of the ordinary with NFuse. You can treat it like a regular application and apply all the standard security. Let’s examine some standard security practices that can be done on your NFuse web server.

Using the Microsoft IIS Lockdown Tool

If your NFuse web server is running IIS on a Microsoft platform, the Microsoft IIS security lockdown tool provides an automated, easy to use way to lock down your web servers. You can download the IIS lockdown tool for no charge from Microsoft’s website. (www.microsoft.com/technet/security/tools/locktool.asp)

When you run this tool on your web server, you are given a list of “server templates.” Each server template corresponds to a different role that an IIS web server could play. For NFuse web servers, highlight the “Dynamic Web server (ASP enabled)” template.

Before you click “Next,” be sure to check the “View template settings” box. This will allow you to customize the settings that the IIS lockdown tool applies from the template. If you don’t check this box and you accept the default settings of the Dynamic Web server template, NFuse will stop working.

After you click next, you are given the option to disable certain Internet services on your web server. NFuse only requires that the Web service be present. You can disable the FTP, SMTP, and NNTP services.

The next screen allows you to enable and disable certain scripts. You can leave the default settings as they are.

The third configuration screen is where you need to make the change in order for NFuse to work. In the section that removes selected virtual directions, uncheck the “Scripts” box, since NFuse stores some scripts in the “\Scripts\” web folder. Other than that, the rest of the IIS lockdown tool options can be left at the default settings.

Configuring NFuse Web Pages to Time Out

One potential downside to using NFuse is that after a user logs in and receives his list of applications, the web page remains open after his MetaFrame XP session is started on the server. This could be a problem because he could walk away from his computer and leave that web page open, allowing anyone who passes by to be able to access his applications. To mitigate this, you can change the amount of time that the session information is retained for a user’s session. The default is 20 minutes. If, after 20 minutes, a user tries to click on a link to launch an application, he will be sent back to the login page because the web server would have deleted his session information, including his user credentials. You can set the session timeout to be longer or shorter, depending on the security you need in your environment. To change this timeout in IIS 5.0, navigate to the following location: Internet Services Manager | Right-click website | Properties | Home Directory tab | Application Settings | Configuration Button | App Options Tab | Session Timeout. If you change this timeout, you will need to stop and start the web server service for the settings to take affect.

Application Security

The next layer that we will look at in our approach to MetaFrame XP security is the application layer. Here, we’ll consider the applications that users run, how they access them, and what they can do with them. To begin with, let’s review how applications are launched by users. There are two ways that users can launch applications on a MetaFrame XP server:

 By connecting to a published application.

 By running the Windows desktop and launching applications from within their established session.

When looking at application security, we first need to examine the security of these two different ways of launching applications. Before we do that, though, we should note that complete details of the ways users launch applications and when different methods should be used, are covered back in Chapter 4. In this current chapter, we’ll focus on application access strictly in terms of security.

Now, let’s look at the security aspects of these two methods of accessing applications, starting with published applications.

Published Application Security

The ability to publish applications to users is one of the main benefits that MetaFrame XP offers over pure Terminal Services environments. After all, this is what allows users to connect to an application by its name alone without needing to know which servers it uses. Also, published applications provide an easy way for us, as administrators, to set permissions as to which users can access specific applications. From a security standpoint, there are two things to look at with respect to MetaFrame XP published applications:

 Published application permissions.

 How to limit users to only running published applications.

Published Application Permissions

As outlined in Chapter 4, individual applications (or the entire desktop) can be published “Explicitly” or “Anonymously” in MetaFrame XP. Remember that an explicitly published application requires that a user authenticate with valid credentials before the application session is started and an anonymous application requires no credentials allowing any user that discovers the MetaFrame XP server to run the application. These two methods of securing published applications have an effect on the security of the MetaFrame XP environment.

Explicit Applications

Explicitly published applications are the most common in the real world. You can set the permissions on explicit applications to make them available to local or domain groups, or local or domain user accounts. Most likely, you’ll choose to set the permissions for domain groups because then you can easily grant a user access to a published application simply by adding him to the appropriate domain group instead of having to use the Citrix Management Console to change the permissions of the published application. By setting published application security at the group level, you can also publish multiple applications (such as entire application suites), to the same domain group. Then, by adding a user account to that domain group, you can instantly give him access to the entire application suite. By using domain groups instead of local MetaFrame XP server groups, the user’s group membership will apply on any MetaFrame XP server to which he connects, which works well in environments where applications are published across multiple MetaFrame XP servers.

There are no restrictions to the number of groups to which a user can belong. Many companies that have dozens of applications published set the permissions of each application so that each is available to a different domain group. Users that need access to multiple applications are simply added to multiple domain groups.

Another advantage to giving users access to published applications by adding them to domain groups is that the domain groups can be used as a basis for additional security configuration outside of the published application. For example, a domain group could be used to assign NTFS rights to files or network shares that the published application needs.

By configuring multiple security items for the same domain group, adding a user to a single domain group gives access to the application, the files, and the settings he needs to use the application.

Anonymous Applications

Applications published anonymously work well in two scenarios:

 The application provides its own security. This means that any user can connect to the application because the user will need to log into the application itself before it can be used. Many line-of-business applications are configured in this way since they contain their own internal user databases.

 The application is accessed by a wide variety of users, without formal user accounts. This is usually seen in public or kiosk applications as well as demonstration and sample applications.

When a user establishes an ICA session with an anonymous application, he is automatically logged on with one of the local anonymous user accounts that was created when MetaFrame XP was installed. All of the local anonymous user accounts (named anon000, anon001...) belong to a local group called “Anonymous Users.” This group membership is important to remember when you create the security model for your environment because you can assign or deny permissions elsewhere on the MetaFrame XP server based on this group. Just because anonymous users don’t officially log on doesn’t mean that they can’t be granted rights.

On a side note, applications cannot be published anonymously if the MetaFrame XP server is also a domain controller because domain controllers don’t have local groups, and so the anonymous accounts cannot be created.

Forcing Users to Run Only Published Applications

One mistake that many administrators make is to assume that once the security is set properly on published applications, there is nothing more to worry about. They forget that even with only published applications available, any user can create a custom ICA connection within his ICA client software. In the custom connection properties, he could choose to connect to a specific MetaFrame XP server instead of a published application. Using that new custom connection, he would be able to logon to a full Windows desktop. Even if you use NFuse to connect to MetaFrame XP applications, anyone can download and install the full ICA client from Citrix’s website and create a custom connection to one of your MetaFrame XP server’s desktop.

If this happens, it is usually the case that the administrator did not anticipate that the users would ever connect to the desktop. The administrator probably did not make any effort to lock down or secure the desktop and the user would have free access to inappropriate applications, data, or configuration settings.

To prevent this from happening, you can configure your MetaFrame XP server ICA connections so that they only allow users to connect to published applications, preventing them from connecting directly to the server desktop.

This setting is configured via the Citrix Connection Configuration utility (Citrix Connection Configuration | Right-click the connection | Properties | Advanced Button | Only run published applications checkbox). If you check this box, it will apply to all users that access the MetaFrame XP server via the connection where it is applied, including administrators. There is no way to limit some users to published applications while giving others access to the full Windows desktop over a single connection. However, this can be easily remedied by publishing the desktop as an application. By doing so, you can configure the needed security for the desktop application. For example, you might choose to allow administrators to use the “desktop” published application while denying everyone else.

Advantages of Forcing Users to Published Applications Only

 Useful for preventing users from connecting to the desktop of a server.

 There is no way around this setting over a specific connection. The connection would be very secure.

Disadvantages of Forcing Users to Published Applications Only

 All users are restricted to running published applications—including administrators.

Windows Desktop Application Security

The other way that users access applications is by connecting to a Windows desktop and then launching applications through icons on the Start menu just as in any regular environment.

If you plan to use this method to provide users access to applications on MetaFrame XP servers, you need to ensure that the user environment is protected and secured so that users cannot do things that they are not supposed to do. There are four strategies that you can use to secure your Windows desktops:

 Apply appropriate policies or profiles.

 Use the AppSec utility.

 Configure NTFS security.

 Prevent users from installing applications.

Applying Policies and Profiles

The Windows desktop shell can be “locked down” so that users are limited by the rights that they have and the actions that they are able to perform. In MetaFrame XP environments, locked down desktops are often used when users connect to the actual server desktop instead of the individual published applications.

In the simplest sense, a locked down desktop could be a Windows desktop that has the “Shutdown” or “Run” commands removed from the Start menu. On the other end of the spectrum, a locked down desktop can be created that gives users almost no access to the system—no “My Computer,” no “Network Neighborhood,” and no access to local system drives.

There are several methods that can be used to lock down Windows desktops on MetaFrame XP servers. The most popular methods involve using policies to restrict user shell access and applications that can be executed. Policies are discussed in detail in Chapter 5.

Locking down a Windows desktop is a function of the underlying Windows operating system. MetaFrame XP does not provide any additional mechanisms to help lock down a Windows desktop. What MetaFrame XP does provide is the published application alternative to users accessing the Windows desktop at all. With MetaFrame XP, many people avoid the hassle of locked down desktops by only allowing users to run published applications and not allowing general users to access the desktop.

Advantages of Enforcing Application Security with System Policies

 Can be easily applied across multiple servers.

Disadvantages of Enforcing Application Security with System Policies

 Policies only watch over the Windows shell. If you restrict certain areas or applications, users can get around that restriction by launching applications via the command prompt.

Limiting Application Execution with the AppSec Utility

The Application Security (appsec.exe) utility can be used to enforce application execution security by allowing you to specify exactly which executables users are able run. This is similar to applying a policy restriction, although this AppSec utility works without policies. Any users that connect to your servers with administrative rights will not be affected by the AppSec security policy.

The AppSec utility is part of the Server Resource Kit. It is available for both NT 4.0 and Windows 2000. However, the version that shipped with the Windows 2000 resource kit was missing three critical files, so if you want to use AppSec for Windows 2000, you should download it from the Microsoft FTP site. (ftp.microsoft.com/reskit/win2000/appsec.zip)

When this tool is used, the server is set to a restricted state, and you can add application executables that you want users to be able to run. This makes the AppSec tool extremely granular. However, because you must specify every single executable that is permitted, the configuration can become very complex for large numbers of applications. This happens because you must find all of the exact executables that an application needs, which can be a dozen or more. For example, if you use the tool to provide access to the Windows desktop, you must allow access to both explorer.exe and systray.exe. For many applications, you can only find all of the executables that are needed through trial and error.

Whenever you run the AppSec utility, you have the option to enable or disable AppSec security. If you disable it, any of the settings that you made do not apply. This is good, especially if you make a change that adversely affects users. By running the tool and disabling security, you can “fix” whatever problems you caused by enabling security.

AppSec is an execution-layer security tool, so it cannot technically prevent users from connecting to the system. However, if you enable AppSec security without giving any executable rights to users, you can effectively prevent them from connecting. In this case, your users will get this error when they try to connect:

An error (193) occurred while creating user logon. Failing component: explorer.exe.

When the user clicks “OK,” his session is terminated.

If, through the course of his session, a user tries to run an application that is not on the AppSec authorized list, he will get the following error:

yourapp.exe in not a valid Windows NT application

AppSec can also be used to allow users to run 16-bit applications. To do this, you should use the 16-bit version of AppSec. This will automatically allow the users to use the necessary 16-bit support files, like ntvdm.exe (the virtual DOS machine) and the WOW subsystem (Windows on Windows).

Advantages of Limiting Application Execution with AppSec

 Very granular control.

 Users cannot get around this by going to a command prompt.

 Does not affect administrators.

 Can be easily turned off.

Disadvantages of Limiting Application Execution with AppSec

 Every application executable must be listed.

 Must be configured on every server.

Setting NTFS Security

Another way to restrict the applications that a user can access is to configure the NTFS security on the application executables themselves. The nice thing about setting NTFS-level security is that once set, there is no way around it. No matter how the user accesses the server, the application won’t run if the user doesn’t have NTFS rights to the application.

Advantages of Limiting Application Execution with NTFS Security

 NTFS permissions that prevent users from accessing certain files or applications are absolute—there is no way for a user to get around them.

 Very granular control of who can and cannot access applications.

Disadvantages of Limiting Application Execution with NTFS Security

 Must be set on every MetaFrame XP server.

 NTFS permissions do not prevent users from running applications from other, non-local locations. Even if you restrict access to a local copy of Word, a user might find winword.exe on a network share and be able to execute it from there.

Preventing Users from Installing Applications

Undoubtedly, if users run remote Windows desktops on your MetaFrame XP servers, you do not want them to be able to install any software applications. The easiest way to do this is to remove the users’ “write” permissions from the software installation registry key. Use regedt32.exe to browse to the following registry location:

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Terminal Server\Install\Software

From the Security menu, choose “Permissions.” From there you can configure your users with read-only permissions. Be sure that you propagate these permissions to the subkeys below the key where they are applied. In order to configure registry security, you must use regedt32.exe instead of regedit.exe. Regedit.exe does not allow you to set permissions on registry keys.

Connection Security

Remember from Chapter 2 that “connections” in the MetaFrame XP environment refer to the groups of settings that apply to a specific Session Protocol / Network Protocol / Network Interface combination. There are multiple options configured at this “connection layer.” Many of them directly impact the overall security of the system. Additionally, there are many neat tricks that you can do to provide different levels of security to different interfaces.

Connection Properties

When configuring the properties of a connection (Citrix Connection Configuration Utility | Right-click on connection | Edit | Advanced Button), it is important to remember that those properties will affect all users that connect to the MetaFrame XP server via that connection unless you check the box for each item that allows the server to use the settings in each user’s profile. (Checking this box will actually allow the setting to be configured from the user’s profile or by a Citrix user policy.)

Let’s examine each of the following connection layer security settings:

 Session timeouts.

 Working with broken connections.

 Auto session logon.

 Limiting the number of sessions per connection.

 Disabling logons.

 Encryption.

 Using default NT authentication.

 Initial programs to be executed.

 Forcing Users to Run Only Published Applications

 Session shadowing.

 ICA TCP port.

Session Timeouts

You can configure three different timeout periods for each connection: connection timeout, disconnection timeout, and idle timeout. Each of these choices allows you to specify the timeout in minutes. The checkbox allows the timeout settings of the connection to default to those specified in the user profile as opposed to by the connection itself. This allows for different settings on a user-by-user basis. Selecting “no timeout” disables that specific session timer for that connection.

The “Connection” timeout allows you to specify the maximum time that an ICA session can stay connected. After this time passes, the server either disconnects or terminates the session. (The decision to terminate or disconnect the session is determined by the connection property setting outlined later.)

The “Disconnection” timeout causes the server to reset a disconnected session after the specified time has passed. This will cause the current user to lose any work that was in progress. The disconnection timer is a good way clean up any disconnected sessions that users have forgotten about. Many companies set this to something like 2880 minutes (48 hours). If they have some situations that require less time, they configure those in the user profile. If you configure disconnection timeouts for users in addition to the connection properties, the more restrictive setting will always take precedence.

The “Idle” timeout specifies the amount of time that a live connection can stay in an idle state (no activity) before the server automatically disconnects or resets the session. From a security standpoint, the idle timeout works well as an “automatic lock-down.” Many companies set their idle timeouts relatively low so that if a user leaves his desk with an active ICA session open, the server will disconnect the session after a few minutes. Then, when the user returns to his desk, he can conveniently reconnect to his disconnected session, without losing any work.

Extreme care must be taken when working with these connection timeouts. Almost all environments that utilize connection timeouts configure them as a property of the user account (at the “user layer”), instead of configuring them here as a property of a connection. The one exception is the disconnection timeout, which are used to clean up any old sessions.

Working with Broken Connections

The term “Broken Connection” is used to specify what happens when an ICA client stops responding to the MetaFrame XP server during an ICA session. There are many things that can cause broken sessions, including network failures, power failures, and crashed client devices.

At the connection layer, you can specify what action should be taken when a connection is broken. Choosing to have the server disconnect the session will allow the session to maintain its state on the server, enabling the user to reconnect and pick up right where they left off. This often happens when client computers crash. After the crash, the user reboots, mutters a curse word or two, and reconnects to his existing session that is still running on the server. The server will maintain the disconnected session as long as the timeout period allows, with the “timeout period” being the shorter of the connection-layer disconnection timeout or user-layer disconnection timeout.

From a security standpoint, the broken connection action does not pose much of a security risk because users must successfully authenticate before they are given the option to reconnect to a broken session.

Reconnecting to broken sessions generally works best with explicit connections because anonymous users are not guaranteed that they will authenticate with the same anonymous account each time. If this happens, the server has no way of knowing which disconnected session belongs to that user.

You might be wondering about the “Auto Client Reconnection” that is available with Feature Release 1 and 2 and how it relates to the broken connection detection of a MetaFrame XP server. Auto client reconnect allows ICA clients to automatically reconnect to a MetaFrame XP server if their ICA session is interrupted. Auto client reconnection is a property of the client devices themselves and cannot be configured at the connection layer. For details on configuring auto client reconnection, see Chapter 10.

Reconnecting From Any Client

You can also decide whether you want to allow users to reconnect to disconnected sessions from any client device or whether users should be restricted to reconnecting only from the client device on which their ICA session was originally established. Some people perceive the ability to reconnect from any client as a security problem. In actuality, the security consequences are not that great because the user must authenticate on the new client before being able to reconnect to a session. Also, the user can only reconnect if the disconnected session was started with the same credentials as the new user. This means that one user cannot reconnect to another user’s disconnected session.

Potential security problems arise when multiple users logon with the same user account to access MetaFrame XP servers. This is common in many environments for kiosks, common applications, or task-based workers. If a user authenticates with credentials that were used to start multiple sessions (which have since been disconnected) on one server, the user will be presented with an option to choose the disconnected session to connect to. It is possible that the user might pick a session that does not belong to him and be able to view privileged information or data.

Auto Session Logon

The AutoLogon parameters of a connection’s advanced configuration will use one set of credentials to automatically log on any user that attempts to start an ICA session via that connection. This can pose a tremendous security risk, as any person could access to the system without being officially set up or authorized. It is relatively simple for a user/attacker to download and install the Citrix ICA client software and then to “discover” the Citrix server, connect to it, and be automatically logged on.

The AutoLogon settings are intended for point-to-point connections, such as the asynchronous RAS. AutoLogon in these cases is nice because users usually need to authenticate at other levels, as when the RAS connection is established. In these cases, AutoLogon prevents users from having to log on twice.

Limiting the Number of Sessions per Connection

The maximum number of concurrent sessions can be limited per connection on the connection’s main property page. In general, this is not used to limit user connections because this limit applies to all users, including administrators. More often, administrators will create a dedicated connection for their own use (over a specific network interface), and limit the number of sessions to one or two as an additional security precaution,

Disabling Logons

Disabling logons is useful if a custom connection is needed from time to time, but you do not want to have the connection open all the time or have to recreate the connection each time it is needed.

Remember that disabling the logons of a connection does not cause existing sessions to be broken—it merely prevents additional users from being able to log on.

Encryption

The required level of encryption can be set at the connection level, affecting all sessions on the connection. The encryption levels are self-explanatory, except for “Basic.” Basic encryption is not really secure and should not be used if you care about protecting your environment. Encryption is detailed fully in the “Network Security” section of this chapter.

Use Default NT Authentication

Checking this box forces user authentication to occur through the standard Windows authentication DLL, msgina.dll.

For example, if you install the Novell NDS Client on your MetaFrame server, the Novell client authentication and logon DLL (nwgina.dll) will replace the Microsoft DLL. This is why the “Press CTRL+ALT+DEL” logon screen is a Novell screen instead of the standard Microsoft screen after you install Novell’s NDS Client. Checking the “Use default NT Authentication” checkbox will force ICA sessions to be logged on via the Microsoft client when that connection is used.

This is useful if you have two groups of users that connect to the same MetaFrame XP server. You can create two separate connections—one for each group of users. One connection (“ICA-IPX”) for users that use the IPX protocol, can have the “Use Default NT Authentication” box unchecked, allowing them to logon with the Novell authentication. The other connection (“ICA-TCP”) will be for users connecting via the TCP/IP protocol. This connection should have the box checked, forcing users to authenticate via the Microsoft logon DLL.

It should be noted that the end user experience is the same, regardless of whether the “User default NT authentication” box is checked or unchecked. The ICA client only passes the basic authentication parameters to the MetaFrame XP, and this checkbox merely specifies which DLL handles those parameters after they are received by the server. See Chapter 8 for more information about the GINA DLL.

Specifying an Initial Program to be Executed

A MetaFrame XP server connection can be configured to set the initial program for every user that connects via the connection. Setting the initial program at the connection layer functions in the exact same way as setting it for one specific user, except that the connection layer setting applies to all users on that connection, without exception. As soon as the user logs on, the specified program is run. As soon as the user closes that program, he is automatically logged off. At no time will the user ever see a desktop unless the desktop is specified as the initial program to run.

Specifying an initial program that is executed is a good way to lock down your server if all users will only need to use one program. The nice thing about it is that users still need to authenticate before the program is run (unless the AutoLogon is configured).

The downside to it is that since this is set at the connection layer, the initial program will affect everyone who connects, including administrators.

In the real world, setting the initial program at the connection level is most useful for MetaFrame XP servers that serve as public terminals or kiosk devices. In these cases, administrators often connect via a different protocol (such as RDP), ensuring that it is not possible to run any other application from the kiosk client devices.

As an interesting side note, even if a user connects to a published application over a connection that has the initial program specified, the initial program will run, not the published application. When the user closes that initial program, the connection is terminated. As you can see, when an initial program is specified, it doesn’t matter how the user connects (full desktop or published application), the user will always run the program specified in the initial program setting.

Only Run Published Applications

Instead of forcing all users on one connection to run one specific program, you can require that all users only run published applications. Checking this box will prevent users from connecting to the server’s desktop directly, unless the desktop is a published application.

Checking this box does not set any file or system-level security. For example, if this box is checked, but explorer.exe is a published application, a user could use explorer to run additional, non-published applications.

Full details of the security of applications on MetaFrame XP servers can be found in the preceding section of this chapter, “Application Security.”

Session Shadowing

Basic session shadowing parameters can be set at the connection layer, such as whether shadowing is enabled and what type of notification or input the shadowed sessions have. Many organizations choose to set different shadowing parameters for different connections. Refer to the “Administrative Environment” segment of this chapter for more information on session shadowing.

TCP Port Used for ICA Sessions

By default, MetaFrame XP servers accept inbound ICA sessions via TCP port 1494. For added security, some administrators like to change this port number. This port can be changed in the registry in the following path:

Key: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations \ICAConnectionName\

Value: PortNumber

Type: REG_DWORD

Data: Port number in hex (default 1494 = 5D6)

The “ICAConnectionName” in the above registry path is the name of the ICA connection you would like to change, for example “ICA-TCP.” Because the ICA port configuration is a connection layer setting, you can configure different ports for different connections. After changing this port number, you need to stop and start the IMA service.

Remember that if you change the ICA port on the server, you must also change the port that the ICA client looks for.

In the real world, very few people change the ICA port, mainly because there are plenty of other security measures that can provide excellent security without the need to change the ICA port and they don’t want to deal with configuring all of their ICA clients to use a nonstandard port. “Security through obscurity” has never worked well for anything.

Connection Permissions

In addition to the parameters of server connections that we reviewed previously, you can set user permissions separately for each connection. (Citrix Connection Configuration Utility | Right-click on connection | Permissions)

This allows you to specify user and group permissions at the connection layer, with the permissions affecting the configured users for each connection. You can select any user or group and then give them Guest, User, or Full Control for a given connection. You can also give a user or group “No Access” by unchecking every box.

In the event of a conflict (one user belonging to multiple groups with different permission levels), the most restrictive permissions apply.

It is important to understand that these permissions only affect the one connection where they are applied. It is possible for one user to have “Full Control” rights on one connection and “No access” rights to another.

Clicking on the “Advanced” button allows you to create granular permissions as needed. This does not allow you to give any more permissions than you could with the regular guest, user, or full access checkboxes. The “Advanced” button simply allows you to select only the specific options you need. For example, you could give one group “shadowing” permissions without having to give them full access rights. This would be accomplished by clicking the “advanced” button, selecting the group, clicking the “view/edit” button, and selecting the rights needed for that group.

Figure 15.4 Basic connection permission levels

   Guest User Full Control

Logon Rights (basic session use) X X X

Query information about the session X X

Send Messages X X

Connect to a disconnected session X X

Modify connection properties X

Delete the connection X

Reset ICA sessions X

Log off ICA session X

Disconnect ICA session X

Shadow ICA sessions X

For each line-item property, there are two boxes: allow and deny. If you select the deny box, the option is explicitly denied for that user or group, and this “deny” takes precedence over any other allow permissions configured in any other group, similar to the “no access” NTFS permission.

Figure 15.5 Advanced connection permission properties

Advanced Permission Allows the User or Group to...

Query Information Obtain information about the current session

Set Information Configure connection parameters

Reset Reset other peoples’ sessions

Shadow Shadow other users(1)

Logon Connect via selected connection

Logoff Log off other users

Message Send popup messages to other sessions

Connect Reconnect to disconnected sessions

Disconnect Disconnect other peoples’ sessions

Virtual Channels Use ICA virtual channel in a session

(1) Note: If shadowing permissions are configured that do not give users shadow rights, the users can still shadow themselves. There have been instances where helpdesk personnel without shadowing rights would ask an end user for their name and password. With that, the helpdesk people could log on as that user and then shadow them, even though the user was not given shadow rights.

In the past, some people have recommended that you disable the RDP connection. While doing this would minimize your security risk, it actually increases your overall risk, because if there is a problem with your MetaFrame XP server that prevents an ICA session from connecting, you have no recourse unless you are physically located near the server. In the real world, most people choose to leave the default RDP connection active, but to configure the permissions so that only administrators are able to connect. That way you protect the connection while giving your own group a back door connection in case of trouble. (Of course if your administrator account is called “administrator” and its password is “password,” keeping RDP active is a valid risk. If this is the case in your environment, you should put this book down and pick up a copy of Security for Dummies.)

Strategies for Using Multiple Server Connections

MetaFrame XP server connections can be used in creative ways to provide different types of security. All security configuration settings that are applied at the connection layer apply to all users that connect via the same protocol pair. However, there is nothing to say that you can’t have more than one connection for each protocol.

If you put multiple network cards in a MetaFrame XP server, you can create multiple ICA-TCP connections, one for each card. To do this, change the LAN adapter for the connection’s properties (Citrix Connection Configuration | Right-click the connection | Edit). Change the LAN adapter from “All network adapters configured with this protocol” to just the network adapter that you want to use. Then create a new connection for the other LAN adapter. Because each network card will have a different IP address, each connection will be accessible via a unique IP address and therefore a unique DNS name.

This will allow you to have a completely different set of properties for the same server, each accessible via its own unique address. This is useful if you want to provide different groups of users access to the same server, but you want different connection–layer settings to apply to each group. One group could access server1.yourcompany.com and the other group could access server2.yourcompany.com. In reality each would be using a different connection of the same server.

Advantages of Configuring Multiple Connections

 If you need different connection layer settings on one server, this is the only way to do it.

Disadvantages of Configuring Multiple Connections

 You need one physical network card for each unique connection.

 Applications can only be published to the server. You cannot specify the connection over which an application is available.

Connection Configuration in the Registry

Because the connection parameters are properties of the MetaFrame XP servers, these parameters are not stored in the IMA data store. Instead, all of the connection configuration information is stored in the registry in the following location:

HKLM\System\CurrentControlSet\Control\TerminalServer \WinStations\ICAConnectionName

Because this configuration information is stored in the registry, you can allow or deny specific users access to the appropriate registry keys. If a user has the ability to write to this registry key, then he will have the ability to change the parameters of MetaFrame XP connections, regardless of the permissions that are configured in the connection configuration.

Network Security

Any traffic that crosses a computer network is susceptible to being captured and viewed by unauthorized people. Because of this, the networks must be secured. There are two ways that this can be done:

 Protect the physical network connections so that no one can access the network to compromise the data.

 Protect the logical data on the network so that if the data is compromised it is meaningless to the person who found it.

Protecting physical connections is not really practical in today’s world, especially over the Internet. When addressing network security, most people focus on protecting the data that crosses the network. The common approach is “I don’t care if you actually capture my data, because if you do, it will be totally meaningless to you.” The networks over which MetaFrame XP traffic flows are no different than any other computer networks in the world. To secure your MetaFrame XP network, you need to look at two components:

 Network data security. (Encryption)

 Network perimeter security. (Firewalls)

Let’s begin by examining your MetaFrame XP network’s data security.

MetaFrame XP Network Data Security / Encryption

In MetaFrame XP environments, there are multiple types of network communications that need to be secured. Figure 15.6 shows all of the various network communications that take place in a standard MetaFrame XP environment. Each of the five arrows in that diagram represents a network segment that has data that must be protected. As we analyze the security of these links, we’ll break them down into “front-end” and “back-end” network communications.

Figure 15.6 MetaFrame XP Network Segments

 

As you can see in Figure 15.6, the front-end communication includes all of the traffic that travels between client devices and the servers; the back-end communication includes all of the network traffic that travels between the various server components. Let’s analyze the security needs of each of these network communication links, starting with the front-end. As we analyze these, we will refer to each network segment by its number in Figure 15.6.

Segment 1. Client Device Web Browser to NFuse Web Server

The network connection between the end user’s web browser and the web server is usually a very susceptible connection because it often travels the public Internet. When we look at security on this connection, we’re only concerned with the actual NFuse web traffic. We are not concerned about ICA traffic because after an ICA session is launched via NFuse the network connection moves from the web server (Segment #1 in Figure 15.6) to the MetaFrame XP server (Segment #2 in Figure 15.6). We’ll study Segment 2 later.

Even though the client device web browser to the NFuse web server network communication takes place before the ICA session is started, there are several security risks at this point. The main risk stems from the fact that standard web server to web browser HTTP traffic is not secure. When a user logs in to an NFuse web server, his credentials are passed over the standard web connection. If that connection is not secure, the credentials are not secure. When a user clicks a hyperlink on an NFuse web page to launch a published application, the information for that published application is sent down to the client’s web browser. Again, the standard web connection is used and it must be secure to protect the data. Anything else that traverses this connection, including application set lists, HTML forms data, clear text credentials for launching ICA sessions, and cookies are not secure.

Fortunately, the World Wide Web and web security have been around a lot longer than NFuse and MetaFrame XP. This means that there are standard ways to address this problem. The easiest and most effective way to secure this network segment is to use Secure Socket Layers, or SSL. SSL is a form of encryption used to secure TCP/IP-based communications in everything from online banking to book selling. The encryption process is transparent to the end user.

An Overview of Secure Socket Layers (SSL)

Using SSL is pretty straightforward. As an administrator, you must first purchase an X.509 digital certificate for your web server which contains the web server’s DNS name. This digital certificate is nothing more than a bit of information that positively binds the details of your web server (such as its name) to a public key. As long as the client’s web browser trusts the holder of your public key, then it will trust your web server. This will allow the client to send and receive encrypted information.

In order for client web browsers to trust that your X.509 digital certificate is real, you need to obtain it from a Certificate Authority (CA) that the client web browsers already trust. Examples of widely-trusted CAs include Baltimore, Equifax, GTE, Thawte, and VeriSign. By default, most client web browsers are configured to trust all of the big-name CAs. You can check this out yourself. For example, in Internet Explorer 6 there are dozens of “pre-trusted” CAs (IE6 | Tools | Internet Options | Content Tab | Certificates Button | Trusted Root Certification Authorities).

In order to purchase the X.509 digital certificate from a “pre-trusted” CA, specify the DNS name of your web server, choose the encryption strength (such as 40- or 128-bit), and select the expiration date. After you purchase the X.509 digital certificate, install it on your web server. The exact process varies depending on your web platform, but it usually involves cutting and pasting a really long certificate number into your web server’s administrative console. Once you have installed the certificate, you can enable secure communications on specific (or all) directories for your website. This will allow your web server to securely communicate with your web users, causing the little padlock icon to appear in the corner their IE web browsers.

Because your website will now be secure, your users will need to access it using an address that begins with an https: prefix instead of http:. This is something that you’ll need to think about because in the real world, most users will access your website by typing www.yourcompany.com without any prefix. Today’s web browsers will automatically add the http:// prefix when the user presses enter. However, if the user is trying to access your secure website, they will get an error if they enter the address without the https: prefix. This error occurs because the web browser automatically adds the http:// prefix, creating http://www.yourcompany.com. But, because your web server is now secure, it needs the address in the secure format, https://www.yourcompany.com.

To alleviate this problem, you can create a non-secure web page that automatically forwards users to the secure web page. In our example, we could create a non-secure page called default.asp that contained the one line of code that would forward users to the secure page, complete with the prefix, to https://www.yourcompany.com/secure/login.asp. By doing this, your users can simply type www.yourcompany.com into their browsers and be connected to the secure page. For the non-programmers out there, the default.asp page on an IIS web server would only need a single line of code:

<%response.redirect(“https://www.yourcompany.com/secure/login.asp”)%>

Using SSL encryption will not require you to change your NFuse web site in any way. NFuse does not know (or care) whether or not the connection is secure. You should also keep in mind that once the ICA session is started on the MetaFrame XP server, NFuse, the web server, and the client’s web browser all drop out of the picture—the ICA session is a direct connection between the MetaFrame XP server and the ICA client.

By using SSL encryption on your NFuse web server, anyone, even attackers, will be able to establish a secure connection with your web server. In this case, the SSL encryption is designed to prevent attackers from reading user credentials as they pass by on the network. It is not designed to only allow certain users to connect to your web server.

However, even if an attacker established a secure session with your web server, they would still not be able to get anywhere because the only web page that they would be able to see is the secure NFuse login page that asks them to enter their user credentials. The attacker won’t have any valid user credentials, and so they will not be able to continue. Furthermore, the attacker won’t be able to read anyone else’s credentials because the other users’ credentials are encrypted with SSL as they are passed over the network to the web server. This SSL encryption is the same method that every commercial site uses, including online banks, brokers, and the Social Security Administration.

Advantages of Protecting Web Traffic with an X.509 Certificate

 SSL is the industry standard for TCP/IP web site encryption.

 Users can use any standard web browser. No specialized VPN client software is needed.

 X.509 Certificates are available from several vendors.

 The complete process is transparent to the end user.

Disadvantages of Protecting Web Traffic with an X.509 Certificate

 X.509 certificates can be expensive, anywhere from US$100 to US$1000 per year.

 Requires extra configuration of the web server.

 Multiple web servers with their own addresses each require their own X.509 digital certificates.

Segment 2. PN Agent Client to NFuse Web Server

32-bit Windows clients that use the Program Neighborhood Agent ICA client get all of their configuration information from the config.xml file located on an NFuse web server. By default, this communication is an unencrypted HTTP transfer. If the PN Agent clients must cross public networks to receive their configuration information, it is possible to configure them to use SSL encryption. Configuring SSL encryption for the PN Agent clients can be done in two simple steps:

1. Secure the NFuse Web Server. Because the PN Agent uses NFuse, you must configure your NFuse web server to be able to use SSL encryption. This means that you must have an X.509 certificate for your web server, as outlined in the previous section. Once you have this, you can configure the “PNAgent” web directory to only be accessed via secure sessions. This directory contains all of the PN Agent files.

2. Change the PN Agent configuration URL prefixes to “https.” The easiest way to do this is to edit the config.xml file. Full details of that file are covered in Chapter 11, but for the purposes of security, all you need to do is find all of the URL links and change the prefixes from http to https. You can use your text editor’s “find and replace” function to do this. All in all, there should be a total of four URLs that you need to update. Each of the following sections of config.xml has a “Location” tag that contains the URL:

 FolderDisplay | DesktopDisplay | Icon

 ConfigurationFile

 Request | Enumeration

 Request | Resource

Once you make these updates, the Program Neighborhood Agent client devices will begin using SSL to download their configurations. As with the SSL used in other areas, each client device must have a root certificate installed for the certificate authority that generated the X.509 certificate for you NFuse web server.

Segment 3. ICA Client Device to MetaFrame XP Server

The ICA session communication usually travels across public networks. In order to secure this network link, there are two aspects of ICA session traffic that we need to look at: ICA session creation and ICA session use.

 Session creation. When an ICA session is created, the user credentials are passed from the client device to the MetaFrame XP server. This poses a security risk because stolen user credentials could be used to invoke pirated ICA sessions. Even worse, because many companies are consolidating their user directories, stolen user credentials from an ICA session could most likely be used to access email or other network resources.

 Session use. While an ICA session is in use, a packet sniffer could be used to capture the ICA session packets. Because these packets contain all the keystrokes that a user types, anything that the user types could be compromised, including passwords.

Incidentally, you’ll notice that during an ICA session, we’re only really worried about the keystrokes, not the screen display data. It is highly unlikely that an attacker could capture the screen shot information from ICA session packets. Screen shot captures would require that the attacker crack the binary ICA protocol, which is highly unlikely. Of course, there are many hacker websites and the Citrix SDK that could change this in the future.

Either way, ICA session traffic must be protected. As with HTTP web traffic, the most effective way to do this is with encryption. Encrypting ICA traffic does not make it any harder for an attacker to obtain, but it does render the data unreadable to an attacker. There are four methods that can be used to encrypt ICA session traffic:

 Create an encrypted tunnel (VPN) between the end user and the server, through which ICA session data flows.

 Encrypt only the ICA traffic with the SecureICA protocol extensions.

 Use the Citrix SSL Relay service to encrypt the ICA traffic with SSL or TLS encryption.

 Use Citrix Secure Gateway to encrypt the ICA traffic with SSL or TLS encryption.

Segment 3 Method 1. Encrypt ICA Traffic with a VPN Tunnel

Third party Virtual Private Networking (VPN) software can be used to create a secure, encrypted “tunnel” from the client device to the MetaFrame XP servers. In these scenarios, each user has VPN client software installed locally on his client machine. This software utilizes the user’s local ISP and the Internet to connect to the corporate office. Once this secure connection is established, a private tunnel is created that connects the local user to the corporate network. The local user can access the corporate network as if he was attached to the network locally. In actuality, the VPN software on the user’s client device connects to the VPN software at the corporate office via the Internet. All traffic that flows back and forth is encrypted by the VPN software. Through this VPN tunnel, the user can launch MetaFrame XP ICA sessions. The ICA protocol itself is not encrypted directly; rather, it is encrypted by the VPN software automatically.

Figure 15.7 An ICA session encrypted via a VPN tunnel

 

Many companies choose to use VPNs like this for their users to access MetaFrame XP applications from remote locations. In most instances, VPN access to MetaFrame XP applications is chosen because the company already has an existing VPN solution in place for remote access to other applications. They can easily extend their existing VPN environment to support MetaFrame XP ICA session traffic from remote users.

The major downfall to these types of VPNs is that the VPN client software must be installed on every single client device. Often the configuration of this client software is complex and users are not able to do it on their own. Also, the platforms on which VPN software runs is usually limited. Many times users with Macintosh computers are not able to use the VPN software. Lastly, because the VPN software must be physically installed before it can be used, it is often difficult to use it on a guest computer.

For example, imagine you were at a friend’s house when your pager went off, notifying you that there was an urgent work–related matter that needed to be addressed immediately. Fortunately for you, your company built MetaFrame XP servers that will allow you to connect from home. You can go to your friend’s PC, log onto the Internet, and begin accessing your MetaFrame XP applications. But, because your company chose to secure their MetaFrame XP servers with a VPN, before you can connect you must first go to your company’s intranet site to download and install the VPN software. Only after this is configured are you able to access your MetaFrame XP applications. When you are done, you uninstall the VPN software from your friend’s computer.

Advantages of Using VPN Tunnels

 All traffic is encrypted.

 Users are not limited to accessing only MetaFrame XP applications.

 If the VPN is already in place, it can be easily extended to support MetaFrame XP.

Disadvantages of Using VPN Tunnels

 VPN software must be installed on every client device.

 VPN software must be configured before it can be used.

 Some clients are not compatible with VPN software.

 Many corporate firewalls block VPN traffic.

 The VPN software costs money, and may be very expensive.

 Some bandwidth is wasted by the VPN tunnel overhead.

Ultimately, VPNs are good solutions if you have users that will use the same computer over and over to remotely connect to your MetaFrame XP servers. VPNs are not good solutions if remote users will need to connect from many different random computers.

In case you are wondering, Citrix used to sell their own VPN software solution called “Citrix Extranet.” While the name of this product suggests that it was a fully integrated solution that combines the benefits of ICA clients and VPN software, Citrix Extranet is little more than a third-party VPN software tool that Citrix OEM’ed from a VPN vendor (V-ONE). Citrix Extranet has been discontinued now that there are better ways of securely accessing remote MetaFrame XP servers. (Keep reading for details.)

Segment 3 Method 2. Encrypt ICA Traffic with SecureICA

Instead of encrypting the entire ICA client to MetaFrame XP server network connection with a VPN solution, it is possible to encrypt just the ICA session traffic itself, as shown in Figure 15.8.

Figure 15.8 Encrypting the ICA session

 

One method that can be used to encrypt ICA traffic is Citrix’s SecureICA protocol extensions. All Citrix ICA clients version 6.01 and above have the native capability to encrypt ICA sessions with SecureICA. For those of you who remember, this used to be a separate purchase option, but it is now a built-in feature in all versions of MetaFrame XP.

The built-in ICA session encryption uses the RSA RC5 encryption model to encrypt ICA session traffic. This encryption scheme uses a 1024-bit key to generate a pair of RC5 keys. From there, 128-bit encryption is used for authentication, with the rest of the ICA session encrypted in both directions at the 40-, 56-, or 128- bit levels (depending on your requirements).

This ICA session encryption can be configured at the server, connection, application, or client device layer. When you configure it, you can choose to enforce minimum encryption levels. For example, you might have a MetaFrame XP server configured to allow users to connect with any level of encryption, but you may publish one sensitive application for which you choose to enforce 128-bit encryption. If a user attempts to connect to that application without an ICA client that can support 128-bit encryption, they will be refused a connection.

This encryption is completely transparent to the user. It does not add any overhead to the ICA network traffic, although it does add a touch of overhead to the server and client processors as they encrypt and decrypt all ICA session data.

If you configure ICA encryption, you will not be able to configure your ICA clients for automatic logon. This is by design, because when automatic logon is used the user credentials are stored locally on the client device and passed to the MetaFrame XP when the session is initiated. This session initiation occurs before the server and client negotiate the secure session so that the credentials are passed in clear text. Citrix figures that if you have configured encryption, there must be a reason, so they don’t let you pass credentials in clear text, which means they don’t let you configure automatic logon when ICA encryption is used.

Advantages of Citrix SecureICA Session Encryption

 Works on any ICA client platform.

 Transparent to the user.

 Easy to configure.

 Can be configured at multiple layers.

 Does not require an X.509 certificate.

The only real disadvantage to using Citrix’s SecureICA encryption is that you need to open a nonstandard port (TCP port 1494, for the ICA session) on your firewall to receive the ICA traffic from the outside clients. This topic will be covered in greater detail in the “Perimeter Security” section of this chapter.

Disadvantages of Citrix SecureICA Session Encryption

 Requires nonstandard ports to be opened on the firewall when ICA clients connect across the Internet.

 Does not verify the identity of the MetaFrame XP server.

Segment 3 Method 3. Encrypt ICA Traffic with the Citrix SSL Service

If you’re using Feature Release 1 for MetaFrame XP and your ICA clients are at least version 6.20, you can use Citrix SSL Relay Service to enable the industry standard SSL encryption to secure your ICA session traffic. With Feature Release 2, this service can also be used to encrypt your ICA sessions with TLS.

This encryption has the same effect as the proprietary Citrix SecureICA encryption except that everything conforms to industry standards when SSL or TLS is used. You’ll probably have more success implementing SSL or TLS ICA encryption than the native ICA encryption because it can communicate via TCP port 443, which is open on most firewalls.

However, with SSL and TLS encryption, the client device must support the level of encryption that you want to use. For example, Windows 2000 clients will need to download and install the Windows 2000 High Encryption Pack in order to use 128 bit encryption.

Advantages of SSL/TLS Encryption with the Citrix SSL Relay

 Industry standard encryption algorithm.

 Does not require any nonstandard ports to be opened on the firewall.

 Supports verification of the identity of MetaFrame XP servers.

 Each MetaFrame XP server can run its own Citrix SSL Service

 Transparent to the end user.

Disadvantages of SSL/TLS Encryption with the Citrix SSL Relay

 Requires Feature Release 1 for SSL and Feature Release 2 for TLS.

 Requires that the client device supports encryption.

 All traffic must flow through a Citrix SSL Relay server which acts like a SOCKS proxy,

 You must add every SSL Relay Server to each client’s server list.

 Requires a dedicated port which cannot be shared with any other SSL services on a MetaFrame XP server.

 Requires an X.509 certificate for each MetaFrame XP server.

 Requires that the client device supports encryption.

 Requires ICA clients version 6.20 or newer for SSL and 6.30 or newer for TLS.

Segment 3 Method 4. Encrypt ICA Traffic with Citrix Secure Gateway

If you’re using Feature Release 2 and NFuse, you can use Citrix Secure Gateway 1.1 to encrypt the ICA sessions with SSL or TLS encryption.

Citrix Secure Gateway is a stand-alone gateway server that acts as the liaison between your ICA clients and your MetaFrame XP servers. ICA clients securely communicate with the Citrix Secure Gateway server (which usually sits behind a firewall) and the Citrix Secure Gateway server communicates with the MetaFrame XP servers.

Advantages of Citrix Secure Gateway

 One X.509 digital certificate can be used for multiple MetaFrame XP servers.

 MetaFrame XP server addresses are hidden from the outside world.

 Industry standard SSL or TLS encryption.

 Does not require any nonstandard ports to be opened on the firewall.

 Supports verification of the identity of the MetaFrame XP servers.

 Transparent to the end user.

Disadvantages of Citrix Secure Gateway

 Requires Feature Release 2.

 Requires that the client device supports encryption.

 Requires ICA clients version 6.30 or newer.

 The ICA session path between the Citrix Secure Gateway server and MetaFrame XP server is unencrypted.

 All ICA session traffic must flow through a gateway server.

How to Use the Citrix SSL Relay Service to Encrypt ICA Traffic

The Citrix SSL Relay Service is a Citrix service that acts as a SOCKS proxy. It receives SSL- or TLS-encrypted data from the ICA clients, decrypts it, and forwards it on to the MetaFrame XP ICA session components of the server. When the MetaFrame XP server needs to send ICA session traffic back to the ICA client, the traffic is routed back through the SSL Relay Service to be encrypted. The SSL Relay Service then sends it on to the ICA client.

Figure 15.9 The Citrix SSL Relay Service in action

 

 

Let’s look at the steps needed to configure the Citrix SSL Relay Service. Once this is configured, your clients can begin to use SSL- or TLS-encrypted ICA sessions. There are seven steps that you need to perform to make this happen:

Step 1. Obtain an X.509 digital certificate.

First obtain an X.509 digital certificate for each MetaFrame XP server that will use SSL or TLS–encrypted ICA sessions.

If the MetaFrame XP server that you are using for the Citrix SSL Relay Service is also running an SSL–secured web server, you can use the same X.509 digital certificate that your web server uses. However, if you already purchased an X.509 digital certificate for your web server but your web server is not the same physical server that you are using for the Citrix SSL Relay, then you will need to purchase an additional X.509 digital certificate for the SSL Relay server, because each digital certificate is server–specific.

You have two options for obtaining the X.509 digital certificates needed for the SSL Relay service on your MetaFrame XP servers. You can either purchase a certificate from a professional certificate authority or you can build your own certificate authority and issue you own certificates.

Option 1. Buy a Digital Certificate

Your first option is to buy an X.509 digital certificate from a real certificate authority. Send the details of each of your SSL Relay servers to the certificate authority and give them some money. They will send you back a digital certificate which will be nothing more than a computer file that contains some information about your server and a very long string of numbers. Because you bought this certificate from a real certificate authority, most client devices or web browsers worldwide will trust that your certificate is valid. Windows clients automatically trust almost every big-name certificate authority. For non-Windows clients, Citrix includes the root certificates (trust) for VeriSign and Baltimore Technologies in the ICA client software.

Advantages of Buying a Certificate from a Real Certificate Authority

 If you buy your certificate from a big name certificate authority, all of your clients will trust it without any additional configuration on your part.

 Clients can connect from guest computers and begin using secure applications immediately.

Disadvantages of Buying a Certificate from a Real Certificate Authority

 You must pay for each certificate.

 There may be a delay in receiving new certificates.

Option 2. Create your own Certificate Authority

Instead of buying certificates from someone else, you can create your own root certificate authority and issue your own X.509 digital certificates. Pick a server in your environments and install a certificate authority service. For example, in a Windows 2000 server, you install a certificate authority just like any other Windows component (Control Panel | Add/Remove Programs | Add/Remove Windows Components | Certificate Services). When you install this component, it will ask you for the details of your certificate authority, including your name, its name, and the desired expiration period for the certificates that you will issue. (See Microsoft article Q231881 for a Certificate Services “How-To” guide.) It doesn’t really matter what you enter into these fields. They don’t affect anything except the data contained in the certificates that your server issues.

The certificates that you issue with your certificate authority are technically no different than the certificates that a real certificate authority would issue. The only difference is the source. Instead of being issued by “VeriSign,” your certificate would be issued by “Brian’s Citrix Certificates,” or whatever name you choose when installing your certificate authority service.

This is important because every client device in the world trusts “VeriSign,” but no client device in the world trusts “Brian’s Citrix Certificates.” In order to get a client device to trust you, you must install your root certificate (or your new certificate authority’s root certificate, in this case). Windows 32-bit ICA clients automatically use the root certificates that are installed into Internet Explorer. Other platforms require that you install the root certificates into the ICA client software itself. Once your root certificate is installed on a client, the client device will trust you, which means that it will trust any certificates that you create. Therefore you can use your certificate authority to mass-produce the X.509 certificates that you need for each MetaFrame XP server that will run the Citrix SSL Relay Service.

Advantages of Creating your own Certificate Authority

 No cost for your certificates.

 You can configure the expiration date and encryption strength of each certificate.

 Fast turnaround time when new certificates are needed.

 You can push your certificate authority’s root certificate out with an Active Directory policy or the Internet Explorer Administration Kit.

Disadvantages of Creating your own Certificate Authority

 Your certificates will not be automatically trusted.

 If you lose your certificate server, no new clients will be able to trust the old certificates.

 If a user connects from a new machine, they will have to first install your root certificate before they can securely communicate with you.

Now that you’ve decided how you will obtain your X.509 digital certificates, let’s continue stepping through the process needed to use SSL to encrypt ICA sessions.

Step 2. Configure the SSL Relay TCP listener port.

Configure the TCP port that the Citrix SSL Relay Service will listen on (Start | Programs | Citrix | MetaFrame XP | Citrix SSL Relay Configuration Tool | Connection Tab | Relay Listening Port). By default, this port is 443, which is the industry standard SSL port. In most situations, 443 should work fine. However, the Citrix SSL Relay Service cannot share its port with any other service. This means that if the SSL Relay is installed on the same server that hosts secure web pages via port 443, you will have to change one of them. If you choose to change the Citrix SSL Relay port, you will need to configure your client devices to use the nonstandard port. If you change the web servers SSL port, then your users or hyperlinks will have to refer to the new port in the web address when they request secure pages. For example, if you change the SSL web server port from 443 to 4443, you users will need to request the port number when opening a web page, such as https://www.yourcompany.com:4443.

Step 3. Copy the digital certificate to the SSL Relay server.

Once you configure the SSL Relay port, copy your X.509 digital certificate onto the MetaFrame XP server that is running the SSL Relay Service. Remember that each digital certificate is server–specific and tied to that server’s DNS name, so you can’t use the same certificate twice and you can’t mix them up.

Copy the certificate to the SSL Relay certificate directory on your MetaFrame XP server. By default, this directory is %systemroot%\sslrelay\ keystore\certs. You can change this path with the SSL Relay Configuration Tool (Citrix SSL Relay Configuration Tool | Relay Credentials Tab | Key Store Location). When you specify the path in the configuration tool, you must specify a directory that has two subdirectories under it: \cacerts and \certs. You need to copy your certificate into the \certs directory.

The Citrix SSL Relay Service needs to have a certificate that is in the Personal Electronic Mail (PEM) format. A PEM certificate will have the file extension .pem.

Often , you will receive certificates that are not in the PEM format. They may be in other formats that have different file extensions, such as .CER or .PFX. In order to use these types of certificates, you will need to convert them into the PEM format. You can convert certificates to the PEM format with the keytopem.exe utility, located in the %systemroot%\sslrelay directory of your MetaFrame XP server. To use the conversion utility, open a command prompt and type:

keytopem sourcecertificate.cer newcertificatename.pem

Sourcecertificate.cer is the name of your existing certificate and newcertificate.pem is the name you want for the newly-converted PEM certificate. When you convert your certificate to PEM format, you should always specify the file extension PEM.

If your MetaFrame XP server running the SSL relay is also running an IIS web server that already has an X.509 digital certificate, you can export IIS’s certificate for use by the SSL Relay Service (MMC | Add Snap-In | Certificates (for the local computer) | Double click certificate | Details tab | Copy to File button). You must remember to convert the certificate to PEM format after you copy it. Also, remember to configure either the SSL Relay or IIS so that they are both not trying to use port 443.

Step 4. Configure the SSL Relay to use the digital certificate.

Once the digital certificate is copied to the MetaFrame XP server, configure the Citrix SSL Relay Service to use your new certificate (Citrix SSL Relay Configuration | Relay Credentials). Choose your certificate from the drop-down list and enter the password if needed. Once you click “OK,” the Citrix SSL Relay Service will be installed and started on that server. This service works just like any other service. It will show up in the list of Windows services.

Step 5. Verify the SSL Relay Cipher Suites.

After the certificate is installed, you should verify that you have the correct cipher suites enabled (Citrix SSL Relay Configuration Tool | Ciphersuites tab). A cipher suite is a specific encryption/decryption algorithm. When using SSL, the client and server look at all the available cipher suites and mutually agree on one. Different cipher suites have different properties, such as encryption strength or speed. Any client that connects to the Citrix SSL Relay Service must support at least one of the cipher suites that you have enabled. There is no way to add additional cipher suites. By default, the Citrix SSL Relay Configuration enables all of the available cipher suites, which should be fine for most environments.

Step 6. Configure SSL Relay target addresses.

Once the certificate is installed and the service is running, you need to edit the target addresses for the SSL Relay Service (Citrix SSL Relay Configuration Tool | Connection Tab). The SSL Relay only sends decrypted packets to IP addresses and ports listed here. By default, the local server’s primary IP address and the Citrix XML service port are listed.

Since you want to use the SSL Relay Service to send decrypted ICA packets to the local MetaFrame XP server, you need to add the TCP port that ICA uses, which is 1494 unless you changed it (Highlight the IP Address | Click “Edit” | Type in new destination port 1494 | Click “Add” | Click “OK”). When done, you should see both the XML service port (default 80) and the ICA service port listed next to your server’s IP address.

Configure the SSL Relay service to forward packets to any host or any port by clicking the corresponding “Any” button when you are adding an address or port. However, by doing this you increase the risk that unencrypted data will be sent to the wrong location.

Step 7. Configure your ICA client devices to use SSL for ICA encryption.

After you’ave performed the previous six steps, your MetaFrame XP server will be ready to support SSL– or TLS-encrypted ICA sessions. The only thing left to do is configure your ICA clients to connect via SSL. For information regarding specific client configurations, refer to Chapter 10. If you’re using NFuse Classic or the Program Neighborhood Agent to provide access to your MetaFrame XP servers, you are in luck because you can change the ICA client settings centrally. Once you make the change, all client devices automatically receive the new settings the next time they connect. Let’s take a look at what it takes to configure NFuse Classic and the Program Neighborhood Agent to communicate via SSL-encrypted ICA sessions. We’ll start with NFuse.

Configuring NFuse to use SSL Encrypted ICA Sessions

Remember that NFuse Classic’s main role is getting ICA sessions started. You can enable SSL encryption of your ICA sessions by setting just one configuration item. Edit the NFuse.conf file on your NFuse web server. Refer to Chapter 11 for details on this file. Locate the “AddressResolution Type” setting. Ensure that its value is set to DNS (or DNS-port if your ICA protocol is configured for a port other than 1494). The new line should look like this:

AddressResolutionType=DNS

As with all NFuse settings, you will need to stop and start the web server service for this change to take effect. This change will ensure that the MetaFrame XP server addresses passed to clients are the full DNS names instead of the IP addresses.

Configuring the PN Agent to use Encrypted ICA Sessions

Configuring the Program Neighborhood Agent to use SSL encryption for ICA sessions is easy. If the published application is configured to use SSL (CMC | Right-click Published Application | Properties | ICA Client Settings Tab | Enable SSL), the PN Agent will automatically use SSL.

How to use Citrix Secure Gateway to Encrypt ICA Traffic

A Citrix Secure Gateway (CSG) server can support thousands of users simultaneously accessing multiple MetaFrame XP servers as seen in Figure 15.10.

Figure 15.10 How CSG is used

 

Using CSG is completely transparent to your users. In fact, because it’s so easy to use, CSG is widely thought of as the “VPN” killer. In order to understand CSG, let’s take a look at how it works.

How Citrix Secure Gateway Works

Citrix Secure Gateway is made up of two components: the Citrix Secure Gateway server and the optional Secure Ticket Authority:

 Citrix Secure Gateway server. This is a dedicated server that acts as the proxy between users and MetaFrame XP servers. Since a single CSG server can interface to multiple MetaFrame XP servers, you can have a fully SSL/TLS-encrypted environment without needing certificates for all of your individual MetaFrame XP servers.

 Secure Ticket Authority. The Secure Ticket Authority (STA) is an optional component of CSG that runs on a separate server. The STA can be used to generate tickets that are sent to the user instead of credentials and server information. Using a STA renders an intercepted packet useless, since it would only contain a temporary ticket number instead of real data. To see how this works, let’s take a detailed look at how CSG functions.

In most environments, CSG is used in combination with NFuse Classic. For this reason, you’ll notice that the first several steps that take place to start an application in a CSG environment are identical to when they are started in NFuse Classic environments.

Figure 15.11 Citrix Secure Gateway in action

 

1. A user with a web browser and an ICA client requests the NFuse Classic portal web page by typing in a URL.

2. The web server sends down the HTML login page via the HTTP protocol. In secure environments, this can be via the HTTPS protocol.

3. The web user types in their credentials and clicks the “Submit” button which sends them to the web server.

4. The web server forwards the user’s information to a MetaFrame XP server running the Citrix XML service.

5. The MetaFrame XP server validates the credentials and retrieves the user’s list of applications for the server farm.

6. The MetaFrame XP server sends the application list to the NFuse web server.

7. The NFuse web server builds a web page that contains all of the user’s application icons. Each icon is hyperlinked with its application properties.

8. The web page is sent to the user’s browser via the HTTP or HTTPS protocol.

9. The user selects an application to run by clicking on an icon in the web browser.

10. The web browser sends a request to the web server for the link that the user selected.

11. The NFuse Java Objects on the web server receive the request for the application. They forward the request on to the Citrix XML service running on a MetaFrame XP server.

12. The Citrix XML service returns the IP address of the least-loaded server.

13. The NFuse Java Objects send the IP address to the Secure Ticket Authority (STA).

14. The STA saves the IP address into memory and generates a random ticket number.

15. The STA sends the ticket number to NFuse.

16. NFuse retrieves the ICA file template. The ticket number is added to the ICA file in place of the user’s credentials. The fully qualified domain name or DNS name of the Citrix Secure Gateway is added in place of the MetaFrame XP server.

17. The custom-built ICA file is sent to web browser on the client device.

18. The web browser receives the ICA file and passes it to ICA client software that is also loaded on the ICA client device.

19. The user’s local ICA client starts the MetaFrame XP session with the information contained in the custom ICA file. Since the server specified is the Citrix Secure Gateway, the client contacts the CSG.

20. The SSL/TLS handshaking process takes place. The ICA client verifies that the CSG is valid based on its installed root certificate.

21. The CSG passes the ticket number to the STA.

22. The STA examines ticket and (if it’s valid), sends the IP address of the MetaFrame XP server to the CSG.

23. The CSG establishes an ICA session with the MetaFrame XP server. The CSG then encrypts and decrypts the ICA session traffic, passing decrypted traffic to the MetaFrame XP server and encrypted traffic to the ICA client.

As you can see, the way that the Citrix Secure Gateway works is pretty simple. Let’s now take a look at how you can get it installed in your environment.

Step 1. Install the (Optional) Secure Ticket Authority

We mentioned previously that using the STA with CSG is optional. While this is true, the advantages of using the STA far outweigh the disadvantages. Before we look at how the STA is installed, let’s take another look at how CSG works with a focus on how the STA helps to secure the environment.

Think back to how NFuse works. After a user logs in, they click a hyperlink to launch an ICA session. The NFuse web server builds a custom, dynamic, behind-the-scenes ICA file and sends it down to the client. That ICA file has the user’s credentials imbedded into it since the NFuse server remembered the user’s credentials because an NFuse Session Object was set when the user logged into the NFuse web page. The user’s local ICA client software then launches the ICA session with the information (and credentials) from that ICA file.

This leaves a gaping security hole. Instead of clicking an NFuse application hyperlink to launch an application, a savvy end user could right-click the link, choose “Save target as...” from the context menu, and save a local copy of the ICA file. That ICA file could then be used to access the application at any time. Even worse, because that ICA file contains that user’s credentials, it could be passed around and used by any user.

To combat this shortcoming, Citrix Secure Gateway uses the Secure Ticket Authority to create tickets. Ticketing was first introduced with NFuse 1.5 several years ago, and CSG ticketing is still based on that technology. Remember from Figure 15.11 that when CSG and STA are used, the user clicks on a hyperlink to launch an ICA session from the NFuse web page and the NFuse server builds a custom ICA file for the user, as usual.

However, instead of placing the user’s credentials and the target MetaFrame XP server in the ICA file, NFuse sends the information to the STA. The STA then creates a totally random 30-character string called a “ticket” that it associates with those specific credentials. The STA maintains a list in memory that maps authenticated users, their servers, and their ticket numbers. It then returns the ticket to the NFuse web server.

When the ICA file is created and sent down to the user’s client device, it contains the 30-character ticket instead of the actual user credentials. It also contains the name of the CSG as the server instead of the actual MetaFrame XP server. When the client device receives the ICA file, an ICA session is launched as usual. The ticket number is sent to the CSG server, and that server communicates with the STA to retrieve the actual user credentials based on the user’s ticket number.

By using ticketing, a user’s real credentials are not sent across the network multiple times and they are not placed in the ICA file. But wait! It gets even cooler for the following two reasons:

 Tickets are configured with a timeout period.

 Tickets are only valid for one time use.

Every ticket is configured with a timeout period (based on settings of the STA server). Once a certain amount of time passes after the ticket has been created, the STA destroys the ticket along with the associated user credentials. For example, if the timeout is set for 100 seconds, a user that “right-click” captures the dynamic ICA file from the NFuse web page will not be able to use that file after 100 seconds have passed because the STA server would not have the user credentials associated with the ticket number contained in the ICA file.

One of the great things about this timeout feature is that the ticket timeout period begins when the ticket is created. The ticket is created when a user clicks a hyperlink to launch an ICA session, not when the user first accesses the application list webpage. Because of this, there is no risk that a user will log in to the web page and then wait too long, causing the ticket to expire.

The other major advantage to using the STA for ticketing is that each ticket can only be used once. After a user logs on with a ticket, the STA destroys the 30-character ticket and the associated user credentials. Therefore, even if the timeout for tickets has not expired, a single NFuse-generated ICA file cannot be used by multiple users.

Advantages of STA 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 STA Ticketing

 Unencrypted data is still sent over the network once.

 NFuse is required.

In reality, the Secure Ticket Authority is nothing more than a DLL installed into the \scripts\ directory of an IIS web server running on Windows 2000 with Service Pack 2 or newer. When you install it (from the “Components” section of the main MetaFrame XP SP-2/FR-2 splashscreen), you will need to know the path to your IIS scripts folder (%systemroot%\inetpub\ scripts by default).

As soon as the STA is installed, the STA configuration tool is launched. You will need to specify an STA ID that is a unique character string made up of a maximum of 16 uppercase and numeric characters. This ID is used to differentiate multiple STA servers in your environment. This name doesn’t really matter, and the default of “STA01” should be fine.

If you click the “advanced options” of the STA configuration screen, you are also given the option to specify the timeout period of the tickets that this STA generates and the maximum number of concurrent tickets that can be generated.

By default, the ticket timeout is 10000 milliseconds, or 100 seconds. This should be acceptable for most environments, although you can change it at any time if you need to (Start | Programs | Citrix | Citrix Secure Gateway | Secure Ticket Authority Configuration).

The STA is configured by default for a maximum of 100,000 tickets. You can drop this number considerably. Since this number only affects concurrent tickets (not total), it should roughly correspond to the number of users you have. Even with a few users, you can safely drop this number to about 1,000. An entry of 1,000 will be enough tickets that you will never run out but not enough that a brute-force attacker could find a way into your server.

If you use the IIS Lockdown Tool on to secure IIS on your STA server, you should use the same settings that you did for NFuse as outlined earlier in this chapter.

Step 2. Build your Citrix Secure Gateway Server

Once your STA is up and running you can build your CSG server. This server can just be a standard Windows 2000 server with Service Pack 2, although it must be a physically different server from the STA.

The exact hardware requirements vary depending on your exact environment and how bust your users are. However, you’ll be pleasantly surprised to know that CSG scales fairly well. In the real world, you can fit 700-1000 users on a dual 1.0GHz processor CSG server.

Step 3. Obtain and Apply a Digital Certificate

The CSG server is the one that needs a digital certificate. (The STA does not need one, since it doesn’t communicate directly with clients.) Follow Step #1 from the previous section (“How to Use the Citrix SSL Relay Service to Encrypt ICA Traffic”) for detailed instructions about obtaining and installing this certificate.

Step 4. Install the Citrix Secure Gateway Service

You can install CSG from the SP-2/FR-2 splashscreen or by running “csg_gwy.msi.” If you’ve decided to use CSG without using a STA, the CSG will operate in “Relay Mode.” To configure your CSG for Relay Mode, install it using the following command:

Msiexec.exe /i csg_gwy.msi RELAYMODE=1

Step 5. Configure the Citrix Secure Gateway

Similar to the STA installation, the CSG configuration wizard launches as soon as the CSG installation is complete. The main option that you need to configure is the address or addresses of the STA servers that you will use. From a sizing standpoint, even the largest environments only need a single STA server. However, for purposes of redundancy, you can have multiple STA servers. (See Chapter 17 for more information.)

Keep the following points in mind as you configure CSG:

 You need to specify the IP addresses and ports that the CSG will watch. Ordinarily this would be the external interface of the server over port 443.

 The “Worker Threads” option allows you to specify how many threads the CSG service will use. The default value of 8 should work for up to two processors. You should double this to 16 on quad-processor servers.

 The connection timeout that you specify in milliseconds only affects the timeout of the security handshaking process. It does not affect overall session times. The default value of 10,000 (100 seconds) should be sufficient for most environments.

 You should also specify a connection limit to ensure that you do not get too many users on your CSG server. You can specify a connection limit and a resume limit. When the number of concurrent users hits the connection limit, all new connections will be refused until the number of connections falls to the resume limit.

 When you configure CSG, a single server can only support one secure protocol. If you want to support both TLS and SSL, you’ll have to add another CSG server.

 Like the SSL Relay Service, CSG has the ability to use multiple cipher suites. Unless you have direction from your internal security team, you should keep the cipher suite settings configured for “all.”

 When asked to exclude certain IP addresses from the CSG activity log file, think about anything in your environment that might access the server that you do not want to log. You don’t want your CSG logs filling up because someone’s copy of “What’s Up Gold” keeps pinging your CSG server every three minutes.

 When you configure error logging, keep in mind that CSG errors are written to the Windows event log, not to standard log files. If you select one of the more robust logging options, be sure that your Windows event logs can handle the amount of information.

 After you finish configuring CSG, you should reboot it for the changes to take affect.

Step 6. Configure NFuse Classic for use with CSG

If you’re using CSG as it was fully intended (complete with the STA), you’ll need to configure NFuse so that it knows that it should use CSG. As with the other NFuse Classic 1.7 options, you can configure NFuse CSG options via the administrative web pages (NFuse Admin Web Pages | Server-Side Firewall | Secure Gateway Server) or by editing the NFuse.conf file directly. See Chapter 11 for more information about configuring NFuse.

First put the NFuse web server into CSG operating mode. This is done with the following line in the NFuse.conf file:

SessionField.NFuse_CSG_Enable=On

Then, to complete the configuration of NFuse, you need to know the addresses of both the STA and the CSG. You can point a single NFuse web server to up to 256 different Secure Ticket Authorities (in case you want a really redundant environment). This is done via the NFuse session field called “NFuse_CSG_STA_URLx.” (The “x” is a number from 1 to 256.)

For example, to configure two STAs, add or modify the following two lines in the NFuse.conf file:

SessionField.NFuse_CSG_STA_URL1=http://staserver1.yourcompany.com/scripts/CtxSta.dll

SessionField.NFuse_CSG_STA_URL2=http://staserver2.yourcompany.com/scripts/CtxSta.dll

Then, use these two lines in the NFuse.conf file to specify the name and port of the CSG server:

SessionField.NFuse_CSG_Server=yourcsgserver.yourcompany.com

SessionField.NFuse_CSG_ServerPort=443

After you enter these settings, you’re all set. Stop and start the web server service and you can begin using CSG. As you use CSG, you’ll notice that your NFuse web pages (and the entire experience) is the same as when CSG was not used. While this is convenient for your users, you may wonder if CSG is actually doing anything. The easiest way to check this is to go into the ICA connection manager on your client device while you have an ICA session opened. You should see that your session is encrypted via 128-bit encryption.

Securing Back End Network Communications

Thinking back to Figure 15.6, we can now start to look at what needs to be done to secure the back-end network communications. In MetaFrame XP server farms, IMA and XML traffic is passed between various servers. By default, all of this communication is in clear text, unencrypted and unsecured.

Most administrators ignore the back-end network segments when evaluating security. This is usually because they don’t think that there is a need to secure those segments since all of the servers are located in the same data center or within the same corporate network and so are generally considered secure.

However, there are many environments in which a single MetaFrame XP server farm will span multiple locations, causing back-end server communication security to be an issue. Within MetaFrame XP environments, there are four types of backend network communications that can be secured:

 Segment 4. NFuse web server to the MetaFrame XP XML server.

 Segment 5. MetaFrame XP farm servers to the IMA data store.

 Segment 6. MetaFrame XP farm servers to the zone data collector.

 Segment 7. The Citrix Management Console to the MetaFrame XP host server.

Segment 4. NFuse Web Server to MetaFrame XP Server

NFuse web servers must communicate with the MetaFrame XP IMA service in order to build lists of published applications and content for users that log in. The NFuse servers access this data from the MetaFrame XP servers via the Citrix XML service. Much of this data is sensitive in nature, including user credentials and application set information. By default, this information is not encrypted (with the exception of passwords, which are encrypted at a basic level). Because this is standard XML information, it can be very easy to read if intercepted.

If you determine that the network segment between your NFuse web server and your MetaFrame XP server is not secure, there are two things that you can do:

 Encrypt the Citrix XML traffic on the network segment with SSL or TLS.

 Remove the network segment by running the NFuse web server on a MetaFrame XP server.

Method 1. NFuse Web Server to MetaFrame XP Server SSL Encryption

In scenarios in which a public, unsecured network separates the NFuse web server and the MetaFrame XP server, you can configure NFuse so that all traffic traveling between the two servers is encrypted. Remember that NFuse 1.7 can be configured to communicate with multiple MetaFrame XP servers for load balancing. In this case, X.509 digital certificates service must be installed and configured on each MetaFrame XP server that communicates with the NFuse web server.

To allow NFuse to use SSL encryption for its communication with the Citrix XML service, all you have to do is edit the NFuse.conf file on your NFuse web server. See Chapter 11 for detailed information about NFuse and the use of this file.

With NFuse 1.7, you have two choices for encrypting this traffic. If you’re running the Citrix SSL Relay service, locate the following line in the NFuse.conf file:

SessionField.NFuse_Transport=HTTP

Change the “HTTP” to “SSL,” so that the line looks like this:

SessionField.NFuse_Transport=SSL

Then, in order to specify your Citrix XML servers running the Citrix SSL Relay service, add the following two lines:

SessionField.NFuse_RelayServer=yourserver

SessionField.NFuse_RelayServerPort=443

Alternately, if you are not using the Citrix SSL Relay service, you can change the transport setting to “HTTPS,” so that the line looks like this:

SessionField.NFuse_Transport=HTTPS

With the “HTTPS” setting, NFuse will use the regular Citrix XML servers and ports that you specified in the SessionField.NFuse_CitrixServer and SessionField.NFuse_CitrixServerPort lines.

Just as with any other changes that you make to the NFuse.conf file, you must stop and start the web server service for these changes to take affect.

Advantages of Encrypting the NFuse to MetaFrame XP Link

 Ultimate security.

 Works well when NFuse and MetaFrame XP servers are on opposite sides of an unsecured network.

Disadvantages of Encrypting the NFuse to MetaFrame XP Link

 Extra configuration is needed.

 One X.509 certificate is needed for each MetaFrame XP server that communicates with NFuse.

 Security is usually not needed at this level because most communication is intra-site, or site-to-site with private, secure lines.

Method 2. Use the Same Server for NFuse and MetaFrame XP

A simple way to eliminate the risk of a network segment attack between the NFuse web server and the MetaFrame XP server is to eliminate that network segment altogether. You can do that by running the NFuse web server on the same physical machine as the MetaFrame XP server. When you do this, the Citrix XML service is still used, but there is no need for its data travel to across the network.

Advantages of Running NFuse on a MetaFrame XP server.

 Inexpensive.

 Secure.

Disadvantages of Running NFuse on a MetaFrame XP server.

 Does not scale very well.

 Single point of failure.

 Does not allow the web pages and the SSL encrypted ICA sessions to both use the default TCP port 443.

Segment 5. MetaFrame XP Server to the IMA Data Store

All communication between MetaFrame XP servers and the IMA Data Store is done via standard database communication traffic. There is nothing of particular value in this communication, but it can be encrypted if needed. If you decide to encrypt, you must do it with the native ODBC database tools and software. The database communication encryption is not a feature of MetaFrame XP.

Segment 6. MetaFrame XP Server to Zone Data Collector

All zone update information is transferred between zone data collectors and MetaFrame XP servers via TCP port 2512. This communication is also done in clear text. However, this information does not contain any potentially dangerous information; it is not valuable to attackers. If you must encrypt it, then do it with non-MetaFrame products, such as a VPN or IPSec.

Segment 7. CMC to MetaFrame XP Host Server

The CMC communicates over TCP port 2513. This communication is done in clear text, and it contains logon information including the CMC user’s name and password as well as any configuration done through the CMC, such as group rights and published applications.

This security risk can be avoided by running the Citrix Management Console locally on MetaFrame XP servers. It can be made available to remote administrators by publishing the CMC itself as an explicit ICA application. In doing so, the standard ICA session security procedures will be used. See Chapter 16 for details about publishing the CMC.

Network Perimeter Security / Firewall Configuration

In this section, we won’t spend time talking about the importance of firewalls and why you need them. The truth is that most environments have them. We only care about using them with MetaFrame XP. There are really three questions that get asked when using firewalls in MetaFrame XP environments:

 Where should I put the MetaFrame XP servers in relation to the firewall?

 What ports do I need to open on the firewall?

 How do I make the MetaFrame XP servers work if the firewall is using Network Address Translation (NAT)?

Let’s examine each of these questions.

MetaFrame Server Placement in Relation to the Firewall

When deciding where to put MetaFrame XP application servers that will provide ICA access to applications across the Internet, there are three basic options:

 MetaFrame XP servers outside the firewall.

 MetaFrame XP servers inside the firewall.

 MetaFrame XP servers in a DMZ.

Option 1. MetaFrame XP Servers outside the Firewall

Placing your MetaFrame XP servers outside of the firewall exposes them to all the attackers on the Internet. However, if a server is breached, it remains on the outside of the firewall, severely limiting any potential damage to sensitive resources on the inside of the firewall.

Figure 15.12 A MetaFrame XP server outside the firewall

 

This configuration is primarily used when MetaFrame XP applications are stand-alone (do not need to access any data from the inside of the firewall).

A major downside to putting MetaFrame servers on the outside of the firewall is that any MetaFrame XP application that accesses resources from servers on the inside of the firewall will need to have a port opened on the firewall. The more ports that are opened increase the likelihood that a breach of the firewall could occur.

Another thing that people worry about is that Microsoft software is not exactly known for being bulletproof. Very few organizations feel comfortable having unprotected Windows servers sitting on the Internet.

Putting MetaFrame XP servers on the outside of the firewall raises complexities if you have users on the inside that need to access the MetaFrame XP servers. Should they go through the firewall in the opposite direction? Should you have a MetaFrame XP server farm that has some servers on the inside and others on the outside? When users from both inside and outside need to access MetaFrame XP application servers, the servers are usually not put on the outside of the firewall.

Advantages of Placing MetaFrame XP Servers Outside the Firewall

 Works well if no internal users will need to access the servers.

 If the MetaFrame XP server is compromised, the inside network is not affected.

Disadvantages of Placing MetaFrame XP Servers Outside the Firewall

 Application holes need to be opened in the firewall.

 It can be difficult for some applications on the MetaFrame XP server to get through the firewall to the resources they need on the inside.

 If users connect to the MetaFrame XP servers with the same user accounts that they use on the inside, they must authenticate to the MetaFrame XP server through the firewall.

Option 2. MetaFrame XP Servers inside the Firewall

Most companies choose to place their MetaFrame XP servers inside the firewall. By doing this, they are leveraging the true definition of the “firewall,” as it will take the brunt of all Internet traffic and attacks.

Figure 15.13 A MetaFrame XP Server behind the firewall

 

This tends to be the most secure of all possible configurations because the only holes that need to be opened on the firewall are for ICA traffic to MetaFrame XP servers.

Advantages of Placing MetaFrame XP Servers Inside the Firewall

 Only the MetaFrame server addresses and ports need to be opened on the firewall.

 Very Secure.

Disadvantages of Placing MetaFrame XP Servers Inside the Firewall

 If the MetaFrame server is compromised, other servers behind the firewall could be compromised.

 The firewall must be configured to allow ICA traffic to flow to the MetaFrame XP servers.

Option 3. MetaFrame XP server in a DMZ

Some firewalls allow for the configuration of a DMZ (Demilitarized Zone). A DMX can also be created with a pair of firewalls. This DMZ is like a combination of the two above methods. The MetaFrame XP servers aren’t totally exposed on the outside of the firewall, but they also do not have free access to devices on the inside of the firewall. In this configuration, no outside traffic has direct access to devices on the inside of the firewall. Instead, the firewall is configured so that outside clients can access only the MetaFrame XP servers in the DMZ. Those MetaFrame XP servers, in turn, can access (through the firewall) network resources on the inside.

Figure 15.14 A MetaFrame XP server in the DMZ

 

Advantages of Placing MetaFrame XP Servers in the DMZ

 Balance between no access and all access.

Disadvantages of Placing MetaFrame XP Servers in the DMZ

 Most complex firewall configuration.

Firewall Ports Configuration for MetaFrame XP Environments

If you decide to put your MetaFrame XP server behind a firewall or in a DMZ, there are several TCP ports that must be configured on the firewall (if you’re not using Citrix Secure Gateway).

Figure 15.15 Firewall port usage

Port Direction Destination Description

1494 Inbound All MetaFrame ICA port needed for ICA Servers sessions Servers

1023 Outbound ICA Client MetaFrame XP will dynamically select a unique port for each ICA session. This port configuration is standard practice on firewalls.

80 Inbound NFuse Web If you are using NFuse, and your NFuse server is behind the firewall, you will need this Server port to allow users to access the website.

80 Inbound Citrix XML This port is needed on one or more MetaFrame XP servers that will be providing the Server on at application lists to external clients. If all external clients will use NFuse, this port will not be least one XP needed. Server

443 Inbound NFuse Web If you are using an SSL connection to an internal NFuse server, or you are encrypting Server or ICA traffic via SSL, then this port is needed. SSL session encryption uses this port in XP Server place of 1494.

Network Address Translation at the Firewall

Most companies that use firewalls configure them to do Network Address Translation (NAT). This allows internal servers to be configured with private IP addresses that are not valid to the outside world. Because all network traffic between the inside servers and the outside world is channeled through the firewall, the firewall maintains two addresses for each server. One address is valid to the outside world; the other address is valid to the inside network. When a request for the server hits the firewall from the outside, the firewall translates the address to the internal address of the server before passing it on to that server. Just the same, when the internal server sends network data to an external address, the firewall changes the existing sender’s address (the server’s internal address) to the server’s valid external address. The server has no idea that its address is not valid to the outside world. Using NAT allows servers on the inside to be protected from the outside world by forcing all communication to travel through the firewall.

Figure 15.16 Network address translation at the firewall

 

 

 

The advantage to using NAT is that because the internal IP addresses of the servers are not valid on the outside, it is technically impossible for an attacker to find a “back door” into the network. All traffic must flow through the firewall because the internal addresses are not valid to the rest of the world. Also, by using NAT, companies do not have to register the IP addresses for all of their internal devices.

In non-MetaFrame XP environments there are usually no issues with NAT because the internal server has no need to know that its IP address is being changed by the firewall. This is not the always the case in MetaFrame XP environments. To understand why, let’s consider the following scenario.

A Citrix ICA client device connects to a MetaFrame XP server via the Internet. The MetaFrame XP server is accessible to the Internet via the IP address 128.242.82.212. A firewall running NAT sits between the Internet and the MetaFrame XP server. The MetaFrame XP server’s IP address is configured to be 10.1.1.1. The firewall automatically translates between the two IP addresses for traffic going between the Internet and the MetaFrame XP server. This scenario is outlined in Figure 15.17 (facing page).

If an ICA client on the outside of the firewall connects directly to the MetaFrame XP server, there will be no issues. The firewall will use NAT to translate between the internal and external addresses of the MetaFrame XP server. In this case, the ICA client and the MetaFrame XP server do not know that the address is being translated. All translation occurs transparently at the firewall, and all is well.

Figure 15.17 The firewall translates the ICA client’s request

 

 

However, if the external ICA client queries the MetaFrame XP server farm (via the Citrix XML service) to connect to a load-balanced published application, the user’s request is sent in the form of data from his client’s IP address to the server, at 128.242.82.212. The firewall gracefully intercepts that data and sends it on to the MetaFrame XP server’s actual address, 10.1.1.1.

The MetaFrame XP server receives the data at its address of 10.1.1.1. It looks at which published application the user wants to connect to, queries the zone data collector, and finds the IP address of the MetaFrame XP server with the least load. In this case, the server with the least load is 10.1.1.1. The MetaFrame XP server sends this information back to the client, letting the client know that he can connect to 10.1.1.1.

The firewall will also intercept this data on its way to the client before it is sent back across the Internet. The firewall will change the sender server’s address (the return address) from 10.1.1.1 to 128.242.82.212. However, the firewall will not change the actual content of the data itself. Think of it like this: A firewall running NAT will always translate the “to” and “from” addresses of the data. It will not scan the data to see if there is anything else that needs to be changed.

In this case, the ICA client will receive the data from the MetaFrame XP server without incident. That data will show a return address of 128.242.82.212. However, the content of the data will contain instructions for the client to connect to the server via 10.1.1.1. This IP address is not valid to the outside world. The ICA client will not be able to connect.

In order for the ICA client to connect to a MetaFrame XP server behind a firewall using NAT, the MetaFrame XP server needs to know that the firewall is translating its IP address via NAT. It also needs to know what the translated address is. This “alternate” translated address can be configured on the MetaFrame XP server with the altaddr command-line utility.

Using the ALTADDR command

The altaddr command-line utility is used to inform the MetaFrame XP server that some clients may request information about the server requiring an address other than the server’s real IP address. This command has the following syntax:

altaddr /set ipaddress

You can use “altaddr /?” to view the full options and syntax of the command. You can specify different alternate addresses for different NICs for servers that have multiple NICs.

In our example from the previous page, we would execute the following command from the command prompt of the MetaFrame XP server:

altaddr /server:ourservername /set 128.242.82.212

After this command has been executed (and after the server has been rebooted or the IMA service stopped and started), the MetaFrame XP server will determine which address ICA clients are looking for and return either the “real” IP address (in this case 10.1.1.1) or the “alternate” IP address (in this case 128.242.82.212).

The altaddr command line utility stores the alternate address in the registry in the following location.

Key: HKLM\system\CurrentControlSet\Services\ICABrowser\ Parameters\AlternateAddress\TCP

Value: DefaultAddress

Type: REG_SZ

Data: IP address of the alternate address.

It is important to note that the altaddr command is used to configure IP addresses that are not local on the MetaFrame XP server. There is no need to open the network properties dialog box of the MetaFrame XP server to add another IP address to the network card. Remember that the firewall running NAT will make sure that the traffic gets to the proper server. All the altaddr command does is enable the MetaFrame XP server to provide an additional alias address to ICA clients. Configuring alternate addresses will not break any internal clients that already connect via the real IP address.

You may be wondering how the server knows when to provide the alternate address or the standard address. In actuality, it’s the ICA client configuration that dictates whether the client will request the server to return to the standard address or the alternate address. For example, in the Windows ICA client, the “server location” section of a connection’s properties has a “Firewalls...” button. This button leads to a screen that has a checkbox labeled “Use alternate address for firewall connection.”

It is easy to be confused as to exactly which situations require the configuration of an alternate address. For example, if you have users that connect directly to one server via an IP address, the alternate address is not needed. An easy way to remember it is that the alternate address is only needed if the MetaFrame XP server will be providing its own IP address to the ICA client through a NAT firewall. The alternate address is not needed if the ICA client already knows the IP address of the MetaFrame XP server.

Port Translation

Some firewalls can also be configured for port translation in addition to address translation. This can be used if you have multiple MetaFrame XP servers that you would like to make available via the Internet on a single IP address. Look at the environment in Figure 15.18.

Figure 15.18 Port translation at the firewall

 

This company has three MetaFrame XP servers. All of them have private IP addresses and host ICA sessions via port 1494. When this company extended their environment to the Internet, they only had a single external IP address available: 12.8.192.113. Since they would like external users to be able to access all of their servers, they configured different ports on the firewall to map to different servers. For example, port 5000 on the firewall maps to port 1494 on Server 1 at 10.1.1.1 on. Port 5001 maps to 10.1.1.2 port 1494 and port 5002 maps to 10.1.1.3 port 1494.

In this situation, the altaddr command is also used. If you’re using it to map a port, simply append the port number to the end of the IP address. For example:

altaddr /server:server1 /set 12.8.192.113:5000

In this situation, you wouldn’t have to configure the server for port 1494 since that’s the port that the ICA sessions are already using. (You would, of course, still need to manually configure the 12.8.192.113:5000 to 10.1.1.1:1494 mapping on the firewall.)

While this solution may not be pretty, it does allow users from outside the network to access any MetaFrame XP server via that single 12.8.192.113 IP address. Of course all of the users inside the network continue to access the servers as usual.

Advantages of Port Translation

 Multiple MetaFrame XP servers can share the same external IP address.

 The servers’ real IP addresses are not exposed to the outside world.

Disadvantages of Port Translation

 It requires a firewall that can support address and port mapping.

 Client devices must be configured to connect to the non-standard port.

Port translation is not common in the real world, because most people in this situation use Citrix Secure Gateway.

Using NFuse with Alternate Address Mapping

Since it’s up to the client device to determine whether it needs the “alternate” address or the “standard” address from a MetaFrame XP server, the NFuse web pages must be configured to tell the ICA client which address to ask for. In the past, you had to manually modify the default NFuse web pages to use different ICA template files depending on the IP addresses of the clients. With NFuse 1.7, this functionality is built in.

Configuring Default Address Behavior

On the “Server-Side Firewall” configuration page (NFuse Admin Web Pages | Server-Side Firewall), the first section titled “Default address translation setting” allows you to specify what type of address is provided to NFuse clients for the MetaFrame XP servers. There are four options:

 Normal Address.

 Alternate Address.

 Citrix Secure Gateway.

 Translated Address.

The Normal Address setting causes the NFuse server to send the client the actual address of the MetaFrame XP server. As detailed in Chapter 11, the exact format of that address (IP address or fully qualified domain name) and whether a TCP port is supplied is dictated by the “AddressResolution Type” entry in the NFuse.conf file.

The Alternate Address setting causes the NFuse server to send the client the alternate address of the MetaFrame XP server as configured on each server via the altaddr command.

The Citrix Secure Gateway setting causes the NFuse server to send the client the address of the Citrix Secure Gateway server instead of the MetaFrame XP server’s address. In order for this option to work, NFuse must be configured for use with CSG as previously detailed in this chapter.

The Translated Address option uses a network address mapping table to map specific external IP addresses or server names to specific internal IP addresses or server names. This table is maintained by NFuse. Conceptually, this mapping is identical to the “alternate” address mapping, except that translated addresses are managed centrally on the NFuse web server whereas alternate addresses are manually configured at each server. If you plan on using NFuse for outside clients exclusively, you will not need to use the altaddr command. (If you plan to use CSG and NAT together you’ll still have to use the altaddr command.)

In order for the translated address option to function, Enter at least one pair of translated addresses. (This is done further down the “Server-Side Firewall” NFuse admin web page via the “MetaFrame server address translation map” section.) To use this map, simply specify the actual MetaFrame XP server address and port and the associated translated (or external) address and port. These addresses must be fully qualified domain names or IP addresses, again depending on the “AddressResolutionType” entry in the NFuse.conf file.

For example, if you flip back to the altaddr diagram in Figure 15.17, you would add a translation entry of 10.1.1.1:1494 for the server address and port and 128.242.82.212:1494 for the translated address and port. You can add as many entries as you want, which is a good thing since you’ll need one for each MetaFrame XP server that is accessible from the outside if your firewall is using NAT.

Applying Conditional Address Translation based on Client Address

Now that you’ve configured your default address types and your translation maps, you can set specific rules that will override these default settings based on the actual IP address of each client.

Take one last look at Figure 15.17. If NFuse Classic was used in that environment, you would have specified a “translated address mapping” that mapped 10.1.1.1 to 128.242.82.212. Then, you would also have configured NFuse’s default address setting to use the “translated” address. However, internal users would need the server’s actual IP address, not the translated address. Therefore, you would configure the “Specific address translation settings” section of NFuse so that the client address prefix of your users (“10.” in this case) would use the normal address.

When you configure “specific address translation settings,” the NFuse server searches through its list of IP address prefixes every time a client user connects. If that user’s IP address prefix is on the list, NFuse sends the client the address of the MetaFrame XP server in the format that is configured for that prefix. Otherwise, it sends the address to the MetaFrame XP server in the format specified by the default address translation setting.

You can configure client address prefixes for the level of detail you require. For example, you could specify “10.” or “10.1.2.” for whatever you need in your situation. The important thing is that client IP addresses are matched to this list based on identical patterns in the client address and the address on the list. Therefore, you cannot specify addresses based on subnet masks or wildcards.

Advantages of NFuse Classic’s Specific Address Translation

 Very easy to apply

 Works well

 Can also translate ports

Disadvantages of NFuse Classic’s Specific Address Translation

 Wildcards cannot be used in addresses.

 Client address searching is only based on pattern matches, not IP subnets.

Client Device Security

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 http://thethin.net. 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:

SessionField.NFuse_TicketTimeToLive=200

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

AutologonAllowed=ON

[NFuse_Ticket]

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.CacheControl=”no-cache”

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.

Figure 15.21 A Sample webica.ini file

[Access]

CurrentConnection=MS WORD10.1.1.2

GlobalSecurityAccess=-1

MS WORD10.1.1.2=405

128.242.82.212=-1

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 (10.1.1.2 in this case).

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

Figure 15.22 Security values for webica.ini files

Value Meaning

-1 The security setting has not been configured.

403 No access.

404 Read access.

405 Full access.

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 10.1.1.2. 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 10.1.1.2) and sometimes not get the popup window (when they are routed to a server other than 10.1.1.2). 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.

User Account Security

The last layer of security that we need to look at is the security and configuration of the user accounts themselves. When addressing security from a user perspective, there are three different items that must be addressed:

 The user account configuration.

 Secure user authentication

 The domain configuration and trust relationships.

User Account Configuration

You can configure several security options at the user layer. The advantage to configuring security at this layer is that the settings follow the user no matter where he logs on. In both Windows NT 4.0 and Windows 2000, there are several user properties that affect the security of your MetaFrame XP environment. These user-layer security configuration options can be broken down into three broad categories:

 Options that are configured as part of the user’s domain account.

 Options that are configured per user or group as part of a server’s local security rights.

 Options that are configured as part of a policy.

User Domain Account Configuration

The security options that are configured as part of a user’s account properties are literally properties of the user account itself. In Windows NT 4.0, these properties are configured via user manager for domains and the configured options become part of a user’s account in the SAM. In Windows 2000, they are configured as part of a user’s Active Directory account properties and the options become part of that user’s Active Directory user object.

There are only a few user account properties specific to MetaFrame XP (or any Terminal Services) environments. First, each domain user that will use any MetaFrame XP server must have the “Allow logon to Terminal Services” box checked in their account properties. If you have particular users that you do not want to use any MetaFrame XP servers, you can uncheck this box. Unchecking this box affects the user for both RDP and ICA connections.

Each user’s account also has properties similar to those that you can configure at the connection layer. These properties include the timeouts for ending disconnected sessions, active and idle session limits, and whether the user can reconnect to disconnected sessions from any client or only the original client. These settings apply to the user whether they connect via RDP or ICA.

Not immediately obvious is how the “run program on startup” options work within a user’s account properties. This option is similar to the initial program option that you can specify at the connection layer because when the user exits from the program, their Terminal Services session is ended. However, be aware that any initial program that you specify in a user’s domain account property only affects him when he logs onto Terminal Services with the RDP protocol. MetaFrame XP ICA connections are unaffected.

Server Local Security Rights

Each server can have a local policy in place that affects users’ local security rights. The way you configure these local user rights depends on the platform on which your MetaFrame XP servers are running. In Windows NT 4.0, user rights are configured via user manager on the target server (user manager | policies menu | user rights). In Windows 2000, local user rights are set via the local security policy of a server (administrative tools | local security settings | security settings | user rights assignments). On both platforms, you can configure local or domain users or groups with various user rights. While many of these user rights are not relevant to the security of MetaFrame XP environments, there are several that are. Some of the security-related rights include a user’s ability to shut down the computer, change the system time, manage the auditing and security log, and take ownership of files.

One of these security rights that is particularly useful in MetaFrame XP environments is the “log on locally” right (log on interactively in Windows NT 4.0). In order for a user to be able to use a MetaFrame XP server, he must have the rights to log on locally to the server. In the real world, you might have 10 or 12 servers for 2 or 3 different departments. You can create a global group for each department, called “Dept A Citrix Users.” Then, on the MetaFrame XP servers that serve applications to Department A, you can remove the “log on locally” right from “Domain Users” and grant it to “Dept A Citrix Users.” Configuring the local security rights of the server gives you an extra level of protection beyond your published application and NTFS security. If you do this, remember also to grant “log on locally rights” to the group that contains the MetaFrame XP administrators.

In addition to the “log on locally” security right, you’ll notice there is a “deny log on locally” security right. You might be confused as to why there are two of these and how they should be used. Normally, if you have users that you do not want to use Terminal Services, you can just choose not to give them the “log on locally” security right. That way, if the user is a member of multiple groups, they can get the “log on locally” security rights from any one of their group memberships. However, if you have specific users or groups that you definitely do not want to use the MetaFrame XP server no matter what, then you can add them to the “deny log on locally list.” This security right will always take precedence if a user is on the list for both “log on locally” and “deny log on locally.” You need to use the “deny log on locally” carefully because it is possible that one user might be a member of multiple groups and each group could have conflicting rights.

User Policies

All of the local security rights from the previous section can be deployed across multiple servers as part of a domain policy (NT 4) or group policy (Windows 2000). They are tied to specific user accounts only when those user accounts are added to the system policy or to an organizational unit where the group policy is applied. For detailed information regarding the use of policies in a MetaFrame XP environment, refer to Chapter 7. In all cases, domain policy or group policy settings will take precedence over the configured local security rights.

Secure User Authentication

One way that many organizations are securing their user environments is by implementing secure user authentication mechanisms. There are two methods that work well in MetaFrame XP environments:

 Smart cards.

 RSA SecurID hardware tokens.

Smart Cards

In environments in which positive user identification is important, smart card technology if often used to authenticate users.

In MetaFrame XP environments, smart card readers can be attached directly to ICA client devices. In order for a user to logon to run their ICA applications, they insert their smart card into the card reader. Their smart card contains a digital certificate which is transmitted to the MetaFrame XP server. The server (which has its own X.509 digital certificate) checks the user’s certificate from the smart card to verify that it matches the certificate on file. If so, the user is authenticated and their MetaFrame session is launched.

For added security, policy options are usually configured on the MetaFrame XP servers that dictate the action taken when the smart card is removed from the reader. Many companies configure their environments so that a user’s session is immediately disconnected if their smart card is removed from the card reader attached to the client device.

Using smart cards in MetaFrame XP environments is no more difficult than using them in standard Windows 2000 environments. Getting your existing Windows servers, clients, and Active Directory configured for smart cards represents the bulk of your work. Extending MetaFrame XP to work with smart cards is the easy part.

This section is not intended to teach you everything there is to know about using smart cards in Windows. That would require an additional 800 pages. The purpose of rather is to provide information about how existing smart card implementations can be extended with MetaFrame XP. For more information about smart card usage in Windows 2000 environments, check out Microsoft article Q313274. This article describes the process to configure a Windows 2000 certificate authority to issue smart card certificates. It also contains links to other Microsoft articles that step through the process of getting a background smart card environment set up.

To secure your MetaFrame XP environments with smart cards, you need to use Feature Release 2. Also, your client devices must use the 32-bit Windows or Java ICA client, version 6.30 or newer.

Windows 2000 and Windows XP are the only Microsoft operating systems that directly support smart cards. However, so long as your MetaFrame XP server is running Windows 2000, you can use smart cards from any 32-bit Windows client, including Windows 9x.

This is possible because the ICA protocol has been extended with Feature Release 2 and version 6.30 clients. A smart card channel has been added that passes smart card information from client devices to the MetaFrame XP server.

Therefore, if your clients are using Windows 9x, a locally attached smart card reader cannot prevent a user from logging on locally to the client desktop. However, they can be prevented from logging on to MetaFrame XP without proper smart card authentication.

If your ICA clients are running Windows 2000 or Windows XP, the smart card software and drivers can be installed locally on them to enforce local logons. In this situation, the smart card reader would be used for local logon and remote MetaFrame XP logon.

Advantages of using Smart Cards

 Ultimate security.

 Easy for users to use and understand.

Disadvantages of using Smart Cards

 Requires Feature Release 2.

 Requires the Citrix ICA Win32 or Java client.

 Requires substantial smart card infrastructure (cards, readers, certificates, etc.).

Before you begin using smartcards in your MetaFrame XP environment, you should have them working in your existing environment. This means that you should have individual cards with user’s certificates and PINs on them. Your backend directory (such as AD) should be ready to go. Your certificate authorities and digital certificates should be all set up. Once all this is in place, smart card usage with MetaFrame XP is very straightforward.

RSA SecurID Hardware Tokens

If you use RSA SecurID hardware tokens in your environment for two-factor authentication, you can easily extend their use to NFuse 1.7 Classic environments. Out of the box, your users must access a web page to authenticate with their token (against an RSA “ACE” server). Then, users must access a second web page where they enter their credentials to authenticate to NFuse.

However, you can use “Project Willamette” to consolidate these authentication pages so that your users’ standard NFuse login page asks for their username, password, and SecurID token passcode. Project William is written by some very smart people from a company called ISC (www.iscnet. co.uk). You can download Project Willamette for free from www.tweakcitrix.com/sections/wilakenz.htm. In order to use Project Willamette with NFuse 1.7, download Project Willamette version 2.0 or newer.

Project Willamette only has a few requirements:

 Your NFuse web server must be running on a Microsoft Windows 2000 Server with Service Pack 2 or newer.

 You must be using IIS as your web server.

 You must have an X.509 digital certificate for your NFuse web server.

 The RSA ACE Agent for Windows v5.0x or newer must be installed on your NFuse web server.

 You need to use Citrix Secure Gateway with a Secure Ticket Authority.

 Your users’ SecurID usernames (their “ACE” accounts) need to match the usernames of their domain accounts.

Using Project Willamette is simple. It basically includes modified NFuse web pages, and all you have to do to use it is to copy a few files from Project Willamette over the original files on your NFuse web server.

Advantages of Project Willamette

 Easy to install and configure.

 Simplifies and clarifies the user login process.

 It’s free (thanks to Chris Walsh and Martin Hodgson).

Disadvantages of Project Willamette

 It’s not “officially” supported by anyone (although plenty of help is available at www.tweakcitrix.com and http://thethin.net.)

Domain Configuration

MetaFrame XP server farms are extremely flexible. This flexibility allows one server farm to span multiple domains or forests. However, just because a server farm can technically span multiple domains or forests, extreme caution must be exercised with this option. There can be conflicts with user credentials and permissions. Consider the following scenario.

The Burning Troll Lumber Company has two Windows 2000 domains, EAST and WEST. Each domain has a domain local group (DLG) for users: EAST-USERS and WEST-USERS. By definition, a DLG cannot contain members of other domains. (Hence the “L” in “DLG.”)

Figure 15.23 Burning Troll Lumber’s Windows 2000 domains

 

The Burning Troll Lumber Company has one MetaFrame XP server farm for their entire enterprise with servers in both the EAST and the WEST domains. They have one published application, “LumberTracker,” which they load-balanced on all MetaFrame XP servers. They want to publish the application explicitly to both the EAST-USERS and WEST-USERS groups.

As you may have figured out, this configuration will cause a problem. Consider how load-balanced published applications work. A user requests the application—LumberTracker in this case. The MetaFrame XP back-end determines which server is least busy and returns that server address to the user. For the Burning Troll Lumber Company, this could cause a technical short-circuit. What if a user from the west is given the address for a server in the east? Because the WEST-USERS group is a domain local group, the east servers do not recognize it. The server would not allow the user to start a session.

The Burning Troll Lumber Scenario could never happen in the real world. There are two ways that MetaFrame XP automatically addresses this situation to prevent it from occurring:

 Trust Intersections. MetaFrame XP does not allow the permissions of the published applications to be set unless all target users and groups can access the application on all servers where it is published.

 Trust–Based Routing. MetaFrame XP will dynamically route authentication to a server on which the user has permissions.

Trust Intersections

When setting the permissions of an explicit application via the CMC, MetaFrame XP only shows users and groups that have permission to access the application on all the servers where the published application is configured. If you try to be crafty by setting the permissions first and then going back and adding servers where those permissions would not be valid, MetaFrame XP produces an error message and automatically removes the users or groups that cannot access the application on every server where it is published.

Trust-Based Routing

Even though you cannot configure applications to be published to users that don’t have rights on all the servers where the application is published, it’s still possible that a user could do something that would require him to be authenticated by a server where he doesn’t have rights. If this happens, the user’s authentication is transparently passed on to another farm server where the user does have access. This is known as “trust-based routing.” It’s possible because MetaFrame XP keeps track of Windows domain trust relationships via the IMA data store. The domains and associated trust relationships of all farm servers are updated during a trust query cycle. A trust query cycle occurs when the IMA service starts and every six hours thereafter.

Trust based routing can occur in the following situations:

 A user refreshes the application list or launches a published application.

 An administrator launches the CMC.

 Anytime accounts are listed in the CMC, including adding users or groups to applications, printer auto-creation, and adding farm administrators.

Looking back to the lumber example, if a farm administrator from the WEST domain tried to use the CMC to connect to a server in the EAST domain, the server from the east would route the authentication to a server in the WEST. This routing would be necessary because the server in the east would recognize that the administrator has farm administrator rights, but would not be able to authenticate the user because the user account is in a different domain.

How to Mitigate Domain Trust Issues

If you decide that trust intersections and trust based routing is too risky or confusing, you can follow these guidelines to avoid having MetaFrame XP invoke its trust voodoo. Think of these as the three golden rules of server farm design if you don’t want to troubleshoot weird trust problems:

 Do not publish applications across servers in different domains to domain local groups.

 Do not publish applications across servers in different forests to domain local groups.

 Do not publish applications across servers in different non-trusted domains in Windows NT 4.

To summarize, you should really make sure that all of your farm administrators have administrative rights on all your MetaFrame XP servers and that all of your users have rights on any servers that they would ever access. Remember that MetaFrame XP server farms operate totally independently of domain boundaries, so using some sense when you design your farms will save you from headaches down the road. The simplest way to avoid all this is to not create server farms that include servers from multiple non-trusted domains.

Secure System Administration Environments

The last thing that we need to look at when considering MetaFrame XP security is how your MetaFrame XP servers will be administered. This is often overlooked, but very important. Even the world’s most technically secure environments won’t actually be secure if too many people have administrative rights.

Another big part of the administration of your MetaFrame XP servers relates to how the servers are actually used. This includes how administrators or help desk personnel shadow end users and how everyone’s actions are logged, recorded, and audited.

As we look at the security of the MetaFrame XP administrative environment, we’ll focus on three areas:

 MetaFrame XP administrators.

 Shadowing end users.

 Auditing and usage logs.

MetaFrame XP Administrators

You can configure your server farm administrators using the Citrix Management Console (CMC | Farm | Citrix Administrators). Farm administrators can be added by group or by user. In environments with Feature Release 1 and lower, there are two levels of farm administrator: “Read-Only” and “Read-Write.” In Feature Release 2 environments, you can also configure custom levels of farm administration.

When granting accounts different levels of administrative access, there are two things to consider:

1. Administrative rights apply to the IMA Data Store only.

2. Administrative rights can only be assigned on a farm-wide basis.

When you assign MetaFrame XP administrator rights to the server farm, you are actually assigning rights to the IMA data store itself. Assigning administrator rights in the CMC does not change any NTFS file rights anywhere and it does not add the user to any Windows domain groups. It is not necessary for a user to have domain administrator or server administrator rights for him to be granted farm administrator rights—although these rights are usually granted for convenience.

Assigning Read-Only farm administrator rights allows the assigned user to read any information about any server from the IMA data store, and the Read-Write privilege allows users to add, delete, change, and reconfigure the information on MetaFrame XP farm servers that is contained in the IMA data store.

You can use the custom rights in Feature Release 2 environments to customize the specific administrative rights that a user has. When you configure custom rights, you have extremely granular control over the type of rights that an administrator has. You do not have control over the where those rights are applied.

For example, you can use custom administrator rights to grant a user the ability to edit load evaluators without giving him the ability do anything else in the farm. However, since all farm administrative settings apply on a farm-wide basis, that administrator would be able to edit load evaluators on any server in the farm. There is no way to allow users to administer certain servers while preventing them from administering others. Think of these rights as “options-based,” not “server-based.”

In fact, all administrative rights assigned through the CMC always apply on a farm–wide basis. If you have some administrators that you only want to administer certain farm servers, you need to break the server farm into multiple farms, or trust the administrators not to touch the wrong servers.

Some crafty people have thought that they could find a way around this “all or nothing” limitation, by creating one single server farm with granular administration by setting local rights on MetaFrame XP servers. They created three servers in one farm. Each server had its own administrator, and each administrator only had administrative level access on his own server—with no rights on the other servers. All three administrators were configured with server farm Read-Write administrator privileges.

The problem with this scenario is that all of the administrators have full read-write administrative access to the IMA data store. Administrator “A” cannot access Administrator “B’s” server directly through the network, but Administrator “A” can launch the CMC and delete users, applications, and configuration information for Administrator “B’s” server. This is because this server farm information does not reside on the local server, but rather in the IMA data store, where Administrator “A” is a full Read-Write administrator.

Help Desk Security Rights

One of the nice things about the ability to set custom administrative rights in your server farm with Feature Release 2 is that it allows you to give your help desk analysts the power to do their jobs without giving them full farm administration rights.

Most people create a Windows domain group called “Helpdesk” and give them the following custom rights in the server farm:

 Log on to Citrix Management Console

 View Printers and Printer Drivers

 View Published Applications and Content

 View Resource Management Configuration

 View Server Information

 Disconnect Users

 Log Off Users

 Reset Sessions

 Send Messages

 View Session Management

 View User Policies

MetaFrame Administration in Active Directory Environments

Just as publishing applications to users in AD environments is no different than in non-AD environments, MetaFrame XP administration is the same in both environments. MetaFrame XP does not extend the Active Directory schema. The “limitation” of only having farm–wide administrators still holds true in the AD environment. The only change from an administration standpoint with in AD environment is that MetaFrame XP administrators can be assigned based on the AD–only groups. (Universal, etc.)

Session Shadowing

MetaFrame XP shadowing allows administrators to remotely view a selected end user’s ICA session. There are several security and privacy concerns raised when deciding how to use shadowing. These stem from the fact that a malicious user could shadow another user’s session without them knowing it. They would be able to view potential sensitive or personal information.

To mitigate this security risk, you have the option of choosing not to enable any of the shadowing features or choosing to manage the shadowing environment so that only authorized users are able to shadow other users. Additionally, if you do enable shadowing, you can log all shadow requests for security purposes. Let’s look at how these two options can be applied in the real world.

Choosing not to Enable Shadowing

When you install MetaFrame XP, you have the option of choosing not to install the shadowing capabilities. If the security principles of your environment prevent you from using shadowing, this allows you to easily turn off shadowing for your environment.

Shadowing Rights

You also have the ability to configure which users are able to shadow other users. These rights are configured at the connection layer via the Citrix Connection Configuration utility (CCC | Right-click connection | Permissions). The “Full Control” default rights give users shadowing rights over a connection. Alternately, you can select “Advanced...” (“Special Access” in NT 4) for access to granular rights, where you can assign shadowing permissions without assigning the “Full Control” rights.

If you are using Feature Release 2, you can also configure shadowing permissions as part of a Citrix user policy. (See Chapter 5 for more information.)

Shadowee / Shadower Interaction

Even with permissions to shadow users, there are two shadowing parameters that can be configured, “Input” and “Notification.” Each of these can be set to “ON” or “OFF.” These can be configured as a property of a connection via the Citrix Connection Configuration (CCC | Edit Connection | Advanced Button) or as a property of the user’s account via the user management tool for your platform. If you’re using Feature Release 2, you can also specify the minimum settings for shadowing users with a Citrix user policy.

As always, if the user layer settings do not match the connection layer settings, the most restrictive setting applies (“ON” for “Notify” and “OFF” for “Input”). “Input” specifies whether a shadowed user’s keyboard and mouse are enabled while being shadowed (ON), or if the user has no interaction and cannot control the session (OFF). “Notify” specifies whether a user is notified before they are shadowed (ON) or if the shadower is able to covertly begin a shadow session (OFF). This notification setting is the most sensitive, as a setting of “OFF” will essentially allow administrators to “spy” on end-users. Before setting this to “OFF” be sure to check your company’s privacy policy and local laws.

Shadow Session Logging

The MetaFrame XP shadow taskbar can be configured to log all shadow events (Right click on Shadow taskbar | Logging Options... | Enable logging). The logs that are produced are by default not secure—making them not very useful. Most people want to log shadowing so that they can watch potentially mischievous employees who might want to spy on other users.

Fortunately, in MetaFrame XP, there is a special DLL (shdwhook.dll) that is responsible for logging shadowed sessions. This DLL watches all applications that could be used for shadowing (cshadow.exe, mfadmin.exe, shadow.exe, and tsadmin.exe) and logs the sessions to the event viewer.

MetaFrame XP User Auditing

Often times MetaFrame XP administrators want to be able to create log files that they can use to audit specific MetaFrame XP user events, such as user session logons and logoffs. There are three ways that audit logs can be created:

 MetaFrame XPa or XPe load manager.

 Windows user account auditing.

 Third party auditing and logging tools.

Logging Users with MetaFrame XPa or XPe Load Manager

When thinking of ways that user actions can be logged, most people immediately think of the logging that is available with MetaFrame XP load manager in MetaFrame XPa and XPe. This logging, which is enabled via the Citrix Management Console (CMC | Load Evaluators | Log Tab | Enable Logging Button), will show ICA user requests and resolutions of those requests.

The MetaFrame XP load manager log is secure (except for farm administrators with Read-Write privileges) and it works well for what it was intended for. The problem is that this log was intended for load balancing troubleshooting purposes. It has a small size limitation. After it reaches 16k it stops logging events until it is manually cleared and reset.

The load manager log should not be used for security purposes.

Logging Users with Windows Auditing

For more industrial–strength user logging, it’s best to think back to your Windows NT administration 101 class:

 In NT 4 environments, you can enable user auditing via user manager for domains (Security Menu | Auditing).

 In Windows 2000 environments, auditing can be configured via a group policy in Active Directory environments (Group Policy Object | Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy), or via the local computer policy when group policies are not used (Administrative Tools | Local Security Settings | Local Policies | Audit Policy). When Active Directory is used, most people configure the audit policies for the Group Policy Object that has the OU that contains their MetaFrame XP servers.

Once your servers are set to allow auditing, you can configure auditing for any item via the audit dialog box (Item Properties | Security Tab | Advanced Button | Audit Tab). There are many books dedicated to Windows 2000 security that can take you step by step through the various security and audit log elements of Windows 2000.

All of the user and computer auditing information is written to the security event log. There is a utility included on the MetaFrame XP CD, auditlog.exe, that can be used to dump the contents of the security event log to a CSV file. From there, you can import that file into a spreadsheet to generate audit reports.

Logging Users with Third Party Tools

If you need heavy duty security auditing and logging in your MetaFrame XP environment, you will probably be disappointed with the native components that are available from Microsoft of Citrix. Most likely, you will want to use a third party security tool, such as Techtonik’s ONEAPP utility. Details are available from www.oneapp.co.uk. New information about other third party tools is constantly available at http://thethin.net.
Brian Madden - Citrix MetaFrame XP Security Design.pdf

---

---

Comments

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.