I've been assigned to revamp our Organizational Units (OUs) to facilitate vulnerability testing and the deployment of Group Policy Objects (GPOs). Our VP has suggested that each department should have its own OU, with sub-OUs dedicated to testing and deployment. These OUs are intended to hold both user and computer objects for each department. I'm looking for insights and examples from others on how they've organized their OUs for better vulnerability management.
4 Answers
In my experience, we don’t use OUs or GPOs; instead, our vulnerability management system has its own tags and groups. This way, we can manage vulnerabilities without worrying about the complications of OUs.
In my opinion, it’s better not to mix users and computers in the same OU. You can use the GPO processing order to set a baseline at the top level, then have separate GPOs for specific exceptions. For instance, you could structure it like this: Root of Domain, Admin Accounts, Users, Org 1, Org 2, Org 3, Servers, Workstations. This method provides distinct GPOs for users and computers while also allowing discussions about specific policies for things like security settings.
Just a thought: OUs should be organized so that they can be accessed by anything interacting with them. However, this can pose serious operational security (opsec) risks, as it allows potential bad actors access to detailed insights about your structure via simple LDAP lookups.
I’ve heard that companies like Microsoft often keep everything under a single OU or have a very limited number of OUs. One downside to creating a complex OU structure is that moving objects between OUs changes their Distinguished Names (DN), which can lead to issues with applications relying on that structure, such as Oracle. Also, mixing user and computer GPOs in an OU can slow down policy processing. It’s important to consider how cross-functional policies would work if users are restricted to one OU at a time.
Thanks for pointing that out! The previous system engineering team suggested using security groups for policy management instead of complicating the OU structure. It seems like a good way to avoid those issues.
At my last company, we used SCCM to apply fixes through device collections, which made things so much easier. Unfortunately, I don't have SCCM in my current role.