Its often difficult to decide on a policy for locking down
your workstations, especially in a small- to medium-size enterprise. Its nice
to allow users some freedom to personalise their computers–install tickers and
screensavers, etc; however, there comes a point where an inordinate amount of
time is spent repairing and rebuilding machines due to users fiddling with
things that they dont understand or solving software conflicts caused by
random applications, games, and malware. The only way to stop this regular
rebuild cycle is to lock down what users can do on their machines and create
standard builds including only the software required by users to meet their
business objectives.
Most people working within a large enterprise environment
would be shocked at the suggestion that the average users would have anything
but the most basic rights, but this is pretty normal for smaller companies
which tend to follow more user-friendly standards. Microsoft allows a majority
of its employees full local admin rights, although this may
change with the rollout of Windows Vista, for security reasons.
So, locking down Windows workstations within a Windows
domain isnt too tricky; group policies can be distributed, software deployed
and user group permissions defined. However, it can seem a lot more daunting to
set restrictive policies on workstations that are not operating in a Windows
domain environment.
So what are our basic tools for controlling what a user can
and cant do?
Account Permissions:
One way of limiting what users can and cant do is to set
them up on the workstation with a limited account. This is a very simple
process, when a user is created via control panel; there is a choice of making
the user an Administrator (they can do anything on the machine) or a Limited
user. Limited users are very restricted; they cannot install software or hardware,
make system-wide changes, or access files of other users on the computer. One
issue you could encounter as a limited user is that some legacy (i.e.,
non-WinXP-approved) applications may not run correctly. Some users could be
added to the Power User group–which has more rights–however, these problems
can still occur. You may also find that setting up users with limited accounts
will stop them from installing random applications, but it doesnt stop them
from messing around with other settings in their own account. This is where our
second tool comes in.
Group Policy Editor:
The Group Policy Editor can easily be accessed by typing gpedit.msc
in your Run dialog on the Start menu. You will see straight away that the
layout is presented in a Windows Explorer styleif you descend through the
menus youll find the Administrative Templates under User Configuration. In
this section, you can dictate a huge range of system permissions for the
current user. You can remove various options from the system, including access
to the Control Panel and Run dialog. This is a very powerful tool, even when
not combined with a Windows domain and the associated benefits. It will take
some time to fine-tune policies and find the right balance for your
organisation.
Im still looking for a definitive answer as to how one
would create a master policy on one workstation, limiting a single user in
various ways (but leaving the administrator free to do anything and everything)
and then transferring this policy to other workstations in order to create a
standard build of permissions (without having to define each part of the policy
on every machine). I have also found that if using a Limited User account, one
does not have permissions to run the gpedit.msc tool, therefore Group Policy
would need to be created as the administrator, and applied to the computer
rather than current user, which in turn limits the administrator. So far I
havent found a satisfactory way to limit a local user with the Group Policy
editor, while leaving the local administrator user unrestricted. Has anyone had
experience with achieving this task? If so please leave some clues in the
comments for this blog 🙂