3

Up until now I have just left all the users and computers in my domain in the domain root.

I've been considering how I might better organize my AD, but I don't see the advantage of using OUs yet.

Right now, I organize everything using security groups, and then apply GPO using security filtering.

If I organize everything by OU, it seems to me all it will allow me to do is remove security filtering on a few GPOs. But it also seems it will make figuring out membership and inheritance more complex overall.

What am I missing here?

I found these two threads where it seems others are similarly confused about how to make good use of OUs:

Structuring an OU to properly model an Organizational Hierarchy
Apply group policy to specific users (in an OU) on specific computers (not in an OU)

Community
  • 1
Daniel
  • 1,614
  • 9
  • 29
  • 47
  • 3
    If your domain is small enough it may not matter to you. Once the domain is past a certain size, linking everything on the root and using security filtering becomes insane. Another 'win' for OUs is delegation of control and access. – jscott Sep 14 '16 at 17:38
  • @jscott That is a perfect answer. You should submit is as such. – longneck Sep 14 '16 at 18:26

2 Answers2

5

Mostly the reason for putting users on OUs is for Organization as the name purposes.

Mainly, the most important reason is GPOs. OUs help you to isolate GPOs, you can direct GPOs by using the security options or WMI filters, but WMI filters are real performance killers, and generally cause slow logon.

Other important benefit is the possibility to delegate control of OU to users. That way you can make your security stronger and delegate functions to non adminsitrator users. The less privileges a user has, the better.

Felipe Donda
  • 476
  • 2
  • 8
  • 1
    If I could put groups of users in a specific OU, and have the policies of that OU apply to the users in the group, WITHOUT the users themselves actually being in the OU, I can envision the OU system as being far more useful. But from reading one of the links above, it seems the system does not work that way. Is that correct? – Daniel Sep 15 '16 at 01:07
  • 1
    **Example**: `Robert.Doe` is in OU `domain.com\Departments\Accounting`. `Robert.Doe` is in group `Accountants` and in group `Administrators`. The group `Accountants` is also in OU `domain.com\Departments\Accounting`. The group `Administrators` is in OU `domain.com\Departments\Administration`. If I link a GPO to `domain.com\Departments\Administration`, should it apply to `Robert.Doe`? – Daniel Sep 15 '16 at 01:10
  • No, GPOs are only applied to users and computers inside the OU or Containers they are linked to. Security groups will only affect GPOs in their security settings. – Felipe Donda Sep 15 '16 at 13:12
  • Seems like a silly and inflexible design, but thanks :) – Daniel Sep 15 '16 at 13:30
  • It makes sense, all domain users are in the group "Domain Users" located in the Users container, if GPOs would apply to groups it would be a hassle to avoid a GPO being applied to some users. It would be necessary to move the default groups to a OU with block inheritance, which would be "ugly". – Felipe Donda Sep 15 '16 at 13:38
  • Still seems like a fault of design. There should be a "Default" OU at the root domain level (in other words, one level down from the root). Then all user-created OUs would start as a different branch from the root. It's only ugly because you have to change the location of the default groups, and in that sense I agree. It wouldn't be ugly if MS has designed it that way from the beginning, and allowed GPO policies to also apply to groups within a linked OU. It just seems to me it would be a much more flexible system. I don't know, maybe there is a good reason why that wouldn't work. – Daniel Sep 15 '16 at 22:08
0

I think that you are asking, why use OUs with GPOs when I can use security groups? I can think of a few reasons:

1) Clarity. If you create a logical OU structure (e.g. create "computer" and "user" base OUs, create "server" and "PC" child OUs under "computer", create "administrators" and "accounting" OUs under PC, etc.) and link GPOs to their appropriate OU without changing the security filter, you will be able to understand at a glance what GPOs are affecting what user or computer groups. If you use security group filtering only, you'll need to examine each GPO's security filter or use some other time-consuming method to see what is going on. If you only have a few GPOs and you are the only person managing the GPOs it may not really matter, but as the number of GPOs and the number of people managing GPOs increases the security group filtering only method becomes very confusing very quickly.

2) Efficiency and manageability. GPOs linked to higher level OUs apply to all subordinate OUs. Through a well designed OU structure, you can effectively apply group policies with pinpoint precision and minimal redundancy. For example, more generic computer policies that apply to both computers and servers should be linked to the computer OU (e.g. generic IE/Edge settings, generic security certificate deployment, powershell environment settings, etc.), policies to apply specifically to PCs (e.g. client only Windows firewall rules, MS Office related rules, client software deployment rules) should be linked to the PC OU, and custom rules should be linked at lower level OUs (e.g. specific file share mapping, special permissions, etc.). If all your GPOs are linked to the same OU, you'll need to remember every time to change the GPO priority order so that more important/specific policies take precedence over more generic policies (this is extremely easy to forget). I think you find that troubleshooting "GPOs not applying" problems becomes much easier if you have a logical OU structure with minimized security group filtering. (NOTE: some group policies, like the group policy loopback policy, can behave in unexpected ways if you use security group filtering).

3) Speed. GPOs that use security group filtering take slightly longer to process. GPOs that use WMI filtering take much longer. It may not matter with only a few GPOs, but when your GPOs start numbering in the hundreds you'll need to think about optimization. If you want to minimize GPO processing times OU-based GPO assignment is the way to go.

wrieedx
  • 750
  • 3
  • 11
  • 23