5. Schema Users Servers Attributes of Users might contain: List of attributes accountExpires badPasswordTime mail cAConnect dhcpType eFSPolicy fromServer governsID Name … accountExpires badPasswordTime mail name Attribute Examples: Object Class Examples: Dynamically available, updateable, and protected by DACLs Computers
6.
7.
8. Directory Partitions Configurable Replication Application Domain-wide replication Forest-wide replication (every DC in forest has a replica) All Partitions Together Comprise the Active Directory Database Zoom.com Configuration Schema Contains information about all domain-specific objects created in Active Directory Contains information about Active Directory structure Contains definitions and rules for creating and manipulating all objects and attributes Contains application data ForestDNSZone DomainDNSZone
18. Forest Functional Levels Windows Server 2003 Server family Windows Server 2003 Server family Windows NT 4.0, Windows Server 2003 Server family Windows Server 2003 Interim Windows NT 4.0, Windows 2000, Windows Server 2003 Server family Windows 2000 (default) Domain Controllers Supported Forest Functional Level
19. Forest Functional Levels- Features Same as Windows Server 2003 Interim, plus: Schema de-/reactivation Domain rename Forest trust Windows Server 2003 Server Family Same as Windows 2000, plus: LVR replication (Linked Value Replication- new group structuring) Improved ISTG (Inter-Site Topology Generator- generates replication connections) Windows Server 2003 Interim Universal group caching Windows 2000 Features Supported Functional Level
20. Domain Functional Levels Windows 2000 Mixed Mode- NT4, Windows 2000 or WS03 DCs Domain Controller (Windows 2000) Domain controller (Windows NT 4.0) Domain Controller (Windows Server 2003) Windows 2000 Native Mode- No NT 4 DCs Domain Controller (Windows Server 2003) Domain Controller (Windows 2000)
21. Domain Functional Levels Windows Server 2003 Interim- No 2000 DCs Domain controller (Windows NT 4.0) Domain Controller (Windows Server 2003) Windows Server 2003 Server Level- All WS03 DCs Domain Controller (Windows Server 2003) Domain Controller (Windows Server 2003)
22. Domain Functional Levels- Features Same as Windows 2000 Native, plus: Kerberos KDC version numbers Domain Rename Windows 2003 Server Family Same as Windows 2000 mixed, plus: Group nesting and converting Universal security and distribution groups Universal group membership caching SID history Windows 2000 Native/Windows Server 2003 Interim Universal group caching Application directory partitions Windows 2000 mixed Features Supported Functional Level
30. Global Catalog Server Application Solaris.com Ccna.com Mcse.com Configuration Schema Holds read only copy of all other domain directory partitions- all objects, but only attributes marked for GC inclusion Holds full copy of domain partition for own domain Holds full copy of configuration partition for forest Holds full copy of the schema partition for forest Contains application data if configured ForestDNSZone, DomainDNSZone, user-defined application partition(s)
31. Global Catalog Servers Global Catalog Server Universal Group membership when user logs on Global Catalog Queries Include in GC Telephone Email Name … Object Attributes Domain Domain Domain
Editor's Notes
The AD Schema is the set of definitions that defines the kinds of objects—and the types of information about those objects—that can be stored in Active Directory. Because the definitions are themselves stored as objects, AD can manage the schema objects with the same object management operations used for managing the rest of the objects in the directory. There are two types of definitions in the schema: attributes and classes. Attributes & classes are also referred to as schema objects or metadata. Classes Classes, also referred to as object classes, describe the possible directory objects that can be created. Each class is a collection of attributes. When you create an object, the attributes store the information that describes the object. Ex: the User class is composed of many attributes, including Network Address, Home Directory, and so on. Every object in Active Directory is an instance of an object class. Attributes Attributes are defined separately from classes. Each attribute is defined only once & can be used in multiple classes. Ex: the Description attribute is used in many classes, but is defined once in the schema, ensuring consistency. Attributes describe objects. Each attribute has its own definition that describes the type of information that can be specified for that attribute. Each attribute in the schema is specified in the Attribute-Schema class, which determines the information that each attribute definition must contain. The list of attributes that can be applied to a particular object are determined by the class of which the object is an instance and by any superclasses of that object's class. Attributes are defined only once & potentially used many times. This ensures consistency across all classes that share a particular attribute. Extending the Schema The schema can be extended by defining new classes & new attributes for existing classes. The content of the schema is controlled by the DC that holds the schema operations master role. A copy of the schema is replicated to all DCs in the forest. The use of this common schema ensures data integrity & consistency thruout the forest. You can also extend the schema by using the AD Schema snap-in. In order to modify the schema, you must satisfy the following three requirements: Be a member of the Schema Administrators group. Install the Active Directory Schema snap-in on the computer holding the schema operations master role. Have administrator permission to modify the schema master. When considering changes to the schema, there are three key points to remember: Schema extensions are global. When you extend the schema, you extend the schema for the entire forest because any changes to the schema are replicated to every domain controller in every domain in the forest. Schema classes related to the system cannot be modified. You cannot modify default system classes within the Active Directory schema; however, applications that are used to modify the schema may add optional system classes that you can change. Schema extensions can be reversible. Some properties of attributes or classes may be modified after creation. Once a new class or attribute has been added to the schema, it can be deactivated, but it cannot be removed. However, you can defunct definitions & re-use object identifiers (OIDs) or display names, which allows you to reverse a schema definition. For more info about modifying the schema, see the Microsoft Windows Resource Kits at http://www.microsoft.com/reskit. AD does not support deleting schema objects; however, objects can be marked as deactivated, providing many of the benefits of deletion.
Schema data .The schema is the formal definition of all object and attribute data that can be stored in the directory. Windows Server 2003 includes a default schema that defines many object types, such as user and computer accounts, groups, domains, organizational units, and security policies. Administrators and programmers can extend the schema by defining new object types and attributes, or by adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that only authorized users can alter the schema.
Configuration data . The configuration data describes the topology of the directory. This configuration data includes a list of all domains, trees, and forests, and the locations of the domain controllers and global catalogs.
The directory is stored on servers known as domain controllers and can be accessed by network applications or services. A domain can have one or more domain controllers. Each DC has a writeable copy of the directory for the domain in which it is located. Changes made to the directory are replicated from the originating domain controller to other DCs in the domain, domain tree, or forest. Because the directory is replicated, and because each DC has a writeable copy of the directory, the directory is highly available to users and administrators throughout the domain. Domain information. This describes all of the objects in a domain. This data is domain-specific and is not distributed to any other domains. For the purpose of finding information throughout the domain tree or forest, a subset of the properties for all objects in all domains is stored in the GC. Domain data is stored in a domain controller and is replicated to all domain controllers in the domain. Domains: Trees, Forests, Trusts, and OUs AD is made up of one or more domains. Creating the initial domain controller in a network also creates the domain—you cannot have a domain without at least one domain controller. Each domain in the directory is identified by a DNS domain name. You use the Active Directory Domains & Trusts tool to manage domains. You use domains to accomplish the following network management goals: Administrative Boundaries. An AD domain defines an administrative boundary. Security policies and settings (such as account policies and group policies) do not cross from one domain to another. Active Directory can include one or more domains, each having its own security policies. However, AD domains do not provide isolation from each other, & are therefore not security boundaries. Only the forest constitutes a security boundary. Replicate information. A domain is a directory partition (also called a Naming Context). These directory partitions are the units of replication. Each domain stores only the information about the objects located in that domain. All of a domain's domain controllers can receive changes made to objects, and can replicate those changes to all other domain controllers in that domain. Apply Group Policy. A domain defines one possible scope for policy (Group Policy settings can also be applied to organizational units or sites). Applying a Group Policy object (GPO) to the domain establishes how domain resources can be configured and used. For example, you can use Group Policy to control desktop settings, such as desktop lockdown & application deployment. These policies are applied only within the domain & not across domains. Structure the network. Because one AD domain can span multiple sites & can contain millions of objects, most organizations do not need to create separate domains to reflect the company's divisions & departments. It should never be necessary to create additional domains to handle additional objects. However, some organizations do require more than one domain to accommodate, for example, independent or completely autonomous business units that do not want anyone external to their unit to have authority over their objects. Such organizations can create additional domains & organize them into an AD forest. Another reason to split the network into separate domains is if two parts of your network are separated by a link so slow that you never want complete replication traffic to cross it. (For slow links that can still handle replication traffic on a less frequent schedule, you can configure a single domain with multiple sites.) Delegate administrative authority. You can narrowly delegate administrative authority for individual OUs as well as for individual domains, which reduces the number of admins needed w/ wide administrative authority. Because a domain is an administrative boundary, administrative permissions for a domain are limited to the domain by default. For example, an admin w/ permissions to set security policies in one domain is not automatically granted authority to set security policies in any other domain in the directory. However, domains in an AD forest are tightly coupled. An admin in one domain can always find ways to grant himself access to resources in other domains in the forest, even if the admin of the other domain has not specifically allowed the access.
Active Directory services now allows the creation of a new type of naming context , or partition, referred to as Application Partition. This naming context can contain a hierarchy of any type of object except security principals (users, groups and computers), and can be configured to replicate to any set of domain controllers in the forest, not necessarily all in the same domain. This feature provides the capability of hosting dynamic data in Active Directory without significantly impacting network performance by providing the ability to control the scope of replication and placement of replicas. DNS zones in Active Directory can be stored and replicated in the application partition. Using application partitions to store the DNS data results in a reduced number of objects stored in the global catalog. In addition, when DNS zone data is stored in an application partition, it is replicated to only that subset of domain controllers in the domain that is specified in the application partition. By default, DNS-specific application partitions contain only those domain controllers that run the DNS server. In addition, storing the DNS zone in an application partition enables replication of the DNS zone to the DNS servers running on the domain controllers in different domains of an Active Directory forest. By integrating DNS zones in an application partition it is possible to limit the replication of this information and decrease overall replication bandwidth requirements.
Domain names for DNS are based on the DNS hierarchical naming structure, which is an inverted tree structure: a single root domain, underneath which can be parent and child domains (branches and leaves). For example, a Windows domain name such as child.parent.microsoft.com identifies a domain named child, which is a child domain of the domain named parent, itself a child of the domain microsoft.com. Active Directory includes one or more domains, each with one or more domain controllers, enabling you to scale the directory to meet any network requirements. Multiple domains can be combined into a domain tree and multiple domain trees can be combined into a forest. In the simplest structure, a single-domain network is simultaneously a single tree and a single forest. Trees In Active Directory, a tree is a set of one or more domains with contiguous names. If more than one domain exists, you can combine the multiple domains into hierarchical tree structures. One possible reason to have more than one tree in your forest is if a division of your organization has its own registered DNS name and runs its own DNS servers. The first domain created is the root domain of the first tree. Additional domains in the same domain tree are child domains. A domain immediately above another domain in the same domain tree is its parent. All domains that have a common root domain are said to form a contiguous namespace . Domains in a contiguous namespace (that is, in a single tree) have contiguous DNS domain names that are formed in the following way: The domain name of the child domain appears at the left, separated from the name of its parent domain to its right by a period. When there are more than two domains, each domain has its parent to its right in the domain name. AD-based domains that form a tree are linked by trust relationships that are both two-way and transitive. These trust relationships are described later. The parent-child relationship between domains in a domain tree is a naming relationship and a trust relationship only. Administrators in a parent domain are not automatically administrators of a child domain, and policies set in a parent domain do not automatically apply to child domains.
Forests An Active Directory forest is a distributed database , which is a database made up of many partial databases spread across multiple computers. Distributing the database increases network efficiency by letting the data be located where it is most used. The forest's database partitions are defined by domains, that is, a forest consists of one or more domains. All domain controllers in a forest host a copy of the forest Configuration and Schema containers in addition to a domain database. A domain database is one part of a forest database. Each domain database contains directory objects, such as security principal objects (users, computers, and groups) to which you can grant or deny access to network resources. Often, a single forest, which is simple to create and maintain, can meet an organization's needs. With a single forest, users do not need to be aware of directory structure because all users see a single directory through the global catalog. When adding a new domain to the forest, no additional trust configuration is required because all domains in a forest are connected by two-way, transitive trust. In a forest with multiple domains, configuration changes need be applied only once to affect all domains. You should not create additional forests unless you have a clear need to do so, because each forest you create will result in additional management overhead. One possible reason to create more than one forest is if administration of your network is distributed among multiple autonomous divisions that cannot agree on the common management of the schema and configuration containers. Another reason to create a separate forest is to ensure that specific users can never be granted access to certain resources (in a single forest, each user can be included in any group or can appear on a discretionary access control list, or DACL, on any computer in the forest). With separate forests, you can define explicit trust relationships to grant users in one forest access to certain resources in the other forest. Multiple domain trees within a single forest do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although trees in a forest do not share a namespace, a forest does have a single root domain, called the forest root domain . The forest root domain is, by definition, the first domain created in the forest. The two forest-wide predefined groups—Enterprise administrators and Schema administrators—reside in this domain. All Windows 2000 domains in all of the domain trees in a forest possess the following traits: Have transitive trust relationships among the domains within each tree. Have transitive trust relationships among the domain trees in a forest. Share common configuration information. Share a common schema. Share a common global catalog. Important Adding new domains to a forest is easy. However, you cannot easily move existing Active Directory domains between forests. You can remove a domain from the forest only if it has no child domains. After a tree root domain has been established, you cannot add a domain with a higher-level name to the forest. You cannot create a parent of an existing domain; you can only create a child. Implementing both domain trees and forests lets you use both contiguous and noncontiguous naming conventions. This flexibility can be useful, for example, in companies with independent divisions that each wants to maintain its own DNS name, such as Microsoft.com and MSNBC.com.
Trust Relationships A trust relationship is a relationship established between two domains that allows users in one domain to be recognized by a domain controller in the other domain. Trusts let users access resources in the other domain and also let administrators administer user rights for users in the other domain. For computers running Windows 2000 or Windows Server 2003, account authentication between domains is enabled by two-way, transitive trust relationships. All domain trusts in an Active Directory forest are two-way and transitive, defined in the following way: Two-way. When you create a new child domain, the child domain automatically trusts the parent domain, and vice versa. At the practical level, this means that authentication requests can be passed between the two domains in both directions. Transitive. A transitive trust reaches beyond the two domains in the initial trust relationship. Here is how it works: If Domain A and Domain B (parent and child) trust each other and if Domain B and Domain C (also parent and child) trust each other, then Domain A and Domain C trust each other (implicitly), even though no direct trust relationship between them exists. At the level of the forest, a trust relationship is created automatically between the forest root domain and the root domain of each domain tree added to the forest, with the result that complete trust exists between all domains in an Active Directory forest. At the practical level, because trust relationships are transitive, a single logon process lets the system authenticate a user (or computer) in any domain in the forest. This single logon process potentially lets the account access resources on any domain in the forest. Note, however, that the single logon enabled by trusts does not necessarily imply that the authenticated user has rights and permissions in all domains in the forest. In addition to the forest-wide two-way transitive trusts generated automatically, you can explicitly (manually) create the following two additional types of trust relationships: Shortcut Trusts and External Trusts. These are discussed with the next slide. Forest trust is a new type of Windows trust for managing the security relationship between two forests . This feature vastly simplifies cross-forest security administration and enables the trusting forest to enforce constraints on which security principal names it trusts other forests to authenticate. This feature includes: Forest Trust A new trust type that allows all domains in one forest to (transitively) trust all domains in another forest, via a single trust link between the two forest root domains. Forest trust is not transitive at the forest level across three or more forests. If Forest A trusts Forest B, and Forest B trusts Forest C, this does not create any trust relationship between Forest A and Forest C. Forest trusts can be one-way or two-way. Trust Management A new wizard simplifies creating all types of trust links, especially forest trust. A new property page lets you manage the trusted namespaces associated with forest trusts.
Active Directory supports four forms of trust relationships: shortcut, forest, external, and realm trusts. Shortcut – One or Two-Way – Transitive Trusts A one-way shortcut trust, established between two domains located in separate domain trees, can reduce the time needed to fulfill authentication requests, but from only one direction. In other words, when a one-way shortcut trust is established between domain C and domain E, authentication requests made in domain C to domain E will be able to take full advantage of the new one-way trust path. Whenever authentication requests from domain E to domain C are made, they will not be able to utilize the shortcut trust path that was created between domain C and domain E, and will default to walking up the trust path hierarchy to find domain C. In a two-way trust relationship, if domain A trusts domain B, then domain B automatically trusts domain A. In a transitive trust relationship, if domain B trusts domain A and domain C trusts domain A, domain B automatically trusts domain C and domain C automatically trusts domain B. If a two-way, transitive trust exists between two domains, you can grant permissions to resources in one domain to user and group accounts in the other domain, and vice versa. Two-way, transitive trust relationships are the default between Windows Server 2003 Server family domains. Forest – One or Two-Way – Transitive Trusts Creating a forest trust between two Windows Server 2003 forests provides a transitive relationship between every domain residing within each forest, and can be one-way or two-way. You can create only a forest trust between the forest root domains in one forest to a forest root domain in a second forest. Forest trusts are perfect for companies undergoing mergers or acquisitions, collaborative business extranets and for companies seeking a solution to administrative autonomy. In a one-way forest trust, all domains in the trusted forest can utilize resources in the trusting forest, while members in the trusting forest will not be able to access resources in the trusted forest. For example, if you create a one-way forest trust between Company A (the trusted forest) and Company B (the trusting forest), then users in Company A can access resources in Company B (assuming the users have permissions on resources). Users in Company B will not be able to access resources in Company A until a second forest trust is established. External – One-Way – Non-Transitive Trusts In a one-way trust relationship, if domain A trusts domain B, domain B does not automatically trust domain A. In a non-transitive trust relationship, if domain A trusts domain B and domain B trusts domain C, domain A does not automatically trust domain C. Windows NT networks use one-way, non-transitive trust relationships. You manually create one-way, non-transitive trust relationships between existing domains. Active Directory supports one-way, non-transitive trusts for connections to Windows NT networks. You can also establish one-way, non-transitive trusts between Active Directory domains. For example, if you want to allow an external business partner to have access to resources in a particular domain while working on a joint project, you might create a one-way, non-transitive trust between the internal and external domains. Realm – One or Two-Way – Transitive/Non-Transitive Trusts You can establish a realm trust between any non-Windows Kerberos V5 realm and a Windows Server 2003 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos V5 versions such as UNIX and MIT implementations. Realm trusts can switch from non-transitive to transitive and back. Realm trusts can also be either one-way or two-way.
This slide contains animations
Active Directory: Forest and Domain Functional Levels This feature provides a versioning mechanism that can be used by Active Directory core components to determine what features are available in a forest or domain. It is also used to prevent computers running pre-Windows Server 2003 Server Family operating system Domain Controllers (DCs) from joining a forest or domain that has Active Directory features activated that only apply to the Windows Server 2003 Server Family operating system. There are certain features in Active Directory, such as Group Membership Replication Improvements and Inter-site Replication Topology Generator, that cannot be activated until all DCs in a forest are upgraded to the Windows Server 2003 Server Family. Similarly, there are certain features that require all DCs in the domain to be upgraded to Windows Server 2003 Server Family. A list of these features is present in the Functional Levels descriptions of the Help section of the Windows Server 2003 Server Family product. In order to take advantage of these features, an IT administrator should advance the forest or domain functional level to Windows Server 2003 Server Family after all of the DCs in the forest or domain have been upgraded to run the Windows Server 2003 Server Family operating system. Windows Server 2003 Standard Server, Windows Server 2003 Enterprise Server, Windows Server 2003 Datacenter Server Applies to 32-bit and 64-bit; information updated for Beta 2; information updated for Beta 3; information updated for Server RC1To raise or view functional levels use the Domains and Trusts UI or Users and Computers UI.
Forest functionality is a tool that will enable various features across all the domains within the forest. There are two forest functional levels: Windows 2000 (default) and the Windows Server 2003 Server family. By default, forests operate at the Windows 2000 functional level. You can then increase the functional level of a forest to the Windows Server 2003 Server family, if necessary. The following table lists the forest functional levels and their corresponding supported domain controllers. Forest functionality level Enabled features Domain controllers supported Windows 2000 (Default) Active Directory install from media Universal Group caching Windows NT 4.0, Windows 2000, Windows Server 2003 Server family Windows Server 2003 Interim Same as Windows 2000 plus:LVR replication Improved ISTG Windows NT 4.0, Windows Server 2003 Server family Windows Server 2003 Server family-All Windows Server 2003 Interim, plus: Dynamic aux classes User to INetOrgPerson change Schema de-/reactivation Domain rename Forest trust Windows Server 2003 Server family Note LVR = Linked-value-replication (large group support) ISTG = Inter-Site Topology Generator After a forest functional level has been increased, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you increase a forest functional level to the Windows Server 2003 Server family, domain controllers running Windows 2000 Server cannot be added to the forest. There is one additional forest functional level, called Windows Server 2003 Server interim. Use this level if you are upgrading your first Windows NT domain so that it becomes the first domain in a new Windows Server 2003 Server family forest. Caution Changing the forest functional level is an irreversible procedure. After you have increased the forest functional level, you can not lower it.
Domain functionality enables features that will affect the entire domain. Three domain functional levels are available: Windows 2000 mixed (default), Windows 2000 native, and Windows Server 2003 Server family. Domains will operate at the Windows 2000 mixed functionality level by default. You can increase the functional level of a domain to either Windows 2000 native or the Windows Server 2003 Server family. The following table lists the domain functional levels and their corresponding supported domain controllers. Domain functionality level Enabled features Domain controllers supported Windows 2000 mixed (Default) Active Directory install from media Universal Group caching Windows NT 4.0, Windows 2000, Windows Server 2003 Server family Windows 2000 native All mixed mode, plus: Group nesting and converting Universal groups, security, and distribution SID History Windows 2000, Windows Server 2003 Server family ( continued ) Domain functionality level Enabled features Domain controllers supported Windows Server 2003 Interim Same as Windows 2000 mixed/native mode Windows NT 4.0, Windows Server 2003 Server family Windows Server 2003 Server family All Windows 2000 native, plus: Update logon timestamp attribute Kerberos KDC version numbers User password on INetOrgPerson Domain Renaming Tool Windows Server 2003 Server family Note Windows Server 2003 Interim is used only for direct upgrades from Windows NT 4.0 to the Windows Server 2003 Server family, directly bypassing Windows 2000. Domain controllers running Windows 2000 will not function in Windows Server 2003 Interim domain functionality. After a domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise a domain functional level to the Windows Server 2003 Server family, domain controllers running Microsoft Windows 2000 Server cannot be added to that domain. Caution Changing the domain functional level is a one-way procedure. After you have raised the domain functional level, you cannot lower it.
Domain functionality enables features that will affect the entire domain. Three domain functional levels are available: Windows 2000 mixed (default), Windows 2000 native, and Windows Server 2003 Server family. Domains will operate at the Windows 2000 mixed functionality level by default. You can increase the functional level of a domain to either Windows 2000 native or the Windows Server 2003 Server family. The following table lists the domain functional levels and their corresponding supported domain controllers. Domain functionality level Enabled features Domain controllers supported Windows 2000 mixed (Default)Active Directory install from media Universal Group caching Windows NT 4.0, Windows 2000, Windows Server 2003 Server family Windows 2000 native All mixed mode, plus: Group nesting and converting Universal groups, security, and distribution SID History Windows 2000, Windows Server 2003 Server family ( continued ) Domain functionality level Enabled features Domain controllers supported Windows Server 2003 Interim Same as Windows 2000 mixed/native mode Windows NT 4.0, Windows Server 2003 Server family All Windows 2000 native, plus: Update logon timestamp attribute Kerberos KDC version numbers User password on INetOrgPerson Domain Renaming Tool Windows Server 2003 Server family Note Windows Server 2003 Interim is used only for direct upgrades from Windows NT 4.0 to the Windows Server 2003 Server family, directly bypassing Windows 2000. Domain controllers running Windows 2000 will not function in Windows Server 2003 Interim domain functionality. After a domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise a domain functional level to the Windows Server 2003 Server family, domain controllers running Microsoft Windows 2000 Server cannot be added to that domain. Caution Changing the domain functional level is a one-way procedure. After you have raised the domain functional level, you cannot lower it.
The Role of Sites in Replication Sites streamline replication of directory information. Directory schema and configuration information is replicated throughout the forest and domain data is replicated among all domain controllers in the domain and partially replicated to global catalogs. By strategically reducing replication, the strain on your network can be similarly reduced. Domain controllers use sites and replication change control to optimize replication in the following ways: By occasionally re-evaluating which connections are used, Active Directory uses the most efficient network connections. Active Directory uses multiple routes to replicate changes, providing fault tolerance. Replication costs are minimized by only replicating changed information. If a deployment is not organized into sites, information exchange among domain controllers and clients can be chaotic. Sites improve the efficiency of network usage. Active Directory replicates directory information within a site more frequently than among sites. This way, the best-connected domain controllers—those most likely to need particular directory information— receive replications first. The domain controllers in other sites receive all changes to the directory, but less frequently, reducing network bandwidth consumption. And because data is compressed when replicating between sites, bandwidth consumption is further reduced. To be efficient, updates are limited only to times when new directory information has been added or current directory information has been changed. If directory updates are constantly distributed to all other domain controllers in the domain, they will consume network resources. Although you can manually add or configure connections or force replication over a particular connection, replication is automatically optimized by the Active Directory Knowledge Consistency Checker (KCC) based on information that you provide in the Active Directory Sites and Services administration tool. The KCC is responsible for constructing and maintaining the replication topology for Active Directory. In particular, the KCC decides when replication will occur, and the set of servers that each server must replicate with.
The Role of the Global Catalog A global catalog is a domain controller that stores a copy of all Active Directory objects in a forest. In addition, the global catalog stores each object’s most common searchable attributes. The global catalog stores a full copy of all objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest, which provides efficient searches without unnecessary referrals to domain controllers. A global catalog is created automatically on the initial domain controller in the forest. You can add global catalog functionality to other domain controllers or change the default location of the global catalog to another domain controller. A global catalog performs the following directory roles: Finds objects. A global catalog enables user searches for directory information throughout all domains in a forest, regardless of where the data is stored. Searches within a forest are performed with maximum speed and minimum network traffic. When you search for people or printers from the Start menu or choose the Entire Directory option within a query, you are searching a global catalog. Once you enter your search request, it is routed to the default global catalog port 3268 and sent to a global catalog for resolution. Supplies user principal name authentication. A global catalog resolves user principal names when the authenticating domain controller does not have knowledge of the account. For example, if a user’s account is located in example1.microsoft.com and the user decides to log on with a user principal name of user1@example1.microsoft.com from a computer located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the user’s account and will then contact a global catalog server to complete the logon process. Supplies universal group membership information in a multiple domain environment. Unlike global group memberships, which are stored in each domain, universal group memberships are only stored in a global catalog. For example, when a user who belongs to a universal group logs on to a domain that is set to the Windows 2000 native domain functional level or higher, the global catalog provides universal group membership information for the user’s account. If a global catalog is not available when a user logs on to a domain running in Windows 2000 native or higher, the computer will use cached credentials to log on the user if the user has logged on to the domain previously. If the user has not logged on to the domain previously, the user can only log on to the local computer. Note: Members of the Domain Administrators group are able to log on to the network even when a global catalog is not available.
![Basics of Active Directory in Windows Server 2003 ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)