Active Directory Restructuring Recommendations

Transcription

1 Active Directory Restructuring Recommendations Version Final September 7, 2004 Authored By: Jenn Goth Microsoft Services jgoth@microsoft.com Contributors: Brian Redmond Microsoft Services briar@microsoft.com

2 Table of Contents 1 INTRODUCTION LOGICAL & PHYSICAL ACTIVE DIRECTORY STRUCTURE FOREST & DOMAIN DESIGN CONCEPTS CMU FOREST & DOMAIN DESIGN NAME RESOLUTION SITES, SERVERS & SUBNETS ORGANIZATIONAL UNITS CONCEPTS CMU ORGANIZATIONAL UNIT DESIGN DELEGATION OF ADMINISTRATION CONCEPTS CMU ADMINISTRATIVE MODEL NAMING STANDARDS ORGANIZATIONAL UNITS GROUP POLICY OBJECTS COMPUTER OBJECTS USER OBJECTS SERVICE ACCOUNTS GROUPS DFS CMU SPECIFIC ABBREVIATIONS MIGRATION PLANNING...37 Active Directory Restructuring Recommendations Page 2

3 1 Introduction CMU Computing Services is in the process of determining ways to simplify their existing Active Directory infrastructure and prepare to support Exchange They have already planned to migration existing accounts and resources to this new structure after the upgrade of the existing domain controllers is successfully completed. The purpose of this document is to discuss the new architecture and design decisions that will be implemented as part of the new Active Directory structure. It is intended to provide a high-level conceptual overview of the core Windows components. Detailed implementation and migration plans will need to be developed to deploy the design documented in the following sections. Active Directory Restructuring Recommendations Page 3

4 2 Logical & Physical Active Directory Structure 2.1 Forest & Domain Design Concepts A domain tree comprises several domains that share a common schema and configuration, forming a contiguous namespace. Domains in a tree are also linked together by trust relationships. Active Directory is a set of one or more trees. Trees can be viewed two ways. One view is the trust relationships between domains. The other view is the namespace of the domain tree. You can draw a diagram of a domain tree based on the individual domains and the existing trust relationship. Windows establishes trust relationships between domains based on the Kerberos security protocol. Kerberos trust is transitive and hierarchical if domain A trusts domain B, and domain B trusts domain C, then domain A trusts domain C. You can also draw a diagram of a domain tree based on the namespace. You can determine an object's distinguished name by following the path up the hierarchy of the domain tree namespace. This view is useful for grouping objects into a logical hierarchy. The chief advantage of a contiguous namespace is that a deep search from the root of the namespace searches the entire hierarchy. A forest is a set of one or more domain trees that do not form a contiguous namespace. All trees in a forest share a common schema, configuration, and global catalog. All trees in a given forest exchange trust according to transitive hierarchical Kerberos trust relationships. Unlike trees, a forest does not require a distinct name. A forest exists as a set of cross-reference objects and Kerberos trust relationships recognized by the member trees. Trees in a forest form a hierarchy for Active Directory Restructuring Recommendations Page 4

5 the purposes of Kerberos trust; the tree name at the root of the trust tree refers to a given forest. The following figure shows a forest of non-contiguous namespaces. Active Directory Restructuring Recommendations Page 5

6 2.2 CMU Forest & Domain Design Active Directory Design CMU had originally intended to migrate to a new AD forest model from the existing AD forest. After much debate, the decision was made to keep the existing domain structure and modify it according to the current needs. Most of the benefits of a new forest can be obtained during a migration, so the value of the new forest was somewhat limited. Note: One goal of the new forest was to eliminate the empty forest root domain. In keeping the existing forest, there is no method to removing this forest root domain, so this goal cannot be met. The diagram below gives an overview picture of the CMU AD forest/domain structure: Any department that requires their own AD forest will be integrated with the central ad.cmu.edu forest via cross-forest trusts. This will allow those departments to leverage the user accounts contained in the ANDREW domain, and still provide the autonomy of their own forest environment. Active Directory Restructuring Recommendations Page 6

7 2.2.2 Exchange Considerations The computing services team is also beginning the process of designing an Exchange 2003 messaging environment. One of the initial thoughts for this design is to establish a messaging resource forest model, where users from other departments that may or may not have their own Active Directory environments are able to have their mailbox hosted by computing services in a centrally managed forest. In this case, Microsoft recommends that the existing andrew.ad.cmu.edu forest be used to house Exchange (effectively making it an Exchange resource forest. This will allow CMU to reduce hardware requirements and reduce management complexity. The Andrew domain design already provides for trusts from other Active Directory forests, so departments that have their own AD environment can have their user accounts in their forest and their Exchange mailboxes in the Andrew forest. The Andrew domain design also maintains a user account for all CMU users, so departments that do not have their own AD environment can leverage the user account that exists in ANDREW domain by mailbox-enabling the account. Why not an Exchange Resource Forest? In general, the pure Exchange Resource Forest (ERF) scenario is a deployment option for centralizing exchange messaging within an organization, while still maintaining one or more independent AD domains for employee network access. This scenario is common in large enterprises or in disparate organizations where the enterprise is comprised of many independent departments or companies, each with its own IT department and AD domains, yet still wishing to centralize their exchange messaging while minimizing the impact on employees. The ERF consists of an AD domain that is dedicated to running Exchange and is separate from the external AD domain(s) where the users are located. For every user account that exists in the external AD domain(s), an equivalent "placeholder" user account is created in the ERF and provisioned with a mailbox. The mailbox rights settings for each mailbox can be modified to allow access by the original user in the external AD domain. A one-way trust is established between the ERF and the external AD domains so users that authenticate to an external AD domain automatically gain access to the ERF environment. The security of the external AD domain is preserved since user and administrative accounts in the ERF environment do not automatically link back to the AD domain. Since CMU already has a forest/domain structure that contains all CMU users and there are currently no identified administrative requirements that force Exchange to be in a separate forest, the andrew.win.cmu.edu forest can be leveraged for Exchange for the majority of users. Only those users who log on to an Active Directory user account in a different forest (e.g. Tepper) would leverage this proposed environment in the classic ERF. This allows CMU to make the best use of their organizational and financial investment in the andrew.ad.cmu.edu environment Active Directory Domain Rename One of the original reasons to migrate was the requirement to change the namespace to be based upon a win.cmu.edu suffix. Windows Server 2003 introduced the domain rename function for active directory. In order to meet this requirement, both domains in the ad.cmu.edu forest would need to be renamed. Renaming a domain is a very intrusive operation and it should be done with extensive planning and testing. Active Directory Restructuring Recommendations Page 7

8 Active Directory Rename Considerations The AD rename operation is not a seamless activity. Some things that you will expect are: The forest will out of service for a short period which could cause service disruption briefly. Member computers of the domain must be re-booted after the rename (NT 4.0 machines would need to be unjoined/rejoined). Each DC in the forest would need to be updated individually and re-booted. Below are some domain rename constraints: The forest root of the domain can be renamed, but it must stay the forest root of the domain and cannot be removed. No domains can be removed or merged as a part of the rename operation. Some of the supported domain rename operations are: Rename the DNS name of a domain Rename the NetBIOS name of a domain Rename the forest root domain Restructure a domain Move any non-root domain under a new parent domain in the same forest Move any non-root domain to a new tree in the same forest Active Directory Restructuring Recommendations Page 8

9 CMU Domain Rename Process The picture bellows shows the process. In this case, it will make sense to rename the forest root domain first to win.cmu.edu. Once this is complete, the andrew domain can be moved to become a child domain in the new tree Exchange related domain rename Though AD fully supports a domain rename operation in Windows 2003, Exchange 2003 did not support it until SP1 of Exchange After the domain rename, you must run some additional cleanup scripts for Exchange to work properly. Refer to these articles for additional info: , Exchange System Attendant Does Not Start After You Rename a Windows Server 2003 Domain , How to use the Exchange Domain Rename Fix-up tool Active Directory Restructuring Recommendations Page 9

10 2.3 Name Resolution Concepts The Active Directory directory service servers publish their addresses such that clients can find them knowing only the domain name. Active Directory servers are published using the Service Resource Records (SRV RRs) in DNS. The SRV RR is a DNS record used to map the name of a service to the address of a server that offers the service. The name of a SRV RR is in this form: <service>.<protocol>.<domain> Active Directory servers offer the LDAP service over the TCP protocol so that published names are ldap.tcp.<domain>. Thus, the SRV RR for fabrikam.com is ldap.tcp.fabrikam.com. Additional data about the SRV RR indicates the priority and weight for the server, enabling clients to choose the best server for their needs. When an Active Directory server is installed, it uses Dynamic DNS to publish itself. Because TCP/IP addresses are subject to change, servers periodically verify their registrations to be sure they are correct, and update them if necessary. Dynamic DNS is a recent addition to the DNS standard. Dynamic DNS defines a protocol for dynamically updating a DNS server with new data. Prior to Dynamic DNS, administrators were required to manually configure the records stored by DNS servers CMU Name Resolution Design DNS The andrew.ad.cmu.edu forest will be switching to using CMU s BIND environment for name resolution. The following DNS zones must be enabled for dynamic updates: andrew.ad.cmu.edu ad.cmu.edu The dynamic updates will be restricted to allow only the three domain controllers to perform this function. This permissioning is accomplished by allowing only the IP addresses that correspond to the domain controller servers update the zone. Note: The long term goal is to move to a namespace of andrew.win.cmu.edu via a domain rename. At this point, these DNS zones will no longer be needed. Active Directory Restructuring Recommendations Page 10

11 The architecture is summarized in the following diagram: Sites, Servers & Subnets Concepts Sites & Subnets A site is a group of computers in one or more IP subnets. You use sites to map the physical structure of your network. Sites mappings are independent from logical domain structures, and because of this there's no necessary relationship between a network's physical structure and its logical domain structure. With Active Directory, you can create multiple sites within a single domain or create a single site that serves multiple domains. There is also no connection between the IP address ranges used by a site and the domain namespace. Computers are assigned to sites based on their location in a subnet or a set of subnets. If computers in subnets can communicate efficiently with each other over the network, they're said to be well connected. Ideally, sites consist of subnets and computers that are all well connected. Windows Server 2003 uses site information for many purposes, including routing replication, client affinity, system volume replication, DFS, and service location. Active Directory uses a multimaster, store-and-forward method of replication. A domain controller communicates directory changes to a second domain controller, which then communicates to a Active Directory Restructuring Recommendations Page 11

12 third, and so on, until all domain controllers have received the change. To achieve the best balance between reducing replication latency and reducing traffic, site topology controls Active Directory replication by distinguishing between replication that occurs within a site and replication that occurs between sites. Within sites, replication is optimized for speed data updates trigger replication and the data is sent without the overhead required by data compression. Conversely, replication between sites is compressed to minimize the cost of transmission over WAN links. When replication occurs between sites, a single domain controller per domain at each site collects and stores the directory changes and communicates them at a scheduled time to a domain controller in another site. Domain controllers use site information to inform Active Directory clients about domain controllers present within the closest site as the client. For example, consider a client in the Seattle site that does not know its site affiliation and contacts a domain controller from the Atlanta site. Based on the IP address of the client, the domain controller in Atlanta determines which site the client is actually from and sends the site information back to the client. The domain controller also informs the client whether the chosen domain controller is the closest one to it. The client caches the site information provided by the domain controller in Atlanta and queries for the site-specific service (SRV) resource record (a DNS resource record used to locate domain controllers for Active Directory) and thereby finds a domain controller within the same site. By finding a domain controller in the same site, the client avoids communications over WAN links. If no domain controllers are located at the client site, a domain controller that has the lowest cost connections relative to other connected sites advertises itself (registers a site-specific SRV resource record in DNS) in the site that does not have a domain controller. The domain controllers that are published in DNS are those from the closest site as defined by the site topology. This process ensures that every site has a preferred domain controller for authentication. For more information about the process of locating a domain controller, see the Directory Services Guide of the Windows Server 2003 Resource Kit. The system volume (SYSVOL) is a collection of folders in the file system that exists on each domain controller in a domain. The SYSVOL folders provide a default Active Directory location for files that must be replicated throughout a domain, including Group Policy objects (GPO), startup and shutdown scripts, and logon and logoff scripts. Windows Server 2003 uses the File Replication service (FRS) to replicate changes made to the SYSVOL folders from one domain controller to other domain controllers. FRS replicates these changes according to the schedule that you create during your site topology design. DFS uses site information to direct a client to the server that is hosting the requested data within the site. If DFS does not find a copy of the data within the same site as the client, DFS uses the site information in Active Directory to determine which file server that has DFS shared data is closest to the client. By publishing services such as file and print services in Active Directory, you allow Active Directory clients to locate the requested service within the same or nearest site. Print services use the location attribute stored in Active Directory to let users browse for printers by location without knowing their precise location. Active Directory Restructuring Recommendations Page 12

13 Naming Contexts Each domain controller in an Active Directory forest includes directory partitions. Directory partitions are also known as naming contexts. A directory partition is a contiguous portion of the overall directory that has independent replication scope and scheduling data. By default, the Active Directory for an enterprise contains the following partitions: Schema Partition: The schema partition contains the classschema and attributeschema objects that define the types of objects that can exist in the Active Directory forest. Every domain controller in the forest has a replica of the same schema partition. Configuration Partition: The configuration partition contains replication topology and other configuration data that must be replicated throughout the forest. Every domain controller in the forest has a replica of the same configuration partition. Domain Partition: The domain partition contains the directory objects, such as users and computers, associated with the local domain. A domain can have multiple domain controllers and a forest can have multiple domains. Each domain controller stores a full replica of the domain partition for its local domain, but does not store replicas of the domain partitions for other domains. Windows Server 2003 introduces the Application Directory Partition, which provides the ability to control the scope of replication and allow the placement of replicas in a manner more suitable for dynamic data. In Windows 2000, the support for dynamic data is limited. Storing dynamic data in a domain partition can be complicated. The data is replicated to all domain controllers in the domain which is often unnecessary and can result in inconsistent data due to replication latency. This can adversely impact network performance. In addition, domain partitions are not effective for applications that must replicate data across domain boundaries. Another option in Windows 2000 is to store dynamic data in attributes marked as non-replicated. However, this arrangement is limited in that it has a single point of failure, namely, the single domain controller housing the only copy of the object's non-replicated attributes. Application directory partitions provide the ability to control the scope of replication and allow the placement of replicas in a manner more suitable for dynamic data. As a result, the application directory partition provides the capability of hosting dynamic data in Active Directory, thus allowing ADSI/LDAP access to it, without significantly impacting network performance. The Windows 2000 DNS service is an example of a service that can take advantage of application directory partitions. In Windows 2000, if the DNS service is optionally configured to use Active Directory, the DNS zone data is stored in Active Directory in a domain partition. That is, the data is replicated to all domain controllers in the domain, regardless of whether a DNS server is configured to run on the domain controller. This is an instance where full domain-wide replication is unnecessary. By storing the DNS zone data in an application directory partition, the service can redefine the scope of replication to only that subset of domain controllers in the domain that actually run the DNS server. Types of data that can be stored in an application directory partition include: An application directory partition can contain instances of any object type except security principals, such as users, computers, or groups. Objects in an application directory partition can maintain DN-value references to other objects in the same application directory partition, to objects in the configuration and schema partitions, and Active Directory Restructuring Recommendations Page 13

14 to any naming context head (which is the top object of a directory partition, such as the domaindns object at the top of an application directory partition). Some limitations of application directory partitions include: Objects in an application directory partition cannot maintain DN-value references to objects in other application directory partitions or domain partitions. Likewise, objects in Domain, Configuration, and Schema Partitions cannot maintain DN-value references to objects in an application directory partition. A DN-value reference can be maintained to the naming context head. Objects in an application directory partition are not replicated to the Global Catalog. As with any domain controller, a global catalog server can also be configured to contain a full replica of an application directory partition, but the application directory partition data is completely separate from the global catalog data. When an application directory partition replica is created, the Domain-Naming FSMO role must be on a Windows Server 2003 family operating system and later domain controller. After the application directory partition replica is created, the Domain Naming FSMO role can be assigned back to a Windows 2000 domain controller. Application directory partition objects cannot be moved to other Active Directory partitions outside the partition in which they were created. Other application directory partition features include: The security and access control model for the application directory partition is the same as that for other partitions in Active Directory. The time intervals that control the latency of initiating an originating change notification to replication partners within a site can be configured separately for each application directory partition basis. Application directory partitions can be named just as regular domains, attached anywhere in the Active Directory namespace where a domain can, and discovered using DNS even by down-level Windows 2000 systems. An application directory partition can be created, its replication scope defined, and its configurable settings adjusted programmatically using standard LDAP and ADSI APIs Global Catalog Servers Active Directory can consist of many partitions or naming contexts. The distinguished name (DN) of an object includes enough information to locate a replica of the partition that holds the object. Many times however, the user or application does not know the DN of the target object or which partition might contain the object. The global catalog (GC) allows users and applications to find objects in an Active Directory domain tree, given one or more attributes of the target object. The global catalog contains a partial replica of every naming context in the directory. It contains the schema and configuration naming contexts as well. This means the GC holds a replica of every object in Active Directory but with only a small number of their attributes. The attributes in the GC are those most frequently used in search operations (such as a user's first and last names or login names) and those required to locate a full replica of the object. The GC allows users to quickly find objects of interest without knowing what domain holds them and without requiring a contiguous extended namespace in the enterprise. The global catalog is built automatically by Active Directory replication system. The replication topology for the global catalog is generated automatically. The properties replicated into the global Active Directory Restructuring Recommendations Page 14

15 catalog include a base set defined by Microsoft. Administrators can specify additional properties to meet the needs of their installation Hardware The Microsoft best practices for domain controller sizing and placement are summarized in the following table: Users 1 per Domain in a Site Minimum # of DCs per Domain in a Site ,000-2, ,000 10,000 2 > 10,000 users 1 for every 5,000 users Minimum CPU Speed per DC Uniprocessor 850 MHz and higher Dual processor 850 MHz and higher Dual processor 850 MHz and higher Quad processor 850 MHz and higher Quad processor 850 MHz and higher Minimum Memory per DC 512 MB 1 GB 2 GB 2 GB 2 GB After you determine the minimum memory requirements for each domain controller, consider using the /3GB switch to allow the Lsass process (the process in which Active Directory runs) to cache a larger number of directory objects. Lsass memory usage on domain controllers has two components: Data structures, which are like other processes and consist of threads, heaps, and stacks. Database buffer cache, which consists of database pages and index pages for the directory. In Windows 2000, the memory that can be used by the database buffer cache without adding the /3GB switch to the Boot.ini file is.5 GB. With the /3GB switch in place, the database buffer cache is still limited to 1 GB. In Windows Server 2003, there is no limit to how large the database buffer cache can grow. However, with the /3GB switch in place on a 32-bit computer, virtual address space is limited to 4 GB, with 3 GB allocated for user mode processes and 1 GB for kernel mode processes. Therefore, on a 32-bit computer, the database buffer cache never grows greater than 3 GB with the /3GB switch in place, and it does not grow that large because of the memory that is used by other processes. The /3GB switch can be added to domain controllers that are running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Do not add the /3GB switch to the Boot.ini file if you have less than 2 GB of physical memory. 1 This refers to users that authenticate against the domain controller to obtain Windows services in the CMU environment Active Directory Restructuring Recommendations Page 15

16 Disk Partition Requirements Domain controllers require at least enough disk space for the Active Directory database, Active Directory log files, the SYSVOL shared folder, and the operating system. The following guidelines should be used for determining these requirements: On the drive that will contain the Active Directory database, NTDS.dit, provide 0.4 gigabytes (GB) of storage for each 1,000 users. For example, for a forest with two domains (domain A, domain B), with 10,000 and 5,000 users respectively, provide a minimum of 4 GB of disk space for each domain controller that hosts domain A and a minimum of 2 GB of disk space for each domain controller that hosts domain B. On the drive that will contain the Active Directory transaction log files, provide at least 500 megabytes (MB) of available space. On the drive that will contain the SYSVOL shared folder, provide at least 500 MB of available space. On the drive that will contain the Windows Server 2003 operating system files, provide at least 1.5 GB to 2 GB of available space. To prevent single disk failures, many organizations use a redundant array of independent disks (RAID). For domain controllers that are accessed by fewer than 1,000 users, all four components generally can be located on a single RAID 1 array. For domain controllers that are accessed by more than 1,000 users, place the log files on one RAID array and keep the SYSVOL shared folder and the database together on a separate RAID array, as specified below: Component Operations Performed RAID System Operating system files Read and write operations RAID 1 Active Directory log files Mostly write operations RAID 1 Active Directory database and SYSVOL shared folder Mostly read operations RAID 1 or RAID 0+1 If cost is a factor in planning for disk space, the operating system and Active Directory database can be placed on one RAID array (such as RAID 0+1) and the Active Directory log files on another RAID array (such as RAID 1). However, it is recommended that the Active Directory database and the SYSVOL shared folder are stored on the same drive. Designating the domain controllers as global catalog servers increases the database size. Each additional domain in a forest adds approximately 50 percent of its database size to the global catalog CMU Physical Design The physical architecture for the new environment will not change much from the existing design. This section will detail recommendations for the site topology, domain controller configuration and replication topology Sites, Subnets and Replication CMU Computing Services maintains a centralized Windows environment. Even though other departments and/or locations (e.g. Qatar) may have their own Active Directory implementation, and there may be trusts established between those environment and the ANDREW forest, this does not impact the physical architecture for the ANDREW forest. Active Directory Restructuring Recommendations Page 16

17 Since the ANDREW forest is centrally located on the Pittsburgh campus, only a single Active Directory site needs to be defined. The domain controllers may reside in separate physical buildings; however there is LAN connectivity between them all. To ensure that the Windows clients are taking advantage of site affinity, and to plan for any future additions of Active Directory sites, all IP subnets that contain Windows clients (servers, desktops, laptops, etc ) are a member of the ANDREW domain should be defined in Active Directory and associated with the Pittsburgh site. Since the CMU network is changing regularly and there is only one Active Directory site defined, the recommendation is to define the super-net(s) and associate that with the site. Based on conversations with CMU personnel, those IP ranges are: / / / /16 Within this site, the Active Directory connection objects should be allowed to be automatically created by the Knowledge Consistency Checker (KCC). The intra-site KCC optimizes replication between the servers by avoiding unnecessary network traffic and leveraging a bi-directional ring. Intra-site replication avoids unnecessary network traffic by introducing a change notification mechanism that replaces the usual polling of replication partners for updates. When a change is Active Directory Restructuring Recommendations Page 17

18 performed in its database, a domain controller waits a configurable interval (default 5 minutes), accepts more changes during this time, then sends a notification to its replication partners, which pull the changes. If no changes are performed for a configurable period (default 6 hours) the domain controller initiates a replication sequence anyway, just to make sure that it did not miss anything. Attribute changes considered security-sensitive are immediately replicated and intra-site partners are notified: lockout of user accounts, change of domain trust passwords, some changes in the roles of domain controllers. Intra-site replication topology is a bi-directional ring built using domain controller GUIDs. If CMU deployed seven or more domain controllers in the Pittsburgh site,, bi-directional connections would be added to keep the path between any pair to less than three hops. New DCs configured in the site are included in the ring. One bi-directional ring is built for each naming context available in a site. Schema and configuration information share the same topology and only one bi-directional ring is built for them, because they must be replicated to all domain controllers. Since all domain controller s in the Pittsburgh site are in the ANDREW domain, the two rings are the same the ring that includes all site domain controllers is equivalent to the ring that includes all domain controllers in that domain. There would only be more than one distinct ring only if the site contained more than one domain: 2 domains = 3 rings, 3 domains = 4 rings, and so forth Hardware / Disk Requirements The current plan for domain controller placement at CMU is to have two servers located in the primary datacenter, and a third located in a separate building to provide additional high-availability in the event the datacenter is unavailable. Even though these servers will be in separate physical buildings, they will still be defined in the same Active Directory site (as noted previously). The servers should adhere to the best practices detailed previously in this document. Using those recommendations there are two acceptable domain controller configurations: Preferred Server Configuration Processor 2 x 850 MHz Memory 2 GB Disks C: Operating System RAID 1 D: AD Log Files RAID 1 E: AD database & SYSVOL RAID 1 or RAID 0+1 Acceptable Server Configuration Processor 2 x 850 MHz Memory 2 GB Disks C: Operating System, AD Log Files D: AD Database & SYSVOL RAID 0+1 RAID 1 Active Directory Restructuring Recommendations Page 18

19 Active Directory Restructuring Recommendations Page 19

20 3 Organizational Units 3.1 Concepts Organizational units are subgroups within domains; they are logical containers into which you can place accounts, shared resources, and other organizational units. Objects placed in an organizational unit can only come from the parent domain. For example, organizational units associated with sales.fabrikam.com contain objects for this domain only. You can't add objects from example.net to these containers, but you could create separate organizational units to mirror the business structure of sales.fabrikam.com. Organizational units should be used to assist in the administration of Active Directory. They should not be arbitrarily created. Valid reasons for creating an OU are: Organizational units allow you to delegate authority and to easily control administrative access to domain resources. This helps you control the scope of administrator privileges in the domain. You could grant user A administrative authority for one organizational unit and not for others. Meanwhile, you could grant user B administrative authority for all organizational units in the domain. Organizational units allow you to assign a group policy to a small set of resources in a domain without applying this policy to the entire domain. This helps you set and manage group policies at the appropriate level in the company. Organizational units create smaller, more manageable views of directory objects in a domain. This helps you manage resources more efficiently. Active Directory Restructuring Recommendations Page 20

21 3.2 CMU Organizational Unit Design To meet the administrative needs at CMU, the following OU hierarchy has been developed. Each of the OUs serves a purpose for delegation of administration, the application of group policy, or both. The CMU OU hierarchy has six custom top level OUs CMU Users, CMU Departments, CMU Administration, CMU Servers, CMU Groups, CMU Self-Registered Computers, and CMU Staging. These OUs were created specifically for delegation of administration and the application of group policy. The top level CMU Users OU has sub OUs that correspond to letters of the alphabet. Users are automatically provisioned to this OU using the CMU developed Trigger Server. This mechanism creates the accounts in the OU that corresponds to the first letter of the users last names. Under the top level CMU Departments OU there are several departmental OUs that are delegated to each corresponding department to allow the departmental administrators to control their objects. These administrators can create, modify and delete all objects, except user objects. The CMU Administration OU contains a location for administrative groups (i.e. those groups used to grant permissions) and administrative accounts for people that have administrative access to Active Directory. The CMU Groups OU is broken down into two sub-ous, Application and Software. These OUs contain groups that are used for granting access to applications and automatically installing software. The CMU Self-Registered Computers OU is a placeholder for future use when the university decides to allow users to join their own machines to the domain. CMU Staging is used to test directory changes before applying these changes to the production user and computer populations. Active Directory Restructuring Recommendations Page 21

22 4 Delegation of Administration 4.1 Concepts The objective of delegating administrative authority is to allow organizations to efficiently manage their Active Directory environments and the data stored in or protected by Active Directory in accordance with good security practices. Delegation of administration makes Active Directory management easier and allows organizations to address specific administrative needs. The administrative responsibilities of managing an Active Directory environment fall into two categories: Service management. Administrative tasks involved in providing secure and reliable delivery of the directory service. Data management. Administrative operations involved in managing the content that is stored in or protected by the directory service Service Management Service management includes managing all aspects of the directory service that are essential to ensuring the uninterrupted delivery of the directory service across the enterprise. Service management includes, but is not limited to, the following administrative tasks: Adding and removing domain controllers Managing and monitoring replication Ensuring the proper assignment and configuration of operations master roles Performing regular backups of the directory database Managing domain and domain controller security policies Configuring directory service parameters, such as setting the functional level of a forest or putting the directory in the special List-Object security mode Data Management Data management includes managing the content that is stored in Active Directory, as well as content that is protected by Active Directory. Data management tasks include, but are not limited to, managing the following Active Directory content: User accounts, which represent the identities of people who use the network Computer accounts, which represent the computers that are joined to domains in the Active Directory forest Security groups, which are used to aggregate accounts for the purpose of authorizing access to resources Application-specific attributes for Active Directory-enabled and -integrated applications, such as Microsoft Exchange and Microsoft Real-Time Communication service In addition, Active Directory data management can also facilitate the distribution and delegation of these management tasks: Workstation management, which includes managing all aspects of end-user workstations Server management, which includes managing all aspects of all servers joined to any domain in an Active Directory forest Resource management, which includes managing all aspects of services and applications hosted on member servers joined to any domain in an Active Directory forest, possibly Active Directory Restructuring Recommendations Page 22

23 including the server management aspects of the servers on which the application or resource is being hosted 4.2 CMU Administrative Model The administrative model for CMU is derived from four key components determining the administrative tasks, identifying the necessary administrative roles to perform those tasks, defining a user account strategy, and defining a group strategy Administrative Tasks There are several tasks that are necessary to the operation of the CMU domain that require specific rights and permissions. Those tasks are defined below: Administration of the entire forest, including network services (DNS, DHCP, WINS, etc ). Organizational Unit administration. This task involves creating, deleting and modifying OUs to work with the standard hierarchy that CMU has defined. User administration. This task involves adding, modifying and deleting user accounts that will be used for running services and administrative user accounts. As well as resetting users passwords and managing account lockouts when the AD accounts are used more extensively in the CMU environment. Administration of groups. This task includes the administration of software and application groups, as well as administrative groups. The two types of groups will be created and managed differently. Sever administration. This task pertains specifically to the member servers in the CMU environment. These computer accounts will need to be created, modified and deleted within Active Directory, and the actual machine will also need to be administered and maintained. Backup and restore of CMU servers (including domain controllers). To perform disaster recovery in the CMU forest, an administrator must have permissions on the domain controllers in the Andrew Windows domain. Monitoring and maintaining the CMU servers (including domain controllers). To access the event logs in the CMU domain, an administrator must have been granted permissions to do so. In addition, server maintenance will require the ability to logon to the domain controllers. Group policy administration. Policies will need to be created, modified and deleted within the CMU environment. Some of these policies will apply to users, some to computers, and other policies will apply only to member servers Administrative Roles The tasks mentioned above will be performed by one or more corresponding administrative role. These roles will then map to the actual groups in the CMU domain. The following roles have been identified as necessary for managing this environment: Domain Administrators. Administrators that have access to all objects in the CMU domain. They are able to update the OU hierarchy, manage the security on all objects in the domain and administer objects all the way down the tree. This role also manages the initial membership of all administrative groups and the on-boarding process for new departments. Departmental Administrators. Administrators that have access to all objects within their department. They are able to administer objects all the way down the tree and manage security within their department. <Function> Server Administrators. Administrators that have access to all of the servers that perform a specific function (i.e. Exchange, IIS, etc ). They can add, modify and delete Active Directory Restructuring Recommendations Page 23

24 computer accounts, and administer the physical machine. They will also be able to back up and restore any of these servers. Software Distribution Administrators. Administrators that can add, modify and delete group policy objects for the purposes of distributing software. Departments can then subscribe to this service and chose to install only the software they select. Self-Registered Administrators. Once CMU allows users to register their computer in the CMU domain, an administrative role will be necessary manually modify and/or delete computer accounts Account Strategy The following strategy will be employed for users that need to be able to administer the andrew.ad.cmu.edu domain: Each user will have their normal user account in the domain. Note that a normal user account is the one that is used for end-user tasks - using , accessing file shares, web browsing, etc A user should have only one normal user account that has been provisioned by the trigger server. Some set of users (most likely CMU Computing Services) will also have an administrative user account in this domain. Administrative user accounts should not be used for everyday purposes (as defined above). These administrative accounts will be prefixed with admin-. For example, if the naming convention specifies 2 that John Smith will have a normal user account with the name of jsmith, then the corresponding administrative account will be called admin-jsmith. These accounts are used to grant the rights and permissions to backup up the root domain controllers, monitor the servers, maintain the servers, etc These admin- accounts will reside in the Admin Accounts OU under CMU Administration, as shown in the OU diagram earlier in this document. Users that require the use of an administrative account to perform a specific task can supply the credentials in one of the following manners: Use the runas command to supply alternate credentials this is the preferred approach. Explicitly logon using the administrative User Account. Use the connect as function to supply alternate credentials. Use the appropriate tool-specific option to supply alternate credentials. The following examples may help to clarify the user account strategy for the CMU domain: Standard User. Someone in the CMU organization that is not involved with the administration of Windows 2000 (e.g. Joe User) Normal user account in the andrew.ad.cmu.edu domain according to the administrative model put in place for that domain: ANDREW\juser. This account should be used for normal end-user purposes. Administrative function in the CMU domain. Someone that needs permission to backup the CMU domain controllers (e.g. Jim Operator) would receive the following: 2 Note that recommended naming standards are included at the end of this documentation, but they have not yet been approved. Active Directory Restructuring Recommendations Page 24

25 4.2.4 Group Strategy Normal user account in the andrew.ad.cmu.edu domain: ANDREW\joperato. This account should be used for normal end-user purposes. Administrative account in the andrew.ad.cmu.edu Domain: ANDREW\admin-joperato. This account should be used for backing up the CMU domain controllers General Strategy The general rule for this delegation model follows the Microsoft recommendations of placing users into global groups, global groups into domain local groups, and using the domain local groups to grant rights and permissions. The strategy used by this delegation of administration model depends primarily on two variables the location of the users and the location where the rights and permissions are granted. As noted above, in the general case when creating custom groups, domain local groups will be used to grant the rights and permissions (to AD objects or any other objects that can be ACL ed). Computer rights & permissions (i.e. those granted to workstations and servers) are generally granted to machine local groups (e.g. <machine>\backup Operators and <machine>\administrators). Existing machine local groups will be used whenever possible by nesting the domain local groups into those machine local groups. If an existing group cannot be used and therefore a new group is needed, the rights and permissions on the machine should be granted to a new domain local group. This means that the group can be managed from Active Directory rather than the specific machine. Domain controllers are a special type of Computer they do not have any machine local groups. Instead, the domain Builtin groups are used to apply to all domain controllers in the domain (e.g. <domain>\backup Operators and <domain>\server Operators). CMU should take advantage of the Builtin Groups whenever possible. This model also considers the limitations of the Builtin groups (e.g. Backup Operators and Server Operators). Specifically, there are two limitations: Builtin groups cannot be made members of machine local groups (on member servers or computers). Builtin groups cannot contain Domain Local Groups. They can only contain global and universal groups. Since the CMU forest consists of a single domain, users will not have administrative rights or permissions in any other domain. This means that a group of users from a single domain are granted rights and permissions within that domain only. The following model can be used to illustrate the group strategy when applied to a single domain: Active Directory Restructuring Recommendations Page 25

26 Users Global Group Domain Rights & Permissions Granted Domain Local Group Builtin Group Domain Controller Rights & Permissions Granted Machine Rights & Permissions Granted Machine Local Group Group Nesting The following section details the roll-up strategy for groups using the general group nesting strategy outlined above. In addition to nesting the groups based on their type (global group, domain local group, etc ), every group in this implementation of Active Directory belongs in one of two categories: Services & Rights Administrative The category determines which how the group is rolled up and where the groups are located in the OU hierarchy Services & Rights Groups Service & Rights groups are nested based on their scope. If a service/right is granted to users throughout CMU (e.g. access to the Kerberos for Windows application), then the groups are nested from each department location into a corresponding central group that is used in the ACLs to grant the permissions. Departmental services & rights groups are used for services/rights that are only available at a department level (e.g. access to a database that is only available to a particular department). In all cases, users are made members of the groups that reside at the local department level. Users should never be placed directly into a central services & rights group. This allows the department administrators to manage access to all resources (departmental and central) because the membership of the groups is managed locally. The following image depicts a scenario where there are three resources that need to be accessed by a specific set of users: Active Directory Restructuring Recommendations Page 26