Introduction
When it comes to locking down your terminal service users there is never an easy approach. Many users feel bound when we as IT professionals limit their possibilities in the terminal services environment. The reason for locking down the environment is easily explained and through my work with server based computing environments I have also found that there is a limit to what we should and should not lock down. We can never forget that our main purpose is to provide the users with a set of tools to allow them to do their daily duties. In this article I will try to explain some of the options we have to create a locked down, consistent but still flexible approach to a user desktop.
I will not go into details with how to use group policies on terminal services as Patrick Rouse did a great article a couple of months back, you can read it here.
Group policies
Folder redirection
As we want to keep the local drives on the server hidden and restricted to the user, we have to redirect the user desktop. The consequence of not redirecting the desktop when restricting access to the local server drives will be that the users cannot save and open files placed on their desktop. Moving the desktop solves this:
The setting is found at [User configuration\Windows Settings\Folder Redirection\Desktop].
Editing the properties of desktop redirection
Configuring the desktop redirection to match the intended destination
Configuring redirection of My Documents is also a good idea to avoid user documents in the roaming profile; these would be lost if you would have to delete a user’s profile due to corruption, and user profiles are rarely backed up in the same way fileservers are.
The setting is found at [User configuration\Windows Settings\Folder Redirection\My Documents].
There are other options for redirection, Start Menu and Application Data but I will not touch these in this article.
But Folder redirection is a great tool, but should always be used with the purpose of making the experience better for the user, and never to just redirect folders as this also means more network traffic and in large organizations this can become an issue of debate in the IT Department.
Lockdown and settings
The lockdown of a terminal server is very much dependant on the requirements of the organization. It is hard to have a standard template which fits any type of organization, but I do find it valuable to have a lot of Group Policy tools in my toolbox. A lot of the different settings have been commented on by other authors and I will only touch these briefly. I will try to explain some of the group policy settings I apply to make the users feel more at home instead. For the basic terminal server lockdown best practice, please have a look at How to lock down terminal services. The great thing to keep in mind about these settings is that it is possible to use these together or spread in different policies applying to different user groups.
[Computer Configuration\Administrative Templates\Windows Components\Terminal Services]
Here I would like to talk about the option to ‘Set path for TS Roaming Profiles’. This option gives us a unique option to differentiate among servers. If you can imagine having more than one type of server, it might be beneficial to have different profiles for the different server types. This option overrides the option to set the path for terminal service profile on the User in Active Directory. This setting is also extremely useful in migration situations, where you want to move to a new version, but don’t want to risk affecting your production environment.
[User Configuration\Administrative Templates\Control Panel]
The options presented here are often debated as to what is best and what is most secure. I have had great experiences with the use of the control panel and instead of using the ‘Prohibit access to the control panel’, simply use the ‘Show only specified Control Panel applets’. This does not prevent access to the other control panel applets, but it only shows the objects listed. This way the users themselves can change the mouse/keyboard settings, the language settings and the exchange settings for their outlook client.
There are several lists on the Internet containing descriptions on which CPL’s to call for which features. Simply perform a search for ‘control panel cpl list’.
[User Configuration\Administrative Templates\Start menu and Taskbar]
This group of options is what makes the real difference in appearance for the users. I want to run through a few of these.
- Add Logoff to the Start Menu; This we want enabled as we will later remove the shutdown option.
- Force classic Start Menu; If your clients run windows 2000 or use classic start menu I would do the same on the terminal services.
- Remove and prevent access to the Shut Down command; This we want to enable for obvious reasons.
- Remove common program groups from Start Menu; This option removes the shortcuts and folders placed in the ‘All Users’ Start Menu. I enable this as I want to build my own Start Menu.
[User Configuration\Administrative Templates\Windows Components\Windows Explorer]
There are several important settings here; I will point out two:
- Hide these specified drives in My Computer; This option can hide local server drives from the user.
- Prevent access to drives from My Computer; This option prevents the user from accessing the local server drives, it does not prevent the user from starting his applications.
If you remap your server drives to something other than A, B, C and D you should have a look at tools like Hidecalc or make a custom .adm file. There is an example here.
[User Configuration\Windows Settings\Scripts\Logon]
This option allows us to run a script based on a user or group; I often use this to run personalization scripts for applications that cause problems and to build the users Start Menu.
Building your Start Menu in a simple and consistent way
When users connect to a remote desktop, whether it is terminal services, Citrix Presentation Server or another product they expect to use it like they would their PC at home. To that end I always want to build the Start Menu items from scratch when the user logs on. This way the user can benefit from their experiences from home and they are more likely to appreciate the server based environment. To do this I have often used scripting to build the Start Menu and found myself more than once spending too much time making wonderful VBScripts only to realize that when my colleagues, or the System Administrator on site, wants to change something they find it too complex.
To change this fact I took a different approach to the Start Menu, which consists of two parts.
An IconStore
To have a consistent set of icons/shortcuts for the Start Menu and Programs folder on the desktop, you can build the hierarchy in the IconStore. The files in the root of the store will be placed in the root of the ‘Programs’ folder in the Start Menu. The Folders in the root of the IconStore will be created in the root of the ‘Programs’ folder in the Start Menu and so on.
Having built the IconStore, we need to designate which users get which application shortcuts. This is easily done using NTFS Rights and normally I would recommend making a Usergroup in your active directory for each application or application group, named something like TS-Mediaplayer or similar. Then you can simply turn off the inherit permissions from parent directory under the advanced tap:
And after this you can add the usergroup with read permissions on the file.
These simple steps will have to be repeated for each file or folder and you are good to go.
A script to manage the users Start Menu
I make a simple commandline-script to perform simple actions at the userlogon. I place the script in a GPO under [User Configuration\Windows Settings\Scripts\Logon]. In the script I perform the following tasks:
1. Delete the Programs portion of the Start Menu of the users profile
2. Delete the Folder I create on the desktop.
3. Create the Programs folder, and the Icons folder I place on the desktop
4. I copy the icons the users have the appropriate NTFS rights for in the IconStore.
(in this example I use robocopy, you can find it in the RESKit for Server 2003, simply copy it to c:\windows\system32 or similar)
A simple script to perform the actions above.
Rd “%userprofile%\start menu\Programs” /S /Q Rd “\\PROFILESERVER\TSHomeFolder\%username%\Desktop\Programs” Md “%userprofile%\start menu\Programs” /S /Q Md “\\PROFILESERVER\TSHomeFolder\%username%\Desktop\Programs” Robocopy \\PROFILESERVER\IconStore “%userprofile%\start menu\Programs” /MIR /R:0 /W:0 robocopy \\PROFILESERVER\IconStore \\PROFILESERVER\TSHomeFolder\%username%\Desktop\Programs /MIR /R:0 /W:0 |
This will give you a desktop with a folder called Programs and a Start Menu consisting of the icons and folders with the right access permissions for the user in the IconStore.
Summary
The users working on the terminal servers that we provide expect us to deliver the tools they need to perform their duties every day. Using simple scripts and group policies, it is possible to make the environment close to a personal computer without having to sacrifice security in the process.
References
How to lock down terminal services
