Windows Server 2008 : Designing Organizational Unit and Group Structure - Exploring 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, two 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 geographically based, where remote sites are granted separate OUs and groups.

Examining a 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

Detailing OU Design for a Business Function–Based Design

Although the culture of the company revolves around a decentralized business approach, the IT department wanted to consolidate 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 AD DS domain named companya.com that used five separate OUs, one for each department, similar to the structure shown in Figure 1.

Figure 1. Organizational unit design.

To create this structure, resources were created in the single AD domain. Administrative rights were assigned to each OU by creating special global groups whose members included the local administrators for each department. 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 .

Detailing 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 2.

Figure 2. 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. This flexibility is the main goal of this type of design.

Understanding Geographically 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 set 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 3.

Figure 3. Sample administrative structure.

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.

Outlining OU Design for a Geographically 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 4.

Figure 4. Redesign using organizational units instead of domains.

Examining Group Design for a Geographically 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 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 5. 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.

Figure 5. Nested delegation of control.

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 redelegated 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.