This chapter is from the book
This chapter is from the book
This chapter is from the book
Sample Design Models
Although the possibilities for OU and group design are virtually unlimited, often the same designs unfold because business needs are similar for many organizations. Over time, three distinctive models that influence OU and group design have emerged. The first model is based on a business function design, where varying departments dictate the existence of OUs and groups. The second model is geographical based, where remote sites are granted separate OUs and groups.
Business Function–Based Design
CompanyA is a clothing manufacturer based in St. Louis, Missouri. Facilities for the company are limited to a small group of locations in Dayton that are connected by T1 lines. A central IT department directly manages approximately 50% of the computer infrastructure within the company. The rest of the company is remotely managed by the following independent groups within the company:
Sales
Manufacturing
Design
Management
Historically, there have been five NT domains within the organization, as shown in Figure 6.12. Each domain was created to give each department autonomy and administrative control over its own environment.
The NT domains were connected via two-way trusts and were named as follows:
IT_NT
SALES_NT
MANUF_NT
DESIG_NT
MNGMT_NT
)
Figure
6.12 Multiple Windows NT4 domain structure.
OU Design for a Business Function–Based Design
While the culture of the company revolves around this decentralized business approach, the IT department wanted to consolidate these domains into a single AD domain, while at the same time preserving the administrative autonomy that the various departments had with the old environment. The result was a single Active Directory domain named companya.com that utilized five separate OUs, one for each department, similar to the structure shown in Figure 6.13.
)
Figure
6.13 Organizational unit design.
To create this structure, the resource domains were collapsed into the single AD domain with the use of the Active Directory Migration Tool (ADMTv2). For more detailed analysis of this procedure, see Chapters 16, "Migrating from NT4 to Windows .NET Server 2003," and 17, "Migrating from Windows 2000 to Windows .NET Server 2003."
Administrative rights were assigned to each OU by creating special global groups whose members included the local administrators for each department, as displayed in Figure 6.14. These groups were then delegated password change, user creation/deletion, and other typical administrative capabilities on their respective department's OUs through use of the Delegation of Control Wizard (see the "Delegation of Administration with OUs" section earlier in this chapter).
)
Figure
6.14 Delegation control task completion.
Group Design for a Business Function–Based Design
A group structure was created with five separate global groups that contained users from each department. The global groups were named as follows:
IT Global
Sales Global
Manufacturing Global
Design Global
Management Global
Resources were assigned domain local groups that followed a standard naming scheme, such as that represented in the following examples:
Printer1 DL
FileServer3 DL
VidConfServer1 DL
Printer3 DL
Security rights for all resources were then given to the appropriate domain local groups that were set up. The global groups were added as members to those groups as appropriate. For example, the printer named Printer3 was physically located in an area between both the Design and the Sales departments. It was determined that this printer should be accessible from both groups. Consequently, printing access was given to the Printer3 DL group, and both the Design Global and Sales Global groups were added as members to the Printer3 DL group, as shown in Figure 6.15.
)
Figure
6.15 Nesting groups to assign permissions.
This type of resource security allowed for the greatest amount of flexibility and reduced the replication of group membership needed in the domain. If, at a later time, the decision is made to allow the IT department to print off Printer3 as well, simply adding the IT Global group into the Printer3 DL group will do the trick.
Geographical-Based Design
As was the case with the business function–based design model, domain structures can easily be tailored to the needs of organizations with geographically dispersed locations, each with its own sets of administrators. It is important to understand that simply having sites in remote locations does not immediately warrant creation of an OU for each site. Some type of special local administration is required in those remote sites before OU creation should be considered.
Keeping this point in mind, consider the example of CompanyB. It is an international semiconductor producer that is centralized in Sacramento, California, but has worldwide remote branches in Malaysia, Costa Rica, Tokyo, Australia, Berlin, and Kiev, as shown in Figure 6.16.
Administration takes place on a continent-by-continent basis. In other words, Berlin and Kiev are both managed by the same team, and Tokyo and Malaysia use the same administrators. Australia administers its own users, as does Costa Rica.
)
Figure
6.16 Sample trust design of full domain-to-domain trusts.
OU Design for a Geographical-Based Design
The AD designers at CompanyB determined that the local administrative requirements of the branch offices were best served through the creation of OUs for each administrative region. A Europe OU was created for users in Berlin and Kiev, and an Asia OU was created for Tokyo and Malaysia. The three other sites were given individual OUs, as shown in Figure 6.17.
)
Figure
6.17 Redesign using organizational units instead of domain trusts.
Group Design for a Geographical-Based Design
Domain local groups were created to grant access to each OU on a resource basis. For example, a domain local group named Europe OU DL was created for application of security to the Europe organizational unit. To apply this security, the Delegation of Control Wizard was run on each OU, and each corresponding domain local group was granted Administrative access to its own respective OUs.
Membership in the domain local groups was only the first step for allowing CompanyB's administrators to manage their own environments. Global groups were created for each IT team, corresponding with their physical location. For example, Berlin IT Admins Global and Kiev IT Admins Global global groups were created, and each IT admin user account for the remote locations was added as a member of its respective groups. The two global groups were then added as members of the Europe OU DL domain local group, as shown in Figure 6.18. The same process was applied to the other OUs in the organization. This solution allowed for the greatest degree of administrative flexibility when dealing with permissions set on the OUs.
Each administrative team was consequently granted a broad range of administrative powers over its own environment, allowing each team to create users, change passwords, and effectively administer its own environments without the need for broad, sweeping administrative powers over the entire domain.
The added advantage of this design is that it is completely flexible, and administrative control can be re-delegated on the fly, so to speak. For example, if a branch office opens in Paris, and IT administrators in that location need to have equivalent administrative control over the Europe OU, a simple global group can be created and added as a member to the Europe OU DL domain local group. Removing permissions is subsequently straightforward. In addition, entire OU memberships can effectively be collapsed into a different OU structure, as required by the changing needs of different organizations.
){kind=small}
Figure
6.18 Nested delegation of control.