Active Directory Tips, Tricks, and Facts – Part 1: Organizational Units

As those who follow this blog are aware, I have been working with Active Directory (AD) since it was first introduced. Over the course of my career, I have worked with organizations both large and small, new and old, and in just about every business sector you can think of. I’ve done more than a few breach recovery projects, as well as hardening and optimization efforts for all sorts. This blog entry is the first in what I plan to be a series of items outlining some of the most common challenges I have seen, from more general usage items, all the way up to hardening. The items you will find in this series all come from hard earned experience and study, as well as plenty of trial and error. After all, we learn from failures, not successes.

OU Structure

The first item I want to address, which is actually a personal pet peeve of mine, is that nearly every organization uses OUs as if they were folders in a file share, which is incorrect. The most common refrain I hear is “It has the word ‘organizational’ in the name, so I should use it to organize my objects”. Unfortunately for those people, they are misinterpreting the usage of the word. It is, in a sense, for organization of your objects, but not in a visual sense, where folders are used to simply group objects for ease of location.

If you read through Microsoft’s documentation on designing AD, there are two reasons to create an OU; to delegate control, or to manage the application of Group Policy Objects (GPO). This means that the structure you implement should generally create a separation of concerns between different teams of administrators, as well as what those administrators are responsible for.

To provide a practical example, consider the following, admittedly very simplified org structure.

If you are using a Tiered administrative approach (you are using tiering…right?), then you have some immediate needs right off the bat that can be answered by the tier separation itself.

• Infra
  • AD Team
    • This team will need to manage your Tier 0 assets; e.g., Domain Controllers, MS certificate authorities, DNS, and anything else that could result in compromise of the entire environment if captured
    • Should be represented by a single root OU
  • Server Team
    • Most orgs treat this as though the team is responsible for anything running a server OS, however this should instead be limited to Tier – 1 assets, which means any device running a server OS and hosting applications or servers not found in Tiers 0 or 2
    • Should be represented by a single second-level OU under Tier – 1
    • Note: This may also extend to underlying virtualization infrastructure, however such items are rarely tied to AD so, other than stating that Tier – 0 and Tier – 1 should use separate virtualization infrastructure, I will leave this alone for now
  • Storage Team
    • As with servers, this should be separated out, with admin focused shares treated as Tier – 0 (and separate hardware), and user-facing shares being Tier – 1
    • In addition to this, there should also be separation based on the classification of the data being stored, with sensitive data being limited to only your senior (e.g., most trusted) storage team members, rather than all of them
    • Should be represented by a single second-level OU under Tier – 1, with additional child OUs to represent data classifications
    • Note: Obviously this entry really depends on whether the underlying devices are joined to AD or not
• Database Admins
  • In some orgs, this will be the developers, but in larger ones, it will be a separate team or at least a few devs who focus on back-end development
  • As with storage, this should ideally be further segregated by data classification, even if the org doesn’t have a big enough team to separate administrative access
  • Should be represented by a single second-level OU in Tier – 1, with additional child OUs to represent data classifications
• DevOps
  • Ideally, your developers should not have any type of persistent access to your production environment, instead leveraging infrastructure-as-code and CI/CD to make changes
  • In reality, most orgs don’t have dedicated technical owners on the infrastructure team, so developers inevitably require access
  • Should be represented by a single second-level OU in Tier – 1, with additional child OUs to represent the different support teams (apps with the same team should have all front-end servers grouped together)
• End User Services
  • Global Helpdesk
    • Most orgs leverage helpdesk to perform simple user assistance, such as fulfilling access requests, or managing password resets, as well as troubleshooting desktop issues
    • Should be represented by a single second-level OU under Tier – 2
  • Desktop Support
    • While many orgs like to treat these teams as a single entity for access purposes, the reality is that they are typically specific to one or more locales
    • Should be represented by third-level OUs for each area of responsibility, which should sit under the global OU
    • I personally also believe that VIP users that are often targets for threat actors, should be segregated into their own second or third-level OU with more restricted access
    • Note: The tendency of most orgs is to have all the desktop team have access to all the user and workstation OUs to ‘provide coverage’, even though such occasions are typically rare; Ideally, “coverage permissions” should only be assigned as needed
• IAM and Compliance
  • The IAM team should not have direct access to your directory, only to servers used to provision and deprovision users, which can be addressed with a single second-level OU in Tier – 1 that does not fall under the control of the server team
  • Note: Some would place IAM servers within Tier – 0, however I believe that Tier – 0 and Tier – 1 accounts should be manually created and linked to an owner account in Tier – 2, with the IAM tool only having the permissions to disable the associated accounts; Server or AD teams create the accounts and the links, with access to set passwords, but not disable or delete for users, while the IAM tool can disable or delete, but not perform any other administrative actions

All of the above elements might result in an OU structure that looks like the below. For Tier – 2, users could alternately be placed under each location instead of as a root, and computers would presumably also be represented. In either case, you end up with a structure that supports growth where teams may be responsible for an entire region, or just a location, as well as supporting periodic “coverage” access when needed.

Most organizations that I have dealt with would balk at the above OU structure. They want to create containers for different OS versions, or departments, or a dozen other things so that it is “easier to find the objects”. From observing these admins, particularly in large orgs, I can tell you that it isn’t often that I see admins browsing through AD to find an object…they use search, because it’s faster. That said, it does happen, so how does one address this need without creating more OUs?

The answer is attributes. Too many organizations try to put everything into the name, when just about every attribute available for a user is available for Computers as well. This is because the Computer class inherits from the same class as User objects. For those still using AD Users and Computers, it’s a trivial matter to create a saved query, which will enable you to rapidly limit the number of objects shown. All it requires is a little effort to maintain the attribute values from a system of record (not manually).

Configuration Defaults

For those in the know, there are technically two types of objects within AD that are used to host other objects in a visual hierarchical format. Well, technically there are a lot more than two, but for the purposes of this section, two is sufficient. The two types are Organizational Units and Containers. The former is typically represented by a folder type icon with a symbol on it, while the latter is only the folder icon itself.

You may find yourself wondering how this could possibly be a problem, and the answer is “defaults and Group Policy”.

By default, new users without a specified destination are created in the Users container, and computers joined to the domain are routed to the Computers container. The issue with this is that you cannot attach a Group Policy Object to a container, only to an OU. Further, while you technically can delegate access to these containers, these are also the same locations where many of the built-in and sensitive objects are also placed by default.

Some organizations address this by moving the default objects to other locations, which is an option I suppose, however it doesn’t solve the challenge of Group Policy. While some orgs create default images that are pre-hardened, even the most dedicated cannot iterate such items fast enough to keep up with the pace of change in the security space. You also need to manage things like access controls and the like, which should be managed by Group Policy as well. This element is critical, since many orgs tend to depend on Domain Admins to provide access for things like vulnerability scanning and system configuration tools, which is a horrible practice.

Another default in this area is the ability to join systems to the domain. As most admins know, all users have the ability to add up to 10 machines to AD without any special privileges or access. Doing so will naturally result in the computer object showing up in the Computers container. If such a system is infected or otherwise insecure, that will result in exposure of your environment.

Instead of moving default objects, or attempting to engineer your way around things, there is a simpler mechanism. Microsoft provides two command line tools; redirusr.exe and redircmp.exe.

• Create a new “landing zone” OU for both user and computer objects in Tier – 2
• Attach a GPO to each OU to prevent usage or extensive access to the environment until the object is moved to the correct container
• Get the DistinguishedName value of each of the new OUs, and run the related command to change the default locations
• Remove the ability to add systems to the domain by both changing this permission in the GPO at the root of the domain, and by setting the quota to 0 using the below PowerShell

Set-ADDomain -Identity yourdomainname -MachineAccountQuota 0

Set-ADDomain -Identity yourdomainname -MachineAccountQuota 0

Group Policy

The final element I’d like to cover for this first article is management of Group Policies in relation to the OU structure. An absolutely horrible practice in nearly every org I have ever worked with is the frequent use of ‘No Override’ and ‘Block Inheritance’.

For the former, this should never be necessary. If you are concerned that junior admins or desktop/server teams will preempt these values to make their lives easier, then you should ideally not be providing them with access to manage settings. That said, this could result in a much higher burden on the AD team as they work to manage all the various changes that often occur. There are a couple of ways to address this need, without adding excessive overhead to the AD team.

• Mandate Infrastructure-as-Code (IaC)
  • Use Group Policy only to set your general settings that are truly common across the board, as well as ensuring onboarding to the appropriate configuration
  • Use IaC to handle all of your system level settings, ideally via layered elements that separate core OS configuration from application settings
  • Enforce the use of CI/CD for all deployments, and implement tools or scripts to detect and block settings that would result in an insecure state
  • For certain classifications of settings (admin, security, or new items not accounted for in scanning tools), include a human check by InfoSec or your Infra team as a release gate
• Implement a Change Control GPO tool
  • SDM Software has a very reasonably priced tool that can introduce a CI/CD pipeline-like approach to GPO change management, enabling admins to review and approve changes
  • Why this over other options: This tool is the most bang for your buck that I have come across, while still providing enterprise class features and no pressure to buy a suite you may not need
  • Note: Do not implement Microsoft’s Advanced Group Policy Management (AGPM), both because it is not a flexible or scalable tool, and also because MS has announced its deprecation
• Implement a Delegated GPO tool
  • Quest Software’s GPOAdmin tool wins for me in this category, though at a bit higher price point than the above
  • Why this over other options: The key aspect of this tool over others I have reviewed is that it provides more granular controls by enabling admins to disable configuration of certain settings or sections by delegated admins (e.g., you can prevent someone from changing security settings, while enabling configuration of all other areas)

Adopting the above will eliminate the need to set the No Override value. This is important because it often makes troubleshooting of GPO more challenging, particularly when mixed with ‘Block Inheritance’ that often ends up being required to undo the higher level No Override policies.

The latter area, setting ‘Block Inheritance’, is equally problematic. It can prevent the application of critical configuration elements, including those implemented to address security risks or incidents. In addition, having this setting in place is not something that is readily apparent within the standard tools…you have to specifically look for it.

If you have a setting in your general GPOs that can’t be applied to a set of users or systems, you should instead identify the specific settings that are causing the issue, and only override those specific values. Doing this with intent, and ideally adding comments, will enable better tracking and eliminate the need to duplicate policies just to achieve a small change.

The only other area that sort of relates to OUs and GPO, is the prevalence of orgs that create separate GPOs for every single setting and OS version. This not only clutters up AD, making it harder to keep track of desired and applied states, but it also slows down logins. GPOs don’t contain only the values you specify, they contain ALL the settings, just with no values. That means that each GPO a system is in scope for has to be reviewed line-by-line. While this generally happens fairly quickly, I have seen orgs where there are double digits of policies being applied.

If you want to create a GPO to test a group of settings prior to wider deployment, that’s fine, but it should be temporary. Once the testing has been completed and you are ready to deploy broadly, you should incorporate the settings into your standard policies. This helps with both delegation and the ability keep tabs on your desired state for the enterprise.

Conclusion

As tends to happen, this article ran a bit longer than I had initially intended, but I feel like I got a good set of well-rounded coverage for my first topic. Hopefully some of this is helpful in your own endeavors.

Before signing off, there is one more minor issue that technically is not related to OUs, but it is important. Do not ever deny read access to any Group Policy Objects. If you want to exclude a particular set of systems or users from applying a given policy, you have a couple of options. If it’s just a single setting, consider changing it into a Policy Preference via Registry (most GPO settings are just registry values) and then use targeting via group memberships or AD attributes. For multiple settings, add the systems or users to an AD group, add it to the GPO delegation, and add a deny for ‘Apply’. This tells the system to ignore the settings, whereas blocking read causes the system to pause until it times out because all it knows is that there is a policy, so it tries to check the settings. This slows down logins a lot.

Thanks for hanging in till the end! Next time, I will get into how to delegate a variety of tasks in AD while applying least privilege. All too many times, people provide too many rights, or leverage the built-in groups, when it just isn’t needed if you just delegate things the right way.