Forcing Domain Admins to be local admins on domain computers

All network administrators want to be able to administer user workstations remotedly. Often this requires the administrator to be a member of the local Administrators group on the user workstation. A simple way to ensure this is to have Domain Admins group to be a member of local Administrators group on each computer. Not surprisingly, this is the default situation on all Windows computer that are domain members.

However, if your users are local admins on their computers, sometimes you can find yourself in a situation when a clever or misguided user removed Domain Users from their local Administrators group. Also, sometimes you want some less privileged group than Domain Admins to be local admins on all computers - for example a group of network administrators that are assigned to manage user computers but are not eligible to administer the domain. In both cases you face a problem: how to ensure that a certain domain group is always a member of local Administrators group on each domain member computer?

Group policy to the rescue. Below I describe how to achieve this goal, as well as the pitfalls and shortcomings of this seemingly simple solution.

The key to the solution is to configure a feature in Group Policy called "Restricted Groups". In the following steps I will assume that you want to make Domain Admins part of local Administrators, but you can use any other group that you want.

Fire up Group Policy Management Console and locate your default domain policy (or any other Group Policy Object you want to use for this configuration). Right-click it and select edit. In the Group Policy Editor navigate to Computer Configuration\Windows Settings\Security Settings\Restricted Groups. Right-click and select "Add Group". Browse for your Domain Admins group. You should now arrive at the dialog box that looks like this:

First, in the top part of the dialog window, press "Add..." and add all the members of your Domain Admins group here. This seemingly extra step is necessary, because when the Group Policy is applied, it will change the membership of the group to the one specified here. If you don't list all your Domain Admins members here, you will wipe out your Domain Admins group! So, be careful and specify all relevant members here.

Now you are ready to do what you came here for. In the bottom part of the dialog, press "Add..." and type in Administrators group name. Note: do not use "Browse..." button, just type in the name. The dialog will now look like this:

Click OK and you are done. Once Group Policy applies to domain member computers, Domain Admins will become part of local Administrators group if not already there.

Caveats

Unfortunately, there are issues with this solution that you must be aware of. They all stem from the fact that Group Policy matches the Restricted Groups by name rather then SID; i.e. when the policy applies your Domain Admins will become a member of a group named Administrators; but it's not this name that makes this group special, it's its well-known SID. Let's see what implications this has.

For one, a malicious user may simply rename the local Administrators group (e.g. call it Admins), and it will completely defeat our trick, because Group Policy won't find a group named Administrators. This said, a truly malicious user will always find a way to prevent Group Policy from applying to his computer or to undo its effect after it applied. Thus we shouldn't even expect Group Policy to help overcome malicious users.

Next, consider international users. The local admin group is called Administrators in English version of Windows, but in other language versions the name is localized. In Russian version of Windows the group is called Администраторы, in Cyrillic. If you have both Russian and English systems in your domain, you can simply add both names to the "This group is a member of" list:

This will work, but has its own problems. Whenever Group Policy applies, it will find either Russian or English version of the Administrators name, depending on the system language. The other name will not be found, and a warning like the following will be logged to the Application system log.

Event Type: Warning
Event Source: SceCli
Event Category: None
Event ID: 1202
Date:  9/4/2008
Time:  1:41:37 AM
User:  N/A
Computer: 
Description:
Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for "troubleshooting 1202 events".

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.
...
[very detailed explanation follows]

That might be not a big deal on a workstation, but on domain controllers the Group Policy applies every 5 minutes, and the Application log will be flooded with these warnings, making it harder to spot more serious warnings, if they occur.

What can we do? Well, this policy doesn't need to apply to domain controllers, they don't even have local groups! So, you can do the following:

1. create a new GPO;
2. make the Restricted Groups configuration there and not in Default Group Policy;
3. make the GPO apply to Domain Computers group only (which does not include domain controllers). For this add Domain Computers group in the "Security Filtering" section of Group Policy Management Console for this GPO and remove any other groups that were there, like this:

That gets rid of the flood of warning on domain controllers. An occasional warning in member servers' and workstations' logs can be tolerated, but if not, you have a way to get rid of them. For that you will need to create two separate GPOs and make them apply to either English or Russian systems with WMI Filters.

Using WMI Filters

So, back in Group Policy Management Console, create a new GPO. Let's call it "Russian language-specific policy". Make it apply to Domain Computers as described above. Now, under WMI Filters, in the Group Policy Management Console's left-hand tree, select "New" from the context menu to create a new filter with the following condition:

select * from Win32_OperatingSystem where OSLanguage = 1049

Your "New WMI Filter" dialog will look as follows:

Make the filter apply to the GPO by selecting the filter from the drop down list in the "WMI Filtering" section of Group Policy Management Console:

Voila, you have a GPO that applies only to domain computer with Russian version of Windows. Now you can configure Restricted Groups in it using the Russian name "Администраторы".

Repeat the same steps to configure "English language-specific policies" with a similar WMI Filter:

select * from Win32_OperatingSystem where OSLanguage = 1033

Now you can configure Restricted Groups in it using the English name "Administrators".

Somewhat complicated, but now you have different policies that apply to different language versions of Windows. Was it worth it? In this case probably not, but it's an interesting exercise and the technique may help you in other situations.