Home > Articles > Operating Systems, Server > Microsoft Servers

This chapter is from the book

System Privileges and Restrictions

Once an authorized user has logged on to the Terminal Server, the security focus shifts from one of complete access prevention to one of access restriction. A user's ability to interact with objects in the system is managed through user rights, system security restrictions, administrative templates, and file and registry restrictions. The task of configuring these settings is further complicated by the need to ensure that adequate session security exists while still providing the functionality required by the users to perform their job.

As I discussed in the "Administrative Delegation" section of this chapter, whenever possible system privileges and restrictions should be managed using local user groups as opposed to individual user accounts or domain security groups. The idea is to then assign the desired domain group or user to the corresponding local group that is appropriate for their access level. Assignment of access rights on a Terminal Server should be kept as simple as possible. When the security requirements become too complex, this increases the likelihood that some setting may be missed. In most implementations this means dividing the users into two categories when delegating access rights. Either the user is a member of the Administrators group, with full rights to the entire server, or the user is a member of the Users group, with only limited access to the server's resources.

NOTE

With such a simplified division of access rights (Administrators group or Users group), care must be taken when the default Users permissions are not sufficient to let a user perform a particular job function. In most circumstances this occurs when an application does not operate properly under the limited privileges granted the Users group.

A common reaction to this type of problem, particularly under pressure from the user community to come up with a quick solution, is to assign regular users full administrative access. While this certainly resolves the application issue, it is critical that this never be allowed on a production Terminal Server. Such privilege elevation immediately brings the integrity of the Terminal Server into question since any mistake by a user can render the server completely unusable.

Assignment of privileges when pertaining to application integration is discussed in the "Application Privileges and Restrictions" section of this chapter.

User Rights Assignment

User rights are a special set of privileges that define which basic operating system functions a user or group of users can perform. While I recommend that you review the User Rights configuration on your server to ensure that the appropriate groups have been defined, under most circumstances you will not have to modify the default settings. Figure 16.15 shows the default User Rights Assignment policies for a Windows 2003 Terminal Server as viewed from within the Local Security Settings MMC snap-in. This utility is found under Administrative Tools on the Start menu for both Windows 2000 and 2003 and is used to view the settings currently in effect on the server.

Figure 16.15Figure 16.15 The default User Rights Assignment policies for a Windows 2003 Terminal Server.

While the Local Security Settings snap-in is used to review the current settings on a Terminal Server, if you wish to make changes to the User Rights Assignment policies, I recommend that they be performed within the Terminal Server Machine Policy defined in Active Directory and not within the Local Security Settings snap-in. This ensures consistency across all Terminal Servers in your domain, since all necessary policy settings are automatically applied once the policy has been added to the Terminal Servers organizational unit. Policies defined at the domain level always take precedence over those options set locally when a conflict occurs.

When assigning user rights within a GPO, make certain that you include all the groups that require access to that user right. Rights defined within a GPO override the local settings; they do not merge with them. Also be aware that because the GPO affects all servers within the organizational unit, you need to assign permissions based on the domain groups and not the local groups of a specific server. As I discussed in Chapter 15, this is an exception to the general rule of assigning permissions based on local groups. Because GPOs are defined at the domain level, domain-level groups must be used. Figure 16.16 shows an example of User Rights Assignment policies defined within a Terminal Server Machine Policy for the Terminal Servers OU in a Windows 20003 domain.

Figure 16.16Figure 16.16 A User Rights Assignment policies example in a Windows 2003 Active Directory domain.

Table 16.4 lists the user rights for both Windows 2000 and 2003 that most directly pertain to a Terminal Server. A complete explanation of each of the Windows 2000 user rights can be found in the Group Policy Reference included in the Windows 2000 Resource Kit documentation. An explanation of the Windows 2003 user rights can be found simply by right-clicking the desired user right and selecting Help.

Table 16.4 Terminal Server–related User Rights Assignment Policies for Windows 2000 and 2003

Windows Server 2003

Windows 2000

Explanation

Access this computer from the network.

Access this computer from the network.

This right is not required for a user to be able to establish a Terminal Server session. This right is required only if you will be sharing folders or printers off the Terminal Server.

 

 

The default group assignments can be limited to only Administrators if no file or print sharing is required.

Deny access to this computer from the network.

Deny access to this computer from the network.

Members of this group are explicitly denied access to network resources on this server. The Deny property overrides any other permissions that might be assigned.

Allow log on locally.

Log on locally.

This right is required for a user to be able to interactively log on to the server. On a Windows 2000 server this right is required to be able to log on to a Terminal Server session. On a Windows 2003 Terminal Server this right is required only when logging on directly from the server console. Omitting or denying this user right does not prevent a user from being able to establish a Windows 2003 Terminal Server session as long as they possess the "Allow log on through Terminal Services" privilege.

Allow log on through Terminal Services.

Log on locally.

To establish a Terminal Server session a user must have this user right. Without it a user receives the message "The local policy of this system does not permit you to logon interactively" immediately after providing their logon credentials.


WARNING

Use caution when modifying the default User Rights Assignment policy for a Terminal Server. Incorrectly restricting the rights can adversely affect server operability.

Local Security Options

Windows local Security Options policies allow an administrator to configure additional machine-specific security settings. As with local User Rights Assignment policies, it is recommended that changes to the local Security Options policies be performed within the Terminal Server Machine Policy and not directly on the individual Terminal Servers. Table 16.5 lists the changes I suggest making to local Security Options policies for your production Terminal Servers.

Table 16.5 Suggested Local Security Options Policies Changes for a Windows Terminal Server Environment

Windows Server 2003

Windows 2000 Server

Explanation

Accounts: Guest account status.

N/A

(W2K3 only.) Controls whether the local Guest account is enabled or disabled. While it is disabled by default, enforcing the disabled status for the Guest account is always a good security practice.

Accounts: Rename administrator account.

Rename administrator account.

Lets you define an alternate name for the local Administrators account. This simple change makes it more difficult for someone to guess the administrator's password, since they won't even know what the local administrator's account name is. Be sure to select an alternate name you can remember but is not immediately obvious to a would-be hacker. This option is disabled by default.

Accounts: Rename guest account.

Rename guest account.

Even though it's disabled, renaming the Guest account to something more obscure is a good security practice.

Devices: Prevent users from installing printer drivers.

Prevent users from installing printer drivers.

Enabled by default on all Windows servers. On a Terminal Server in particular you do not want users to have the ability to arbitrarily install printer drivers when connecting to a network printer. While most Windows 2000/2003 printer drivers work without issue on a Terminal Server, it is still best if an administrator monitors what drivers are and are not available to the users. A single ill-behaved printer driver can easily cause a Terminal Server to crash with a STOP error (blue screen of death).

Interactive logon: Do not display last user name.

Do not display last user name in logon screen.

When an RDP session is initiated to a Terminal Server, the logon screen automatically displays the name of the last user to log on to that server from that particular client machine. Enabling this security option eliminates this behavior. The ICA client never displays the name of the last user to log on, and as such this option has no effect on the ICA client's behavior.


Administrative Templates

In Chapter 15, I discussed use of administrative templates and how they provide a centralized mechanism for applying behavioral changes and restrictions to both the target computers in the organizational unit and the users who log on to those computers. Both Windows 2000 and 2003 provide a set of standard administrative templates that include a number of security-related options. Windows Server 2003 includes new template options as well as updated naming for many of the options found in Windows 2000 Server. Because of this, I divide my policy suggestions into two separate tables. Table 16.6 lists suggested security settings for Windows 2000, while Table 16.7 lists my equivalent settings for Windows 2003. These suggestions have been subdivided based on the group policy object they should be applied in. The categories used are Terminal Server All Users Policy, Terminal Server Regular Users Policy, and Terminal Server Machine Policy. These tables list only Windows system-specific changes and no application-related settings that may pertain to a Terminal Server environment. These types of changes are discussed in the later section "Application Privileges and Restrictions."

TIP

As I discussed in Chapter 15, customized or third-party administrative templates can be added to the active directory, allowing for the centralized management of applications or additional Windows components. Applications such as Microsoft Office support extensive configuration via administrative templates. You can also create your own custom .ADM files. General information on creation of custom administrative templates can be found in Microsoft knowledgebase article 323639.

Table 16.6 Windows 2000 Administrative Template Security Suggestions

Administrative Templates Policy

GPO Affected

Explanation

Start Menu & Taskbar

Terminal Server All Users

 

Add Logoff to the Start Menu.

 

This ensures that all users have the Logoff <UserName> option on the Start menu.

Disable and remove the shutdown command.

 

This option makes it more difficult for even an administrator to accidentally shutdown a Terminal Server. On more than one occasion I've witnessed an administrator accidentally select Shutdown instead of logoff and acknowledge the action before they even know they've done so. An administrator can still shutdown a server by using the TSSHUTDN command from a command prompt.

Windows Components\ Windows Explorer

Terminal Server All Users

 

Only allow approved Shell extensions.

 

This setting ensures that only those Shell extensions approved by an administrator are allowed to load when Explorer starts.

Windows Components\ Windows Explorer

Terminal Server Regular Users

 

Hide the Manage item on the Windows Explorer context menu.

 

Removes the Manage item from Explorer and My Computer. If the MMC snap-in access has been prohibited (see Microsoft Management Console later in this table), this menu item has no effect on regular users, but I like to completely remove it as part of my standard configuration.

Hide Hardware tab.

 

This setting removes the Hardware tab from all local drives on the server, preventing users from being able to see what hardware is being used for hard drives, CD-ROM drives, and so on.

Disable DFS tab.

 

When a user has a drive mapping to a distributed file system (DFS) share, the DFS tab is available on the Properties dialog box. This option disables access to this tab, preventing users from seeing the available physical locations for the particular DFS share point.

Windows Components\ Microsoft Management Console\

Terminal Server Regular Users

 

Restrict users to the explicitly permitted list of snap-ins.

 

Enabling this policy prohibits all regular users from accessing any MMC snap-in.

Start Menu & Taskbar

Terminal Server Regular Users

 

Disable and remove links to Windows Update.

 

Removes the link to Windows Update from the Start menu and prevents the users from accessing the Windows Update Web site.

Remove Network & Dial-up Connections from Start Menu.

 

Completely removes access to the Network & Dial-up Connections folder, preventing users from finding out specific details about the server's network configuration.

Remove Run menu from Start Menu.

 

Eliminating this option from the Start menu prevents users from quickly launching an application by name. This policy does not prevent users from starting applications present on the Start menu or double-clicking them through Windows Explorer.

Disable user tracking.

 

Windows enhances the user's work experience by tracking user-specific information such as what applications they commonly run, the documents they open, and so on. Disabling this option turns off this tracking feature.

Desktop

Terminal Server Regular Users

 

Remove Properties from My Computer context menu.

 

Disables access to the System Properties the dialog box for the My Computer icon. This dialog box provides general access to information such as available memory, CPU type, and operating system version.

Prohibit users from changing My Documents path.

 

If you redirected the My Documents folder for your users, you must implement this policy. Normally users have the ability to change their My Documents path, and allowing such access could result in users storing sensitive documents in a location where they may be easily accessible by others or omitted from the regular backup process. Enabling this policy does not affect use of the folder redirection policy.

Desktop\Active Desktop

Terminal Server Regular Users

 

Disable Active Desktop.

 

In addition to providing a performance improvement, this policy increases security by preventing Web-based content from being enabled directly on the user's desktop.

Control Panel

Terminal Server Regular Users

 

Show only specified control panel applets.

 

If users require access to one or more control panel applets, only those specific options should be made available and all other entries suppressed. Usually I provide users with access to only the Display applet so they have access to make minor changes to their visual desktop experience. The specific applet file name is DESK.CPL.

Control Panel\Add/Remove Programs

Terminal Server Regular Users

 

Disable Add/Remove Programs.

 

This option completely eliminates access for all regular users to the Add/Remove Program option.

Control Panel\Display

Terminal Server Regular Users

 

Hide Screen Saver tab.

 

Very often, users try to run custom screen savers without realizing they not only consume available system resources but also can pose a security risk. Removing access to the Screen Saver tab prevents users from easily configuring and activating screen savers. It does not prevent a user from directly executing a screensaver file (*.scr) that he or she may have acquired through email or a Web site.

Network\Offline Files

Terminal Server Regular Users

 

Disable user configuration of Offline Files.

 

Completely removes the user's ability to modify the Offline Files menu option. Offline files in general can pose a security risk by making files available in a location that may not be secure.

Disable 'Make Available Offline'.

 

Turns off the ability to make files or folders available offline.

Network\Network and Dial-up Connections.

Terminal Server Regular Users

 

Prohibit access to properties of a LAN connection.

 

While users typically do not have access to modify the properties for a LAN connection, by default they can still view network configuration options. Enforcing this policy prevents access to this information.

Prohibit viewing of status statistics for an active connection.

 

Users do not require access to the statistics for a LAN connection. These statistics provide information such as link speed and connection uptime. The properties for the LAN connection are also directly accessible from here.

System

Terminal Server Regular Users

 

Disable the command prompt.

 

Enabling this policy prevents users from directly launching a command prompt while still allowing scripts (logon, startup, and so on) to be processed.

Disable registry editing tools.

 

When enabled, this policy prevents users from being able to run the registry tools REGEDIT and REGEDT32. Users can still update the registry by directly running valid .REG files, but interactive traversal of the registry through either tool is not permitted.

 

 

To effectively limit what applications a user can run on a Terminal Server, the policy "Run only allowed Windows applications" should be enabled and configured. I discuss configuration steps for this policy in the later section "Application Privileges and Restrictions."

System\Logon/Logoff

Terminal Server Regular Users

 

Disable Task Manager

 

Prevents users from viewing their running processes as well as seeing the current performance statistics for the server.


TIP

Windows Server 2003 administrative templates provide extensive support for many of the Terminal Services options normally configured through the Terminal Services Configuration utility. Unless otherwise stated, any Terminal Server client-related settings defined in a Windows 2003 administrative template apply to only RDP connections. Citrix ICA (MetaFrame) connections are not affected by most of these group policies.

Table 16.7 Windows 2003 Administrative Template Security Suggestions

Administrative Templates Policy

GPO Affected

Explanation

Windows Components\Internet Information Services

Terminal Server Machine Policy

 

Prevent IIS Installation.

 

This policy is intended to prevent an administrator from installing IIS or any applications that require IIS.

Windows Components\ Terminal Services

Terminal Server Machine Policy

 

Restrict Terminal Services users to a single remote session.

 

This policy limits a user to a single active Terminal Server session and is enabled by default on all Windows 2003 Terminal Servers. Note that it is applied on a perserver basis and does not restrict a user from having active simultaneous sessions on different Terminal Servers.

Limit number of connections.

 

This sets the maximum number of concurrent connections supported on the server. Enabling this policy in conjunction with the previous policy helps protect a Terminal Server against a crude denial-of-service attack performed by logging on to the server with the same user continuously until all server resources are exhausted. The maximum number of connections should be set to match the maximum number of users supported by your server-sizing estimate.

Sets rules for remote control of Terminal Services user sessions.

 

As I discussed in Chapter 8, remote control allows an administrator (or other authorized user) to connect into a user's session and interact with the environment. This policy lets you configure the rules for remote control on each Terminal Server. There are four choices available:

  • No remote control allowed at all. This feature is completely disabled. In highly secure environments where even an administrator should not be able to view a user's session, this option may be selected.

  • Full control with user's permission. I recommend this option for most implementations. A user must explicitly grant an administrator access before they can control the user's session. This ensures an administrator cannot remotely control a user's session without the user's knowledge.

  • Full control without user's permission. This option can introduce a security risk as an authorized user could shadow another user, manipulate their session, and then exit without the user even knowing. One way to counteract this would be to proactively monitor audit logs for shadowing. I do not recommend selecting this option for the remote control configuration.

  • View session with/without user's permission. Similar to the previous two entries except that the administrator shadowing the user cannot interact with the user's session in any way but can only view what the user is doing.

Windows Components\Terminal Services\Client/Server data redirection

Terminal Server Machine Policy

These policies control the behavior of various data redirection options supported by Windows 2003 Terminal Services. The requirements of your implementation will dictate what redirection options will be used. It is good practice to disallow all options not required. For example, if client drive redirection is not required, the associated policy "Do not allow drive redirection" should be explicitly enabled to prevent this client drive mapping for any remote user.

Windows Components\Terminal Services\Encryption and Security

Terminal Server Machine Policy

 

Always prompt client for password upon connection.

 

The RDP client supports entry and caching of a user's password so it can be automatically passed to the server to log the user on. Enabling this policy causes the Terminal Server to ignore any password passed by the client and instead always prompts the user to provide their password.

Set client connection encryption level.

 

The minimum encryption level required by an RDP client connecting to a Windows 2003 Terminal Server is set to High by default, but you can ensure this option isn't changed by enabling this policy and selecting High Level.

Windows Components\ Windows Explorer

Terminal Server All Users

 

Allow only per user or approved shell extensions.

 

This setting ensures that only those shell extensions that have been approved by an administrator or run only for a single user are allowed to load when Explorer starts.

Start Menu & Taskbar

Terminal Server All Users

 

Add Logoff to the Start Menu.

 

This ensures that all users have the Logoff <UserName> option on the Start menu.

Remove and prevent access to the Shut Down command.

 

This option makes it more difficult for even an administrator to accidentally shut down a Terminal Server. On more than one occasion I've witnessed an administrator accidentally select Shutdown instead of Logoff and acknowledge the action before they even know they've done so. An administrator can still shut down a server by using the TSSHUTDN command from a command prompt.

Windows Components\Windows Explorer

Terminal Server Regular Users

 

Hide the Manage item on the Windows Explorer context menu.

 

Removes the Manage item from Explorer and My Computer. If the MMC snap-in access has been prohibited (see Microsoft Management Console later in this table), this menu item has no effect on regular users, but I like to completely remove it as part of my standard configuration.

Remove Hardware tab.

 

This setting removes the Hardware tab from all local drives on the server, preventing users from being able to see what hardware is being used for hard drives, CD-ROM drives, and so on.

Remove DFS tab.

 

When a user has a drive mapping to a DFS share, the DFS tab is available on the Properties dialog box. This option disables access to this tab, preventing users from seeing the available physical locations for the particular DFS share point.

Windows Components\ Microsoft Management Console\

Terminal Server Regular Users

 

Restrict users to the explicitly permitted list of snap-ins.

 

Enabling this policy prohibits all regular users from accessing any MMC snap-in. Be aware that you may need to add specific snap-ins to the permitted list within Terminal Server User Support Policy.

Start Menu & Taskbar

Terminal Server Regular Users

 

Disable links and access to Windows Update.

 

Removes the link to Windows Update the Start menu and prevents the users from accessing the Windows Update Web site.

Remove Network Connections from Start Menu.

 

Completely removes access to the Network Connections folder, preventing users from finding out specific details about the server's network configuration.

Remove Run menu from Start Menu.

 

Eliminating this option from the Start menu prevents users from quickly launching an application by name. This policy does not prevent users from starting applications present on the Start menu or double-clicking them through Windows Explorer. The ability to launch programs or navigate folders through the Internet Explorer address bar is blocked.

Turn off user tracking.

 

Windows enhances the user's work experience by tracking user-specific information such as what applications they commonly run, the documents they open, and so on. Disabling this option turns off this tracking feature.

Desktop

Terminal Server Regular Users

 

Remove Properties from the My Computer context menu.

 

Disables access to the System Properties dialog box for the My Computer icon. This dialog box provides general access to information such as available memory, CPU type, and operating system version.

Prohibit user from changing My Documents path.

 

If you redirected the My Documents folder for your users, you must implement this policy. Normally users have the ability to change their My Documents path, and allowing such access could result in users storing sensitive documents in a location where they may be easily accessible by others or omitted from the regular backup process. Enabling this policy does not affect use of the folder redirection policy.

Desktop\Active Desktop

Terminal Server Regular Users

 

Disable Active Desktop.

 

In addition to providing a performance im-provement, this option increases security by preventing Web-based content from being enabled directly on the user's desktop.

Control Panel

Terminal Server Regular Users

 

Show only specified control panel applets.

 

If users require access to one or more control panel applets, only those specific options should be made available and all other entries suppressed. Usually I provide users with access to only the Display applet so they have access to make minor changes to their visual desktop experience. The specific applet file name is DESK.CPL.

Control Panel\Add/ Remove Programs

Terminal Server Regular Users

 

Remove Add or Remove Programs.

 

This option completely eliminates access for all regular users to the Add/Remove Program option.

Control Panel\Display

Terminal Server Regular Users

 

Hide Screen Saver tab.

 

Very often, users try to run custom screen savers without realizing they not only consume available system resources but also can pose a security risk. Removing access to the Screen Saver tab prevents users from easily configuring and activating screen savers.

Control Panel\Display\ Desktop Themes

Terminal Server Regular Users

 

Remove Theme option.

 

Completely removes the Themes tab from the Display dialog box.

Network\Offline Files

Terminal Server Regular Users

 

Prohibit user configuration of Offline Files.

 

Completely removes the user's ability to modify the Offline Files menu option. Offline files in general can pose a security risk by making files available in a location that may not be secure.

Remove 'Make Available Offline'.

 

Turns off the ability to make files or folders available offline.

Network\Network Connections

Terminal Server Regular Users

 

Prohibit access to properties of a LAN connection.

 

While users typically do not have access to modify the properties for a LAN connection, by default they can still view network configuration options. Enforcing this policy prevents access to this information.

Prohibit viewing of status statistics for an active connection.

 

Users do not require access to the statistics for a LAN connection. These statistics provide information such as link speed and connection uptime. The properties for the LAN connection are also directly accessible from here.

System

Terminal Server Regular Users

 

Prevent access to the command prompt.

 

Enabling this policy prevents users from directly launching a command prompt while still allowing scripts (logon, startup, and so on) to be processed. While the stability of this option has improved over earlier versions of Windows Terminal Services, anomalies with certain applications that rely on access to a command prompt may exist. Proper testing is very important when this policy has been enabled.

Prevent access to registry editing tools.

 

When enabled, this policy prevents users from being able to run the registry tools REGEDIT and REGEDT32. Users can still update the registry by directly running valid .REG files, but interactive traversal of the registry through either tool is not permitted.

 

 

To effectively limit what applications a user can run on a Terminal Server, the policy "Run only allowed Windows applications" should be enabled and configured. I discuss configuration steps for this policy in the later section "Application Privileges and Restrictions."

System\Ctrl+Alt+Del Options

Terminal Server Regular Users

 

Remove Task Manager.

 

Prevents users from viewing their running processes as well as seeing the current performance statistics for the server.


File and Registry Restrictions

Chapter 8 discussed the file and registry security configuration on a Windows 2000/2003 Terminal Server and how they are both more secure when the Permission Compatibility option is set to Full Security on a Windows 2003 Terminal Server and set to Permissions Compatible with Windows 2000 Users on a Windows 2000 Terminal Server. Figure 16.17 shows the Permission Compatibility dialog box from within the Windows 2003 Terminal Services Configuration utility.

File Security Permissions

In Chapter 8 I talked about the following four general rules for file server security:

  1. Divide the server's storage into at least two logical drives. For my discussions in this chapter I assume that the server drives are X: for the system drive and Y: for the application drive.

  2. When assigning permissions, restrict access to read-only and then grant or revoke permissions as required. When Permission Compatibility has been set to Full Security, as just discussed, the file system for the most part is already secure. There is one major change required on a Windows 2000 Terminal Server, which is discussed later in this section.

  3. Script security changes so they're reproducible. File permission changes can be easily scripted using the CACLS command line file security utility that is included with both Windows 2000 and 2003.

  4. Be certain to implement all file security prior to installing any applications onto the Terminal Server. I discuss suggested default security settings for the application drive immediately after the system drive discussion. Security-related issues with application installation and execution are discussed in more detail in Chapter 21, "Application Integration."

Figure 16.17Figure 16.17 The Windows 2003 Terminal Services Permission Compatibility dialog box.

On a Windows 2003 Terminal Server the default file system permissions provided with the Full Security option provide a suitable security configuration for the system drive. No custom changes are necessary unless you want to be very restrictive in folders and executables accessible by your Terminal Server users. A Windows 2000 Terminal Server, even with the Permissions Compatible with Windows 2000 Users option set, requires one rather significant change to the permissions on the root of the system drive in order to properly secure the volume.

During installation of Windows 2000, the Everyone group is assigned Full Control access to the root of the system drive by default. On a Terminal Server this configuration is unacceptable because it lets a regular user add files or folders to the root of the system drive, which in turn can potentially cause stability- or security-related issues. This can be corrected by assigning the following permissions to the root of the system drive only:

  • Administrators (Full Control)

  • SYSTEM (Full Control)

  • Users (Read)

These permissions should not be propagated to all subfolders but instead should be applied to only the root of the drive. The following simple CACLS script demonstrates how this type of configuration can be scripted for reuse on all Windows 2000 Terminal Servers in the environment.

@ECHO OFF
ECHO Setting security permissions on system volume. Please wait...


REM ** Grant local Administrators and SYSTEM Full Control
REM ** Grant local Users READ access to the root of the system volume.


CACLS X:\ /c /g Administrators:F SYSTEM:F Users:R

Configuring the initial application-volume security permissions is the same for both Windows 2000 and 2003 Terminal Server. I always set the initial application volume permissions as follows:

  • Administrators (Full Control)

  • SYSTEM (Full Control)

  • Users (Read)

As I mentioned, you need to treat this as the starting point when installing the applications into your Terminal Server. In some situations, you may be required to grant permissions other than Read to certain files or folders for an application to function properly. I always recommend that you start out as restrictively as possible and then loosen up only when required. Make sure that you clearly document these exceptions and place them into a script so the changes can be reapplied if necessary. The following script can be used to assign the default permissions on the application volume.

@ECHO OFF
ECHO Setting security permissions on application volume. Please wait...


REM ** Grant local Administrators and SYSTEM Full Control
REM ** Grant local Users READ access to the entire volume.
REM ** Permissions should be adjusted on specific applications if necessary.


CACLS Y:\ /T /c /g Administrators:F SYSTEM:F Users:R
ECHO y|CACLS Y:\* /T /c /g Administrators:F SYSTEM:F Users:R


REM ** Application-specific changes should be appended below.

NOTE

If you have implemented a separate pagefile drive on your server, you should assign the same default permissions to this volume as you've assigned your application volume, otherwise users will have unrestricted access to write data to this drive, which in turn can cause security or stability issues.

Registry Security Permissions

While the registry's security requirements are similar to those of the file system, the process of assigning security in the registry can be much more difficult. The problem is that in certain situations an application can have a legitimate reason for writing to the registry. Fortunately, most applications available today are adhering to the standard of writing machine-specific information to the HKEY_LOCAL_MACHINE key (normally done during installation) while maintaining user-specific information in the user's personal profile (HKEY_CURRENT_USER). By default, users have write access to their personal registry but not to HKEY_LOCAL_MACHINE.

If the Full Security option is not enabled, users gain additional write privileges within the registry that they normally do not have. These permissions have been granted to the special Terminal Server Users group, which is automatically assigned to Terminal Server users when legacy application support has been enabled by reducing the Terminal Server security configuration. As long as the Windows 2000 or 2003 Terminal Server is using full security, the default registry permissions do not need to be modified to support the multiuser environment.

Another part of proper registry security is restricting access to the Registry Editor tools (REGEDIT and REGEDT32). The group policy change that should be made to restrict access to these tools was discussed in the "Administrative Templates" section, earlier in this chapter. When this change is implemented, if a user attempts to launch a Windows registry tool a message similar to the one shown in Figure 16.18 appears.

Figure 16.18Figure 16.18 The message that appears when Registry Editor tool restrictions have been implemented on a Windows 2000 Terminal Server.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020