This chapter is from the book

This chapter is from the book

Active Directory Namespace Structure

At this point, we know enough about a generic LDAP directory service to begin applying the terms and concepts to Active Directory.

Let's start with what we need to store in Active Directory. You can classify the required information into three general categories:

Information about network security entities.
This includes users, computers, and groups along with applications such as group policies, DNS, RAS, COM and so forth.

Information about the Active Directory mechanisms.
This includes replication, network services, permissions, and user interface displays.

Information about the Active Directory schema.
This includes objects that define the classes and attributes in Active Directory.

Microsoft had to devise a way to structure this information in a way that was compatible with LDAP while retaining backward compatibility with classic NT. In classic NT, information about security entities is stored in the
SAM and SECURITY databases in the Registry. Microsoft calls the contents of the SAM database a domain. Because the only way
to control access to the SAM is to control access to the entries in the SAM, a domain defines a security boundary as well
as a management boundary.

The SAM databases in classic NT domains cannot be combined. To get a common security boundary, the domains must be knitted
together using trust relationships. When one domain trusts another, members of the trust-ed domain can be used as security entities in the trust-ing domain. The underlying authentication mechanism, NT LanMan Challenge Response, supports this trust relationship by permitting
pass-through authentication of users from trusted domains.

Domains

LDAP gave Microsoft the freedom to construct just about any namespace it chose. There is no naming restriction other than at the
top of the namespace, where the distinguished name of the root object needs to correspond to a DNS domain name.

Janis Joplin had it right, though, that freedom's just another word for nothing left to lose, and Microsoft had a lot to lose
if it designed Active Directory in such a way as to not be compatible with classic NT. For this reason, Microsoft chose to
structure Active Directory around the classic concepts of domains and trust relationships.

In Active Directory, a domain defines a separate namespace, a separate security structure, a separate management structure, and a separate naming context.
The Active Directory database is hosted on domain controllers. Users and computers are members of a domain. Group policies are contained within a particular domain, even if they impact users in other domains.

Active Directory Naming Contexts

Active Directory is capable of holding a billion objects. This is enough to hold account, computer, mailboxes, and group memberships
for every person in the western hemisphere. A big Active Directory database is like an NBA center, though. He may be the key
to winning, but only if he doesn't have to move too fast or too often.

The Active Directory database, Ntds.dit, can grow very quickly. The DIT for a domain with 150,000 objects could be well over
2GB depending on the number of groups and the length of the group membership. A DIT this size can be difficult to replicate
and manage. Also, it does not make sense to replicate information about users in one continent to domain controllers on other
continents unless those users regularly share information.

Domain Naming Contexts

LDAP permits breaking up a directory into separate naming contexts. Managing the interfaces between these naming contexts can get a little
tricky, though. To get maximum performance, it is often necessary to generate local caches containing references to objects
in other naming contexts. Riding herd on these external reference caches to make sure they reflect the most current information takes some doing.

Microsoft chose to avoid many of the complexities involved with naming contexts by eliminating the ability to create ad hoc
naming contexts. As an Active Directory administrator, you have only two places where you can create a naming context (see Figure 6.8):

At a domain boundary

By creating a special Application naming context (a new feature in Windows Server 2003)

The Application naming context has only limited utility (it is currently used only to support DNS), so the only real option to break apart a big DIT is to create separate domains. In addition to the Domain naming context,
each Active Directory implementation contains two other naming contexts: Configuration and Schema. Every domain controller
in the forest gets a replica of these two naming contexts. The Schema replica is read-only except for the domain controller
selected as the Schema Operations Master.

Schema Naming Contexts

The Schema naming context holds ClassSchema and AttributeSchema objects that represent the various classes and attributes in
Active Directory. If this sounds like a circular definition, it's meant to be. Unlike some directory services that load the
schema in a separate file, the Active Directory schema is completely self-referential.

Every domain controller in a forest hosts a read-only copy of the Schema naming context. Only one domain controller, the Schema
Role Master, can make changes to the schema.

The Schema container object is an instance of the Directory Management Domain (DMD) class. This is a holdover from Exchange,
which uses X.500 terminology to define the information store. Because the Schema object represents a naming context boundary,
it also contains replication control attributes similar to those in the Configuration object and the Domain-DNS object.

If you search through the objects in the Schema container, you'll come across a special object called Aggregate. This lone
instance of the LDAP SubSchema class has attributes called AttributeTypes and ObjectClasses that lists the names of all classes and attributes
in Active Directory. LDAP clients query for the contents of this object to discover the structure of the directory. This helps them formulate queries.

Application Naming Contexts

A new feature in Windows Server 2003 is the ability to create additional naming contexts that can be placed on specific domain
controllers. Microsoft uses this feature to store DNS resource records for Active Directory Integrated zones.

You elect to Active Directory Integrate a zone using the Properties of the zone in the DNS console. The General tab displays the zone type. Click Change to open the Change Zone Type window that lists your options. Figure 6.9 offers an example.

If you elect to integrate a zone into Active Directory, the resource records are copied from the existing text-based zone
file into Active Directory as discrete DNSzone objects. In Windows 2000, these objects are stored in a MicrosoftDNS container in cn=System,dc=<domain>,dc=<root>. This gave limited flexibility to administrators who wanted to deploy Active Directory Integrated DNS in large, multidomain forests.

DomainDNSZones.
A replica of this naming context is placed on domain controllers running the DNS service. Each domain gets a separate DomainDNSZones NC.

ForestDNSZones.
A replica of this naming context is placed on domain controllers running DNS throughout the forest.

When you elect to Active Directory Integrate a zone, a new entry called Replication is added to the General tab in the zone Properties window. Click the Change button next to this entry to open the Change Zone Replication Scope window (see Figure 6.10).

All DNS servers in the forest.
If you select this option, the zone records are placed in the ForestDNSZones naming context. This is the broadest scope and
involves the most replication traffic.

All DNS servers in the domain.
This option places the resource records in the DomainDNSZones naming context for the domain of the DNS server. For instance, if you create stub zone on a DNS server in Company.com that points at Branch.Company.com, the records in the stub zone would be placed in cn=DomainDNSZones,dc=Company,dc=com.

All domain controllers in the domain.
This option places the zone records in the Domain naming context under cn=MicrosoftDNS,cn=System,dc=<domain>,dc=<root>. This is the same container used by Windows 2000, so select this option when you have Windows 2000 DNS server hosting Active Directory Integrated zones.

All domain controllers specified in the scope of the application directory partition.
This option permits you to select a specific application naming context.

If you have a single domain, there is nothing to be gained by using the separate naming context to store DNS records. Select the All domain controllers in the domain option.

If you have a multidomain forest, use the All DNS servers in the domain option when you want to limit the scope of replication to a particular domain. This is typical for most domain-based zones.

All domain controllers in a forest need SRV and CNAME records from the zone representing the forest root domain. Under normal circumstances, DNS servers in the other domains would obtain these records recursively from the DNS servers in the root domain. You can speed this process up a little by setting the replication scope of the root domain to
All DNS servers in the forest.

If this seems like too many records to replicate globally, you can create a new zone just for the resource records that require
forest-wide scope. These records are stored in the forest root zone under _msdcs. For example, if the forest root domain were Company.com, you could create a new zone called _msdcs.company.com. The records would be extracted from the company.com zone and placed in this new zone. Set the replication scope for the _msdcs.company.com zone to All DNS servers in the forest.

Configuration Naming Context

The Configuration naming context holds information about parameters that control the services that support Active Directory.
Every domain controller in a forest hosts a read/write copy of the Configuration naming context. It holds eight top-level
containers. Here is a brief description of their purpose and content.

Display Specifiers

This container holds objects that alter the viewable attributes for other object classes. This is called shadowing. For example, the User-Display object shadows the User class. Display Specifiers provide localization and context menu functions.

Localization is the task of producing foreign language versions of an application. Rather than translate the contents of each
attribute for each AD object into French, Italian, German, Spanish, Cyrillic, Kanji, Szechwan, Arabic, Korean, Hebrew, Thai, and so on, the system
looks to see which country code was used during installation and filters the output through the appropriate Display Specifier.

Display Specifiers also define separate context menus, property pages, and icons based on whether or not the user accessing
the object has administrator privileges. For example, when you right-click an object, the flyout menu that appears comes from
a context menu associated with that object class. The Display Specifier filters the menu to display only those items you are
permitted to perform.

Sorting Through Display Specifiers

When you view the contents of the DisplaySpecifiers container in Active Directory, you'll see a container with a number. This
is the code page for the National Language Group in hex. The United States English code page is number 1033, which corresponds to 409 hex. The code pages for FIGS countries
are French, 1036; Italian, 1040; German, 1031; and Spanish, 1034.

Extended Rights

Directory objects are also Windows security objects. This makes it possible to assign permissions to the object itself as well as any
of the properties associated with the object. A User object can have many properties. Selecting precisely which properties
to assign access rights to get a particular result can get tedious.

Extended Rights control access to objects by consolidating sets of property permissions into a single entity. For example,
an extended right called Membership grants the ability to modify the membership of a single group, selected groups, every
group in a container, or every group in a container and its subordinate containers.

Like the Display Specifiers mentioned previously, each Extended Rights object is associated with a structural object that
it controls. For example, the Personal-Information and Public-Information objects are associated with both User and Contact classes.

Lost and Found Config

This container holds objects that get orphaned during database replication. For instance, if a container is deleted during the
same replication cycle that an object was created in the container, the object is sent to Lost and Found. Both the Domain
and Configuration naming contexts have a Lost and Found container. The Schema naming context does not need one because Schema
objects can never be deleted. See Chapter 7, “Managing Active Directory Replication,” for more information.

Partitions

This container holds the cross-reference objects that list other domains in the forest. Domain controllers use the contents of
this container to build referrals to other domains.

The Partitions container is extremely important for maintaining the integrity of a forest. It would be very bad to have objects
representing invalid naming contexts in this container. For this reason, only one domain controller in a forest is permitted
to update the contents of this container.

Physical Locations

This container holds Physical Location DN objects associated with Directory Enabled Networking (DEN). For example, a DEN-aware
router can place a locator object in this container. Because DEN makes use of standard LDAP functionality, this is the only object class in Active Directory that uses the Location attribute.

The DEN initiative has developed a set of policies for controlling network parameters affecting Quality of Service (QoS),
IP Security (IPSec), and other core networking functions. All leading routing and infrastructure vendors have pledged support
for DEN, and many have allied themselves with both Microsoft and Novell for the Directory part of DEN. Visit the web site
of your favorite vendor to see its DEN-aware products and find out its plans for Active Directory integration.

Services

This container is exposed in the AD Sites and Services console by selecting VIEW | SHOW SERVICES option from the menu. Think of the contents of the Services container as a kind of enterprise-wide Registry. Distributed
applications put objects into this container where they can be seen by other servers running the same application.

A disadvantage to this container is that it is replicated to every domain controller in the forest. You may have applications
that only need their objects to be seen at selected domain controllers. For this reason, Microsoft included the ability to
create a separate Application naming context that can be placed on individual domain controllers of your choice.

Sites

The Sites container is also exposed in the AD Sites and Services console. The objects in this container control Active Directory replication and other site-specific functions.
Sites are used to control replication between domain controllers.

Well-Known Security Principals

The object-based security used by classic NT and Windows Server 2003 assigns a unique Security Identifier (SID) to every security
principal. There is a set of well-known SIDs that represents special-purpose groups. This includes groups like Interactive,
which designates users who are logged on at the console of a machine; Network, which designates users who have logged on to
the domain; and Everyone, which designates every user. This container holds the names and SIDs of these groups.

Active Directory Trees and Forests

Recall that domains represent security boundaries for users as well as management boundaries for administrators. Users in one domain
cannot access resources in another domain unless some provision is made to support a secure connection. If you have separate
domains, you need a way to connect them into a single security structure. Classic NT uses Master domains and Resource domains
for this purpose. Active Directory uses trees and forests.

Trees

Active Directory uses DNS domains to define its namespace. As we've seen, a standard LDAP hierarchy conforms to a contiguous namespace called a Directory Information Tree. An Active Directory namespace that follows
a contiguous namespace is also called a tree (see Figure 6.11).

Figure 6.11 shows the way an Active Directory tree coincides with a standard DNS namespace. In this diagram, a root domain called Company.com has two child domains, one for the US and one for Canada. The Canada domain has a child domain of its own for Quebec. The Quebec domain has Organizational Units (OUs) that divide objects depending on language. The US domain has OUs that divide objects depending on geography. Both represent acceptable uses of OU containers.

From an LDAP perspective, this tree structure looks pretty standard. If a client in the Quebec domain queries LDAP for information about a server in the US domain, the client will get a chain of referrals that walks the tree up to root and then down to a domain controller in the
US domain.

Recall that each of these domains represents the contents of a naming context. The naming context for a domain is hosted on
a domain controller in that domain. When a query walks the tree, it moves from one domain controller to another. If the domain
controllers are in different locations in a WAN, the transaction may take a while to complete.

Forests

Not every organization is fortunate enough to have a clean tree structure. Many companies have business units that are virtually
autonomous fiefdoms with their own DNS root domains and independent administrative staffs and even separate lunchrooms. Many universities, too, have colleges with
separate IT staffs and campuses that maintain their own infrastructures.

To accommodate these and other untree-like business structures, Microsoft tweaked the LDAP standard just a bit to develop a second structure called a forest. See Figure 6.12 for an example.

Domains in an Active Directory forest do not need to follow a contiguous namespace. A secure connection between the root domains
forms a conduit that permits access by users in one domain to resources in the other domains.

Global Catalog

In a standard LDAP search involving multiple naming contexts hosted by multiple servers, the servers pass referrals to the client, and the clients
walk the tree to get information from the various servers. This process of query and referral consumes time and bandwidth.
And if one of those domain controllers is at the wrong end of a 56K line oversubscribed with users downloading MP3s, the search
might take a while.

Active Directory speeds up searches and reduces WAN traffic by aggregating the contents of the various Domain naming contexts into a structure called a Global Catalog, or GC.

Global Catalog Structure

Because the GC contains a copy of every Domain naming context in a forest, it holds a copy of every object. In a big organization,
this could make the database very large. It would not make sense to use separate domains to get separate naming contexts only
to roll them up again into a GC that must be available at each location.

To reduce GC size and replication traffic, only a small number of commonly used attributes are stored in it. The list of attributes
included in the GC is determined by the Partial Attribute Set, or PAS. The PAS contains only 200 or so out of the 1700 attributes in the Active Directory schema. Further, the partial naming
contexts hosted by a GC server are read-only, so the GC server need only concern itself with replicating updates from a domain
controller hosting a full copy of the naming context.

The Global Catalog is not a separate entity. A domain controller does not have a separate DIT file for a GC. Rather, the GC
is really just a name for a domain controller function. The function is controlled by a flag in Active Directory. With the
flag set to FALSE, a domain controller hosts only the standard three naming contexts—its own Domain NC, the Configuration
NC, and the Schema NC. With the flag set to TRUE, the domain controller adds a partial replica for the other naming contexts
in the forest. These naming contexts are stored in Ntds.dit right along with the three standard naming contexts.

Global Catalog Function

A Global Catalog server differentiates itself from a standard domain controller by listening for LDAP queries on a second port. The standard LDAP wire protocol uses TCP/UDP port 389. Global Catalog servers listen on this port but they also listen and respond on TCP/UDP port 3268. Here are the three possibilities for handling a search submitted to a GC on port 3268:

If the GC server receives a search request involving an attribute or attributes in the Partial Attribute Set (PAS), it responds
to the request with a dataset containing the requested objects and attributes.

If the GC server receives a search request involving an attribute or attributes that are not in the PAS but the objects are
in its own domain, it responds to the request with a dataset containing the requested objects and attributes. It obtains this
information from the full copy of its Domain naming context.

If the GC server receives a search request involving an attribute or attributes that are not in the PAS and for objects in
another domain, it responds to the request with a referral to the other domain. The LDAP client follows up on the referral and completes the search by walking the tree.

Global Catalog servers play a crucial role in the operation of Active Directory in an enterprise. If you have a multidomain
forest, it is very important that all users be able to reach a GC server. In the next few chapters, we'll come back to the
operation of the GC and the role it plays in authentication and access control.

Global Catalogs and Naming Context Locations

Just as a recap, take a look at the forest in Figure 6.12. The forest contains six different domains. Let's say that a domain controller in the Canada domain is configured to be both a Global Catalog server and a DNS server for an Active Directory Integrated DNS zone. This server would host the following naming contexts:

A full, read/write copy of dc=Canada,dc=Company,dc=com

A full, read/write copy of cn=Configuration,dc=Company,dc=com

A full, read-only copy of cn=Schema,cn=Configuration,dc=Company,dc=com

A full, read/write copy of cn=ForestDNSZones,dc=Company,dc=com

A full, read/write copy of cn=DomainDNSZones,dc=Canada,dc=Company,dc=com

A partial, read-only copy of the remaining domain naming contexts

Active Directory Trust Relationships

Creating trees and forests requires a way to pipe secure transactions between the various domains. Like classic NT, this pipe is called
a trust relationship.

Classic NT trusts have always reminded me of the Dr. Seuss story The Zax. In this story, a North-going Zax meets a South-going Zax in the prairies of Prax. They stand nose to nose, unwilling to
move out of each other's way. One Zax says, “I'm a North-Going Zax and I always go north. Get out of my way, now, and let
me go forth!” To which the other Zax replies, “You're in MY way! And I ask you to move, and let me go south in my south-going
groove.”

A classic one-way NT trust behaves exactly the same way. The rights implicit in the trust only flow in one direction and cannot
flow from one domain to another. A big NT system based on interlocking trusts between many different resource and master domains
can begin to look a little like a Dr. Seuss drawing, as well.

Transitive Kerberos Trusts

The picture gets a little neater with Active Directory. When two Active Directory domains trust each other, users and groups
and computers from one domain can seamlessly access resources in the other domain. The trust flows both ways.

In addition, Active Directory trusts are transitive, meaning that they flow from one domain to another if domains are chained
together. For example, if five Active Directory domains trust each other, users from one domain can access resources in any
of the other four domains, assuming that they have been granted access permissions.

The magic that makes this work comes from the Kerberos authentication mechanism that underlies the trust relationships. See
Chapter 12, “Managing Group Policies,” for more information about how Kerberos works and how it supports transitive trusts.

Trust Types

Active Directory domains have several ways they can trust each other, or trust downlevel NT domains, depending on the structure
you want to build. There are six types of trust relationships, illustrated in Figure 6.13:

Parent/Child trusts.
This style of trust exists between two Active Directory domains that share a contiguous DNS namespace and belong to the same forest.

Tree Root trusts.
This style of trust exists between root domains in the same forest that do not share a common DNS namespace.

Shortcut trusts.
This style of trust exists between two domains in different trees within the same forest. It is used to expedite Kerberos transactions
between the domains. With a shortcut trust in place, a client can obtain a Kerberos ticket directly from the trusted domain
without walking the tree.

External trusts.
This style of trust exists between an Active Directory domain and a downlevel NT4 domain. You can also create an external trust to a Samba domain. An External trust resembles
a classic NT trust. It is one-way and non-transitive, meaning it cannot link an entire forest to a downlevel domain. LDAP searches and Kerberos authentications do not cross the trust boundary.

Kerberos realm trusts.
This style of trust exists between an Active Directory domain and an MIT v5 Kerberos realm. (MIT stands for Massachusetts Institute of Technology, where Kerberos
originated.) The trust can be made transitive and two-way.

Forest trusts.
This style of trust exists between two Active Directory forests. It can be made transitive and two-way. The forests do not share a common Schema or Configuration naming context. This trust type forms a federation of forests. It is used to join two organizations that have existing Active Directory deployments and do not want to migrate
accounts into a single forest. This trust type is a new feature in Windows Server 2003 and requires all domains in the forests
and the forests themselves to be running at full Windows Server 2003 functionality (no legacy domain controllers.) You must
be a member of the Incoming Forest Trust Builders group to create a Forest trust.

The new Forest Trust type should not be considered a panacea for organizational restructurings. Because the two forests do
not share a common Configuration or Schema naming context, they cannot share applications that require a common configuration.
A principal example is Exchange 2000, which places critical information into the Configuration naming context. A federation
of forests cannot be placed into a single Exchange organization, so users cannot see a common Global Address List (GAL) or
use common distribution lists.

Establishing Parent/Child and Tree Root Trusts

Parent/Child trusts and Tree Root trusts can only be formed when a domain is created. There are no tools for consolidating domains (grafting)
or prying them apart (pruning) after the forest is in place. Every domain controller in a forest hosts an identical copy of
the Schema naming context. There are no tools to coordinate and consolidate two sets of schemas.

I'm going to repeat this point in a different way because it's important to remember. New domains can only be added to a forest
when the first domain controller is promoted in that domain. After you create a forest, the constituent domains cannot be
removed without demoting every domain controller in the domain, essentially losing all Active Directory information for that
domain.

External and Realm trusts do not rely on the Schema or Configuration naming contexts, so they can be created and broken while
leaving the end-point domains intact. If you break the trust, users in the trusted domain lose access to resources in the
other domains. If you make the trust again, the users regain access.

Establishing Forest Trusts

Forest trusts are a bit more complex to configure than the standard Windows 2000 trust types. Although the trust itself is
two-way and transitive, you can select the domains in each forest that participate in the trust. For example, consider the
diagram in Figure 6.14. This diagram shows two forests in a federation connected by a Forest trust. Each forest has domains connected by Parent/Child
trusts.

In a fully transitive configuration, users in the US.Company.com and Canada.Company.com domains would be able to access resources in the PacRim.Subsidiary.com and Europe.Subsidiary.com domains and vice-versa. However, you may not want to enable fully transitive resource access. Using the Properties window
for the trust, you can select which domains will participate in the Forest trust and in which direction the trust will be
effective.

Using this feature, you can target trusts in the federation. For example, you can configure the Forest trust so that users
in PacRim.Subsidiary.com can access resources in US.Company.com but not in Canada.Company.com.

You must be a member of the Incoming Forest Trust Builders group to create a Forest trust to another domain. This new Builtin
group permits a root domain administrator to grant permissions for an administrator in another root domain to create a trust
without giving that administrator full domain administrative privileges.

Object Migration Between Domains and Forests

You cannot build or break Parent/Child and Tree Root trusts after they are formed, so the only way to change your forest structure
is to migrate objects between domains. Microsoft provides a utility for performing these object migrations called the Active Directory Migration Tool, or ADMT.

Moving user, computer, and group accounts between domains involves issues of security and accessibility. Both classic NT and
modern Windows servers use Security IDs (SIDs) to identify users. These SIDs are placed on access control lists (ACLs) to
control access to resources. ADMT performs a complex set of functions designed to preserve the original SIDs so that users retain access to their resources.
The new version in Windows Server 2003 also preserves passwords and the original user profiles. There are a variety of third-party
tools that can help with object migration between domains and forests. See Chapter 9, “Deploying Windows Server 2003 Domains,” for details.

Sysvol

There's more to being a domain controller than simply hosting the Active Directory database. The domain controller is also
responsible for distributing the files associated with group policies. Group policies are used to centrally manage member
servers, desktops, and users. They are covered in detail in Chapter 12, “Managing Group Policies.”

Active Directory domain controllers must also support downlevel clients by providing a place to obtain classic scripts and
system policies contained in Config.pol or Ntconfig.pol files. In an NT domain, these files are stored in the Netlogon share,
physically located at C:\Winnt\System32\Repl\Import\Scripts.

Sysvol Files

To meet its dual responsibilities of supporting modern group policies and classic system policies and scripts, Active Directory
domain controllers host a special folder called Sysvol. The location of the folder is determined during Dcpromo. Sysvol must
be on an NTFS volume because folders within Sysvol use reparse points, which are only supported by NTFS.

Sysvol contains a folder with the name Domain that holds the group policy files in a folder called Policies and classic scripts in a folder called Scripts. The Scripts folder is shared as Netlogon to support downlevel clients. Modern scripts that are distributed as part of group policies
are stored as part of a particular group policy under the Policies folder.

Clients access Sysvol via a special fault tolerant share with the Universal Naming Convention (UNC) path of \\<domain_name>\Sysvol. For example, you can do a directory of \\company.com\Sysvol from any client in the Company.com domain. Accessing fault tolerant shares requires that the Dfsclient service be running on the client.

File Replication and Sysvol

The contents of Sysvol are replicated to every domain controller in a domain. It is important that the contents stay in sync.
Otherwise, users will get different group policies, system policies, and classic scripts when they log on to different domain
controllers.

A service called the File Replication Service, or FRS, is responsible for synchronizing the contents of Sysvol between domain controllers. (The actual service name is
Ntfrs, which you may see in Event log entries.) FRS replicates an entire file when any changes are made to the file. To prevent
race conditions that could occur if the file were locked, the file is first copied to a Staging folder then replicated to the other domain controllers.

Locating Active Directory Services

Active Directory clients use DNS to locate domain controllers. They do this by querying for Service Locator (SRV) records that point at LDAP, Kerberos, and Global Catalog ports on the servers. Refer to RFC 2052, “A DNS RR for Specifying the Location of Services.” (RR stands for Resource Record.)

SRV Records for Active Directory

Figure 6.15 shows a DNS zone table for the Company.com domain. The zone table contains the SRV records registered by the first domain controller in a Windows Server 2003 domain.

Format of SRV Record Names

The leading underscores in SRV record names are there to avoid collision with other records by the same name. The naming format
is specified in RFC 2052, “SRV Record Format and Use.”

Windows DNS reverses the SRV record names to display them as a hierarchy of folders. Here are the functions of the SRV records based
on their groupings in the DNS console:

_MSDCS.
This heading collects SRV records based on their status as domain controllers, domain invocations, global catalog servers, and primary domain controllers.
Domain controllers and global catalog servers are broken down by site. This tells Active Directory clients very quickly where
to find local services. Domain invocations support replication. Each domain controller gets a GUID that it uses when invoking replication. The PDC entry contains the SRV record for the domain controller assigned to be the
PDC Emulator, a domain controller that acts as the PDC to downlevel NT BDCs.

_SITES.
A site represents an area of high-speed connectivity associated with one or more distinct IP subnets. By indexing domain controllers based on their site affiliation, clients can look in _SITES to find local services rather than sending their LDAP lookups across the WAN. Standard LDAP queries use port 389. Global Catalog queries use port 3268.

_TCP.
This heading collects all domain controllers in the DNS zone. The _TCP grouping acts as a catchall for clients that cannot find their specific site or that need to find a domain controller elsewhere
in the network if none of those with local SRV records respond.

_UDP.
Kerberos v5 permits clients to use connectionless services to get tickets and change passwords. This is done via UDP ports
that correspond to the TCP ports for the same services, UDP port 88 for ticketing and UDP 464 for password changes.

Operational Description of SRV Record Queries

When a user initiates a process that requires an Active Directory lookup, the AD client process sends a query to DNS for SRV records corresponding to server advertising LDAP ports. The first query is for SRV records in the client's local site. This ensures that LDAP searches do not go to domain controllers elsewhere in the WAN. If there are no domain controllers in the client's site, it asks for all SRV records regardless of site.

Registry Tip: Site Name Cache

Clients cache their site information in the following Registry location:

DNS returns all SRV records that meet the query conditions. If there are five domain controllers in a site, DNS returns five SRV records accompanied by the Host record containing the IP address of the server in each SRV record. This is different than standard DNS operation, where it would normally return a single record in a round-robin selection process.

When the client receives the SRV records, it performs a quick LDAP ping to all of them by sending out a bind query to UDP port 389. The first domain controller to respond is selected as the
primary LDAP server by the client. Here are details of the transaction:

When the operating system loads, the network client locates a domain controller by querying DNS for SRV records. The client in the diagram sends a query for _kerberos._tcp.Phoenix._sites.dc._msdcs.Company.com. Notice that the scope of this query is limited to domain controllers from the same site and domain. The client stores the
site name in the Registry under HKLM | System | CurrentControlSet | Services | Netlogon | Parameters | DynamicSiteName.

When the DNS server receives this query, it returns all SRV records that meet the query criteria, sorting them by priority and weight.

When the network client receives the SRV records, it fires off an LDAP ping (a single UDP packet) over port 389 to every domain controller on the list. It sends these pings in rapid succession,
every one-tenth of a second.

When a domain controller gets the LDAP ping, it returns an LDAP response. The client designates the first domain controller to respond as the logon server and proceeds to authenticate via
Kerberos.

At this point, the client behaves like a lonely kid who has finally found a friend. It hounds the domain controller with all
subsequent LDAP requests, Kerberos authentication requests, and group policy downloads.

You can determine the identity of the domain controller that authenticated a member Windows Server 2003 using the SYSTEMINFO
utility. Here is a partial listing showing the logon server information:

If the client is in a forest, the domain controllers generate referrals to other domains. Clients use SRV records for those
domains to locate domain controllers that host copies of the target Domain naming contexts.

Site Coverage

You cannot configure a preferred domain controller for a client. If you have a large LAN and you want to compartmentalize
your clients based on their area of a campus LAN or MAN (metropolitan area network), you must structure your replication topology
around multiple sites. This is true even if your WAN interties meet the requirements for a high-speed connection that would not normally require separate sites.

Domain controllers automatically register their SRV records using their site name. They also return referrals to clients to
ensure that clients use a local domain controller for authentication and LDAP queries. This “localization” feature is possible because each site is associated with one or more IP networks connected by Site Links. A domain controller can read the IP address of a client and determine the site it should designate when making DNS requests for SRV records.

Here's how this works. Let's say that the client is a laptop. The user shuts down the laptop, flies to Houston, and connects
to the network again:

The client gets a local address from Dynamic Host Configuration Protocol (DHCP). It remembers that it is in the Phoenix site and queries DNS for domain controllers in that site.

DNS returns the requested SRV records and the client sends LDAP pings to the domain controllers in Phoenix.

A domain controller in Phoenix examines the client's IP address and sees that the client is in the Houston site. It knows this by comparing the IP address to the IP Subnet objects in Active Directory.

The domain controller responds with a referral telling the client to query DNS for the Houston site.

The client responds by repeating the DNS query for SRV records from the Houston site. In this way, the client automatically adjusts to changes in location.

Clients cache their site information in the following Registry location:

This site localization feature herds clients toward local domain controllers for authentication and LDAP queries. If you have a location that does not have a domain controller, you should still create a site for the location.
This populates DNS with SRV records for the next site upstream so that clients authenticate at the closest domain controllers.

Compatibility Settings

For backward compatibility, certain Active Directory features are disabled while domain controllers running something other than
Windows Server 2003 are in operation.

In Mixed, certain advanced features in Active Directory are disabled because they are incompatible with classic NT4. Here
is a list:

Universal groups.
This group type can have members from any domain in a forest and can be placed on access control lists anywhere in a forest.

Global group nesting.
In Native, Global groups from different domains can be nested together and nested into Universal groups.

Local access to Domain Local groups.
In Native, Domain Local groups from Active Directory can be placed on access control lists on member servers and desktops.

Downlevel clients can participate in transitive authentication.
After a domain is running in Native, the domain controllers can proxy NTLM authentication requests from downlevel clients
to give them access to domains that they would not be able to access in a standard NT master/resource domain structure.

After you have upgraded or decommissioned all NT4 BDCs, you can get these advanced features by shifting the domain to Windows 2000 Native. This stops replication from the PDC Emulator to any remaining NT4 BDCs. After a domain has been shifted to Windows 2000 Native,
it cannot be shifted back to Windows 2000 Mixed.

Functional Levels

Several new Windows Server 2003 features are incompatible with Windows 2000. Here is a quick list:

The calculations for determining replication topology between sites have been streamlined. This corrects a problem where large
organizations with hundreds of sites might experience replication failure because the topology calculations could not be completed
in the time allotted to them.

Group members are now replicated as discrete entities instead of replicating the entire group membership list as a single
unit. This corrects a problem where membership changes made to the same group on different domain controllers in the same
replication interval would overwrite each other.

A new trust type has been added to simplify transitive trust relationships between domains that are not in the same forest.

Support has been added for the inetOrgPerson object class, which is used on other commercial LDAP directory services to represent users. inetOrgPerson objects can be given a SID and used as security principals for logon
and put on access control lists.

Domain controllers can be renamed in a Windows Server 2003 domain. Domains themselves can be renamed in a Windows Server 2003
forest. This permits restructuring a forest by changing parent/child relationships between domains.

Schema objects can be declared defunct so that the parameters can be reused in another Schema object. A Schema object cannot
be deleted nor can the Common Name (CN) be changed.

Changes made to elements of the Global Catalog, such as adding an attribute to the GC or taking one away, do not now require
a full rebuild and replication of the GC.

As long as Windows Server 2003 domain controllers coexist with Windows 2000 Domain Controllers, these features are disabled.
When all Windows 2000 Domain Controllers have been upgraded to Windows Server 2003 or demoted to standard servers, the domains
and the forest can be shifted to full Windows Server 2003 functionality. This is a one-time operation and cannot be reversed.
See Chapter 9, “Deploying Windows Server 2003 Domains,” for the prerequisites and steps to change functional levels.

Client Compatibility

Windows Server 2003 Active Directory domains are compatible with any and all Windows clients as well as the Microsoft DOS client and the most current
versions of Samba.

The opposite is also true. Windows Server 2003 and XP can operate in any Windows domain environment: classic workgroups, classic
NT, Windows 2000 Active Directory, and of course, Windows Server 2003 Active Directory. (The sole exception is XP Home Edition,
which cannot join a domain of any form.)

One subtle problem that arose in Windows 2000 was fixed in Windows Server 2003 and in Windows 2000 SP2. When Kerberos-based
Windows clients operate in downlevel domains, they happily use NTLM Challenge-Response for their authentication. This means
they can log on to classic backup domain controllers (BDCs) and participate in pass-through authentication.

Piling On

When the domain is upgraded to Active Directory, however, a Kerberos-based client changes a flag in its security database
to disable NTLM Challenge-Response and use only Kerberos. This means that if you have deployed a few thousand Windows 2000
or XP desktops in your NT domain, as soon as you upgrade the PDC, all those desktops will scurry to that one machine to authenticate.
Microsoft calls this behavior “piling on.”

In addition, after a client has authenticated with an Active Directory domain controller, it behaves like a teenager who has
finally gotten up the gumption and money to move out of the house. It sets a flag in its local security database and thereafter
will only authenticate with Active Directory domain controllers. If only classic BDCs are available, the client logs users
on using cached credentials rather than deign to use a classic BDC. This can cause operational difficulties if you have large
numbers of desktops and member servers that have already been upgraded to Windows 2000 or XP or Windows Server 2003 when you
do the upgrade of the PDC. If the clients are in Guam and your PDC is in Galveston, the morning logons in Guam are going to
be exceedingly slow.

To avoid this problem, Windows Server 2003 includes a feature that keeps an Active Directory domain controller pretending
that it is still a downlevel domain controller to its clients. After you have installed enough Windows Server 2003 Domain
Controllers to handle the logon requests, you can pull up the curtain and turn on the footlights and let the clients switch
to Kerberos authentication.

The feature consists of a Registry entry that makes a newly promoted Windows Server 2003 domain controller pretend to be classic
NT4 domain controller. Here is the entry:

It is important that you put this entry in place on all NT domain controllers before you upgrade them. The domain controller will still register its SRV records, but when the modern Windows clients go to authenticate,
the domain controller will only respond with an NTLM authentication sequence.

Special NT4 Emulator Considerations

During the time that you have the NT4Emulator switch in place, your XP and Windows 2000 desktops will continue to use NTLMv2 authentication rather than Kerberos. This
imposes the following limitations:

Clients do not download or implement group policies.

You cannot use Active Directory management tools such as AD Users and Computers or AD Sites and Services from the client because it has not authenticated using Kerberos and therefore cannot gain LDAP access to Active Directory.

You cannot promote a member server to a domain controller because it cannot make LDAP connection to an existing domain controller.

If the NT4Emulator switch is set on domain controllers in the root domain of the forest, you cannot create a new domain in the forest because
the new domain controller cannot make LDAP connection to an existing domain controller in the root domain.

You can avoid these limitations on a case-by-case basis by permitting the client to ignore the NT4Emulator behavior of a domain controller and to log on using Kerberos. Do this by putting an entry into the Registry at the client:

After putting this entry in place, log off and back on again. The desktop finds the Windows Server 2003 domain controller
and uses Kerberos to authenticate. You can verify that this occurs using the Kerbtray utility from the Resource Kit.

When you have sufficient Windows Server 2003 domain controllers deployed to handle the expected volume of Kerberos authentications
and group policy deliveries, flip the NT4Emulator switch to 0 in the Registry of each domain controller and restart it. This enables the domain controller to authenticate
using Kerberos as well as NTLMv2. Be sure you flip the switch on all domain controllers to avoid confusion.

Active Directory Namespace Highlights

Here is a summary of the key points to remember about how the Active Directory namespace is structured. These points become
critical design elements when the time comes to deploy Active Directory in your organization:

The Active Directory database is divided into separate replication units called naming contexts. There are four types of naming
contexts: Domains, Configuration, Schema, and Application.

Active Directory domains form separate security and management units as well as separate naming contexts.

Every domain controller in a forest has a replica of the Configuration and Schema naming context. This ensures that the domain
controllers share the same knowledge about Active Directory topology, operation, and object management.

Separate Active Directory domains can be connected together into a common security structure. If the domains share a contiguous
DNS namespace, they form a tree. If they do not share a contiguous namespace, they form a forest.

Active Directory uses trust relationships between domains to form trees, forests, and secure connections to external domains,
forests, and MIT Kerberos realms. A trust can also be used to create a shortcut between domains in the same forest.

Trust relationships between Kerberos-based Windows domains can be made transitive and two-way. Trusts to downlevel domains
are one-way and non-transitive.

Active Directory improves the performance of deep LDAP searches (searches that include multiple domains) by aggregating a partial replica of all Domain naming contexts into a Global
Catalog. Any domain controller can host a copy of the GC.

Active Directory clients use SRV records in DNS to locate Active Directory services on domain controllers. Clients preferentially use domain controllers from their local
network to reduce WAN traffic and improve performance.