Problem: Office politics made it impossible to take away all administrative rights for some staff members. You need a painless way to delegate administrative rights to certain users without jeopardizing the security of many machines.
Solution: Use User Configuration – Local User and Groups Preferences to add and remove users depending on who is logged on. Ready to see it in action? Read on
Manage Administrative Permissions with Group Policy Preferences
Group Policy MVP Martin Binder taught me this trick when he posted a comment here. In this article, we will outline that idea and provide some step-by-step guidance for implementation.
Start by creating two security groups in Active Directory named something like:
- Local Admin Computers
- Local Admin Users
Add the users needing administrative rights to the Local Admin Users group. Any computer that they need the permissions on should be added to the Local Admin Computers group. I prefer using two separate groups as I do not like to have multiple object types in the same security group.
Create a new GPO named Restricted Group: Additional Local Admins. Though we will be using Group Policy Preferences, I like keeping the GPO prefix the same as my other restricted groups GPOs. Under Security Filtering, add both groups that you created earlier. We will be using loopback for this GPO – both the user and computer will need permissions to apply the GPO. The GPO should be linked to a OU containing members of the Local Admin Computers security group.
Edit the GPO. If your computers do not already have loopback enabled, navigate to Computer Configuration/Policies/Administrative Templates/System/Group Policy. Enable Configure user Group Policy loopback processing mode and set the mode to Merge. Ensure that the GPO is processed when a member of Local Admin Users logs into a computer in the Local Admin Computers group. If not, see this Group Policy troubleshooting guide.
Under User Configuration, navigate to Preferences/Control Panel Settings/Local Users and Groups. Select New – Local Group. Under Group Name, select the search button (…) and search for Administrators. Make sure that the scope is set to the local computer’s account. Enable Add the current user and check the Delete all member users box. Your preference should look like the screenshot below:
You are done! Easy right? Now, how will this preference interact in a live environment?
What is going on behind the scenes with GPP Local Users and Groups
We have a user, Abigail Admin. She is a member of the Local Admin Users group. When she logs into PC-01 (which is a member of Local Admin Computers), she will be made an administrator on her first logon! When she logs into PC-02 (which is not a member of Local Admin Computers), she will not be an administrator.
If Adam Admin (who is also a member of Local Admin Users) logs into PC-01, Abigail is removed from the administrators group and Adam will be added. This keeps our Administrators group clean and minimizes potential issues.
This method is significantly better than making all members of the Local Admin Users group administrators on every computer in the Local Admin Computers group. Only one user is an administrator of a single computer at a time. If you wanted to get more granular, you could even create specific security groups and use Item Level Targeting to do 1:1 matches.
Local Users and Groups Preferences pair nicely with Restricted Groups. GPP will overlay changes on top of policies deployed by Restricted Groups (either in Append or Clear modes). Groups controlled by Restricted groups will still be populated as normal.
How are you managing group memberships? Will Group Policy Preferences make the process easier?
A problem with this approach is that staff will have access to each other’s machines. Eg you have some director who wants local admin rights, and you have some developers who want admin rights, the developers will have access to the director’s c$ share. Not great.
You need an AD group per machine (eg domain\localAdmins_)
During machine startup, kick any manually added user accounts out of local admins and add %userdomain%\localAdmins_%computername%
If the domain group doesn’t exist, not problem.
If it exists it’s added to the local admins group.
This is a safer way to centrally give staff local admin rights to a machine and only that machine.
Though I agree with you that generally staff don’t need admin rights (you can use let them self-service install software with tools like SCCM.) And consuming content from the internet (web pages, downloads, email attachments) with admin rights is a great way to end up with malware installed.
Hi Alex – the method described in this article should do exactly what you want. A user is only a member of the administrators group while they are logged into a specific machine.
Reposting the script:
http://pastebin.com/zSq3TGF3
If someone want to translate and document the script, creating a blog post in english, please send an email at antitese.br[at]gmail and I can give more details about the script…
antítese
Please, can you re-post this script? it deleted on pastebin ((( i’am really interesting in it, whant to look on this script 🙂
Hi!
Excellent post!
There are only 2 problems with this approach:
1- It deletes every domain user that are members of the local administrator group; If in the past you added a user as a local administrator you will have problems using this method.
2- It doesn’t delete local users that are members of the local administrator group. Well, I guess it should delete EVERYBODY or NOBODY, it is deleting domain users but not local users from the local admins group.
Personally I use the “MEMBER OF” trick to manage local administrator users.
Thanks.
Vinicius
Thank you! You are right about the potential downsides. Like most things in Group Policy, we are given multiple ways to accomplish something and they each only do 90% of what we need. 🙂
In our environment, we use a powershell script that loads a csv file with associations of user, computer, start time and end time Of each local admin account. Since our users usually use the same computer and ~50 out 16k have admin rights , it works great for us. Our script also remove all local admins if last logon is greater than x days.
But I think I’ll use your method for adding the IT staff as local admin of their own division computers..
If you get the chance, post that script – I would be interested in it.
Well, I hope you can understand the script — it’s really messy at some points 🙂
Since the script runs on clients, we need to make sure it’s compatible with all powershell versions, so we use ADSI instead of ADModule.
http://pastebin.com/Vr95zyWL
Let me know your thoughts. Maybe I’ll document/rewrite script and make it avaliable on github.
It looks good to me! Do you have a lot of older clients that don’t support the ad module?