Understanding Terminal Server's Permissions Compatibility Options

brUnderstanding Terminal Server’s Permissions Compatibility Options When installing a terminal server, the very first configuration option is an important security decision. The person installing terminal server is given a choice about “permissions compatibility.

brUnderstanding Terminal Server’s Permissions Compatibility Options

When installing a terminal server, the very first configuration option is an important security decision. The person installing terminal server is given a choice about “permissions compatibility.” For Windows 2000, this decision is presented as “Permissions compatible with Windows 2000 Users” or “Permissions compatible with Terminal Server 4.0 Users.” Windows 2003 presents the choice as “Full Security” or “Relaxed Security.” This decision lays the foundation of the rest of your NTFS security strategy. It even has the potential to override your own NTFS settings, so understanding it is very important.

In this article, we’ll look at how this permission compatibility option actually works, and what you have to know to ensure that your servers will be as secure as possible while still letting your users run whatever programs they need to run.

Permission Compatibility Basics

Fundamentally, the permissions compatibility setting affects what NTFS and registry permissions users of your Terminal Server have. However, configuring this compatibility option either way does NOT change any actual permissions of files, folders, or registry entries.

Instead, the permissions compatibility setting affects what group SIDs are added to the user’s token when they logon.

The permissions compatibility setting is just a registry key. You can change it at any time as often as you want for a server via the Terminal Services Configuration MMC snap-in, and you can control it via Group Policy.

When a user logs on to a Terminal Server, the server checks the status of the permission compatibility registry key. If the server is operating in “restricted” mode (“Permissions Compatible with Windows 2000 Servers” for Windows 2000 servers or “full security” for Windows 2003 servers), the logon process continues as normal.

However, if the terminal server is operating in “relaxed” mode (“Permissions Compatible with Windows NT 4.0” for Windows 2000 or “relaxed security” for Windows 2003”) then the logon process adds a TSuserSID attribute to the user’s security token.

What does this mean, exactly? It basically has the effect of adding the user to a local “Terminal Server User” (TSUser) group for the duration of their session. The TSUser group has a lot of permissions that allow people in that group to do a lot of things on a terminal server. (In fact, the group’s permissions approach that of a power user!) Another way of looking at this is that by putting your terminal server into the “relaxed” security mode, your basically giving all your users “power user” rights on the box.

The Terminal Server User permissions are as follows:

Windows 2000 TSUser Permissions

%SystemDrive%\Program Files
Modify

%SystemRoot%\help
Read, Write and Execute

HKLM\Software
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Classes
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions    
Apply Onto:  This key and subkeys

HKLM\Software\Classes\.hlp
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Classes\helpfile
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

Windows 2003 TSUser Permissions

%SystemDrive%\Program Files
Modify

%SystemRoot%\help
Read, Write and Execute

HKLM\Software
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Microsoft\Tracing
Read
Apply Onto: This key and subkeys

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions
Apply Onto:  This key and subkeys

HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDLLs
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions 
Apply Onto:  This key and subkeys

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
Special: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, Delete, Read Permissions    
Apply Onto:  This key and subkeys

As you can see, these TSUser permissions are very powerful!

In addition to the TSUser SID assignment, Microsoft added some addition functionality to Windows 2003 when the server is configured for relaxed security.

The first is, to quote, “When a user starts a program that is non-Terminal Services-aware in a user context, the user receives an "access denied" error when the user attempts to open a restricted registry key. The reg-code attempts to open the same key again with the maximum permissions that the user can have (which is typically read-only) and returns that handle to the program. Most legacy programs open a key with write/create privileges, but they only perform read actions, so legacy programs still run correctly.”

The second is, to quote again, “When a non-Terminal Services-aware program, which is running in the user context, attempts to change or write a value under HKCR and HKLM\Software\Classes, the change is redirected to its own HKCU\Software\Classes; therefore, when necessary, a whole sub-branch is created under HKCU\Software\Classes.”

How does permission compatibility affect the server?

The first thing to remember is that as the administrator, by setting a server for relaxed security you’ve essentially given up a bit of control over what access you can give or take away from users. For example, if you wanted to only allow Read access to a folder under ‘Program Files,’ you would have to remove the TS User group and then assign permissions manually. The other option to override the TS User group is to apply the deny permission to a different group or user. Of course this defeats of the purpose of using relaxed security in the first place. (In this case you should just keep the server in the restricted security mode.)

The second thing to consider with relaxed security is that you’ve given ordinary users the ability to install and run unauthorized applications on your terminal server. This is never a good thing. An application not installed correctly on a terminal server can have unexpected results when running on the server—especially if other users try using it. Even worse, if the user installs a new application that’s packaged as an MSI, it will put the server (for Windows 2000) or session (for Windows 2003) into install mode. While in install mode, all users share the same .ini files and registry areas, and changes made to these areas and the HKCU area for the new application are recorded to the shadow key. This can cause numerous issues because users might suddenly lose their personal settings for applications the next time they log in. (Read this article for more information.)

The third thing to consider are those two bits of new functionality in Windows 2003 we mentioned previously. These are interesting changes that Microsoft has made. In effect, these changes try to do away with the need for application compatibility scripts. (Everyone remember those, right?) Unfortunately, this also makes it easier for users to install applications and have them work properly.

So if putting a server into relaxed security mode is bad, what can you do if an application you need will not run in the restricted / full security mode? The answer is to open the permissions only on the specific files, folders, or keys that are required for the application to function correctly. 

The tools typically used to do this are Regmon and Filemon from http://www.sysinternals.com. These tools are excellent for finding where permissions are being denied to users. They return a very large amount of information that can be difficult to sort through. The key to finding the “Access Denied” messages is to use the Filter/Highlight features of the tools. While you cannot use the filter on the results field, you can use the highlight feature on there. This makes it very simple to find those error messages:

The next step is to apply the appropriate permissions to the file system and registry. The typical response is to apply these changes directly. Unfortunately, this can be the cause of some problems. The first is if the changes have to be replicated to other servers. Manual changes can be the cause of many mistakes and the servers may not be built the same if done this way. The second problem is will you remember what changes were made a year from now?

A better way to set registry and NTFS permissions

There are a few different things you can do to set registry and NTFS permissions on Terminal Servers other than manually applying the changes.
 
The first way is to create a script to handle these changes. A simple batch file using cacls.exe or xcacls.exe can be created. One advantage to using a script is that it can be documented with comments as to what applications require the changes and other information as needed. This can be even more important when turnover happens in the admin ranks. These scripts can be called during installation of terminal servers. 

The second way is to use group policy to push these settings down to servers. The machine portion of group policy allows you to set permissions on the file system and registry from a centralized location. While the ability to document the changes is missing using this method, it does allow for several advantages. Changes to the permissions can be done after the fact and applied to all servers with minimal effort. There is less chance of these changes ‘being lost’ over time. For example, scripts have a tendency of becoming misplaced or forgotten as turnover happens within an organization.

Applications that are installed and work properly in Full Security mode also tend to open up permissions very broadly. Most applications will set folder permissions to full control for users even if there are no writeable files. You can use the process above to lock down these folders as well. Assign read only permissions to the application folder and then unlock what’s needed using Filemon.

Join the conversation

15 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

That web site is http://www.sbcgatekeeper.com
Cancel
My poor article.....
Cancel
I always choose Full Security for Windows Server 2003.
But this article makes me curious how tight that security really is.
In other words, for example how do the default permissions on %PROGRAMFILES%, HKLM\Software and other look like? Are they secure enough? And can the Terminal Server User group be deleted when not using Relaxed Security?

Sluvi.
Cancel
I think i would go with scripting instead of just relaxing security in the TS-settings, but i can definately imagine situations where relaxed might actually come in handy. But as you say Jeff, we can get a long way with scripting and file- and regmon :)

/Rene
Cancel
Okay, it's fixed now. This is what I get for editing it via a cell phone!

Although the problem was that I clicked "submit" before waiting for the page to fully load, so I re-submitted only part of the article... not really the phone's fault I guess.
Cancel
Lets have a vote is Brian a Dumb Ass with his phone :)?
Cancel
I always make my users domain admins, so if they have any issues i tell 'em to fix it themselves, because they are admins. Also I have preinstalled all known viruses, spypware and malware so that the users have wont have to be bothered to install the stuff...
Cancel
Hi,

When it's hard to spot what registry and/or file security must be released to get this application (s) running, it's an option to run this application in the Application Isolation Environment or maybe have the option to use Softricity SoftGrid.

This relaxed/full security point is a nice + point of application virtualisation/isolation.

With regards,
Ruben Spruijt
Cancel
Towards the bottom of page 3 you have a comment "read this article for more info" regarding users losing personal setting. Unfortunately you do not provide a link. I have tried looking at http://sbcgatekeeper.com but couldn't find anything there either.
Cancel
I have a 20 users that works on terminal server.
we work's with a isa server, there we adding the sites that the users can see.
 
in two days ago, sometihng append to the settings and all the 20 users can go to all sites they wants.
on the isaserver, in the internet option nothing worng in the proxy settings, so i thing maby somthing is happend to the settings in the group policy.
 
Is someone can help me?
thnks...
Tali   
Cancel
If the proxy is set properly for the users, then you've got a configuration issue with your web filtering on your ISA server.  Group Policy doesn't control what sites you get to (unless you're attempting to implement IE's crappy content advisor junk).

Shawn
Cancel
Hi
I have a windows 2003 server, very simple environment running published browser, however the customer requested we install an old image viewing application from Canon, "Canofile for Terminals" is the client side i try to deploy.
 
When i install this under Application mode it will not work correctly. If the server is toggled to remote admin mode it works fine. I have rebuilt the server and installed the app at pre and post toggling the terminal services mode and no difference. Its very easy to replicate the problem.
 
The bit that bothers me is when testing apps on terminal services/citrix the app usually works from the console and then bombs out for the regular user due to system files, app compatibility scripts.. etc. However this app won't even run correctly for the local admin.. so i can't put a finger on permissions!!
 
where do i start!! Anyone that could help, it would be much appreciated.
 
Ace
ascyabishara@hotmail.com
Cancel
Cancel
Hello, I will try to help you Can you post server configuration? :)
Cancel

 

Are these permissions applicable to AIE also? I have TS running in Full Security mode and had explicitly removed write/create permission to users on Program Files. Now i see that Citrix AIE...Program files also gets created as read-only. Is there a way i can get full control in AIE?

 This has become a show stopper for my environement where many applications need to have write permission for users on program files and all these applications are installed and published through Isolation Environment..

Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close