Remotely accessing your servers and workstations through terminal services or RDP is an easy

method of doing your job from a remote location, or gaining access to specific published
applications that have been published on your servers. However, without properly investing in
securing these types of RDP connections, you could be compromising the security and integrity
of your servers, the data on them, and the services they're providing.

Can You Playback RDP, SSH and Citrix Sessions?

Do you really know what remote vendors and privileged users are doing on your servers?

ObserveIT acts like a security camera on your servers!

Record & replay every remote user action as if you are looking over their shoulders.

Supports all session protocols: RDP, Citrix, VMware, SSH and more.

Download ObserveIT Free!

Ever since I started working at ObserveIT (Remote Desktop RDP Session Auditor) - see my "My
new job - VP Technologies for ObserveIT – Enterprise Scale Window Session Recording" article
for some info on my new job - a company that provides IT and security managers to protect,
secure, record and audit RDP and other types of remote access, I have received many emails and
answered many forum posts regarding terminal server and RDP security. In this article I will
summarize some of the most common security considerations you should take into account when
designing your terminal server and RDP security.

Terminal Server usage scenarios

When planning for terminal server and RDP security we must take the terminal server usage
scenario into consideration. While some terminal server and RDP deployment scenarios are
created to allow full remote desktop capabilities, some allow full remote administration
capabilities, while others only allow access to a specific list of line of business applications.
Every scenario might pose additional security risks and thus require us to make additional
changes to our security design.

Terminal Server usage scenarios include:

  Publishing Users' Desktops – In this scenario, the Terminal Server is used to publish the users'
entire desktop, and bring all the desktop and application capabilities of the server to the remote
users. The users log on to the remote desktop through RDP, use applications that are installed
on the server, surf the Internet, and generally feel as though the desktop is their full personal
workspace. This remote connection can be accomplished by using an RDP client (also known as
an RDC client), or by using a thin client hardware. In this scenario you will need to purchase TS
CALs for each concurrent connection to the server.
 Publishing selected applications - In this scenario, the Terminal Server is used to publish a few
selected applications such as Microsoft Office, an ERP or CRM application, Internet Explorer
windows for "Internet sharing", and generally speaking – any application that you want to be
made available for the remote users. Users click on their published application shortcut (which
can be a desktop icon or an Internet shortcut, depending on the method used to publish the
applications). After logging on, users gain access to the published application and only to that
application. There is not full desktop capability, and when the application is closed, the session
ends. Here too, remote connections can be established by using RDP/RDC clients, or by using
thin client hardware. Here too, you will need to purchase TS CALs for each concurrent
connection to the server.
 Remote administration – Another scenario for using Terminal Server/Remote Desktop is for
remote administration purposes. In most cases, passing the RDP protocol (TCP port 3389)
through the corporate firewall is a lot easier than having to allow Microsoft Management
Console snap-ins (MMC) or other types of management tools that use RPC and other protocols
through the firewall. In this scenario, the remote administrator initiates the RDP/RDC
connection and gains access to the server's entire desktop, where they can use any locally
installed application to manage the server's services and functionality. Also, this scenario does
not require purchasing TS CALs, as the RDP connection is limited to only 1, 2 or 3 concurrent
connections (the number depends on the version or operating system you're running: Windows
2000 and Windows Server 2008 only allow 2 concurrent connections, while Windows Server
2003 has 3. Windows XP and Vista only allow 1 concurrent connection).

Security Guidelines

Here are some points that you need to take into consideration when designing your terminal
server security. Keep in mind that some are specific for published application usage, while others
are general and should be applied to all the usage scenarios. Read through these guidelines and
see which ones apply to your situation.

Note: These guidelines are listed in no particular order.

 Do not implement terminal services on a domain controller – This is one of the basics. Doing so
means that you will need to allow users the "Log on locally" user right. Also, doing so means that
in order to delegate management tasks for specific users on the TS servers, these users will
automatically become administrators for the entire domain's domain controllers, which is
obviously a wrong thing to do.
 Design a good Organization Units (OUs) structure in Active Directory for the computer objects
of the terminal servers – Using a good OU design makes it easier to link specific Group Policies
(GPOs) to these OUs and have them effect all servers within these OUs. This consideration is
 mostly beneficial when looking at the published applications usage scenario, where it's most
likely that you'll be using more than one TS which will be dedicated to running that role.

 Implement "Loopback Processing" on GPOs to control settings for users that are not in the
same OU as the terminal server computer objects – This is most important when you have
users from different OUs accessing terminal servers that are in another OU. When using this
configuration, because user accounts log on to the servers after the servers are booted, there
 may be inconsistencies between the terminal server-linked GPOs and the GPOs for the user
accounts. In this case, you can use the GPO loopback feature to apply Group Policy Objects that
depend only on which computer the user logs on to.
 Use Group Policies to control many terminal servers – Instead of separately configuring each
server, use GPOs that are linked to the OU where the server objects are located.

 If possible, publish a single application on each terminal server – While not always possible,
this will allow you to better fine tune for security (and performance) issues that are related to
specific applications.
 For specific published applications, consider pre-configuring the startup application – In order
to pre-configure exactly what application is started when the user logs on to the terminal server.
This setting is only useful in specific application publishing scenarios and NOT for remote
administration, but using it will increase security for the terminal server.
 Consider implementing IPSec between the client and the terminal server – If the protection of
the traffic between the clients and the terminal server is important, use IPSec to add an extra
layer or security and encryption to the traffic.
 Implement data encryption on the terminal server – For Terminal Services connections, data
encryption can protect your data by encrypting it on the communications link between the
client and the server. Encryption protects against the risk of unauthorized transmission
interception on the link between server and client. By default, Terminal Services connections are
encrypted at the highest level of security available (128-bit). However, some older versions of
the Terminal Services client do not support this high level of encryption. You can select the level
of encryption, with higher encryption offering better security, but adding extra CPU cycles to the
server.
 Use a mechanism to configure IP Address filtering on the terminal server – This will allow only
specific IP Addresses to connect to the terminal server. To do that, you can either use the built-
in Windows Firewall (depending on the version of Windows that you're using), or a 3rd-party
firewall that is installed on the servers. You can also use IPSec to implement blocking filters (In
Windows Server 2008 IPSec blocking filters is a part of the Windows Firewall with Advanced
Security).
 Properly configure your corporate firewall to only allow specific computers to connect to the
terminal server – Needless to say, properly configuring your corporate firewall to block all
unnecessary traffic to and from the terminal server is one of the first steps you should take to
protect it. While your mileage may vary, it's worth noting that RDP communication uses TCP
port 3389, and all firewalls, routers and NAT devices between the remote clients and the
terminal servers should be configured to properly allow (or block) traffic based upon your
design.
 Unless required for published applications, require user credentials when logging on – The
logon process can be made easier by storing the user credentials on the client's computer as
part of the RDP/RDC program. However, this means that anyone that double-clicks on the
RDP/RDC shortcut will be automatically logged on to the terminal server. While useful in some
cases (such as kiosk environments where casual users do not have a user name and password
they can type in), it will lower your security level.
 Restrict RPC management access to the terminal server by requiring security – For
management purposes, restrict RPC access to the TS. This is done through either a GPO linked to
the OU where the TS computer accounts are located, or by using local policies.
 Consider limiting the active user session length – While not strictly security-related, this can
add some security to a terminal server session. Be careful not to limit the active session to a
time that is shorter than what your users need to perform their job.
 Limit the idle session and disconnected session time – Idle sessions should not be left open for
ever, and they should be automatically terminated after 15 or 30 minutes. Disconnected
sessions, on the other hand, are harder to control because of the possibility that a user's
connection has terminated due to network issues, and killing that session will result in lost un-
saved data on the user's session. I use 3 hours for application or desktop sharing, and 24 hours
for remote administration scenarios.
 Disconnect from session – Should be enabled, in order to put a user's session into "disconnect"
state when a session limit is reached.

 Restrict reconnections of a disconnected session to the client computer from which the user
originally connected – This makes it easier to prevent session hijacking, but might prove a bit of
an annoyance if clients lose Internet connectivity temporarily, and when they come back online
they get a different IP address than the one used in the disconnected session.
 Restrict the number of client sessions that can remain active on the server – This makes it
easier to keep track of who is connected.
 Override user settings in the terminal server Configuration console – This will allow the
administrator to centrally configure user session settings from one place, and not need to
configure these settings on each user's user account properties.
 Do not enable remote control on users' sessions – Terminal server allows you to "shadow" or
view users' sessions when logged on to the server via RDP/RDC. While useful for training and
help desk scenarios, this also means that administrators can view users' sessions, possibly
exposing themselves to private and confidential information.
 Use granular permissions to control who can connect to the terminal server – Typically, default
settings are adequate for regular TS deployments, however in order to increase security you
should consider manually changing the scope of users and groups that are allowed to log on to
the TS, and what they can do. For example, who can reset a connection, who can remote control
another session, and who can send messages to other concurrent sessions.
 Limit users who can log on remotely - Only allow certain users remote desktop access, even
when using RDP on a regular workstation. Make sure that you only allow the users who you
want to be able to log in remotely.
 Possibly prevent administrators from logging on through RDP – In some cases, when remote
users only need to run specific applications, you might want to configure the local policy of the
server/workstation to prevent administrators from logging on through RDP/RDC.
 Consider limiting the applications that a user can access on the terminal server – Especially
useful for full desktop access, you can use Group Policy to limit the list of applications that can
be opened by a user on the terminal server. Also consider preventing access to some of the
command-line tools found in the %systemroot%'system32 folder – applications such as
subst.exe, xcacls.exe, xcopy.exe, cmd.exe, format.exe, regini.exe, reg.exe and similar.
 Set an account lockout policy - There are tools that will use brute-force to guess passwords and
log-on remotely. You cannot totally stop this, but you can minimized it by setting an account
lockout policy. If someone tries to guess the password, then after a few guesses they will be
locked out for a period of time.

 Change the TCP Port for the terminal server listening port - You can change the terminal
services port from 3389 to another port by changing a registry key. Please see my "Change
Terminal Server Listening Port" article.
 Consider implementing a secure remote access infrastructure by using VPN to protect the
transmitted data and prevent Man In The Middle attacks – Regular RDP connection provides
encryption for the data that is sent between the terminal server and the client computer.
However, this kind of connection does not provide authentication for the terminal server. In
order to mitigate some of the security issues, you should consider implementing a VPN tunnel
between the clients and the terminal server. See my "Record Secure Remote Access SSL VPN
Gateway Sessions" article for more information.
 Consider enabling Transport Layer Security (TLS) to authenticate the terminal server and to
encrypt the data – As noted in the above item, regular RDP connection does not provide
authentication for the terminal server. Instead of using a VPN tunnel, you may want to make
sure that your terminal server is correctly authenticated before you connect to it. Furthermore,
you cannot verify the identity of the terminal server you're connecting to. By using Windows
Server 2003 Service Pack 1 or higher together with Transport Layer Security (TLS) you can
increase terminal server security.
  When using Windows Server 2008 Terminal Server, consider using TS Gateway - Using the new
capabilities of Microsoft Windows Server 2008 TS Gateway provides further protection of RDP
traffic by encapsulating it into SSL packets – much like SSL VPN, but without the need to deploy
special VPN servers. The benefit of using the TS Gateway capabilities of Microsoft Windows
Server 2008 is that remote users will only be granted access to the internal servers based upon a
strict policy that can be enforced on the TS Gateway, and when combined with the NAP
capabilities of the system, will only allow connection of computers that fully meet the security
requirements set by the administrator.
 Monitor Log Files - The Event Viewer logs failed login attempts and account lockouts. Monitor
the event log for such events.

Conclusion

Without properly securing terminal server connections you could compromise the security and
integrity of your servers, the data on them, and the services they're providing. By following the
above guidelines you will be able to protect your data and applications.