Security and Auditing

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Todd W. Mathers and Shawn P. Genoway

Chapter 11 from Windows NT Thin Client Solutions: Implementing Terminal Server and Citrix MetaFrame, published by MacMillan Technical Publishing

• Terminal Server security

  A proper security implementation is a critical component of any Terminal Server installation.

• Connection settings and security

  Connection settings and connection security control both the access to a Terminal Server and how a user can interact with other users on a server.

• User account management

  There are a number of user account options that can be implemented to help improve the security of your Terminal Server environment including password management, account lockout and expiry, time restrictions for user logons, and account auditing.

• The file system

  To develop a secure file system in your Terminal Server environment, you must understand how Windows NT, and hence Terminal Server file security, are configured and managed.

• The TSE Registry

  The Registry contains all of the critical configuration information for a Terminal Server. It is a vital component of your server that needs to be protected as much as possible.

On This Page

Terminal Server Security
Connection Settings and Security
User Account Management
The File System
The TSE Registry

Terminal Server Security

A proper security implementation is a critical component of any Terminal Server installation. Although you must be diligent in configuring the security on a traditional NT server, the very functionality that sets Terminal Server apart is also the reason for implementing more stringent security measures.

One of the major problems with Terminal Server is that the default security of the operating system after installation is not nearly sufficient for any production deployment. Although this is exactly the same behavior as Windows NT Server or Workstation, because any user on a Terminal Server is running locally, default security provides even the regular user with far too many security privileges. Couple this with the fact that system auditing, a way of tracking changes or attempted changes in the environment, is not enabled by default, and you could find your Terminal Server in a nonfunctional state shortly after implementation.

Of course, security is not simply to protect against malicious attack, but more often from human error. Often, a major problem is introduced by a simple mistake. On a Terminal Server, you cannot afford to provide the users (or other NT administrators) with the opportunity to make such mistakes.

On a Terminal Server, there are four distinct areas of security that you will need to visit, which are as follows:

• Client connection and session security

• User accounts

• File system

• Registry

Connection Settings and Security

Connection settings and connection security control not only access to a Terminal Server through the TSE client software or device (RDP or ICA), but also how a user can interact with other users on the server. Connection security is managed through regular NT users or groups.

The tool that you will use to manage connection settings and security is the Terminal Server Connection Configuration (TSCC) program. In Chapter 12, "Terminal Server Installation and Configuration," we will provide a detailed description of all of the features of this program, but for now we will concentrate only on those features pertinent to security.

TSCC is found under Administrative Tools (Common) on the Start menu. When you open TSCC, you will see a list of all of the created connection types for the terminal server, as shown in Figure 11.1.

Figure 11.1: Connections created in TSCC.

Author's Note When configuring security on the terminal server, make sure that you set the security for each of the connection names that exist. Setting them for one will not automatically set them for all. In Figure 11.1, there are three connection names that would have to be configured:

• ica-ipx

• ica-tcp

• rdp-tcp

Connection Security

Connection security is managed by highlighting the connection name you want to edit, and then selecting Permissions from the Security menu. The following table shows the default permissions that are assigned to any new connections that are created, including the ones created during the Terminal Server installation. Figure 11.2 gives an example of this.

User or Group	Permissions
Everyone	Guest Access
<ServerName>\Administrators	Full Control
<ServerName>\Guests	Guest Access
<ServerName>\Users	User Access
SYSTEM	Full Control

Figure 11.2: The default permissions for Terminal Server connections.

These permissions are in line with other Windows NT defaults, set more for ease of use than security. These permissions are not appropriate for managing access to your Terminal Server for the following reasons:

• The Everyone group—This group has access to log on to the server. This is a definite problem and should be removed. This permission allows anyone who exists today or at any time in the future to log on to the terminal server. This can pose a significant problem for both licensing and capacity planning.

• The local Administrators group—This group is granted full control for connections. Although we agree that the local administrator should have access to the server, we prefer not to use the local Administrator's group to assign this right. Surprisingly enough, one of our concerns is the _automatic inclusion of the Domain Admins group into the local Administrator's group when the terminal server is added to a domain. _We will discuss our issues regarding this shortly.

• The local Guests and Users groups—When the server is added to the domain, both of these groups will contain their domain equivalents (Domain Guests, Domain Users). Under most circumstances, you will not want to have any guest accounts accessing your Terminal Server. Unless you are looking at establishing a separate domain only for your TSE environment where all domain users are TSE users, you will not want the Domain Users group included either. If you wanted to restrict a user's access for any reason, the only way to do so would be to remove him or her from the Domain Users group. That would restrict him or her from accessing other non-TSE domain resources.

Methods of Managing Connection Security

So the question now becomes, how should you configure the connection security? You can configure the connection security with local groups, global groups (when an NT domain exists), a combination of both, or through individual user permissions.

Warning: We recommend that you never control connection access through individual user accounts even when you are dealing with only a single server. The administrative work required is much greater than that for using NT groups.

It is our preference to use a combination of both local and global groups for connection security. We create the necessary local groups on the terminal server and then assign into these any global groups that require that particular access. This management approach provides the following benefits over managing with global groups only:

• A standardized set of permissions for Terminal Server connections based on consistent local groups.

• Removes the need to assign identical permissions on a global group-_by-global group basis.

• Allows for an immediate determination of what privileges all of the global groups have, simply by examining their local group memberships. In the section "Managing Local Groups Using ADDUSERS" later in this chapter, we discuss the use of the NT Resource Kit tool ADDUSERS to gather local group membership information for all TSE servers through batch scripting.

• Reduces the chances of global groups unknowingly having different _connection permissions on different servers in the same Virtual Server Domain (we discussed VSDs in Chapter 4, "Server Management and Hardware Considerations").

• The adding or deleting of these global groups can be managed through batch scripts. This is consistent with the Virtual Server Management approach of being able to centrally manage the environment regardless of the number of Terminal Servers in use.

This last point is probably the most compelling reason why we have chosen to manage our connection security in this manner and why we suggest you do the same. If you are managing your connection security only through global groups, to add a new global group (or modify the security of an existing one), you must log on to each server in your environment, run the TSCC application, and perform your connection management. The TSCC program currently does not allow you to manage connections on a remote server, nor can you perform any TSE Connection maintenance from the command line.

Managing Connection Security with Local Groups

Managing connection security through local groups will provide you with much more flexibility and allow you to maintain a much more secure TSE environment. Local groups are created by running User Manager for Domains from the Administrative Tools (Common) folder. If you are logged on to a domain, you will see the user and group accounts for that domain. To view (and add) local groups, choose Select Domain from the User menu and enter the name of the terminal server, as shown in Figure 11.3.

Figure 11.3: Adding local groups using User Manager for Domains.

Tip Although local groups can be created using User Manager for Domains, you can also use the NT Resource Kit tool ADDUSERS to do it automatically. See "Managing Local Groups Using ADDUSERS" later in this chapter for more information on this.

We usually create the following local groups on our Terminal Servers for _managing connection security:

• TSC_ADMINS—Members of this group will have administrative connectivity rights on the terminal server. They will be able to perform all functions on other sessions including logging off, disconnecting, and resetting a session.

• TSC_USERS—Members of this group will have only user connectivity access on this server.

• TSC_USERS_SHDW—Members of the TSC_USERS_SHDW group will have user connectivity access in addition to the ability to shadow other users. This group is usually created to accommodate users who require this privilege, such as application support staff, so that they can view and support users on the terminal server, but they do not require any of the other administrative privileges.

Tip Even though TSE without MetaFrame does not currently support the shadowing feature, we still recommend that you create this group when creating the others. It will save you the effort of going back and adding it later. It can then be used when Microsoft eventually does make shadowing available with RDP.

The TSC prefix before all of the groups stands for Terminal Server Connection and helps us to easily identify the purpose of these groups, which is to maintain connection security.

After the local groups have been created, the next step is to configure the connection security for these groups. This is done by selecting the connection type that you want to update and then selecting Permissions from the Security menu. Begin by removing all of the listed groups except for SYSTEM. Then add in the local groups that we listed earlier, assigning them the following permissions:

Group	Permissions
TSC_ADMINS	Full Control
TSC_USERS	User Access
TSC_USERS_SHDW	Special Access (User Access + Shadow privilege)

To set the privileges for the TSC_USERS_SHDW group, begin by assigning it the User Access privileges. Then double-click TSC_USERS_SHDW from the Permissions list and select the Shadow check box from the Special Access dialog box, as shown in Figure 11.4.

Figure 11.4: Assigning special access to the TSC_USERS_SHDW group.

Once set, your connection privileges should look similar to those shown in Figure 11.5. You will need to repeat the preceding steps for all of the connection names that currently exist or any new ones that you will create.

Tip To keep management as simple as possible, we suggest that you assign the same privileges to all connection types unless you have a specific need to differentiate connectivity between different types, such as TCP and SPX. If this is the case, you may want to add a second prefix that specifies the type. For example, create TSC_TCP_ADMINS for TCP admin connections and TSC_SPX_ADMINS for SPX admin connections.

Figure 11.5: Update permissions for the Terminal Server connections.

If any users are currently logged on while you are making these changes, their sessions will not immediately pick up these new permissions. The new permissions will not take effect for these users until the next time they log on. Any new connections that are established after you have made this change will have these new permissions.

Now that the local groups have been created and the proper permissions assigned, the only thing that remains to be done is to assign the appropriate global groups to these local groups. We will look at two ways of doing this:

• Using User Manager for Domains

• Using the ADDUSERS Resource Kit tool and adding the groups through batch scripts

After these global groups have been added, you will only need to add domain users to the appropriate groups to grant them access to your Terminal Server. Users who are not a member of one of these groups will receive the message shown in Figure 11.6 when they attempt to log on to a Terminal Server. Any user with the proper TSE client can get a logon prompt, but he or she will need to be a member of an authorized group to gain access to the server.

Figure 11.6: The TSE insufficient logon privileges message.

Managing Local Groups Using User Manager for Domains

The traditional method of managing global and local groups is to use User Manager for Domains. You can add global groups to local groups by doing the following:

1. Choose Select Domain from the User menu.

2. Enter the name of the terminal server containing the local groups you want to update (make sure to include \\ before the server name).

3. Double-click on the appropriate local group, and then click on the Add button.

4. Making sure you have selected the appropriate domain, find the group that you want to add and then double-click on it. It will then appear as a listed member of your local group.

5. Click OK when you have added all of the necessary local groups.

If you have a large number of servers to update, it is plain to see that this process will quickly become tedious and the chances of an error or omission very likely. A more reliable and more time-efficient process is to use the ADDUSERS tool from the NT Resource Kit.

Managing Local Groups Using ADDUSERS

ADDUSERS is a command-line administration tool that allows you to create both user and group accounts. ADDUSERS takes its input from a comma-delimited file and writes the appropriate information in the SAM of either_a specific NT computer or into a domain SAM. For a full explanation of the ADDUSERS program, see the NT 4.0 Resource Kit documentation. For our purpose, we will only be making use of the ADDUSERS capability to update _a computer's local group with global group entries.

The two sets of command-line switches that we commonly use with ADDUSERS are

addusers \\<Terminal Server Name> /d <output file>

addusers \\<Terminal Server Name> /c <input file>

The /d switch tells ADDUSERS to dump local groups, global groups, and usernames to the output file. Of course it does not dump any security information such as passwords.

The /c switch tells ADDUSERS to create any groups or users listed in the input file. Here is the format for the input file that would add a global group to a local group when processed by ADDUSERS with this switch:

[User]

[Global]
[Local]
<local group name>, [group description] ,<domain name>\<group name>
[,<domain name>\<group name>],
<local group name>, [group description] ,<domain name>\<group name>
[,<domain name>\<group name>],
etc.

Even though we are not adding any users or global groups, the two sections must still be included for ADDUSERS to function properly. In the [Local] section, you will list all of the local groups that you are updating, and for each you will list the global groups that you want to add. Make sure that you include the extra comma at the end of the list.

Tip If the specified local group does not already exist, the ADDUSERS tool will create it with the group description that you have provided. If the group already exists, the global groups are simply added. The group description is not updated.

Let us assume that we have created a global group in our domain called TSC_ADMINISTRATORS. We now want to add this to our terminal server's local group, TSC_ADMINS, that we created earlier. To do so, you would create the following input file:

[User]

[Global]
[Local]
TSC_ADMINS, ,NOISYRIVER\TSC_ADMINISTRATORS,

We have left the description blank because our local group already exists. We have also made sure to fully qualify the global account with our domain name NOISYRIVER. To add this group to the local group on our Terminal Server named ORCA, assuming we saved our input file as input.txt, we would execute the following command:

addusers \\orca /c input.txt

We then would get the following output:

Error creating local group: "TSC_ADMINS" (group already exists)

- User added to group: "NOISYRIVER\TSC_ADMINISTRATORS"

The creation error is simply telling us that the local group TSC_ADMINS already exists, which is not a problem. It then tells us that it successfully added the NOISYRIVER\TSC_ADMINISTRATORS group to the local group TSC_ADMIN.

Author's Note If we want to add a new global group to all of the local groups on our terminal servers, we simply create our input file and then batch up the ADDUSERS command with a list of server names and let it run.

Unfortunately, removing a global group from a local group is not as straightforward. Although ADDUSERS provides a /e option for erasing users, do not use this on your local groups. It will completely erase the local group and not simply the global group members. If the local group is erased, it will automatically be removed from the permissions list for any connections in which it was defined.

To remove a global group from a local group, you will need to issue the following command on each of the terminal servers you want to update:

net localgroup <local group name> <domain name\global group name>/delete

The NET LOCALGROUP command will not allow you to specify a local group on another server. To remove the NOISYRIVER\TSC_ADMINISTRATORS group from our local TSC_ADMINS group, we would issue the following command on the terminal server:

net localgroup TSC_ADMINS NOISYRIVER\TSC_ADMINISTRATORS /delete

Author's Note The NT Resource Kit comes with a tool called the Remote Command Service (RCMD) that allows you to open a console on a remote computer or to issue a command to execute on a remote computer. This utility consists of two components: a service that must run on the destination server and the client RCMD.EXE that initiates the connection. RCMD can open an interactive console or can issue a single command that will execute on the destination server. The syntax for issuing a single command is

Rcmd \\<server name> <command> 

Using RCMD, we could remove the NOISYRIVER\TSC_ADMINISTRATORS group from our local TSC_ADMINS group by issuing the following command:

Rcmd \\orca "net localgroup TSC_ADMINS 
NOISYRIVER\TSC_ADMINISTRATORS 
/delete" 

If necessary, this command could be used in a batch file to remove the global group from the local group on a number of terminal servers.

Although the use of this tool does make it possible to completely automate the management of security groups on a Terminal Server, you should be cautious of the security considerations that may come with it. There are two main points to remember:

• Although the RCMD service is running on the server, anyone with the interactive logon privilege for that server would be able to establish a remote command prompt.

• Even when connected through RCMD, the users will still retain their personal security information. This means that even if they establish a remote session, they will still only be able to access files that they have been granted access to.

If you plan on using this service, we suggest that you do not leave it running: Start it only when you need to issue a remote command. Using the Command-Line Service Controller utility (NETSVC) from the NT Server Resource Kit, you could automatically start and stop the service on the terminal server from a remote computer. The following batch command would start the remote command server, remove the global group from the local group, and then stop the service again.

netsvc "Remote Command Server" \\ORCA /start 
Rcmd \\orca "net localgroup TSC_ADMINS_NOISYRIVER\TSC_ADMINISTRATORS 
/delete" 
netsvc "Remote Command Server" \\ORCA /stop 

In order to stop or start a remote service, the issuer of the command must have sufficient privileges on the target server.

Connection Settings

The second part to configuring proper connection security involves making some changes to the default connection settings themselves. These changes are done specifically to improve the security of your server. Although all of the changes may not be appropriate depending on your intended deployment, we will review them all with explanations as to why they should be made.

To update the connection settings, you will once again run the TSCC tool. This time, double-click on the connection name that you want to edit to bring up the Edit Connection dialog box. Click on the Advanced button, which will be the same for both RDP and ICA connections. This will bring up the Advanced Connection Settings dialog box, as shown in Figure 11.7. All settings made here will affect every user who attaches to this connection name.

Figure 11.7: The Advanced Connection Settings dialog box.

Timeout Settings

We will begin with the Timeout Settings for the selected connection type:

• Connection—This setting specifies the maximum time that a connection can exist on the server before it is either disconnected or reset. Although it is very unlikely that you will want to set a timeout for everyone, we recommend that you select the Inherit User Config check box in case there are particular users for whom you want to set this value. As with the other timers, deselecting the Inherit User Config option and selecting No Timeout will completely disable this timer for all connections of this type.

• Disconnection—The maximum time that a disconnected session is kept until the session is terminated. We recommend that you select Inherit User Config for this timer too in case one or more users will require either a longer timeout value or no timeout value at all. You should then establish a standard timeout value for all regular TSE users (including administrators). This is done by running User Manager for Domains on a Terminal Server and selecting the Config button from User Properties. For more information on the TSE version of User Manager for Domains, see Chapter 2, "What Is NT Server, Terminal Server Edition?" A timeout for disconnected sessions is always recommended, particularly when you are not rebooting your servers on a nightly basis. Disconnected sessions will hold resources that could be freed up for use elsewhere. This timeout is used mostly to terminate sessions that users have disconnected from instead of logging out of them.

  Author's Note Very often Terminal Servers are set to reboot on a nightly basis to ensure that all server resources (particularly memory resources that may have not been freed by user applications) are available for users when they log on the next morning.

• Idle—To provide improved security by reducing the chances of a user leaving his or her TSE session active for someone else to come along and use, you should look at instituting an idle timeout. This is the maximum allowable idle time for a connection before it is either set to Disconnected, or reset. Of course setting this idle time too short could result in users being prematurely bumped off. We recommend setting it to two hours or so. This would allow users who had gone for lunch to come back without losing their work, but for someone who is away at meetings for the morning or afternoon to be bumped (as he or she should be). In addition to the security benefits, this timer also helps to ensure that resources are freed up where possible.

AutoLogon

The AutoLogon option allows you to specify a user name, password, and domain to automatically log a user on to TSE. This option can be set either here or on the client desktop if the Inherit option is selected. We highly recommend that this option not be inherited. There is very little reason to provide users with an automatic logon to a Terminal Server, particularly at the desktop where the username and password would be stored. Although the password itself is not as easily gained as it is encrypted, it does not need to be known, as the intruder has only to log on to the client's desktop and connect to the terminal server to automatically be logged on as that user. To turn off the Inherit option, deselect the appropriate check box.

Tip When the Inherit Client Config checkbox is selected and you log on to a Terminal Server using the Microsoft TS Client, the user ID for the last user to log on to the server from that client will appear in the logon window. Deselecting the Inherit option for AutoLogon will prevent the user ID from appearing. The Citrix client will never display the user ID of the last user that logged on to a Terminal Server. If you are going to allow inheritance, an alternative method to preventing this behavior is to make a change in the Registry. We discuss this later in this chapter in the section "Other Connection and Session Security Considerations."

Another trick is to force a standard domain to always display when users log on to the connection type. Simply enter a domain name in the appropriate field when you have deselected the Inherit option. If this is not set, the domain name displayed in the logon window will be whatever the last person to log on to that server selected. This behavior is the same whether the ICA or the RDP client is used.

Initial Program

When using Terminal Server with MetaFrame, you will have the additional check box labeled Only Run Published Applications that is enabled when the Inherit Client/User Config is selected. This allows you to restrict the selected ICA connections to allow only published applications to be run. This will prevent users from accessing a complete desktop unless you have explicitly made one available as a published application. This will affect every user, including those with administrative privileges. Of course, this has no effect on a console logon.

Tip Although you will have the ability to specify a single application to run with either RDP or ICA connections, unless you are implementing TSE for a very specific application, you will not want to configure it here. We suggest that you select Inherit Client/User Config to provide you with the ability to restrict users to a specific application through User Manager for Domains if necessary.

Security

Depending on the connection type that you are configuring (ICA or RDP), the Required Encryption drop-down list box will contain different options. With ICA connections you will have two options, None or Basic, unless you have the SecureICA add-on, which provides for higher encryption levels. We recommend that you always select the Basic option for ICA clients that do not have the SecureICA option.

With RDP clients, you have the options Low, Medium, and High. For all levels of encryption, data sent from the client to the server is encrypted. When Low is selected, there is no data encryption from the server back to the client, whereas for both Medium and High encryption, there is. Both Medium and High provide greater security, but a slight performance hit will be incurred as both the client and the server will have to encrypt and decrypt data. If any of your clients will be accessing the environment from a remote location, you should consider using at least Medium security.

We also recommend that you select the check box labeled Use Default NT Authentication. This will force connections to use the standard NT authentication DLL to validate logons. You should deselect this option only if you have installed a third-party security package and you want to use it for Terminal Server authentication.

Other Connection Options

Now, we will look at three remaining connection options. The first is the setting for handling broken or timed-out connections. The options available are Reset and Disconnect, and they control how connects are managed when they are either timed out or have been broken due to a bad connection or network issues. Of the two, the more secure option is Reset, which will terminate any connection that is either broken or times out. This ensures that the sessions do not remain active on the server without the user's knowledge. This option is suggested when the terminal servers are not rebooted on a regular basis. If the servers are rebooted frequently (nightly), you can consider selecting the Disconnect option, particularly if users are dialing in over phone lines, which can be unreliable at times.

The next setting is how disconnected sessions can be reconnected and affects only ICA clients (although it can be set for RDP clients too). We suggest you select the From This Client Only option, which will allow a disconnected session to be reconnected only from the same client and not another one. This option should not be inherited.

The final option also applies only to ICA connections and deals with whether shadowing is enabled and if so, how it is configured. The two settings that are configurable for shadowing are as follows:

• Input—This controls whether the shadower has access to input information into the session that he or she is shadowing. When Input is set to OFF, the person can only view the other user's screen and cannot interact with it. In most cases, this should be set to ON to allow support and training personnel to assist users with any problems they may have.

• Notify—This controls whether or not the user is notified that his or her session is being shadowed. When Notify is set to OFF, the only warning that the user's session is being shadowed is a quick flickering of his or her screen. When Notify is set to ON, the user is asked if he or she wants to allow the shadower to shadow his or her session. The user must respond yes to allow his or her session to be shadowed.

Warning: Although having Notify OFF provides administrators with the ability to go in and covertly see what a user is doing, it provides a large problem for both security and the protection of information. Shadowing is normally restricted to administrative personnel, but it is very possible that other support staff such as help desk people will also have this capability. With Notify off, there is nothing to prevent an authorized shadower from going and reading someone else's mail, viewing his or her data, or in the worst case, damaging the system under that person's user ID (particularly an administrator). We suggest that under all circumstances the Notify option be set to ON. This slight inconvenience to TSE administrators is a small price to pay to add some additional protection against the possible abuse of this function. The Inherit option must also be deselected; otherwise, an individual user account will very likely end up with nonstandard shadowing options. Figure 11.8 shows the shadow options under User Manager for Domains, which are identical to those set for the connections. With the Inherit option enabled, these user settings will override the connection settings.

Figure 11.8: The user shadow settings in User Manager for Domains.

Other Connection and Session Security Considerations

The one remaining change with regards to connection and session security is made in the Registry of the terminal server. As we mentioned earlier, when using the Citrix MetaFrame client, the username of the last person to log on from a workstation will never appear in the logon window. The same cannot be said for the Microsoft Terminal Server client. If the Inherit option is selected for the AutoLogon connection setting, the previously logged-on user's ID will appear. You can force the terminal server to never display the previous user's ID by going to the following Registry key:

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\WinLogon

and changing the value of DontDisplayLastName from 0 to 1.

Warning: Making the DontDisplayLastName Registry change will prevent users who are running the Microsoft Terminal Server Client from being able to hard-code their user IDs and passwords into the Client Connection Manager, even if the Inherit option for AutoLogon is enabled. Because the Microsoft TS client uses the same mechanism for passing the user ID through when displaying the last logon as it does when processing a hard-coded value in the client software, this Registry change effectively disables this option. The DontDisplayLastName change does not affect the MetaFrame client in the same way. A hard-coded user ID and password in the Remote Application Manager will still allow an autologon (as long as the Inherit option for the ICA connection is enabled).

If you want to ensure that an RDP client cannot hard-code his or her ID or password, you should disable the Inherit feature for the AutoLogon option, and not rely on the DontDisplayLastName behavior as described. It is possible that Microsoft will correct this in the future.

For more information on the Client Connection Manager or the Remote Application Manager, see Chapter 2 and Chapter 3, "Citrix MetaFrame," respectively.

User Account Management

A number of user account options can be implemented to help improve the security of your Terminal Server environment. It should not be any surprise that all of these options are also valid for Windows NT itself. The areas that we will examine are

• Password management

• Account lockout

• Account expiry

• Time restrictions for logons

• Account auditing

Password Management

Probably the most insecure component of most computer systems involves the passwords chosen by the users. There are three common problem areas with passwords that we will briefly address:

• Password selection

• Password length

• Password age

Password Selection

Most users, given the opportunity, will tend to choose passwords that are easy to remember, which unfortunately means that they are also usually easily cracked. Commonly chosen passwords such as family names, birth dates, and even license plate numbers are usually easily obtained with only a little investigation. Even when the password is not directly based on user information, it is very often nothing more than a common English word that could make an easy target for a dictionary-based attack.

Instituting an account lockout policy coupled with account auditing will help you to defend against this type of attack. We will discuss both of these later in this chapter. Unfortunately Microsoft does not currently provide a supported method of forcing the use of stronger passwords. Neither does it support the use of any authentication methods other than through passwords. To implement higher security, you will need to look to third-party authentication packages.

Strong Password Enforcement in TSE

Microsoft does provide a method of enforcing strong passwords on Terminal Servers (it is also available in Service Pack 2 and higher for NT 4.0), although it is not officially supported. In the directory %SystemRoot%\System32, you will find the file passfilt.dll. This DLL can be implemented to enforce the following password security:

• Passwords must be a minimum of six characters in length.

  Passwords must contain at least three of the following four character types:

  • Uppercase characters A,B,C,…,X,Y,Z

  • Lowercase characters a,b,c,…,x,y,z

  • Numbers 0,1,…,8,9

  • Nonalphanumeric characters such as ;.,'?/()

These requirements cannot be modified and are hard-coded in the passfilt.dll file itself.

Although the actual steps required to implement passfilt are straightforward, in order to make use of them in your domain environment, you must add this DLL to your Primary Domain Controller and preferably your Backup Domain Controllers in case they are ever promoted to a PDC. We must remind you that although Microsoft makes this DLL available, it makes no warranties and it does not officially support the product. With that in mind, the passfilt.dll file is implemented as follows:

1. Make sure the passfilt.dll file is located in the System32 directory on your Terminal Server (if you are going to be using it against local accounts) or on a domain controller if this will be domain-wide. We highly recommend that you add this to a Terminal Server and not a domain controller initially, so that you can test to ensure that it will meet your needs.

2. Open the Registry and locate the following key:

   HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \LSA

3. Now add the following value to the LSA key if it does not already exist:

   "Notification Packages":REG_MULTI_SZ

4. If any character strings already exist for this value, add PASSFILT on a new line below this last entry.

5. Exit out of the Registry editor and then reboot the server for the changes to take effect. Once restarted, any password changes will have to be validated by passfilt before they will be allowed to be set.

Although the filter works properly—forcing passwords to correspond to the more strict requirements just listed—there is one major problem with this implementation. The message that appears when a user incorrectly attempts to set his or her new password is anything but descriptive, and many times also incorrect. The problem is that the passfilt.dll will simply return an error code if the password that it receives is invalid. This error code is received by the NT component that is attempting to set the new password, and it simply generates an error based on the criteria that it thinks may be wrong. Unfortunately, this component is completely unaware that the passfilt.dll exists, so the error returned is completely wrong. This will be extremely confusing for your users and would require you to deploy special password documentation that they could refer to immediately. It is almost a certainty that calls would be generated to your help desk because of this.

It is really too bad that Microsoft did not allow an easier way to configure the associated message for passfilt, as this simple dll can certainly improve the strength of the passwords for all of your users.

Password Length

In addition to passwords that are easy to remember, most users will also try to choose passwords that are short; that is, between three and five characters. We strongly suggest that you enforce passwords with a minimum length of at least six characters. You can configure your environment to enforce a minimum password length as follows:

1. Open User Manager for Domains and select either your domain or the terminal server if you are going to be logging on using local accounts.

2. Select Account from the Policies menu. This will bring up the Account Policy dialog box. In this box, you will configure how Terminal Server will enforce account security. We will return to this dialog box shortly to discuss the other options that can be configured. By default, the minimum allowable password length is 0 characters (a blank password). Click on the At Least option button and select the minimum password length to enforce as shown in Figure 11.9.

Figure 11.9: Configuring the minimum allowable password length.

The policy change will not affect any passwords that currently exist. The next time a user attempts to change his or her password, if it does not meet the minimum password length requirement, he or she will receive a message similar to the one shown in Figure 11.10. Unfortunately, if an administrator is setting or changing a user's password and it does not meet the policy requirements, the user will simply receive an error message stating the new password is "invalid." There is no indication that it has not satisfied an account policy.

Figure 11.10: The message presented when the minimum password length is not met.

Password Age

In addition to the problems of password length and selection, there is also the question of how often a user actually changes his or her password. Unless forced to do so, users will rarely, if ever, change their password. Luckily, Terminal Server provides the ability to control how often a user must change his or her password, and also how often he or she is allowed to reuse the same password. This is also done from the Account Policy dialog box that we discussed earlier (see Figure 11.9). This dialog box has three sets of options that you should be aware of:

• Maximum Password Age

• Minimum Password Age

• Password Uniqueness

The Maximum Password Age option controls how long a user can use the same password before he or she is forced to change it. To set an expiry, simply click on the Expires In option button and then select the number of days required to expire. We recommend that you set this to 45 days. If a user successfully changes his or her password before the 45 days have expired, the expiry counter is reset.

The next option, Password Uniqueness, sets how many different passwords a user must have before he or she can reuse the same password. Setting this value will prevent users from simply reusing the same password when required to change it. Users should be forced to use at least six different passwords.

The Minimum Password Age option is used to set how long a user must maintain the same password before he or she is allowed to change it. Although this initially does not seem like a very useful feature, it is intended for use in conjunction with the Password Uniqueness option. The logic is that by forcing users to keep the same password for one or more days, they will not be able to simply reset their passwords a number of times in order to reuse a password that they are comfortable with. This would eliminate the security benefits of the uniqueness option.

Tip You should also ensure that the Users Must Log On in Order to Change Password check box located at the bottom of the Account Policy dialog box is selected. When this box is selected, a user must log on to the system in order to change his or her password. As a result, if his or her password expires, he or she will be unable to log on to the environment to change it and will have to contact an administrator to have it reset.

Although this may result in an increase in administrative work, it will prevent accounts that have exceeded their password expiry date from being hacked into and having their password reset. Very often accounts that have expired passwords will also be accounts that have not been accessed since the last time the password was set.

Account Lockout

One security component that you should always enable with the account policies is the ability to lock out an account after repeated logon failures. This functionality will aid you in monitoring your environment even when you cannot do so yourself. As with the other settings, this is configured in the Account Policy dialog box.

By default, account lockout is not enabled. To enable it, click on the Account Lockout option button. When this button is enabled, TSE will populate the settings with the system defaults. We recommend configuring account lockout as follows:

• Lockout after five bad logon attempts. After an incorrect password has been entered five times within the count reset time (30 minutes), the user's account is locked out and he or she will be unable to log back on until the lockout duration has expired, or an administrator has removed the lockout.

• Reset count after 30 minutes. If a bad logon attempt has not occurred within 30 minutes of a previous attempt, the counter is reset to zero.

• Lockout duration set to Forever (until admin unlocks). Although you may consider this to be a little extreme, we feel that after a user has incorrectly entered his or her password five times, there is a very good chance that he or she has forgotten the password and will need to contact an account administrator to reset the password anyway. If he or she has not been attempting to log on, this will alert the administrator to a potential system attack.

Account Expiry

When creating accounts in your Terminal Server/NT environment, it is a good idea to specify an expiry date whenever possible. This option provides a mechanism to automatically "remove" accounts from the environment. Although they are not physically removed, their access to the environment is. You can then review the list of expired accounts at a later date and purge all accounts that are no longer used. Expiry dates are ideally suited for temporary workers who will be leaving the company in a reasonably short period of time.

To specify an expiry date, open User Manager for Domains, double-click on the appropriate user ID and click on the Account button. It will bring up the dialog box shown in Figure 11.11. Click on the End Of option button and enter a date. At midnight on this date, the specified user account will expire, and the message

Your account has expired. Please see your system administrator.

will appear when the user attempts to log on. To re-enable the account, the administrator needs only to update the expiry date. You should be aware that the users will not see any warning message stating that their account will expire before they actually do.

Figure 11.11: Setting the expiry date for a user account.

Time Restrictions for Logons

In User Manager for Domains, you can also establish time restrictions whereby a user is allowed to log on to the environment only during a specified timeframe. This can be useful if you have departments or groups of users who have no requirement for access outside of certain hours. Many NT administrators traditionally will restrict a user's access during a certain timeframe for backup or other maintenance reasons.

Although Terminal Server does not necessarily have the same requirements, especially when your environment consists of a number of servers, restricting a user's logon period is a proactive security measure. Figure 11.12 shows the dialog box where the time restrictions are set. It demonstrates a user who is restricted to logging on between 7 a.m. and 7 p.m., Monday through Friday.

Warning: After you have specified time restrictions for a user, these restrictions will apply for all servers (TSE or NT) that he or she is attempting to log on to. Make sure you are not accidentally locking a person out of other systems that he or she may require access to.

Figure 11.12: Specifying users' logon hours.

You access the Logon Hours dialog box by selecting the properties for one or more users in User Manager for Domains and then clicking on the Hours button. You then specify a time period by clicking to highlight the time range, then clicking on the Allow or the Disallow buttons. When disallowed, the time range will be blank, and when allowed, it will contain a blue line. By default, users are allowed to log on 24 hours, seven days a week. If a user attempts to log on during a time period when his or her access has been restricted, he or she will receive the error message shown in Figure 11.13.

Figure 11.13: Attempting to log on during a restricted time period.

In conjunction with logon time restrictions, you should also set the option Forcibly Disconnect Remote Users from Server When Logon Hours Expire in the Account Policy dialog box. When selected, this will automatically disconnect users from the terminal server (or any NT server) during the user's lockout period.

Account Auditing

We will now look at how you would configure your environment to audit certain user events, and we'll provide suggestions on events that you may or may not want to audit. One thing that you will need to consider carefully is what events you will actually want to audit. Although it is easy to simply configure your environment to audit all events, the resulting logs will be difficult to review and manage, defeating the purpose of auditing in the first place. Finding the proper level of auditing for your environment will require a bit of work, but it is an exercise that we highly recommend.

Auditing is enabled through the User Manager for Domains. To open the Audit Policy dialog box, select Audit from the Policies menu. This dialog box will appear similar to the one shown in Figure 11.14.

Figure 11.14: The Audit Policy dialog box.

If you are going to be making your Terminal Servers a part of an NT domain, you will need to ensure that you are enabling policies for the domain users who will be logging on to your servers. The auditable events listed in the Audit Policy dialog box are as follows:

• Logon and Logoff—Whenever a user attempts to log on or log off, an event is written to the log. We recommend that you audit both success and failure. Successful logons will let you audit the logon activities for users, and failures may indicate an attempt by someone to access a restricted resource. Figure 11.15 shows a sample audit entry created when a user logged off a Terminal Server.

  

  Figure 11.15: User logoff security event.

• File and Object Access—Access to standard objects such as files, directories, or printers is audited using these events. We suggest that you audit failures because this will indicate users with insufficient privileges attempting to access resources. Mapping successes will offer little value except in isolated situations, because users can successfully access a large number of objects during a single session.

• Use of User Rights—This audits the use of all user rights except for the logon/logoff rights.

• User and Group Management—The result of a creation, deletion, or modification of a user account or group will be logged when this audit event is selected. Both successes and failures should be logged for this event. This will allow you to track any account changes or change attempts. Figure 11.16 shows an example of an event created when a user is added to a global (domain) group.

  

  Figure 11.16: Event generated when adding a user to a global group.

• Security Policy Changes—These events cover any changes that are made to the security policies that are configured through User Manager for Domains. These are comprised of the user rights policies, the audit policies, and the trust relationships between domains. Because of the sensitive nature of this security information, both success and failure should always be audited for these events.

• Restart, Shutdown, and System—When a user attempts to restart or shut down a system, this event is triggered. Any event that affects the system security or the security log is also tracked with this event. We suggest that you audit failures.

  Author's Note Do not be too surprised if you see a large number of restart and shutdown attempts made on your Terminal Servers, particularly after you first implement. If your users have had any previous experience with Windows NT or Windows 95, they may be accustomed to "shutting down" when they are finished working on their computer for the day. This will be very common among users who use the Alt+F4 key combination to terminate Windows. Even on TSE, using Alt+F4 will present the user with the NT Security dialog box where he or she has the option to shut down. Although regular users will have insufficient privileges to successfully complete this operation, the shutdown or restart attempt will still be logged.

• Process Tracking—These events track actions such as process (including program) starting and stopping as well as indirect object access. This would include such things as a process or thread from an application that manipulates an object in some way. Just as with file and object access, failures should be audited.

As we mentioned earlier, you should monitor your logs carefully to ensure _that you are tracking all the information that you feel is necessary, and at the same time not tracking extra information that will only fill your logs with _information that you are not interested in.

Tip The AUDITPOL tool from the NT 4 Server Resource Kit (Supplement 2) can be used to update account policies on any computer from a command prompt. This provides a consistent, reliable way of updating account policies on multiple computers. If we wanted to configure the account policies on our ORCA Terminal Server as we have suggested, we would use AUDITPOL as follows:

AUDITPOL \\ORCA /enable /logon:all /object:failure /privilege:failure  
/sam:all /policy:all /system:failure /process:failure 

To update the auditing on a domain, simply use the name of the PDC.

For more information on the AUDITPOL command, see the NT 4 Server Resource Kit documentation or issue AUDITPOL /? from a command prompt.

The File System

In order to be able to effectively develop a secure file system in your Terminal Server environment, you must understand how Windows NT and hence Terminal Server file security is configured and managed. If you are not already familiar with NT file security, we suggest you review Appendix B, "File and Directory Security," before continuing. In Appendix B, we discuss the building blocks of file and directory security.

Author's Note As mentioned earlier, we feel that it should be a requirement that the NTFS file system is used on all drives on your Terminal Server. Using FAT does not even allow you to implement the minimum security to protect your server. For you to be able to create any kind of file security, you must use NTFS.

System Volume

We begin our file system security discussion by looking at the suggested changes that you should make to improve the security of your system volume. The system volume will contain the TSE operating system only and is separate from the application volume that will contain any of your installed application. In Chapter 12, we will discuss more about suggested disk configurations for your Terminal Server.

Table 11.1 lists the directories on your system volume, our suggested permissions, and comments on why we are suggesting such permissions. We will assume that your Terminal Server system root is \WTSRV. If a directory is not listed, it is assumed that it has inherited the permissions of its parent directory. It is assumed that unless stated otherwise, the permissions on any subdirectories are not replaced. All access groups are local Terminal Server groups.

Author's Note We highly recommend that you take the time to review all of these settings in detail. Many of the default permission settings set during a TSE installation provide the regular users with too much access, allowing them to manipulate or add files that they should not have the access to do. Although it may be easy to simply apply these permissions, we feel it is important that you take the time to understand exactly how they work, and what files they are affecting. You may be required to modify these permissions, depending on the applications that you intend to use. In order to make only the changes necessary and still maintain a secure environment, you need to understand why certain permissions have been set the way they have.

Table 11.1 Suggested system volume file permissions.

Directory	Suggested Permissions	Comments
Root (\)	FC: Administrators,System, Read:Users
\Program Files	FC: Administrators, System, Read: Users, Replace permissions on all subdirectories.	Users should not be able to add applications to this directory.
\Temp	FC: Administrators, System, Read: Users	Unique subdirectories are created when a user logs on to the Terminal Server to manage his or her personal temp files. The user is granted FC along with the Admin and System, but no one else has access. This is done at the system level, so users do not even require change permission to the Temp directory.
\Recycler	FC: Administrators, System Change: Users	A unique Recycle container is generated for each user who needs one. It is based on the user's SID and is accessible only by an admin and the user.
\WTSRV\Application Compatibility Scripts	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Users require read access to selected scripts based on the applications that have been installed.
\WTSRV\Config	FC: Administrators, System Replace permissions on all subdirectories.	Required only by administrators.
\WTSRV\Ctxundo	FC: Administrators, System Replace permissions on all subdirectories.	Exists only if you have installed Citrix MetaFrame and contains MetaFrame uninstall information. Required only by administrators.
\WTSRV\Cursors	None	Delete this directory if it exists. This is not required for use of the regular cursors.
\WTSRV\Fonts	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Users require read access to be able to use the fonts. Users cannot be allowed to add fonts to the environment.
\WTSRV\Help	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Allows users to have access to view the help files.
\WTSRV\ICA	FC: Administrators, System Replace permissions on all subdirectories.	Exists only if you have MetaFrame installed. Contains the client database for the ICA Client Update Configuration utility. Only needs to be accessible by administrators.
\WTSRV\INF	FC: Administrators, System Replace permissions on all subdirectories.	Contains configuration files for TSE installation components. Users do not require any access to this area.
\WTSRV\Media	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Users will require Read access if they need to play the .WAV files in this directory. If sound is not required in your installation, do not provide any access for the users.
\WTSRV\Profiles	FC: Administrators, System List: Users	Users can only list the contents of this directory. File rights are not specified. When a new profile directory is created when someone logs on, the only people with access to it will be Admin, System, and the user. This will prevent users from being able to modify other user's desktops.
\WTSRV\Profiles\All Users	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Users cannot change general settings for all users.
\WTSRV\Profiles\Administrators	FC: Administrators, System Replace permissions on all subdirectories.	Users have no access to the local Administrator's profile.
\WTSRV\Profiles\Default User	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Read-only access to these files for users too.
\WTSRV\Repair	FC: Administrators, System Replace permissions on all subdirectories.	Users do not require access to the Repair directory.
\WTSRV\ShellNew	FC: Administrators, System Read: Users Replace permissions on all subdirectories.
\WTSRV\System	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Users should not be allowed to make any changes to the system directory.
\WTSRV\System32	FC: Administrators, System Read: Users	Depending on how restrictive you want to be, specific files within this directory should also be made inaccessible to users.
\WTSRV\System32\clients	FC: Administrators, System	Contains the files used to create client diskettes for both TSE and MetaFrame. Users require no access to this directory. If you are going to share this directory on the network, you will want to assign read permissions to users.
\WTSRV\System32\Config	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	The files in this directory make up the components of the Registry. Even though users have only read access at the file level, further permissions must be set in the Registry to prevent unwanted changes. We discuss this in the final section of this chapter, "The TSE Registry."
\WTSRV\System32\Drivers	FC: Administrators, System Replace permissions on all subdirectories.	Contains device drivers for TSE. Users do not require access to this directory.
\WTSRV\System32\lserver	FC: Administrators, System Replace permissions on all subdirectories.	This contains the database that manages the TSE licenses on the Terminal Server. Users should not have access to this directory.
\WTSRV\System32\os2	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Contains DLLs for OS/2 1.x support. Users will need read access to this directory if they will be running legacy OS/2 applications.
\WTSRV\System32\ras	FC: Administrators, System Replace permissions on all subdirectories.	Contains RAS configuration information. Users do not require access to this directory.
\WTSRV\System32\spool	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	You do not want users installing printer drivers on the terminal server.
\WTSRV\System32\viewers	FC: Administrators, System Read: Users Replace permissions on all subdirectories.	Contains the files for the quick viewers. Users will require read access to be able to use this functionality.

The list of directories shown in Table 11.1 is certainly comprehensive, but it is by no means complete. Depending on any additional components of Terminal Server that you may install, or other software that you add, other directories may exist to which you will need to apply security permissions. When assigning permissions to directories not listed, a good rule of thumb that we use is to be as restrictive as possible and adjust these rights only when required to ensure that a user can function properly. Always assume that the user does not require access until proven otherwise. Although it may increase the amount of work that you must do, it does provide you with better control over access and educates you on what control has been granted.

After you have assigned the specific directory permissions, there are a few specific file permissions that you should also set. These have to do with the actual boot files for the terminal server and will reside in the root of the system volume (see Table 11.2).

Table 11.2 TSE boot file permissions.

File	Suggested Permissions	Comments
Boot.ini	FC: Administrators, System	Contains the list of boot options
Ntdetect.com	FC: Administrators, System	TSE boot file
Ntldr	FC: Administrators, System	TSE boot file

Tip In Appendix C, "CACLS Scripts for System and Application Volume Permissions," we have created CACLS scripts that will set the permissions for both the system and application volumes as described. This _provides a repeatable, consistent means of applying file and directory _permissions without having to use Windows NT Explorer and setting them individually.

Auditing

After permissions have been set, one more task remains to be completed. You need to configure the file auditing for the system volume, just as we did for the user auditing earlier. Auditing is an important part not only for your file security, but also for your application integration.

As we mentioned earlier, you may need to modify permissions on certain files to allow certain applications to function properly. Auditing can help to determine whether an application is failing because of a lack of permissions.

Just as with user auditing, you will want to implement file auditing so that you can monitor your file system to ensure that no unauthorized changes (or attempts) are being made. We suggest that you enable auditing for Everyone, so that events are written regardless of who is on the server. The auditable file system events are as follows:

• Read—Read attempts are monitored when this event is selected. We recommend that you enable auditing for Read failures. Considering that most files on your Terminal Server will be readable, monitoring success may put a large number of entries in the event log. Certain files may be candidates for read success as well, depending on the sensitivity of their data.

  Write—All write attempts are logged when this event is selected. We recommend that you audit both write success and failure. Considering the locked-down nature of the terminal server, there should be very few writes to the server, with the following exceptions:

  • Updates to the pagefile.sys. Because this file is always in use, auditing cannot be set on it anyway.

  • Updates in the temp directories. Data will very often be written to the temp directories for users. You should omit read and write success auditing on the temp directory.

  • Legitimate updates by a Terminal Server administrator.

We suggest auditing write success to monitor the situation in which a Terminal Server administrator updates a file on the server. Whether intentional or by accident, this can help in determining what may have been changed, and by whom.

• Execute—This tracks the execution of files. We suggest that you always monitor execution failures. Depending on the files, you may want to also monitor success, particularly with the Terminal Server administration tools.

• Delete—Monitors the deletion of files. You should always monitor both successful and failed deletion attempts.

• Change Permissions—Whenever the permissions on a file are changed, it will be logged when this event is selected. We suggest monitoring both success and failure. Under normal circumstances, file permissions should not change on any of your Terminal Server volumes.

• Take Ownership—Any attempts at taking ownership of a file or directory are monitored with this event. Both success and failure should be monitored for this event.

File auditing is enabled by opening up the properties for a file or directory, selecting Security, then clicking on the Auditing button. Figure 11.17 shows an example of the Directory Auditing dialog box.

Figure 11.17: The Directory Auditing dialog box.

We suggest that you configure auditing on your system volume as follows:

1. From the root of your system volume, enable auditing for the Everyone group, making sure to replace auditing on subdirectories as well as existing files. Audit the following events:

   • Read: Failure

   • Write: Success and Failure

   • Execute: Failure

   • Delete: Success and Failure

   • Change Permissions: Success and Failure

   • Take Ownership: Success and Failure

2. From the Temp directory on the system volume, set auditing for the Everyone group, replacing auditing on existing files only. Audit the following events:

   • Read: Failure

   • Write: Failure

   • Execute: Success and Failure

   • Delete: Failure

   • Change Permissions: Success and Failure

   • Take Ownership: Success and Failure

We have specified both Success and Failure for Execute because, under almost all circumstances, no executable files are placed into the Temp directory for a user. Auditing this event will allow you to monitor whether a user has executed a file from his or her temp location. This could signal that the user has copied an executable from somewhere into his or her Temp directory and has then run that file from that location.

When auditing is enabled, events are written to the security event log, just as they are for user auditing. Regardless of the policies that you set, you should pay close attention to them, particularly in the beginning to ensure that you are satisfied with the auditing that you are performing and the events that are being captured.

Author's Note Unfortunately there is no Resource Kit tool to automate the setting of file auditing policies.

Application Volume

In general the application volume is much easier to configure for security because only applications are installed onto this volume, and access can be granted on a user group basis. You will usually be able to grant Full Control to the administrator and System and Read to users for the entire volume, _modifying permissions for specific applications only when appropriate.

Auditing

Just as with permissions on the application volume, auditing is also fairly straightforward. We recommend that the following auditing be set for the Everyone group on the entire Application volume:

• Read: Failure

• Write: Success and Failure

• Execute: Failure

• Delete: Success and Failure

• Change Permissions: Success and Failure

• Take Ownership: Success and Failure

Writes should happen on the application volume only when software is being deployed on your Terminal Server. You may need to create Audit exceptions if you need to define custom permissions in order to allow an application to run properly on Terminal Server.

Microsoft Zero Administration Kit for Terminal Server

In conjunction with the release of Terminal Server, Microsoft has made the Zero Administration Kit for Terminal Server (ZAK4WTS) available on their Web site. ZAK4WTS is intended to be a supplement to the ZAK for NT Workstation documentation and not a standalone solution. ZAK4WTS provides two components designed specifically for Terminal Server:

• An automatic lockdown of the file system permissions on the system drive.

• A set of preconfigured system policies designed to restrict a user's desktop on TSE.

Warning: ZAK4WTS is being provided by Microsoft on an as-is basis. They make no warranty as to the accuracy of the product, and at this point it is not officially supported.

ZAK4WTS File System Permission Lockdown

The first, and most substantial, change that ZAK4WTS will introduce to your Terminal Server is the file system lockdown. This file lockdown is performed by running the ZAK4WTS2.exe file that comes as part of this supplement. This executable performs the following:

• Creates the directories POL and SCRIPTS in WTSRV\ZAK, and copies the policy and lockdown scripts to the appropriate directories.

• A script file called ACLS.CMD is then automatically invoked. This script uses CACLS to apply permissions to all files on the system drive.

• When all permissions have been updated, the script HIDE.CMD is executed. This sets the hidden attribute for almost all files on the system drive.

Warning: When you execute the ZAK4WTS2.exe file, it will immediately begin to lock down the file system of the machine it is being executed on, whether it is a Terminal Server or a regular NT server. There is no way to extract the scripts without having it at least start to perform the permission lockdown. You should never run these scripts on a production Terminal Server because it will surely prevent users from being able to run applications that they had been able to run before. We suggest that you run this on a test machine so that the necessary ZAK files can be extracted. You will then be able to review the ACLS.CMD file and determine which changes are appropriate.

You should also be aware of the fact that as part of the ZAK4WTS2 setup, it will delete all entries from the directory %SystemRoot%\Profiles\All Users\Start Menu\Programs\Startup before the ACLS.CMD script is executed. You may want to back this up prior to running ZAK4WTS2.

ACLS.CMD

The permission changes made by ACLS.CMD are similar to those that we _discussed earlier for the file system with the following exceptions:

• Granted permissions are set for the Everyone group and not the local User group.

• The ability to access the NT Accessories (Notepad, and so on) is _completely removed.

• Everyone is given Change permission to the Temp directory. In addition to this, ZAK4WTS creates a file called secure.dir that users have no access to. This is done to prevent users from deleting the temp directory. Change access is more than users require. The system will automatically create a personal temp directory when a user logs on that has sufficient permissions for him or her. Giving users change access allows them to possibly interfere with other users on the system.

• Everyone is granted Change permission in the Profiles directory. Once again, these are greater permissions than are required because the system will handle creating the user's profile with sufficient access permissions.

• Everyone is given Change permission to the Spool directory. This will allow them to add print drivers to the terminal server if they want.

• Access to .INF, .EXE, and .HLP files under SYSTEM is denied.

• Permissions specific to Microsoft Office and Internet Explorer are enabled to ensure that they continue working after ACLS.CMD has been run. This includes providing change access to Everyone in the Office and Office\Templates directories.

HIDE.CMD

This script simply goes through the system drive and sets most files with the Hidden file attribute. Certain files such as PowerPoint files are purposely skipped to ensure the application continues to work properly. The reason for running this script is to hide files from casual viewing by users and administrators alike. The hide status can be reset after ZAK has been installed by running the UNHIDE.CMD file located in the WTSRV\ZAK\SCRIPTS directory.

Tip To view hidden files, open either My Computer or NT Explorer and select Options from the View menu. Select the View tab and click the Show All Files option button. Hidden files will now be visible.

ZAK4WTS System Policies

ZAK4WTS comes with two preconfigured system policies that you can use as-is or modify to suit your Terminal Server environment. For a complete discussion on creating and using system policies in a TSE environment, see Chapter 15, "User Profile, Policy, and Account Configuration."

Author's Note One very important point to understand is that ZAK4WTS is not a replacement for a proper understanding of what is required to establish a secure TSE environment. Unfortunately, the product comes across more as a solution than an educational tool, as demonstrated by the fact that it applies the file permission lockdown as part of its installation. This proactive approach is certain to cause frustration for many TSE administrators who would expect to be able to install the product before having it affect their environment. As we mentioned before, do not run this on a production Terminal Server.

Just as with our suggestions on file security, if you intend to use ZAK4WTS, you should review all components carefully and understand what benefits it does and does not provide.

The TSE Registry

The final area that we need to address for Terminal Server security is the Registry. Containing all of the critical configuration information for a Terminal Server, the Registry is a vital component of your server, and as such needs to be protected as much as possible.

Although we make frequent mention in this book of editing the contents of the Registry to change some configuration option, all direct updates to the Registry through REGEDT32 or some other tool must always be handled with caution. Incorrect changes to the Registry can render your server inoperable. Considering the caution that is required when making changes, it is easy to see why you need to take steps to protect the Registry. Protect it not only from those people who may want to intentionally cause problems, but also those who do not fully understand what they are doing or do not take the multiuser considerations of Terminal Server into account when making a change.

What makes the need for implementing Registry security even more important is the very nature of Terminal Server's multiuser capabilities, which allows users to establish sessions that are local to the server. Under the more traditional method of allowing users to log on to a local workstation, their only access to a server's Registry was remotely through REGEDT32. This was more easily protected with user policies. The fact that users are now local to the server means that they have much easier access to the Registry. If you are not already familiar with basic NT Registry security, we suggest you review Appendix D, "Registry Security," before continuing.

Securing the Registry

Although the Registry has security settings similar to those of the file system, the assignment of security in the Registry is much more difficult. The problem is that there are certain situations where applications may have a legitimate reason for writing into the Registry. This is particularly true for applications that have not been explicitly written for running on a Terminal Server. Because of this, Registry security must be handled on nearly a key-by-key basis. The complexity of this makes it a daunting task indeed. Luckily there are some things that we can point out and suggest to help you along with this.

When looking to improve Registry security, you will need to concentrate only on the HKEY_LOCAL_MACHINE \SOFTWARE key. The other root keys in HKEY_LOCAL_MACHINE, HARDWARE, SAM, and SYSTEM are configured during installation to grant only read access to non-administrator accounts. The HKEY_CURRENT_CONFIG key falls under the SYSTEM key, so permissions are already set properly for it. HKEY_CLASSES_ROOT falls under SOFTWARE, which we will talk about shortly. The HKEY_USERS key, which contains HKEY_CURRENT_USER, is most often controlled in a Terminal Server environment through roaming user profiles (mandatory and regular). In Chapter 15, we discuss user profiles in detail. It is during the creation of the user profile that you will configure any security that you want to appear in HKEY_USERS.

We will now discuss the security permissions that can be modified under the SOFTWARE key of the HKEY_LOCAL_MACHINE hive. Given the nature of Terminal Server as an execution environment for users to run applications from, and the fact that users are not granted the permission to add new software, certain permissions can be set in the Registry that you could not _normally set on an NT workstation. There are also keys that you would not normally find after installing NT Server or Workstation.

Warning: Although we have had success with the security modifications that we are going to discuss, this does not guarantee that these changes will work under all circumstances. It is very possible that certain applications exist that may not function properly when forced to run in a more secure environment.

You should review the changes carefully before you make them. When the changes are completed, test to ensure that your environment is functioning properly. You should always perform these changes on a test server that you can easily rebuild if necessary before you look at making changes on a server that you will have users run on. You should always take a backup of your Registry so that you can recover if necessary.

You should not be afraid to experiment, but you must ensure that you are not going to impact any users in the process.

SOFTWARE\Citrix

This key contains some Citrix MetaFrame configuration information. Users require only read access to this key and all subkeys as changes are only made through an administrator.

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENDR): Everyone	Read: Everyone Replace permissions on existing subkeys.

SOFTWARE\Classes

This contains all of the information on file associations as well as any installed OLE controls. By default, users are restricted from updating these associations through REGEDT32, but they do have the ability to change these associates by selecting Options from the View menu in NT Explorer. This can pose major problems on your Terminal Server, as an update to an association by a user will affect all users on that Terminal Server. Viewing the default permissions listed, you see that while the Everyone group has only Read access, the special group INTERACTIVE has special access, which allows for the updating of the Classes subkeys and values. To prevent users from being able to update associations, you need to remove the INTERACTIVE permission. Administrators will still be able to update and add new associates and OLE configuration information.

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENDR): INTERACTIVE	Read: Everyone
Read: Everyone	Replace permissions on existing subkeys.

SOFTWARE\Microsoft

The Microsoft key under SOFTWARE contains the majority of the configuration information for all of the Microsoft products that are installed during the Terminal Server setup, including many of the core components of TSE itself.

A few keys under this subkey already have adequate security permissions set, which allow users only Read access or no access at all. Although these keys will most likely not need to be modified, you should review the permissions for these keys to convince yourself that the existing permissions are adequate. These subkeys are

• NetDDE

• OLE

• OS/2 Subsystem for NT

• RPC

• Secure

The two other keys—Windows and Windows NT—will be discussed in the next two sections. The question remains about what to do with any remaining subkeys under SOFTWARE\Microsoft that are not part of the seven listed earlier. For most (if not all) of these keys you will find that they have the same default permissions that give everyone the ability to update or delete the values and subkeys. The default permissions and our suggested changes are shown in the following table:

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENDR): Everyone	Read: Everyone Replace permissions on existing subkeys.

When making any of these changes, you cannot make them at the SOFTWARE\Microsoft key itself, or the changes would traverse down through all of the subkeys, including the seven listed previously. To update the other subkeys, you will need to select them one at a time and make the necessary changes.

If you encounter a key that does not fall into the permissions listed earlier, we suggest that you do not make any changes until you are comfortable that the other changes you have made function properly. During your testing, you will want to use Registry auditing to watch for any attempted updates (writes or deletes) to the Registry by any test user accounts. These events may signal a requirement by an application to make changes to the Registry. For the base server installation, you should find that these changes will not affect the operation of your server in any way. The potential for problems may arise when you begin to include other applications, such as Microsoft Office.

SOFTWARE\Microsoft\Windows

This subkey contains a number of system defaults including some desktop default icons and even the tips that are displayed after logon. Although some subkeys have the Everyone group set to Read, a large number of them allow this group to update values and add keys. Only a few subkeys allow the deletion of values or keys.

It is interesting to note that most of these keys include permissions for the Power Users group. We prefer not to utilize this group at all, so when possible we eliminate the permissions for Power Users. You may want to keep them, but we suggest that you keep careful track of what users are members of the local Power Users group.

Warning: The default permissions for the local Power Users group on TSE are identical to those for a regular NT workstation. This includes allowing a power user to shut down a Terminal Server.

We suggest that you modify the permissions for the Windows key and all subkeys from the default to the following:

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENR): Everyone	Read: Everyone
Special Access (QSCENDR) Power Users:	Replace permissions on existing subkeys.

SOFTWARE\Microsoft\Windows NT

Although this subkey contains different system information, it has a very similar setup to the Windows subkey described earlier. Although a few subkeys under the Windows NT key do restrict the permissions of the Everyone group to READ, many of them do allow the addition of new keys, as well as the updating of existing values. The Power Users group is also assigned permissions within this key. The following groups already have the necessary _predefined permissions and should not be modified:

• Perflib

• ProfileList

For all other keys, you can assign the following suggested permissions. As was the case with the Windows key, if you encounter a subkey that has default permissions that differ from those shown, you may want to hold off modifying that key until you are sure that the changes you have made do not affect your server in any way.

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENR): Everyone	Read: Everyone
Special Access (QSCENDR): Power Users	Replace permissions on existing subkeys.

SOFTWARE\ODBC

This key contains the configuration information for 32-bit ODBC drivers and as such should be restricted to allow additions and modifications by only the administrators of the server. As with most other keys, here are the default _permissions and the suggested changes.

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENR): Everyone	Read: Everyone Replace permissions on existing subkeys.

Author's Note You will notice that in the ODBC.INI subkey, there is a Hydra License subkey. Terminal Server manages its licensing in a Jet database and uses the Jet ODBC driver to access it.

SOFTWARE\Windows 3.1 Migration Status

The final key that we suggest you update is the migration status for Windows 3.1. If you have upgraded from Windows 3.1, this key may contain some data. This key and the subkeys probably will not contain any values. Regardless, here are the suggested changes from the defaults:

Default Permissions	Suggested Permissions
Full Control: CREATOR OWNER, Administrators, SYSTEM	Full Control: CREATOR OWNER, Administrators, SYSTEM
Special Access (QSCENR): Everyone	Read: Everyone Replace permissions on existing subkeys.

Registry Auditing

As with file auditing, Registry auditing is both quick and straightforward to enable and configure. We strongly recommend that auditing be enabled for your Terminal Server Registry. To enable auditing, you will need to launch REGEDT32. Next, select the key that you want to audit, and then click on Auditing under the Security menu. Click the Add button to add in the users or groups that you want to audit. We recommend that you audit the Everyone group. Now you need to select the events that you want to audit. Figure 11.18 shows the Registry Key Auditing dialog box along with our recommended settings for auditing of the Registry.

Figure 11.18: The Registry Key Auditing dialog box.

Troubleshooting Tip It is worth noting that monitoring the success of the Query value or the Enumerate Subkeys events will generate a large number of event entries very quickly and should only be enabled when attempting to troubleshoot or resolve a specific issue.

You should enable auditing on both the HKEY_LOCAL_MACHINE and the HKEY_CURRENT_USERS hives. Remember that all of the other hives within REGEDT32 are merely pointers to subkeys within either of these two hives. Make sure to audit permissions on existing subkeys, too.

About the Authors

Todd W. Mathers is a thin-client consultant and software designer who specializes in application integration on Windows NT TSE and WinFrame. He is the founder of Noisy River Software Corporation, which implements thin-client solutions of all sizes using Terminal Server, MetaFrame, and WinFrame.

Shawn P. Genoway is Information Technology Benchmarking Lead and Process Manager for a leading wireless communications company.

Copyright © 1999 by MacMillan Technical Publishing

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order