Re: Must all users be administrators?

From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 05/21/04 

Date: Fri, 21 May 2004 11:55:08 -0500

The theory of AD policy management and delegation is full of complex
details, but at the heart, it's pretty simple concepts.

The familiar look of the AD objects tree you see in Group Policy Editor is
based upon the top of the tree being the highest level domain in the Forest,
if you even have multiple domains. For simplicity, let's assume this is an
SBS with single domain. :)

At the top of your domain tree is your "Domain Object", and policies as well
as delegation can be applied.

Suppose you create a series of tree levels below some root level OU right on
the first level below the domain object. In fact, this is what SBS 2003
provideds by default. It's that OU called MyBusiness. Only thing is that MS
has chosen not to further branch it.

The logic is that everything lower in the branch is subject to be managed
and overruled at a higher level. Conceptually, the idea is that you can
delegate both aspects of lower level things: features and management of
features.

This seems modestly confusing to an SBS Administrator because there's very
little concept of delegation involved at this level of technology
implementation. However, imagine a larger company that has senior IT staff
for the Enterprise, Site specific IT staff, and Department Level IT
responsibilities that are "delegated". This means that the lower parts of
the branch would be OUs that the highest level IT managers provide
"management by delegation" rights given to the IT staff with more close
contact to the end users. In a simple statement, the upper level IT staff
gives the lower level staff the ability to open the Group Policy Editor and
do any settings that they want to do to influence what happens at the
workstations level for the users. However, upper level management can still
overrule whatever they want as the policy tree always applies policies based
upon starting at the bottom and work back up to the top of the tree with
override and reversing policy settings.

So in a single sentance summary statement, upper level IT management
delegates the ability to lower level IT administrators to grant any feature
settings they want into their local user population, while the upper level
IT managers retain the option to override the features implemented, even
though they delegated the management.

It's effectively the same idea as granting you children the right to go into
a department store, go where you want to pick what you want to have, then
bring it back up to me....and I'll decide if I will allow the options you
have chosen to go into the basket.

So, that's all the stuff that AD and Group Policy provides at the higher
policy levels. Now, lets see what that looks like at the lower level of an
actual Local Workstation Administrator. This Local Administrator is really
just another case of what I described above....delegation of management with
override of features still retained by the higher authority.

To understand how this can work, let's start with the familiar condition of
a standalone XP workstation that hasn't been joined to a domain yet. In this
condition, members of the Local Administrators have only the permissions
that are granted by default by the installation default MS established.
Well, those rights happen to be nearly unlimited. More accurately, Local
Administrators have the widest power granted to any user on a workstation,
plus they have the ability to grant themselves even greater permissions if
they choose. What greater permissions are these? Well, by default, we don't
think of even the Administrator as having the rights to "act as part of the
OS", in other words, what we call "System Rights". System Rights are the
truly "unlimited" rights. An illustration of the difference is that if you
sit a workstation logged on as the Local Administrator, by default, there
are certain services that are running that you can't open the Task Manager
and kill, the OS won't allow it, that's reserved only for the System Rights
level to kill anything, anytime.

What I have just illustrated is that the Local Administrator doesn't have
these rights by default, but if they so chose, they can alter their default
rights to expand them even further, making themselves part of the OS System.
The reason that Local Administrator can do this is because the design of
Windows is that whatever the Administrator doesn't have the default rights
to do, they can delegate to themselves the ability to gain that right.
Self-empowerment. Occasionally, the Administrator must first grant
themselves ownership of an object in order to then expand their own rights
with that object. This is the concept of "seizing rights" by "seizing
ownership". One a Local Administrator owns an object, they inherit the right
to control the security access to it, therefore they can elevate their own
access control to full rights. At that point, they can then grant themselves
the full use of whatever that object can do.

Okay, I know this is getting a little theoretical for some people. Let's
illustrate it very briefly with an example.

First example is a private folder location that is owned by a user. Most of
us have had an occasion where a folder location is owned by a user with full
rights to it, but the Administrator doesn't have rights to it. The standard
practice if needed is for the Administrator to take ownership first, thereby
granting themselves full rights to alter the security on something they
previously couldn't use. This is comparable to a "break glass to use this
tool". The administrator now broke the condition blocking them from use of
the tool, and now can use it.

If you want to know how and why a Local Administrator gains these rights,
you open up the Local Policy Editor or the Group Policy Editor (which by
default doesn't show assignments other than for Default Domain Controller
Policy) and examine the stuff under the very top section of Computer
Configuration with regard to Local Security Policies. To locate this,
specifically in XP (or W2K I think), go into the Start Menu of an XP box
where you have Administrator rights, browse to Administrator Tools, then
open Local Security (MMC Console based editor). This small section of stuff
is what you would find in the Group Policy Editor under Computer
Configuration |Windows Settings | Security Settings | Local Policies | User
Rights Assignment.

Warning: Please be careful not to change settings while you are in these
locations unless you truly understand the concepts. If you must play, do it
in a lab, not on a production SBS or workstation!

Once you have this open, I want to point out 3 policies for discussion. The
first two at the top of the list, and the last one at the bottom of the
list.

The first two should be "Access this computer from the network" and "Act as
part of the operating system". The last one is "Take ownership of files and
other objects".

These three policies explain simple concepts in a nutshell that reveal how
important the concepts of delegation and management are.

I used examples above that explained the power of being part of the
Operating System. That's equal to having System Rights. By default, there
should be no users or groups listed there on an XP box. By comparison, you
will see that a number of groups are listed in the "Access this machine from
the network.", including the group of Everyone. This is the default starting
point for access via network to this computer. It means that anyone can
_try_ to access this machine. However, to access the machine for a valuable
connection, not Everyone can do more than "try". That's because the Shared
folders and resources have another layer of security on them. That means a
user can "try" to access a shared folder and if that folder grants rights to
that user, they can in fact apply those rights available to them. That might
be read only, or full control, for example.

Now the important distinction we are driving at begins to be revealed.

If we were to remove Everyone from the "Access by network" rights, some
really unexpected results would occur, and you probably don't want to do
this. The reason is that there are many circumstances that the local machine
cannot yet know who is trying to access it until that account has identified
itself to the local computer, but if it's an unknown account....it can't
even get through for that purpose alone because of this policy. It won't
matter what the share permissions are, the policy is absolute, and overrules
the local share object's permissions. No access policy means absolutely not.

We are seeing an example of a very low level policy right that determines
everything about network access entirely. You typically don't think about
this, but this is where the "basic groundrules of operations" are controlled
for this computer.

Now, if you look over all the various rights listed in this section, you
will see that the Administrator or Administartor's group is listed in many
places. What this is telling you is that Administrator rights are not a
"birth right" of the account Administator. Rather, when MS installs the OS,
by default, the account Administrator is given these broad rights by
delegation from the OS install itself. Think of this as "the System"
delegated this unlimited management power and by default, very broad
features rights to the Administrator account.

You know are ready to become aware of a very powerful, important and
potentially dangerous reality: If you remove the Administrator's account
from one or more of these Computer Security Policies, you actually can
downgrade the Local Administrator rights on the machine. This goes beyond
"locking yourself out", it implies locking out the feature sets and rights
that we all assume that an Administrator always has because you probably
have never seen a machine where an Administrator lacked any of the default
rights!

Therefore, let's consider the power of the third policy I mentioned above,
the one at the very bottom of the list. Administrators are the only group
listed in the policy "Take ownership of files and other objects" section,
right?

If you removed the Administrators group from this one location and then
reboot the machine, you discover that the right you always thought an
Administrator had to "seize ownership" is now entirely gone! It ceases to
exist as an inherited right because of that policy change.

Now, before anyone does this, consider that it may be a change that you
prevent the Administrator from "seize ownership", but if you don't lock the
Administrator account out of the ability to _edit policies_, then in fact,
the Administrator can simply return to this same location in policies and
give themselves back the "seize ownership" right.

You know see an interesting point.

If you remove the right to "seize ownership" via this policy, but if that
policy doesn't remove the ability to modify policy the Administrator retains
rights to change (the already own that object or rights to change it), then
you haven't blocked the "reversal right" for that Administrator account to
take back this power for themselves.

If you are not lost in this revelation, you are now ready to see all of this
come together.

Group Policy provides the ability for the higher authority in the domain
security management to set priority features and management at the
workstation level. Yes, that even includes the ability to remove Local
Administrator rights if that's a priority goal. It's just another form of
"Delegation of Management and Features" to lower-level authority. How is
this all possible at the most basic level??

This is how the Domain model works in Windows and MS Network Domain
authority.

When you join a computer into the domain, you are automatically delegating
to the Domain Administration a higher authority than the local Administrator
has because the Domain has the right to alter _computer policies_ and that's
where the Local Administrator obtains account privileges and rights to
manage the computer. Group Policy is the manner and mechanism that allows
the Domain Administration to continue to delegate an unlimited horizon of
rights to the Local Administrator, or to curb them back. Via group policy,
the Domain Administrators have the power to rewrite the book on what it
means to be a local administrator, or for that matter, pretty much anything
else defined at the local workstation. Group Policy on Security Rights
Assignment can redefine what rights are granted to the Local Administator,
or even lock the Local Administrator out of having the ability to alter the
rights presented.

In the example above, I mentioned the idea of removing the Local
Administrator's membership in the "Take control of files and other objects"
but failing to prevent that account from granting that right back to
themselves? Group Policy provides the mechanisms to do this. It's literally
possible to lock down or lock out the local Administrator account.

At some point, somebody with a wee bit of experience is going to jump up and
say "but you can't lock out the Administrator account, it says so in this
book." Well, that assuming that you still have the Local Policies configured
in such a way that the Local Administrator still have the rights involved
that prevent them from being locked out. Yes, Virginia, it is possible to
totally lock out a computer so that you have a seriously bad situation with
nobody having the ability to do anything about it.

In practical matters, what might be useful is to delegate, or more
accurately continue to honor, the rights granted by default for the Local
Administrator, but use Group Policy to prevent escalation, or to constrain
just certain things more than is normally allowed. If you want an example,
consider this one. Suppose you wanted to allow a local Administrator rights
to do everything like normal, but you want to prevent two specific things:

- Deny the Local Administrator account from having the right to logon via
Terminal Services
- Deny the Local Administrator accounts to reverse this policy, or any other
policy condition at the local machine.

You could do this, but you would have to expand your influence a bit. You
would also have to deny the Administrator the rights to regain policy
management, and you would have to prevent the local Administrator from
defeating this set of conditions by removing the workstation from the Domain
control, because that would either leave the computer isolated from
management, or potentially give the Local Administrator the opportunity to
break the definied assumptions about the security of the machine: it's
managed as a member of the domain.

And now you see full circle, the delegation and seizure of rights comes back
around to a "break the glass and seize the rights to an object model" in
full scale. As long as the computer is a domain member, the domain policies
can basically redefine everything about the computer and local accounts,
unless you leave the option to redefine the given condition of domain
management. At some point, a higher level Administrator has to decide just
how far they are willing to shackle local users and Administrators from
doing things without authority.

Many people hide a key around their house, just to be able to get back in if
they lose their regular keys or don't have them in their pocket, they are
inside! Security models in domains works the same way. There may be a point
that you don't want to tighten everything too far.

Once again, please be careful in playing with this, and do NOT do this sort
of stuff on a production domain or workstation. Test with machines and DCs
that you are willing for flatten and reload.

At a local workstation, what you will find is a list of about 60-80 policies
that indicates who has the rights to invoke and use those powers. Notice
that even the Administartors group is listed in there?

"Anna Clark" <anna.clark(remove this)@verizon.net> wrote in message
news:%239Efd9yPEHA.808@tk2msftngp13.phx.gbl...
> Hi Dave:
>
> I appreiciate your input on this.
>
> Can you explain more?
> For example, I wonder why this use has admin privlidges without the
benefit?
> Why not just make this user a user or power user?
>
> Anna
>
> "Dave" <newsATfureyDOTnet> wrote in message
> news:OO7bLTrPEHA.3456@TK2MSFTNGP11.phx.gbl...
> > Correct me if I am wrong, but GROUP POLICIES override this (local admin
> can
> > do anything) capability!
> >
> > I have one workstation that has a user as Administrator (workstation)
and
> I
> > have restricted them to the extreme via group policies. They cannot
> > install/add/remove anything, they can't save to desktop, can't change
> screen
> > saver or background etc. The can't even see their C: drive.
> >
> > The user can't login locally as their DOMAIN account is the one with
Admin
> > privileges.
> >
> > Dave
> >
> > "Dave Nickason [SBS MVP]" <gwdibble@NOSPAM.frontiernet.net> wrote in
> message
> > news:uXKuDXoPEHA.904@TK2MSFTNGP12.phx.gbl...
> > > I'm very lucky in this regard to work for a boss who is computer savvy
> and
> > > security conscious. He is also quite conscious of the cost of having
me
> > > running around fixing problems all day. If you can get the management
> > > behind you, the employees will know that they're fighting a losing
> battle,
> > > and they'll give up. A couple points:
> > >
> > > A user with local admin rights can do anything to a workstation.
Think
> of
> > > the costs to the company of having a careless user accidentally delete
> the
> > > "Documents and Settings" directory, for example, thereby killing the
> data
> > of
> > > all that machine's users. Or, having to pay you to come in and
recreate
> > the
> > > workstation from scratch because someone blew up the OS.
> > >
> > > A user with admin rights can install anything - forget about the
> annoying
> > > screen savers and the time wasted on games. How about viruses,
trojans,
> > > keystroke logging software, back doors, spyware, and any of a variety
of
> > > other types of malware.
> > >
> > > How about the damage that could be done by a malicious user?
Bypassing
> > AV?
> > > Kazaa? Illegal activities exposing the company to liability? Theft
of
> > > company data?
> > >
> > > I have two categories of users - the owner, who installs a variety of
> > > shareware apps, unsupported add-ins, etc. and has constant computer
> > > problems. And everyone else - power users whose only installations
are
> > > controlled by SUS, who generally have no problems at all.
> > >
> > >
> > > "Anna Clark" <anna.clark(remove this)@verizon.net> wrote in message
> > > news:uE3OCBhPEHA.2468@TK2MSFTNGP11.phx.gbl...
> > > > Hi Dave:
> > > >
> > > > You are probably right on with this solution, but there is still the
> > > > larger
> > > > question of young agressive 20 to 30 year olds that grew up with
> > computers
> > > > wanting to do what ever they want with "their" computers.
> > > >
> > > > Making them Administrators seems to keep them quiet, but then
> > applications
> > > > get removed, printers disappear, and all kinds of "unapproved" apps
> get
> > > > installed on the computers.
> > > >
> > > > There must be a way to control this.
> > > >
> > > > Anna
> > > >
> > > >
> > > > "Dave Nickason [SBS MVP]" <gwdibble@NOSPAM.frontiernet.net> wrote in
> > > > message
> > > > news:%23judI$cPEHA.3044@TK2MSFTNGP10.phx.gbl...
> > > >> What happens if you go into the security settings of the folder in
> > > > question,
> > > >> and give whatever permission Administrators have to Authenticated
> > Users?
> > > >> Theoretically, that would solve the problem.
> > > >>
> > > >> I ran into this with a program from the abstract company, where it
> > wanted
> > > > to
> > > >> write files to the workstations' root directory. I asked them to
> > change
> > > >> their program to write to a directory under Documents and Settings
> > rather
> > > >> than give the users write permissions to the root directory. They
> were
> > > >> willing to rewrite their program knowing that they were going to
run
> > into
> > > >> the issue on every default winxp workstation they installed it on.
> > > >>
> > > >> IMO giving all users admin rights is an invitation for a disaster.
> > > >> You'll
> > > >> have no control over what's installed on the workstations,
including
> > > >> spyware, downloaded trojans, kazaa, shareware, etc.
> > > >>
> > > >>
> > > >> "Anna Clark" <anna.clark(remove this)@verizon.net> wrote in message
> > > >> news:ePYPI%23bPEHA.2580@TK2MSFTNGP09.phx.gbl...
> > > >> > Hello everyone:
> > > >> >
> > > >> > One of my sites has a problem. The are a mortgage broker company
> and
> > > > use
> > > >> > a
> > > >> > software that requires that they save their loan applications to
a
> > > > folder
> > > >> > on
> > > >> > the local workstation.
> > > >> >
> > > >> > Unless their domain id is part of the local adminstrators group,
> they
> > > >> > cannot
> > > >> > save the file.
> > > >> >
> > > >> > Moreover, it seems to me that to make an end user any less than
an
> > > >> > administrator over the local system is just asking to make trip
> after
> > > > trip
> > > >> > to the site to give disgruntled users permissions to do this and
> > that.
> > > >> >
> > > >> > How do others handle this problem, if it is a problem... or have
I
> > > > missed
> > > >> > something basic.
> > > >> >
> > > >> > I take care of SBS W2K, and SBS 2K3 sites where the clients are
XP
> > Pro
> > > > or
> > > >> > W2K Pro and face this issue at all of them.
> > > >> >
> > > >> > Thanks for your input.
> > > >> >
> > > >> > Anna
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: unable to installed software. No rights
    ... If the default is 60 minutes then this means that machine policy will be ... If users in your environment don't have rights ... this checkbox doesn't make any difference on SMS Advanced client. ... Please log in as an administrator or contact your network ...
    (microsoft.public.sms.swdist)
  • Re: Fax in Win2k3
    ... /Begin Quote: ... Go to administrative tools and open the default domain controller policy ... Add the account NETWORK SERVICE to the following rights ... >> The message always indicates to talk to my fax administrator, ...
    (microsoft.public.win2000.fax)
  • Re: No users on Welcome Screen after using cntrl passwords2 in XP Home
    ... administrator policy to a little more secure like power user. ... into safe mode and logged into Admin account, and could not find the other ... as Guest user rights and was unable to make any changes due to ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Everyone Group Missing
    ... access the Local Security Policy ... I have administrative rights, I have ... >> my PC by limiting the rights of the local administrator ...
    (microsoft.public.win2000.security)
  • "Local administrator" access to one DC without being full administrator on the whole domai
    ... Denmark and a DC in the US as well. ... local administrator in the US offices has been delegated full rights for his ... I also want the local administrator in the US to have "local ...
    (microsoft.public.win2000.active_directory)