Remote Desktop Services should be secured using
standard security guidelines and policies defined by an organization. In
addition to an organization’s security standards and guidelines, it is
advisable that administrators use recommended best practices compiled by
Microsoft, as well as the National Institute of Standards and
Technologies (NIST) and the National
Security Agency (NSA). Both NIST and NSA provide security lockdown
configuration standards and guidelines that can be downloaded from their
websites (http://www.nist.gov and http://www.nsa.gov, respectively).
Securely Building Remote Session Services
When building security into
Remote Desktop Services, keep in mind that you are giving users certain
levels of access to a shared resource. Essentially, users are logging
on to a system and using the applications and services installed on that
server or virtual machine. With this in mind, it is important to strike
a balance between a user’s productive capability and what the user can
do (intentionally or accidentally) to a system. Otherwise, a single
session can significantly affect other user sessions, as well as the
entire RD Session Host server or an individual shared virtual machine.
Additionally, administrators should also consider that depending on
their deployment strategy, users might be accessing Remote Desktop
Services from external systems. Therefore, a comprehensive approach
around end-to-end security (from the client to RD Session Host/virtual
machine) needs to be implemented.
Segmenting Resources
RD Session Host server
resources should be segmented in such a way that users can only modify
specific settings. This sounds simple, but requires careful planning.
For instance, partitioning the server’s disk subsystem can keep the
operating system, logs, applications, and profiles separated. Each of
these partitions should also be formatted with NTFS so that the proper
permissions can be applied. This also makes it easier for administrators
to manage and lock down specific resources.
The profile partition should
be given particular attention because of the nature of the content it
stores. For smaller installations, profiles can be stored on the local
server on a separate partition. For larger installations, temporary
profiles should be kept on a separate partition and folder redirection
should be used for data that needs to roam with a user. This not only
improves security, but it can also significantly improve performance.
Typically, these temporary
RDS profiles are stored under %SystemDrive%\Users\%Username%, even if
roaming profiles are used in the network environment. To change the
location to another partition, do the following:
1. | Create a Users folder on the partition.
|
2. | Modify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory Reg_Sz to the new location.
|
3. | Restart the server.
|
Securing Remote Desktop Services with GPOs
GPOs can and should be used to secure the Remote Desktop
Services environment. For instance, if an application or department
working with sensitive information uses Remote Desktop Services, the
Remote Control setting can be disabled to ensure that only authorized
users can
view these sessions. Group Policy can also be used to set disconnect
timeout values and allow reconnections from only the original client.
For more complex security requirements, Group Policy can also be used to
secure and customize a user’s session. For example:
GPO can be used to create a secure desktop that gives users limited Windows functionality based on their needs.
Or, if supported, a GPO can be used to customize and restrict individual application features.
Network Level Authentication
In RDP 6.0, a feature called
Network Level Authentication was introduced. This feature enhanced RDP
security by providing an interface for user authentication earlier in
the connection process of a session (before a Remote Desktop connection
and the logon screen appears). The following are the benefits of
configuring Remote Desktop Services to require Network Level
Authentication:
Fewer resources are used validating users before presenting them with a full session.
Remote computer authentication can be used to preauthenticate servers as well.
It can reduce the risk of a denial-of-service attack.
Changing the RDP Port
As mentioned earlier,
Remote Desktop Services securely communicates over TCP port 3389 using
RDP. Organizations requiring even greater security can change the
default port by modifying the following Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp\PortNumber
Or, if RemoteApp programs are being used, the RDP settings can be modified to specify a different port for RDP traffic.
Note
Only clients using RDP
version 5.1 or later can connect to the nonstandard port. Also, after
the port is changed, the RD Session Host server or RD Virtualization
Host server must be restarted.
