TS 2003 Restrict application usage by group

[musicman]

Hi All,

I have a W2K3 TS that is accessed by multiple groups of users. Lets
call them sales, engineering and operations. There are multiple apps
installed on the server that I need to restrict by group so that sales
cannot access engineerings apps, engineering cannot access operations
apps and so on...

Let's also assume for the sake of argument that there are apps that all
three groups will need access to (MS Office suite) in addition to their
group specific apps. Administrators will of course need access to all
apps.

Can anyone give me a step by step method of performing the above?

Thanks so much

Ryan Tracy

 

[Vera Noest [MVP]]

There are numerous 3rd party add-ons which can do this in a fancy
fashion. I would recommend such an add-on if you have a large
number of different user group and/or your set of applications
changes often.

If you want to do this with native Windows techniques, this is one
way to achieve it:

* enforce the actual restriction by means of NTFS permissions on
the executables of the applications or the folders which contains
the apps.
* use Group Policies with "Folder redirection" to redirect users to
a custom desktop folder. Here you can choose 2 different routes,
depending on how perfectionistic you are:
a) create a separate custom desktop for each user group. Those
custom desktop folders will contain shortcuts to all the common
applications + shortcuts to the group-specific applications (which
aare differemt for each group). Use different GPOs for each user
group to redirect them to the appropriate desktop folder.
b) create a single custom desktop folder, which contains shortcuts
to all common applications + a subfolder for each group. The
subfolders contain the group-specific shortcuts. Use NTFS
permissions on the subfolders to give users access to only their
subfolder.

Advantage of method a):
* users see only their own application
Disadvantage of method a):
* if something changes in the common applications, you have to
modify each separate custom desktop folder
* multiple GPOs needed

Advantage of method b):
* if something changes in the common applications, you only need to
modify one custom desktop folder
* a single GPO will do
Disadvantage of method b):
* users see all subfolders and get an "access denied" error when
they try to open a subfolder which does not belong to their group

To avoid any restrictions for Administrators: give them the "Deny"
right" for "Apply this GPO" in the security filtering of all GPOs.
816100 - How To Prevent Domain Group Policies from Applying to
Administrator Accounts and Selected Users in Windows Server 2003
http://support.microsoft.com/?kbid=816100

Folder redirection is located here in the GPeditor:
User Configuration - Windows Settings - Folder Redirection
"Desktop"

Since this is a user setting, you will want to use "loopback
processing" with the "Replace" option" in all of your GPOs as well.
260370 - How to Apply Group Policy Objects to Terminal Services
Servers
http://support.microsoft.com/?kbid=260370
231287 - Loopback Processing of Group Policy
http://support.microsoft.com/?kbid=231287
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[musicman]

Vera,
Thanks for the response, I am now deciding whether to use your method,
or to define custom software restriction policies by gpo assigned to
individual groups. I must confess that your method looks considerably
less involved.

Questions on enabling loopback processing.

1. If there are no gpos linked to the terminal svcs OU that my TS
servers are installed in, and the default domain gpo contains no user
or computer settings - all are done at user or computer OU levels. Is
loopback processing still necessary, or wouldn't blocking inheritance
of any higher-level gpo's do the trick?

2. Must loopback processing be enabled because of user settings that
may be applied from the OU that contains the user object?

3. Do settings linked to the OU that contains the user's computer
object apply to the terminal services session, or are they only
applicable to login on the local workstation?

 

[Vera Noest [MVP]]

comment inline

Vera,
Thanks for the response, I am now deciding whether to use your
method, or to define custom software restriction policies by gpo
assigned to individual groups. I must confess that your method
looks considerably less involved.

It's really not a "one method versus the other" question. Software
restriction is a very elegant and powerful method to enforce
restrictions on what users are allowed to run, but it doesn't take
care of the customized desktop part.

Questions on enabling loopback processing.

1. If there are no gpos linked to the terminal svcs OU that my
TS servers are installed in, and the default domain gpo contains
no user or computer settings - all are done at user or computer
OU levels. Is loopback processing still necessary, or wouldn't
blocking inheritance of any higher-level gpo's do the trick?

The point is that you want the custom desktops only when users
logon to the TS, not when they logon to their workstation, correct?
If so, then you *must* link the GPOs with the redirected desktops
to the OU which contains the Terminal Server. And then you must use
loppback processing.

2. Must loopback processing be enabled because of user settings
that may be applied from the OU that contains the user object?

Loopback processing is needed when you want to use certain user
settings when users log on to a certain computer (i.e. a TS),
irrespective of where the user account is located and which GPOs
are linked to the OU which contains the user accounts.

3. Do settings linked to the OU that contains the user's
computer object apply to the terminal services session, or are
they only applicable to login on the local workstation?

This is explain in the MS article 231287, but I'll try to reword
it:
under normal conditions, when users logon they are affected by
a) the computer settings from the GPO which is linked to the OU
which contains their computer account (either workstation or TS)
b) the user settings from the GPO which is linked to the OU that
contains the user account (irrespective of the computer they logon
to)

So if you enforce restrictions in the user settings of a GPO linked
to the user account OU, it will restrict them always, everywhere
(both workststation and TS logon). That is normally not what you
want to achieve. And that's why you want to use loopback processing
in the GPOs linke to the TS OU.

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[musicman]

Wow,
Thanks for holding my hand here. I have several more questions if you
have the time.

It's really not a "one method versus the other" question. Software
restriction is a very elegant and powerful method to enforce
restrictions on what users are allowed to run, but it doesn't take
care of the customized desktop part.

In this case couldn't you just create a local user, log in as that
user, customize a desktop environment with all changes desired
(subfolders, ntfs rights etc...) and copy it to the default user
desktop folder. I am wondering if creating GPOs for desktop redirection
is more work than is necessary?

The point is that you want the custom desktops only when users
logon to the TS, not when they logon to their workstation, correct?
If so, then you *must* link the GPOs with the redirected desktops
to the OU which contains the Terminal Server. And then you must use
loppback processing.

Still confused here. If the user and computer objects are located in
separate OUs than the TS OU, then I am at a loss as to why a GPO with
folder redirection that's only applied to the TS OU would affect users
at any other time than when they log into the TS. Thus why is loopback
processing necessary on the TS GPO?

Loopback processing is needed when you want to use certain user
settings when users log on to a certain computer (i.e. a TS),
irrespective of where the user account is located and which GPOs
are linked to the OU which contains the user accounts.

Again, if there is a GPO applied to the TS OU, wouldn't it by default,
process changes as the user logs into a TS session? Is there a need for
loopback processing to be enabled if you have no user settings from
another GPO linked at another OU being applied?

This is explain in the MS article 231287, but I'll try to reword
it:
under normal conditions, when users logon they are affected by
a) the computer settings from the GPO which is linked to the OU
which contains their computer account (either workstation or TS)
b) the user settings from the GPO which is linked to the OU that
contains the user account (irrespective of the computer they logon
to)

So if you enforce restrictions in the user settings of a GPO linked
to the user account OU, it will restrict them always, everywhere
(both workststation and TS logon). That is normally not what you
want to achieve. And that's why you want to use loopback processing
in the GPOs linke to the TS OU.

I guess that this is what I'm getting to. If there are restrictions
applied via GPO at user and computer OUs, and another set of more
restrictive user and/or computer settings applied via GPO at the TS OU,
won't the most restrictive version of the changes be applied?

Please forgive the lengthy dialogue, I have done a lot of reading on
loopback processing, and am still unclear as to why it's necessary if
your gpos are applied at different OUS.
Thanks,
Ryan

 

[Vera Noest [MVP]]

Folder redirection is a User Configuration. If defined in a GPO
which is linked to the TS OU, folders will *never* be redirected,
unless you use loopback processing.

And about your Default user profile approach: I thought that you
wanted to enforce different application restrictions for different
user groups? You can have only one Default User profile. It
wouldn't enforce anything either.

Ryan, I think that more explaining and reading isn't going to help
you. Create some OUs and GPOs, and see for yourself what happens.
That's often the moment when you suddenly see the light

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[musicman]

Vera,
That's eactly what I did last night. I wasn't understanding that
loopback processing allows for replacing user settings that may be in
affect for other OUs.

As for the default user prfile, I was talking about having one,
creating subfolders on the desktop, and only putting the shortcuts to
each groups applications in the subflders, which would then be locked
down using ntfs permissions.

Thanks,
Ryan

 

[Vera Noest [MVP]]

inline

Vera,
That's eactly what I did last night. I wasn't understanding that
loopback processing allows for replacing user settings that may
be in affect for other OUs.

Yes, I thought you would. It has happended to me often that I only
fully understood a new technique when I implemented it myself. One
real-life test says more than a thousand words...

As for the default user prfile, I was talking about having one,
creating subfolders on the desktop, and only putting the
shortcuts to each groups applications in the subflders, which
would then be locked down using ntfs permissions.

The Default User profile would only give new users a starting point
for their own personal profile. And they would all have their
personal copy of it, which you can't lock down (other than by making
the profile mandatory).
If you would later want to change a shortcut, you would have to write
a script which changes the shortcuts in every single user profile.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___