Friday, March 28, 2014

When Restricted Groups Attack

So there you are, using Group Policy in Microsoft Active Directory to manage an armada of computer systems both near and far. You think to yourself, "Self, I should really be managing the membership of important groups like Administrators and Backup Operators more efficiently through group policy! After all, I've controlled the user's passwords, defined their screensavers, configured their browsers, mapped their drives, and installed software to install on demand!" Well right you are, but there is a catch...

Let's say you wanted to manage the membership of 500 desktops in the "Majorbacon" domain so that members of the group "Majorbacon\HelpDesk" were members of each computer's local group "Administrators."

You can do this by adding the restricted group "Administrators" and then adding "Majorbacon\HelpDesk" to the Members tab, as shown:

Now this seems good, but take a  look at the before and after screenshots of a computer affected by this policy!


After running GPUPDATE on the client, here is the POST-policy:

The problem is, when you define the membership list of a group, you define the ONLY members of that group. Therefore, all the other members, SUCH AS DOMAIN ADMINS, have been removed. I'm pretty sure that in most administrative circles, this would be called "bad."

So here is the other option, which is probably the one you want.
You should add the restricted group "Majorbacon\HelpDesk", and then add "Administrators" to the "Member Of" tab, thereby saying that HelpDesk should be a member of the local Administrators group (but NOT saying that other's couldn't also be members as well).

You are now only a GPUPDATE away from nirvana. Let's look at the group after the local computer has been updated by this policy.

So what have we learned? There are two methods to manage local group membership.

The first method: If you want to totally ABSOLUTELY DEFINE a local group membership list, define the local group as a restricted group and configure the active directory global groups in its "members of this group"  list.

The second method: If you want to SUPPLEMENT a local group membership list, define the Active Directory group you want to nest, and add the local group to the "This group is a member of" list.

One final thought: Any local administrator CAN actually change the membership in Local Users and Groups, but since security policies are essentially reapplied with a "/Force" command every 16 hours (see if you don't believe me), those changes will be either set back to group policy standard (if you used the first method) or lost Active Directory groups will be restored (if you used the second method)

No comments: