Title Page Previous Next Contents | Terminal Services Security

Terminal Services Security

Now that we have a terminal server up and running and with applications installed on it, the next step is to learn how to make your terminal server more secure.

The term ‘secure’ in this context has several meanings; for example, it could mean securing the TS from hackers or locking it down so your own users do not access things they should not have access to.

Group Policies

I think the most important step to learn with terminal services is how to properly use Group Policies. Usually what we want to achieve is to apply certain restrictions to our users but only when they are connected to the TS servers and NOT when they are at their workstations. For example you do not want your users to see the terminal servers system drives (i.e. C:) or to be able to shutdown the server but if they are logged on to their PCs they should be able to see these drives and turn off their computers!

The way to do this is actually quite simple: all you need to have is a group policy but with a little setting enabled: the loopback processing mode. This will achieve exactly what we want. Users will get restricted when on the TS but not on their PCs. So let’s take a look at how to implement such policy. I assume you have the TS up and running and part of a domain – preferably Windows Server 2003 AD – and that you have rights to do what we will be discussing next.

Step-by-Step procedure:
  1. Logon to your domain controller and launch ‘Active Directory Users and Computers’. If you followed the steps described under ‘Active Directory Preparation’ at the beginning of this guide you should have an OU called ‘Terminal Servers’ with your TS computer objects.
TerminalServicesAtoZ41.jpg
Fig. 43
Active Directory Users and Computers, Terminal Servers OU
  1. You should also have the two groups we created way back at the beginning of this guide: ‘TS Users’ and ‘TS Servers’. Make sure these exist and that you have your users and servers into the respective groups.
  2. Right-click the ‘Terminal Servers’ OU and click ‘Properties’.
  3. Click on the ‘Group Policy’ tab and then click ‘New’. If you are using the Group Policy Management Console you will need to launch that tool and navigate to the ‘Terminal Servers’ OU and create a new policy there.
TerminalServicesAtoZ42.jpg
Fig. 44
Creating a new group policy
  1. Give your policy a name which is easy to remember like ‘TS Policy’ and then click ‘Properties’. Click on the ‘Security’ tab and there remove ‘Authenticated Users’. Also make sure that for ‘Domain Admins’ and ‘Enterprise Admins’ you click the ‘Deny’ checkbox for ‘Apply Group Policy’. Now add the groups ‘TS Users’ and ‘TS Servers’ and make sure the ‘Allow’ checkbox is checked for ‘Apply Group Policy’ for these two groups. Do not forget to click ‘Apply’!
TerminalServicesAtoZ43.jpg
Fig. 45
‘TS Policy’ policy. Note the groups and checkboxes settings
  1. Click ‘Ok’ to go back to the previous screen (where you see the policy name, ‘TS Policy’).
  2. Now we need to test if the policy is working. Click on ‘TS Policy’ and then click ‘Edit’.
  3. The ‘Group Policy Object Editor’ window will appear. Under ‘User Configuration’ | ‘Administrative Templates’ | ‘Start Menu and Taskbar’ find ‘Remove Run menu from Start Menu’ and double click it.
TerminalServicesAtoZ44.jpg
Fig. 46
Group Policy Object Editor – Remove Run from Start Menu
  1. Set it to ‘Enabled’ and click ‘Ok’.
TerminalServicesAtoZ45.jpg
Fig. 47
Enabling ‘Remove Run from Start Menu’
  1. Now the most important step: under ‘Computer Configuration’ | ‘Administrative Templates’ | ‘System’ | ‘Group Policy’, make sure you enable the ‘User Group Policy loopback processing mode’ and set it to replace.
TerminalServicesAtoZ46.jpg
Fig. 48
Enabling the loopback processing mode
  1. Close the ‘Group Policy Object Editor’ and the click then ‘Close’ button on the ‘Terminal Servers Properties’ window.

If you did everything right, we should be good to go. Reboot your TS and try to logon to it as a ‘TS Users’ group user. You should see a screen similar to this one, with no ‘Run’ option on the Start Menu!
TerminalServicesAtoZ47.jpg

Fig. 49
No ‘Run’ for this user
Now that our basic policy is working we can start our lockdown process. Again, this is one of the areas where people will have different settings based on their needs. I will set some of the basic ones I think are relevant and you just go from there!

Lockdown

Most of the lockdown settings in a TS environment will be performed on the Start Menu/Taskbar and as well on Windows Explorer. As already mentioned, the settings I use on this guide are simply a start point and you should add more settings if needed in your particular environment. I would just like to mention that you should always add more settings one-by-one so in case something goes wrong or shows some unexpected side-effects you know exactly how to fix the issue!

We will basically continue from where we left our group policy settings. Just launch ‘Active Directory Users and Computers’ or the ‘Group Policy Management Console’ and open the ‘TS Policy’.

The follow these steps to set some of the basic recommended settings:
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘Start Menu and Taskbar’ and set the following options:
  1. Remove links and access to Windows Update: Enabled
  2. Remove Favorites menu from Start Menu: Enabled
  3. Remove Search menu from Start Menu: Enabled
  4. Remove Help menu from Start Menu: Enabled
  5. Add Logoff to the Start Menu: Enabled
  6. Remove and prevent access to the Shut Down command: Enabled
  7. Remove access to the context menus for the taskbar: Enabled
  8. Force classic Start Menu: Enabled
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘Windows Components’ | ‘Windows Explorer’ and set the following options:
  1. Turn on Classic Shell: Enabled
  2. Hides the Manage item on the Windows Explorer context menu: Enabled
  3. Hide these specified drives in My Computer: Enabled; Restrict A, B, C and D drives only.
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘Control Panel’ and set the following options:
  1. Prohibit access to the Control Panel: Enabled
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘System’ and set the following options:
  1. Prevent access to the command prompt: Enabled; Disable the command prompt script processing also? No
  2. Prevent access to registry editing tools: Yes; Disable regedit from running silently? No
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘System’ | ‘Control+Alt+Del Options’ and set the following options:
  1. Remove Task Manager: Enabled
  2. Remove Lock Computer: Enabled

These are the basic recommended settings. I will not explain every single option here for one simple reason: when you are selecting these you will be able to read the explanation for every option available. And, one more time, these are the basic settings I recommend and depending on what you need you may have to set extra options!

Remember that Office applications have their own ADM templates that you can import directly in the ‘Group Policy Object Editor’ window; simply right click ‘Administrative Templates’ (under ‘Computer Configuration’ or ‘User click Configuration’ and select ‘Add/Remove Templates’. On the next screen simply click ‘Add...’ and browse for the .ADM files.

ι Note: for Microsoft Office, simply download the Microsoft Office Resource Kit for the version of Office you are using and install it on your terminal server. The template files (.ADM) will be installed as part of the resource kit.

Assuming you set all the options above, this is how your user desktop will look like when he connects to the TS.
TerminalServicesAtoZ48.jpg

Fig. 50
A locked down desktop

Note that all server drives (C:, D:, etc) are hidden and the Start Menu had many options removed from it!

Folder Redirection

As part of the lockdown process, one important and very useful step is ‘Folder Redirection’. The concept here is simple: once enabled, certain folders (i.e. Start Menu, Desktop, etc) are redirected to a network location for your users (by username, groups, etc). This is important for a couple reasons. For example users tend to save files to their desktop. When using a TS this may become a huge problem as by default such folder is part of the user profile and if you are using roaming profiles this means lots of data will be loaded every time the user logs on or logs off the TS which greatly increases logon times.

To preserve the user experience, look and feel, you probably want to give your users the same start menu, only showing the applications they have access to, regardless of the TS they are logged on. Start Menu redirection fixes this particular example.

So let’s learn the basics on how to do this by following these step-by-step instructions. In this example we will be redirecting the Start Menu and the Desktop for our ‘TS Users’ group.
  1. The first step is to create two folders on your file server and share them. I recommend you using a meaningful name. In my case I created ‘StartMenu’ and ‘Desktops’ and shared them as ‘StartMenu$’ and ‘Desktops$’. The permissions must be set as shown below.
  1. Desktops$ share: Domain Admins, Full Control; TS Users, Full Control.
  2. StartMenu$ share: Domain Admins, Full Control; TS Users, Read.
TerminalServicesAtoZ49.jpg
Fig. 51
StartMenu$ share
TerminalServicesAtoZ50.jpg
Fig. 52
Desktop$ share
  1. Now launch ‘Active Directory Users and Computers’ and go to the ‘Terminal Servers’ OU to open our ‘TS Users’ Group Policy. Navigate to ‘User Configuration’ | ‘Windows Settings’ | ‘Folder Redirection’.
TerminalServicesAtoZ51.jpg
Fig. 53
Folder Redirection
  1. Right Click ‘Start Menu’ and select ‘Properties’. On the ‘Target’ tab select ‘Advanced – Specify locations for various user groups’ and click ‘Add’. Click ‘Browse’ to select the ‘TS Users’ group and then enter the path to the StartMenu$ share as \\your_file_server\StartMenu$. Click ‘Ok’.
TerminalServicesAtoZ52.jpg
Fig. 54
Setting Group/Path for Start Menu redirection
  1. If you did everything properly you should see a similar screen to the one below.
TerminalServicesAtoZ53.jpg
Fig. 55
The Start Menu redirection path for our TS Users group
  1. Now repeat the same process for the ‘Desktop’.
TerminalServicesAtoZ54.jpg
Fig. 56
Setting Group/Path for Desktop redirection
  1. If you got it right, you should see something similar as below.
TerminalServicesAtoZ55.jpg
Fig. 57
The Desktop redirection path for our TS Users group
  1. Just close ‘Group Policy Object Editor’ and you are almost set! The last thing to do is to pre-populate the Start Menu folder with the contents you want AND to set a small setting on our ‘TS Policy’ policy.
  1. Logon to the TS with an Administrative account and right-click the ‘Start’ button. Select ‘Explore All Users’. You will see the local Start Menu on the TS that is shown by default to all users. Right-click the ‘Programs’ folder and select ‘Copy’.
TerminalServicesAtoZ56.jpg
Fig. 58
Copying the default ‘Programs’ folder
  1. Navigate to the ‘StartMenu$’ share and paste the contents there.
  1. Now simply navigate the ‘Programs’ folder you just pasted and remove the shortcuts/folders you do not want your users to see.
  1. Finally launch ‘Active Directory Users and Computers’ and open our ‘TS Policy’ policy.
  1. Navigate to ‘User Configuration’ | ‘Administrative Templates’ | ‘Start Menu and Taskbar’ and set the following policies:
  1. Remove user’s folders from the Start Menu: Enabled.
  2. Remove common program groups from Start Menu: Enabled.
TerminalServicesAtoZ57.jpg
Fig. 59
Touching up the ‘TS Policy’ policy
  1. Close ‘Group Policy Object Editor’ and reboot your TS or do a ‘gpupdate / force’ on it.

If everything was setup properly, when your users logon they will see a similar desktop to this!
TerminalServicesAtoZ58.jpg

Fig. 60
A locked down desktop with ‘Start Menu’ redirection

Additional lockdown

With everything we have showed you so far you now have a much better terminal services environment! But as with anything else, there is always ways to improve it. Let’s take a look at some of the additional steps you can take to further lock down your TSs.

SRP

SRP or ‘Software Restriction Policies’ is exactly what the name says: a policy to determine which applications (and types of applications) your users can and cannot launch. Although not perfect, SRP does increase the security on your TSs as users are now restricted to launch only the executables you authorize them to do! Several settings are available but it is not the intent of this guide to explain every single option available and the PROs and CONs on each one. There are already very good books/articles out there for this specific need.

But of course I will show you how to create a basic SRP for your TS. Feel free to expand it according to your needs!
  1. Launch ‘Active Directory Users and Computers’ and open our ‘TS Policy’.
  2. Navigate to ‘User Configuration’ | ‘Windows Settings’ | ‘Security Settings’ | ‘Software Restriction Policies’.
TerminalServicesAtoZ59.jpg
Fig. 61
Software Restriction Policies
  1. Right-click ‘Software Restriction Policies’ and select ‘New Software Restriction Policies’.
  2. In this example we will deny access to Notepad. To do this right-click ‘Additional Rules’ and select ‘New Path Rule...’. Now enter the path for Notepad.exe and type a description. By default this resource will be disallowed (exactly what we want). Click ‘Ok’.
TerminalServicesAtoZ60.jpg
Fig. 62
Creating a ‘New Path Rule’ restriction
  1. Your SRP screen should look like this:
TerminalServicesAtoZ61.jpg
Fig. 63
Your SRP settings
  1. Close ‘Group Policy Object Editor’ and reboot your TS or do a ‘gpupdate / force’ on it.

Now when your users try to launch Notepad they will see the following message:
TerminalServicesAtoZ62.jpg

Fig. 64
SRP at Work

As you can see SRP can be pretty effective if used properly. Now do your homework and expand all the SRP stuff you just learned here.

SecureRDP

One of the most debated topics when talking about Terminal Services is how to access it. Some people say you should never expose port TCP 3389 to the Internet (the port TS uses for RDP traffic; we are not talking about exposing the whole server to the outside but just a single port); others, myself included, are not that paranoid. And in my case, I am still to see a case where a TS, that was properly configured, was hacked through RDP. So I am ok with the idea of having RDP exposed on the Internet, as long as the steps we discussed so far are in fact implemented and you add some extra security layer to the picture.

This is exactly where SecureRDP comes in. This is a small utility that we wrote back in 2004, extremely simple, lightweight and powerful. What SecureRDP does is simple: all connections coming to your TS are filtered based on criteria you set (i.e. username, computer name, client version, etc) and if the incoming connection matches the criteria the connection is allowed. If not, users receive an error message (fully customizable) before they can even see the logon screen and the connection is dropped.
One of my favorite filters is the client version number. If you read the article I wrote and posted on MSTerminalServices.org (Customizing the RDP client) you will learn you can change the RDP client to have a unique client version number (4-digit) and of course on SecureRDP you can filter by that. So if you create your custom RDP client with the version number only you know and deploy it to your clients, when you filter by this number, only your customized RDP client will be able to connect to your TSs. Simple and effective; and the best part, free.

All the details about this, from patching the RDP client to creating a new MSI file for it and the SecureRDP configuration are available at MSTerminalServices.org.
Here you have the links:

http://www.msterminalservices.org/articles/Customizing-Microsoft-RDP-Client-Part1.html
http://www.msterminalservices.org/articles/Customizing-Microsoft-RDP-Client-Part2.html

External Access

Now that you have your environment up and running and properly locked down, how do you provide access to it from the outside? I could say this is actually very simple but as people have different requirements and concerns, for some this may become the hardest part of a TS implementation; for others, the easiest. Again, it all depends on how paranoid you are about security and your company policies/requirements.

All that is needed for TS to work (this includes everything users will need to do like printing, accessing their local drives, etc) is handled over port TCP 3389 (by default) by the RDP protocol. No other ports are needed or required.

As you can see the easiest way to provide external access to your clients is to simply configure your firewall to allow inbound connections on port TCP 3389 and redirect these to the TS internal IP address..
TerminalServicesAtoZ63.jpg

Fig. 65
External access to your TS – Port TCP 3389 only
ι Note: I know we discussed this before but I think it is worth mentioning it again: TSWEB is not RDP over HTTP or HTTPS. If you setup TSWEB as per the steps described previously you still need port TCP 3389 opened and redirected to your TS. With TSWEB, as you can see, you will end up having two ports opened: TCP 80 or TCP 443 (http/https) to your web server where TSWEB is installed AND TCP 3389 (RDP) to your TS. Again, TSWEB is simply a mechanism to easily provide access to the RDP client itself for users that may not have it installed on their Windows machines.

Of course you can add some complexity to the picture to make it more secure. One typical example is to have a VPN in place so users need to connect first to your VPN service and then to the TS itself or you can have a two factor authentication solution (i.e. RSA SecurID) that will require users to enter their credentials with a token based number (that changes every minute!) to get access to the corporate network and then access your TS.

All these extra steps will add complexity to the users and may require several additional steps. And of course, if not properly configured, will cause more harm than good.