Least User Priviledges for Network Administrators

  • Thread starter Thread starter Thomas M.
  • Start date Start date
T

Thomas M.

XP SP2

My organization is trying to comply with the principal of least user
privileges, and toward that end I have been given the task of converting all
the users in my organization to standard user accounts. We've been doing
this using the Restricted Groups policy, and for the most part it hasn't
been a problem, but now I am working with our network technology group and
I've run into some issues.

The employees in our network technology group are the people who design the
network, install routers and switches, run all the cabling and install
network jacks, use protocol analyzers to monitor network traffic and
troubleshoot problems, etc. They maintain that they must be able to:

1) Use terminal services and FTP
2) Disable the firewall
3) Change NIC settings
4) Change IP address and subnet settings
5) Download and install drivers and networking tools

I'm sure the list goes on, but thus far they have not complied with my
request for a complete list of duties that may be impacted by the loss of
administrative rights. I've looked at making them all members of the
Network Configuration Operators group, and while that may solve some issues
it also looks like it will not solve every issue that I'll have with these
users. I've also taken a quick look at some tools that would all specific
applications to be run with a different set of credentials, so maybe the
employee would login as an administrator but specific "high risk"
applications would run with reduced rights, or maybe they'd login with
limited rights and specific applications would run with administrator
rights. But I kind of don't want to introduce a process like that if I can
avoid it.

I'd appreciate the advice of anyone who's had to deal with converting these
kinds of users to standard user accounts. Also, are there any group
policies, or software tools, that would allow these users to do the things
that they have a legitimate need to do in their daily jobs? Are there any
registry keys that I can give them rights to that would (presto chango)
allow them to modify any network setting on their local machine?

Any help that can be offered will be greatly appreciated!

--Tom
 
While implementing the principle of least privilege is a noble goal I think
you might be over doing it with that group of users. Most likely they are
all highly trained competent people very knowledgeable about computers and
people you already trust as they have access to very sensitive areas of your
network.

Consider the unintended consequences of trying to limit such a group which
could include reduced productivity, missing deadlines, bad for morale, and
they feeling untrusted and incompetent. Also being a local administrator
does not give a user any additional access to the domain assuming basic best
practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would slow
their computer down, change settings they know nothing about, disable
malware protection because they can not access some stupid website, creating
shares so their buddy can access their computer, etc. All this can greatly
impact their productivity and increase IT costs cleaning up the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to needed
services [can be done via Group Policy], add to privileged groups other than
administrators, and to grant user rights above what regular users have [via
Group Policy]. Unfortunately there are many tasks that simply can not be
granted to a regular user no matter what you try as usually evidenced by
object access failures in the security log when auditing of object access is
enabled. There is not set plan so you will have to do a ton of trial and
error footwork to see if you can accomplish what you want but I am doubtful
it can be done with the needs of your network technology group. Training
users that need administrator access to logon as a regular user and then use
runas when they need admin powers is a good practice.

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest
 
Steven L Umbach said:
While implementing the principle of least privilege is a noble goal I think
you might be over doing it with that group of users. Most likely they are
all highly trained competent people very knowledgeable about computers and
people you already trust as they have access to very sensitive areas of your
network.

Agree, and the imposition of restrictions on sysops will be so frustrating
that they will likely cease to do their jobs properly - which will further
impact on security.

I think if you want to improve security in the Administrative area, you
could take a long hard look at the more vulnerable aspects of Windows'
remote-admin schemes, for example the Remote Registry service, Terminal
Services, and Administrative Shares (C$, etc.) If you don't need or use these
you can give a significant boost to security by turning them off. If you
later find you DO need them, it's easy enough to turn them back on.

The other key point of course is that granting Domain Admin rights is a very
different thing from granting local Administrator rights. Routine maintenance
or helpdesk work should never be done under a Domain Admin account, as this
exposes the entire network to any malware which might happen to be running on
the faulty computer. Therefore, never use a Domain Admin logon anywhere other
than at a known 'clean' computer, such as a server.
 
I agree with your assessment of controlling what users are also some sort of
admin for the domain and where they use those powers. Along those line a
common security vulnerability is to logon to a domain computer to do work
that requires administrator privileges on that domain computer [non DC] with
a user that is in the domain admins group. That is probably the number 1 way
to give away your domain.

Steve
 
Sorry for the delay in response. I've been out sick for the last few days.

While I understand the thrust of your comments, I also believe that one of
your assumptions is at least partially flawed. You stated that the users in
our Network Technology group are most likely, "people that you already
trust." Trust how? Do we trust them to maintain network equipment? Yes.
Do we trust them to observe proper security practices on the desktop, and to
NOT install unlicensed versions of software? No. In fact, improper desktop
security practices and the installation of unlicensed software occur within
our Network Technology group at a rate that is far beyond that of any other
group of users. It is fair to say that as a group they have a spotty record
when it comes to following enterprise desktop security standards and
policies, and they have run afoul of software licensing requirements.
Management is partly to blame for the situation because until now they have
done nothing to crack down on that kind of behavior. So, in a sense, we
don't trust them because they've proven that a certain level of distrust is
appropriate.

That being said, I do not believe that any of them would do anything
malicious, so in that respect we do trust them. The question then becomes,
how do we allow them to do their jobs with the least amount of disruption
and inconvenience, and still insure that desktop security standards are
enforced, and that they're not installing just any old software that they
download from the Internet?

Maybe with XP SP2, that balance just can't be achieved, and if that's the
case then I guess we'll have to live with that fact. At the same time, my
job is to try to find a way to institute the security standards of the
enterprise without crushing their ability to do their jobs. So, I need to
do my due diligence and try to find a creative solution. One example of a
creative solution is what we did with our Web programmers. Some of their
tools do require administrative rights, so we took those tools off the
desktop and moved them to a virtual server. The programmers have full
administrative rights within the virtual environment, but are only standard
users on the desktop. Maybe something similar would work for our Network
Technology group, and maybe not, but these are the kinds of solutions that I
need to consider.

--Tom

Steven L Umbach said:
While implementing the principle of least privilege is a noble goal I
think you might be over doing it with that group of users. Most likely
they are all highly trained competent people very knowledgeable about
computers and people you already trust as they have access to very
sensitive areas of your network.

Consider the unintended consequences of trying to limit such a group which
could include reduced productivity, missing deadlines, bad for morale, and
they feeling untrusted and incompetent. Also being a local administrator
does not give a user any additional access to the domain assuming basic
best practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would slow
their computer down, change settings they know nothing about, disable
malware protection because they can not access some stupid website,
creating shares so their buddy can access their computer, etc. All this
can greatly impact their productivity and increase IT costs cleaning up
the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to needed
services [can be done via Group Policy], add to privileged groups other
than administrators, and to grant user rights above what regular users
have [via Group Policy]. Unfortunately there are many tasks that simply
can not be granted to a regular user no matter what you try as usually
evidenced by object access failures in the security log when auditing of
object access is enabled. There is not set plan so you will have to do a
ton of trial and error footwork to see if you can accomplish what you want
but I am doubtful it can be done with the needs of your network technology
group. Training users that need administrator access to logon as a regular
user and then use runas when they need admin powers is a good practice.

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest
 
Thanks for the response.

We've already covered most of the other security issues that you mentioned.
We use Citrix in place of TS. By providing a Citrix desktop loaded with the
appropriate tools and drive mappings, we completely negate the need for
people to TS to their local PCs. If a person has data stored on the local
PC then that person is in violation of an enterprise policy and is SOL as
far as accessing those files is concerned (we require data to be stored on a
network share so that it can be backed up, and so that it will be available
via a drive mapping in Citrix). Administrative shares are strictly
prohibited by our enterprise policies. Finally, the accounts that we use to
administer local PCs have rights only on the PC--those accounts have no
rights at the domain level.

--Tom
 
We're working on some of the things that you mentioned. We already have the
computer use policies, software purchasing policies, security policies, etc.
For reasons that I don't entirely understand (I've only been here 18 months)
that group has historically been able to get away with ignoring such
policies. However, there has recently been a change in upper
management--both within the Network Technology group, and at the top of the
organization as a whole--and the new management team is really driving the
process of tightening down security. So things are changing for the better.

I also have thought about using the Restricted Software group policy, but
there are a couple of hurdles to clear before I can leverage that solution.
The first hurdle was that no one in our organization gets access to group
policies without first completing intermediate level classes on AD and Group
Policy (a sensible quality control measure). I already had the skills, but
I still had to complete the classes to get permissions to start using group
policies, and I just completed those requirements about 3 weeks ago. Since
then, I've been working on getting our AD cleaned up and creating a proper
OU structure that will allow us to really leverage the power of group
policies. Finally, historically, my employer has been mainly a Novell shop
at the enterprise network level (Windows on the desktop) and we use Novell
tools for all of our software distribution, except for Windows patches where
we use WSUS. We have an enterprise policy that requires me to get Group
Policy approved as an accepted enterprise standard for software
distribution, which we are working on. So things are moving in the right
direction, but we do have a little way to go before we can really start
using the Restricted Software group policy. In the mean time, I have run
some software inventory reports using our Novell tools and those reports
have been distributed to each bureau chief, so they've been working on
cleaning up some of the installed software on desktops.

I suspect that you're right about the fact that the users in the Network
Technology group will probably end up having admin rights to local machines.
I have a meeting scheduled for next week with the section supervisors from
that group and some of the employees in the trenches to more clearly define
what they do on a day-to-day basis, and to hopefully find some middle
ground. But honestly, I'm not too hopeful that there will be a middle
ground. I suspect that those users will need to be local admins.

--Tom


Steven L Umbach said:
Looks like I may have over estimated that group. As you mention it sounds
like a big part of the problem has been management so if you have the ears
of the powers that be it would be good to institute computer use policy
that defines specific can and can not with spelled out disciplinary action
possibilities but to be effective the policy needs to be enforced. Such
computer use policies are as essential as computer technical policies.

Again it still may be from very difficult to impossible to have users in
that group not be local administrators due to the nature of their work. An
additional item I want to mention is to look into the user of Software
Restriction Policies to manage what they can run and install on their
computers. Maybe you could have the better disciplined users not that
locked down so that they could try new tools and software that could then
be approved for the rest of the users. Software Restriction Policies can
be enforced for local administrators also BUT local administrators are
exempt from Software Restriction policies while in Safe Mode but the user
most likely would not know that.

Steve


Thomas M. said:
Sorry for the delay in response. I've been out sick for the last few
days.

While I understand the thrust of your comments, I also believe that one
of your assumptions is at least partially flawed. You stated that the
users in our Network Technology group are most likely, "people that you
already trust." Trust how? Do we trust them to maintain network
equipment? Yes. Do we trust them to observe proper security practices on
the desktop, and to NOT install unlicensed versions of software? No. In
fact, improper desktop security practices and the installation of
unlicensed software occur within our Network Technology group at a rate
that is far beyond that of any other group of users. It is fair to say
that as a group they have a spotty record when it comes to following
enterprise desktop security standards and policies, and they have run
afoul of software licensing requirements. Management is partly to blame
for the situation because until now they have done nothing to crack down
on that kind of behavior. So, in a sense, we don't trust them because
they've proven that a certain level of distrust is appropriate.

That being said, I do not believe that any of them would do anything
malicious, so in that respect we do trust them. The question then
becomes, how do we allow them to do their jobs with the least amount of
disruption and inconvenience, and still insure that desktop security
standards are enforced, and that they're not installing just any old
software that they download from the Internet?

Maybe with XP SP2, that balance just can't be achieved, and if that's the
case then I guess we'll have to live with that fact. At the same time,
my job is to try to find a way to institute the security standards of the
enterprise without crushing their ability to do their jobs. So, I need
to do my due diligence and try to find a creative solution. One example
of a creative solution is what we did with our Web programmers. Some of
their tools do require administrative rights, so we took those tools off
the desktop and moved them to a virtual server. The programmers have
full administrative rights within the virtual environment, but are only
standard users on the desktop. Maybe something similar would work for
our Network Technology group, and maybe not, but these are the kinds of
solutions that I need to consider.

--Tom

Steven L Umbach said:
While implementing the principle of least privilege is a noble goal I
think you might be over doing it with that group of users. Most likely
they are all highly trained competent people very knowledgeable about
computers and people you already trust as they have access to very
sensitive areas of your network.

Consider the unintended consequences of trying to limit such a group
which could include reduced productivity, missing deadlines, bad for
morale, and they feeling untrusted and incompetent. Also being a local
administrator does not give a user any additional access to the domain
assuming basic best practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would
slow their computer down, change settings they know nothing about,
disable malware protection because they can not access some stupid
website, creating shares so their buddy can access their computer, etc.
All this can greatly impact their productivity and increase IT costs
cleaning up the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to needed
services [can be done via Group Policy], add to privileged groups other
than administrators, and to grant user rights above what regular users
have [via Group Policy]. Unfortunately there are many tasks that simply
can not be granted to a regular user no matter what you try as usually
evidenced by object access failures in the security log when auditing of
object access is enabled. There is not set plan so you will have to do a
ton of trial and error footwork to see if you can accomplish what you
want but I am doubtful it can be done with the needs of your network
technology group. Training users that need administrator access to logon
as a regular user and then use runas when they need admin powers is a
good practice.

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest
 
Looks like I may have over estimated that group. As you mention it sounds
like a big part of the problem has been management so if you have the ears
of the powers that be it would be good to institute computer use policy that
defines specific can and can not with spelled out disciplinary action
possibilities but to be effective the policy needs to be enforced. Such
computer use policies are as essential as computer technical policies.

Again it still may be from very difficult to impossible to have users in
that group not be local administrators due to the nature of their work. An
additional item I want to mention is to look into the user of Software
Restriction Policies to manage what they can run and install on their
computers. Maybe you could have the better disciplined users not that locked
down so that they could try new tools and software that could then be
approved for the rest of the users. Software Restriction Policies can be
enforced for local administrators also BUT local administrators are exempt
from Software Restriction policies while in Safe Mode but the user most
likely would not know that.

Steve


Thomas M. said:
Sorry for the delay in response. I've been out sick for the last few
days.

While I understand the thrust of your comments, I also believe that one of
your assumptions is at least partially flawed. You stated that the users
in our Network Technology group are most likely, "people that you already
trust." Trust how? Do we trust them to maintain network equipment? Yes.
Do we trust them to observe proper security practices on the desktop, and
to NOT install unlicensed versions of software? No. In fact, improper
desktop security practices and the installation of unlicensed software
occur within our Network Technology group at a rate that is far beyond
that of any other group of users. It is fair to say that as a group they
have a spotty record when it comes to following enterprise desktop
security standards and policies, and they have run afoul of software
licensing requirements. Management is partly to blame for the situation
because until now they have done nothing to crack down on that kind of
behavior. So, in a sense, we don't trust them because they've proven that
a certain level of distrust is appropriate.

That being said, I do not believe that any of them would do anything
malicious, so in that respect we do trust them. The question then
becomes, how do we allow them to do their jobs with the least amount of
disruption and inconvenience, and still insure that desktop security
standards are enforced, and that they're not installing just any old
software that they download from the Internet?

Maybe with XP SP2, that balance just can't be achieved, and if that's the
case then I guess we'll have to live with that fact. At the same time, my
job is to try to find a way to institute the security standards of the
enterprise without crushing their ability to do their jobs. So, I need to
do my due diligence and try to find a creative solution. One example of a
creative solution is what we did with our Web programmers. Some of their
tools do require administrative rights, so we took those tools off the
desktop and moved them to a virtual server. The programmers have full
administrative rights within the virtual environment, but are only
standard users on the desktop. Maybe something similar would work for our
Network Technology group, and maybe not, but these are the kinds of
solutions that I need to consider.

--Tom

Steven L Umbach said:
While implementing the principle of least privilege is a noble goal I
think you might be over doing it with that group of users. Most likely
they are all highly trained competent people very knowledgeable about
computers and people you already trust as they have access to very
sensitive areas of your network.

Consider the unintended consequences of trying to limit such a group
which could include reduced productivity, missing deadlines, bad for
morale, and they feeling untrusted and incompetent. Also being a local
administrator does not give a user any additional access to the domain
assuming basic best practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would
slow their computer down, change settings they know nothing about,
disable malware protection because they can not access some stupid
website, creating shares so their buddy can access their computer, etc.
All this can greatly impact their productivity and increase IT costs
cleaning up the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to needed
services [can be done via Group Policy], add to privileged groups other
than administrators, and to grant user rights above what regular users
have [via Group Policy]. Unfortunately there are many tasks that simply
can not be granted to a regular user no matter what you try as usually
evidenced by object access failures in the security log when auditing of
object access is enabled. There is not set plan so you will have to do a
ton of trial and error footwork to see if you can accomplish what you
want but I am doubtful it can be done with the needs of your network
technology group. Training users that need administrator access to logon
as a regular user and then use runas when they need admin powers is a
good practice.

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest
 
Sounds like you have a good plan Tom and if you have the buyin and support
of management that is key. Unfortunately in a previously loose running shop
usually a few examples need to be made of violators before the rest realize
the powers that be are serious about what they say and things will start
getting better.

It makes sense to have a chain of command and approval policy to keep things
united and consistent though it does slow progress at first. Stick to your
plan and you will find that fine line to make it work about as well as it
possibly can between policy and technical solutions.

Good luck!

Steve

Thomas M. said:
We're working on some of the things that you mentioned. We already have
the computer use policies, software purchasing policies, security
policies, etc. For reasons that I don't entirely understand (I've only
been here 18 months) that group has historically been able to get away
with ignoring such policies. However, there has recently been a change in
upper management--both within the Network Technology group, and at the top
of the organization as a whole--and the new management team is really
driving the process of tightening down security. So things are changing
for the better.

I also have thought about using the Restricted Software group policy, but
there are a couple of hurdles to clear before I can leverage that
solution. The first hurdle was that no one in our organization gets access
to group policies without first completing intermediate level classes on
AD and Group Policy (a sensible quality control measure). I already had
the skills, but I still had to complete the classes to get permissions to
start using group policies, and I just completed those requirements about
3 weeks ago. Since then, I've been working on getting our AD cleaned up
and creating a proper OU structure that will allow us to really leverage
the power of group policies. Finally, historically, my employer has been
mainly a Novell shop at the enterprise network level (Windows on the
desktop) and we use Novell tools for all of our software distribution,
except for Windows patches where we use WSUS. We have an enterprise
policy that requires me to get Group Policy approved as an accepted
enterprise standard for software distribution, which we are working on.
So things are moving in the right direction, but we do have a little way
to go before we can really start using the Restricted Software group
policy. In the mean time, I have run some software inventory reports
using our Novell tools and those reports have been distributed to each
bureau chief, so they've been working on cleaning up some of the installed
software on desktops.

I suspect that you're right about the fact that the users in the Network
Technology group will probably end up having admin rights to local
machines. I have a meeting scheduled for next week with the section
supervisors from that group and some of the employees in the trenches to
more clearly define what they do on a day-to-day basis, and to hopefully
find some middle ground. But honestly, I'm not too hopeful that there
will be a middle ground. I suspect that those users will need to be local
admins.

--Tom


Steven L Umbach said:
Looks like I may have over estimated that group. As you mention it sounds
like a big part of the problem has been management so if you have the
ears of the powers that be it would be good to institute computer use
policy that defines specific can and can not with spelled out
disciplinary action possibilities but to be effective the policy needs to
be enforced. Such computer use policies are as essential as computer
technical policies.

Again it still may be from very difficult to impossible to have users in
that group not be local administrators due to the nature of their work.
An additional item I want to mention is to look into the user of Software
Restriction Policies to manage what they can run and install on their
computers. Maybe you could have the better disciplined users not that
locked down so that they could try new tools and software that could then
be approved for the rest of the users. Software Restriction Policies can
be enforced for local administrators also BUT local administrators are
exempt from Software Restriction policies while in Safe Mode but the user
most likely would not know that.

Steve


Thomas M. said:
Sorry for the delay in response. I've been out sick for the last few
days.

While I understand the thrust of your comments, I also believe that one
of your assumptions is at least partially flawed. You stated that the
users in our Network Technology group are most likely, "people that you
already trust." Trust how? Do we trust them to maintain network
equipment? Yes. Do we trust them to observe proper security practices
on the desktop, and to NOT install unlicensed versions of software? No.
In fact, improper desktop security practices and the installation of
unlicensed software occur within our Network Technology group at a rate
that is far beyond that of any other group of users. It is fair to say
that as a group they have a spotty record when it comes to following
enterprise desktop security standards and policies, and they have run
afoul of software licensing requirements. Management is partly to blame
for the situation because until now they have done nothing to crack down
on that kind of behavior. So, in a sense, we don't trust them because
they've proven that a certain level of distrust is appropriate.

That being said, I do not believe that any of them would do anything
malicious, so in that respect we do trust them. The question then
becomes, how do we allow them to do their jobs with the least amount of
disruption and inconvenience, and still insure that desktop security
standards are enforced, and that they're not installing just any old
software that they download from the Internet?

Maybe with XP SP2, that balance just can't be achieved, and if that's
the case then I guess we'll have to live with that fact. At the same
time, my job is to try to find a way to institute the security standards
of the enterprise without crushing their ability to do their jobs. So,
I need to do my due diligence and try to find a creative solution. One
example of a creative solution is what we did with our Web programmers.
Some of their tools do require administrative rights, so we took those
tools off the desktop and moved them to a virtual server. The
programmers have full administrative rights within the virtual
environment, but are only standard users on the desktop. Maybe
something similar would work for our Network Technology group, and maybe
not, but these are the kinds of solutions that I need to consider.

--Tom

While implementing the principle of least privilege is a noble goal I
think you might be over doing it with that group of users. Most likely
they are all highly trained competent people very knowledgeable about
computers and people you already trust as they have access to very
sensitive areas of your network.

Consider the unintended consequences of trying to limit such a group
which could include reduced productivity, missing deadlines, bad for
morale, and they feeling untrusted and incompetent. Also being a local
administrator does not give a user any additional access to the domain
assuming basic best practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would
slow their computer down, change settings they know nothing about,
disable malware protection because they can not access some stupid
website, creating shares so their buddy can access their computer, etc.
All this can greatly impact their productivity and increase IT costs
cleaning up the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to
needed services [can be done via Group Policy], add to privileged
groups other than administrators, and to grant user rights above what
regular users have [via Group Policy]. Unfortunately there are many
tasks that simply can not be granted to a regular user no matter what
you try as usually evidenced by object access failures in the security
log when auditing of object access is enabled. There is not set plan so
you will have to do a ton of trial and error footwork to see if you can
accomplish what you want but I am doubtful it can be done with the
needs of your network technology group. Training users that need
administrator access to logon as a regular user and then use runas when
they need admin powers is a good practice.


tp://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest
 
Back
Top