Some time ago I had a request to create local user accounts on laptops and to provide those user accounts with administrative access and they wanted this done in an automated manner. Of course Restricted Groups immediately came to mind until they told me that they wanted local usernames to match their domain names. They only wanted the users to have this configuration when the laptops would be taken into the field for an extended period of time where they would not be on the corporate network.
That was going to be a little more challenging. And then I thought of it – we’ll use a Restricted Groups policy with security group filtering to add a local group to the local Administrators group. When the laptop was going to go into an unmanaged state, we’d add the workstation to the security group that this policy is filtered on. When the laptop was on the corporate network or in a manageable state, we would remove the workstation from this policy. The local user account would remain a member of the local group at all times.
Here’s how a reproduction of how it went:
1. Create a local user account (rcrandall)
2. Create a local group (local_group) on the workstation and add the local user account (rcrandall)
3. Create a new domain security group (local_admin_group)
4. Create a new restricted group policy
5. Filter the policy to apply only to our new security group (local_admin_group)
6. In the Restricted Groups portion of the policy, add the local Administrators group with a definitive membership list
REMEMBER: Your list will be different than the one in this example.
7. Link the policy to the appropriate OU[s]
NOTE: It is almost never appropriate to link a Restricted Groups policy to the domain level. This will likely apply to your domain controllers as well and there is a good chance that you will be granting more people (or the wrong people) than you would like to have full access to your domain.
8. Add workstation[s] to the security group (local_admin_group)
9. Reboot the client workstation
Aah, that feels good! One restricted group policy and I can still handle all of these unique local usernames through my one standardized local group. Beautiful!
Wait…what? It doesn’t work? No, didn’t you see the screen shot above? I connected to your machine and everything looks good – see the screenshots below.
What do you mean it doesn’t apply? Okay,yea, send me the screen shot of whoami /groups /fo list output
Yea, I see that there is no NT AUTHORITYAdministrators group in your token. What happens if you try to perform an administrative task liking opening the security event logs? That didn’t work?
Ugh! Alright…let me see what’s going on.
Well, what is going on is that you can’t nest local groups. If you take Restricted Groups out of the picture and just try to add local_group to the local Administrators group you’ll notice that this object type doesn’t even show up as an option. However, you can use the net localgroup command to nest local groups.
Whether you can add it or not, there is no functional nesting of local groups. In fairness to Microsoft, this is documented and has been since at least Windows 2000. There isn’t much documentation on the web (at least not that I could find – either then nor now) but it is in a book and the net localgroup command and resulting behavior is documented here: http://support.microsoft.com/kb/974815.
In the end, we had to use a script for the customer to manage the groups. It wasn’t nearly as graceful as we should have liked. If only we had local group nesting. Oh well, don’t expect that it’s going to be added so we’ll have to continue to be creative.
NOTE: Remember, the NET executable is pretty old and hasn’t seen a whole lot of updates for a while so be gentle on it. There are quite a few other legacy behaviors in this command utility and we’ll see more of them coming up in future posts.