Since the actual user sessions are executed on the Terminal Servers, they figure greater into a discussion of security. The basic actions to consider when securing your Terminal Servers are:
* Using the NTFS file system.
* Configuring NTFS file permissions.
* Using GPOs to secure the user environment.
* Installing Terminal Services on a domain controller.
* Disabling the "Secondary Logon" Service.
* Remove unnecessary software
* Applying hotfixes and service packs.
Use the NTFS File System
Each user that runs a session on a Terminal Server is essentially running a remote control console session. Without an NTFS file system, you won't be able to set any file-level security permissions. Any user that is logged would be able to access files in use by other users. No mechanism would prevent users from deleting key system files, potentially crashing the server!
There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an RDP session, even if his client is running on an operating system that cannot support NTFS, such as Windows 95.
Configure NTFS File Permissions
Using just the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your Terminal Servers or plan to run only initial applications, you should secure the basic file system.
When you install Terminal Services on a Windows 2003 server, you're asked whether you want to use "Full Security" or "Relaxed Security." This security setting has nothing to do with your domain configuration or your Active Directory environment. It affects only the level of security that users are given when they access your server via a Terminal Services session. To compare the two settings:
* Full Security. This setting results in Terminal Services users having the same permissions as regular members of the local users group. Regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this level of security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose Full Security, you should thoroughly test your applications before enabling them for any users.
* Relaxed Security This setting results in Terminal Services users having full access to many parts of the registry and many of the system files. This alternate level of security was developed to allow older applications to execute properly.
After selecting the "permissions compatibility" mode during the installation of Terminal Services you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:
Key: HKLM\System\CurrentControlSet\Control\Terminal Server\
Value: TSUserEnabled
Type: REG_DWORD
Data: 1 = Relaxed permissions. 0 = Full Security mode.
Do Not Install Terminal Services on a Domain Controller
Individual domain controllers cannot be managed separately from each other. In order for a user to be able to log on to Terminal Server sessions she must have "log on locally" (called "log on interactively" in Windows 2000) rights. If the Terminal Server is a domain controller, granting the user "log on locally" rights on the server will allow her to log on to any domain controller, even ones that are not Terminal Servers.
Also, domain controllers in Active Directory environments must be located in the "Domain Controllers" OU. You can't use OU-based Group Policy Objects if your Terminal Servers are installed on domain controllers.
Disable the "Secondary Logon" Service
Windows 2000 introduced a secondary logon ability (then called the "Run As" service) which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select "Run as..." from the context menu. Alternately, a user can enter the "runas" command into the command line.
Administrators often lock down Terminal Servers for those groups of users that should be using them. The secondary logon ability allows a user who's already connected to a Terminal Server to change his credentials, potentially bypassing any security measures the administrator has configured. (If you read the rest of this chapter, you'll know better than to build servers that exhibit this weakness.)
The secondary logon ability can be disabled at the server by stopping and disabling the "Secondary Logon" service. Disable the service after you stop it, or the system will start it again when it is needed.
Remove all Non-Essential Software
Any extra applications installed on your Terminal Servers represent an increased security risk. Each installed application brings introduces more vulnerabilities. Access to extra tools, (such as those included in the resource kits) makes compromising or abusing the server easier. You shouldn't give your users more than they need to do their job.
* Using the NTFS file system.
* Configuring NTFS file permissions.
* Using GPOs to secure the user environment.
* Installing Terminal Services on a domain controller.
* Disabling the "Secondary Logon" Service.
* Remove unnecessary software
* Applying hotfixes and service packs.
Use the NTFS File System
Each user that runs a session on a Terminal Server is essentially running a remote control console session. Without an NTFS file system, you won't be able to set any file-level security permissions. Any user that is logged would be able to access files in use by other users. No mechanism would prevent users from deleting key system files, potentially crashing the server!
There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an RDP session, even if his client is running on an operating system that cannot support NTFS, such as Windows 95.
Configure NTFS File Permissions
Using just the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your Terminal Servers or plan to run only initial applications, you should secure the basic file system.
When you install Terminal Services on a Windows 2003 server, you're asked whether you want to use "Full Security" or "Relaxed Security." This security setting has nothing to do with your domain configuration or your Active Directory environment. It affects only the level of security that users are given when they access your server via a Terminal Services session. To compare the two settings:
* Full Security. This setting results in Terminal Services users having the same permissions as regular members of the local users group. Regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this level of security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose Full Security, you should thoroughly test your applications before enabling them for any users.
* Relaxed Security This setting results in Terminal Services users having full access to many parts of the registry and many of the system files. This alternate level of security was developed to allow older applications to execute properly.
After selecting the "permissions compatibility" mode during the installation of Terminal Services you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:
Key: HKLM\System\CurrentControlSet\Control\Terminal Server\
Value: TSUserEnabled
Type: REG_DWORD
Data: 1 = Relaxed permissions. 0 = Full Security mode.
Do Not Install Terminal Services on a Domain Controller
Individual domain controllers cannot be managed separately from each other. In order for a user to be able to log on to Terminal Server sessions she must have "log on locally" (called "log on interactively" in Windows 2000) rights. If the Terminal Server is a domain controller, granting the user "log on locally" rights on the server will allow her to log on to any domain controller, even ones that are not Terminal Servers.
Also, domain controllers in Active Directory environments must be located in the "Domain Controllers" OU. You can't use OU-based Group Policy Objects if your Terminal Servers are installed on domain controllers.
Disable the "Secondary Logon" Service
Windows 2000 introduced a secondary logon ability (then called the "Run As" service) which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select "Run as..." from the context menu. Alternately, a user can enter the "runas" command into the command line.
Administrators often lock down Terminal Servers for those groups of users that should be using them. The secondary logon ability allows a user who's already connected to a Terminal Server to change his credentials, potentially bypassing any security measures the administrator has configured. (If you read the rest of this chapter, you'll know better than to build servers that exhibit this weakness.)
The secondary logon ability can be disabled at the server by stopping and disabling the "Secondary Logon" service. Disable the service after you stop it, or the system will start it again when it is needed.
Remove all Non-Essential Software
Any extra applications installed on your Terminal Servers represent an increased security risk. Each installed application brings introduces more vulnerabilities. Access to extra tools, (such as those included in the resource kits) makes compromising or abusing the server easier. You shouldn't give your users more than they need to do their job.
Source: http://www.brianmadden.com/blogs/terminal_services_for_microsoft_windows_server_2003_advanced_technical_design_guide/pages/server-security.aspx
No comments:
Post a Comment