Designing the Administrative Structure

After you interview the stakeholders and identify the administrative responsibilities, it is time to design the high-level overview of the administrative structure. When documenting the administrative structure, you should describe the administrative functions performed by each of the administrative groups. The documentation should also contain a breakdown of the resources and who is responsible for them. List the resource permissions at a high level. This will not be a resource-by-resource security list. For example, the administrators who are responsible for file servers at a location will be identified, but the individual shares and files will not be listed.

Real World Scenario ”Research and Development

A popular home appliance manufacturer was moving from a Microsoft Windows NT 4.0 network infrastructure to Active Directory. When designing the Active Directory and network infrastructure, it was noted that the Research and Development (R&D) department was a completely autonomous business unit. For years the data that they had collected, the communication systems they used, and all of the users were kept completely separate from the corporate network. Their physical location was even separate from the corporate offices.

When the initial design phase was started, the corporate offices were included in the design, but the R&D group was not. They remained on NT 4.0 and functioned as they had done for years. When the corporate policies dictated that all of the system had to be upgraded from NT 4.0 to either Windows 2000, Windows XP, or Windows Server 2003, the initial reaction from the Active Directory team was to create a new domain for the R&D division. After all of their years of autonomy, political battles ensued. The corporate team wanted to retain a single schema for the entire enterprise, whereas the R&D team did not want to have anyone to have access to their resources.

Although access to the resources within the proposed R&D domain could be restricted to administrative staff from the R&D division, the whole idea of an all-powerful group such as Enterprise Admins scared the R&D administrators. They argued that there was no need for any of their data to be on the corporate network. For years they had maintained their own directory service with NT 4.0, and they knew how to work with Active Directory. They wanted to maintain their autonomy and have their own forest.

The battle waged on until the powers-that-be, upper management, decided that the R&D division should retain its autonomy. They had proven that they knew how to secure their resources, and those resources were not required on the corporate network. By creating the new forest, the R&D administrators had their own control over their schema and all of the administrative groups. This decentralized model is the most extreme case of a single organization having multiple forests, but the political nature of most companies can force an issue such as this.

 

As seen in Table 1.1, one method of documenting the administrative control is to create a resource administration matrix. The data for this matrix can be entered into a database or spreadsheet and reports can be printed out to detail the resource listing and the associated administrators or sorted so that the administrators are listed with the resources for which they are responsible.

Table 1.1: The Administration Matrix

Domain	Resource	Administrative Group	Permissions
Domain A		Enterprise Administrators	Full Control
		Domain A Administrators	Full Control
Domain B		Domain B Administrators	Full Control
	Exchange Server	Domain B Administrators	Full Control
		Messaging Administrators	Messaging Administration
		Messaging Techs	Server Administration
	DHCP Server	Domain B Administrators	Full Control
		Network Techs	Server Administration
	WINS Server	Domain B Administrators	Full Control
		Network Techs	Server Administration

Once this information is collected and documented, you can use it when you re designing other aspects of the Active Directory and network infrastructure. Active Directory resources can be identified and grouped within OUs for easy delegation of control. This includes servers, workstations, user accounts, shared folders, printers, and other OUs. The forest and domain ownership can also be identified, aiding in the logical Active Directory design.

Figure 1.12 shows an OU design based on administrative responsibility.

Figure 1.12: OUs designed for administrative control

Note  

Chapter 5 goes into greater detail concerning creating an efficient OU administrative design.