Understanding Active Directory Services

This chapter is from the book

Inside Windows Server 2003

Learn More Buy

This chapter is from the book

This chapter is from the book 

Inside Windows Server 2003

Learn More Buy

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)

Figure 6.8. Active Directory forest showing naming contexts.

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.

Figure 6.9. DNS zone properties—Change Zone Type window showing Active Directory Integration option.

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.

The application naming contexts added by Windows Server 2003 gives this additional flexibility. When you Active Directory Integrate a zone on a DNS domain controller running Windows Server 2003, the domain controller creates two additional naming contexts:

• 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).

Figure 6.10. Change Zone Replication Scope window.

This window gives you the following replication options:

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

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.

There are over 50 Extended Rights objects covering a wide assortment of management operations, such as changing passwords, changing domain configurations, resetting user lockouts, and managing BackOffice services.

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. Active Directory tree.

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.

Figure 6.12. Active Directory forest.

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.

Figure 6.13. Diagram of various Active Directory trust options in Windows Server 2003.

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.

Figure 6.14. Federation of two Active Directory forests.

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.

Figure 6.15. DNS console showing SRV records for the Company.com domain.

Here are the SRV records in a standard zone table format:

_kerberos._tcp.phoenix._sites.dc._msdcs    600     SRV     0 100 88 dc-01.company.com._
 kerberos._tcp.phoenix._sites              600     SRV     0 100 88 dc-01.company.com.
_kerberos._tcp.dc._msdcs                   600     SRV     0 100 88 dc-01.company.com.
_kerberos._tcp                             600     SRV     0 100 88 dc-01.company.com.
_kerberos._udp                             600     SRV     0 100 88 dc-01.company.com.
_kpasswd._tcp                              600     SRV     0 100 464 dc-01.company.com.
_kpasswd._udp                              600     SRV     0 100 464 dc-01.company.com.
_ldap._tcp.phoenix._sites.gc._msdcs        600     SRV     0 100 3268 dc-01.company.com.
_gc._tcp.phoenix._sites                    600     SRV     0 100 3268 dc-01.company.com.
_ldap._tcp.gc._msdcs                       600     SRV     0 100 3268 dc-01.company.com.
_gc._tcp                                   600     SRV     0 100 3268 dc-01.company.com.
_ldap._tcp.phoenix._sites.dc._msdcs        600     SRV     0 100 389 dc-01.company.com.
_ldap._tcp.phoenix._sites                  600     SRV     0 100 389 dc-01.company.com._
 ldap._tcp.dc._msdcs                       600     SRV     0 100 389 dc-01.company.com.
ldap._tcp.{guid of domain}.domains._msdcs  600     SRV     0 100 389 dc-01.company.com.
_ldap._tcp                                 600     SRV     0 100 389 dc-01.company.com.
_ldap._tcp.pdc._msdcs                      600     SRV     0 100 389 dc-01.company.com.
 dc-01                                     1200    A     10.1.1.1
 gc._msdcs                                 600     A     10.1.1.1
 {GUID of DC invocation}._msdcs              600      CNAME dc-01.company.com.

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.

Key:     HKLM | System | CurrentControlSet | Services | Netlogon 
| Parameters
      Value:   DynamicSiteName
      Data:    Flat name of the last domain controller authenticating 
      the client—
      for example, dc-01
      

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:

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

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

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

4. 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:

Virtual Memory: Max Size:  1,733 MB
Virtual Memory: Available: 1,344 MB
Virtual Memory: In Use:    389 MB
Page File Location(s):     C:\pagefile.sys
Domain:                    company.com
Logon Server:              \\DC01.company.com
   Hotfix(s):                  0 Hotfix(s) Installed
   

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:

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

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

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

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

5. 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:

Key:   HKLM | System | CurrentControlSet | Services | Netlogon | Parameters
Value: DynamicSiteName
Data:  Flat name of domain controller authenticating the client—for example,
dc1

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.

A Windows Server 2003 domain faces two compatibility challenges (at least with other Windows servers):

• Operation with downlevel NT domain controllers

• Operation with Windows 2000 domain controllers

Each of these challenges requires a different compatibility setting.

Operation with Downlevel NT Domain Controllers

Active Directory domain controllers can coexist with NT4 Domain Controllers in the same domain. This is called Windows 2000 Mixed. In Mixed, a Windows Server 2003 domain controller designated as the PDC Emulator uses classic LMRepl (LanMan Replication) to deliver selected Active Directory updates to downlevel BDCs.

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:

Key:    HKLM | System | CurrentControlSet | Services | Netlogon | Parameters
Value:  NT4Emulator
Data:   1 (REG_DWORD)

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:

Key:    HKLM | System | CurrentControlSet | Services | Netlogon | Parameters
Value:  NeutralizeNT4Emulator
Data:   1 (REG_DWORD)

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.

• Windows Server 2003 maintains backward compatibility to both classic NT4 domains and Windows 2000 domains.

• All domains in a forest and the forest itself must be shifted to Windows Server 2003 Functional Level to get access to all new Active Directory features.