CGIAR Active Directory Design Assessment DRAFT. 18 September 2007

CGIAR Active Directory Design Assessment DRAFT 18 September 2007 1170 Hamilton Court Menlo Park, California 94025 www.cgnet.com

Table of Contents 1. Executive Summary...3 2. Introduction...4 3. Alternative Active Directory Designs...5 3.1. Structures in an Active Directory Design...5 3.2. Design Alternatives...6 4. Specification of Architecture for the CGIAR Active Directory...14 4.1. Policies...14 4.2. Rationale...16 4.3. Discussion of Initial Design...18 4.4. Discussion of Current Situation...19 5. Recommendations...21 CGIAR Active Directory Assessment 2 18 September 2007

CGIAR Active Directory Design Assessment 1. Executive Summary The CGIAR centers implemented global directory services in the form of Microsoft Active Directory (AD) between May 2003 and September 2005. Since then, the Active Directory has been operating. Occasionally, issues have arisen that have raised the question of whether the Active Directory could have been designed differently. This report addresses that question by reviewing the Microsoft design guidelines for Active Directory and comparing them to the CGIAR s implementation. Definitions of key terms are reviewed, and alternative designs are presented, together with the advantages and disadvantages of each. The designs are then compared to the CGIAR implementation by reviewing the implementation s policies and rationales. The reasons for the original implementation are discussed. We find that the primary motivations for a Single Forest/Multiple Domain AD design were to provide system-wide access to resources while preserving each center s administrative autonomy to the greatest degree possible. Other key considerations were to ease the implementation by allowing centers to preserve information from their previous domains and to avoid excessive replication of information among domains, particularly over low-bandwidth connections. This rationale is then examined against the issues that have arisen since then. The report finds that the issues identified are not directly affected by the design of the Active Directory, and it recommends that the existing design be maintained. The report also finds that performance of the current Active Directory may be improved by increasing the frequency with which information is replicated among domains. CGIAR Active Directory Assessment 3 18 September 2007

2. Introduction The networks of the different centers of the CGIAR are currently administered through a common directory services structure, Microsoft s Active Directory (AD). Active Directory provides a single unified system with which to manage its computing resources. AD is also required by organizations hosting Microsoft Exchange servers, for versions 2000 and above. The CGIAR centers joined the Active Directory Forest between May 2003 and September 2005. All the centers have been operating with Active Directory since then. Occasionally, issues have arisen about whether resources have been effectively administered under Active Directory, including instances when various resources have not worked as planned or have performed poorly. As a result, the purpose of this study is examine the current Active Directory design, compared to best practices, to see whether it is the best design for the CGIAR s current needs. In the course of this examination, the study will also identify any improvements that can be made to the existing system, short of changing the design. Our examination relies upon Microsoft TechNet documents and documentation from CGNET s docad.cgiar.org site. This site provides the policies and rationale for the Active Directory design, in addition to copious detail about other aspects of the project. The site is password protected. Usernames and passwords for entry are available to appropriate CGIAR personnel upon request. We also discussed the design with CGNET engineers. This scope of this study does not extend to considering alternatives to Active Directory itself. Given the costs and the years of effort that have gone into implementing Active Directory, the upgrades to Microsoft Exchange that depend upon Active Directory, and the implementation of other applications, such as Live Communications Server, that also depend on AD, completely eliminating Active Directory is, at this point, a much greater project than redesigning it. If this study finds huge issues with the continuing use of Active Directory by the CGIAR, a second study of alternatives to AD could be undertaken. CGIAR Active Directory Assessment 4 18 September 2007

3. Alternative Active Directory Designs In order to assess whether the CGIAR s current Active Directory design is the best for the needs of the CGIAR, we will first examine the possible alternative designs that could be used. 3.1. Structures in an Active Directory Design To understand the discussion of alternative Active Directory designs that follows, we will first briefly review the structures that can be arranged in an Active Directory design. Active Directory defines both logical and physical structures for network components. Logical structures are: Domains A group of computers that share a common directory database. Domain Trees One or more domains that share a contiguous namespace. Domain Forests One or more domain Trees that share common directory information. Organization units A subgroup of domains that often mirrors the business or functional structure of the company. Physical structures are: Subnets A network group with a specific IP address range and network mask. Sites One or more subnets; they're used to configure directory access and replication. 1 Domains, domain Trees, domain Forests, and organization units are logical structures in Active Directory. They are used to create an Active Directory s design. Sites and subnets are physical structures represented by devices identified by TCP/IP addresses. Physical structures are thus defined within the AD logical structures. Active Directory uses the naming conventions of the Internet s Domain Naming Service (DNS). This is most important in understanding the 1 Stanek, William R., Using Active Directory Service, Microsoft Windows 2000 Administrator s Pocket Consultant, Chapter 5. Reproduced on Microsoft TechNet: http://technet.microsoft.com/en-us/library/bb726976.aspx. CGIAR Active Directory Assessment 5 18 September 2007

difference between AD Trees and Forests. All the elements in an Active Directory Tree share a contiguous namespace, which means that their domain names share successively common names. If the parent domain name is, for example, cgiarad.org, child domain could be ilri.cgiarad.org, but not ilri.cgiar.org. Child domains can have further child domains, such as addis.ilri.cgiar.org. Each child domain has to build on a parent domain name, and each successive child in the hierarchy has to build on the higher-order structure. This is not true in an Active Directory Forest, which can contain multiple Trees, each building from a different parent domain name. As Microsoft Consulting Services puts it, A Microsoft Windows 2000 Domain is identified by a boundary of security (for example, authentication and domain-level security policies) and replication, and it is distinguished by a unique namespace. Multiple Domains can be joined hierarchically in a contiguous namespace to form a Tree. Multiple Domains and/or Domain Trees can be joined (potentially with a non-contiguous namespace) to form a Forest. All Domain Controllers in a Forest share a common Global Catalog, Configuration and Schema. 2 3.2. Design Alternatives The important variables in an AD design are Forests, domains and Trees, and how they are associated with sites and subnets. The questions are how many Forests, domains and Trees each AD implementation should have, and how the domains should be associated with the sites and subnets. Organization units are defined within domains and have much more flexibility than Forests, Trees and domains. Thus, defining them really comes after the overall design resolves the roles of Forests, Trees and domains. In general, the basic rule is to have as few of any of these logical structures as possible, largely for the reasons of clarity of design and ease of administration. What is possible, however, is governed by the needs of the particular organization being served by the Active Directory implementation. Here is Microsoft s discussion of why more than one domain may be necessary in an implementation: 2 Microsoft Consulting Services, Windows 2000 Domain Architecture: Design Alternatives, Microsoft TechNet, January 01, 2002. http://technet.microsoft.com/enus/library/bb742583.aspx. CGIAR Active Directory Assessment 6 18 September 2007

3.2.1. Alternatives for Assigning Domains When designing a Domain Architecture, the recommended approach is to start with a single Domain and add additional Domains as necessary providing specific justification for the creation of each Domain. Possible reasons for creating additional Domains are itemized below: Administrative Considerations (Politics). Decentralized organizations often have different groups of administrators responsible for managing users and resources throughout the organization. For example, each Organization in Company A has their own set of administrators, which manages the organization users and resources. Some organizations are further decentralized, from an administrative perspective, along geographic boundaries. These administrators may not want to share control of a Domain. For example, a Domain Administrator can always gain access to and take ownership of objects within its Domain. However, a delegated OU Administrator does not have this ability. Unique Policies. Different locations or Organizations may have unique security and administration policies, which may require separate domains. Network Traffic. By creating multiple domains, network traffic is reduced because only changes to the Global Catalog, Configuration and Schema are replicated between Domains. Within a Domain, the entire Domain database, as well as the contents of the SYSVOL partition (which includes Logon/Logoff Scripts and Group Policy Objects), are replicated to all Domain Controllers in the Domain. Note: Although the entire Domain database is replicated to each Domain Controller in a Domain, the impact on link traffic is mitigated. After initial replication, only changed properties are replicated. In addition, with the use of Sites, replication traffic can be scheduled and is compressed significantly. Network Connectivity. Within a Domain and between Sites the RPC Inter-site Connector must be used; you cannot use the SMTP Inter-site Connector within a Domain. If your network cannot support RPC between locations (low or intermittent bandwidth and/or high network latency), then you must use the SMTP Inter-Site Connector. However, the SMTP Connector cannot be used to replicate the Domain Naming CGIAR Active Directory Assessment 7 18 September 2007

Context. Put another way, if the SMTP Connector must be used, then it must be used between Domains. Capacity. Should the number of objects in a Domain significantly exceed one to two million objects, a separate Domain should be considered. International Differences. Differences in languages and business practices could require separate domains. Namespace Requirements. Organizations may have a requirement for one or more specific DNS domain names. In-place Upgrade of Existing Domains. A possible Coexistence and Migration Strategy is to upgrade existing domains in-place, with an eventual migration to a domain architecture that is different than the current domain architecture, requiring the implementation of "temporary" Windows 2000 domains. Additional Design Considerations for Domains Design for the minimum number of domains. The larger the number of domains to administer, the higher the administrative costs and the more likelihood of adjustment during reorganizations. Design for a minimum depth of the domain hierarchy. A good rule of thumb: if you can't remember the FQDN of the domain, then it's probably too long. Choose stable (static) constructs for Domains. A good design will withstand company reorganizations without the need to restructure the domain hierarchy. Each Domain requires at least one Domain Controller to hold the Domain database and provide services such as Domain Authentication. For most Domains, however, it is recommended that at least two Domain Controllers should be available in each Domain for fault tolerance. This may affect the decision to create additional domains. During migration from Microsoft Windows NT 4, a multiple-domain architecture may be maintained during a period of coexistence, thereby creating "transient" Windows 2000 domains. These domains may later be collapsed into a smaller number of Windows 2000 domains. Certain policies can only be applied at the Domain Level. If any of these policies need to be unique for specific logical CGIAR Active Directory Assessment 8 18 September 2007

organizations (such as Organizations), then different Domains must be created. Examples include: Password (length, expiration) Account lockout (threshold, duration) Kerberos (ticket lifetime) Encrypted File System (recovery) IP Security (usage level) Public Key Certificate Authorities The root domain (for instance, the first Domain that is installed in a Forest) cannot be renamed. It is critical to select the correct name for this Domain up front. The root domain cannot be removed from the Forest. It is even more critical that the root domain be based on stable criteria and has longevity. Child domains can be removed from the Forest. Deep LDAP searches submitted to a Domain Controller will only generate referrals within the Tree to which the DC belongs. Deep LDAP searches submitted to a Global Catalog will generate referrals to any Domain within the Forest.... Active Directory Domains can be used to control replication. From a Domain perspective, all properties of all objects within the Domain are replicated to all Domain Controllers within that Domain. Further, Global Catalog servers contain a partial replica (all objects, selected properties) of all Domains in the Forest. To reduce the amount of domain data that is maintained in a DC (or to reduce the amount of domain data that is replicated to a DC), separate Domains can be created. Although replication between Sites is compressed and scheduled, initial replication to Domain Controllers in remote sites can be significant. Strategically locating Domain Controllers and Global Catalog servers can be used (as an alternative to creating additional domains) to mitigate this issue. For example, we can consider placing DC's and GC's in regional IT hubs, as opposed to every remote office. One trade-off that should be considered is trusting your network for logons vs. trusting your network for replication. 3 3 Ibid. CGIAR Active Directory Assessment 9 18 September 2007

3.2.2. Alternatives for Assigning Forests Similar issues need to be considered when deciding whether to use a single Forest or multiple Forests. Microsoft Consulting says, the recommended approach is to start with a single Forest and add additional Forests only if necessary providing very specific justification for the creation of each Forest. In almost all cases, it is envisioned that a single Forest will work for even the largest companies. 4 3.2.3. Overall Design Alternatives Microsoft Consulting defines six design alternatives for an Active Directory implementation: Single Domain Multiple Domains to form a Tree; Domains based on Organization. Multiple Domains to form a Forest; Domains based on Organization. Multiple Domains to form a Tree; Domains based on Geography. Multiple Domains to form a Forest; Domains based on Geography. Multiple Forests; Forests based on Organization. 5 3.2.3.1. Forest or Tree? To simplify the discussion, let us first resolve the question of whether to base domains on Trees or Forests. The advantage of using a Forest instead of a Tree structure is that organizations are able to maintain their existing namespaces, which are not required to be part of a contiguous namespace. This was not necessary in the CGIAR AD implementation, because the namespaces being defined were new. Thus, as we shall see below, the overall implementation contained one Forest and one Tree. The Tree and the Forest, in the CGIAR s case, were identical. 4 Ibid. 5 Ibid. CGIAR Active Directory Assessment 10 18 September 2007

3.2.3.2. Organization or Geographic Tree? Second, let us resolve the question of whether, in the case of a design with multiple domains, a Tree or Forest structure ought to be structured on an organizational or a geographical basis. Microsoft Consulting presents the following advantages and disadvantages of a geographic Tree model, compared to a single domain or an organization Tree model: Advantages Domain Architecture not likely to change, as geographic boundaries are generally stable. Helps to optimize network traffic, as all intra-domain replication is constrained within a geographic region and WAN is typically also modeled along geographic boundaries. Reduced hardware requirements (and associated capital and administrative costs). Geographies, regions or campuses that house multiple Organizations may be able to share Domain Controllers across Organizations. Consistent Domain Level policies across Organizations. Each Domain Controller maintains a full replica of a smaller portion of the enterprise than the single domain model resulting in faster logons, reduced hardware requirements and more manageable backup/restore. Reorganizations, acquisitions and divestitures of Organizations will not require Domain restructuring. Instead, OU restructuring can be performed in such cases, which is a much less expensive operation. User and resource transfers between organizations (yet remaining in the same geography) are much simpler to manage. Isolates language dependencies within a country. Disadvantages Political implications in that administrators in different organizations must "share control" of a Domain. However, this can be partially mitigated with delegation of administration at the first level OU level. Security policies are applied at the geographic level, which may not meet unique business requirements for an Organization. Domain level policies are applied at the geographic level, which may not meet unique business requirements for an Organization. However, applying Organization Policies at the first level OU level can mitigate this. 6 6 Ibid. CGIAR Active Directory Assessment 11 18 September 2007

In the case of the CGIAR, an organization Tree and a geographic Tree model would in fact be very similar to each other. This is due to the geographic dispersion of the CGIAR centers, where most of the local resources were grouped both organizationally and geographically. The exception to this statement is when remote offices of a given center are located closer to another center. As we shall see below, the decision was made to create an organization Tree, with the understanding that many of the characteristics of the geographic Tree would also apply. A truly geographic Tree, based on geographic regions rather than centers would have given the regional domain administrators authority to make all of the domain-specific administrative decisions, where centers have usually considered their directory services to be autonomous. This consideration had to be balanced against the relatively limited advantages of a geographic model, given the centers geographic dispersion. 3.2.3.3. Single Domain or Multiple Domains? Given the strong similarities between the organization and geographic structures, and between the Forest and Tree structures, in the case of the CGIAR, the main remaining choice of models is between using a single domain versus multiple domains. Microsoft Consulting lists the following advantages and disadvantages for a Single Domain: Advantages Some of the advantages of this model include: Centralized administration of security policies for the entire enterprise. Consistent domain-level policies for the entire enterprise. Organization Unit hierarchy provides distributed administration of Organization objects. Extremely flexible model for acquisition, divestiture and reorganizations. Extremely flexible model for user and resource (in fact any object) moves. No need for Global Catalogs every Domain Controller has a full replica of all objects in the enterprise directory. Also a disadvantage see below. Geographies, regions or campuses that house multiple Organizations may share Domain Controllers. Straightforward namespace design a single DNS name. Models the Organization hierarchy, so CGIAR Active Directory Assessment 12 18 September 2007

o o Users are familiar with this model, making it easy to browse and query Unique Organization policies can easily be applied Disadvantages Some of the disadvantages of this model include: Organizations do not have sense of "ownership". Who are the Domain Administrators for this single domain? Security Policies must be identical across the entire enterprise. Every Domain Controller has a full replica of all objects in the enterprise directory. Although a single partition of the Active Directory will likely scale to support the total number of objects in the Company enterprise directory, the hardware requirements for every Domain Controller would be significant. Logon performance will be impacted. Backup and Restore will be more time-consuming, resourceintensive and complicated. Inefficient use of network bandwidth every property of every object in the enterprise directory would be replicated to every Domain Controller. Of course, only deltas are replicated and sites can be used to control replication schedule and to compress data, but nevertheless every single property change in the directory must get replicated all around the world. Think about the impact of things like password changes. 7 The key to deciding whether to adopt the simple, flexible Single Domain or to employ multiple domains, depends, therefore on the particular characteristics of the organization(s) involved. We turn now to the specific circumstances of the CGIAR AD implementation, and the rationales for the design decisions that were made. 7 Ibid. CGIAR Active Directory Assessment 13 18 September 2007

4. Specification of Architecture for the CGIAR Active Directory 4.1. Policies Before the CGIAR Active Directory was implemented, the following policies were agreed upon: Single Forest The CGIAR will have a single Active Directory Forest. DNS Namespace and Design The Root Domain of the CGIAR Active Directory Forest will be called CGIARAD.ORG. The primary and secondary DNS zones will be hosted at CGNET Services International. The name will be registered with the Internic, but will not be resolvable externally. CGIARAD.ORG name resolution will be handled by local DCs first; forwarding goes to root. External name resolution will be forwarded to the CGNET NOC DNS servers. Local ISPs at each center will be designated as secondary resolvers for non domain controllers. Domain controllers at each center will point to themselves as primary and other local domain controllers as secondary resolvers. Single Tree Structure All CGIAR Active Directories will join the CGIARAD Forest, under the same CGIARAD.ORG Tree structure. Dedicated Forest Root The Root of the CGIAR Active Directory Forest will be hosted by CGNET in Menlo Park California at the Menlo Park Site. Site Topology Each physically separate location should be a Windows Active Directory Site. Initially, this will correspond to the center s domain. For example, the Domain isnar.cgiarad.org will be located in the Hague Site, below the Forest Root. Extra sites may be created for branch offices where bandwidth issues demand it. Multiple Domain Structure Number and Boundaries Each center will establish its own domain below the Forest root. CGIAR Active Directory Assessment 14 18 September 2007

Branch offices may join the center domain or create new domains on the same level or as child domains. 8 This structure can be depicted in the following diagram: Diagram 3.1 8 CGIAR docad.cgiar.org, the documentation site for the AD and Exchange 2000 implementations. Section 2.7.1 Forest Architecture. http://docad.cgiar.org/policies/adarch/forest (username and password on request). CGIAR Active Directory Assessment 15 18 September 2007

4.2. Rationale In 2003, when the policies above were established, they were justified with the following rationale: Single Forest There are situations in which the level of security or the level of need for autonomy between different administrative groups might justify multiple AD Forests. The disadvantages of the difficulty of sharing resources, the lack of common global catalogs, the dramatic increase in administrative and maintenance costs, the inability to host an Exchange 2k organization across Forests these all outweigh the other considerations in favor of a single Forest AD structure for the CGIAR. DNS Namespace and Design Each domain must have its own unique DNS name. DNS names for Active Directory can be considered internal In other words, they relate to Active Directory address space, not to the public Internet address space. Internal (ie. CGIARAD.ORG) names will not be resolvable from the internet. The CGIARAD.ORG name will be registered with the Internic, but parked so that it s unresolvable externally. Centers will also have external DNS names for resources they want to be publicly accessible from the internet. These DNS names will resolve IP addresses in the publicly accessible Internet address space (e.g. CGIAR.ORG). All Active Directory DNS domains will be sub domains of the CGIAR root. Since CGIARAD.ORG is an Active-Directory-integrated zone, CGIARAD.ORG hostnames in DNS will be replicated to local DCs at the centers. They will then bear primary responsibility for resolving these domain names locally (from their caches). For resolution of external names, local DCs should forward DNS queries to the DNS servers at the root; the rationale for this is to reduce the load on local DCs. Local ISPs at the center can be designated as secondary resolvers for non DCs, in case the primary (local DC) resolver is temporarily unreachable. CGIAR Active Directory Assessment 16 18 September 2007

Single Tree Structure Simpler for users and administrators to navigate and understand. LDAP searches in a Tree can always be resolved by LDAP referrals. (LDAP referrals are only valid in the Tree from which a search is initiated.) The only major point in creating multiple Tree structure is to allow multiple root domain names (non-contiguous name space). This increases admin and maintenance costs. Sometimes done to tighten access, but not necessary in this case. Dedicated Forest Root Limiting the Forest root domain administrative membership reduces the likelihood that an administrative error will impact the entire Forest. A small root domain can be easily replicated anywhere on your network to provide protection against geographically centered catastrophes. You can never retire the root domain, even if your organization changes. A dedicated root domain never becomes obsolete because it functions solely as the Forest root... Multiple Domain Structure Although a single domain structure is the easiest to manage and delegate administrative authority, less costly in terms of hardware and administration time, a multiple domain structure allows delegation of administrative authority to trusted users at a domain level, reducing workload of centralized administrator and increasing security because administrator rights over users and resources limited to domain level. Multiple domains reduce the single point of failure if an AD domain is getting restored. If the current NT structure is one of multiple domains, then it is generally easier to move to multiple domains in AD a one-toone mapping of domains is the easiest migration patch when upgrading to AD. And the number one reason for choosing a multiple domain structure is - multiple domains can isolate need for intradomain replication over slow wan links. It is best if all devices within a domain can easily reach a domain controller over a high bandwidth connection. 9 9 Ibid. CGIAR Active Directory Assessment 17 18 September 2007

4.3. Discussion of Initial Design Discussions with people who were present when the initial decisions on the design of the CGIAR Active Directory were made provide some emphasis to some of the points mentioned above. The most important reason for the current CGIAR AD design was that each center wished to maintain as much autonomy as possible in how it provided administrative services to its own users. While the AD would allow better sharing among centers, this was probably less important than simply being able to be compatible with newer versions of Exchange, which have become much easier to manage than Exchange 5.5. The second most important reason is related to the first, in that the current structure was one of multiple NT domains. Since the current NT structure at the time was one of multiple domains, moving to multiple AD domains allowed any or all of these domains to move to AD via a domain upgrade rather than a resource migration. This option was advantageous to the centers for the migration process allowing for preservation of their permissions structure for all users and group objects rather than having to manually recreate these in AD. What seemed like the most important consideration at the time, that of avoiding global replication within a Single Domain, particularly when insufficient bandwidth might be available in some cases, seems less important now, since Microsoft has provided alternative ways to deal with this issue in subsequent versions beyond Windows 2000. It is still true, however, that a Single Domain structure might cause performance issues, such as slower times for local logins, and the other considerations mentioned above. CGIAR Active Directory Assessment 18 18 September 2007

4.4. Discussion of Current Situation It can be argued that, in fact, the main reasons for selecting CGIAR s Active Directory design were fundamentally based on what Microsoft Consulting would call political considerations, plus considerations based on what would be the most effective and convenient way to carry out the implementation. But it is also possible that the configuration that resulted is, in fact, the best one possible. The key criteria for making this decision are whether the CGIAR centers feel that administering their own domains is preferable and whether the Active Directory s operation over the last two to four years (depending on when a center joined the Forest) reveals problems with the configuration that would best be solved by reconfiguring the design. CGNET s engineers are in the position of responding to any difficulties with administering the Active Directory because of CGNET s responsibilities under the system-wide contract and its role as administrator of the AD root domain. Issues attributed to Active Directory have tended to fall into two categories. The first is that on occasion, changes to one of the center-level domains have taken time to propagate across the entire directory, resulting, in some cases, in messages being sent to the wrong mailboxes. The delays in question are a matter of a few hours, and the result is only that a message is refused by the incorrect mailbox. This is, however, an irritating issue. How this issue is related to the design of the Active Directory, however, is another question. The fact is that under any other design, such as a Single Domain, propagation might take as long or longer. In addition, such delays might be added to local logins as well as situations, like email, where resources in one domain are looking up resources in another. A response to this issue might be to increase the frequency of the replication schedule. The way that replication among domain controllers currently works is that a domain controller at the root polls the other domain controllers on a regular schedule and then transmits any updates to the center-level domain controllers. This now takes place every three hours. It is possible to increase the frequency of these activities. A good new frequency might be every hour. A second class of issues is when an application either shows poor performance across the CGIAR, particularly on AD-related matters such as user authentication. A recent example of this was the slow authentication of CGIAR staff users in CGXchange. In every case that CGNET engineers can CGIAR Active Directory Assessment 19 18 September 2007

recall, an examination of these problems revealed that something in the application had to be adjusted and that the problem was not with the fundamental structure of the Active Directory. This also applies to whether an application is able to take advantage of the single sign-on capabilities of AD. All indications are that completeness of single sign-on depends how the application supports it, not on how Active Directory has been designed. It is possible that under some imaginable circumstances, a move to a geographically based structure, as opposed to the current organization-tree structure, could be considered. For example, if the CGIAR decided to consolidate its Exchange servers in regional locations, in order to use fewer servers and have fewer locations where Exchange administration would be required, it might make sense to adjust Active Directory to that regional configuration. On the other hand, this is not strictly necessary. It is possible to have Exchange servers in one domain and users in another within the same Active Directory Forest. And if such a regional AD structure were adopted, we would once again have to revisit the question of whether regional administration of several centers would be acceptable to each center. CGIAR Active Directory Assessment 20 18 September 2007

5. Recommendations This examination of alternative Active Directory designs and of the rationale for the current CGIAR Active Directory design concludes that the design principles provided by Microsoft Consulting, which reflect the best practices of the industry, coincide fairly directly with the current CGIAR AD configuration, when the centers needs for autonomy and possible bandwidth-related considerations are taken into account. We have not found existing issues that would be better resolved by redesigning the Active Directory, and we note that the original implementation took several years. Absent major issues, there seems to be no reason to consider another effort of that scope. We therefore recommend that the current CGIAR Active Directory design be retained. We further recommend that the frequency of replication of information among domain controllers be increased, as discussed above. CGIAR Active Directory Assessment 21 18 September 2007