Next consider the applications that users run, how they access them, and what they can do with them. To begin, let's review how applications are launched by users. There are two ways that users can launch applications on a Terminal Server:
By connecting to an "Initial Program" (or "Initial Application").
By running the Windows desktop and launching applications from within established sessions.
When looking at application security, we must first examine the security of launching applications. Complete details of the ways by which users launch applications were covered in Chapter 9.
Many people choose to use Terminal Servers for specific applications. They specify an "initial application" to be launched when the user connects. A quick check of the big feature chart in the appendix shows that you can actually configure an initial application as a property of a user account, GPO, connection listener, client device, or via an RDP file.
If you have a Terminal Server that hosts only a single application, then it's easy to configure the "initial application" as part of a GPO and apply permissions so that users logging in to that server always get that initial application. If you want to host multiple applications on a single server, but also want to use the "initial application" functionality (since it hides the remote task bar, etc), then you either have to use third party server-based computing software (as detailed in the Appendix) or have your users connect via RDP files.
In previous chapters we discussed connecting users to applications using RDP files. These files are preconfigured and usually stored centrally on a web server or network share point for users to launch applications. What we did not discuss was the security of these files.
These files contain the connection information for the RDP client to connect to a server or server cluster and launch an application. Beyond securing the server, the files should be secured so that users who have no need of these applications can not access the RDP file in the first place.
If the files are stored on a network share point they can be secured using normal NTFS and share permissions. Maintain them on a central share and only distribute shortcuts (.lnk files) to the users.
Security on these files should be configured in such a way that users needing access to the application have read and execute permissions and users who do not require these applications have no security configured on the files. Configuring security this way provides two benefits:
Users that require access can launch and use the files but will not be able to modify them.
Users that do not need access will not have the ability to launch the RDP file or open it up to look at its configuration.
In a web server scenario, these files can be secured much the same way. When placed in a public directory on an IIS web server, they are open to the world via the IUSR_%computername% account. Secure either the entire directory using NTFS permissions and domain groups (if the web server is in the domain) or create a login page with a web login (non-domain) that will not let the user access the icons without authenticating. (See Chapter 11 for more information about using web servers to access Terminal Server applications.)
Many administrators make the mistake of assuming that once the RDP files are configured and security on them is set properly, there is nothing more to worry about. They forget that although only RDP files are available, any user can create a new Remote Desktop connection within his RDP client software. Using this new connection, he would be able to log on to a full Windows desktop. Even if you use web server to host your RDP files, anyone can download and install the full RDP client from the Internet and create a connection to one of your Terminal Servers.
If this happens, it usually results from the administrator not anticipating 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.
While it is hard to prevent situation without some third party software (like Citrix or New Moon), you can secure your Terminal Server desktop in such a way that connecting to it would be useless. When using RDP files for your connections, you may want to create a GPO that completely removes every application and link from your Terminal Server's desktop. That way, if an adventurous user does get a connection he will only see an empty screen with a logoff button. (See Chapter 6 for details on configuring User GPOs).
Instead of worrying that users might "accidentally" find their way to the Windows desktop, you might instead decide to let users connect to the remote desktop and run several applications. If this is your plan, you'll need to ensure that the user environment is protected and secured so users can't do things they're not supposed to do. There are three strategies by which to secure your Windows desktops:
Apply appropriate policies or profiles.
Configure NTFS security.
Prevent users from installing applications.
The Windows desktop shell can be "locked down" so that users are limited by their rights and the actions that they are able to perform. In the last section, we talked about desktop so totally locked down as would be completely useless to a user. However, you can also lock down a desktop so that it looks and feels like a standard desktop but has some of the more "dangerous" capabilities removed. For example, you might choose to remove the "Shutdown" or "Run" commands from the Start menu. The easiest way to do this is with policies as described in Chapter 6.
Can be easily applied across multiple servers.
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.
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.
Additionally, in Windows Server 2003 environments you can manage NTFS file permissions with a GPO, just as if you were right clicking on the directory and setting the permissions manually. To do this, browse to the following location in a GPO: Computer Configuration | Windows Settings | Security Settings | File System (You'll must be in a real GPO to see this option, you can't just manually fire up gpedit.msc by itself.).
When you get to this section of the GPO, right-click on the File System object, then on "New File." Browse to the folder or file or create a new one. Once the folder has been selected, set the proper NTFS permissions on it, configure it to replace the existing permissions and propagate the permissions to the subfolders and files.
This feature makes life extremely easy when it comes to NTFS permissions since you can configure security across your entire Terminal Server environment without logging in to each server or changing the permissions via script.
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.
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.
If users run remote Windows desktops on your Terminal Servers, you don't want them to be able to install any software applications. 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.
A new feature of Windows 2003 (well, technically it was introduced in Windows XP) is software restriction policies. While we previously discussed how to use GPOs to restrict which users can run which executables, you can apply software restriction policies to your Terminal Servers to enforce a broad, rule-based control of the types of applications that users can run.
For example, you can use software restriction policies to specify what types of executables can run, or to only allow signed executables to be launched. Software restriction policies are applied to servers as part of a GPO (Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies).
One useful security tool that is often overlooked is the native ability of secedit.exe to create a security template for use on other servers. This tool (which is included by default on Windows 2003 servers) gives you the ability to create a "perfect server" and then copy its security settings to other servers. These security settings encompass several areas, including:
File System permissions
Restricted group settings
User Rights Assignments
To use this tool, create a perfect server, configure its local policies and permissions exactly the way you want them, and then run secedit with a command line switch to export the settings. Here is an example of this command:
SECEDIT /EXPORT /cfg lockdown.inf
Secedit has many options. By default, secedit will read the security info from the local system security database. If you wish to export security settings from another database you can specify the /db switch and the location of the database. Or, if you only wish to export the registry permissions and not the NTFS permissions, Secedit allows you to use the /AREAS switch and specify the security from specific areas of the system. The areas you can specify are listed in the table below:
Copies account policies, security policies, and event log settings
Copies the restricted group settings
Copies the local User rights assignments
Copies local registry permissions
Copies File System permissions
Copies System service settings
These settings can then be imported to another server using the /import switch and specifying which database to import to and which CFG file to import from. Unlike the /export switch, the /import does not assume the local security database. You must specify it. To import to the local security database, you would specify %Systemroot%\Security\Database\secedit.sdb.