Mike,

If you create an account in the domain which your workstations are a
part of and only make it a member of the 'administrators' group (not
enterprise or domain admins), this user should have access as local
administrator only - but to *all* machines (ie. they have access as a
local admin to your domain controllers and servers).

What you'll need to do in order to give people access solely
workstations, therefore, is to specifically create a group *just* for
local administrators of workstations. This method (rather than simply
adding users to administrators for the entire domain) is far more
powerful, and much less clumsy - allowing you to, for instance, revoke
the privileges of the whole group in order to remove the policy with one
alteration, instead of having to remove every user from the
administrators group in a hurry.

In order to accomplish this, you would need to do the following:

i) Create an OU for your workstations and stick them in it (eg. the
Workstations OU)
[NOTE: you could also apply the following to an existing OU or multiple
existing OUs.]

i) Create a group for your workstation admins (eg. stationadmins)

ii) Create a new group policy (right click on Workstations OU,
Properties, group Policy, New) with a name which makes sense (eg.
stationadminpolicy).

iii) Click on 'Edit' for your new group policy. Navigate to the
'Computer Configuration'>'Windows Settings'>'Restricted Groups'

The Restricted groups policy allows you to restrict or allow different
groups of users to be members of different groups; create a new group
called 'administrators'. In the properties (Configure membership) window
for this policy, the top box (Members of this group) defines who is a
member of the restricted group (which is called administrators) which
you have created. In this box, add your new group (stationadmin), and
any other groups on the domain who you want to be a member of the local
administrators group (domain\domain administrators, domain\enterprise
administrators, domain\administrators).

IMPORTANT: If you set this policy for an OU *WITHOUT* adding the other
groups on the domain which you want to be members of the local
administrators group, then the 'other groups' (such as enterprise
administrators) will *NOT* be members of the local administrators group,
as the Restricted Group policy will override the windows default. For
this reason, I recommend that you test this thoroughly first on a test
OU!

This defines your policy to your group (stationadmins) rather than to
individual users, which is 'best practice' for Group Policy.

Hope this helps! Let me know if you have any queries about this or have
any other queries!

- James.

On Mon, 2005-02-07 at 21:46 -0800, Mike Groh wrote:
> The workstation admin idea sounds good to me. I want to do it in my
> network. Is there a way to easily push this policy to the workstations.
> Win2k3 server (AD) and XP workstations? I'm assuming it would involve
> GPO but I have very little experience with it.
>
> Thank You,
>
> -Mike
>
>
> d.pigna (at) email (dot) it [email concealed] wrote:
>
> > Hi Boris
> >
> > What about something like:
> >
> > 1) Create a WorkstationAdmin who has admin privileges on workstations
> > (local admin), and NOT on servers, active directory, network folders,
> > etc...
> > This will ensure, if the password is compromised, that only your
> > workstations will be at risk.
> >
> > 2) If you have several OUs and several Local
> > Administrators/Supervisors, create different WorkstationAdmins.
> > Again: the lowest number of machines compromised in case someone will
> > get this password.
> >
> > 3) Change this password(s) EVERY DAY. Or every hour.
> >
> >
> > A question from my side, now.
> >
> > How many times these operations are performed every day???
> >
> > Everyday operations have to be easy and fast. In this case, I suggest
> > you to give your Supervisors a wide range of "freedom".
> > Otherwise you'll get a call everytime a normal maintenance operation
> > is performed on a remote, lonely and unuseful machine (something you
> > don't want to happen).
> > It's better to have 5 workstations compromised every year - that need
> > to be reinstalled - than 50 calls every day.
> >
> > How many workstations/LocalAdmins do you have???
> >
> > Is there a REAL security risk in your environment? Who can be really
> > dangerous for you? If you're at risk, and you have to protect sensible
> > information, you'll need to give up on usability, and go for the
> > security (i.e. change LocalAdmins passwords everyday).
> > If you don't have something really important to protect... c'mon, just
> > make LocalAdmin life easy.
> >
> > If you're managing 10.000 machines in a high school, what data are you
> > trying to protect on every single workstation? PPT files for the art
> > teacher and some stupid videos downloaded from students?? ;-)
> > Let them play, and mess up!
> >
> >
> > It could be nice to have a final report on this question...
> > Something that will put together all these suggestions and try to line
> > out a security model (from very weak to very strong) for different
> > security needs.
> >
> > Hope this helped.
> > Davide
> >
> >
> >
> > Boris Skoblo wrote:
> >
> >>
> >>>> Hi All,
> >>>>
> >>>> There is a usual situation: on normal users computers ( W2k and
> >>>> Winxp ) an administrator should perform an administrative actions
> >>>> (for example, with help RunAs) thus the administrative password is
> >>>> entered. Do exist a potential possibility that on the user's computer
> >>>> there is keylogger.
> >>>>
> >>>>
> >>>> What ways to perform administrative operations exist, thus not
> >>>> endangering disclosure the administrative password? There are some
> >>>> limitations:
> >>>>
> >>>> 1. usage of smarts-cards and others hardvare devices are not
> >>>> applicable .
> >>>>
> >>>> 2. performed operations cannot be delegated for various reasons
> >>>>
> >>>> 3. keylogger is custom designed and any of existing protective
> >>>> software yet does not find out it
> >>>>
> >>>> ------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------
> >>>
> >>>
> >
> >
> >
> > ------------------------------------------------------------------------
---
> >
> > ------------------------------------------------------------------------
---
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------
---
> ------------------------------------------------------------------------
---
>

------------------------------------------------------------------------
---
------------------------------------------------------------------------
---

[ reply ]