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 submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
- 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.
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.
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:
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.