|
|
The two primary Active Directory components are its logical and physical structures, which involve the organization and communication of objects, respectively. A third component, known as the schema, defines objects that make up the Active Directory. For the sake of convenience, the discussion of the schema is included in the logical structure section.
The base logical components of the Active Directory are objects and their associated attributes. Object classes are merely definitions of the object types that can be created in the Active Directory. The schema is the Active Directory mechanism for storing object classes. It also permits the addition of object classes and associated attributes.
Active Directory objects are organized around a hierarchical domain model. This model is a design facility that permits the logical arrangement of objects within administrative, security, and organizational boundaries. Each domain has its own security permissions and unique security relationships with other domains. The Active Directory uses multimaster replication to communicate information and changes among domains.
The following sections provide an overview of domain model building blocks: domains, domain trees, forests, organizational units, and the schema.
The Active Directory manages a hierarchical infrastructure of networked computers with the domain as the foundation. A domain comprises computer systems and network resources that share a logical security boundary. It can store more than 17 terabytes in the Active Directory database store. Although a domain can cross physical locations, all domains maintain their own security policies and security relationships with other domains. They are sometimes created to define functional boundaries such as those between administrative units (e.g., marketing and engineering). They are also viewed as groupings of resources or servers that use a common domain name, known as a namespace. For example, all servers or resources in the EntCert.com namespace belong to a single domain.
In very simple terms, every domain controller has the following information as part of its Active Directory:
Data on every object and container object within the particular domain
Metadata about other domains in the tree (or forest) to provide directory service location
A list of all domains in the tree and forest
The location of the server with the Global Catalog
When multiple domains share a schema, security trust relationships, and a Global Catalog, a domain tree is created, defined by a common and contiguous namespace (Figure 5.4). Thus, for example, all domains with the ending namespace of EntCert.com belong to the EntCert domain tree. A domain tree is formed through the expansion of child domains like Sales.EntCert.com and Research.EntCert.com. The first created domain is known as the root domain, and it contains the configuration and schema data for the tree and (as we shall see) the forest. (In Figure 5.4, the root domain is EntCert.com.) A tree structure is formed by adding child domains. There are a number of reasons for creating multiple domains in a tree, some of which follow:
Discretely managing different organizations or providing unit identities
Enforcing different security boundaries and password policies
Requiring a better method of controlling Active Directory replication
Better handling of a very large number of managed objects
Decentralizing administration
A single domain contains a complete Active Directory partition for all of its objects. It is also, by definition, a complete domain tree. As child domains are added to the domain tree, Active Directory partitions are replicated to one or more domain controllers within each of the domains.
Trust relationships can be formed between domain trees with different namespaces. When this occurs, a domain forest is created, which allows the enterprise to have different domain names, such as "EntCert.com" and "unint.com." By default, all Windows Server 2003 forests are set at Windows 2000 functional levels.
All trees in the forest share a number of attributes, including a Global Catalog, configuration, and schema. A forest is simply a reference point between trees and does not have its own name. As discussed later, forests use the Kerberos security technology to create transitive trust relationships between trees. Figure 5.5 illustrates how two domain trees form a forest.
Domains and child domains can be internally divided into administrative substructures known as organizational units (OUs), each of which can compartmentalize over 10 million objects. As container objects, OUs can be nested within other OUs. For example, the marketing division may be defined as an organizational unit and the product groups within this division as suborganizational units. A domain usually comprises one or more organizational units arranged hierarchically. Objects can be organized within organizational units for administrative purposes. The OU acts as a container that lists the object contents, including users, computer systems, and devices such as printers.
An organizational unit is a logical subset defined by security or administrative parameters. In this administrative arrangement, the specific functions of the system administrator can also be easily segmented or delegated with the organizational unit level. From a system administrator's vantage point, this is very important to understand. It is possible to delegate system management responsibility solely to certain activities within a domain, OU, or child subsidiary OU. For example, a person in an organizational unit could be delegated authority to add, modify, or delete user accounts within that group.
Figure 5.6 illustrates the relationship of an organizational unit to a domain tree. Organizational units are subunits with a domain or child domain.
The Active Directory scales across environments ranging from a single server to a domain of one million users or more. The basis of this scaling is the peer-to-peer directory service relationship that is established between domains. Every domain server (known as a domain controller) is provided updated information on Active Directory objects. Consistency across domains is ensured through the automatic replication services. To avoid extremely large and unwieldy directories, the Active Directory creates tree partitions that comprise small portions of the entire enterprise directory. However, every directory tree has sufficient information to locate other objects in the enterprise. In addition to greater efficiency, objects that are used more frequently are placed in the local store for more rapid access. A trust relationship is automatically established between the domains in the same tree, so it is possible to transparently locate resources anywhere in the tree or forest enterprise where the Active Directory resides.
The schema is simply a framework of definitions that establishes the type of objects available to the Active Directory. These definitions are divided into object classes, and the information that describes the object is known as its attributes. There are two types of attributes: those that must exist and those that may exist. For example, the schema defines a user object class as having the user's name as a required attribute; the user's physical location or job description is optional. Attributes are used to further distinguish one object from another. They include object name, object identifier (OID), syntax, and optional information, as shown in Figure 5.7.
The schema is stored in the Active Directory database file Ntds.dit. Object definitions are stored as individual objects, so the directory can treat schema definitions in the same way it treats other objects. The default schema is created with the first installation of the Active Directory. It contains common objects and properties for such items as users, groups, computers, printers, and network devices. It also establishes the default Active Directory structure that is used internally.
Because schema is an extensible component, new object classes may be dynamically added to the current schema and old object classes can be modified. It was not possible to modify or deactivate system classes and attributes under Windows 2000, but it is now possible with Windows Server 2003.
NOTE
Schema data should not be confused with configuration data, which provides the structural information for the Active Directory. The schema provides information on what objects and attributes are available to the directory. Configuration information maintains the directory structure that represents the relationship between the actual objects and indicates how to replicate this structure between domain controllers.
The schema is accessible only to the Enterprise Administrators and Schema Admins user groups by default. It is managed through the Active Directory Schema snap-in tool. (The Active Directory Schema snap-in becomes available only after the adminpak application is installed from the Windows Server 2003 CD within the I386 folder.) Active Directory schema elements are dynamic and available to applications after the initial startup of the system. Attributes and classes can be added to the schema to provide dynamic extensibility to the Active Directory.
Using the Schema Active Directory Service Interface (SADS) is another method to facilitate the browsing and extending of functions and relationships of a schema object or attribute. The four SADS objects and schema object containers are listed in Table 5.1.
The schema object container attaches definitions to the directory tree. It is typically represented as a child of the directory root. In turn, each instance has a unique individual schema.
The Schema Operations Master domain controller (as discussed in greater detail in Chapter 6) manages the structure and content of the schema. It replicates schema information to the other domain controllers in the forest. Every domain controller loads a copy of the schema in a RAM-based cache, ensuring rapid access to current object and attribute definitions. If changes occur in the schema, the cache is refreshed.
|
Object |
Description |
|---|---|
|
Schema |
Contains all the information involved in a particular Active Directory schema. |
|
Object Class |
Establishes the classification of the object. Examples are computers, users, and groups. Object classes include:
|
|
Property |
Describes the defined properties (a device type, screen color, etc.). Properties are not subdivided into functional sets as occurs with directory service objects, like a group object. |
|
Syntax |
Describes first how the properties are defined, then specific options. |
NOTE
With Windows Server 2003, deactivation of attributes and class definitions in the Active Directory schema is now possible. This permits the redefinition of attributes and classes if an error was made in the original definition. In addition, deactivation can be used to supercede the definition of an attribute or class after it has been added to the schema. This is useful if an error was made in setting an immutable property. Deactivation is also a reversible operation so that an administrator can undo an accidental deactivation.
The second component of the Active Directory is the physical structure, which holds the mechanisms for data communication and replication. This section covers two physical structure topics: the definition of the IP subnet network structural component that constitutes Active Directory sites, and the physical server that stores and replicates Active Directory data known as the domain controller and the related Global Catalog.
In an ideal world, network communication would always be rapid and reliable. Unfortunately, geographic and other limitations result in the need to create smaller networks, known as subnets, to facilitate communication within and between locations. Although rapid and reliable network communication can be achieved within the larger unit, communication between subnets can vary radically. Therefore, to ensure the most effective network communication by Windows 2000 and Windows Server 2003, the Active Directory offers methods of regulating inter-subnet traffic.
The physical network structure of the Active Directory is based on a unit known as a site. The role of the administrator is to design sites that ensure the greatest network performance. A site comprises one or more Internet Protocol (IP) subnets that are tied together by high-speed, reliable connections. The speed considered sufficient is really arbitrary. For example, in small networks a 128-Kbps connection could be sufficient, whereas the bandwidth for a large network might need 3 Mbps or more. The administrator must determine the speed that best accomplishes the goal of minimum performance loss due to network traffic and establish sites accordingly. Many subnets can belong to a single site, but a single subnet cannot span multiple sites.
The primary goal of a site is rapid and economical data transmission. An important part of that is efficient directory services replication. The Active Directory physical structure governs when and how replication takes place. This is true of both intersite and intrasite replication. Network site performance also impacts the location of objects and logon authentication. As users log on to the network, they are able to reach the closest domain controller site through the previous assignment of subnet information. This is accomplished through DNS network-matching discovery of the closest domain controllers. The system administrator uses the Active Directory Sites and Services snap-in to manage the topology of replication services. With intrasite replication, the defined high-speed connection normally ensures rapid deployment. With intersite replication, the WAN bandwidth may be considerably slower. The site structure permits the management of Active Directory replication scheduling between sites.
Administrative granularity is significantly enhanced through the concept of the site and its relationship to domain and organizational units. In many cases, sites have the same boundaries as a domain or an organizational unit; thus, delegation of site responsibility might be mirrored in OU or domain administration.
No formal relationship exists between the boundaries of a site or domain. A site can have multiple domains, as a domain can have a number of sites (Figures 5.8 and 5.9). In addition, sites and domains do not have to maintain the same namespace.
A domain controller is a server that contains a copy of the Active Directory. All domain controllers are peers and maintain replicated versions of the Active Directory for their domains. The domain controller plays an important role in both the logical and physical structures of the Active Directory. It organizes all the domain's object data in a logical and hierarchical data store. It also authenticates users, provides responses to queries about network objects, and replicates directory services. The physical structure provides the means to transmit this data through well-connected sites.
The Active Directory replaces the Windows NT Primary Domain Controller (PDC) and its Backup Domain Controller (BDC) counterparts. Now all domain controllers share a multimaster peer-to-peer relationship that hosts copies of the Active Directory. Another big difference from Windows NT is that all domain controllers in Windows Server 2003 have read and write capability to the Active Directory. In previous versions only the PDC was read/write capable and initiated replication. Now any Active Directory domain controller can initiate the replication process when data is added.
Figure 5.10 illustrates that multiple domain controllers can exist within each domain or child domain.
An Active Directory domain may have one or more domain controllers that replicate the directory partition. Among the reasons for having multiple domain controllers in a domain are:
Better user connectivity
High-volume user activity
Greater failover and redundancy of information
When creating multiple domain controllers, the system administrator must take into account the added network load that will result from replication traffic. Still, it is recommended that each domain and each site have more than one domain controller so as to provide logical and physical structure redundancy and fault tolerance. It is important to protect both key domain information and geographical site connectivity.
NOTE
It is probably not overkill to emphasize that in the event of domain controller problems, without this protection users will not be able to log on. In addition, in the event of a total failure, all Active Directory information is lost unless regular backups or replications have been achieved.
A domain controller is assigned to a site during installation of the Active Directory and stays there unless the administrator manually intervenes to relocate it. The site location of a domain controller is part of the Active Directory replication topology and other system requests.
Whereas a domain controller is assigned to a specific site, sites of client systems may change. When a client computer boots and an IP address is assigned by DHCP, site membership may shift to a different subnet.
Active Directory replication between domain controllers is managed by the system administrator on a site-by-site basis. As domain controllers are added, a replication path must be established. This is done by the Knowledge Consistency Checker (KCC) coupled with Active Directory replication components. The KCC is a dynamic process that runs on all domain controllers to create and modify the replication topology (Figure 5.11). If a domain controller fails, the KCC automatically creates new paths to the remaining domain controllers. Manual intervention with the KCC will also force a new path.
The Active Directory replaces PDCs and BDCs with multimaster replication services. Each domain controller retains a copy of the entire directory for that particular domain. As changes are made in one domain controller, the originator communicates these changes to the peer domain controllers. The directory data itself is stored in the ntds.dit file.
Active Directory replication uses the Remote Procedure Call (RPC) over IP to conduct replication within a site. Replication between sites can use either RPC or the Simple Mail Transfer Protocol (SMTP) for data transmission. The default intersite replication protocol is RPC.
There are distinct differences in internal and intersite domain controller replication. In theory, the network bandwidth within a site is sufficient to handle all network traffic associated with replication and other Active Directory activities. By the definition of a site, the network must be reliable and fast. A change notification process is initiated when modifications occur on a domain controller. The domain controller waits for a configurable period (by default, 5 minutes) before it forwards a message to its replication partners. During this interval, it continues to accept changes. Upon receiving a message, the partner domain controllers copy the modification from the original domain controller. In the event that no changes were noted during a configurable period (by default, 6 hours), a replication sequence ensures that all possible modifications are communicated. Replication within a site involves the transmission of uncompressed data.
NOTE
Security-related modifications are replicated within a site immediately. These changes include account and individual user lockout policies, changes to password policies, changes to computer account passwords, and modifications to the Local Security Authority (LSA).
Replication between sites assumes that there are network connectivity problems, including insufficient bandwidth, reduced reliability, and increased cost. Therefore, the Active Directory permits the system to make decisions on the type, frequency, and timing of intersite replication. All replication objects transmitted between sites are compressed, which may reduce traffic by 10 to 25 percent; however, since this is not sufficient to guarantee proper replication, the system administrator has the responsibility of scheduling intersite replication, as described in Chapter 6.
Whereas the KCC represents the process elements associated with replication, the following comprise the Active Directory object components:
Connection object. Domain controllers become replication "partners" when linked by a connection object. This is represented by a one-way path between two domain controller server objects. Connection objects are created by the KCC by default. They can also be manually created by the system administrator.
NTDS settings object. The NTDS settings object is a container automatically created by the Active Directory. It contains all of the connection objects and is a child of the server object.
Server object. The Active Directory represents every computer as a computer object. The domain controller is also represented by a computer object, plus a specially created server object. The server object's parent is the site object that defines its IP subnet. However, in the event that the domain controller server object was created prior to site creation, it will be necessary to manually define the IP subnet to properly assign the domain controller a site.
When it is necessary to link multiple sites, two additional objects are created to manage the replication topology: site link and site link bridge.
Site link. The site link object specifies a series of values (cost, interval, and schedule) that define the connection between sites. The KCC uses these values to manage replication and to modify the replication path if it detects a more efficient one. The Active Directory DEFAULTIPSITELINK is used by default until the system administrator intervenes. The cost value, ranging from 1 to 32767, is an arbitrary estimate of the actual cost of data transmission as defined bandwidth. The interval value sets the number of times replication will occur: Fifteen minutes to a maximum of once a week (or 10,080 minutes) is the minimum; 3 hours is the default. The scheduled interval establishes when replication should occur. While replication can be at any time by default, the system administrator may want to schedule it only during off-peak network hours.
Site link bridge. The site link bridge object defines a set of links that communicate via the same protocol. By default, all site links use the same protocol and are transitive. Moreover, they belong to a single site link bridge. No configuration is necessary to the site link bridge if the IP network is fully routed. Otherwise, manual configuration may be necessary.
The Active Directory issues a unique identifier known as the update sequence number (USN), which is given to every change made to an object. This number is incrementally changed whenever the object is modified. Each property of an object is also issued a USN. A source domain regularly communicates USN sequence changes to the peer domain controller. The latest USN is then registered in each domain controller to ensure the freshness of an object's state. The Active Directory uses a timestamp only when changes are made at approximately the same time to the same object. At this point, in order to avoid data collisions, the change with the latest timestamp will be replicated by default. In all other cases, the Active Directory disregards the timestamping process.
Some domain controllers are assigned specific roles to facilitate performance and to reduce conflict. While the principle of multimaster replication of services across all domain controllers is the underpinning of the Active Directory, certain functions are best performed by a single domain controller. Therefore, Windows Server 2003 supports two forms of specialized function: the Global Catalog and operations masters. Forests share a Global Catalog and some operations masters.
The GC has two primary functions. First, it acts as a domain controller that stores object data and manages queries about objects and their most common attributes (called the Global Catalog Partial Attribute Set, or PAS). Second, it provides data that permits network logon. In single-domain controller environments, the Active Directory and GC reside on the same server. Where multiple domain controllers exist, as we discuss later, it is often advisable to move the GC to its own dedicated domain controller. All domain trees have a GC and must reside on a domain controller.
NOTE
In the absence of a GC, a user can log on only to the local system. However, a member of the Domain Administrators group can log on to the network without a GC.
NOTE
In Windows 2000, processing a user logon in native mode required a domain controller (DC) to contact a Global Catalog server in order to expand a user's Universal Group membership. As a result, it was recommended that the GC server be located in a remote site to avoid network-related logon failures. Windows Server 2003 reduces this need through group membership caching. Domain controllers within a site can cache the Universal Group membership so that user logon processing can occur in the absence of a GC. The cache is refreshed periodically when the site-based DC can contact the GC. This feature is turned on by configuring a site to use Global Catalog-less logon in the Active Directory Sites and Services snap-in.
The Global Catalog server stores and replicates an assortment of information, including the domain forest schema data and configuration data. It can also be seen as a data repository and engine for rapid object searches. The GC lists all the objects in a domain tree or forest. However, it differs from the Active Directory in that it is comprised of a partial list of object attributes. A list of the most requested or common object attributes is contained in the GC in an abbreviated format that results from partial replication of domain data. By cataloging domain objects, locating objects can be faster without the need to search the entire source domain. Clearly, the reason for a dedicated GC is to separate the inquiry process from the updating and management processes within a directory service, as shown in Figure 5.12.
An object's distinguished name typically provides sufficient data to identify the partition that holds it. The GC contains a partial copy of every distinguished namespace on the Active Directory.
The Global Catalog supports a set of default object attributes that are considered the most common or the most frequently queried—for example, a user's first and last names. However, for greater control over the defined attributes for a particular domain, Windows Server 2003 provides a means to modify the default settings. The system administrator can use the Schema Manager snap-in to update the attributes included in the GC replication.
When the first Active Directory is installed, it creates a default Global Catalog. More than one GC server can exist depending on the size of the enterprise, the number of physical sites, and the quality of network connectivity. Global Catalog servers are added through the Sites and Servers Management snap-in of the Microsoft Management Console (MMC). Moving the GC to another domain controller is accomplished by modifying the NTDS Setting Properties in the Sites and Server Management snap-in.
In selecting a system to become the GC server, it is important to consider both capacity and network connectivity. The system should have sufficient storage capability to support the management of a million or more objects. The CPU system speed should be sufficient to permit the processing of a steady flow of queries.
NOTE
Global Catalog synchronization has been improved. In Windows 2000, the GC Partial Attribute Set required full synchronization cycle of its read-only (RO) naming context (NC) with propagation of extended PAS (addition of an attribute to the PAS). The purpose was to provide up-to-date attribute-extended replica images on other domain controllers. Windows Server 2003 has a mechanism to preserve the GC synchronization state rather than reset it. This feature is activated through the Active Directory Users and Computers snap-in.
Network connectivity to the GC server must be fast and of high quality, since access to a GC is required for successful network logon. Given that a site is bounded by rapid and reliable network connectivity, at least one GC domain controller per site is recommended.
Multimaster domain replication assumes that all domain controllers eventually receive synchronized Active Directory information. However, there are master domain controller relationships to handle certain Active Directory information within a domain or forest. The master roles are:
Domain Naming Master. This domain controller manages the addition and removal of domains in the forest. A forest can have only one Domain Naming Master, which can be transferred to another domain controller through the Active Directory Domains and Trusts snap-in.
Infrastructure Master. The domain controller is responsible for managing group and user references. Expect a delay in changes when they are made across domains. Updates to other domains are made by the Infrastructure Master domain controller via a process called multimaster replication. This master role can be transferred to another domain controller through the Active Directory Users and Computers snap-in.
PDC Emulator. In a mixed Windows Server 2003 and Windows NT environment, the PDC Emulator supports the BDCs. Thus, it manages user account and password changes and forwards that information to the Windows NT BDC. In a native mode Windows Server 2003 environment, the PDC Emulator receives preference in the replication of user account passwords. Before a logon fails, it is checked for updated information. This master role can be transferred to another domain controller through the Active Directory Users and Computers snap-in.
Relative ID Master. A single Relative ID (RID) Master in each domain of a tree manages the allocation of sequential RIDs to each domain controller. This makes all security IDs (SIDs) created in a domain relative to the domain controller. This master role can be transferred to another domain controller through the Active Directory Users and Computers snap-in.
Schema Master. The Schema Master controls updates to the domain schema data. There is one Schema Master in the entire forest. It can be transferred to another domain controller through the Active Directory Schema Master snap-in.
CAUTION
Microsoft issues a word of caution regarding potential conflicts between the Infrastructure Master and the Global Catalog. In environments with more than one domain controller, the GC should not be hosted on a controller that also hosts the Infrastructure Master. Since the Infrastructure Master compares its data with the GC, there may be significant replication impacts and full replication may fail. In particular, outdated information will not be seen. The exception to this rule about separating the GC and the Infrastructure Master is an environment where every domain controller retains a copy of the GC.
NOTE
In Windows 2000/Server 2003 Active Directory, the membership of a group is stored and replicated as a single unit. As a result, a change to a group with large membership causes the entire membership to replicate. This could easily consume large amounts of network bandwidth and processor load. In addition, this also results in failed replication conflict resolution. Now, when a forest is advanced in a Windows Server 2003 native mode, group membership is changed to store and replicate values for individual members. Membership is not treated as a single unit. No administrative action is required to activate this improvement since it is integral to Windows Server 2003. This does not apply to Global Catalog systems.
 |
|
|
| Top |