An organizational unit is an administrative-level container, depicted in Figure 1,
that is used to logically organize objects in AD DS. The concept of the
organizational unit is derived from the Lightweight Directory Access
Protocol (LDAP) standard upon which AD DS was built, although there are
some conceptual differences between pure LDAP and AD DS.
Objects within Active Directory
can be logically placed into OUs as defined by the administrator.
Although all user objects are placed in the Users container by default
and computer objects are placed in the Computers container, they can be
moved at any time.
Note
The default Users and
Computers folders in AD DS are not technically organizational units.
Rather, they are technically defined as Container class objects. It is
important to understand this point because these Container class objects
do not behave in the same way as organizational units. To be able to
properly utilize services such as Group Policies, which depend on the
functionality of OUs, it is recommended that you move your user and
computer objects from their default container locations into an OU
structure.
Each object in the AD DS
structure can be referenced via LDAP queries that point to its specific
location in the OU structure. You will often see objects referenced in
this format when you’re writing scripts to modify or create users in AD
DS or simply running LDAP queries against AD DS. For example, in Figure 2, a user named Paul Cochrane in the SF sub-OU of the Locations OU would be represented by the following LDAP string:
CN=Paul Cochrane,OU=SF,OU=Locations,DC=companyabc,DC=com
Note
The
OU structure can be nested, or include sub-OUs that are many layers
deep. Keep in mind, however, that the more complex the OU structure, the
more difficult it becomes to administer and the more time consuming
directory queries become. Microsoft recommends not nesting more than 10
layers deep. However, it would be wise to keep the complexity
significantly shorter than that number to maintain the responsiveness of
directory queries.
OUs primarily satisfy
the need to delegate administration to separate groups of
administrators. Although there are other possibilities for the use of
OUs, this type of administration delegation is, in reality, the primary
factor that exists for the creation of OUs in an AD environment.
|
Although there is a tendency
to use organizational units to structure the design of AD DS, OUs
should not be created to just document the organizational chart of the
company. The fact that the organization has a Sales department, a
Manufacturing department, and a Marketing department doesn’t suggest
that there should be these three AD DS OUs. An administrator should
create OUs if the departments will be administered separately and/or
policies will be applied differently to the various departments.
However, if the departments will all be administered by the same IT
team, and the policies being applied will also be the same, having
multiple OUs is not necessary.
Additionally, OUs are not
exposed to the directory, meaning that if a user wants to send an email
to the members of an OU, he would not see the OU structure nor the
members in the OU grouping.
To see members of an
organizational structure, AD DS groups should be created. Groups are
exposed to the directory and will be seen when a user wants to list
members and groups in the organization.
|
