I have to blog this right away - it will be part of a larger "GP Processing" article at some point though… But this is IMHO important stuff which needs to get out there quick :)
I’ve heard the following sentence too many times (in one way or the other): "You can only assign Group Policy Objects to Site, Domain Level or OU’s"…
- but that’s only partly true! Normally in newsgroups, forums etc. this leaves the readers (eg. someone who asked a GP question or whatever) with the impression that you cannot "hit" members of a certain Security Group only (which leaves you with "Site/Domain/OU Filtering" and/or "WMI Filtering" as the only possible a choices available). But that’s simply not fair to the amazing Group Policy processing engine!
Even though "WMI Filtering" is pretty well-known these days (after WS2003 arrived), many people tend to forget the little - but extremely effective and flexible - thing called "Security Filtering" (even though it’s somewhat more "Basic" compared to WMI)…
Let’s talk about it for a minute or two if you are interested…
You can set this kind of filtering within the Group Policy Management Console (GPMC) on either the Scope tab:
- or the Delegation tab (a bit more Advanced):
As you can see, by DEFAULT all Group Policy Objects (GPO) include "Authenticated Users" with both Allow:"Read" and Allow:"Apply Group Policy" permissions set. Both of these permissions are needed for users and computers to take on (or process) a given GPO:
The thing about the very important "Authenticated Users" group is that it includes ALL User AND Computer accounts/objects within the AD domain (Domain Controllers too, right). So, by default a GPO applies to both computers and users (we are not going to talk about disabling GPO parts etc. now).
That’s the "technical" explanation why policies placed on
a) the Site applies to ALL users and computers within the Site (users site follows computer site, site follows IP address)
b) the Domain Level applies to ALL users and computers within the Domain
c) any given OU applies to ALL users and computers within that particular OU (and sub-OUs for that matter)
=> because the "Authenticated Users" security group is there by default. These default permissions on new GPOs are handled by something called "Security Descriptors", but more on that in some other blog or article.
So, we have Security permission on all of our GPOs (unfortunately not the GPO links, but that’s another talk) - leaving us with GREAT power to control to whom he particular GPO should be assigned (or ‘applied’). All we need to do is to change the default permissions and <Zaboooka!> we are in complete control.
First step is generally to remove the "Authenticated Users" group from the GPO in question. Click Remove (below Security Filtering section) on the Scope tab and click OK:
Click Add… and select the domain security group you want to "hit" - click OK when done:
And <poof>, this GPO will only apply to members of "The Sales Group" - or whatever group (or user, or computer object…) you selected:
Now all you need to do is to link the GPO to the Domain Level (or Site or OU if that’s better in your case) - but the Domain Level should be fine for most environments.
Now, you could turn this around and Exclude certain groups, users or computers - by setting Deny:"Apply Group Policy" instead. In some cases that might be the best choice - but as always with "deny" you have to watch out (manly because deny overwrites allow)!
Also note, that Security groups can include both user and computer accounts - we are maybe used to thinking that groups are for users only (in my experience most admins know the "Domain Users" group - but the "Domain Computers" group is not that well known)… But, with this in mind, you could make a group of computers instead of applying a WMI filter for instance (which is generally slower).
You could use other methods for setting permissions than the GPMC (like scripts) - but the GPMC is a wonderful tool for doing this easily - no sweat!
One way of automatically creating Security Groups from members of an OU is described in my article "Configuring Granular Password Settings in Windows Server 2008, Part 2" - these groups are referred to as Shadow Groups (cool, right). In some "filtering situations" that is nice to know…
Wow - that was nice getting it off my shoulders, and now I can refer to this blog entry whenever I get the question again - and so can you of course :-)
.
