I've been asked to revamp our Organizational Units (OUs) to enhance our approach to vulnerability testing and deployment, particularly with Group Policy Objects (GPOs). The VP mentioned that each department should have its own OU, with additional sub-OUs dedicated to testing and deployment tasks. These OUs will include user and computer objects that pertain to each department's needs. I'm looking for insights or examples from others on how they structure their OUs to effectively manage vulnerabilities and streamline operations.
5 Answers
It's important to remember that OUs should be accessible by anything needing to read from them. If you're not careful, it could lead to security risks—just a simple LDAP lookup can provide a lot of intel for anyone looking to exploit it.
In our setup, we don’t rely on OUs or GPOs for vulnerability management. Instead, we use our own groups and tags within the vulnerability management system, which keeps things simpler and more efficient.
When it comes to OUs, I think separating user and computer accounts is beneficial for clarity and policy management. It helps to have specific GPOs for different types of accounts to streamline operations and keep things organized.
In my experience, I advise against combining users and computers in the same OU. Have a high-level baseline GPO, then set up an 'override' GPO for exceptions. For example, structure it like this: Root of Domain âž” Admin Accounts âž” Users âž” Org 1 âž” Org 2 âž” Org 3 âž” Servers âž” Workstations. This allows for tailored GPOs for users and computers separately, plus it makes scoping LDAP a bit easier if needed.
I've heard that Microsoft operates with a pretty flat OU structure—sometimes just a single OU or a limited number. One thing to consider is that moving objects between OUs changes their Distinguished Name (DN), which can lead to issues with applications relying on fixed paths, like ORACLE. Also, mixing user and computer GPOs could complicate policy processing, so careful design is essential. You might also run into issues with cross-functional policies if users can only belong to one OU at a time.
That’s a great point! A previous workplace of mine recommended using security groups for policy management instead of complicating the OU structure, which might make things more manageable.
That makes sense! At my last job, we used SCCM for applying fixes through device collections. Unfortunately, I'm not working with SCCM now, but it was quite effective.