Organizational Unit Permissions
A particularly useful type of directory object contained within domains is the organizational unit. Organizational units are Active Directory
containers into which you can place users, groups, computers, and other organizational units. An organizational unit cannot contain objects from other domains. An organizational unit is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority.Using organizational units, you can create containers within a domain that represent the hierarchical, logical structures within your
organization. You can then manage the configuration and use of accounts and resources based on your organizational model.
As shown in the figure, organizational units can contain other organizational units. A hierarchy of containers can be extended as necessary to model your organization's hierarchy within a domain.
Using organizational units will help you minimize the number of domains required for your network. You can use organizational units to create an administrative model that can be scaled to any size.
A user can have administrative authority for all organizational units in a domain or for a single organizational unit. An administrator of an organizational unit does not need to have administrative authority for any other organizational units in the domain.
Organizational Units
Having covered the large-scale (domains, trees, and forests) view of Active Directory, it is now time to discuss the small scale view of Active Directory. When you look inside an Active Directory domain, you will see a hierarchical structure of objects. This hierarchy is made up of objects that can act as containers and objects that cannot. The primary type of container that you will create to house objects is called an organizational unit (OU). Another type of container, which is actually called a container, can also be used to store a hierarchy of objects and containers. Although both can contain huge hierarchies of containers and objects, an organizational unit can have group policies applied to it.Let us illustrate this with an example. Imagine that you are the administrator of the asia.mycorp.com domain from Figure 2-7. You have 500 users and 500 computer accounts in the domain. Most of the day-to-day account and machine management is very simple, but the manufacturing section is currently undergoing restructuring and an extensive recruitment program; people keep being transferred in or hired from the outside. You would like to be able to give this group limited autonomy over user objects by allowing one of the senior administrators to manage its own section of the tree. Complete segregation of security is not needed, and the manufacturing tree is not large enough to justify creating another domain to manage along with the associated domain controllers. You can instead create an organizational unit in your hierarchy called Manufacturing. You then give the senior engineer authority over that organizational unit to create and delete accounts, change passwords, and create other organizational units within the Manufacturing OU. Obviously, the permissions that the senior engineer would be given would be properly tailored so that he had control over only that organizational unit and not the asia.mycorp.com domain tree as a whole. You could do this manually or delegate control using the Delegation of Control Wizard.
When you install an Active Directory domain, a number of default containers and organizational units are created automatically, including the Users and Computers containers and the Domain Controllers OU.
If you try to create a new container, you will find that there is no option to do so from within the Active Directory Users and Computers (ADUC) MMC snap-in. This also applies to Organization, Locality, and Country container objects. This is intentional; in almost all cases, you would want to create an
organizational unit instead of a container. It is possible to create the other types of containers from within scripts and other LDAP tools, but generally it is not necessary.
Throughout this book, whenever we advocate creating hierarchies within domains, we always recommend that you use organizational units. After all, an organizational unit is just a superset of a container.
There is nothing a container can do that an organizational unit cannot.
