One of the issues that data center or even any Windows Administrator has is managing the local administrators group on each and every one of their domain members. There is a lovely security setting that has been around for many years, Restricted Groups, which can be controlled via local security policies of via GPO. This works, but has a few pitfalls as you’ve probably run into once in a while. Keep reading to see how you can solve some of them with Group Policy Preferences.
The Issue with Restricted Groups
Restricted groups work great. They work as designed and that is that. The problem is when your AD and your infrastructure and GPOs start growing it becomes a juggling game and more difficult to control the order of Restricted groups. This is because they are not cumulative, meaning that they don’t add to the current list. The last GPO with a Restricted Group setting applied, wins. The members of that group are used. Period.
Another issue is that anyone with local server access can log onto a machine and update the Local Administrators group as needed. Now it’s time for a security audit and you have to report which machine has what users and groups. This because a pain and tiresome.
Use Group Policy Preferences
Using Group Policy Preferences (GPP) is a great way I’ve found to work in environments I’ve had to deal with. Group Policy Preferences allow you to overwrite, add and control the users base on OU or other targeting items that apply to the computer.
Let’s look at this basic example:
So there is nothing really complex about what you see here. The thing you probably notice is that there are 3 Administrators (built-in) entries. If we used restricted groups, we’re forced to use only one entry as we saw in the Restricted Group section. Another thing that we’ll need to pay attention to use the Order. This is paramount when it comes to how I use this.
The first time I reference a group in the GPP, I set it to delete all existing users and groups. Trust no one. Especially the ones that have local access to your machines. If an admin does do something abnormal and adds a user/group to the local administrators group, the next time Group Policy refreshes, their changes will be removed! If you’re thinking about service accounts etc, just hang in there, I’ll cover it!
Order 1
Here is a screenshot of the Order 1 – Administrators (built-in). Notice that we leave the GPP Action as “Update”. We don’t want to delete the Group or Replace etc. There are options to delete all the members/groups. There is no item level targeting. So if we apply this GPO at the top of the domain, every computer it applies to, we will remove all the current existing users and groups and then we will add the 4 groups below. At this point we’ve just deleted all of our service accounts! Uh oh, so be aware! I’ll cover how we can handle that in a little bit.
Tip –I also copy the Administrators group description and paste it into the Description field, prefixed with GPP. This shows me when I look on a local computer (say via Computer Management), I can easily see that this Administrators group was modified by the GPP.
Order 2
Now when we move to the second entry Order 2 – Administrators (built-in), we change it up a little. Now we can start customizing. Order 1 is all about specifying the high level enterprise support groups for the entire domain. You’ll see below, everything looks like Updating and we DO NOT delete the users/groups. This leaves all the members from Order 1 and we will add 2 more groups, in this case Help Desk groups. Why not add them into the Order 1? Well this time we have item level targeting. Let’s look at the common tab.
Now this is where we really take advantage of the Group Policy Preferences Item level targeting. This is the magic! In this case, we are only going to add the Level 1 and Level 2 Help desk groups as Local Administrators if the computer that is applying this GPO is in the Workstations OU. This means that Level 1 and Level 2 Help desk can log on and help with user issues. Remember all the users in Order 1 will also be here too!
Order 3
This is a whole new group together. In this example it’s the Remote Desktop Users (built-in) group. We are going to allow the Level 2 Help Desk members to remote desktop onto any of our servers. This will allow them to help give us better troubleshooting information or help them in solving any of their tickets.
Order 4
I consider this a special case. There are a few servers in the organization that should have restricted access. This is for servers such as the Certificate Servers. These special cases should be applied at the end, because like Order 1, they will delete all the members from the Administrators group and add only the specified ones in the Member list. This one is also targeted at a specific OU for the Certificate Servers.
Handling Server Accounts
This can honestly be the pain of using the GPP, but it also centralizes everything into AD Group Memberships. This way when an audit is required, you can easily query the group memberships for each machine. On purpose, I hide a group from you in Order 1. Let me scroll down in the members list and show you another screenshot.
Look at that. I also add “GAG – Local Admins %ComputerName%. Here is the leg work. If you have a service account or specific users that must be added to specific machines, follow the following steps. For this example, let’s pretend that we have to allow two special service accounts svc_service1 and svc_service2 to have local administrator permission on SERVER99.
- Create an AD Group named: GAG – Local Admins SERVER99
- Add user: svc_service1 to AD Group GAG – Local Admins SERVER99
- Add user: svc_service2 to AD Group GAG – Local Admins SERVER99
- Run GPUPDATE /force on SERVER99 and check the members of the Local Administrators group
So the magic here comes from Group Policy Preferences. It is smart enough to replace %ComputerName% with the actual computer name that’s processing the GPO. Thank you Microsoft!
Recap
So let’s recap this. In our case when Administrator (builtin) Order 1 runs, we remove all members from the local administrators group, then start adding back all the groups. If the AD Group GAG – Local Admins SERVER99 exists, it will also be added to the Local Administrators group.
Order 2 will run. Depending on the item level targeting, we will add more users to the local administrators group.
Order 3 will run. Depending on the item level targeting, we will add more users to the Remote Desktop users group
Order 2 will run. If we are a certificate server, we will again, remove all the members and add the specified members to the local administrators group.
Summary
Using GPP’s in a GPO at a high level, we can centralize who are members of the local administrators group across our organization. If a rogue admin updates the local administrators group, it will be removed when the GPO is reapplied. The next benefit is that we can query AD Groups and exam the GPP to see who actually has access across our whole AD.
Allan, Great article. We just implemented something very similar at work. However, we have run into a snag you may have insight on. Occasionally a machine drops off the domain but it still processes the GPO’s it received. And in doing so, it wipes out all users from the local admins group but then doesn’t add everyone back, including our local admin account. Then we are stuck with no local admin on the machine and have no choice but to wipe the unit. Not great when it’s an a manager’s laptop. I realize the first gpo is wiping all users/groups, and that part still works in this weird state. But then it doesn’t complete the update to the admins group and we’re SOL. Also, had a person try and move domains (we have 2) and in moving from domain A to a workgroup, before joining domain B, the second you go to workgroup, exact same issue.
thanks again.
Hi Noah, Thanks for the reply/question, and apologies on the late reply. The spam filter wasn’t working too well! As you mentioned, you’ve elected to delete all users and groups from the Local Administrators group. In any case, to start debugging your situation, I would uncheck those boxes and allow the members to stay intact while you troubleshoot the reason the computer keeps getting disconnected from the domain.
As for your second scenario, when you move into a Workgroup you’re no longer managed by AD and Group Policies are not being applied.
Let me know if I can be of any further assistance! Hopefully you’ve solved it by now!
I followed these steps and I notice that in the local device. the SID of the group is displayed and not the new local admin group name. Is this normal?
how often we should reapply this policy and how?