Terminal Server Security
This chapter is from the book
This chapter is from the book
This chapter is from the book
Before You Begin
Regardless of the size of your Terminal Server environment, it is imperative that you take the time to properly assess the security requirements of your infrastructure. Unlike the typical Windows server, a Terminal Server lets users interact with the server in very unpredictable ways. You must provide a security mechanism that protects the Terminal Server both internally and externally. After the user has established a connection, he or she has an interactive presence on the server with direct access to the resources shared between all users, such as disk and memory. Actions of one user can have an impact on all other users on the system unless the proper steps are taken to protect against this possibility. This requirement covers all users, including system and network administrators.
Considering the multiuser nature of a Terminal Server environment, even with little risk of a malicious threat, an accidental change performed by a single user could affect every other user on the system. For this reason, the key to developing a suitable security configuration requires the right balance between mitigating risks while still providing an environment within which the end user can perform their dictated job function. While a server can be hardened to the point where it is extremely secure, the end result might be a configuration completely unusable from an end user's perspective. This chapter focuses on helping you decide and implement the desired level of security suitable for your Terminal Server implementation.
Most security settings discussed in this chapter are implemented using group policy objects (GPOs) in a Windows Active Directory domain. An overview of implementation and use of a GPO is provided in Chapter 15, "Group Policy Configuration." The information covered in Chapter 15 forms the foundation on which the security changes in this chapter are discussed. If you're unfamiliar with configuration of group policies in an active directory, I highly recommend reviewing Chapter 15 before proceeding. Figure 16.1 shows the sample organizational unit (OU) configuration I use to demonstrate the security changes discussed in this chapter. As you can see, this follows the suggestions outlined in Chapter 15, whereby an organizational unit called Member Servers exists off the domain root, and under here an OU exists for each of the subcategories of member servers. In this case, I have an OU for Terminal Servers, file servers, and print servers.
)
Figure
16.1 Sample "Member Servers" OU configuration containing Terminal
Servers.
NOTE
Entire books have been written on the subject of Active Directory configuration, and details of such a configuration are beyond the scope of this book. For the purpose of this chapter I focus on configuration of the Terminal Server organizational unit in an active directory.
While most screen shots in this chapter come from a Windows 2000 domain controller, unless otherwise noted, the exact same steps can be performed against a Windows 2003 domain controller.
In Chapter 8, "Server Installation and Management Planning," I briefly discussed the eight areas of Terminal Server security that I recommend all administrators consider when developing a security implementation plan for their environment. Figure 16.2 shows a simple visual representation of these eight layers, which I discuss in more detail in the next few sections of this chapter.
)
Figure
16.2 The eight recommended areas of review for Terminal Server security.
Physical access—Physical access to your Terminal Server (and associated server hardware) should be restricted as much as possible to only the people responsible for managing the Terminal Server environment.
Administrative delegation—Before any other security considerations can be addressed, a decision must be made as to who will have administrative authority over the Terminal Server OU and all servers that reside within this OU.
User authentication—Almost all Terminal Server implementations have some form of user authentication to verify that a user is who they declare themselves to be. The most common form of authentication is the combination of user ID and password. In most organizations, this is also typically the weakest and most vulnerable of the security layers.
User authorization—Unlike user authentication, which deals with verifying identity of a user, user authorization deals with regulating what users have access to log on and what server resources they can access. Just because a user is who they say they are does not necessarily mean they are authorized to access the resource they are attempting to use.
System privileges and restrictions—Once an authorized user has logged on to the Terminal Server, their ability to interact with objects on the server is managed through user rights, security restrictions, and administrative templates. These three components work in combination to limit a user's access to only those components of the server pertinent to their job function.
Application privileges and restrictions—Usually access to the applications on a Terminal Server should be restricted to a subset of users based on their job function. For example, administrative applications are available only to administrators, while accounting-related applications should be accessible only to the accounting staff.
System auditing—Once you have implemented the desired security configuration for your Terminal Servers, you need a means of monitoring effectiveness of the configuration and flagging suspicious activity when it occurs. System auditing is an important part of any secure environment but is of little use unless an effective means of monitoring the logged information is also implemented.
-
Security patch management—A critical part of any secure environment is the timely deployment of all appropriate security patches. Poor patch management can be particularly damaging to a Terminal Server environment, since many of the ex-ploits released into the wild specifically target end users and impact common applications such as Outlook or Internet Explorer. While a properly secured server normally limits the effects a user can have on stability of the server, some exploits can specifically target privilege elevation, effectively granting administrative access to the user's session and allowing a malicious program to cause system-wide problems. In Chapter 9, "Service Pack and Hotfix Management," I discussed security patch management in detail.