Simple measures for more security in AD (Part 4): Local administrators

In the third part of the article series I covered LAPS for servers and clients in the article "Simple measures for more security in AD". Admittedly: The LAPS article was written some time ago, but the topic has not been forgotten. That is why there is now a new article on "Simple measures for more security in AD". This fourth part now deals with local administrators on AD computers.

First of all, the background: The topic of "local admins" seems to have picked up speed again and many companies have switched to LAPS and Admin Tiers and have perhaps (hopefully) already implemented it.

In almost every environment, however, a user needs local administrator rights from time to time, as admin rights are required even to install a printer. However, users do not normally need admin rights permanently, but only for a limited period of time, for example to install a new printer. If LAPS has already been implemented, you could now give the user access to LAPS so that the user can request the password for the local administrator password and use it for certain actions. In this case, however, the user could repeatedly request the local administrator password and use it for any actions and also add their own user account to the local administrator group. Giving the user access to LAPS therefore involves a certain risk.

However, there is a possible solution to this problem: you can allow user accounts only temporary admin access. This means that a user only receives admin rights for a limited period of time, can install a new printer, for example, and loses admin rights again after a certain period of time.

This article is about granting users only temporary admin rights and keeping the local "Administrators" group on the clients "clean". The prerequisites for this are easy to implement, in principle the AD itself takes care of the temporary group membership, only when adding a user you have to be careful.

Requirements for temporary administrators

In order for user accounts to be temporarily added to groups, the overall structure and domain function level must correspond to "Windows Server 2016":

All domain controllers within the overall structure must therefore use at least Windows Server 2016 as the operating system.

Zusätzlich muss das „Privileged Access Management Feature“ aktiviert werden, dies kann mit folgendem Befehl durchgeführt werden:

Bei Gesamtstrukturen, welche direkt mit Windows Server 2016 installiert wurden, ist der oben genannte Befehl nicht erforderlich, das „Privileged Access Management Feature“ ist dort bereits aktiviert.

These are all the prerequisites.

Administrators Create groups for computers

So that administrative authorizations can be controlled via AD groups, each computer requires its own group in the Active Directory. A new group is therefore created for each computer, as shown here in this example:

It is a good idea to put the computer name in front of the group so that you can quickly find the groups in AD to which you want to add the user accounts later. It also makes sense to save the groups for local admin rights in a separate OU, as this also makes it easier to find them again and automate the process. Using the AD search function, you can quickly find the corresponding group for the computer.

Normally, however, you don't want to manually create the corresponding group for each computer, and you also have to remember to delete a corresponding group again when the computer is removed from AD. Without a bit of automation, this quickly ends in chaos.

I have also prepared a small PowerShell script for this, which can be executed cyclically via Task Scheduler. Only the first 2 lines in the script need to be adapted:

• $ComputerOU = DN to the OU where the computer accounts are located
• $GroupOU = DN to the OU where the groups are to be created
• $GroupSuffix = Suffix which is appended to the group name (optional)

The script creates a corresponding group for each computer account within the specified OU (CL1_LocalAdmins, as in the example). If a computer is no longer found in the AD, the corresponding group is also deleted. The script can be executed daily (or more frequently) via Task Scheduler, for example. The script can be downloaded here:

GPO for adding admin groups to local administrator group

However, nobody wants to manually add the created Active Directory groups to the local administrator group of the clients and servers. This can therefore also be automated using a group policy. As soon as the admin groups for the computers have been created in AD (or are created by the script), a GPO can be created which adds the respective AD group to the local admin group of the client.

To make it a little clearer: In my lab I have 3 clients (PC1, PC2 and PC3), the script linked above has created a group in AD for each computer (PC1_LocalAdmins, PC2_LocalAdmins and PC3_LocalAdmins):

The group "PC1_LocalAdmins" is now to be added to the local group "Administrators" via group policy on the PC1. A group policy is now not required for each client, but only one GPO for all clients. It therefore does not matter whether there are 3, 50 or thousands of clients in AD, one GPO is sufficient.

A new empty group policy is therefore created and the "User configuration settings deactivated":

A new entry for a local group can now be added under the "Local users and groups" setting:

"Update" is selected as the action and "Administrators (integrated)" is selected as the group name. The two checkboxes "Delete all member users" and "Delete all member groups" keep the local administrator group clean and remove all existing authorizations (see note at the end of the section). The "Domain Admins" can now be added as members first, so you still have a foot in the door (due to the restrictions of the Admin Tiers, Domain Admins are not allowed to log on to clients, a corresponding GPO should prevent this):

To ensure that the admin groups created from the AD are also added to the local group, an additional group member can be added by specifying a variable. In this case, the group name is made up of the name of the computer and the suffix "_LocalAdmins". The variable "%ComputerName%" is used for the computer name. The entry for the local group member in my Lab is thus:

• FRANKYSWEBLAB\%ComputerName%_LocalAdmins

There are now two members in the properties of the local "Administrators" group:

The new group policy must now be linked to the corresponding OUs:

Nachdem die Richtlinie auf einem Client angewendet wurde, sieht es in der lokalen Gruppe “Administratoren” nun wie folgt aus (der Client im Beispiel heißt hier CL1, daher auch der der Name der AD Gruppe CL1_LocalAdmins“):

You can now conveniently manage local admin authorizations via the corresponding groups in AD. Users who are to receive admin authorizations no longer have to be added locally to the administrator group, but are simply added to the corresponding AD group. Incidentally, this also solves the problem of orphaned SIDs in local groups. In this case, however, the users would be statically assigned to the groups, temporary memberships work slightly differently, this is described in the next section.

Note: The checkboxes for "Delete all member users" and "Delete all member groups" can usually be set quite painlessly on clients, where users may then complain that software can no longer be installed: Just as well, that's one of the aims of this concept. On servers, you have to be a little more careful here, as the local admin group often contains service accounts that are required for services to function (e.g. Exchange Server). For servers, you could therefore leave out the two checkboxes and clean up the groups manually or via script; this is relatively easy to do via PowerShell. Using WMI and PowerShell, you could first read out the members of the local admin group and then add them to the AD group, only then is the GPO activated. The same applies to clients, of course. I have a script at hand, but it would have to be heavily customized to your own environment, so I will not publish it here in general. If you are interested, just send me an e-mail and I will be happy to make it available, but as already mentioned, it still needs to be customized.

Temporary admin authorizations

The preparations for temporary admin authorizations are now complete. However, there is a small hurdle that makes assigning temporary admin permissions a little complicated: Temporarily assigning a user to a group only works via PowerShell (if you don't want to use an Identity Manager right away).

Temporarily assigning a user to a group works via PowerShell with the following commands:

The above command can be used to add a user to a group for 60 minutes. After the 60 minutes have expired, the account is automatically removed from the group.

Alternatively, you can use PowerShell to create a small GUI that does the work for you, here is an example:

This small script can also be downloaded here:

I have created the script with PowerShell Studio, the corresponding project file is included in the download. So if you want, you can customize the script according to your own requirements. The script requires the Active Directory module for the Powershell and the DLL "CubicOrange.Windows.Forms.ActiveDirectory.dll", which provides the selection dialog of the AD. The DLL is also included in the archive.

Tip: If users are to have temporary admin rights on a client, it is advisable to use a separate user. Example: If user "Frank" is logged on to his PC with the user name "Frank", then the user "Frank" does not receive local admin rights, but a separate user "Frank_Admin" receives the temporary admin authorization. The user "Frank_Admin" is therefore added to the computer's admin group instead of the user "Frank". The user "Frank" therefore does not have to log off from his PC, but can use the user "Frank_Admin" when Windows prompts that administrative rights are required.