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

webinar_ondemand

On Demand Webinar – Why You Still Suck at Patching

Posted March 27, 2015    Lindsay Marsh

On Demand Webinar: Dave Shackleford recounts some of his personal experiences in patch management failure, and breaks down the most critical issues holding many teams back from patching more effectively.

Tags:
,
dave-shackleford-headshot

Why You Still Suck at Patching…and How to Turn Your Life Around

Posted March 25, 2015    Dave Shackleford

Live webinar | March 26, 2015 | 10am PT/1pm ET | Dave Shackleford, SANS Instructor | Why You Still Suck at Patching…and How to Turn Your Life Around

Tags:
, ,
infographic

Privilege Gone Wild 2: Over 25% of Organizations Have No Privileged Access Controls

Posted March 24, 2015    Scott Lang

BeyondTrust recently conducted a survey, with over 700 respondents, to explore how organizations view the risk of misuse from privileged account misuse, as well as trends in addressing and mitigating those risks.

Tags:
,