AD/OU Question

pcgizzmo

We are looking at restructuring our AD at my current company. Currently we have it broken into a geographical structure. Regions, then broken down into OU's for organization purposes in each region such as HR, IT etc.. We recognize this as not being good because there are no policies applied to these OU's they are just that way for visual organization.

One of the admins has recommended we break with the geographical structure and just have a "Users" OU. Then we would apply group policy via security filters/groups. Computers would still be based on geographical location so that we could apply policy to to servers and PC in specific locations if need be.

The thought process is that users change often. They change locations, jobs etc. and we get our user information from a JDE database. We could run scripts against fields in the database to match up w/attibutes in AD and apply security groups and policy based on these attributes.

As it is now we have to manually go in and move users from differing locations and to differing OU's. By doing it the way the admin suggests we would not have to manually move the users and the security groups would automatically get applied.

I've never done it this way and his thought process actually makes sense to me. We are considering his suggestion.


Thoughts either good or bad????

MitM

I've always had an Users OU under each geographical location, and applied proper policies. However, like you said, it's a manual or script effort to move them when the users move.

I don't see anything "wrong" with your idea, could just get confusing with the all the security filtering

blargoe

I used to apply GPOs at the AD Site level for geographic settings such as the correct file or update server. Doing OU's that way makes sense if you are delegating rights to a remote tech to the objects in that office.

For me, if there isn't a settings or security reason to split objects into OUs, I don't do it. I've seen people break out OU's by Operating System, by department (in excruciating detail), different OUs for full employees vs contract to hire types, and every time it adds complexity that is not required if you are not creating different policies for these OUs.

I have top level OUs for Servers and Workstations (for computer objects), Admins, Users, and Service Accounts (for User objects) and a scattering of other special purpose OU's for one off stuff like objects created when adding a unix or esx server to the domain or OUs for testing policies. If there is a policy need to split those OUs, we do it, but we do not treat OUs like a filing cabinet for people to browse like they would organize their folders in Windows Explorer.

But, YMMV as always. Everyone has their favorite way to do things I guess.