I work for a college with almost a thousand users (faculty and staff). Many staff members also teach part-time, and many faculty members teach in different departments.

Knowing that a user and/or computer can only exist in a single OU, what kind of strategy would allow for a nice hierarchical structure, and still be flexible enough to allow different department Group Policies to apply to the same user.

This can't be too uncommon of a scenario but I'm just not seeing the simplest or cleanest layout yet.

  • 1
    WMI filtering of the GPOs and Security groups and scripts that check against those memberships come to mind immediately. Though, I'm curious to find out if a more experience AD admin has anything better, myself. – HopelessN00b Jul 20 '12 at 22:35
  • 3
    @HopelessN00b: Rather than writing scripts that check group membership (which can be difficult-- ever implemented a recursive algorithm to check for nested group memberships?) it's often easier to break your script into smaller parts, each relating to an individual security concern, and specify NTFS ACLs that control who can execute the script. Then you offload all the group membership checking to the OS, which will always handle it better than you can (handling multiple domains, trust relationships, etc). – Evan Anderson Jul 20 '12 at 22:58

Without some explanation of the specific scenarios you're looking for it's difficult to give you any "step by step".

User Group Policy application is influenced by:

  • The Distinguished Name (DN) of the user object in Active Directory and GPlink objects in Organization Unit objects in the parent path of the user object DN
  • GPlink objects at the AD Site object containing the IP address of the computer where the user logon occurs
  • The "Block Inheritance" attribute of OUs in the parent path of the DN of the user object or at the AD site object
  • The "Enforced" / "No Override" attribute of GPlink objects that are linked to OUs in the parent path of the user object or at the AD site object
  • The security group membership of user accounts and the permission that confers upon them with respect to applying the GPOs or applying specific policy or preference settings within the GPO that might have ACLs attached to them (Software Installation policy and Group Policy Preference settings have ACLs within the GPO, for example)
  • Enabling Loopback Group Policy Processing on computers (in either Merge or Replace mode)

Those are all the mechanisms for controlling user Group Policy application. Between all those functions you can create reasonably complex deployment scenarios.

Your OU hierarchy should always be designed first based on planned delegation of control. You only get one OU hierarchy and there are no good mechanisms to decouple delegation of control from the OU hierarchy. Design for delegation of control first, Group Policy application second.

I focus on using security group membership to filter user Group Policy application. Never forget that some settings within GPOs have ACLs separate from the GPO itself. The "Block Inheritance" and "Enforced" / "No Override" functions should be used sparingly and are typically indicative of a broken design. Loopback Group Policy Processing can be a very powerful and useful tool, but it's a bit complex to understand.

You're focusing on users but I'll take a moment to mention computers, too. Computer Group Policy application has all the same filtering functionality as user Group Policy, but also includes WMI Filtering. WMI Filtering can let you target GPOs to specific hardware or operating system-related attributes of computers. I often see security group filtering neglected when filtering computer Group Policy.

There are some things you can accomplish with both WMI Filtering and security group filtering for computer Group Policy. WMI Filtering has the added feature of being dynamically calculated on each Group Policy application (versus security group memberships, which must be changed manually to affect filtering). Security group filtering can still be beneficial if you have computers located in disparate OUs without a WMI filterable attribute that need to have common Group Policy Objects applied. I use security group filtering with computers, frequently, to control Software Installation policy (wherein I have a GPO with multiple software packages assigned, each with a unique ACL that includes a group to control the software installation).

The most important thing you can do, setting aside everything I said above, is to make sure you fully understand how the Group Policy client calculates the Resultant Set of Policy and, with that knowledge, brainstorm and test possible designs before putting them into production. I firmly believe that testing should start with pen and paper (whiteboard, etc) rather than software. You need to have enough organizational knowledge to be able to design realistic scenarios and test them. Get other groups in your IT organization (and outside the IT organization if need be) involved. Your Helpdesk team, for example, will have delegation of control needs that will drive the physical OU hierarchy. Your desktop support team may have software installation needs that drive computer group policy filtering. There are any number of possible scenarios that should be talked through, worked out on paper, and finally tested in a lab scenario before being put into production.

| improve this answer | |
  • Don't know how you threw the answer down so quickly, dang! Much deserved +1. As a K12 district, we're still working to clean-up, re-organize and streamline our inherited config. – jscott Jul 20 '12 at 23:08
  • 2
    @jscott: It's been long-established that I'm not actually human. My favorite AD environment in my Customer base is my K12 District. I really love the variety of scenarios and getting to exercise a lot of the functionality of the product. Unfortunately, being a nearly 9 y/o AD environment it has built up a certain amount of "cruft" that I keep saying "I'll get around to it" w/ respect to cleaning up some things. You could really get a feel for my personal evolution re: using some features of AD just by looking at their Directory sorted by object creation date. – Evan Anderson Jul 20 '12 at 23:16
  • @EvanAnderson Thank you for the depth of information and thought you put into this post. This will help us out immensely. – BenC Jul 20 '12 at 23:30
  • @silmaril8n: Glad I could help. Teaching those MSFT classes on AD design at the community college paid off... >smile< – Evan Anderson Jul 20 '12 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.