Active Directory Architecture

Remy_3D

Abstract

To use the Microsoft

Remy_3D

Gaining an understanding of the Active Directory

Remy_3D

Before getting to the main sections of this paper桝ctive Directory architecture and interoperability梩his preliminary section takes a quick look at Active Directory from two very different perspectives:

昑he first is Active Directory at its most abstract, that is, Active Directory as a namespace that is integrated with the Internet's Domain Name System (DNS).

昑he second is Active Directory at its most mundane, that is, as the software that makes a server into a domain controller.

In the context of a computer network, a directory (also called a data store) is a hierarchical structure that stores information about objects on the network. Objects include shared resources such as servers, shared volumes, and printers; network user and computer accounts; as well as domains, applications, services, security policies, and just about everything else in your network. One example of the specific kinds of information a network directory might store about a particular type of object is that a directory typically stores a user's name, password, e-mail address, phone number, and so on, for a user account.

A directory service differs from a directory in that it is both the directory information source and the services making the information available and usable to administrators, users, network services, and applications. Ideally, a directory service makes the physical network topology and protocols (formats for transmitting data between two devices) transparent so that a user can access any resource without knowing where or how it is physically connected. To continue the user account example, it is the directory service that lets other authorized users on the same network access stored directory information (such as an e-mail address) about the user account object.

Directory services can support a wide variety of capabilities. Some directory services are integrated with an operating system, and others are applications such as e-mail directories. Operating system directory services, such as Active Directory, provide user, computers, and shared resource management. Directory services that handle e-mail, such as Microsoft Exchange, enable users to look up other users and send e-mail.

Active Directory, the new directory service central to the Windows 2000 Server operating system, runs only on domain controllers. Active Directory, in addition to providing a place to store data and services to make that data available, also protects network objects from unauthorized access and replicates objects across a network so that data is not lost if one domain controller fails.

Active Directory Incorporates DNS

Active Directory and DNS are both namespaces. A namespace is any bounded area in which a given name can be resolved. Name resolution is the process of translating a name into some object or information that the name represents. A telephone book forms a namespace in which the names of telephone subscribers can be resolved to telephone numbers. The Windows 2000 NTFS file system forms a namespace in which the name of a file can be resolved to the file itself.

DNS and the Internet

Understanding how Windows 2000 handles Active Directory and DNS namespaces requires understanding a few basics about DNS itself and its relationship to the Internet and TCP/IP. The Internet is a TCP/IP network. The TCP/IP communications protocols connect computers and let them transmit data over networks. Every computer on the Internet or on any other TCP/IP network (such as many Windows networks) has an IP address. DNS locates TCP/IP hosts (computers) by resolving the computer names that end users understand to the IP addresses that computers understand. The IP addresses on the Internet are managed by using the globally distributed DNS database, but DNS can also be implemented locally to manage addresses within private TCP/IP networks.

DNS, which is organized into a hierarchy of domains, makes the entire Internet into one namespace. DNS has several top-level domains that are further subdivided into second-level domains. The root of the Internet domain namespace is managed by an Internet authority (currently, the Internet Network Information Center, or InterNIC) that is responsible for delegating administrative responsibility for the top-level domains of the DNS namespace and for registering second-level domain names. The top-level domains are the familiar domain categories commercial (.com), educational (.edu), governmental (.gov), and so forth. Outside the United States, two-letter country-region codes are used, such as .uk for United Kingdom. Second-level domains represent namespaces that are formally registered to institutions (and to individuals) to provide them an Internet presence. Figure 1 shows how a company's network connects into the Internet DNS namespace.


Figure 1: How Microsoft fits into the Internet's DNS namespace

Integration of DNS and Active Directory Namespaces

The integration of DNS and Active Directory is a central feature of the Windows 2000 Server operating system. DNS domains and Active Directory domains use identical domain names for different namespaces. Because the two namespaces share an identical domain structure, it is important to understand that they are not the same namespace. Each stores different data and therefore manages different objects. DNS stores its zones2 and resource records; Active Directory stores its domains and domain objects.

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 2000 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.

Each computer in a DNS domain is uniquely identified by its fully qualified domain name (FQDN). The FQDN of a computer located in the domain child.parent.microsoft.com is computername.child.parent.microsoft.com.

Every Windows 2000 domain has a DNS name (for example, OrgName.com), and every Windows 2000-based computer has a DNS name (for example, AcctServer.OrgName.com). Thus, domains and computers are represented both as Active Directory objects and as DNS nodes (a node in the DNS hierarchy represents a domain or a computer).

DNS and Active Directory each uses a database to resolve names:

昜b]DNS is a name resolution service. DNS resolves domain names and computer names to IP addresses through requests received by DNS servers as DNS queries to the DNS database. Specifically, DNS clients send DNS name queries to their configured DNS server. The DNS server receives the name query and then either resolves the name query through locally stored files or consults another DNS server for resolution. DNS does not require Active Directory to function.

昜b]Active Directory is a directory service. Active Directory resolves domain object names to object records through requests received by domain controllers as Lightweight Directory Access Protocol (LDAP)3 search or modify requests to the Active Directory database. Specifically, Active Directory clients use LDAP to send queries to Active Directory servers. To locate an Active Directory server, an Active Directory client queries DNS. That is, Active Directory uses DNS as a locator service, resolving Active Directory domain, site, and service names to an IP address. For example, to log on to an Active Directory domain, an Active Directory client queries its configured DNS server for the IP address of the LDAP service running on a domain controller for a specified domain. Active Directory does require DNS to function.

At the practical level, to understand that the DNS and Active Directory namespaces in a Windows 2000 environment are different is to understand that a DNS host record that represents a specific computer in a DNS zone is in a different namespace than the Active Directory domain computer account object that represents the same computer.

In summary, then, Active Directory is integrated with DNS in the following ways:

昜b]Active Directory domains and DNS domains have the same hierarchical structure. Although separate and implemented differently for different purposes, an organization's namespace for DNS and Active Directory domains have an identical structure. For example, microsoft.com is a DNS domain and an Active Directory domain.

昜b]DNS zones can be stored in Active Directory. If you are using the Windows 2000 DNS service, primary zones can be stored in Active Directory for replication to other Active Directory domain controllers and to provide enhanced security for the DNS service.

昜b]Active Directory clients use DNS to locate domain controllers. To locate a domain controller for a specified domain, Active Directory clients query their configured DNS server for specific resource records.

Remy_3D

Active Directory and the Global DNS Namespace

Active Directory is designed so that it can exist within the scope of the global Internet DNS namespace. When an organization using Windows 2000 Server as its network operating system requires an Internet presence, the Active Directory namespace is maintained as one or more hierarchical Windows 2000 domains beneath a root domain that is registered as a DNS namespace. (An organization can choose not to be part of the global Internet DNS namespace, but if it does so, the DNS service is still required to locate Windows-2000 based computers.)

According to DNS naming conventions, each part of a DNS name that is separated by a period (.) represents a node in the DNS hierarchical tree structure and a potential Active Directory domain name in the Windows 2000 domain hierarchical tree structure. As shown in Figure 2, the root of the DNS hierarchy is a node that has a null label (" "). The root of the Active Directory namespace (the forest root) has no parent, and it provides the LDAP entry point to Active Directory.


Figure 2: Comparing DNS and Active Directory namespace roots

SRV Resource Records and Dynamic Updates

DNS exists independently of Active Directory, whereas Active Directory is designed specifically to work with DNS. For Active Directory to function properly, DNS servers must support Service Location (SRV) resource records4. SRV resource records map the name of a service to the name of a server offering that service. Active Directory clients and domain controllers use SRV resource records to determine the IP addresses of domain controllers.

Note: For more information about planning DNS server deployment in support of your Active Directory domains as well as other deployment issues, see the Microsoft Windows 2000 Server Deployment Planning Guide in the "For More Information" section in this paper.

In addition to the requirement that DNS servers in a Windows 2000 network support SRV resource records, Microsoft also recommends that DNS servers provide support for DNS dynamic updates5. DNS dynamic updates define a protocol for dynamically updating a DNS server with new or changed values. Without the DNS dynamic update protocol, administrators must manually configure the records created by domain controllers and stored by DNS servers.

The new Windows 2000 DNS service supports both SRV resource records and dynamic updates. If you choose to use a non-Windows 2000-based DNS server, you must verify that it supports the SRV resource records or upgrade it to a version that does support them. A legacy DNS server that supports SRV resource records but does not support dynamic updates must have its resource records manually updated at the time you promote a Windows 2000 Server to a domain controller. This is accomplished using the Netlogon.dns file (located in the %systemroot%\System32\config folder), which is created by the Active Directory Installation wizard.

Active Directory Creates Domain Controller

Implementing and administering a network are tangible activities. To understand how Active Directory fits into the picture at the practical level, the first thing you need to know is that installing Active Directory in a computer running the Windows 2000 Server operating system is the act that transforms the server into a domain controller. A domain controller can host exactly one domain.

Specifically, a domain controller is a computer running Windows 2000 Server that has been configured using the Active Directory Installation wizard, which installs and configures components that provide Active Directory directory services to network users and computers. Domain controllers store domain-wide directory data (such as system security policies and user authentication data) and manage user-domain interactions, including user logon processes, authentication, and directory searches.

Promoting a server to a domain controller using the Active Directory Installation wizard also either creates a Windows 2000 domain or adds additional domain controllers to an existing domain.

This section describes what an Active Directory domain controller is and some of the major roles it plays in your network.

With the introduction of Active Directory, Windows 2000 domain controllers function as peers. This is a change from the superior/subordinate roles played by Windows NT Server Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). Peer domain controllers support multimaster replication, replicating Active Directory information among all domain controllers. The introduction of multimaster replication means that administrators can make updates to Active Directory on any Windows 2000 domain controller in the domain. In the Windows NT Server operating system, only the PDC has a read-and-write copy of the directory; the PDC replicates a read-only copy of directory information to the BDCs. (For more about multimaster replication, see the section "Multimaster Replication.")

If you are upgrading to the Windows 2000 operating system from an existing domain, you can perform the upgrade in stages and at your convenience. If you are creating the first domain controller for a new installation, several entities come into being automatically at the same time that Active Directory is loaded. The next two subsections explain the following aspects of installing an Active Directory domain controller in a new network:

旻irst domain controller is a Global Catalog server.
旻irst domain controller holds the operations master roles.

Global Catalog

The Windows 2000 operating system introduces the global catalog, a database kept on one or more domain controllers. The global catalog plays major roles in logging on users and querying.

By default, a global catalog is created automatically on the initial domain controller in the Windows 2000 forest, and each forest must have at least one global catalog. If you use multiple sites, you may wish to assign a domain controller in every site to be a global catalog, because a global catalog (which determines an account's group membership) is required to complete the logon authentication process. This refers to a native-mode domain. Mixed-mode domains do not require a global catalog query for logon.

After additional domain controllers are installed in the forest, you can change the default location of the global catalog to another domain controller using the Active Directory Sites and Services tool. You can optionally configure any domain controller to host a global catalog, based on your organization's requirements for servicing logon requests and search queries. More global catalog servers provide quicker responses to user inquiries; the trade-off is that enabling many domain controllers as global catalog servers increases the replication traffic on the network.

The global catalog performs two key Active Directory roles, logon and querying:

昜b]Logon. In a native-mode domain, the global catalog enables network logon for Active Directory clients by providing universal group membership information6 for the account sending the logon request to a domain controller. In fact, not just users but every object authenticating to Active Directory must reference the global catalog server, including every computer that boots up. In a multi-domain setup, at least one domain controller that contains the global catalog must be running and available in order for users to log on. A global catalog server must also be available when a user logs on with a non-default user principal name (UPN). (For more about logging on, see the section "Logon Names: UPN and SAM Account Names").

If a global catalog is not available when a user initiates a network logon process, the user is able to log on only to the local computer (not to the network). The only exception to this is that users who are members of the domain administrators (Domain Admin) group are able to log on to the network even when a global catalog is not available.

昜b]Querying. In a forest that contains many domains, the global catalog lets clients quickly and easily perform searches across all domains, without having to search each domain individually. The global catalog makes directory structures within a forest transparent to end-users seeking information. Most Active Directory network traffic is query-related: users, administrators, and programs requesting information about directory objects. Queries occur much more frequently than updates to the directory. Assigning more than one domain controller to be a global catalog server improves response time for users seeking directory information, but you must balance this advantage against the fact that doing so can also increase the replication traffic on your network.

Remy_3D

Multimaster replication among peer domain controllers is impractical for some types changes, so only one domain controller, called the operations master, accepts requests for such changes. Because multimaster replication plays an important role in an Active Directory-based network, it is important to know what these exceptions are. In any Active Directory forest, at least five different operations master roles are assigned to the initial domain controller during installation.

When you create the first domain in a new forest, all five of the single master operations roles are automatically assigned to the first domain controller in that domain. In a small Active Directory forest with only one domain and one domain controller, that domain controller continues to own all the operations master roles. In a larger network, whether with one or multiple domains, you can re-assign these roles to one or more of the other domain controllers. Some roles must appear in every forest. Other roles must appear in every domain in the forest.

The following two forest-wide operations master roles must be unique in the forest, that is, there can be only one of each throughout the entire forest:

昜b]Schema master. The domain controller holding the schema master role controls all updates and modifications to the schema. The schema defines each object (and its attributes) that can be stored in the directory. To update the schema of a forest, you must have access to the schema master.

昜b]Domain naming master. The domain controller holding the domain naming master role controls the addition or removal of domains in the forest.

The following three domain-wide operations master roles must be unique in each domain: there can be only one in each domain in the forest:

昜b]Relative ID (RID) master. The RID master allocates sequences of RIDs to each domain controller in its domain. Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The security ID consists of a domain security ID (which is the same for all security IDs created in the domain), and a relative ID (which is unique for each security ID created in the domain). When the domain controller has exhausted its pool of RIDs, it requests another pool from the RID Master.

昜b]Primary domain controller (PDC) emulator. If the domain contains computers operating without Windows 2000 client software or if it contains Windows NT backup domain controllers (BDCs), the PDC emulator acts as a Windows NT primary domain controller (PDC). It processes password changes from clients and replicates updates to the BDCs. The PDC emulator receives preferential replication of password changes performed by other domain controllers in the domain. If a logon authentication fails at another domain controller due to a bad password, that domain controller forwards the authentication request to the PDC emulator before rejecting the logon attempt.

昜b]Infrastructure master. The infrastructure master is responsible for updating all inter-domain references any time an object referenced by another object moves. For example, whenever the members of groups are renamed or changed, the infrastructure master updates the group-to-user references. When you rename or move a member of a group (and that member resides in a different domain from the group), the group may temporarily appear not to contain that member. The infrastructure master of the group's domain is responsible for updating the group so that it knows the new name or location of the member.

The infrastructure master distributes the update using multimaster replication. Unless there is only one domain controller in the domain, do not assign the infrastructure master role to the domain controller that is hosting the global catalog. If you do, the infrastructure master will not function. If all domain controllers in a domain also host the global catalog (including the situation where only one domain controller exists), all domain controllers have current data and therefore the infrastructure master role is not needed.

Remy_3D

Once you have installed an Active Directory domain controller, you have simultaneously also created the initial Windows 2000 domain or added the new domain controller to an existing domain. How do the domain controller and domain fit into the overall network architecture?

This section explains the components of an Active Directory-based network and how they are organized. In addition, it describes how you can delegate administrative responsibility for organizational units (OUs), domains, or sites to appropriate individuals, and how you can assign configuration settings to those same three Active Directory containers. The following topics are covered:

昈bjects (including the schema).

昈bject naming conventions (including security principal names, SIDs, LDAP-related names, object GUIDs, and logon names).

昈bject publishing.

旸omains (including, trees, forests, trusts, and organizational units).

昐ites (including replication).

旽ow delegation and Group Policy apply to OUs, domains, and sites.

Objects

Active Directory objects are the entities that make up a network. An object is a distinct, named set of attributes that represents something concrete, such as a user, a printer, or an application. When you create an Active Directory object, Active Directory generates values for some of the object's attributes, others you provide. For example, when you create a user object, Active Directory assigns the globally unique identifier (GUID), and you provide values for such attributes as the user's given name, surname, the logon identifier, and so on.

The Schema

The schema is a description of the object classes (the various types of objects) and the attributes for those object classes. For each class of object, the schema defines the attributes that object class must have, the additional attributes it may have, and the object class that can be its parent. Every Active Directory object is an instance of an object class. Each attribute is defined only once and can be used in multiple classes. For example, the Description attribute is defined once but is used in many different classes.

The schema is stored in Active Directory. Schema definitions are themselves also stored as objects桟lass Schema objects and Attribute Schema objects. This lets Active Directory manage class and attribute objects in the same way that it manages other directory objects.

Applications that create or modify Active Directory objects use the schema to determine what attributes the object must or might have, and what those attributes can look like in terms of data structures and syntax constraints.

Objects are either container objects or leaf objects (also called noncontainer objects). A container object stores other objects and a leaf object does not. For example, a folder is a container object for files, which are leaf objects.

Each class of objects in the Active Directory schema has attributes that ensure:

昒nique identification of each object in a directory data store.

旻or security principals (users, computers, or groups), compatibility with security identifiers (SIDs) used in the Windows NT 4.0 operating system and earlier.

旵ompatibility with LDAP standards for directory object names.

Schema Attributes and Querying

Using the Active Directory Schema tool, you can mark an attribute as indexed. Doing so adds all instances of that attribute to the index, not just the instances that are members of a particular class. Indexing an attribute helps queries find objects that have that attribute more quickly

You can also include attributes in the global catalog. The global catalog contains a default set of attributes for every object in the forest, and you can add your choices to these. Both users and applications use the global catalog to locate objects throughout the forest. Include only those attributes that have the following characteristics:

昜b]Globally useful. The attribute should be one that is needed for locating objects (even if just for read access) that may occur anywhere in the forest.

昜b]Not volatile. The attribute should be unchanging or change rarely. Attributes in a global catalog are replicated to all other global catalogs in the forest. If the attribute changes often, significant replication traffic results.

昜b]Small. Attributes in a global catalog are replicated to every global catalog in the forest. The smaller the attribute, the lower the impact of that replication.

Schema Object Names

As stated earlier, classes and attributes are both schema objects. Any schema object can be referenced by each of the following types of names:

昜b]LDAP display name. The LDAP display name is globally unique for each schema object. The LDAP display name consists of one or more words combined, using initial caps for words after the first word. For example, mailAddress and machinePasswordChangeInterval are the LDAP display names for two schema attributes. Active Directory Schema and other Windows 2000 administrative tools display the LDAP display name of objects, and programmers and administrators use this name to reference the object programmatically. See next subsection for information about programmatically extending the schema; see the section "Lightweight Directory Access Protocol" for more information about LDAP.

昜b]Common name. The common name for schema objects is also globally unique. You specify the common name when creating a new object class or attribute in the schema梚t is the relative distinguished name (RDN) of the object in the schema that represents the object class. For more about RDNs, see the section "LDAP DN and RDN Names." For example, the common names of the two attributes mentioned in the preceding paragraph are SMTP-Mail-Address and Machine-Password-Change-Interval.

昜b]Object identifier (OID). A schema object's identifier is a number issued by an issuing authority such as the International Organization for Standardization (ISO) and the American National Standards Institute (ANSI). For example, the OID for the SMTP-Mail-Address attribute is 1.2.840.113556.1.4.786. OIDs are guaranteed to be unique across all networks worldwide. Once you obtain a root OID from an issuing authority, you can use it to allocate additional OIDs. OIDs form a hierarchy. For example, Microsoft has been issued the root OID of 1.2.840.113556. Microsoft manages further branches from this root internally. One of the branches is used to allocate OIDs for Active Directory schema classes, and another for attributes. To continue the example, the OID in Active Directory is 1.2.840.113556.1.5.4, which identifies the Builtin Domain class and can be parsed as shown in Table 1.

Table 1 Object identifier
Object ID Number | Identifies
1 | ISO ("root" authority) issued 1.2 to ANSI, then

Remy_3D

The Windows 2000 Server operating system provides a default set of object classes and attributes, which are sufficient for many organizations. Although you cannot delete schema objects, you can mark them as deactivated.

Experienced developers and network administrators can dynamically extend the schema by defining new classes and new attributes for existing classes. The recommended way to extend the Active Directory schema is programmatically, through the Active Directory Service Interfaces (ADSI). You can also use the LDAP Data Interchange Format (LDIFDE) utility. (For more about ADSI and LDIFDE, see the sections "Active Directory Service Interface" and "Active Directory and LDIFDE.")

For development and testing purposes, you can also view and modify the Active Directory schema with the Active Directory Schema tool.

When considering changing the schema, remember these key points:

昐chema changes are global throughout the forest.

昐chema extensions are not reversible (although you can modify some attributes).

昅icrosoft requires anyone extending the schema to adhere to the naming rules (discussed in the preceding subsection) for both the LDAP display name and the common name. Compliance is enforced by the Certified for Windows logo program7Microsoft Developer Network Web site for more information. .

旳ll classes in the schema are derived from the special class Top. With the exception of Top, all classes are subclasses derived from another class. Attribute inheritance lets you build new classes from existing classes. The new subclass inherits the attributes of its superclass (parent class).

Extending the schema is an advanced operation. For detailed information about how to extend the schema programmatically, see the section "For More Information" at the end of this document.

Object Naming Conventions

Active Directory supports several formats for object names to accommodate the different forms a name can take, depending on the context in which it is being used (some of the names are in the form of numbers). The following subsections describe these types of naming conventions for Active Directory objects:

昐ecurity principal names.

昐ecurity identifiers (also called security IDs or SIDs).

昄DAP-related names (including DNs, RDNs, URLs, and canonical names).

昈bject GUIDs.

昄ogon names (including UPN and SAM account names).

If your organization has several domains, it is possible to use the same user name or computer name in different domains. The security ID, GUID, LDAP distinguished name, and canonical name generated by Active Directory uniquely identify each user or computer in the directory. If the user or computer object is renamed or moved to a different domain, the security ID, LDAP relative distinguished name, distinguished name, and canonical name change, but the GUID generated by Active Directory does not change.

Security Principal Names

A security principal is a Windows 2000 object managed by Active Directory that is automatically assigned a security identifier (SID) for logon authentication and for access to resources. A security principal can be a user account, computer account, or a group, so a security principal name is a name that uniquely identifies a user, computer, or group within a single domain. A security principal object must be authenticated by a domain controller in the domain in which the security principal object is located, and it can be granted or denied access to network resources.

A security principal name is not unique across domains, but, for backward compatibility, it must be unique within its own domain. Security principal objects may be renamed, moved, or contained within a nested domain hierarchy.

The names of security principal objects must conform to the following guidelines:

昑he name cannot be identical to any other user, computer, or group name in the domain. It can contain up to 20 uppercase or lowercase characters except for the following: " / \ [ ] : ; | = , + * ? <>

旳 user name, computer name, or group name cannot consist solely of periods (.) or spaces.

Security IDs (SIDs)

A security identifier (SID) is a unique number created by the security subsystem of the Windows 2000 operating system, and assigned to security principal objects, that is, to user, group, and computer accounts. Every account on your network is issued a unique SID when that account is first created. Internal processes in the Windows 2000 operating system refer to an account's SID rather than to the account's user or group name.

Each Active Directory object is protected by access control entries (ACEs) that identify which users or groups can access that object. Each ACE contains the SID of each user or group who has permission to access that object and defines what level of access is allowed. For example, a user might have read-only access to certain files, read-and-write access to others, and no access to others.

If you create an account, delete it, and then create an account with the same user name, the new account does not have the rights or permissions previously granted to the old account, because the accounts have different SID numbers.

LDAP-related Names

Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service. In the Windows 2000 operating system, all access to Active Directory objects occurs through LDAP. LDAP defines what operations can be performed in order to query and modify information in a directory and how information in a directory can be securely accessed. Therefore, it is LDAP that you use to find or enumerate directory objects and to query or administer Active Directory. (For more about LDAP, see the section "Lightweight Directory Access Protocol.")

It is possible to query by LDAP distinguished name (which is itself an attribute of the object), but because they are difficult to remember, LDAP also supports querying by other attributes (for example, color to find color printers). This lets you find an object without having to know the distinguished name.

The following three subsections describe Active Directory-supported object-naming formats that are all based on the LDAP distinguished name:

昄DAP DN and RDN names.

昄DAP URLs.

昄DAP-based canonical names.

LDAP DN and RDN Names

LDAP provides distinguished names (DNs) and relative distinguished names (RDNs) for objects8. Active Directory implements these LDAP naming conventions with the variations shown in Table 2.

Table 2 LDAP naming conventions and their Active Directory counterparts
LDAP DNRDN Naming Convention | Corresponding Active Directory Naming Convention
cn=common name | cn=common name
ou=organizational unit | ou=organizational unit
o=organization | dc=domain component
c=country | (not supported)

Note: cn=, ou=, etc are attribute types. The attribute type used to describe an object's RDN is called the naming attribute. The Active Directory naming attributes, shown on the right above, are for the following Active Directory object classes:

昪n is used for the user object class

昽u is used for the organizational unit (OU) object class

昫c is used for the domainDns object class

Every Active Directory object has an LDAP DN. Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the DN. The name of the object itself is defined by the RDN. The RDN is that segment of an object's DN that is an attribute of the object itself.

By using the full path to an object, including the object name and all parent objects to the root of the domain, the DN identifies a unique object within the domain hierarchy. Each RDN is stored in the Active Directory database and contains a reference to its parent. During an LDAP operation, the entire DN is constructed by following the references to the root. In a complete LDAP DN, the RDN of the object to be identified appears at the left with the name of the leaf, and it ends at the right with the name of the root, as shown in this example:

cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName.dc=com

The RDN of the JDoe user object is cn=JDoe, the RDN of Widget (the parent object of JDoe) is ou=Widgets, and so on.

Active Directory tools do not display the LDAP abbreviations for the naming attributes (dc=, ou=, or cn=). These abbreviations are shown only to illustrate how LDAP recognizes the portions of the DN. Most Active Directory tools display object names in canonical form (described later). The Windows 2000 operating system uses the DN to let an LDAP client retrieve an object's information from the directory, but no Windows 2000 user interface requires you to enter DNs. The explicit use of DNs, RDNs, and naming attributes is required only when you are writing LDAP-compliant programs or scripts.

Remy_3D

Active Directory supports access using the LDAP protocol from any LDAP-enabled client. RFC 1959 describes a format for an LDAP Uniform Resource Locator (URL) that lets Internet clients have direct access to the LDAP protocol. LDAP URLs are also used in scripting. An LDAP URL begins with the prefix "LDAP," and then it names the server holding Active Directory services followed by the attributed name of the object (the distinguished name). For example:

LDAP://server1.USRegion.OrgName.com/cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName,dc=com

LDAP-based Active Directory Canonical Names

By default, Active Directory administrative tools display object names using the canonical name format, which lists the RDNs from the root downward and without the RFC 1779 naming attribute descriptors (dc=, ou=, or cn=). The canonical name uses the DNS domain name format, that is, the constituents of the domain labels section of the name are separated by periods桿SRegion.OrgName.com. Table 3 contrasts the LDAP DN with the same name in canonical name format.

Table 3 LDAP DN format contrasted with the canonical name format
Same Name in Two Formats
LDAP DN Name: cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName.dc=com
Canonical Name: USRegion.OrgName.com/Manufacturing/Widgets/JDoe

Object GUIDs

In addition to its LDAP DN, every object in Active Directory has a globally unique identifier (GUID), a 128-bit number assigned by the Directory System Agent when the object is created. The GUID, which cannot be altered or removed, is stored in an attribute, objectGUID, which is a required attribute for every object. Unlike a DN or RDN, which can be changed, the GUID never changes.

When storing a reference to an Active Directory object in an external store (for example, a Microsoft SQL Server

Remy_3D

Publishing is the act of creating objects in the directory that either directly contain the information you want to make available or provide a reference to it. For example, a user object contains useful information about users, such as their telephone numbers and e-mail addresses, and a volume object contains a reference to a shared file system volume.

Here are two examples梡ublishing file and print objects in Active Directory:

昜i]Share publishing. You can publish a shared folder as a volume object (also called a shared folder object) in Active Directory, using the Active Directory Users and Groups snap-in. This means that users can now easily and quickly query Active Directory for that shared folder.

昜i]Printer publishing. In a Windows 2000 domain, the easiest way to manage, locate, and connect to printers is through Active Directory. By default10, when you add a printer using the Add Printer wizard and elect to share the printer, Windows 2000 Server publishes it in the domain as an object in Active Directory. Publishing (listing) printers in Active Directory lets users locate the most convenient printer. Users can now easily query Active Directory for any of these printers, searching by printer attributes such as type (PostScript, color, legal-sized paper, and so on) and location. When a printer is removed from the server, it is unpublished by the server.

You can also publish non-Windows 2000-based printers (that is, printers on non-Windows 2000-based print servers) in Active Directory. To do so, use the Active Directory Users and Computers tool to enter the universal naming convention (UNC) path for the printer. Alternatively, use the Pubprn.vbs script provided in the System32 folder. The Group Policy Downlevel Printer Pruning determines how the pruning service (automatic removal of printers) handles printers on non-Windows 2000-based print servers when a printer is not available.

When to Publish

You should publish information in Active Directory when it is useful or interesting to a large part of the user community and when it needs to be highly accessible.

Information published in the Active Directory has two major characteristics:

昜i]Relatively static. Publish only information that changes infrequently. Telephone numbers and e-mail addresses are examples of relatively static information suitable for publishing. The user's currently selected e-mail message is an example of highly volatile information.

昜i]Structured. Publish information that is structured and can be represented as a set of discrete attributes. A user's business address is an example of structured information suitable for publishing. An audio clip of the user's voice is an example of unstructured information better suited to the file system.

Operational information used by applications is an excellent candidate for publishing in Active Directory. This includes global configuration information that applies to all instances of a given application. For example, a relational database product could store the default configuration for database servers as an object in Active Directory. New installations of that product can then collect the default configuration from the object, simplifying the installation process and enhancing the consistency of installations in an enterprise.

Applications can also publish their connection points in Active Directory. Connection points are used for a client/server rendezvous. Active Directory defines an architecture for integrated service administration using Service Administration Point objects and provides standard connection points for Remote Procedure Call (RPC), Winsock, and Component Object Model (COM)-based applications. Applications that do not use the RPC or Winsock interfaces for publishing their connection points can explicitly publish Service Connection Point objects in Active Directory.

Application data can also be published in the directory using application-specific objects. Application-specific data should meet the criteria discussed above. Data should be globally interesting, relatively non-volatile, and structured.

How to Publish

The means of publishing information varies according to the application or service:

昍emote Procedure Call (RPC). RPC applications use the RpcNs* family of APIs to publish their connection points in the directory and to query for the connection points of services that have published theirs.

昗indows Sockets. Windows Sockets applications use the Registration and Resolution family of APIs available in Winsock 2.0 to publish their connection points and query for the connection points of services that have published theirs.

旸istributed Component Object Model (DCOM). DCOM services publish their connection points using the DCOM Class Store, which resides in Active Directory. DCOM is the Microsoft Component Object Model (COM) specification that defines how components communicate over Windows-based networks. Use the DCOM Configuration tool to integrate client/server applications across multiple computers. DCOM can also be used to integrate robust Web browser applications.

Remy_3D

Domains: Trees, Forests, Trusts, and OUs

Active Directory is made up of one or more domains. Creating the initial domain controller in a network also creates the domain梱ou 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 and Trusts tool to manage domains.

You use domains to accomplish the following network management goals:

昜i]Administrative Boundaries. A Windows 2000 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, domains in Active Directory do not provide isolation from each other, and are therefore no security boundaries. Only the forest constitutes a security boundary.

昜i]Replicate information. A domain is a Windows 2000 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.

昜i]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 and application deployment. These policies are applied only within the domain and not across domains.

昜i]Structure the network. Because one Active Directory domain can span multiple sites and can contain millions of objects11, most organizations do not need to create separate domains to reflect the company's divisions and 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 and organize them into an Active Directory 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.)

昜i]Delegate administrative authority. In networks running Windows 2000, you can narrowly delegate administrative authority for individual organizational units as well as for individual domains, which reduces the number of administrators needed with 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 administrator with 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 Active Directory forest are tightly coupled. An administrator in one domain can always find ways to grant himself access to resources in other domains in the forest, even if the administrator of the other domain has not specifically allowed the access.

Understanding domains includes understanding trees, forests, trusts, and organizational units, and how each of these structures relates to domains. Each of these domain components is described in the following subsections:

昑rees

旻orests

昑rust Relationships

昈rganizational units

The Windows 2000 operating system also introduces the related concept of sites, but site structure and domain structure are separate梩o provide for flexible administration梥o sites are handled in a later section. This paper presents the basics about Windows 2000-based domains and sites. For detailed information about how to plan their structure and deployment, see the Microsoft Windows 2000 Server Deployment Planning Guide in "For More Information" at the end of this document.

When reading the following subsections describing possible domain structures, keep in mind that for many organizations, a structure consisting of one domain that is simultaneously one forest consisting of one tree is not only possible, but may be the optimal way to organize your network. Always begin with the simplest structure and add complexity only when you can justify doing so.

Remy_3D

In the Windows 2000 operating system, 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, as shown in Figure 3. Windows 2000-based domains that form a tree are linked by trust relationships that are both two-way and transitive. These trust relationships are described later.


Figure 3: Parent and child domains in a domain tree. Double-headed arrows indicate two-way transitive trust relationships

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 results in additional management overhead12. 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 DACL13, 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. (For an example of two forests, see Figure 7 in the section "Example: Mixed Environment of Two Forests and One Extranet.")

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桬nterprise administrators and Schema administrators梤eside in this domain.

For example, as shown in Figure 4, although three domain trees (HQ-Root.com, EuropeRoot.com, and AsiaRoot.com) each have a child domain for Accounting named "Acct", the DNS names for these child domains are Acct.HQ-Root.com, Acct.EuropeRoot.com, and Acct.AsiaRoot.com, respectively. There is no shared namespace.


Figure 4: One forest with three domain trees. The three root domains are not contiguous with each other, but EuropeRoot.com and AsiaRoot.com are child domains of HQ-Root.com.

The root domain of each domain tree in the forest establishes a transitive trust relationship (explained in more detail in the next section) with the forest root domain. In Figure 4, HQ-Root.com is the forest root domain. The root domains of the other domain trees, EuropeRoot.com and AsiaRoot.com, have transitive trust relationships with HQ-Root.com. This establishes trust across all the domain trees in the forest.

All Windows 2000 domains in all of the domain trees in a forest possess the following traits:

旽ave transitive trust relationships among the domains within each tree.

旽ave transitive trust relationships among the domain trees in a forest.

昐hare common configuration information.

昐hare a common schema.

昐hare a common global catalog.

Important: Adding new domains to a forest is easy. However, you cannot move existing Windows 2000 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.

[ Last edited by Remy_3D on 15-3-2004 at 06:13 AM ]

Remy_3D

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, account authentication between domains is enabled by two-way, transitive trust relationships.

All domain trusts in a Windows 2000-based forest are two-way and transitive, defined in the following way:

昜i]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.

昜i]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 in the Windows 2000 operating system, you can explicitly create the following two additional types of trust relationships:

昜i]Shortcut Trusts. Before an account is granted access to resources by a domain controller in another domain, Windows 2000 computes the trust path between the domain controllers for the source domain (where the account is located) and the target domain (where the desired resource is located). A trust path is the series of domain trust relationships Windows 2000 security traverses in order to pass authentication requests between any two domains. Computing and traversing a trust path between domain trees in a complex forest can take time. To improve performance, you can explicitly (manually) create a shortcut trust between non-adjacent Windows 2000 domains in the same forest. Shortcut trusts are one-way transitive trusts that enable you to shorten the path, as shown in Figure 5. You can combine two one-way trusts to create a two-way trust relationship. Although you cannot revoke the default two-way transitive trusts automatically established among all domains in a Windows 2000 forest, you can delete explicitly created shortcut trusts.


Figure 5: Shortcut trusts between Domains B and D, and between Domains D and 2

昜i]External Trusts. External trusts create trust relationships to domains in a different Windows 2000 forest or to a non-Windows 2000 domain (either a Windows NT domain or a Kerberos version 5 realm14). External trusts enable user authentication to an external domain. All external trusts are one-way non-transitive trusts, as shown in Figure 6. Again, you can combine two one-way trusts to create a two-way trust relationship.


Figure 6: One-way external non-transitive trust

In the Windows NT 4.0 (and earlier) operating system, trust relationships are one-way, and trust is restricted to the two domains between which the trust is established (they are non-transitive). When you upgrade a Windows NT朾ased domain to a Windows 2000朾ased one, the existing one-way trust relationships between that domain and any other Windows NT domains are maintained. If you install a new Windows 2000 domain and want to establish trust relationships with Windows NT domains, you must create Windows 2000 external trusts with those domains. To explicitly establish a trust relationship, you use the Active Directory Domains and Trusts tool.

Example: Mixed Environment of Two Forests and One Extranet

Figure 7 illustrates a mixed environment with two Windows 2000 forests and a Windows NT 4.0 domain. In the figure, four separate namespaces are implemented: A.com, D.com, G.com, and F.


Figure 7: A network with two forests and one extranet

Figure 7 illustrates the following state of affairs:

旳.com and D.com are the roots of separate trees in Forest 1. (A.com is the forest root domain.) The two-way, transitive, tree-root trust between them (automatically generated by Windows 2000) provides complete trust between all domains in the two trees of Forest 1.

旹.D.com frequently uses resources in C.A.com. To shorten the trust path between the two domains, C.A.com trusts E.D.com directly. This one-way, transitive shortcut trust shortens the trust path (reduces the number of hops) for authenticating E.D.com users so they can efficiently use resources in C.A.com.

旼.com is the root of a single tree that makes up Forest 2. The automatic two-way, transitive trust between G.com and H.G.com lets users, computers, and groups in both domains be granted access to each others' resources.

旸omain G.com in Forest 2 implements an explicit one-way external trust relationship with domain D.com in Forest 1 so that users in domain D.com can be granted access to resources in domain G.com. Because the trust is nontransitive, no other domains in Forest 1 can be granted access to resources in G.com, and users, groups, and computers from D.com cannot be granted access to resources in H.G.com.

旸omain F is a Windows NT 4.0 domain that provides support services to the users in E.D.com. This one-way nontransitive trust does not extend to any other domains in Forest 1. In this scenario, the Windows NT 4.0 domain is an extranet. (An extranet is an intranet that is partly accessible to authorized outsiders. An intranet resides behind a firewall and is inaccessible, but an extranet provides restricted access to people outside the organization.)

Remy_3D

New in the Windows 2000 operating system, organizational units (also called OUs) are a type of directory object into which you can place users, groups, computers, printers, shared folders, and other organizational units within a single domain. An organizational unit (represented as a folder in the Active Directory Users and Computers interface) lets you logically organize and store objects in the domain. If you have multiple domains, each domain can implement its own organizational unit hierarchy.

As Figure 8 illustrates, organizational units can contain other organizational units.


Figure 8: Organizational unit hierarchy inside a single domain

You use organizational units primarily to delegate administrative authority over sets of users, groups, and resources. For example, you might create an organizational unit to contain all user accounts for your entire company. After creating organizational units to delegate administration, apply Group Policy settings to the organizational units to define desktop configurations for users and computers. Because you use organizational units to delegate administration, the structure you create will probably reflect your administrative model more than your business organization.

Although it is possible for users to navigate a domain's organizational unit structure when looking for resources, querying the global catalog to find resources is much more efficient. Therefore, it is not necessary to create an organizational unit structure that appeals to end-users. It is also possible to create an organizational unit structure that mirrors your business organization, but doing so can prove difficult and expensive to manage. Instead of creating an organizational unit structure to reflect resource location or departmental organization, design organizational units with administrative delegation and Group Policy settings in mind.

For more information about establishing delegation and Group Policy using organizational units, see the section "Use Delegation and Group Policy with OUs, Domains, and Sites." For detailed information about how to design an organizational unit structure when planning how to implement Windows 2000, see the Microsoft Windows 2000 Server Deployment Planning Guide in the section "For More Information" at the end of this document.

Sites: Service Clients and Replicate Data

You can think of a Windows 2000-based site as a set of computers in one or more IP subnets connected using Local Area Network (LAN) technologies, or as a set of LANs connected by a high-speed backbone. Computers in a single site need to be well-connected, which is generally a characteristic of computers within a subnet. In contrast, separate sites are connected by a link that is slower than LAN speed. You use the Active Directory Sites and Services tool to configure connections both within a site (within a LAN or a set of well-connected LANs) and between sites (in a WAN).

In the Windows 2000 operating system, sites provide the following services:

旵lients can request service from a domain controller in the same site (if one exists).

旳ctive Directory tries to minimize replication latency for intra-site replication.

旳ctive Directory tries to minimize bandwidth consumption for inter-site replication.

昐ites let you schedule inter-site replication.

Users and services should be able to access directory information at any time from any computer in the forest. To make this possible, additions, modifications, and deletions of directory data must be relayed (replicated) from the originating domain controller to other domain controllers in the forest. However, the need to widely distribute directory information must be balanced against the need to optimize network performance. Active Directory sites help maintain this balance.

It is important to understand that sites are independent of domains. Sites map the physical structure of your network, whereas domains (if you use more than one) typically map the logical structure of your organization. Logical and physical structures are independent of each other, which has the following consequences:

昑here is no necessary connection between sites and domain namespaces.

昑here is no necessary correlation between your network's physical structure and its domain structure. However, in many organizations, domains are set up to reflect physical network structure. This is because domains are partitions, and partitioning influences replication梡artitioning the forest into multiple, smaller domains can reduce the amount of replication traffic.

旳ctive Directory lets multiple domains appear in a single site and a single domain appear in multiple sites.

How Active Directory Uses Site Information

You specify site information using Active Directory Site and Services, and then Active Directory uses this information to determine how best to use available network resources. Using sites makes the following types of operations more efficient:

昜b]Servicing client requests. When a client requests a service from a domain controller, it directs the request to a domain controller in the same site, if one is available. Selecting a domain controller that is well connected to the client that placed the request makes handling the request more efficient. For example, when a client logs on using a domain account, the logon mechanism first searches for domain controllers that are in the same site as the client. Attempting to use domain controllers in the client's site first localizes network traffic, increasing the efficiency of the authentication process.

昜b]Replicating directory data. Sites enable the replication of directory data both within and among sites. Active Directory replicates information within a site more frequently than across sites, which means that 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. Replicating Active Directory data among domain controllers provides information availability, fault tolerance, load balancing, and performance benefits. (For an explanation of how the Windows 2000 operating system implements replication, see the subsection "Multimaster Replication" at the end of this section on Sites.)

Domain Controllers, Global Catalogs, and Replicated Data

The information stored in Active Directory on every domain controller (whether or not it is a global catalog server) is partitioned into three categories: domain, schema, and configuration data. Each of these categories is in a separate directory partition, which is also called a Naming Context. These directory partitions are the units of replication. The three directory partitions that each Active Directory server holds are defined as follows:

昜b]Domain data directory partition. Contains all of the objects in the directory for this domain. Domain data in each domain is replicated to every domain controller in that domain, but not beyond its domain.

昜b]Schema data directory partition. Contains all object types (and their attributes) that can be created in Active Directory. This data is common to all domains in the domain tree or forest. Schema data is replicated to all domain controllers in the forest.

昜b]Configuration data directory partition. Contains replication topology and related metadata. Active Directory-aware applications store information in the Configuration directory partition. This data is common to all domains in the domain tree or forest. Configuration data is replicated to all domain controllers in the forest.

If the domain controller is a global catalog server, it also holds a fourth category of information:

昜b]Partial replica of domain data directory partition for all domains. In addition to storing and replicating a complete set of all objects in the directory for its own host domain, a global catalog server stores and replicates a partial replica of the domain directory partition for all other domains in the forest. This partial replica, by definition, contains a subset of the properties for all objects in all domains in the forest. (A partial replica is read-only, whereas a complete replica is read/write.)

If a domain contains a global catalog, other domain controllers replicate all objects in that domain (with a subset of their properties) to the global catalog, and then partial replica replication takes place between global catalogs. If a domain has no global catalog, a regular domain controller serves as the source of the partial replica.

By default, the partial set of attributes stored in the global catalog includes those attributes most frequently used in search operations, because one of the primary functions of the global catalog is to support clients querying the directory. Using global catalogs to perform partial domain replication instead of doing full domain replication reduces WAN traffic.

Remy_3D

If your network consists of a single local area network (LAN) or a set of LANs connected by a high-speed backbone, the entire network can be a single site. The first domain controller you install automatically creates the first site, known as the Default-First-Site-Name. After installing the first domain controller, all additional domain controllers are automatically added to the same site as the original domain controller. (Later, if you wish, you can move them to other sites). Here is the only exception: If, at the time you install a domain controller, its IP address falls within the subnet previously specified in an alternative site, the domain controller is then added to this alternative site.

Directory information within a site is replicated frequently and automatically. Intra-site replication is tuned to minimize replication latency, that is, to keep the data as up-to-date as possible. Intra-site directory updates are not compressed. Uncompressed exchanges utilize more network resources but require less domain controller processing power.

Figure 9 illustrates replication within a site. Three domain controllers (one of which is a global catalog) replicate the forest's schema data and configuration data, as well as all directory objects (with a complete set of each object's attributes).


Figure 9: Intra-site replication with just one domain

The configuration formed by the connections used to replicate directory information between domain controllers, called the replication topology, is automatically generated by the Knowledge Consistency Checker (KCC) service in Active Directory. Active Directory site topology is a logical representation of a physical network and is defined on a per-forest basis. Active Directory attempts to establish a topology that allows at least two connections to every domain controller, so if a domain controller becomes unavailable, directory information can still reach all online domain controllers through the other connection.

Active Directory automatically evaluates and adjusts the replication topology to meet the changing state of the network. For example, when a domain controller is added to a site, the replication topology is adjusted to incorporate this new addition efficiently.

Active Directory clients and servers use the forest's site topology to route query and replication traffic efficiently.

If you expand your deployment from the first domain controller in one domain to multiple domain controllers in multiple domains (still within one site), the directory information that is replicated changes to include the replication of the partial replica between global catalogs in different domains. Figure 10 shows two domains, each containing three domain controllers. One domain controller in each site is also a global catalog server. Within each domain, the domain controllers replicate the forest's schema data and configuration data, as well as all directory objects (with a complete set of each object's attributes), just as in Figure 9. In addition, each global catalog replicates the directory objects (with only a subset of their attributes) for its own domain to the other global catalog.


Figure 10: Intra-site replication with two domains and two global catalogs

Replication between Sites

Create multiple sites to optimize both server-to-server and client-to-server traffic over WAN links. In the Windows 2000 operating system, inter-site replication automatically minimizes bandwidth consumption between sites.

Recommended practices when setting up multiple sites include the following:

昜b]Geography. Establish every geographic area that requires fast access to the latest directory information as a site. Establishing areas that require immediate access to up-to-date Active Directory information as separate sites provides the resources required to meet your users' needs.

昜b]Domain controllers and global catalogs. Place at least one domain controller in every site, and make at least one domain controller in each site a global catalog. Sites that do not have their own domain controllers and at least one global catalog are dependent on other sites for directory information and are less efficient.

How Sites Are Connected

Network connections between sites are represented by site links. A site link is a low-bandwidth or unreliable connection between two or more sites. A WAN that connects two fast networks is an example of a site link. Generally, consider any two networks connected by a link that is slower than LAN speed to be connected by a site link. In addition, a fast link that is near capacity has a low effective bandwidth and is also considered a site link. When you have multiple sites, sites connected by site links become part of the replication topology.

In a Windows 2000-based network, site links are not automatically generated梱ou must create them using Active Directory Sites and Services. By creating site links and configuring their replication availability, relative cost, and replication frequency, you provide Active Directory with information about what Connection objects to create to replicate directory data. Active Directory uses site links as indicators for where it should create Connection objects, and Connection objects use the actual network connections to exchange directory information.

A site link has an associated schedule that indicates at what times of day the link is available to carry replication traffic.

By default, site links are transitive, which means that a domain controller in one site can make replication connections with domain controllers in any other site. That is, if site A is connected to site B, and site B is connected to site C, then domain controllers in site A can communicate with domain controllers in site C. When you create a site, you may want to create additional links to enable specific connections between sites and customize existing site links connecting the sites.

Figure 11 shows two sites connected by a site link. Of the six domain controllers in the figure, two are bridgehead servers (the bridgehead server role is assigned automatically by the system).


Figure 11: Two sites connected by a site link. Each site's preferred bridgehead server is used preferentially for inter-site information exchange.

The bridgehead servers are the preferred servers for replication, but you can also configure the other domain controllers in the site to replicate directory changes between sites.

After updates are replicated from one site to the bridgehead server in the other site, the updates are then replicated to other domain controllers within the site through intra-site replication. Although a single domain controller receives the initial inter-site directory update, all domain controllers service client requests.

Remy_3D

Directory information can be exchanged using the following network protocols:

昜b] IP replication. IP replication uses remote procedure calls (RPC) for replication within a site (intra-site) and over site links (inter-site). By default, inter-site IP replication adheres to replication schedules. IP replication does not require a certification authority (CA).

Remy_3D

In the Windows NT 4.0 operating system, administrators sometimes delegate administration by creating multiple domains in order to have distinct sets of domain administrators. In the Windows 2000 operating system, organizational units are easier to create, delete, move, and modify than domains, and they are thus better suited to the delegation role.

To delegate administrative authority (other than authority over sites, covered next), you grant a group specific rights over a domain or organizational unit by modifying the container's discretionary access control list (DACL). By default, members of the domain administrators (Domain Admin) security group have authority over the entire domain, but you can restrict membership in this group to a limited number of highly trusted administrators. To establish administrators with lesser scope, you can delegate authority down to the lowest level of your organization by creating a tree of organizational units within each domain and delegating authority for parts of the organizational unit subtree.

Domain administrators have full control over every object in their domain. However, they do not have administrative rights over objects in other domains.

You delegate administration of a domain or organizational unit by using the Delegation of Control wizard available in the Active Directory Users and Computers snap-in. Right-click the domain or organizational unit, select Delegate Control, add the groups (or users) to whom you want to delegate control, and then either delegate the listed common tasks, or create a custom task to delegate. The common tasks you can delegate are listed in the following table.

Domain Common Tasks You Can Delegate

halo brader Remy_3D..

bro pernah / experience implement Active Directory 2000 @ 2003 nie tak??
bole tolong bg saya guideline tak kalau saya nak buat migration from Win NT4.0 kepada Windows 2003 Server??

which one is easier and better performance between upgrade and migate??
most important which one is easier to implement??

thank you....