When do you really need an organizational unit in Active Directory?

Question

I have to grant some permissions to a certain user in Windows Server 2003 Active Directory that will only be active on a certain collection of users. The initial thought was to just have an OU that we would allow this particular user certain rights to (user creation, password reset, add users to groups, etc.). However, after reading further in to things, I'm not sure if an OU is needed or not, and I'm really not sure when an OU would ever be needed. This is bugging me and I would really like to better understand the purpose of OU's before using or not-using them.

I've searched the web quite a bit and results vary from the vague "Use organizational units to organize AD" to the somewhat specific "Add an OU to a domain if a completely separate group needs special administrative access to a segment of users." At this point, the later sounds the most appropriate here. Technically speaking, you can only use the Delegation of Control Wizard on an OU. However, I see nothing stopping me from manually assigning the permissions individually to a domain group and effectively having the same thing. What am I missing here? Thanks.

Izzy · Answer 1 · 2009-10-12T21:30:10.743

OUs are used to organise objects in Active Directory. A typical example would be as follows:

myDomain.loc
├─Users
├─Servers
│ ├Domain Controllers
│ └Member Servers
└─Workstations
  ├New York
  ├London
  └Brisbane

This makes it easier to differentiate objects in the domain visually, rather than having to rely on memory or digging around. Using this structure you can also apply policies to specific containers. You could have a general Internet Explorer policy applied to the Workstations OU so it applies to all child objects in that tree. You can then set specific Internet Explorer settings to the sub-OUs (for example, different policies that set the IE Home Page for London workstations, another than sets a different homepage for the new York workstations etc.)

In your specific example it seems you want to delegate AD control to a group of users. In this case the right method is to create a new security group and make all the target users a member of that group. Then, you would open AD Users and Computers, right click on the OU you want the users/group to have control over, and select Delegate Control.

Now... if you organise your AD properly, you can have granular control over what you want that group of users to have control over. For example, you could create a group called NewYork-Admins, and delegate control for that group JUST to the New York workstations, instead of all workstations.

An ideal AD structure for this type of delegation would be a structure as silimar to the following:

myDomain.loc
├─Domain Controllers
├─Special Users
└─Locations
  ├─New York
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  ├─London
  │ ├─Users
  │ ├─Workstations
  │ ├─Servers
  │ ├─Contacts
  │ ├─Servers
  │ └─Groups
  └─Brisbane
    ├─Users
    ├─Workstations
    ├─Servers
    ├─Contacts
    ├─Servers
    └─Groups

This allows you to delegate control to AD objects in a very granular way.

score 2 · Accepted Answer · answered Oct 12 '09 at 21:50

In general OUs are used for:

Keeping things clean and structured. Your users are kept away from groups, your groups are kept away from computers, objects in site A are kept away from objects in site B, and so on.
Delegation of control. Only really needed if you have multiple levels of access or multiple sites with different admins in each. Even so I would plan ahead and set things up to enable it anyway.
Group policies. Not totally necessary as policy application can be managed via either permissions or WMI filters, but all the same it helps to know that if a user is in OU X they get policy Y.

Note that in the above you cannot apply a GPO to a container, so if you don't create OUs you will have to set all of your GPOs at top (Domain) level and filter them using either WMI or security. It's easier for you and for everyone else to just use OUs except for if you have a scenario where the specific policies you want/need cannot be done (or can be done but are messy) using an OU model.

Aside from the obvious technical requirements in my last 2 points, I think that keeping things clean and tidy is reason enough. It's easier to find the object you want out of a list of 100 than it is to find it out of a list of 1500, for example. It also separates the objects you create (users, computers and groups, mostly) from builtin objects, which can help to prevent nasty accidents ("OK, who deleted the Administrator account?").

score 0 · Answer 3 · answered Oct 12 '09 at 21:11

I created two OUs, one to store "Employees", and the other to store clients who need to authenticate to our FTP servers.

The reason that I used OUs is that some of my devices can authenticate against LDAP, but don't (seem?) to recognize group membership only. Also, it "felt" better to cordon off external accounts. If I had a bigger infrastructure with more clients, I would have created their own domain for them.

When do you really need an organizational unit in Active Directory?

3 Answers3