- Implementing an Organizational Unit (OU) Structure
- Analyzing the Administrative Requirements for an OU
- Creating an OU
- Planning an OU Structure Based on Delegation Requirements
- Exam Cram Questions
- Answers to Exam Cram Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning an OU Structure Based on Delegation Requirements
OUs provide a powerful, yet flexible mechanism for administering a Windows Server 2003 domain. As an administrator, when you look to implement an OU structure, you need to analyze your organization for its requirements prior to putting an OU structure in place. One important consideration is with respect to the OU hierarchy. Because you can nest OUs inside of OUs, you have the ability to create a very granular level of administrative control on a group-by-group basis within your organization. Consider the following example.
Your organization consists of 10 sites (sites are discussed in Chapter 7, "Implementing and Managing Active Directory Sites") corresponding to 10 physical locations in North America, Europe, and Asia. The network consists of three domains: na.wwinc.com, europe.wwinc.com, and asia.wwinc.com. The domains are part of the same forest, so they are connected automatically by two-way transitive trusts (trust relationships were discussed in Chapter 2, "Planning and Implementing Forests and Domains"). The Enterprise Admin team resides at your company's headquarters in Dallas, and each member of the Enterprise Admins group also belongs to the Domain Admins group in each domain. The office in Barcelona is the headquarters for Europe, and that's where the Domain Admins team for europe.wwinc.com resides. The office in Seoul is the headquarters for Asia, and it houses the Domain Admins team for Asia. Each of the seven nonheadquarters physical locations has its own local IT department responsible for its own site.
In this scenario, you want the local IT departments to have administrative permissions for their local offices without granting them permissions at the domain level. In other words, giving them administrative rights should not allow them to administer sites other than their own. This holds true as well for the Domain Admins teams in each country. They should be able to administer their own domains but not other domains. And, finally, the Enterprise Admins team in Dallas should have administrative rights over the entire forest.
In the Windows NT days, this type of complex administrative structure would require creating a multimaster/resource domain model consisting of at least 13 domains (3 master accounts domains and 10 resource domains). Furthermore, you would have to manage a lot of one-way and two-way trust relationships, all manually configured. This would be a messy administrative situation.
Fortunately, with Windows Server 2003 you can use OUs to accomplish your goals. You would start by creating security groups for each IT department. Then you would create OUs for each local site. After that you would delegate administrative permissions for the OUs to the desired security groups (the local IT departments and higher-up IT departments). For example, you create an OU for the Omaha site. You also create all the relevant security groups, including OmahaIT and DallasIT (for North American administration). DallasIT includes the entire Dallas IT department, which has authority over any other site, yet only a subset of DallasIT is in Domain Admins, and only a subset of the na.wwinc.com Domain Admins group is a member of the Enterprise Admins group. After you had done that, you would delegate administrative control of the Omaha OU to OmahaIT and DallasIT (Domain Admins and Enterprise Admins by default have permissions).
Because the Dallas IT group is the highest level of IT in North America, above all the other site-administration groups, you would want to reflect that in your OU structure. Continuing with our example, you can use the nesting ability of Windows Server 2003 OUs to further define the structure. You could then create an OmahaIT OU and nest it inside the Omaha OU. By default, permissions in child objects are inherited from parent objects, so you wouldn't have to explicitly delegate authority to OmahaIT and DallasIT again unless you had disabled propagating permissions. If you had, you would delegate control of that OU to the OmahaIT and DallasIT security groups.
Continuing, you could create further child OUs in the Omaha OU, one for each department that requires separate administration (or even just for categorizing users and groups). Using a hierarchy of OUs, you could even effectively deal with a situation where a local IT department shouldn't have administrative rights to a certain OU, but the Enterprise Admins group should. For instance, if you had a human resources group in Omaha, you could create an HR OU and remove OmahaIT from having propagated administrative rights (from the Omaha OU), remove DallasIT, remove Domain Admins as well, and delegate administrative control to the HR Administrators security group. The HR Administrators group would have administrative rights to its OU but not to any higher-level OUs (such as Omaha OU), and only the Enterprise Admins security group would still have access.
You could move this philosophy of creating an OU hierarchy across domains as well, resulting in a well-structured administrative hierarchy throughout the organization, encompassing all domains and sites.