Admin Rights Best Practices

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
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Mike KlineCommented:
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:
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).
bluntTonyHead of ICTCommented:
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!
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

sfarazmandAuthor Commented:
The main concern is local admin rights (LAR) for users. One user per machine (flast! on workstation1). 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.
bluntTonyHead of ICTCommented:
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.
sfarazmandAuthor Commented:
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.
bluntTonyHead of ICTCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sfarazmandAuthor Commented:
Thanks for all the input. This has me thinking a bit more and I will need to present all sides as options.  Thanks again
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Project Management

From novice to tech pro — start learning today.