Lesson 2: Understanding Active Directory Concepts - MCSE Training Kit, Microsoft Windows 2000 Active Directory Services [Electronic resources] نسخه متنی

Lesson 2: Understanding Active Directory Concepts

There are several new concepts introduced with Active Directory, including the global catalog, replication, trust relationships, DNS namespaces, and naming conventions. It is important that you understand the meaning of these concepts as applied to Active Directory.

After this lesson, you will be able to

Explain the purpose of the global catalog in Active Directory

Explain Active Directory replication

Explain the security relationships between domains in a tree (trusts)

Describe the DNS namespace used by Active Directory

Describe the naming conventions used by Active Directory

Estimated lesson time: 20 minutes

Global Catalog

The global catalog is the central repository of information about objects in a tree or forest, as shown in Figure 2.6. By default, a global catalog is created automatically on the initial domain controller in the forest, known as the global catalog server. It stores a full replica of all object attributes in the directory for its host domain and a partial replica for all object attributes contained in the directory of every domain in the forest. The partial replica stores attributes most frequently used in search operations (such as a user''s first and last names, logon name, and so on). Object attributes replicated to the global catalog inherit the same permissions as in source domains, ensuring that data in the global catalog is secure.

Figure 2.6 The global catalog is the central repository of information

The global catalog performs two key directory roles:

It enables network logon by providing universal group membership information to a domain controller when a logon process is initiated.

It enables finding directory information regardless of which domain in the forest actually contains the data.

When a user logs on to the network, the global catalog provides universal group membership information for the account to the domain controller processing the user logon information. If there is only one domain controller in the domain, the domain controller and the global catalog are the same server. If there are multiple domain controllers in the network, the global catalog is the domain controller configured as such. If a global catalog is not available when a user initiates a
network logon process, the user is only able to log on to the local computer.

IMPORTANT
If a user is a member of the Domain Admins group, he or she is able to log on to the network even when the global catalog is not available.

The global catalog is designed to respond to user and programmatic queries about objects anywhere in the domain tree or forest with maximum speed and minimum network traffic. Because a single global catalog contains information about all objects in all domains in the forest, a query about an object can be
resolved by a global catalog in the domain in which the query is initiated. Thus, finding information in the directory does not produce unnecessary query traffic across domain boundaries.

You can optionally configure any domain controller or designate additional
domain controllers as global catalog servers. When considering which domain controllers to designate as global catalog servers, base your decision on the ability of your network structure to handle replication and query traffic. However, the availability of additional servers can provide quicker responses to user inquiries, as well as redundancy. It is recommended that every major site in your enterprise have at least one global catalog server.

Replication

Users and services should be able to access directory information at any time from any computer in the domain tree or forest. Replication ensures that changes to a domain controller are reflected in all domain controllers within a
domain. Directory information is replicated to domain controllers both within and among sites.

What Information Is Replicated ?

The information stored in the directory is partitioned into three categories. Each of these information categories is referred to as a directory partition. These
directory partitions are the units of replication. The following information is
contained in each directory:

Schema information. This defines the objects that can be created in the directory and what attributes those objects can have. This information is common to all domains in the domain tree or forest.

Configuration information. This describes the logical structure of your deployment, containing information such as domain structure or replication topology. This information is common to all domains in the domain tree or forest.

Domain data. This describes all of the objects in a domain. This data is domain-specific and is not distributed to any other domains. For the purpose of finding information throughout the domain tree or forest, a subset of the properties for all objects in all domains is stored in the global catalog.

Schema and configuration information is replicated to all domain controllers in the domain tree or forest. All of the domain data for a particular domain is replicated to every domain controller in that domain. All of the objects in every domain, and a subset of the properties of all objects in a forest, are replicated to the global catalog.

A domain controller stores and replicates:

The schema information for the domain tree or forest.

The configuration information for all domains in the domain tree or forest.

All directory objects and properties for its domain. This data is replicated to any additional domain controllers in the domain. For the purpose of finding information, a subset of the properties of all objects in the domain is replicated to the global catalog.

A global catalog stores and replicates:

The schema information for a forest

The configuration information for all domains in a forest

A subset of the properties for all directory objects in the forest (replicated between global catalog servers only)

All directory objects and all their properties for the domain in which the global catalog is located

CAUTION

How Replication Works

Active Directory replicates information within a site more frequently than across sites, balancing the need for up-to-date directory information with the limitations imposed by available network bandwidth.

Replication Within a Site

Within a site, Active Directory automatically generates a topology for replication among domain controllers in the same domain using a ring structure. The topology defines the path for directory updates to flow from one domain controller to another until all domain controllers receive the directory updates (see Figure 2.7).

Figure 2.7 Replication topology

The ring structure ensures that there are at least two replication paths from one domain controller to another; if one domain controller is down temporarily, replication still continues to all other domain controllers.

Active Directory periodically analyzes the replication topology within a site to ensure that it is still efficient. If you add or remove a domain controller from the network or a site, Active Directory reconfigures the topology to reflect the change.

Replication Between Sites

To ensure replication between sites, you must customize how Active Directory replicates information using site links to represent network connections. Active Directory uses the network connection information to generate connection
objects that provide efficient replication and fault tolerance.

You provide information about the replication protocol used, cost of a site link, times when the link is available for use, and how often the link should be used. Active Directory uses this information to determine which site link will be used to replicate information. Customizing replication schedules so replication occurs during specific times, such as when network traffic is light, will make replication more efficient.

NOTE
When operating in Native Mode, Windows 2000 domain controllers do not replicate with pre-Windows 2000 domain controllers.

Trust Relationships

A trust relationship is a link between two domains in which the trusting domain honors the logon authentication of the trusted domain. Active Directory supports two forms of trust relationships:

Implicit two-way transitive trust. A relationship between parent and child domains within a tree and between the top-level domains in a forest. This is the default; trust relationships among domains in a tree are established and maintained implicitly (automatically). Transitive trust is a feature of the Kerberos authentication protocol, which provides the distributed authentication and authorization in Windows 2000.

For example, in Figure 2.8 a Kerberos transitive trust simply means that if
Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A trusts Domain C. As a result, a domain joining a tree immediately has trust
relationships established with every domain in the tree. These trust relationships make all objects in the domains of the tree available to all other domains in the tree.

Transitive trust between domains eliminates the management of interdomain trust accounts. Domains that are members of the same tree automatically participate in a transitive, bidirectional trust relationship with the parent domain. As a result, users in one domain can access resources to which they have been granted permission in all other domains in a tree.

Figure 2.8 Active Directory supports two types of trust relationships

Explicit one-way nontransitive trust. A relationship between domains that are not part of the same tree. A nontransitive trust is bounded by the two domains in the trust relationship and does not flow to any other domains in the forest. In most cases, you must explicitly (manually) create nontransitive trusts. For example, in Figure 2.8, a one-way, nontransitive trust is shown where Domain C trusts Domain 1, so users in Domain 1 can access resources in Domain C. Explicit one-way nontransitive trusts are the only form of trust possible with

A Windows 2000 domain and a Windows NT domain

A Windows 2000 domain in one forest and a Windows 2000 domain in another forest

A Windows 2000 domain and an MIT Kerberos V5 realm, allowing a client in a Kerberos realm to authenticate to an Active Directory domain in order to access network resources in that domain

DNS Namespace

Active Directory, like all directory services, is primarily a namespace. A namespace is any bounded area in which a name can be resolved. Name resolution is the process of translating a name into some object or information that the name represents. The Active Directory namespace is based on the DNS naming scheme, which allows for interoperability with Internet technologies. Private networks use DNS extensively to resolve computer names and to locate computers within their local networks and the Internet. DNS provides the following benefits:

DNS names are user-friendly, which means they are easier to remember than IP addresses.

DNS names remain more constant than IP addresses. An IP address for a server can change, but the server name remains the same.

DNS allows users to connect to local servers using the same naming convention as the Internet.

NOTE
For more information on DNS, see RFCs 1034 and 1035. To read the text of these Requests for Comment (RFCs), use your Web browser to search for RFC 1034 and RFC 1035.

Because Active Directory uses DNS as its domain naming and location service, Windows 2000 domain names are also DNS names. Windows 2000 Server uses Dynamic DNS (DDNS), which enables clients with dynamically assigned
addresses to register directly with a server running the DNS service and update the DNS table dynamically. DDNS eliminates the need for other Internet naming
services, such as Windows Internet Name Service (WINS), in a homogeneous environment.

IMPORTANT
For Active Directory and associated client software to function
correctly, you must have installed and configured the DNS service.

Domain Namespace

The domain namespace is the naming scheme that provides the hierarchical structure for the DNS database. Each node represents a partition of the DNS
database. These nodes are referred to as domains.

The DNS database is indexed by name; therefore, each domain must have a name. As you add domains to the hierarchy, the name of the parent domain is
appended to its child domain (called a subdomain). Consequently, a domain''s name identifies its position in the hierarchy. For example, in Figure 2.9, the
domain name sales.microsoft.com identifies the sales domain as a subdomain of the microsoft.com domain and microsoft as a subdomain of the com domain.

Figure 2.9 Hierarchical structure of a domain namespace

The hierarchical structure of the domain namespace typically consists of a root domain, top-level domains, second-level domains, and host names.

There are two types of namespaces:

Contiguous namespace. The name of the child object in an object hierarchy always contains the name of the parent domain. A tree is a contiguous namespace.

Disjointed namespace. The names of a parent object and a child of the same parent object are not directly related to one another. A forest is a disjointed namespace. For example, consider the domain names

www.microsoft.com

msdn.microsoft.com

www.msn.com

The first two domain names create a contiguous namespace within microsoft.com, but the third domain is part of a disjointed namespace.

NOTE
The term domain, in the context of DNS, is not related to domain as used
in Windows 2000 directory services. A Windows 2000 domain is a group of
computers and devices that are administered as a unit.

Root Domain

The root domain is at the top of the hierarchy and is represented as a period (.). The Internet root domain is managed by several organizations, including
Network Solutions, Inc.

Top-Level Domains

Top-level domains are organized by organization type or geographic location. Table 2.1 provides some examples of top-level domain names.

Table 2.1 Examples of Top-Level Domains

NOTE

Top-level domains can contain second-level domains and host names.

Second-Level Domains

Organizations, such as Network Solutions, Inc. and others, assign and register second-level domains to individuals and organizations for the Internet. A second-level name has two name parts: a top-level name and a unique second-level name. Table 2.2 provides some examples of second-level domains.

Table 2.2 Examples of Second-Level Domains

NOTE
In the case of country names, "gov.au", "edu.au", and "com.au" are
top-level domains. If the name is structured as "company.au", however (and in this case only), ".au" is top-level.

Host Names

Host names refer to specific computers on the Internet or a private network. For example, in Figure 2.9, Computer1 is a host name. A host name is the leftmost portion of a fully qualified domain name (FQDN), which describes the exact
position of a host within the domain hierarchy. In Figure 2.9, Computer1.sales. microsoft.com. (including the end period, which represents the root domain) is an FQDN.

NOTE
The host name does not have to be the same as the computer name, NetBios, or any other naming protocol.

Zones

A zone represents a discrete portion of the domain namespace. Zones provide a way to partition the domain namespace into manageable sections.

Multiple zones in a domain namespace are used to distribute administrative tasks to different groups. For example, Figure 2.10 depicts the microsoft.com domain namespace divided into two zones. The two zones allow one administrator to manage the microsoft and sales domains and another administrator to manage the development domain.

A zone must encompass a contiguous domain namespace. For example, in Figure 2.10, you could not create a zone that consists of only the sales.microsoft.com and development.microsoft.com domains because the sales and development
domains are not contiguous.

The name-to-IP-address mappings for a zone are stored in the zone database file. Each zone is anchored to a specific domain, referred to as the zone''s root
domain. The zone database file does not necessarily contain information for all subdomains of the zone''s root domain, only those subdomains within the zone.

Figure 2.10 Domain namespace divided into zones

In Figure 2.10, the root domain for Zone1 is microsoft.com and its zone file
contains the name-to-IP-address mappings for the microsoft and sales domains. The root domain for Zone2 is development, and its zone file contains the name-to-IP-address mappings for the development domain only. The zone file for Zone1 does not contain the name-to-IP-address mappings for the development domain, although development is a subdomain of the microsoft domain.

Name Servers

A DNS name server stores the zone database file. Name servers can store data for one zone or multiple zones. A name server is said to have authority for the domain namespace that the zone encompasses.

One name server contains the master zone database file, referred to as the
primary zone database file, for the specified zone. As a result, there must be at least one name server for a zone. Changes to a zone, such as adding domains or hosts, are performed on the server that contains the primary zone database file.

Multiple name servers act as a backup to the name server containing the primary zone database file. Multiple name servers provide the following advantages:

They perform zone transfers. The additional name servers obtain a copy of the zone database file from the name server that contains the primary database zone file. This is called a zone transfer. These name servers periodically query the name server containing the primary zone database file for updated zone data.

They provide redundancy. If the name server containing the primary zone database file fails, the additional name servers can provide service.

They improve access speed for remote locations. If there are a number of clients in remote locations, use additional name servers to reduce query traffic across slow wide area network (WAN) links.

They reduce the load on the name server containing the primary zone database file.

NOTE
You can find information on configuring DNS for Active Directory in Chapter 5, "DNS and Active Directory Integration."

Naming Conventions

Every object in Active Directory is identified by a name. Active Directory uses a variety of naming conventions: distinguished names, relative distinguished names, globally unique identifiers, and user principal names.

Distinguished Name

Every object in Active Directory has a distinguished name (DN) that uniquely identifies an object and contains sufficient information for a client to retrieve the object from the directory. The DN includes the name of the domain that holds the object, as well as the complete path through the container hierarchy to the object.

For example, the following DN identifies the Firstname Lastname user object in the microsoft.com domain (where Firstname and Lastname represent the actual first and last name of a user account):

/DC=COM/DC=microsoft/OU=dev/CN=Users/CN=Firstname Lastname

Table 2.3 describes the attributes in the example.

Table 2.3 Distinguished Name Attributes

DNs must be unique. Active Directory does not allow duplicate DNs.

NOTE
For more information on distinguished names, see RFC 1779. To read the text of this Request for Comment (RFC), use your Web browser to search for RFC 1779.

Relative Distinguished Name

Active Directory supports querying by attributes, so you can locate an object even if the exact DN is unknown or has changed. The relative distinguished name (RDN) of an object is the part of the name that is an attribute of the object itself. In the preceding example, the RDN of the Firstname Lastname user object is Firstname Lastname. The RDN of the parent object is Users.

You can have duplicate RDNs for Active Directory objects, but you cannot have two objects with the same RDN in the same OU. For example, if a user account is named Jane Doe, you cannot have another user account called Jane Doe in the same OU. However, objects with duplicate RDN names can exist in separate OUs because they have different DNs (see Figure 2.11).

Figure 2.11 Distinguished names and relative distinguished names

Globally Unique Identifier

A globally unique identifier (GUID) is a 128-bit number that is guaranteed to be unique. GUIDs are assigned to objects when the objects are created. The GUID never changes, even if you move or rename the object. Applications can store the GUID of an object and use the GUID to retrieve that object
regardless of its current DN.

In earlier versions of Windows NT, domain resources were associated to a security identifier (SID) that was generated within the domain. This meant that the SID was only guaranteed to be unique within the domain. A GUID is unique across all domains, meaning that you can move objects from domain to domain and they will still have a unique identifier.

User Principal Name

User accounts have a "friendly" name, the user principal name (UPN). The UPN is composed of a "shorthand" name for the user account and the DNS name of the tree where the user account object resides. For example, Firstname Lastname (substitute the first and last names of the actual user) in the microsoft.com tree might have a UPN of FirstnameL@microsoft.com (using the full first name and the first letter of the last name).

Lesson Summary

In this lesson you learned about several new concepts introduced with Active
Directory, including the global catalog, replication, trust relationships, DNS namespaces, and naming conventions.

You learned that the global catalog is a service and a physical storage location that contains a replica of selected attributes for every object in Active Directory. You can use the global catalog to locate objects anywhere in the network without replication of all domain information between domain controllers.

Active Directory includes replication to ensure that changes to a domain controller are reflected in all domain controllers within a domain. Within a site, Active Directory automatically generates a ring topology for replication among domain controllers in the same domain. Between sites, you must customize how Active Directory replicates information using site links to specify how your sites are connected.

A trust relationship is a link between two domains in which the trusting domain honors the logon authentication of the trusted domain. Active Directory supports two forms of trust relationships: implicit two-way transitive trusts and explicit
one-way nontransitive trusts.

In this lesson you also learned that Active Directory uses DNS as its domain naming and location service; therefore, Windows 2000 domain names are also DNS names. Windows 2000 Server uses DDNS, so clients with dynamically
assigned addresses can register directly with a server running the DNS service and dynamically update the DNS table. There are contiguous namespaces and disjointed namespaces.

Finally, you learned about the naming conventions employed by Active
Directory: DNs, RDNs, GUIDs, and UPNs.