by
Jeff Pitsch
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.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.