Other Active Directory Components

Active Directory is a complex system that includes far more than the basic logical structure just described. 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 distinct directories, or partitions: the domain partition, the configuration partition, and the schema partition. Each partition is a self-contained section of Active Directory that can have its own properties, such as replication configuration and permissions structure. A Windows Server 2003 domain controller will always hold three naming partitions in its database file (Ntds.dit). These are the default LDAP paths for these partitions:

• Configuration: cn=configuration,dc=sales,dc=microsoft,dc=com

• Schema: cn=schema,cn=configuration,dc=sales,dc=microsoft,dc=com

• Domain: 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 Server 2003 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 Internet protocol (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 called 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 Server 2003 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; these connection objects 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 Server 2003, DNS takes on this role and helps the client find the services it needs on the network. Dynamic DNS is supplied with Windows Server 2003 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 domains. For instance, a user in domain A might 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. The Global Catalog is not a separate file; it is instead held inside the NTDS.DIT file. The GC will be roughly 40 percent of the size of your active directory, or the size of the your NTDS.DIT file on a non-GC domain controller.

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 Server 2003 is one of those applications. For instance, a user might want to browse the Global Address List, which is generated by the Global Catalog server. The Global Catalog server gathers each mail-enabled object into a list and returns this list 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.

Figure 4-3: DNS entry for Global Catalog services on indianapolis.trainsbydave.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, with the full set of attributes for the object being returned. In contrast, a query over port 3268 allows a client to search for domain objects from all domains in the 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.

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