Organizational Unit

From Wikipedia, the free encyclopedia

In computing, an Organizational Unit (OU) provides a way of classifying objects located in directories, or names in a digital certificate hierarchy, typically used either to differentiate between objects with the same name (John Doe in OU "marketing" versus John Doe in OU "customer service"), or to parcel out authority to create and manage objects (for example: to give rights for user-creation to local technicians instead of having to manage all accounts from a single central group). Organizational Units most commonly appear in X.500 directories, X.509 certificates, Lightweight Directory Access Protocol (LDAP) directories, Active Directory (AD), and Lotus Notes directories and certificate trees, but they may feature in almost any modern directory or digital certificate container grouping system.

In most systems, Organizational Units appear within a top-level Organization grouping or Organization certificate, though in many systems one OU can also exist within another OU.

[edit] Specific uses

The nomenclature "Organizational Unit" assumes that the structure represents a single organization with multiple units (departments) within the main organization. However, the construction of OUs does not always follow this model. They might represent regions; job-functions separate from the corporate hierarchy (for example: union groupings or job-types that tend to run across all divisions of a company); or an association with an IT group supporting a group of users or objects; or the technology used in relation to the objects.

However, OUs commonly represent job functions, so the structure of OUs tends to follow the structure of a company modelled in organizational or geographical terms. An OU features hierarchy in that it can contain other OUs. Indeed, a domain contains OUs, they function as containers in this sense, and can hold multiple nested OUs.

For AD, Microsoft recommends as few domains as possible and a reliance on OUs to produce structure and policies. Group Policy settings apply most commonly to OUs and not to domains or to groups, which AD stores as Group Policy Objects (GPOs), although GPOs can also model domains or sites. The OU represents the lowest level to which AD can delegate administrative powers. OUs differ from Security Groups in that one can apply Group Policies to them and that they model hierarchies (one can put an OU in an OU.)

In AD, OUs can contain any other unit, including other OUs and so on. OUs let an administrator group computers and users so as to apply a common policy to them.

OUs give a domain a hierarchical structure, and when well designed can ease administration.

[edit] Origins with X.500, Novell, and Lotus Software

The idea of OUs started with X.500 directories. Before implementations of these became common, Novell and Lotus supplied the two largest software directory systems. Each of these companies started with flat account and directory structures, and encountered the support and name-conflict limitations inherent in their flat structures. They adopted the X.500 OU concept into their next-generation software around 1993 -- Novell with the release of Novell Directory Services (subsequently known as eDirectory), and Lotus with the release of the third version of Lotus Notes. Microsoft allegedly used Novell's directory as a blueprint for the first released versions of AD, but this claim appears suspect, given that X.500 served as the "granddaddy" of all directory systems.

NDS/eDirectory features three classes of objects, namely: Roots, Containers, and Leafs. These make up the NDS/eDirectory database. The product supports three types of container objects: Country (C=), Organizations (O=), and Organizational Units (OU=).

Lotus Notes uses the same container classes (Country, Organization, and Organizational Unit). Typically, the form of these levels comes about by setting up a top-level Organization certifier, and then OU certifiers within the O certifier (or within another OU, up to four OUs deep). Any object created with an OU inherits its hierarchy, so for an O called "Acme," with two OUs, "Factory" and "Office" set up within it, the OUs automatically get named "Factory/Acme" and "Office/Acme." If regional OUs appear within these top OUs, they would further reflect the hierarchy as (for example) "East/Factory/Acme", etc. Users and servers created from the certifiers will inherit the OU certifier hierarchies as well, so that user "John Doe" set up within the second-level OU "East/Factory/Acme" will actually have the name "John Doe/East/Factory/Acme," or, canonically: "CN=John Doe/OU=East/OU=Factory/O=Acme" ("CN" stands for "common name"). The "C" (country) level remains optional, and most organizations do not use it within Lotus Notes. User IDs registered without a certifier, and with just a directory entry, can have an arbitrary containment hierarchy; only the certifier hierarchy limits an administrator's naming choices.

In most other directories, the containment hierarchy functions as a strict object-hierarchy, and the OUs actually live within an O, and leaf objects within the OUs; without creating the OU object one cannot create a lower level object utilizing an OU name.