As many of us pointed out already, there are some severe challenges with this approach.
The most important one is scale.
I'll start off by answering the original answerer's first remark. If I can do it for an OU, than why can't I for a group.
The short answer here is that the ConfigMgr client cheats when querying for the OU, as the client actually caches its OU membership locally in WMI.
As OU membership doesn't change that often, this approach works fine for OU's.
This tiny little cheat brings us back to the advice I gave during the MMS session I co-hosted with Jason in regards to global conditions. You only use global conditions to test on locally available data. Ldap queries even though available to build global
conditions from are a very bad fit.
Before you throw me another question, if they are such a bad fit, than why are they in there?
Well, there a left-over imho from the given that Global Conditions are DCM in disguise, and ldap queries imho only exist to be targetted at domain controllers.
Just as the SQL query global condition type is only designed to run against SQL servers as targets.
David's script neatly solves that part of the equation by querying for local data using WMI.
David script does leave 2 things unhandled though. Depending on the number of apps you risk having severe client impact by targetting all your applications this way.
The amount of policy stored and required to re-evaluate at global condition re-evaluation time would be painful. Secondly your compliance statistics from the Admin UI would be completely skewed as these are based on the number of objects in your collection
without taking into account who got "filtered" by the global conditions.