Designing Organizational Unit and Group Structure
This chapter is from the book
This chapter is from the book
This chapter is from the book
Chapter 6: Designing Organizational Unit and Group Structure
In This Chapter
-
Organizational Units
-
Groups
-
OU and Group Design
-
OU Design
-
Using OUs to Delegate Administration
-
Group Policies and OU Design
-
Group Design
-
Sample Design Models
The organization of users, computers, and other objects within the Windows .NET Active Directory (AD) structure gives administrators great flexibility and control over their environments. Both organizational unit (OU) and group structure design can be tailored to fit virtually any business need. There is, however, a great bit of confusion among administrators in the design and use of OUs and groups. Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. With the proper preparation and advance knowledge of their use, however, a functional OU and group design can do wonders to simplify your Windows .NET Active Directory environment.
In addition to the lessons learned from OU and group use in Windows 2000, Windows .NET Server 2003 introduces several functional advantages and improvements to OU and group structure and replication that fundamentally change their design method. Global catalog (GC) caching, incremental universal group replication, and other enhancements have increased the flexibility of OU and group design, and have given administrators greater tools to work with.
This chapter defines organizational units and groups within Windows .NET Server 2003's Active Directory and describes methods of integrating them into various Active Directory designs. Specific step-by-step instructions and "best practice" design advice are given as well. In addition, functional OU and group design models are detailed and compared.
Organizational Units
An organizational unit is an administrative-level container, depicted in Figure 6.1, that is used to logically organize objects in Active Directory. The concept of the organizational unit is derived from the Lightweight Directory Access Protocol (LDAP) standard upon which Active Directory was built, although there are some conceptual differences between pure LDAP and Active Directory.
){kind=small}
Figure
6.1 Active Directory organizational structure.
Objects within Active Directory can be logically placed into OUs as defined by the administrator. Although all user objects are placed in the Users folder by default and computer objects are placed in the Computers folder, they can be moved at any time.
NOTE
The default Users and Computers folders in Active Directory 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 that depend on the functionality of OUs, it is recommended that you move your user and computer objects into an OU structure.
Each object in the Active Directory 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 Active Directory or simply running LDAP queries against Active Directory. For example, in Figure 6.2, a user named Andrew Abbate in the San Jose Users OU would be represented by the following LDAP string:
)
Figure
6.2 Active Directory organizational structure.
NOTE
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 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. See the "OU Design" section of this chapter for more details on this concept.
The Need for Organizational Units
While there is a tendancy to use organizational units to structure the design of Active Directory, 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 Active Directory OUs. An administrator should create organizational units 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, organizational units are not exposed to the directory, meaning that if a user wants to send an e-mail 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, Active Directory 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.