Admin Rights Best Practices

Posted on 2009-06-30
Last Modified: 2015-02-16
We have a broad range of users from developers and testers to Desktop Support, etc. Apart from security groups which allow domain level access for help desk and users, we have the need for local admin rights on the machines.

I know that best practice is to determine what access/permissions are needed on the local level and grant that access without the use of local admin rights, however, we are not there yet.

We are planning on using a bang account (second account) such as sfarazmand!  We want to limit domain access as well, so that users are not using the admin account as their default.

The question is which is best practice; to use a domain account or a local account. What are pros and cons of each
Question by:sfarazmand
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 25 total points
ID: 24747322
You are right with your statement that the best practice is to limit admin accounts (either local or domain)
Who actually needs to be an administrator on the workstations, is that all users and all helpdesk.  Why do all users need admin rights?
We give our help desk staff admin rights by doing the second account like you are doing.  Then we put those into a group called "helpdesk admins".  We use restricted groups to add the group to the worksations.
Really good article on restricted groups here:

Assisted Solution

LBizzle earned 75 total points
ID: 24747751
If you have the ability and your structure allows for it an easy workaround for using domain accounts at the local level and the limit the workstations they access (for example to exclude them from having access to Servers or IT, HR & Finance workstations is you can create a new OU for PC's the standard users would need access too and then everyone who needs access is put in to a group and given permission over that OU.

Or Several groups and OU's for each department (one for HR, one for Finance and then on each of these OU's you have one or several groups to define admin, Power User etc.. rights). I have worked both scenarios and it works fine; the one best practice when doing what you are asking or if you use one of my mentioned structures here is that DO NOT USE Distribution lists as security groups, besides it's pet peeve of mine and one of the sure ways to loose control over who has the proper access to what resources.

Having a second account for each user just increases the amount of password lockouts, permissions issues etc.. that need to be handled. With a decent OU and domain group security structure you can probably easily address your access needs until you can get away from them needing admin priv at all which is where I have finally gotten, (thank the mighty redmond over lords for not finding a way to stop it).
LVL 27

Assisted Solution

bluntTony earned 400 total points
ID: 24747948
I would say always use domain accounts. This keeps management of those accounts centralised. You are then able to control them using group policy, AD delegation, and domain local and global security groups.
I personally can't see any advantage of creating various local accounts across a number of machines.
Like Mike says, you can then use Restricted Group policies to control which domain users have what levels of access on different groups of machines locally, and then use User Rights Assignments to control what groups/users (whether local or domain) can perform what tasks.
I do think that you shouldn't really touch the built-in Administrator account - rename it and leave it alone for a rainy day. Create accounts for admins which have the required elevated privileges. Best practice is for each admin to have two accounts - one for everyday work, another when elevated privileges are needed. I understand the reasons behind this, but it depends how far you wish to take it.
With regards to the one account you mentioned with elevated privileges, the main issue with this I see is auditing. You've no way of knowing who did what if they all use one account. It depends how much you trust your admins!
Is Your AD Toolbox Looking More Like a Toybox?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.


Author Comment

ID: 24753682
The main concern is local admin rights (LAR) for users. One user per machine (sfarazmand on WS33990). Users currently have admin rights and we have been cleaning this up. There are however those who state they need these rights and while we work with business units to find out exactly why, we still need to get the job done.
We currently (someone's poor design) have all the users (about 3000) in the users container. We cannot change this because there are about 40 applications pointing there. If we do use group policy it will require going through an approval process as well as management on a monthly basis.
The mentality was that with the second account, the account management group could simply disable the account, instantly removing LAR. We would be able to place the secondary accounts in an OU making it easy to see who has local admin rights which would enable us to ensure those accounts or access is not removed and that we can go back and review to see if they are still needed.
That's what we were thinking.
LVL 27

Assisted Solution

bluntTony earned 400 total points
ID: 24755202
It sounds like you're a bit stuck with user policies then, as the Users container is not an OU and cannot have GPOs linked to it. You could only create domain-linked GPOs and use security filtering the target groups of users which could get messy.
However, Restricted Groups and User Rights Assignments are computer configuration policies and therefore linked to OUs containing the computers, not users, so you could implement these.
Also bear in mind that without centralised control of who is and who isn't a local admin, there's nothing stopping a user creating another admin account locally on a machine while they have the rights to. As soon as you remove their admin rights, they could use this new account without your knowledge. Restricted Groups counters this as users cannot modify the local groups.
You also mention placing the admin accounts in an OU - this isn't possible with local accounts as they do not exist in AD.
How about this - create a domain local group (say User_Admins). Add all the users who say they require local admin rights to this group. Create a restricted groups policy adding this domain local group the each machine's local Admin group, effectively giving it's members local admin rights. Then your accounts management group just has to add/remove users out of this group to grant/deny local admin rights. This sounds a lot simpler than having multiple local admin accounts on each group, and each user only then has one account to use.

Author Comment

ID: 24755995
To clarify with the OUs/Admins, I was talking about domain accounts (which would be the user account with an ! at the end) put in the OU and then using the new 2008 Group Policy Preferences to manage LAR. That would prevent the user from adding another admin account on the machine.
LVL 27

Accepted Solution

bluntTony earned 400 total points
ID: 24756323
I think we are at cross purposes. I thought you were considering creating a local admin account on each machine, which I why I said what I did.
The group policy preferences you mentioned are basically the same as Restricted Groups, only the prefences are a bit more flexible I think. You can add/remove users into an OU and they will be added/removed from the local group. So we're on the same page there.
If you are going to do this, then I don't think there would be a need to have two user accounts. Just add/remove users to and from the OU to which this policy is applied. Ensure this OU is a sub-OU of the main users OU and it will still inherit all other policies.
What you are suggesting will work fine. There's always a number of ways to do things and it just depends on how you want to administer things.

Author Closing Comment

ID: 31598418
Thanks for all the input. This has me thinking a bit more and I will need to present all sides as options.  Thanks again

Expert Comment

ID: 40612327
I would love it if bluntTony saw my comment and replies! I am in a similar situation as the OP. I have an inherited AD that needs some attention. Domain Users was granted membership to the local Administrators group on all PC's. I have corrected that for 90% of my domain at this point by simply removing Domain Users from that policy. Now I need to implement a good method for allowing some users administrative access, like we commonly say, for those users that say they need local admin privs.

bluntTony, in your solution for the OP, you say just add/remove users to and from the OU. Are you in the mind set of the "user" needing access and they call the helpdesk, helpdesk tech moves the user into the appropriate OU and later removes them? If I understand this correctly, this would grant the user LAR for any PC that is also in the appropriate OU.

If so, what is the option for granting LAR for a user specifically on their PC? We have limited staff, we do not have a helpdesk, I am all-in for this methodology but unfortunately I don't think it will get approved. So, what I am trying to accomplish is to allow a small group of users, LAR to their PC ONLY and no one else's.

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article shows the method of using the Resultant Set of Policy Tool to locate Group Policy that applies a particular setting.
This article provides a convenient collection of links to Microsoft provided Security Patches for operating systems that have reached their End of Life support cycle. Included operating systems covered by this article are Windows XP,  Windows Server…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question