Partager via

Managing Client Machine Local Admin Rights

  • Article

 

Restricted Groups

Restricted Groups! Argh! We have all done this at least once: Setup a restricted group thinking it would add to the local administrators group of the local machines for the users only to find that the policy removes the existing members and replaces them with the users defined by the policy. This is great if every machine has same set of requirements for who should be local administrators. This is seldom true.

Wouldn't it be nice for the user to be able to call the help desk to request permission to be local admin of their machine and with proper approval have the help desk place that user in the local administrators without adding them to every machine (restricted group policy) and without having to modify a GPO AND without manually adding them to the local administrators group? Wouldn't it be nice to not have run on sentences?

So good news for you.  There is a way to manage the local administrator groups on local machines with GPO Preferences. What is really COOL here is that you do not need a Windows 2008 or a 2008 R2 domain controller. YES, you can do this in a Windows 2003 forest/domain with no Windows 2008 or 2008 R2 domain controllers. Ah, but I have a mix of XP and Windows 7 clients, you say. This works from XP SP2 (not supported) and up.

It takes a few steps to setup, but it gives granular control to give a specific user, users, or groups administrative rights  to a specific computer. The following is the framework needed to accomplish this task.

Framework needed:

  1. Windows 2003 or greater forest. Really! Yes, really.
  1. GPO Policy needs to be managed from Windows 7/2008 R2 or Vista/2008 (Does not have to be a domain controller). Once you move to Windows 7/2008 R2, do not use Vista or 2008 or 2003/XP to manage policies.
  2. You will need a group name for each machine account that you want to manage.
    1. For example a machine name CIN1234W7 would also have a global group or domain local group named "CIN1234W7 - Admins." Or something of that nature.
    1. The cool part here is if the group does not exist, the machine will not apply the policy. No harm done.
    2. The Help Desk can use this group add a user for local administrative access. And can likewise remove the user from the group when local administrative access is no longer needed.
  1. One GPO applied on an OU above the machine accounts
  1. For Windows XP, the Client Side Extensions for preferences needs to be applied. This will work for XP SP2 and above.
    1. Client side extension: www.microsoft.com/download/en/details.aspx?displaylang=en&id=3628
    1. Look here for MS Support Policies: support.microsoft.com/lifecycle

Here are three GPO choices to manage local administrative access:

  1. Use restricted groups - old method not granular and applies to many machines
    1. This is the old school method and is more like a authoritarian rule that says this is what everybody gets. You could make this a little granular by creating multiple GPOs linked to each OU but any changes to group membership would require a GPO change that affects all machines under this policy.
  1. Use preferences with a form of restricted groups (most control)
    1. May not scale to larger environments
    2. However, not needed to be made a global policy across all machines
    3. This clears current membership and populates it as restricted groups would do.
    4. Allows Help Desk to add to the local administrators with a simple group membership change
  1. Use only one preference setting (only adds to existing groups)
    1. Similar to the 2nd choice, but this only adds to the existing members and does not remove any members. So if the build process is adding groups that need local administrative access (and those groups will never change - ha ha), then this would work.
    2. If the groups change you could always use choice 1 or 2 to clean them out.

So with all that up front, let's sort of start over and redefine the problem and solution.

Problem:

Provide consistent set of support engineers local administrative rights and also on request, temporarily (or long term), grant specific user or groups local administrative rights. Without impacting all machines under the policy.

Solution:

Group Policy Preferences. Computer Configuration/Control Panel Settings/Local Users and Groups and add two new settings.

clip_image001

This policy above is shown completed after the two steps below.

Step 1: Define standard local admins that should be on the workstations.  This is the same as the restricted group you are familiar with.  To get the dialog box below create a new policy and navigate to the “Local Users and Groups” under the Preferences settings for Computer Configuration.  Then in the window to the right, Right Click and choose New: Local Group and complete as shown below. Take note of the two check boxes, we will be doing something different for the next step.

clip_image002

This list of Members are the members that should always have local admin rights.  Note both Delete All check boxes are checked.  This makes it work like the restricted groups that you are used to.  So to add the flexibility of adding a single user to the local admin you need to add the second group which is the dialog box below.

Step 2:  Add a specific domain group to the local admins.

Same steps as above with in the same policy add another group. Note the "Delete all…" check boxes are not checked.

clip_image003

This above MEMBER is “%DomainName%\%ComputerName - Administrators”   Without the quotes. This is a global group (could be domain local) but that group does not need to exist unless you want to grant additional users admin rights.  If it does not exist then the policy will ignore it.  If the group exists then those in the group are added to the local admins.  Using Environment Variables %ComputerName% gives you the granular control you need. Want a list of available environment variables? After clicking the Add button press F3 to see a list of available environment variables.

clip_image004

It is important the order of adding the two "local group" settings. If you reverse them, then the result will only be the members of the setting that has the "delete all…" boxes checked since it would be the last one processed.

Once this is setup let’s say a user named Joe User needs "Administrative" access to his local computer named LTCincy001.  The steps to grant him admin rights are to create a group in AD named “LTCcncy001 - Administrators” and put Joe User in it.  That’s it.  A GPO refresh will add him to the local administrators without impacting the other computer local administrator group memberships.  GPupdate /force will do the trick.

So you could pre-create all, some, or none of these groups with no members and delegate permissions to manage the group membership if you want to control it that way. There are many possibilities.

Hopefully, this gets some of your creative minds thinking and make you want to dive into group policy preferences a little deeper.

<theEnd>

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    I feel like I left AdamC and SebastienD without response. I should check this blog post once in a while. I don't review this blog much because I moved to http://blogs.technet.com/askpfeplat and post with several other Microsoft Engineers. Adam: I like your method and it is shorter - just realize it gives access to all machines. However, if you use the group as intended and only make the user temporary, it is better than having domain users as the group with local admin rights. Sebastien: I love the variables as well and like the F3 key that displays the list. Would have been nice if there was a button for us to show the list. But for now, we know it available

  • Anonymous
    January 01, 2003
    @Kevin - if you are still checking this here is a short response for you. I would double check that you followed all the steps, the policy is actually applying to the machines, etc. If no GPPs are applying and they were XP, I would look at client side extensions for the client - Though XP is long beyond support.

  • Anonymous
    September 29, 2011
    This is a great article, thank you for the detailed steps. If I were to put this in though, I would want to provide the user with a different account to ensure the user is not logged on with local admin rights, the second account would provide a way of elevating the rights to gain the access, instead of remaining elevated at every logon. A similar approach would be to provide a local account with admin rights for this elevation instead. Thanks again.

  • Anonymous
    April 04, 2013
    The comment has been removed

  • Anonymous
    April 23, 2013
    Great article! I was right about to implement something myself for this very purpose to be able to combine restricted groups (members method) with the possibility to grant per user / per PC admin access. I was totally unaware of the possibility to use variables in there. In two words: awesome, thanks!

  • Anonymous
    August 21, 2014
    This is absolutely great. Thanks again Doug. It was a pleasure working with you.

  • Anonymous
    September 17, 2014
    Hello,

    I am using the "%DomainName%%ComputerName% Administrators" variable in my GPP. I have a global Group named "DOMAINCOMPUTERNAME Administrators" in Active Directory. When I run gpupdateforce, all the other GPP settings are applied properly, but the configuration containing the variable is never applied. I have also tried DOMAIN%ComputerName% Administrators in the GPP with no luck? Any ideas? I have never had luck applying any GPP that is using a variable.

    Thanks.