[THIN] Re: GPO Question

  • From: "TSguy92 Lan" <tsguy92@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Wed, 26 Dec 2007 08:59:03 -0800

From what I've read of your question. You want to enforce some restrictive
computer level policy settings on all your end users and have that setting
not affect your administrators when they login to those machines.

Actually, to a very limited degree you can do this...MS has some KB's on how
to do this with servers in a workgroup.

Check out:

http://support.microsoft.com/default.aspx?scid=kb;en-us;325351 = Q325351 –
how to apply local policies to all users except for administrators on
Windows 2003 servers in a workgroup.

http://support.microsoft.com/default.aspx?scid=kb;en-us;293655 = Q293655 –
"……………………………………………………………………………" Windows 2000 servers in a workgroup.

Having run into a similar issue in the past myself, I found the above
articles, and ended up using my own methodology (listed below) to setup a
machine level policy on a server that affected users only, and not
administrators. One thing to keep in mind with this alternative setup is
that these settings are being done via "Gpedit.msc" the local group policy
editor on each server. These settings can't be defined and manipulated for
multiple systems at an OU level, they should be done Per machine.

I cannot stress enough however, that it's very easy to lock yourself
"admins" out of a system if you make a mistake with these changes. I'd
highly suggest testing this out with non-production systems first, and if
you're comfortable with the process, then move up to enforcing these
settings to your live systems.

1.       As an admin account login to the machine you want to lock down.

2.       go to 'start' – 'run' – and type 'gpedit.msc' – press enter.

3.       configure all the computer level restrictions you want.

       a.       Note as soon as you close this window your session (if on a
windows 2003 server) will have applied all the restrictions you've setup.

4.       Log off from the console of the machine.

5.       Login to *a different machine in the domain *as an admin account.

6.       go to 'start' – 'run' and type \\machinename\c$<file://machinename/c$>
 (in order to remotely get to the C: drive of the machine you just used
gpedit.msc on)

7.       Once connected to the remote systems' c:, browse to C:\windows (
winnt for win2k)\system32, and find the "hidden" folder called "GroupPolicy"

8.       check the NTFS permissions on this folder, and set a "*deny*"
permission for administrators, in "*reading*" this folder.

      a.       *Do not make any permissions changes to 'system', or
'authenticated users'.*

      b.   Do not add in groups / users to this permissions area.

      c.   Do not remove any groups / users from this permissions area.

9.       Login to the restricted machine as an administrative account to
verify the restrictions are not affecting the admin session.

      a.       In some cases, it is necessary to delete and recreate the
admins local profile on the locked down machine to clean up restrictions
which may have been applied in step 3a.

This setup has some benefits and some negatives attached. This can be very
useful in setting up group policy like restrictions for 'roaming laptops' or
for machines that aren't part of a domain. However, administration on the
policies takes some work, as you have to reverse steps 7 through 9 and grant
the Admins permissions to the 'group policy' folder again, to be able to
edit the policy if needed.

Be careful with this setup and try out just a few restrictions first so you
can see what steps will have to be used to allow admins back in to modify
the system.
HTH

Lan


On Dec 22, 2007 8:29 AM, Jon Luchette <jon.e.luchette@xxxxxxxxx> wrote:

> ok thanks!  so I cannot have different machine policies for different
> groups of users?
>
> On 12/22/07, Greg Reese <gareese@xxxxxxxxx> wrote:
> > computer settings will apply for everyone, user settings will apply to
> each
> > group.
> >
> > I usually setup mine similar. it works pretty well.  For the sake of
> staying
> > organized, I try to keep all the machine policies in a single place.
> >
> > also, don't mess with domain admins when setting permissions on these.
>  Make
> > a separate group.  I have locked myself out of things many times by
> screwing
> > up the permissions on a gpo and the domain admins group.
> >
> >
> > On 12/21/07, Jon Luchette <jon.e.luchette@xxxxxxxxx> wrote:
> > >
> > > I have one group of 3 citrix servers.  I have created a separate OU
> > > for citrix servers and moved all 3 computer accounts into it. what I
> > > want to do is enforce two policies at this level. one for admins and
> > > one for non admins.if I create  one policy for admins and set the read
> > > and apply group policy permission for their geoup in AD, and do the
> > > same for the non admins with another policy, will both groups apply
> > > their own user and computer settings or will just their user settings
> > > be unique?
> > >
> > > On 12/21/07, Greg Reese <gareese@xxxxxxxxx> wrote:
> > > > seperate the machines by OU and only link the policies you want
> applied
> > > to
> > > > OU you want them applied to.
> > > >
> > > >
> > > >
> > > >
> > > > On 12/21/07, Jon Luchette <jon.e.luchette@xxxxxxxxx> wrote:
> > > > >
> > > > > I want to enable different computer configuration settings for
> > > different
> > > > > groups of users in AD on some 2003 terminal servers.  Is that
> > > possible?
> > > > > How?  I know about loopback and everything, but that is mostly
> > > controlling
> > > > > how the user level GPOs are applied...
> > > >
> > > ************************************************
> > > For Archives, RSS, to Unsubscribe, Subscribe or
> > > set Digest or Vacation mode use the below link:
> > > //www.freelists.org/list/thin
> > > ************************************************
> > >
> >
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> //www.freelists.org/list/thin
> ************************************************
>

Other related posts: