In this post, I would like to explain, what my experiences and solutions for the delegation of local Administrator permissions are. In a Client deployment Scenario, you will often be asked for a solution to provide IT Professionals and maybe also end users with local Administrator permissions. I will point out the most useful solutions which I do prefer.

1. Local Administrator Account
2. Permanent Local Administrator permissions for IT Professional
3. Microsoft Local Administrator Password Solution for spontaneous permission
4. Local Administrator delegation based on group per client

1. Local Administrator Account
Let me point this one out very clear: DO NOT USE THE SAME PASSWORD ON ALL YOUR CLIENTS FOR THE BUILT IN ADMINISTRATOR ACCOUNT!
Phew, sorry for that, but even if you rename the account, never use the same Password on all your clients. I would suggest to set an unknown password, or manage the password with the local administrator password solution from Microsoft (see Chapter 3).
If you’re setting a password known to the IT Department (or someone else), make sure you have implemented a solution to change the password on a regular base, and again set different passwords each client!

2. Permanent Local Administrator permissions for IT Professional
This is nothing special, based on Active Directory, you can create groups, where the Administration Accounts of the IT Department can be added. You can then use Restricted Groups from the Group Policy to add the required groups to the Built-In Administrators group of the client. I would not use the Group Policy Preference for this setting, in some circumstances (like a “gpupdate /force”), the Group Policy preferences might not be executed.

3. Microsoft Local Administrator Password Solution for spontaneous permission
Microsoft has released a handy tool to manage the password of a user Account on the Client, this is very useful in the event of a user without a network connection required to get local Administrator permission. You can manage the Built-In Administrator Account or another Account that you have previously created, the corresponding password will be saved to Active Directory, a Schema Update is mandatory to get the required Attributes. One small hint: If you reinstall a client, make sure to clear the expiration date of the password within the AD, or the client will not create a password on the Account. See this blog for further information about LAPS: LAPS (on dirteam.com).

4.1. Local Administrator delegation based on group per client (With GPP)
But what if you need to grant local Admin permission only to one computer for one user? And you might also want to get easily reported, which client do have Endusers with local Admin rights. This requirement can be achieved with the following solution, and starting with creating a group per client, where a single, or multiple End-users should have admin permission. Make sure that you will name all groups with the same name, except the computer name of course. In this example, my group convention leads me to the following group name:
G-LocalAdmin-%computername%
So in fact, for my computer Rudolph, a group named “G-LocalAdmin-Rudolph” is created:

Create a group for every client which is required to permit local Admin to a user, and you can also use local Groups to nest the global group if you like to.
Now go ahead and open or create a GPO which does apply on the designated clients, navigate to the “Local User and Groups” section, and add a setting for the “Administrators (built-in)”:

Make sure that you select “Update” as Action, as Group Name select “Administrators (built-in)” from the drop down and add the Description, otherwise the Description will be cleared on the clients:

Now it is time to fill the members of the group, click on “Add..” in the lower section of the wizard, and paste your corresponding value into the box. In my case the string is “deheim\G-LocalAdmin-%computername%”, make sure to change this value to your requirements:

When you have added the group, you will have to change the to common and activate the check box at “Remove this item when it is no longer applied”, this ensures together with the Update Action of the GPP that the group will be removed, as soon as the Item-Level targeting is no longer true. Also activate the check box on item-level targeting and click on “Targeting…” afterwards:

In the opened window called Targeting Editor click on “New Item” and select “LDAP Query”, configure the added item by just copy the following query to the filter (&(&(sAMAccountType=805306369)(objectCategory=computer)(objectClass=computer)(|(samAccountName=%computername%$))(managedBy=*)))”. Your targeting editor should then looks like the following picture:

Finish the wizard by click on “OK” twice.
The last step would be to add the created group to the ManagedBy attribute of the client. You can do this through the Active Directory Users and Computers mmc:

Without adding the ManagedBy attribute, the LDAP Query would not be true, and the group will be removed from the local Built-In Administrators group. Please mind, that this not magically will add the group or user from the managedBy attribute, you can add whatever you want to this attribute and the GPP will be triggered.
But you can also easily report all the clients which have given admin permissions to only some of your users.

4.1. Local Administrator delegation based on group per client (With GPO/Restricted Groups)
This is a more robust solution than in 4.1, but also requires a little bit more Effort for implementing. If you are using restricted groups from group Policy, as mentioned in Chapter 2, you might consider issues with configuring the same group (Administrators) with Group Policy Preferences. I would then create a Local Group through group Policy preferences, lets call it “L-Client-LocalAdmin”:

You can use the same Item-Level Targeting as mentioned in 4.1 to apply the settings only to clients which has set the ManagedBy attribute.
If this is done, you have to make sure, that you add this Local Group the restricted group setting of your clients: