Group Policy: Creating A Standard Local Admin Account


Windows_Server_Group_Policy
 
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…
     
    clip_image002
     
  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
     
    clip_image004
     
  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”

     
    clip_image006

     
  6. Right click on the GP and select Edit
     
  7. Navigate to “Computer Configuration” -> “Control Panel Settings” -> “Local Users and Groups”
     
    clip_image008
     
  8. Right click in the Local Users and Groups screen and select “New”-> “Local User”
     
    clip_image010
     
  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
     
    clip_image012

     
  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.
     
    clip_image014
     
  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”
     
    clip_image016

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 (4)

  1. Style says:

    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

  2. Bawx27 says:

    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

  3. 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.

  4. Lexus Sai Gon says:

    I savor, cause I discovered just what I was looking
    for. You have ended my 4 day lengthy hunt! God Bless you man. Have a
    nice day. Bye

Skip to main content