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