Background information:
I'm working on using Powershell DSC for some machine configuration across several machines. One aspect that DSC is used for is granting domain users local administrative access as needed.

Previously, this was being done by ensuring the user was part of the local Administrators group. However this DSC way of doing this would trigger a non fatal error being logged:

The error logged is "Exception calling "Save" with "0" argument(s): "Cannot perform this operation on built-in accounts."

What is happening is that DSC would attempt to rebuild the group from scratch and Windows would properly try and protect the local Administrator account from being pulled from the Administrators group. Again, not a fatal error, however it complicates DSC troubleshooting since an error is logged that everyone needs to know to ignore. I'd rather stop generating the error. There's some discussion around this on GitHub with a forked version of the DSC resource. The fix is that the DSC group resource will be only removing and adding people if the group already exists instead of removing everyone and rebuilding it. However it's not clear when this fix will migrate from the open source side and into a patch for DSC 2.0.

Even when this bug is fixed though, it doesn't solve another issue I realized was happening with the setup. Our domain admins might add a new user or group to the local Administrators group via group policy or similar. If the additions they make aren't mirrored in the DSC scripts my group uses, it results in a sort of tug-of-war on the box with DSC removing entries and GPO or something else adding them back.

Attempted fix for both issues:
As a fix to both the non fatal error and the possible tug-of-war, I figured I'd instead have DSC manage a separate local group, and flip the above code to look like this:

This way the GroupAdmins contains the users from my group needing admin access, and DSC will ensure the GroupAdmins group is added to the local Administrators group. No more tug-of-war, the domain admins can add who they want without it needing to be added to our DSC scripts, and our group has the access they need on these boxes.

DSC worked and the GroupAdmins group was created and added to the local Administrators group. No more non fatal errors from DSC, however...

The problem:
Anyone in the GroupAdmins group ends up not having admin access. "whoami /priv /user" from an administrative command prompt shows a reduced set of privileges, and access to things like the \\Machine\C$ share is denied.

This is being seen on both Windows 7 and Windows 10.

Is there something special that needs to be done to ensure a local group on Windows added to the Administrators group is granted admin access? Domain groups added to the local Administrators group appear to correctly have admin access as expected, it's only the local group added that isn't working.

I think your approach is good, sounds like the "right way" to go about it.

Let me be clear about what you're asking though. You're saying:

- Add a Domain sub-group to a Local Admins group = works.
- Add a Local sub-group to a Local Admins group = fails.

Is that what you're getting?

Next question:
- Do you get this same behavior whether you do the job scriptingly, or by hand from the "Users and Groups" screen in COMPMGMT.MSC? If you haven't tried the latter, try it and see if maybe there are warnings popping up that you don't see in the script.

Yep, exactly.


Aha, I think you're on to something. Thanks for the reminder to try it manually.

The GUI refuses to let me add a local group to another local group in general. When it's set to search or resolve from the local machine, groups isn't listed as an object type. Only "Other Objects", "Built-in security principals" and "Users". The GUI is gating the possibility of adding a local group to another local group.

When search is set to search the directory, object types lists a forth entry of "Groups".

Looks like DSC is able to inject a local group without an error. The GUI showing the local group looks right, where the added subgroup even has the proper local groups icon instead of a directory group. But no code is likely hooked up behind the scenes to properly grant permissions from the parent group.

Interestingly, a second test adds to the theory that the gate to adding a local group to another local group is only in the GUI. I created a new local group called "TomTest" and added my domain account DOMAIN\tom as a member via the GUI. The following command also succeeded without error, adding the TomTest group to the Administrators local group.

After this, the GUI shows the TomTest group inside the local Administrators group. DOMAIN\tom still lacked admin access.

Further testing though seems to point to the gate only being in place when all actions are done the same way.