Organisational Units, and how to implement them.

This section of the document will briefly discuss Organisational Units.

Organisational Units, as discussed here, are an important component of Active Directory. These containers are responsible for managing users, security groups, computers and other Sub-OUs.

Whilst these containers can be used simply to store and “contain” (get it, literal speaking over here…) objects, they can also be the target of Group Policy Objects. There are a number of reasons behind this, but here is an example:

Suppose Sales and Admin both require Java 7 Update 71, but Parts require Java 6 update 81 for their PCs.

We’ve got a variance here; both software and departments. To ensure the staff each get their correct version of Java installed, we would:

  1. Create an OU for Sales, Admin and Parts;
  2. Link a GPO to install Java 6 Update 81 to Parts and Java 7 Update 71 to Sales and Admin

Meaning that, if a new object is created in this OU, they will inherit this GPO and get the correct version of Java.

You could create a Security Group, add the members required and then push the policy across the entire domain (it will filter down to only those in the security group); this requires manual intervention to ensure the users are in this group (unless a rename or other over-arching script does this for you).

In some instances, using a GPO linked to an OU as opposed to a Security Group is beneficial – it is reliant on how the IT department handles GPO objects.

On the other hand, using Security Groups has it’s benefits as well; if you restrict NTFS permissions to certain directories based on a group, you can use the same group (I.E. Sales-Staff) to map the drive, have permissions, and install the correct software in the same GPO. Neither way is right nor wrong, and is entirely dependent on the methodology the business implements.