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