Best Practice: How to use Group Policy Preferences to Secure Local Administrator Groups
One problem I see all the time is IT administrator never being able to control who is a local administrator of any particular computer. The problem is that when you give someone local admin access to a computer (because they legitimately need it) you cant stop them from giving admin access to someone else on the same computer. When this does happen it is also its almost impossible to discover as you have to run a query every computer to see who is in the local admin group and then figure out which account should be a member. Once solution to this is of course following Microsoft best practice and not give your users local admin access to their PC or Server and in an utopian environment this would be possible but we all live in the real world where managers have admin access to their PC’s and developers are allowed to install any software they want. So how do you give a users full admin access to a computer but stop them from adding more people to the local admin group on a computer? Use Group Policy Preference of course.
But first a bit of History… Since Group Polices were first introduced with Windows 2000 there was an setting called “Restricted Groups” which allows you to control the membership of a group. This option had two modes one called “Members” option which I also call the “Iron Fist” mode and the other “Members Of” option which is much gentler. The “Members” option removes any groups or users that are not explicitly specified and the “Members Of” option just adds a specific group which out removing any existing groups. The “Members” option was really good at cleaning up those rogue members of the local admin group but its was also really hard to setup as you had to have a new group policy every time you wanted a different list of members in local group on a computer. The “Members Of” option was a lot easier to maintain as you could layer multiple group policies on top of each other but this normally resulted in just adding another layer of group to the pile of groups that were already in the local administrators group. The other problem was the “Members” option would override the “Members Of” option so there was really no way of mixing the two modes.
BUT… Group Policy Preferences can use Variables which enabled you to be very extremely granular in controlling you local admin group while still having “Iron Fist” control. Muuhhaaaahahahahah!!!
How do I setup a restricted local administrator group?
The following steps will need to be applied to a GPO that is applied to the computer objects you want to control the local administrator groups. Note: You must make sure you don’t have any other Group Policy “Restricted Groups” settings applied to your computers as they will always override the group policy preferences settings.
Step 1. Open the Group Policy Management Consol and edit the group policy that is applied to the scope of computers that you want to control.
Step 2. Go to the Computer Configuration > Preferences > Control Panel Settings > Local User and Groups option (see Image 1.).
Image 1. Local User and Group
Step 3. Now click on Actions > New > Local Group
Step 4. Now you will be need to select “Administrators (built-in)” from the group name as this always selects the built-in administrators group even if you have renamed it to obfuscate the name of the admin account.
Step 5. Tick both “Delete all member users” and “Delete all member groups”. These two options will automatically remove any users or groups that are not explicitly being added to the group. You only need to do this on item number 1 in the list of settings as that setting will be processed last.
Step 6. Now you will need to make sure you have added back in the Domain Admin’s and Local Administrator groups so that you don’t totally lock yourself out of the computer. To do this click the “Add…” button to bring up the “Local Group Member” dialogue box (see Image 2)
Image 2. Local Group Member
Step 7. Now type “BuiltIn\Administrator” in the Name field and click OK (see Image 3.)
Note: The image below is wrong… it should be “BUILTIN\Administrator”
Image 3. Local Administrators group added to the local administrators group
Step 8. You should also add “DOMAINNAME\Domain Admins” as it is a good practice to have the DA account as a member of the local admin group on all computers in the domain. To do this we are going to use the DomainName variables. Click “Add…” again and now click in the “Name:” text field and then press F3. This will now bring up the “Select Variable” dialogue box (See Image 4.). Click on the “DomainName” field and press “Select” and then “OK”. (alternatively you could type %DomainName% in the name field and just press OK.)
Note: The image below is also wrong… The bottom image should be “BUILTIN\Administrator”
Image 4. Selecting the DomainName Variable
You should now see the following which will restrict the local administrator group to only have the Domain Admins and the local administrator.
Note: The image below is wrong. It should be “BUILTIN\Administrator”
Image 5. Basic local administration group setting
So what you as? I can do this already with the “Restricted Groups” Group Policy setting. Well only having the local Administrator and Domain Admin’s in the local admin group is not not much use unless you are willing to give everyone the local admin password or give them all Domain Admin’s privileges (Like that ever happens) when ever they needed admin access. Well again this is where Group Policy Preferences can help.
How to add individuals to a single computer?
Now we are going to go thorough how to add a uniquely named domain group to the local administrators group without having to set up multiple group policies objects. This scenario is very helpful if you want to grant a single user or group local administrators access on computer but still ensure that no other users or groups can be added without explicitly being approved. In the steps below the computer name is DESKTOP01 and the domain name is CONTOSO, we want to add the group “CONTOSO\DESKTOP01 Administrators” to the local administrator group but we also want the same to happen on DESKTOP02, DESKTOP03 and so on, each with their own uniquely named group based on the computer name.
Update: Having a unique group for each computer allows you to easily grant permission to for a single users to a single computer as there is a one to one mapping of domain groups to local administrator groups.
Step 9. Now go back and repeat steps 3 to 6 until you get to the Local Group Member dialogue box again (see Image 6.).
Note: This creates a second local administrator group entry in the list to work around an issue.
Image 6. Add Local Group Member
Step 10. Type “%DomainName%\%ComputerName% Administrators” in the Name text field and click “OK” (Image 7.)
Image 7. Configuration to automatically unique group to local administrators group
Now this will now automatically add a domain group called “DOMAINNAME\COMPUTERNAME Administrators” to the local administrators group on the computer to which the policy is applied and your group policy should look like Image 8.
Image 8. Two local administrator group settings
Update: There are two separate local administrator group setting in the policy, the first one is the setting you see in image 5 and second one is the setting you can see in image 7.
However the “CONTOSO\DESKTOP01 Administrators” group will only be added to the local administrators group on the computer DESKTOP01 if that group is already exists. Therefore you do not need to create the group until the need arises to add an individual user or group to just a single computer.
Update: This policy will not create the group in your Active Directory called “DOMAINNAME\COMPUTERNAME Administrators” and you don’t have to create it unless you want to use it to grant permission to the computer. Once you have created the group you can then add a single user to the domain group… or multiple user accounts and groups. The other advantage of having this domain group is that it is the only place where you can grant admin access to the computer without it being automatically removed there fore it makes auditing who is a local administrator on a workstation much easier as you only have to audit the domain groups. This means that you can even report on who has access to the computer when the computer isn’t even connected to the domain.
This group policy setting combined with the other setting made earlier (see Image 5.) will mean that the local administrator group on the computer DESKTOP01 in the CONTOSO domain will have the following members automatically added to the group:
- CONTOSO\Domain Admins
- DESKTOP01\Administrator
- CONTOSO\DESKTOP01 Administrators
But ANY other users or groups will be automatically removed after the next group policy refresh. This does mean there is a slight window of opportunity for someone to slip in an un-authorised account into the local administrators group but they will get removed at the next policy update.
Side Note: I have found that users almost never complain that they cant add un-authorised user to the local admin account on computer. Go figure… 
AWSOME!!!! I hear you say… but wait there is more…
How do I add additional broader groups to the local administrators group?
Now that you are able to granuarlly add a single user or group to the local administrators group on a computer you might run into problems id you have more than a 1000 computers due to AD Token Bloat Issues . So to get around this we can setup some more broadly applied administrator groups to the computer that will give admin access to only a subset of computers such as all workstations or only the SQL Servers in your organisation.
Workstations Admin Groups
To apply a Workstation administrators group to the local administrators group on all workstations make sure you have a group policy only targeted to your workstations. This is normally pretty easy as most companies isolate their workstations computer accounts to one (or a select) number of Organisational Unit.
Step 11. Go back and repeat steps 6 and 7 but this time add the group “%DomainName%”\Workstations Administrators” in the name field. This will added the additional group “CONTOSO\Workstation Administrators” to the local admin group on all the workstations in your domain which will allow you to easily add all the Desktop Administrators in your organisation access to all the workstations without having to give them the local admin password or domain admin’s privileges.
Server Role Admin Groups
It gets a little tricker when you want to grant access to a server based on its role as server are sometime configured for multiple roles. So in these steps we are going to automatically added a domain group called “CONTOSO\SQL Server Administrators” to all the servers you have that have SQL Server installed on them. This will be very handy to making sure SQL service accounts or database administrators have admin access to all the servers that have Microsoft SQL Server installed. You can however make multiple version of these admin group for other roles (e.g. Exchange,SCCM,ISA) you just need to know what the best way to target the setting.
Step 12. First make sure you are editing a group policy that is applied to all your servers in your organisation.
Step 13. Repeat Step 9 and 10 and then we open the properties of the new policy setting and specify the group but this time we type “%DomainName%\SQL Server Administrators” in the name field.
Step 14. Click on the “Common” tab and then tick “Item Level Targeting” and click the “Targeting…” button.
Step 15. Click on the “New Item” in the menu bar and select the option you want to use to target all the SQL servers in your organisation and select the “File Match” option to look in the Program Files folder and see if a sub-folder exists called “Microsoft SQL Servers” (See Image 8). This is normally true for any server that has Microsoft SQL Server installed and so it will then automatically apply the SQL Server Admin group to that server if it was installed.
Note: In this example we tested that the “Microsoft SQL Server” folder exists but we could also make rule to test for the existence of a particular file or registry key.
Image 8. Testing to see if Microsoft SQL Server is installed.
Now any computer that SQL Server, MSDE or SQL Express installed will get the group “CONTOSO\SQL Server Administrators” automatically added to the local admin group.
This nice thing about this is that if SQL is installed on the server at some point in the future the SQL Admin group will be added automatically at the next group policy refresh without you having to do a thing.
Finally.. now you have tight control of the local administrator groups on all the computers in your domain it is now important to monitor and secure the domain groups that are being added to the local administrator groups as they now control who has admin access to all your computers. But I will save how to do that for another blog post…
Hi Alan, it’s a great article and we have already implemented this and worked a treat, till recently. This solution worked fine for XP machines. Recently we extended the same to WIndows 7 PCs. What we were noticing was that after a few days, the %comuptername%administrators group was getting stripped off the Builtin admin group of the PCs. Found a hotfix for that issue KB976399, which appeared to fix the issue. But it has come back, where people regularly loose access. What we do, is login as admin, force the gpupdate and then it seems to work. Is there an issue with WIndows 7 that we need to address. Will be happy to hear from you, as it is biting us hard now
Cheers
Thanks for the feedback… not that i have heard of… just make sure that the %computername% administrators group is in a seperate configuration item and not with other settings on the group.
Hi Alan,
Excellent article, a query if I may.
The local group will be created on the local computer once the preference applies, then will become active once an AD group is created with the accounts populated? Is this thinking correct. If so, you are my hero!
Regards
Stuart
@Stuart The local admin group is already created. If the domain group is not created then it will only give a warning in the event log. If the group is then created in AD it will be added at the next policy refresh on that computer. Hope it helps
Hi Alan,
Yes, I understand, but also i have now had chance to test, it works like a charm. Thanks for your help.
Can i ask how you cross domain groups from parent domains, to add them to child domains. I used to do this with restricted groups, but i believe that this can cause issues when applying local groups preference. Any help would be much appreciated.
Regards
Stuart
just specify the domain domain when adding it to the local group… .eg. DOMAINNAME\GROUPNAME
Hi Alan,
Do I need to specify this in the form of a variable, or actually specifying the name & group name?
Thanks Again.
Stuart
Hi Alan,
Quick query – step 7 – you seem to be adding the Builtin\Administrators group to the local Administrators group. Surely it should be a case of adding the Builtin\Administrator user account to the local Administrators group? By default the local Administrator user account should be in the local Administrators security group. Or am I missing something?
Cheers,
Rich.
Hi
I’m having problem to make WinXP to follow any GPO of this type (adding/updating/delete) local user accounts.
No problem with win7
Is there a limitation to OS version higher than?
any extra action required with WinXP?
On Win7 all I need to do is gpupdate /force
Kjell
Q1: Have you installed the Group Policy Client Side extentions…
Thanks Alan
thats it.
A combination of afraid of testing on our live WinXP, and to eager to run the testings, I forgot to add the extra stuff from Windows Update where the client side extensions are.
thanks for an excellent article
another detail.
when adding a GPO, test it, remove it, redo another, test it, I know getting half of it, Only BuiltIn\Administrators remains in my Local Admin Group, All other are always removed.
Do I have to reset the GPO handling in any way to get back on square 1 ? (so to speak)
Rgds
Kjell
Preference do not revert the configuration when you remove the settings. Therefore if you remove the policy the affect will be everything will stay as it was last configured… NOT revert back to original.
what ment was; I followed your example “Restricted Local Admin Group” by adding 2 modifications, and it worked just like described, excellent. then I removed the GPO, made a couple of other settings on the same thema, when I was done with my labb-work I wanted to re-do the original “Restricted Local Admin” as per your example. The result now is different; Only BuiltIn\Administrator makes it through a gpupdate /force, and that’s it.
The Domain\Domain Admins are being removed now from the local machine, I’ve re-created the GPO 2-3 times already following your description trying to see where I type wrong but I can’t make the GPO kick in correctly.
I will create a new VM and see if that one acts correctly.
Just wanted to check if anyone has seen this behaviour.
Kjell
I have seen that behaviour before if you are trying to add a user or group that does not exist. To work around this make them seperatem items and it should work…
Ok, I will labb on that.
In my case I tried with BuiltIn\Administrator and %DomainName%\Domain Admins just like your example above
Local Admins is making it, but Domain Admins is being removed as if they was not part of the GPO
If I find the workaround i will post here
Kjell
Not sure exactly what I did to fix it.
I noticed that the example stipulates BuiltIn\Administrators and when I think about it, it should be singularis form BuiltIn\Administrator. but, that alone did not fix the problem at once.
anyway; I also removed the BuiltIn\Administrator from the GPO and run gpupdate /force several times adding and removing other users in the GPO in between every gpupdate.
From that moment of removing the local admin everything went back to logical, the local Admin stays in the group event though it’s not part of the GPO declaration, now the group responds correctly.
When I finally added the local Admin to the GPO it’s still acting logical as it did the first time.
but now its in singularis form BuiltIn\Administrator
Kjell
Hi Alan,
Now we have 2 different administrator groups.
Why are we using 2 separate groups such as “Administrators (built-in)” and Administrators? Can we work only on default “Administrators” group?
Thanks.
John
You should only use the “Administrators (Built-in)” group… Not sure how you are getting a second group called “Administrators”…
I am having the same issue. Before I apply the GPO I only have the Local Group Administrators listed in Local Users and Groups. After I apply the GPO I have the Local Group Administrators and Administrators (built-in), and this built in group does not have admin rights.
For the GPO settings I selected Update and picked (instead of using the dropdown) the administrators group.
If I use restricted Groups works correctly and does not create Administrators (built-in).
Hi Allan…I was trying the steps you have provided to add a single or group of users from a domain to the computer’s local admin account. It didnt work….My main goal is to add a group of users from a domain and make them their computer’s local admin (as a part of our reqirements)…any other suggestions please let me know… Prior testing that, I did add a test computer to the “Test OU” and assigned a policy to that Test OU after following the steps mentioned….pls advice…
Things to check…
1. Does the name you are typing match a group that exists…
2. check the event log for warnings.
2. Are you adding multiple groups in the one policy setting… split them onto seperate entries
Feel free to send me an email via the contact form if you have any more detail.
Hi Alan,
Excellent tutorial, however, I did some testing on a laptop and it seems that the Group Membership is not equal to specifying the exact account name: once I applied the policy to a notebook outside the local network (over VPN), I could not successfully elevate my permissions with that account any longer. Is that an expected limitation?
Doug
Hi Doug…
Strange one… At a guese I would say that you may need to have logged on locally at least once for the caching of the credentials to work. Centainly appling the permission via a group you would have to log off and back on again after the setting has applied for the access to become affective.
Alan
Hi Alan,
I just wanted to give you an update on this. The problem I experienced was due to the credentials being cached. Once I log on at the office, my user gets the correct group memberships and things work as expected.
I did experience some additional frustration due to not following your tutorial EXACTLY as you have written it: setting the groups without using %DomainName% or letting the GPP editor specify the exact SID either do not work at all, or cause inconsistent behaviour (some of the GPP applies, some doesn’t).
I really enjoy your website. Thanks a lot for all the great posts, especially the ‘Best Practices’.
Step 7 makes no sense! You should add “BuiltIn\Administrator” and NOT “BuiltIn\Administrators”. Right?
@ThL yes i think you are right… i have update a text and put a note next to the images that are wrong. Thanks.
In my tests of the way Mr. Burchill wrote this up, BuiltIn\Administrators seemed to work just fine, the workstation’s local Administrators group included the user Administrator using only steps 1-8.
I have a part timer working with me. I don’t want him to have domain admin rights but I want him to be a computer administrator so he can do software installs, etc. Using the steps above 1-8 I was able to clean and secure the administrators group on the test computer. Besides builtin\administrators and domainname\administrators I also wanted this one person to be an administrator but it would not add him.
I created a second order group just as described starting in step 9, with only him being added, and it added him. I don’t understand why I had to do that. Any ideas?
@danielkr The second one is need for two reasons…
1. A bug if the group does not exist cause all the actions to fail
2. Group is MUCH better then ading a individual user as you can see the membership on the users account in AD… Otherwise it would be very dificult to audit and control this access, especially if the computer is offline.
Three corrections:
1) “make sure you have added back in the Domain Admin’s and Local Administrator groups” should read “make sure you have added back in the Domain Admins group and local Administrator”
2) “Image 3. Local Administrators group added to the local administrators group” should read “Image 3. Local Administrator added to the local Administrators group”
3) “only having the local Administrator and Domain Admin’s” should read “only having the local Administrator and Domain Admins”
I have just implemented some additional control using group policy preferences on our estate but have used the following method, but seem to be hitting problems with some machines.
A single restriced groups GPO specifying the central domain groups plus the local machine accounts we want to keep across the estate
We then have a number of GP Preference GPO’s which add a addition group. These are both secuirty and WMI filtered so they only target windows XP and certain machines based on group membership.
After initial testing this seemed to work fine, and gave us more granular control, however we get cases where GPP processes but the groups never appear, I have since re-ordered the GPO links so that the GPP additions should take presidence over the restricted groups. But I’m wondering if I should maybe ammend the policies so we just use GPP’s. I will see what happens now the order is correct however
Any thoughts?
Restricted group will take precedence… you will need to remove this setting if the GPP is going to work…
I am trying to setup the SQL example and getting an error of The computer ‘Administrators (built-in)’ preference item in the ‘Computer – SQL DBA Local Admin {88AA58D2-456F-48DC-8195-4B2E3EB8C527}’ Group Policy object did not apply because it failed with error code ’0×80070534 No mapping between account names and security IDs was done.’ This error was suppressed. when i enable the targeting. if I remove the targeting the settings apply correctly. I have tried to replace your example path with %SystemDrive%\Program Files\Microsoft SQL Server and %SystemDrive%\Program Files(x86)\Microsoft SQL Server but that generates the same error. my domain and forest functional settings are 2008 R2 testing this on a win 2008 R2 server.
Sounds like you are trying to add a security group that does not exist… Are you sure the group you are trying to add exists? did you chose it from the group picker button?
If I wanted to give a domain security group access would I also just put that in the Members section of image 5?
I have a couple of new laptops in the office that I haven’t got to deploying yet, and after I did yesterday’s “Patch Tuesday” MS updates, both computers began to hang at user logon with “Applying Group Policy Local Users and Groups policy” (I have verbose messages enabled; I only use the Local Users and Groups policy on new computers not old ones already in the field). They sat for well over 10 minutes and go nowhere. Multiple reboots resulted in the same thing happening over and over again. If I pulled the LAN cable, they could logon okay.
My Google searches turned up no useful results, so I decided to apply all the “Patch Tuesday” patches on my DC and restart it. After that, subsequent reboots on the laptops seemed to be alright, and I did ‘gpupdate /force’ a couple times to make sure they took the policies from scratch. Again it seemed to return to normal behaviour.
This occurrence makes me nervous though – has anyone else experienced this type of behaviour when using GPP Local Users and Groups?
Can we use preferences to add a group from an other forest tol the Local Administrator group. When I am look at Locations I only see the local domain. Trying with “domain\Group” does not work
http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/
Alan,
Thank you for your very educational post.
In your scenario, do we have to create separate gpp for each PC if we want to specify DESKTOPxx Administrators? i.e. gpp1 for adding DESKTOP01 Administrators to DESKTOP01, and gpp2 for adding DESKTOP02 Administrators to DESKTOP02 and so on? Is it possible to create only one gpp, and it adds DESKTOP01 Administrators to DESKTOP01, DESKTOP02 Administrators to DESKTOP02?
Also, your scenario can be achieved by using gp restricted groups, and I cannot see any advantage by using gpp in this instance?
Looking forward to your reply.
I can answer my own questions now.
Firstly, just need to use Item-level targeting, and target computer’s DNS name. This will identify the PC, and is able to add DESKTOP01 Administrators to DESKTOP01, and adding DESKTOP02 Administrators to DESKTOP02
Secondly, using GPP is better than using gp restricted group in this instance. I created local user account(user configuration–preferences–control panel– local users and groups–, then I add this local user account to the builtin-administrators. So I don’t need to create global security group anymore.
This way, I can achieve in one GPP, adding global security group domain admin/desktop admin for all PCs, then target individual necessary PCs to grant them a unique local user account with administrator right.
This works well for big organisations. We need to have control of all PCs. But there are always a few users need admin rights on their own PC.
My experience is this:
We get an error in the event log if we add BUILTIN\Administrator (without the ‘s’) as described in step 7
This is the log entry:
The computer ‘Administrators (built-in)’ preference item in the ‘Win7-EC-Computer-v1.0 {GUID}’ Group Policy object did not apply because it failed with error code ’0x8007056c A new member could not be added to a local group because the member has the wrong account type.’ This error was suppressed.
0x8007056c A new member could not be added to a local group because the member has the wrong account type.
It seems that either of the following is the case: 1) The local admin account can’t be deleted from the Local Admins group or 2) When it tries to add BUILTIN\Administrator, it fails because the account already exists.
When we remove BUILTIN\Administrator from the GPP the error goes away AND the local administrator is NOT removed from the Local Admins group.
Is this anyone else’s experience?
Phil,
YES. This is exactly what we are experiencing.
I would like to stop users from adding the Domain user to the local administrators group of their pc’s. Can this be done with GPO’s?
This method does not STOP them from doing that… however in 2 hours any non-authorised users and groups will be removed. The only way to prevent this from happening it to remove them from the local admin group.