Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Does This GPO Make Me Look Fat?

August 20, 2012

  • Blog
  • Archive
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.
Photograph of Scott Lang

Scott Lang, Sr. Director, Product Marketing at BeyondTrust

Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

Mapping BeyondTrust Solutions to the Qatar National Information Assurance Policy v2.0

Whitepapers

KuppingerCole Executive Review - BeyondTrust Endpoint Privilege Management

Webcasts

Tech Talk Tuesday: Managing Vendor Access

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.