Microsoft Windows Server 2003 Unleashed (R2 Edition)
| 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 FunctionBased 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:
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. Figure 6.12. Multiple Windows NT4 domain structure.
The NT domains were connected via two-way trusts and were named as follows:
OU Design for a Business FunctionBased Design
Although 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 used 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 Windows NT4 to Windows Server 2003," and 17, "Migrating from Windows 2000 to Windows 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 "Using OUs to Delegate Administration" section earlier in this chapter). Figure 6.14. Delegation control task completion.
Group Design for a Business FunctionBased Design
A group structure was created with five separate global groups that contained users from each department. The global groups were named as follows:
Resources were assigned domain local groups that followed a standard naming scheme, such as that represented in the following examples:
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. This flexibility is the main goal of this type of design. Geographical-Based Design
As was the case with the business functionbased 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. Figure 6.16. CompanyB legacy domain 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. 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 domains.
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 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. Figure 6.18. 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 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. |
Категории