- 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
Analyzing the Administrative Requirements for an OU
One of the most common needs for an administrator is the ability to allow others to manage user accounts. In larger companies, for example, it is often practical to allow desktop support personnel to have the ability to reset user passwords rather than having to go through a network administrator. There's always a fine line between maintaining security and delegating power to others. Windows NT offered the capability to grant others the right to change passwords and other limited administrative control, but these rights were applied on a domainwide basis. As a result, organizations were often forced to create complex multidomain environments to handle the varying administration requirements of different divisions.
For example, suppose your company has a group of software developers that needs to administer itself. The individual developers require administrative-level permissions to their source code and development servers. Your company also has a human resources group that must retain its own individual administration because of the confidential nature of the information it possesses, as well as a legal division that also has to administer itself for similar reasons. Plus, you have the main corporate domain that encompasses most everyone else. In the past, with Windows NT, you would be required to have four distinct domains for this scenario, with carefully managed trust relationships in place so everyone could access the corporate domain. But at the same time, you would have to ensure that the corporate domain could not access the other domains, except for some specific exceptions. Sounds like an administrative headache, doesn't it? Well, consider that as the size of the company grew, often so did its domain structure. The result often wasn't pretty.
Windows Server 2003, though, offers the capability to delegate various levels of control to only parts of a domain. This is accomplished through the use of organizational units (OUs). As discussed earlier, an OU is a container that can hold various Active Directory objects, including user accounts, computers, printers, shares, services, and much more. An OU can be thought of conceptually as a sub-domain: Administrators of a domain can retain control of the OU, but specific rights can also be granted to other users or groups. It is important to note, though, that unlike a real domain, an OU is not a true security boundary and doesn't function in Active Directory like a domain. The OU is the smallest level of organization that can be administered in Active Directory. Using OUs in Windows Server 2003 with our previous scenario, you would be able to use a single domain for your organization and create OUs for developers, human resources, and legal to delegate administration of their groups to the appropriate personnel. Because the delegation is within a single domain, the administrative burden of managing trust relationships and duplicating resources is reduced.
In the next few sections, we will go through implementing an OU structure on your network, including creating an OU and delegating control of it. The scenario you will be following has the engineering department as somewhat of a separate organization, and it has been decided that the engineering department needs the right to change passwords for the division. Tired of changing passwords for marketing people at 2:00 a.m., the IS department agrees. So, IS will create an OU for engineering and also give someone in engineering the right to change passwords within this OU.