When it comes to designing and administering active directory (AD), sometimes less is more. I have worked with a variety of both large and small AD environments where years of change—coupled with inconsistent administrative practices—have resulted in the proliferation of organizational units (OUs) and group policy objects (GPOs) that try to accommodate every possible scenario.
Some AD environments have existed for 20+ years and gone through many different teams, each with their own ideas of how to manage the environment. This often leads to mismanagement, group policy conflicts, and open vulnerabilities. Documentation tends to be out of date or missing altogether. Administrators struggle to make sense of it all and do their best to maintain it with the limited resources available to improve the environment. Without clear standards and processes it is difficult to maintain consistency and operational excellence.
Re-designing a Simpler OU Structure
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
OUs are container objects within AD that group resources that share administrative control or common settings applied through policies. Opinions vary across organizations when it comes to designing an OU structure. In many cases, administrators have tied the OU hierarchy to the real-world organizational structure, using regions, divisions, or departments in their organizational structure. That works until there is an organizational change and then the structure becomes obsolete. Other extremes may use an ad-hoc process where every request for an OU is fulfilled. Regardless of the processes, OUs can quickly get out of control due to the sheer number of requests to satisfy a large number of users, computers, and groups, all of which can lead to an overly complex OU structure.
Without a standardized approach to creating OUs and delegations, the structure can become inconsistent and confusing and lack uniformity. Inconsistency makes it difficult to find and manage objects, increasing the risk of errors, lax permissions, and conflicting policies.
Now is a good time to start adopting a set of criteria to refer to when deciding if a new OU is needed. The following two criteria are a good place to start when determining if it is best practice to create additional OUs:
- Delegation of permissions – When you need to delegate access rights to manage objects and attributes within an OU and its children.
- Application of Group Policy – When you need to apply different group policy settings to a subset of users and computers within that OU.
If neither of those criteria are applicable, you may be able to identify opportunities to consolidate objects and reduce the number of OUs and delegation sprawl. This effort will require an audit of all the delegations within AD and identifying where you can remove or consolidate delegations.
Simplifying the OU structure can bring numerous advantages such as:
- Simplified administration – A streamlined OU structure makes it easier for administrators to manage the directory.
- Policy management – Reduces the risk of conflicting policies and makes it easier to apply and troubleshoot.
- Security – A clear and logical OU structure lowers the risk of misconfigurations that could lead to vulnerabilities.
- Delegation of permissions – A simplified OU structure helps to ensure only the right people have the necessary access for better control and accountability.
You can start simplifying your OU structure by removing legacy delegations that no longer apply because someone has moved on to a different position or where various teams no longer exist. Then start tackling those persistent delegations that could be better aligned with a central technical team. You may be surprised at the level of access some have when digging in. When adjusting delegations, use the principle of least privilege to only delegate what is required.
Reducing Group Policies for Better Control
Group policy proliferation happens when admins are unsure of where to place specific settings, or where there is no standard for when a new group policy is created. Some departments may want to manage their own settings. However, this can lead to various groups blocking inheritance or circumventing security settings that should be applied to all user or computer objects. In some of the environments that I have worked in, there are many policies that are duplicated across multiple OUs. In other cases, there are conflicting policies that yield unexpected results. It takes a lot of time to unwind all the policies to find a root cause for why particular settings are not applying correctly. The following guidelines may help as you evaluate your existing policies and links:
- Consider linking settings that apply to all subordinate users or computers at a higher level in the OU structure to avoid duplication or conflicts.
- Use a consistent naming scheme that helps to identify what the GPO is used for.
- Centralize group policy management to a set of core teams.
- Create a standard that team members can refer to when there is a question about when to create a new GPO.
Consider the following generic diagram as a simple example how Group policy and delegations may be applied to an OU called “Servers” with two child OUs called “Type 1” and “Type 2”. This example may not be applicable for every scenario.
Using group policy inheritance, the mandatory baseline server security settings can be applied to all servers under the servers OU. Whereas any additional settings can be added using GPOs at lower levels. To reiterate, only create additional OUs if you need to:
- Delegate specific permissions to another team to manage objects under the parent OU
- Apply additional GPOs
Lastly, carefully consider the requests that come into your queue. We’ve all been there when a request comes in for a new OU and GPO so that a specific desktop background can be applied to all computers in a single department. Consider how this request may lead to further OU sprawl and administrative overhead, especially as more requests for custom desktop backgrounds come in. To avoid having to make a judgement call, create a standard and obtain management backing. If the request is denied, leverage the standard rather than making it about a judgement call. Some good questions to ask as you consider these types of requests are:
- Does the request increase or decrease compliance and security of the organization?
- Will the request increase company productivity and profitability?
- What impact could this have on the existing structure?
- What is the long-term maintenance and scalability?
- Does the request align with a written standard or best practice?
Setting up for Success
Due diligence Is key to being successful. It takes time to perform a proper analysis. Do not rush the process. When planning for consolidation, start small with one or a few OUs and rack up some successes. Consider the following:
Assess your current state – Review and document the current state of delegations and settings. Remove any conflicts or unnecessary settings.
Define your end goal – Define the future state administrative model and what cases necessitate delegation of permissions. When delegating, practice the principle of least privilege and avoid conflicting settings across policies. Be aware that some settings may break older systems.
Communicate – Create a good communication plan so that those objects that are affected know when a move will take place and who to call if something is not working right.
- Start working through your Change Advisory Board early so that changes don’t conflict with other work being performed.
- Keep your help desk updated as this may cause an influx of calls if something goes awry.
- Consider opening a conference bridge where technical staff can reach the change implementors in case of significant issues
Test – Use test objects that are not connected to production systems and assess the changes that occur. Identify pilot users that can provide real feedback about how that move affected them. Test delegations to make sure that staff have only the necessary rights to continue to do their job effectively.
Understand the Impact – Be aware of the impact a move may cause. Identify any dependencies or constraints and be prepared to move objects back to their original locations. Create a quick fix manual for minor issues so that your first lines of support are well advised on mitigations.
Document – Create a detailed document that lists the changes to delegations and settings and keep it updated as issues arise. Create a schedule of the objects that are moving so you have an approximate timeline. If you need to roll back some or all of the objects moved, you now have a detailed map to help you complete an object restoration.
Wrapping up
When AD environments become difficult to manage due to extensive OU structures and group policies it can become overwhelming to manage. Such complexity increases the administrative overhead and presents a risk to both the productivity and security of the organization. Long-lived AD forests carry the baggage of years of organizational change and administrative changeover. Now is the time to take stock of the environment and build standards and practices that bolster security and help achieve operational excellence. It will require a lot of work to unwind numerous OU’s and GPOs, but it will be worth the effort.
At Ravenswood Technology Group, we specialize in helping organizations design, implement, and manage their Active Directory environments. If you need help getting started, review some of our other blogs such as Active Directory Design Overview | AD Security. We can also work with your team to provide an assessment using our Active Directory Health Check – Ravenswood Technology Group.
Get in touch with Ravenswood Technology Group today to learn how we can help you achieve a well-designed, secure, and efficient Active Directory environment.
