Solved

Admin Rights Best Practices

Posted on 2009-06-30
9
1,805 Views
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
0
Comment
Question by:sfarazmand
9 Comments
 
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:
http://www.frickelsoft.net/blog/?p=13
Thanks
Mike
0
 
LVL 7

Assisted Solution

by:LBizzle
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).
0
 
LVL 27

Assisted Solution

by:bluntTony
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!
0
 
LVL 7

Author Comment

by:sfarazmand
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.
0
 
LVL 27

Assisted Solution

by:bluntTony
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.
0
 
LVL 7

Author Comment

by:sfarazmand
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.
http://www.windowsecurity.com/articles/Securing-Local-Administrators-Group-Every-Desktop.html
 http://msforums.ph/blogs/phiwug/archive/2009/03/30/windows-server-2008-manageability-features-group-policy-preferences-part-2-the-local-administrator.aspx
0
 
LVL 27

Accepted Solution

by:
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.
0
 
LVL 7

Author Closing Comment

by:sfarazmand
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
0
 
LVL 1

Expert Comment

by:ctna
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.
0

Join & Write a Comment

Communication between departments might not happen in two different languages, but they do exist in two different worlds. With different targets and performance goals the same phrase often means something completely different to each party. Learn ho…
In this article, you will read about the trends across the human resources departments for the upcoming year. Some of them include improving employee experience, adopting new technologies, using HR software to its full extent, and integrating artifi…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

759 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now