BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

Does This GPO Make Me Look Fat?

Posted August 20, 2012    Peter McCalister

I was on a call with a colleague and friend of mine Paddy McHale. We were walking a new PowerBroker Desktops (PBD) customer through some initial planning and setup. Being a Group Policy Extension quite commonly the topic of how many GPOs are required to maintain this software frequently comes up. Specifically, should a company maintain all PBD policies in one or two GPOs, or should they be separated into several GPOs; commonly referred to as Monolithic and Functional GPOs. It was at this point Paddy simply said, “Does this GPO make me look fat?”. After I picked myself up off the floor and iced my ribs, I thought about this more. As humorous as the question was, it actually sums up what folks that are new to the product have to consider; how do I limit GPO Bloat and Group Policy refresh times in my enterprise while implementing this software? Keep in mind the purpose of PBD is to manage the privileges of an application, regardless of what rights the logged on user has. It needs to perform this task without negatively impacting the user experience or an admin’s already taxed resources.

Ultimately the choice is yours, and the school of thought you’re most familiar with. Our best practice suggestion, and that of popular thought, is it’s always best to maintain the least amount of separate GPOs you can. While there are reasons, and in many cases current native GPO functionality that necessitates a higher number of GPOs, there are features available within the PBD software you may not be aware of that will help keep your GPO count down with your PBD rollout.

Item-Level Targeting (ILT):
Similar to what exists within MS Group Policy Preferences, you can assign specific policies or groups of policies to a subset of who the GPO is linked too. As an example, let’s say you link a GPO at an OU called ‘USERS’, and under this OU you create Sub-OUs that relate to various geographic regions or roles within your organization. By default any of the PBD policies under User Configuration would apply to every User in the USERS OU and any Sub-OU. There is some functionality at the GPMC level to adjust this, but it’s limited. With Item-Level Targeting you can assign a policy to only apply to a User if they are in a particular security group, on a specific computer or computer security group, apply only if a specific application is installed, have particular hardware installed, or any combination of these and 20+ other targeting criteria.

Collections:
Collections allow you to combine policies into logical groupings. Think of these the same way you would an OU or Security Group, but managed within a single GPO rather than a global AD setting. Commonly collections are used to group policies from a particular vendor, (Adobe, Java, etc.). It helps when you want to go back and edit or view rules affecting the respective vendors software. You can also use Collections based on roles, (Developer, Marketing, Retail). In other words, you would create policies that only Users or Computers responsible for this role would require. By doing so you can assign Item-Level Targeting criteria to the group of policies, rather than assigning the same Filtering to each policy within the Collection.

Collections can also be used to enforce a specific action, meaning instead of having to assign the same settings to fifty different applications that simply allow it the appropriate privileges or deny it from running, you can assign this behavior at the Collection level and any policy in that collection takes on that action. Both this and ILT at the collection level will save you time when creating policies, as well as when you need to edit the GPO.

By utilizing these two features within PBD, you can see how the need to separate policies that target different applications or different groups of users is not required. You can successfully implement a Least Privilege solution and keep your GPO on a diet. In other words, you can have your cake and eat it too, we’re just making sure the cake is apple sauce, diet coke and sugar substitute rather than eggs, oil and the real stuff.

Leave a Reply

Additional articles

Dark Reading

2014: The Year of Privilege Vulnerabilities

Posted December 18, 2014    Chris Burd

Of the 30 critical-rated Microsoft Security Bulletins this year, 24 involved vulnerabilities where the age-old best practice of “least privilege” could limit the impact of malware and raise the bar of difficulty for attackers.

Tags:
, , , , ,
dave-shackleford-headshot

Looking back on information security in 2014

Posted December 16, 2014    Dave Shackleford

Dave Shackleford is a SANS Instructor and founder of Voodoo Security. Join Dave for a closer look at the year in security, and learn what you can do to prepare for 2015, with this upcoming webinar. 2014 has been one heck of an insane year for information security professionals. To start with, we’ve been forced…

Tags:
, ,
patch-tuesday

December 2014 Patch Tuesday

Posted December 9, 2014    BeyondTrust Research Team

This month marks the final Patch Tuesday of 2014. Most of what is being patched this month includes Internet Explorer, Exchange, Office, etc… and continues a trend of the greatest hits collection of commonly attacked Microsoft software. Probably the one thing that broke the mold this month is that for once there is not some…

Tags:
,