Other Active Directory Components

[Previous] [Next]

Active Directory is a complex system that includes far more than this basic logical structure. This section highlights several other components that play a critical role within Active Directory.

Naming Partitions

You can think of Active Directory as being divided into three parts: domains, configuration, and schema. Each part is called a naming partition because it is a self-contained section of Active Directory that can have its own properties, such as replication configuration and permissions structure. A Windows 2000 domain controller will always hold three naming partitions in its database file (Ntds.dit):

• Configuration (sample LDAP path: cn=configuration,dc=sales,dc=microsoft,dc=com)
• Schema (sample LDAP path: cn=schema,cn=configuration,dc=sales,dc=microsoft,dc=com)
• Domain (sample LDAP path: dc=sales,dc=microsoft,dc=com)

In a multidomain structure, domain controllers belong to different domains. These servers share a common configuration and schema naming partition but have a unique domain naming partition. Exchange 2000 Server stores most of its information in the configuration naming partition. Because this partition is replicated throughout the forest, global administration is easier than in Exchange 5.5.

Sites

A site within Active Directory is a collection of IP subnets that enjoy permanent, high-bandwidth connectivity. Active Directory assumes that all computers in the same site have permanent, high-speed connectivity with one another. Sites tend to map to the physical structure of your network: slow WAN links will be considered outside your sites, and high-speed links will form your sites.

Site and domain topologies are not dependent upon each other; a single domain can span multiple sites, or multiple domains can be located in a single site. Since the bandwidth between sites is assumed to be slow or unreliable, it stands to reason that some type of connector is needed to connect the sites. That connector is call a site link.

Site links are built manually by the administrator and form the physical topology of the network. To create replication paths between domain controllers across the site links (as well as between domain controllers within the same site), Windows 2000 employs the knowledge consistency checker (KCC), which runs automatically but can be configured manually, if necessary. The KCC creates connection objects on each domain controller in the configuration naming partition that form the overall replication topology over which Active Directory information can be replicated. The KCC is a service that runs on each domain controller to create the connection objects for that domain controller.

Location Service Providers

In Windows NT 4, to find a service such as the server service on a domain controller, the client needs to contact the Windows Internet Name Service (WINS) to obtain the IP address of the server offering that service (WINS offers dynamic mapping of NetBIOS names to IP addresses). In Windows 2000, DNS takes on this role and helps the client find the services it needs on the network. Dynamic DNS is supplied with Windows 2000 and is a standard part of the Active Directory installation. With dynamic DNS, clients query DNS service (SRV) records to locate services on the network.

Global Catalog Servers

In a multidomain environment, it is reasonable to assume that some users will need access to objects outside of their own domain. For instance, a user in domain A may need access to a color printer located in domain B. Since domain controllers maintain only a replica of objects in their own domain, a special service is needed in the forest to gain access to objects located in remote domains. The Global Catalog server performs this function. This server holds a replica of all objects in the forest, with a limited set of attributes for those objects. The schema defines which attributes are listed for each object in the Global Catalog.

TIP

---

By default, there is only one Global Catalog server in the entire forest, and that is the first domain controller installed in the first domain of the first tree. All other Global Catalog servers need to be configured manually. You can do this by opening the Active Directory Sites and Services snap-in, navigating to the NTDS settings on the server you want to install this service on, right-clicking NTDS Settings, choosing Properties, and selecting the Global Catalog Server check box.

In addition to users needing access to services outside their domain, some applications need access to a forestwide listing of objects. Exchange 2000 Server is one of those applications. For instance, when a user wants to browse the Global Address List, this list is generated by the Global Catalog server, which gathers each mail-enabled object into a list and returns it to the user inside the address book interface.

Even in a single-domain environment, Exchange clients are referred to the Global Catalog server for address book lookups. In this scenario, the default is to refer all those lookups to the root domain controller. The best practice is to create two or more Global Catalog servers for redundancy and scalability.

A Global Catalog server is represented as an SRV record in the DNS database. There are two ways to locate the Global Catalog server: by service and by both service and site name. To find a domain controller without specifying the site name, you would specify a node path of ._tcp._gc._msdcs.domain. The entry name would be _LDAP, and the entry data would be [0][100][3268] server-name.domain. Figure 4-3 illustrates what this entry looks like in the DNS snap-in. Table 4-2 shows node paths for other DNS resource records in Windows 2000.

Figure 4-3. DNS entry for Global Catalog services on indianapolis.hr.oaktree.com.

It is helpful to note that a Global Catalog server will pass back different attributes depending on the TCP port used for the query. For instance, a query to port 389 (the default LDAP port) allows a client to search for objects only within the home domain, and the full set of attributes for the object is returned, whereas a query over port 3268 allows a client to search for objects in the entire forest, including the home domain of the Global Catalog server. However, a query over this port returns only a subset of the attributes available, even if the object is in the home domain of the Global Catalog server.

Table 4-2. Resource records registered by Windows 2000 domain controllers

What the Record Does	Node Path
Finds a Windows 2000 domain controller in the domain named DNSdomainname. Each domain controller registers this record.	_ldap._tcp.<DNSdomainname> Example: _ldap._tcp.hr.oaktree.com
Finds a domain controller in a specified site. Each domain controller registers this record.	_ldap._tcp.<sitename>.sites.<DNSdomainname > Example: _ldap._tcp.defaultfirstsitename.sites.hr.oaktree.com
Finds a PDC in a mixed mode domain. Only the PDC of the domain registers this record; it is responsible for unregistering any other registrations of this record.	_ldap._tcp.pdc._msdcs.<DNSdomainname> Example: _ldap._tcp.pdc._msdcs.hr.oaktree.com.
Finds a Global Catalog server. Only Global Catalog servers register this name.	_ldap._tcp.gc._msdcs.<DNSdomainname> Example: _ldap._tcp.gc._msdcs.hr.oaktree.com
Finds a Global Catalog server when the site name is specified.	_ldap._tcp.<sitename>.sites.gc._msdcs. <DNSdomainname> Example: _ldap._tcp.defaultfirstsitename.sites.gc._msdcs.hr.oaktree.com
Finds a domain controller based on its GUID.	_ldap._tcp.<domainGUID>.domains._msdcs. <DNSdomainname> Example: _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.hr.oaktree.com
Finds a domain controller that holds a modifiable copy of the directory in a specified domain. In mixed mode, the PDC always registers this record. In native mode, all domain controllers register this name.	_ldap._tcp.writable._msdcs.<DNSdomainname > Example: _ldap._tcp.writable._msdcs.hr.oaktree.com
Finds a domain controller that holds a writable copy of the directory in a specified domain and a specified site.	_ldap._tcp.<sitename>.sites.writable._msdcs. <DNSdomainname> Example: _ldap._tcp.defaultfirstsitename.sites.writable._msdcs.hr.oaktree.com
Finds a domain controller by a normal A (host) record DNS lookup. This record is registered by the Net Logon service	<DNSdomainname> Example: Hr.oaktree.com

Client Authentication

When a client attempts to log on to the domain, it queries DNS SRV records to locate a domain controller. DNS attempts to match the client's IP address to an Active Directory site and then returns a list of domain controllers that can authenticate the client. The client chooses a domain controller at random from the list and then pings it before sending the logon request. In native mode, the authenticating domain controller passes the client's credentials to the local Global Catalog server so that the Global Catalog can enumerate universal security group access.

Active Directory Names

Both users and applications are affected by the naming conventions that a directory uses. To locate a network resource, you'll need to know its name or one of its properties. Active Directory supports many naming schemes for the different formats that can access Active Directory.

Distinguished Name

Each object in the directory has a distinguished name (DN) that identifies where the object resides in the overall object hierarchy. For example,

cn=benglish,cn=users,dc=microsoft,dc=com

would indicate that the user object Benglish is in the Users container that is located in the microsoft.com domain. If the Benglish object is moved to another container, its DN will change to reflect its new position in the hierarchy. Distinguished names are guaranteed to be unique in the forest. You cannot have two objects with the same distinguished name.

Relative Distinguished Name

The relative distinguished name of an object is that part of the distinguished name that is an attribute of the object. In the former example, the relative distinguished name of the Benglish object is Benglish. The relative distinguished name of the parent organizational unit is Users. Active Directory will not allow two objects with the same relative distinguished name under the same parent container.

User Principal Name

The user principal name that is generated for each object is in the form username@DNSdomainname. Users can log on with their user principal name, and an administrator can define suffixes for user principal names if desired. User principal names are required to be unique, but Active Directory does not enforce this requirement. It's best, however, to formulate a naming convention that avoids duplicate user principal names.

Globally Unique Identifier

Some applications require that an object be referred to by an identifier that remains constant. This is achieved by adding an attribute called the globally unique identifier (GUID), a 128-bit number that is guaranteed to be unique. A GUID is assigned to an object when it is created, and it will never change, even if the object is moved between containers in the same domain.