Target Group Policy Preferences by Container, not by Group

Hello again AskDS readers, Mike here again. This post reflects on Group Policy Preference targeting items, specifically targeting by security groups. Targeting preference items by security groups is a bad idea. There is a better way that most environments can accomplish the same result, at a fraction of the cost.

Group Membership dependent

The world of Windows has been dependent on group membership for a long time. This dependency is driven by the way Windows authorizes access to resources. The computer or user must be a member of the group in order to access the printer or file server. Groups are and have been the bane of our existence. Nevertheless, we should not let group membership dominate all aspects of our design. One example where we can move away from using security groups is with Group Policy Preference (GPP) targeting.

Targeting by Security Group

GPP Targeting items control the scope of application for GPP items. Think of targeting items as Group Policy filtering on steroids, but they only apply to GPP items included in a Group Policy object. They introduce an additional layer of administration that provides more control over "how" GPP items apply to a specific user or computer.

Figure 1 - List of Group Policy Preference Targeting items

The most common scenario we see using the Security Group targeting item is with the Drive Map preference item. IT Professionals have been creating network drive mappings based on security groups since Moby Dick was a sardine-- it's what we do. The act is intuitive because we typically apply permissions to the group and add users to the group.

The problem with this is that not all applications determine group membership the same way. Also, the addition of Universal Groups and the numerous permutations of group nesting make this a complicated task. And let's not forget that some groups are implicitly added when you log on, like Domain Users, because it’s the designated primary group. Programmatically determining group membership is simple -- until it's implemented, and its implementation's performance is typically indirectly proportional to its accuracy. It either takes a long time to get an accurate list, or a short time to get a somewhat accurate list.

Security Group Computer Targeting

Using GPP Security Group targeting for computers is a really bad idea. Here's why: in most circumstances, the application retrieves group memberships from a domain controller. This means network traffic from the client to the domain controller and back again. Using the network introduces latency. Latency introduces slow process, and slow processing is the last thing you want when the computer is processing Group Policy. Also, Preference Targeting allows you to create complex targeting scenarios using Boolean operators such as AND, OR, and NOT. This is powerful stuff and lets you combine one or more logon scripts into a single GP item. However, the power comes at a cost. Remember that network traffic we created by make queries to the domain controller for group memberships? Well, that information is not cached; each Security Group targeting item in the GPO must perform that query again- yes, the same one it just did. Don't hate, that's just the way it works. This behavior does not take into account nest groups. You need to increase the number of round trips to the domain controller if you want to include groups of groups of groups etcetera ad nauseam (trying to make my Latin word quota).

Security Group User Targeting

User Security Group targeting is not as bad as computer Security Group targeting. During user Security Group targeting, the Group Policy Preferences extension determines group membership from the user's authentication token. This process if more efficient and does not require round trips to the domain controller. One caveat with depending on group membership is the risk of the computer or user's group membership containing too many groups. Huh- too many Groups? Yes, this happens more often than many realize. Windows creates an authentication token from information in the Kerberos TGT. The Kerberos TGT has a finite amount of storage for this information. User and computers with large group memberships (groups nested with groups…) can maximize the finite storage available in the TGT. When this happens, the remaining groups memberships are truncated, which creates the effect that the user is not a member of that group. Groups truncated from the authentication token results in the computer or user not receiving a particular Group Policy preference item.

You got any better ideas?

A better choice of targeting Group Policy Preference items is to use Organization Unit targeting items. It's da bomb!!! Let's look at how Organizational Unit targeting items work.

Figure 2 Organizational Unit Targeting item

The benefits Organizational Unit Targeting Items

Organization Unit targeting items determines OU container membership by parsing the distinguished name of the computer or user. So, it simply uses string manipulation to determine what OUs are in scope with the user or computer. Furthermore, it can determine if the computer or user has direct container membership of an OU by simply looking for the first occurrence of OU immediately following the principal name in the distinguished name.

Computer Targeting using OUs

Computer Preference targeting with OUs still has to contact a domain controller. However, it’s an LDAP call and because we are not chasing nested groups, it's quick and efficient. First, the preference client-side extension gets the name of the computer. The CSE gets name from the local computer, either from the environment variable or from the registry, in that order. The CSE then uses the name to look up the security identifier (SID) for the computer. Windows performs an LDAP bind to the computer object in Active Directory using the SID. The bind completes and retrieves the computer object's distinguished name. The CSE then parses the distinguished name as needed to satisfy the Organizational Unit targeting item.

User Targeting using OUs

User Preference targeting requires fewer steps because the client-side extension already knows the user's SID. The remaining work performed by the CSE is to LDAP bind to the user object using the user's SID and retrieve the distinguished name from the user object. Then, business as usual, the CSE parses the distinguished name to satisfy the Organizational Unit targeting item.

Wrap Up

So there you have it. The solution is clean and it takes full advantage of your existing Active Directory hierarchy. Alternatively, it could be the catalyst needed to start a redesign project. Understandably, this only works for Group Policy Preferences items; however-- every little bit helps when consolidating the number of groups to which computer and users belong-- and it makes us a little less dependent on groups. Also, it's a better, faster, and more efficient alternative over Security Group targeting. So try it.

Update

We recently published a new article around behavior changes with Group Policy Preferences Computer Security Group Targeting.  Read more here.

- Mike "This is U.S. History; I see the globe right there" Stephens

Comments

• Anonymous
  June 21, 2011
  An interesting read.  We use user group security filtering extensively as we have a fairly flat AD so users don't have to be managed by OU.   Side note/feature request: GPP needs "Login script" that accepts targeting for those times you still need to run a script, but want it to be targeted

• Anonymous
  June 21, 2011
  Thanks gallwapa, It true, many Active Directory environments have little structure-- probably inherited down from NT4 or Netware. It's sad too, because that is really why we have a directory, to organize users.  It's a mindset that is difficult to break, but its actually easier to manage than trying to remember all the group memberships.  In this instance, it certainly helps applying GPP rather than using group membership, especially when used with computers. Thanks for the feature request. We'll forward it up the food chain. Mike Stephens

• Anonymous
  June 21, 2011
  Unfortunately you'd be surprised the applications we find that require the bind user be at an OU higher than the OU's you want to search and you cannot specify an alternate base OU (oh the humanity!).  I seem to recall at one point we experienced failures with GPP targeting when using nested groups, but in speaking with colleagues here we do not recall if it was a computer group or not. As far as the organization of user objects go, the thinking behind this design was that when a user moves from location to location, we already have to change group memberships.  Absent a compelling reason to organize them into OUs, we can query other properties such as office and group membership.  Our AD was created in May 2008.   We have on occasion organized computers into OUs for GP reasons.

• Anonymous
  June 21, 2011
  I am the colleague that gallwapa spoke of in his most recent post. In my testing, nested groups do not work for security group computer targetting. I have a global group that's a member of a domain local group. The computer is a member of the global group. For the test I am creating a shortcut on the all users desktop. If I target members of the global group, the shortcut is created. If I target members of the domain local group, the shortcut is not created. I have done the same test with security group user targetting. The shortcut is delivered when either group is targetted. If this is working as expected, then chalk it up as one more reason to use containers for computer targetting.

• Anonymous
  July 07, 2011
  Thanks Mike for pointing this out. We had our hopes on GPP to phase out our loginscript but now I think we'll have to stick to it. Let me give one example of our situation: We are a university and have staff and students and classroom and non-classroom PC's. Students on classroom PC's are not allowed to lock the PC. Students on non-classroom PC's and staff on all type PC's are allowed to lock. To make it worse their are some non-classroom PC's where nobody is allowed to lock the PC. Students and staff are in one User OU, al our PC's are in one Computer OU. This is because users and computers tend to switch roles and have double roles, so targeting groupmembership is far better then the one OU an account can be in. I made two registry GPP's: one to delete the DisableLockWorkstation value and one to replace the DisableLockWorkstation value. You can imagine the complex AND, OR, TRUE, FALSE restrictions to user and computer groups I needed to build. Applying those two registry GPP's alone to the user profile took 50! seconds to complete. Why doesn't Windows 7 cache the (computer) group memberships temporary in registry. You say it's just the way it works, but it shouldn't be that hard or am I missing something? Kind regards, Danny

• Anonymous
  July 11, 2011
  Hi Danny, You're right-- not targeting by OU will not meet all scenarios; however, it is a great alternative that is often overlooked.  Also, targeting by OU typically requires more depth in the Active Directory hierarchy than a single OU.  Many scenarios that include multiple conditional targeting items can benefit from filtering by OU, especially computers because of the speed gained in processing. With regard to caching groups, the actual implementation of caching anything is not that hard.  However, several other factors come into play.  The biggest factor to consider is when do you update the cache.  Cache data is only useful before it becomes stale.  To refresh cache, you have to find all the lists of groups again, which increases time.  So, you end up with a solution where one application of policy may be slow and the next fast.  Now your application times become unpredictable.  So, caching information doesn’t always speed things up.  It comes with a cost that you'll incur at some point.  Also, targeting by security groups was not always slow.  It came from a hotfix where targeting items did not support nested groups. So, we fixed it, but with a cost. There are a few things you can do to combat the slowness.  You could move the complex targeting items to an environment Preference item.  Then, use the newly created environment for all future targeting items to determine which condition they should use.  This gives you the behavior of a cache in that as long as the environment variable is present, you're golden.  As always, thanks for reading and huge thanks for the feedback. Mike Stephens