Group Policy: Creating A Standard Local Admin Account

Much has been covered thus far in the Group Policy series:

• How to create a new policy
• How to link a GP to an OU
• How to navigate the GP management GUI
• Additional remediation technics.

This post will detail the setup of a group policy that will create a standard local admin account. The inherent value addresses the support need of a user who is unable to login and/or resolving issues with the domain based login thus utilizing a local admin to troubleshoot. Having a local admin account in a domain based scenario to allow entry level techs a degree of admin control without giving them domain admin permissions is a great enabler to alleviate tasks from senior administrators.

Steps to enable said local admin account are as follows:

1. Launch Group Policy management
    

2. Navigate through the structure to locate the “Computers” OU
    

3. Right click Computers and select Create a GPO in this domain, and Link it here…
    
    

4. In the new pop-up window give the GP a name (be descriptive – it will make it much easier to find later). You can use a starter GP if you have any configured

   
    

5. Now you have to edit the policy.

   Note: This only applies if you have an existing group policy (skip to step 6 if this is the first policy you create) if you have an existing policy you can use it as a starting place to point you in the right direction. As you can see in the screen shot below which is taken from the “Settings” tab of the GP where we are heading is in “Computer Configuration -> “Preferences” -> “Control Panel Settings” -> “Local Users and Groups”
    

    

6. Right click on the GP and select Edit
    

7. Navigate to “Computer Configuration” -> “Control Panel Settings” -> “Local Users and Groups”

   
    

8. Right click in the Local Users and Groups screen and select “New”-> “Local User”

   
    

9. From here you create the user account just like you would in AD. The interface looks a little different from AD but the options are still similar. The only two new items here is the option to rename the account and that it relates directly to Group Policy
    

    

10. The first line in the above screen shot shows that we are going to “Update” the existing policy. If you click on the drop down you will see that there are 4 options. “Create” and “Delete” are fairly straight forward so I will not explain them. The “Replace” action is more suited to files. Think of this as remove and replace. The “Update” action is used to change the properties. This is what we will do here since the account already exists (in my case – you may most likely want to create one however). Later on (after the policy has been applied) you can change this from a “Create” action to an “Update” action.

    
     

11. Now comes the fun part. Sitting around and waiting for the policy to update. No time for waiting? Log onto the local machine to which you wish to push the policy and open a command prompt. Type the following command: “GPUPDATE /FORCE”

    

Once completed, a standard local admin account is now successfully created allowing a entry level tech to login to any PC on the domain.

Comments

• Anonymous
  December 10, 2014
  The use of the preferences for password is not really a good idea due to a vulnerability.
  http://blogs.technet.com/b/srd/archive/2014/05/13/ms14-025-an-update-for-group-policy-preferences.aspx
• Anonymous
  December 10, 2014
  Hey Garth nice post :p
  
  We used to used this in schools but since May 2014 it was patched to not allow this anymore.
  
  http://blogs.technet.com/b/srd/archive/2014/05/13/ms14-025-an-update-for-group-policy-preferences.aspx
  
• Anonymous
  December 10, 2014
  Thank you very much for raising the concern. I was not aware of the exploit at the time of writing the article. I have read the provided links and they do mention that using domain credentials is a bad idea. I know that is not the best option especially now that there is a known exploit when using preferences. I have been look at alternate ways of ensuring standardization and this is what I found:
  The new recommendation is to push a policy which contains a list of domain accounts that are to be given local admin permissions. They do not recommend pushing the passwords as those are easy to exploit so here is a work around
  
  1) Create a local admin group in AD
  2) Add the needed users to the group
  3) Create a new group policy to push the policy
  4) Expand “Computer Configuration” -> “Policies” -> “Windows Settings “ -> “Security Settings” -> “Restricted Groups”
  5) In the “Add Groups” interface you add the group you created in steps 1 and 2 above
  6) Attach this policy to the computers OU
  
  This way you centrally control the local admins via the domain-based Active Directory and leverage that security. Quite an interesting way to spin it and I am pretty sure that it is far more secure. Thank you again for raising the concern.
  
  
  • Anonymous
    May 03, 2017
    Hi, I am new to this topic and maybe you can answer me one question to the new workaround via local admin group.When adding the AD group to the computers local admins, will I be able to log into these accounts when there are problems on the local computer while connecting to the DomainController?We once had the problem that we had to rejoin a computer to the domain. Therefore we needed a "real" local admin account which is not part of the domain to login. Does this workaround handle this?
• Anonymous
  February 06, 2017
  The comment has been removed