Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide

Disclaimer:

This book is based on Microsoft® Windows® 2000 applications and technologies that are under development. Future versions of this book will reflect subsequent changes in Windows 2000.

© 1985-1999 Microsoft Corporation. All rights reserved.


Active Directory Logical Structure

Active Directory™, the Microsoft® Windows® 2000 directory service, stores information about network objects and also implements the services that make the information available and usable to users. Active Directory presents this information through a standardized, logical structure that facilitates the organization of domains and domain resources in a predictable and useful way by using Domain Name System (DNS) hierarchical naming and Windows 2000 trust relationships.

In This Chapter

Active Directory Domain Hierarchy

Active Directory Domain Names

Active Directory and DNS

Locating Active Directory Servers

Tree and Forest Structure

Active Directory Objects

Related Chapters in the Resource Kit

  • For more information about Active Directory architecture, search functionality, and physical storage, see “Active Directory Data Storage and Name Resolution” in this book.
  • For more information about planning the DNS namespace, domain hierarchy, and organizational unit structure, see “Designing the Active Directory Structure” in the Microsoft® Windows® 2000 Server Resource Kit Deployment Planning Guide.
  • For more information about standard DNS concepts, see “Understanding DNS” in the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.
  • For more information about using Microsoft DNS with Active Directory, see “Windows 2000 Implementation of DNS” in the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.


Active Directory Domain Hierarchy

In Windows 2000, a domain defines both an administrative boundary and a security boundary for a collection of objects that are relevant to a given group of users on a network. A domain is an administrative boundary because administrative privileges do not extend to other domains. It is a security boundary because each domain has a security policy that extends to all security accounts within the domain. Active Directory stores information about objects in one or more domains.

Domains can be organized into parent-child relationships to form a hierarchy. A parent domain is the domain directly superior in the hierarchy to one or more subordinate, or child, domains. A child domain also can be the parent of one or more child domains, and so on, as shown in Figure 2.1.

Figure 2.1 A Domain Hierarchy

This hierarchical structure is a change from the flat domain structure of Microsoft® Windows NT® version 3.51 and Microsoft® Windows NT® version 4.0. The domain hierarchy allows you to search multiple domains in one query because each level of the hierarchy has information about the levels immediately above and below it. Searches in Windows NT 4.0 and earlier require knowing both the domain and server where an object is stored; Windows 2000 provides a search capability that eliminates the need to know the location of a given resource in order to find it.

For more information about Active Directory searches, see “Active Directory Data Storage and Name Resolution” in this book.


Active Directory Domain Names

Windows 2000 uses DNS naming standards for hierarchical naming of Active Directory domains and domain computers. For this reason, domain and computer objects are part of both the DNS domain hierarchy and the Active Directory domain hierarchy. Although these domain hierarchies have identical names, they represent separate namespaces.

Note

The domain hierarchy defines a namespace. A namespace is any bounded area in which standardized names can be used to symbolically represent some type of information, such as an object in a directory or an Internet Protocol (IP) address. In each namespace, specific rules determine how names can be created and used. Some namespaces, such as the DNS namespace and the Active Directory namespace, are hierarchically structured and provide rules that allow the namespace to be partitioned. Other namespaces, such as the Network Basic Input/Output System (NetBIOS) namespace, are flat (unstructured) and cannot be partitioned.

The main function of DNS is to map user-readable computer names to computer-readable IP addresses. Thus, DNS defines a namespace for computer names that can be resolved to IP addresses, or vice versa. In Windows NT 4.0 and earlier, DNS names were not required; domains and computers used NetBIOS names, which were mapped to IP addresses by using the Windows Internet Naming System (WINS). Although DNS names are required for Windows 2000 domains and Windows 2000–based domain computers, NetBIOS names also are supported in Windows 2000 for interoperability with Windows NT 4.0 domains and with clients that are running Windows NT 4.0 or earlier, Microsoft® Windows® for Workgroups, Microsoft® Windows® 98, or Microsoft® Windows® 95.

Note

WINS and NetBIOS are not required in an environment where computers run only Windows 2000, but WINS is required for interoperability between Windows 2000–based domain controllers and computers that are running earlier versions of Windows.


DNS Naming Conventions

DNS naming standards are used within Active Directory to provide support for industry-standardized mapping of DNS domain names to the IP addresses of domain computers. In DNS, computers are referred to as hosts. When it is given a host name, the DNS name server resolves the name to an IP address so that IP routing protocols can locate the computer by its IP address. In addition, Active Directory domain controllers are identified by DNS as Lightweight Directory Access Protocol (LDAP) servers. Therefore, when given the name of a domain, a DNS name server can locate a domain controller within that domain. (See “Active Directory Data Storage and Name Resolution” in this book.)

A DNS hierarchy is enforced by the following requirements:

  • A child domain can have exactly one parent domain.
  • Two children of the same parent cannot have the same name.

Because Active Directory domains use DNS names, these two standards apply to Active Directory domains.

When you view a DNS name, a domain is any single portion of the DNS name that is separated from other parts of the DNS name by a period (.). For example, in the domain name calif.noam.reskit.com, “calif,” “noam,” and “reskit” each correspond to a domain, as illustrated in Figure 2.2. The full name represents a hierarchy in which reskit.com is the root, noam is a child of reskit.com (noam.reskit.com), and calif is a child of noam.reskit.com (calif.noam.ireskit.com). The leftmost portion of a DNS name also can be the host (computer) name.

Figure 2.2 An Active Directory Hierarchy with DNS Names

In DNS, the name that precedes a period is called a label. Reading the domain name from right to left, applications can correctly interpret the order of hierarchy for each label. And because two children of the same parent cannot have the same name, a domain name is always unique in the hierarchy. Each domain in the hierarchy defines its own portion of the overall namespace.

Note

For information about Internet Standard host names, see Request for Comments (RFC) 1123. This host naming standard is recommended, but not required, for Active Directory domain names.

For more information about DNS functionality, see “DNS Concepts” in Windows 2000 Server Help, and see “Understanding DNS” in the TCP/IP Core Networking Guide.


NetBIOS Domain Names

Windows 2000 provides support for applications that use the NetBIOS networking application programming interface (API) and the flat NetBIOS names used by these applications. This support for non-DNS domain and computer names allows computers that are running Windows NT 4.0 and earlier, or those running Windows 95 or Windows 98, to identify Windows 2000 domains. For example, in a mixed-mode environment, Windows NT 4.0–based backup domain controllers (also known as BDCs) recognize a specified Windows 2000–based domain controller as the primary domain controller (also known as a PDC). They use NetBIOS names to locate the primary domain controller, therefore, each Windows 2000–based domain controller must have a NetBIOS name that it either registers or broadcasts to allow non-Windows 2000–based computers to log on. Likewise, other server and workstation computers are recognized by NetBIOS names.

When you create a new domain during the domain controller promotion procedure, a default NetBIOS name is provided that matches the left-most label in the DNS domain name. You can change this name during the procedure, but you cannot change it thereafter. When you name a standalone server or workstation computer, the DNS name includes a NetBIOS portion as well.

For more information about the domain controller promotion procedure, see “Active Directory Data Storage and Name Resolution” in this book


Active Directory and DNS

DNS is the de facto naming system for IP-based networks and the naming service that is used to locate computers on the Internet. Windows 2000 uses DNS to locate computers and domain controllers (that is, to locate Active Directory). A workstation or member server finds a domain controller by querying DNS. For this reason, installing or upgrading to Microsoft® Windows® 2000 Server requires that a DNS infrastructure is in place or is installed simultaneously. Microsoft DNS can be installed at the time of Windows 2000 Server installation and be configured as part of the domain controller promotion procedure.

For more information about installing Microsoft DNS, see “Microsoft Implementation of DNS” in the TCP/IP Core Networking Guide.


DNS Hierarchy vs. Active Directory

Every Windows 2000 domain has a DNS name (for example, reskit.com), and every Windows 2000–based computer has a DNS name (for example, win2kserver.reskit.com). Thus, domains and computers are represented both as objects in Active Directory and as nodes in DNS.

Because DNS domains and Active Directory domains share identical domain names, it is easy to confuse their roles. The difference is that the two namespaces, although sharing an identical domain structure, store different data and, therefore, manage different objects: DNS stores zones (zone records), and Active Directory stores domains (domain objects). Both systems employ a database to resolve names.

  • DNS resolves domain names and host names to IP addresses through requests received by DNS name servers as DNS queries to the DNS zone database.
  • Active Directory resolves domain object names to the object’s record through requests received by domain controllers as LDAP search or modify requests to the Active Directory database.

Thus, the Active Directory domain computer account object is in a different namespace than the DNS host record that represents the same computer in the DNS zone.

For more information about using Microsoft DNS, see “Microsoft Implementation of DNS” in the TCP/IP Core Networking Guide.


DNS and the Internet

The Internet is a Transmission Control Protocol/Internet Protocol (TCP/IP) network. Every computer on the Internet or on any other TCP/IP network has an IP address. DNS locates TCP/IP hosts by resolving the host computer names that end users understand to the IP addresses that computers understand. For example, the host name DC1.reskit.com is resolved to the IP address 172.16.44.1. The addresses on the Internet are managed by using the globally distributed DNS database of host information, but DNS can also be implemented locally to manage addresses within private TCP/IP networks. To create a presence on the Internet, an organization can register its domain name with an Internet DNS registration agency and, thereby, other computers on the Internet can locate its servers, and vice versa.

With DNS as the organizational structure, the entire Internet is one global namespace that has a series of top-level domains that are further subdivided into second-level domains. The root of the Internet domain namespace is managed by an Internet authority that is responsible for delegating administrative responsibility for the top-level domains of the DNS namespace and for registering second-level domain names. The top-level domains are the basic domain categories, such as commercial (.com), educational (.edu), governmental (.gov), and so forth. Second-level domains represent namespaces that are formally registered to individuals and to institutions and, thus, provide an Internet presence for these individuals and institutions. Their presence is supported by pointers in the relevant top-level domains to DNS servers in an individual’s or organization’s root domain (for example, name servers in the .com DNS database contain pointers to DNS name servers in the root domain of the private domain (reskit.com). These DNS pointers enable other domains to use the Internet to find the reskit.com domain. Similarly, DNS servers in the root domain for an individual or organization provides pointers to all DNS servers in child domains of the root domain, and so on. DNS name servers on a private network likewise can contain pointers to Internet name servers if you want to be able to locate other domains over the Internet.

For more information about DNS and the Internet, see “Understanding DNS” in the TCP/IP Core Networking Guide.


Active Directory and the Internet

Active Directory can exist within the scope of the global Internet DNS namespace. When an Internet presence is required by an individual or organization, the Active Directory namespace is maintained as one or more hierarchical Windows 2000 domains beneath a root domain that is registered as a DNS namespace. Registration of individual and organizational root domain DNS names ensures the global uniqueness of all DNS names and provides for the assignment of network addresses that are recorded in the global DNS database. Registration of its root domain DNS name also grants the individual or organization the authority to manage its own hierarchy of child domains, zones, and hosts within its root domain.

Note

An organization may or may not choose to be part of the global Internet DNS namespace. However, even if the organization’s root domain is not registered as an Internet DNS namespace, the DNS service is required to locate Windows 2000–based computers in general and Windows 2000–based domain controllers in particular.

For more information about DNS and DNS name servers, see “DNS Concepts” in Windows 2000 Server Help and “Understanding DNS” in the TCP/IP Core Networking Guide.

The root of the DNS hierarchy is a node that has a null label (“ ”). Historically, the DNS root is characterized as “.” to indicate the top level in the DNS hierarchy. In a fully qualified domain name (FQDN), the trailing dot separates the last domain label in the name from the null label. For example, the FQDN reskit.com. appears to end with a dot, but it actually ends with the null root node. The dot separates “com” from the null label that represents the root node.

This null “.” provides the entry point from which anyone can search the entire Internet. To search the entire Internet, you have to begin at a point above all DNS nodes; the root provides that point. Similarly, the root of the Active Directory namespace (the directory root) is a null “object” that has no parent and that provides the LDAP entry point to Active Directory. The LDAP term for this root is rootDSE. RootDSE is an object in the sense that it has attributes; however, it is not an entry in Active Directory. RootDSE exists outside and immediately above Active Directory in the hierarchy. See Figure 2.3 for a comparison of DNS and Active Directory roots.

Figure 2.3 DNS and Active Directory Namespace Roots

For more information about rootDSE, see “Active Directory Data Storage and Name Resolution” in this book.


DNS Host Names and Windows 2000 Computer Names

In Windows 2000, a computer name is a human-friendly representation of the IP network address by which the computer is physically located and is the value used to identify the computer’s security account. In Windows NT 4.0 and earlier, a computer is identified primarily by a NetBIOS name—a name that is recognized by WINS, which maps the name to a static IP addresses or to an address configured dynamically by the Dynamic Host Configuration Protocol (DHCP). In earlier versions of Windows NT, if DNS was employed, the NetBIOS name was used as the DNS host name, concatenated with the Windows NT domain name. To maintain compatibility with NetBIOS names used on non-Windows 2000 – based computers, Windows 2000 incorporates the NetBIOS computer name and the DNS domain name as distinct pieces of the DNS host name, thereby accommodating both DNS and, where needed, NetBIOS.

In Windows 2000, therefore, the DNS host name has two parts:

Computer name
The left-most label in the name. This label is also used as the NetBIOS version of the computer name for compatibility with Windows NT 3.5x and Windows NT 4.0 domains and with computers that are running Windows 95 or Windows 98. The computer name identifies the computer’s account that is stored in Active Directory, and it also is the name of the Security Accounts Manager (SAM) local computer account on a workstation or member server (a computer that runs Windows NT or Windows 2000 but is not a domain controller).

Note

Because the computer name for a workstation or member server computer is stored in two places (Active Directory and SAM), a name change for either a workstation computer or a member server computer must be made in both places. Domain controller computer accounts do not have a SAM account; they are stored in Active Directory only; therefore, the name change for this computer must be made only in Active Directory.

Primary DNS domain name
By default, the Windows domain to which the computer account (also called the “machine account”) belongs. The default can be changed.

Figure 2.4 illustrates the form of a host name.

Figure 2.4 Components of a Host Name


DNS Name Servers and Zones

DNS is a distributed database of TCP/IP host information. DNS employs a client/server mechanism wherein the server portion, the name server provides domain host information to clients called resolvers. By default, Microsoft DNS server runs on every Windows 2000–based domain controller and is optimized for use with Active Directory. Client resolvers are built-in components of modern TCP/IP protocol implementations and, therefore, are readily available to communicate with DNS servers.

DNS name servers store database files, called zone files, that contain information used to locate computers and services within the DNS namespace. A zone is a partition of the DNS namespace that contains a single DNS domain and its subdomains, if any. When you configure DNS on a domain controller, you determine what this partitions are. Because Active Directory domain names have a 1:1 correspondence with DNS domains, it follows that DNS zones can include data about the computers in one or more Active Directory domains — that is, zones and domains do not have to correspond 1:1. One zone can encompass more than one domain, and these domains do not have to form a tree.

Zone data identifies each host by DNS name and IP address and specifically identifies computers as domain controllers by linking the service they run (LDAP) to a computer name and IP address. Zone files also contain site information that makes it possible to locate domain controllers in the same site as the client and to locate domain controllers that have specific roles in the domain, such as a Global Catalog server or a Kerberos v5 server. Zone data can be stored in text files or in Active Directory. When zone data is stored in Active Directory, you configure the zone as an Active Directory integrated primary zone.

For more information about deciding what DNS server to use, see “Designing the Active Directory Structure” in the Deployment Planning Guide. For more information about domain replication, see “Active Directory Replication” in this book. For more information about DNS and DNS name servers and DNS resolvers, see “Understanding DNS” and “Introduction to TCP/IP,” respectively, in the TCP/IP Core Networking Guide.


Support for Dynamic DNS Updates

Microsoft DNS Service supports dynamic update protocol, a standard protocol that allows hosts to dynamically register their names in the DNS database, which reduces administrative costs. When DNS zones are stored in Active Directory, DNS is configured by default to accept dynamic updates. The relevant specification for dynamic update is RFC 2136. (For more information about dynamic DNS updates, see “Windows 2000 Implementation of DNS” in the TCP/IP Core Networking Guide.)

Secure dynamic update is a Windows 2000 feature that provides the additional benefit of making it possible to authenticate clients who dynamically register their host names in DNS. With secure dynamic updates, the server does not perform a dynamic update on behalf of the client unless it has authenticated the client and determined that the client has sufficient permissions to perform the dynamic update. Secure dynamic update is implemented in Windows 2000 in accordance with the Generic Security Service Application Program Interface (GSS-API), as defined in RFC 2078.

When a client tries to register a DNS name, the DNS server authenticates the update message via the Kerberos v5 protocol. The (dynamic) DNS server also verifies that the user is authorized (has permission) to make the requested update and either rejects the update request or makes the change.

For more information about secure dynamic update, see “Windows 2000 Implementation of DNS” in the TCP/IP Core Networking Guide.


Active Directory-Integrated DNS

Active Directory–Integrated DNS

Active Directory–integrated DNS enables Active Directory storage and replication of DNS zone databases. Microsoft DNS, the DNS service that is included with Windows 2000 Server, accommodates storing zone data in Active Directory. When you configure a computer as a DNS name server, zones are usually stored as text files on name servers, that is, all of the zone files required by DNS are created in a text file on the server computer. These text files must be synchronized among DNS name servers by using a system that requires a separate replication topology and schedule. However, if you use Active Directory–integrated DNS when you configure a computer as a DNS name server, zone data is stored as an Active Directory object and is replicated as part of domain replication.

The standard method of synchronizing DNS data between DNS name servers is by means of a system of primary and secondary master servers that can be scheduled to copy primary zone updates from the primary master server to the servers that store the secondary zones (replicas of the primary zone) in a process called zone transfer. When you use Active Directory–integrated DNS, Active Directory domain controllers act as name servers.

Note

Only DNS servers that run on domain controllers can load Active Directory–integrated zones.

In this scenario, all name servers act as primary master servers — that is, updates can occur at any domain controller, and zone transfer occurs automatically as part of Active Directory replication.

To implement DNS integration within Active Directory, you assign a zone type of Active Directory Integrated primary when you create the zone in DNS Manager. Zone database records are created in the Microsoft DNS container within the System container (visible in the Advanced Features view in the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in), and the contents are replicated to all domain controllers in the domain.

When DNS data is stored in Active Directory, each DNS zone is an Active Directory container object (DnsZone). The DnsZone object contains a DnsNode object for every unique name within that zone. These unique names include the variations assigned to a given host computer when it functions, for example, as a primary domain controller or as a Global Catalog server. The DnsNode object has a DnsRecord multivalued attribute that contains a value for every resource record associated with an object’s name. When other non-Microsoft DNS servers are already in place and Active Directory domains represent only part of the overall DNS namespace, standard zone transfer still can be used to synchronize zone data between Active Directory and other DNS servers (that is, using Active Directory–integrated DNS does not preclude other DNS implementations). For more information about using different DNS servers, see “Designing the Active Directory Structure” in the Deployment Planning Guide.

Note

Microsoft DNS is not a requirement for using Active Directory, but the DNS server you use must support service resource records (SRV records) in accordance with RFC 2052, and it also should support the dynamic update protocol described in RFC 2136.

Administrators can selectively remove the DNS service from a domain controller after the name service has been integrated, but as long as Microsoft DNS is installed on at least one domain controller, the zone data is always replicated to every domain controller.

For more information about where to place DNS servers, see “DNS Concepts” in Windows 2000 Server Help and “Windows 2000 Implementation of DNS” in the TCP/IP Core Networking Guide. For more information about zone transfer and the location of zone data in Active Directory, see “Understanding DNS” and “Windows 2000 Implementation of DNS,” respectively, in the TCP/IP Core Networking Guide.


Locating Active Directory Servers

When an application requests access to Active Directory, an Active Directory server (domain controller) is located by a mechanism called the domain controller locator (Locator). Locator is an algorithm that runs in the context of the Netlogon service. Locator can find domain controllers by using DNS names (for IP/DNS-compatible computers) or by using NetBIOS names (for computers that are running Windows 3.x, Windows for Workgroups, Windows NT 3.5 or later, Windows 95, or Windows 98, or it can be used on a network where IP transport is not available).

Note

Hereafter, “Windows NT 4.0–compatible Locator” will be used to refer to the locator process that is used by clients that are running Windows 3.x, Windows for Workgroups, Windows NT 3.5 or later, Windows 95, or Windows 98 to locate a domain controller in any domain, as well as by clients that are running Windows 2000 to locate a domain controller in a Windows NT 3.51 or Windows NT 4.0 domain.

The client software for DNS, called the resolver, resolves a host computer name to an IP address in the DNS database. The resolver is built into the TCP/IP software that is included with Windows 2000 and Windows NT operating systems.

The process of locating a domain controller is implemented in two parts:

  • Locating the domain host.
  • Resolving the host IP address.

The DNS service responds by looking up and sending the IP address to the client.

The process of locating the domain host is covered in the following sections of this chapter. The resolution of the host IP address is described in “Understanding DNS” in the TCP/IP Core Networking Guide.


Domain Controller Name Registration

Every Windows 2000–based domain controller registers two names at startup:

  • A DNS domain name with the DNS service.
  • A NetBIOS name with WINS or another transport-specific service.

When a computer starts up and logs on to a domain, the computer must do one of two things:

  • If the requested name is a DNS name, the computer must query DNS to find a domain controller with which to authenticate.
  • If the requested name is a NetBIOS name, .the computer must send a broadcast message to find a domain controller for the specified domain.

After the computer has found a domain controller, the information is cached so that a new query is not required for subsequent logon sessions.

DNS Domain Name Registration

Active Directory supports dynamic registration of domain controller addresses in DNS. When Active Directory is installed during domain controller creation, the Netlogon service dynamically creates records in the DNS database that are used to locate the server. Dynamic DNS update (described in RFC 2136) is a recent addition to the DNS standard; it defines a protocol for updating a DNS server with new or changed values dynamically. Prior to the addition of this new standard, administrators had to create the records stored by DNS servers manually. Microsoft DNS, the DNS server that is included with Windows 2000, supports dynamic updates.

Every Windows 2000–based domain controller dynamically registers SRV records in DNS, which allow servers to be located by service type (for example, LDAP, FTP, or WWW) and protocol (for example, TCP). Because domain controllers are LDAP servers that communicate over TCP, SRV records can be used to find the IP addresses of domain controllers. In addition to registering LDAP-specific SRV records, Netlogon also registers Kerberos protocol–specific SRV records to enable locating servers that run the Kerberos v5 Key Distribution Center (KDC) service.

Every Windows 2000–based domain controller also dynamically registers a single host resource record (an A resource record), which contains the name of the domain (DnsDomainName) where the domain controller is located, and maps the record to the appropriate IP address. The A resource record makes it possible for clients that do not recognize SRV records to locate a domain controller by means of a generic host lookup.

NetBIOS Domain Name Registration

A domain controller registers its NetBIOS name (DomainName[1C]) by broadcasting or directing a NetBIOS name registration request to a NetBIOS name server, such as a WINS server. Registering the NETBIOS name makes it possible for Windows clients that are not IP/DNS-enabled to find the domain controllers that are running Windows 2000, Windows NT 3.51, or Windows NT 4.0. In this case, the client finds the domain controller by sending a Netlogon request that is based on the NetBIOS domain name.

Note

NetBIOS recognizes domain controllers by the [1C] registration.

For information about registering names with WINS, see “Windows Internet Naming Service (WINS)” in the TCP/IP Core Networking Guide.


SRV Resource Records

When a Windows 2000–based computer starts up, the Netlogon service uses dynamic DNS updates to register SRV resource record in the DNS database, as described in RFC 2052. The SRV record is used to map the name of a service, in this case the LDAP service, to the address of a server offering that service. In a Windows 2000 network, an LDAP resource record locates a domain controller.

A workstation that is logging on to a Windows 2000 domain queries DNS for SRV records in the general form:

_service._protocol.DnsDomainName

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

Note

The service and protocol strings require an underscore (_) prefix to prevent potential collisions with existing names in the namespace.

The _msdcs Subdomain

There are possible implementations of LDAP servers other than Windows 2000–based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows 2000. To facilitate locating Windows 2000–based domain controllers, in addition to the standard _service._protocol.DnsDomainName format, the Netlogon service registers SRV records that identify the well-known server-type pseudonyms “dc” (for domain controller), “gc” (for Global Catalog), “pdc” (for primary domain controller), and “domains” (for the Globally Unique Identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows 2000–specific roles in the domain or forest, as well as location by GUID in the event a domain has been renamed. To accommodate locating domain controllers by server type or by GUID (abbreviated “dctype”), Windows 2000–based domain controllers register SRV records in the form:

_service_protocol.dctype._msdcs.DnsDomainName

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP or Kerberos v5 server that is running TCP (or, in the case of a Kerberos v5 server, either TCP or the User Datagram Protocol (UDP)), and the subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows 2000 role. The name_msdcs is reserved for locating domain controllers and should not be used for any other purpose. The single keyword _msdcs was selected to avoid polluting the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were purposely kept short to avoid infringing on the maximum length of DnsDomainName.

SRV Records Registered by Netlogon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Netlogon as each record is registered. Text in bold-face type denotes constant record components; text in italic type denotes variable names.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name used during creation of the domain controller when the domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root domain.

To identify the correct DNS entries that should exist for Windows 2000 Server installation, locate and open the text file Netlogon.dns in the %SystemRoot%\System32\Config folder.

_ldap._tcp.DnsDomainName.
Allows a client to locate a server that is running LDAP in the domain named by DnsDomainName. The server is not necessarily a domain controller; that is, the only assumption that can be made about the server is that it supports the LDAP API. All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.reskit.com.).
_ldap._tcp.SiteName._sites.DnsDomainName.
Allows a client to locate a server that is running LDAP in the domain named in DnsDomainName in the site named by SiteName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers register this SRV record (for example _ldap._tcp.charlotte.sites.reskit.com.).
_ldap._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller (dc) of the domain named by DnsDomainName. All Windows 2000 Server–based domain controllers register this SRV record.
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller for the domain named by DnsDomainName and in the site named by SiteName. All Windows 2000 Server–based domain controllers register this SRV record.
_ldap._tcp.pdc._msdcs.DnsDomainName.
Allows a client to locate the server acting as the primary domain controller (PDC) in the mixed-mode domain named in DnsDomainName. Only the PDC Advertiser (the domain controller that advertises itself as the PDC Flexible Single Master Operation (operations master) role owner) of the domain registers a SRV record that contains this information.
_ldap._tcp.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest. Only domain controllers that are functioning as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.reskit.com.).
_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.charlotte._sites.gc._msdcs.reskit.com.).
_gc._tcp.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this domain. The server is not necessarily a domain controller. Only a server that is running LDAP and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.reskit.com.).

Note

In Windows 2000, a Global Catalog server is a domain controller. Other non--Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

_gc._tcp.SiteName._sites.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. The server is not necessarily a domain controller. Only a server that is running LDAP and functioning as the Global Catalog for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.charlotte._sites.reskit.com.).
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName.
Allows a client to locate a domain controller in a domain on the basis of its GUID. A GUID is a 128-bit (8 byte) number that is automatically generated for referencing objects in Active Directory — in this case, the domain object. This operation is expected to be infrequent; it occurs only if the DnsDomainName of the domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.reskit.com.). All domain controllers register this SRV record.
_kerberos._tcp.DnsDomainName.
Allows a client to locate a server that is running the Kerberos v5 KDC for the domain named in DnsDomainName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running at least an RFC 1510–compliant Kerberos KDC service register this SRV record.
_kerberos._udp.DnsDomainName.
Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.
_kerberos._tcp.SiteName._sites.DnsDomainName.
Allows a client to locate a server that is running the Kerberos v5 KDC service for the domain that is named in DnsDomainName and is also in the site named in SiteName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running at least an RFC 1510–compliant Kerberos KDC service register this SRV record.
_kerberos._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Microsoft extended Kerberos v5 KDC service for the domain named in DnsDomainName. All Windows 2000 Server–based domain controllers that are running the Microsoft extended version of the Kerberos KDC service (that is, implement a public key extension to the Kerberos protocol’s initial Authentication Service Exchange subprotocol) register this SRV record.
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Microsoft extended Kerberos v5 KDC service for the domain that is named in DnsDomainName and that is also in the site named in SiteName. All Windows 2000 Server–based domain controllers that are running the Microsoft extended version of the Kerberos KDC service (that is, implement a public key extension to the Kerberos protocol’s initial Authentication Service Exchange subprotocol) register this SRV record.
_kpasswd._tcp.DnsDomainName.
Allows a client to locate a Kerberos Password Change server for the domain. All servers providing the Kerberos Password Change service register this name. This server at least conforms to draft-ietf-cat-kerb-chg-password-02.txt. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running at least an RFC 1510–compliant Kerberos v5 KDC service register this SRV record.
_kpasswd._udp.DnsDomainName.
Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied.

If multiple domain controllers have the same criteria, multiple records exist with the same information. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would simply pick one of the returned records at random to select a domain controller.

For information about the Kerberos v5 authentication protocol and Kerberos subprotocol extensions, see “Authentication” in this book.

Host Records for Non-SRV-Aware Clients

Netlogon registers the following DNS A records for use by LDAP clients that do not support DNS SRV records. The Locator does not use these records.

DnsDomainName.
Allows a client to locate any domain controller in the domain by using a normal A-record lookup. A name such as this is returned to the LDAP client through an LDAP referral.
gc._ms_dcs.DnsForestName.
Allows a client to locate any Global Catalog in the forest by using a normal A-record lookup. A name such as this is returned to the LDAP client through an LDAP referral.

Netlogon registers the following DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record.

DsaGuid.DnsForestName.
Allows a client to locate any domain controller in the forest using a normal A-record lookup. The only information known about the domain controller is the GUID of the Directory System Agent (also known as the DSA) object for the domain controller and the name of the forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

Other SRV Record Content

The following information is also included in a SRV record:

  • Priority

    The lowest of the available prioritized servers to query. A value of 0 indicates that no priority is set.

  • Weight

    A load-balancing mechanism that is used when selecting a target host from those that have the same priority. A value of 0 indicates that load balancing is not needed.

  • Port number

    The port where the server is listening for this service.

  • Target

    The fully qualified domain name of the host computer.

To illustrate the combined information contained in A resource records and SRV resource records, a domain controller named Phoenix in the domain reskit.com with an IP address of 157.55.81.157 that has no priority or load balancing set would register the following A records and SRV records with DNS:

phoenix.reskit.com    A    157.55.81.157
_ldap._tcp.reskit.com        SRV    0 0 389 phoenix.reskit.com
kdc._tcp.reskit.com    SRV    0 0 88 pheonix.reskit.com
_ldap._tcp.dc._msdcs.reskit.com    SRV    0 0 389 phoenix.reskit.com
kdc._tcp.dc_msdcs.reskit.com    SRV    0 0 88 phoenix.reskit.com.

With the SRV records and A records in place (and similar records by all of the other domain controllers in the same domain), a simple DNS lookup of _ldap._tcp.dc._msdcs.reskit.com returns the names and addresses of all domain controllers in the domain.

For more information about A records, SRV records, DNS, and dynamic DNS updates, see the TCP/IP Core Networking Guide.


Domain Controller Location Process

Each Windows 2000–based domain controller registers its DNS domain name on the DNS server and registers its NetBIOS name using a transport-specific mechanism (for example, WINS). Therefore, a DNS client locates a domain controller by querying DNS, and a NetBIOS client locates a domain controller by querying the appropriate transport-specific name service. Because the Windows 2000 IP/DNS-compatible Locator is shared code with the Windows NT 4.0–compatible Locator, both DNS clients and NetBIOS clients are supported.

The process for locating a domain controller can be summarized as follows:

  1. On the client (the machine locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator API (DsGetDcName) is implemented by the Netlogon service.
  2. The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName API.
  3. The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:
    • For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator — that is, DsGetDcName calls DnsQuery to read the SRV and A records from DNS, after it appends an appropriate string to the front of the domain name that specifies the SRV record.
    • For a NetBIOS name, Netlogon performs domain controller discovery (when necessary, converting the DomainName to a flat name) by using the Windows NT 4.0–compatible Locator, that is, by using the transport-specific mechanism (for example, WINS).
  4. The Netlogon service sends a datagram (“ping”) to the computer(s) that registered the name, thereby remoting the DsGetDcName API to the domain controller. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP UDP search.
  5. Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
  6. The Netlogon service returns the information to the client from the domain controller that responds first.
  7. The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and, thus, a consistent view of Active Directory.

DsGetDcName API

The following parameters are the DsGetDcName API parameters Netlogon uses to collect information from the client and to compose the DNS or WINS query. As described in “Domain Controller Location Process” earlier in this chapter, the API is remoted in a datagram to the discovered domain controllers, and the domain controller provides the information to the client.

  • ComputerName

    The name of the computer collecting the information. Typically, this parameter should be specified as NULL, which denotes the local computer.

  • DomainName

    The name of the domain to be queried. This name can be either a DNS-style name (for example, reskit.com.) or a flat, NetBIOS-style name (for example, reskit). If a DNS-style name is specified, the name can be specified with or without a trailing period.

  • DomainGuid

    The GUID of the domain being queried. This value is used when a domain has been renamed. If this value is specified and DomainName has been renamed, DsGetDcName attempts to locate a domain controller in the domain that has the specified DomainGuid.

  • SiteName

    The name of the site that should be closest to the returned domain controller. This parameter should typically be the name of the site in which the client is located. If not specified, SiteName defaults to the site of ComputerName.

  • Flags

    Additional information used to process the request, as follows:

    • DS_FORCE_REDISCOVERY.

    Requires that the “closest” domain controller be determined again, even though one is currently known in the cache. This flag can be used in case an additional domain controller becomes available or a domain controller has been detected as unavailable. The returned domain controller is verified to be running if this flag is specified. Without this flag, this API guarantees only that the returned domain controller was running when the domain controller initially was entered into the cache.

    • DS_DIRECTORY_SERVICE_REQUIRED.

    Requires that the returned domain controller supports Directory Server API (runs Windows 2000 Server).

    • DS_DIRECTORY_SERVICE_PREFERRED.

    Prefers that the returned domain controller supports Active Directory (that is, it runs Windows 2000 Server). If no such domain controller is available, a domain controller that is running Windows NT 4.0 or earlier is returned. If no domain controller that supports a directory service is available, DsGetDcName returns the name of the “closest” non-Active Directory domain controller; however, DsGetDcName returns the non-Active Directory domain controller information only after the attempt to find an Active Directory domain controller has timed out.

    • DS_GC_SERVER_REQUIRED.

    Requires that the returned domain controller be a Global Catalog (GC) server for the forest of domains that has this domain as the root. This flag cannot be set if the DS_PDC_REQUIRED flag is set.

    • DS_PDC_REQUIRED.

    Requires that the returned domain controller be the primary domain controller (PDC) for the domain. This flag cannot be set if the DS_GC_SERVER_REQUIRED flag is set. If this flag is specified, the DS_DIRECTORY_SERVICE_PREFERRED flag and DS_WRITABLE_REQUIRED flag are ignored.

    • DS_WRITABLE_REQUIRED.

    Requires that the returned domain controller host a writable copy of Active Directory (or SAM). If the specified DomainName is a NetBIOS name, this flag causes DsGetDcName to find either a primary domain controller or a Windows 2000 Server–based domain controller. If the specified DomainName is a DNS name, this flag is ignored

    • DS_IP_REQUIRED.

    Requires that the IP address of the discovered domain controller be returned.

    • DS_KDC_REQUIRED.

    Requires that the returned domain controller currently be running the Kerberos v5 KDC service.

    • DS_TIMESERV_REQUIRED.

    Requires that the returned domain controller currently be running the Windows Time Service.

    • DS_GOOD_TIMESERV_PREFERRED.

    Prefers that the returned domain controller be a “reliable” time server. The Windows Time Service can be configured to declare one or more domain controllers as “reliable” time servers. This flag is intended for use only by the Windows Time Service. Its behavior is subject to change.

    • DS_IS_FLAT_NAME.

    Specifies that the DomainName parameter is a NetBIOS name. As such, the IP/DNS-compatible Locator is not tried, and the Windows NT 4.0–compatible Locator is used. (See “Windows NT 4.0–Compatible Locator Process for Non-IP/DNS Clients” later in this chapter.) This flag cannot be specified with the DS_IS_DNS_NAME flag. It is valid to set neither DS_IS_FLAT_NAME nor DS_IS_DNS_NAME; however, DsGetDcName()takes longer to find a domain controller because it must try both the DNS-style and NetBIOS names. In addition, it is potentially ambiguous to specify neither flag. For example, if you specify a domain name of “reskit,” a domain with a NetBIOS name of “reskit” exists on your network, and a different domain with a DNS-style name of “reskit” also exists on your network, DsGetDcName()might find a domain controller in either domain.

    • DS_IS_DNS_NAME.

    Specifies that the DomainName parameter is a DNS name. (See “Windows NT 4.0–Compatible Locator Process for IP/DNS Clients” later in this chapter.) This flag cannot be specified with the DS_IS_FLAT_NAME flag.

    • DS_AVobject identifier_SELF.

    Specifies that the domain controller returned should not be the domain controller named by ComputerName. If ComputerName is not a domain controller, this flag is ignored. This flag can be used to get the name of another domain controller in the domain.

    • DS_RETURN_FLAT_NAME.

    Specifies that the returned DomainControllerName and returned DomainName should be flat names. If a flat name is not available, an error is returned. This flag cannot be specified with the DS_RETURN_DNS_NAME flag.

    • DS_RETURN_DNS_NAME.

    Specifies that the returned DomainControllerName and returned DomainName should be DNS names. If a DNS name is not available, an error is returned. This flag cannot be specified with the DS_RETURN_FLAT_NAME flag. This flag implies the DS_IP_REQUIRED flag.

    • DS_ONLY_LDAP_NEEDED.

    Specifies that the server returned must be an LDAP server. The server returned is not necessarily a domain controller. No other services are implied to be present at the server. The server returned does not necessarily have a writable Configuration container nor a writable Schema container. The server returned is not necessarily used to create or modify security principles. This flag can be used with the DS_GC_SERVER_REQUIRED flag to return an LDAP server that also hosts a Global Catalog server. The returned Global Catalog server is not necessarily a domain controller. No other services are implied to be present at the server. If this flag is specified, the following flags are ignored: DS_PDC_REQUIRED, DS_TIMESERV_REQUIRED, DS_GOOD_TIMESERV_PREFERRED, and DS_KDC_REQUIRED.

For more information about the DsGetDcName API and the DsGetDcName flags, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation. Search for MSDN at http://microsoft.com.

Finding a Domain Controller in the Closest Site

During a search for a domain controller, the Locator attempts to find a domain controller in the site “closest” to the client. When the domain that is being sought is a Windows 2000 domain, the domain controller uses the information stored in Active Directory to determine the closest site. When the domain being sought is a Windows NT 4.0 domain, domain controller discovery occurs at client startup and uses the first domain controller that it finds.

As described in “SRV Records Registered by Netlogon” earlier in this chapter, each Windows 2000–based domain controller registers DNS records that indicate the site where the domain controller is located. The site name is registered in several records so that the various roles the domain controller might perform (for example, Global Catalog server or Kerberos v5 server) each can be associated with the domain controller’s site. When DNS is used, the Locator searches first for a site-specific DNS record before it begins to search for a DNS record that is not site-specific (thereby preferentially locating a domain controller in that site).

A client computer stores its own site information, but it is not necessarily located physically in the site associated with its IP address. For example, a laptop computer in a new location contacts a domain controller in its home site, which is not the site to which the computer is currently connected. In this situation, the domain controller looks up the client’s site and returns the name of the site closest to the client. The client then updates the information in the DynamicSiteName registry entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters.

The domain controller stores site information for the entire forest in the Configuration container. The domain controller uses the site information to check the IP address of the client computer against the list of subnets in the forest. In this way, the domain controller ascertains the name of the site in which the client is assumed to be located, or the site that is the closest match, and returns this information to the client.

Active Directory Site and Subnet Objects

A site is a collection of domain controllers that have high-speed connections. In Active Directory, a site is defined by a site object in the cn=sites,cn=configuration,dc=DomainName…,dc=DomainName container. A subnet is an addressed segment within a site and is represented by an object in the cn=subnets,cn=sites,cn=configuration,dc=DomainName…,dc=DomainName container.

The site in which a domain controller is located is identified in the Configuration container by the domain controller object beneath the site object for a particular site. A domain controller can identify the site of a client by using the subnet object in the Sites container. Each subnet object has a SiteObject property that links it to a site object; the value of SiteObject is the distinguished name of the site object. This link enables a domain controller to identify clients that have an IP address in the specified subnet as being in the specified site.

Subnet names in Active Directory take the form “network/bits masked.” For example, the subnet object 172.16.72.0/22 (subnet of 172.16.72.0 and a 22-bit subnet mask) might have a SiteObject property value that contains the distinguished name of the Seattle site object. All IP addresses in the 172.16.72.0 subnet would therefore be considered to be in the Seattle site. The SiteObject property is a single value, which implies that a single subnet maps to a single site. However, multiple subnet objects can be linked to the same site object. The directory administrator manually creates subnet objects and, hence, the SiteObject property value.

The Configuration container (including all of the site and subnet objects in it) is replicated to all domain controllers in the forest. Therefore, any domain controller in the forest can identify the site in which a client is located, compare it to the site in which the domain controller is located, and indicate to the client whether that domain controller site is the closest site to the client.

For more information about site and subnet objects, see “Active Directory Sites and Replication” in this book.

Mapping IP Addresses to Site Names

During Netlogon startup, the Netlogon service on each domain controller enumerates the site objects in the Configuration container. Netlogon on each domain controller is also notified of any changes made to the site objects. Netlogon uses the site information to build an in-memory structure that is used to map IP addresses to site names.

When a client receives the list of IP addresses from DNS, the client begins querying the domain controllers in turn to find out which domain controller is available and appropriate. Active Directory intercepts the query, which contains the IP address of the client, and passes it to Netlogon on the domain controller. Netlogon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client’s IP address and then returns the following information:

  • The name of the site in which the client is located, or the site that most closely matches the client’s IP address.
  • The name of the site in which the current domain controller is located.
  • A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.

The domain controller returns the information to the client. The response also contains various other pieces of information that describes the domain controller. The client inspects the information to determine whether to try to find a better domain controller. The decision is made as follows:

  • If the returned domain controller is in the closest site (the returned bit is set), the client uses this domain controller.
  • If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses this domain controller.
  • If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the new domain controller is used. If the second query fails, the original domain controller is used.

This process ensures that a close domain controller is found, even if the domain is not in the same forest as the client. The potential cost is that the closest domain controller might not be found on the first attempt. If the domain being queried is the same as the domain in which the client is located, the site returned from the domain controller is considered to be the site where the client is located. The client stores this site name in the DynamicSiteName registry entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located. Never change dynamically determined values. To override the dynamic site name, edit the SiteName entry in the Netlogon subkey.

CAUTION

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows. To configure or customize Windows, use the programs in Control Panel or Microsoft Management Console whenever possible.

If the domain being located is in the same forest as the client and the client has not physically moved to a different site since the last query, the dynamically-determined site name in the registry is the actual site in which the client is located. As such, the client finds a domain controller in the correct site without having to retry the operation. If the site name in the registry is not the current site of the computer (for example, if the computer is a laptop), the domain controller location process serves to update the site information in the registry.

Registration in Every Site

There is not necessarily a domain controller in every site. It is possible that no domain controller exists for a given domain at the local site. For example, consider the case where sales-related domains are replicated within a site called Sales, but the engineering-specific domains are not. To eliminate this possibility, the Netlogon service registers DNS names for every domain at every site by using the site topology information stored in Active Directory. If there is one site that is physically closest to the Sales site and the site has domain controllers for the Engineering domain, the Engineering domain controllers in that site should be configured to “cover” the Sales site. This configuration is implemented by using information stored in the SiteCoverage registry entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters. This entry can store a list of sites in which the domain controller registers itself. In this case, the domain controller registers itself as existing in multiple sites. If a client pings this domain controller and the client is in one of those sites, the domain controller returns the bit for the “closest site.”

Clients with No Apparent Site

Sometimes the client pings a domain controller, and the client’s IP address cannot be found in the subnet-to-site mapping table. In this case, the domain controller returns a NULL site name, and the client uses the returned domain controller.

For more information about site location, see “Active Directory Sites and Replication” in this book.

Types of Locator

On the basis of parameters passed to Netlogon in the DsGetDcName API, the process of locating a domain controller proceeds in one of two ways:

  • The IP/DNS-compatible Locator is used if the domain name passed to DsGetDcName is a DNS-compatible name. The Netlogon service on the client looks up the name in DNS (by calling DnsQuery) after it appends an appropriate string to the front of the domain name. The DNS service supports a query for determining the set of domain controllers. If the client site name is known, the client’s DNS query specifies the site. DNS returns the IP addresses of domain controllers that match the DNS query. The client Netlogon service sends an LDAP UDP message to one or more of the domain controllers that have been returned by DNS to determine whether any of the domain controllers specified are running and support the specified domain.
  • The Windows NT 4.0–compatible Locator is used if the domain name passed to DsGetDcName is a NetBIOS name. The Netlogon service on the client sends a transport-specific logon request query to discover a domain controller in a given domain and then sends a mailslot message to one or more of the domain controllers to determine whether any of the domain controllers it found are running and support the specified domain.

For more information about the DsGetDcName Locator API, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation. Search for MSDN at http://microsoft.com.

For more information about DNS and IP address resolution, see “Understanding DNS” and “Windows 2000 Implementation of DNS” in the TCP/IP Core Networking Guide. For more information about Windows Time Service, see “Active Directory Sites and Replication” in this book.

IP/DNS-Compatible Locator Process for Windows 2000 Clients

The IP/DNS–compatible Locator uses DNS SRV records to locate the closest domain controller on the basis of the site name registered for a particular domain controller.

Note

A site name is registered in DNS as a DNS label, which implies that the site name must syntactically conform to the rules of a DNS label. For example, when represented in UTF-8, a label cannot be more that 63 octets long and cannot contain illegal characters such as a dot. (For more information about DNS naming rules, see the DNS chapters in the TCP/IP Core Networking Guide.)

The IP/DNS-compatible Locator algorithm runs in the context of the Netlogon service that is running (typically) on the client. The following process takes place after the Netlogon service has established that a DNS name is being requested.

  1. Locator queries DNS (calls DnsQuery) and specifies one of the criteria-specific DNS host names. If the client has site information, it first queries the site-specific DNS names. On the basis of parameters to the DsGetDcName API and the success or failure of a previous lookup, DNS is queried as follows:
    • If the DS_PDC_REQUIRED flag is specified, look up the _ldap._tcp.pdc._msdcs.DnsDomainName name. Return any success or failure to the caller.
    • If the DS_GC_SERVER_REQUIRED flag is specified and the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName name. If no domain controller is found, go to the next step. Otherwise, return any success or failure to the caller.
    • If the DS_GC_SERVER_REQUIRED flag is specified, look up the _ldap._tcp.gc._msdcs.DnsForestName name. Return any success or failure to the caller.
    • If the DS_KDC_REQUIRED flag is specified and the SiteName parameter is specified, look up the _kdc._tcp.SiteName._sites.dc._msdcs.DnsForestName name. If no domain controller can be found, go to the next step. Otherwise, return any success or failure to the caller.
    • If the DS_KDC_REQUIRED flag is specified, look up the _kdc._tcp.dc._msdcs.DnsForestName name. Return any success or failure to the caller.
    • If the DS_ONLY_LDAP_NEEDED flag is specified and the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.DnsDomainName name. If no computers is found, go to the next step. Otherwise, return any success or failure to the caller.
    • If the DS_ONLY_LDAP_NEEDED flag is specified, look up the _ldap._tcp.DnsDomainName name. Return any success or failure to the caller.
    • If the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName name. If no domain controller is found, go to the next step. Otherwise, return any success or failure to the caller.
    • Look up the _ldap._tcp.dc._msdcs.DnsDomainName name. If no domain controller has that name (which is not the same as “If no domain controllers can be found”), go to the next step. Otherwise, return any success or failure to the caller.
    • If the DomainGuid parameter is specified, look up the _ldap._tcp.DomainGuid.domains._msdcs.DnsForestName name. Otherwise, return any success or failure to the caller.
  2. If IP is not supported or DNS is not supported (indicated by an error returned from the DnsQuery API), implement the Windows NT 4.0–compatible Locator.
  3. If the specified name cannot be found (perhaps because the domain has been renamed), implement the Windows NT 4.0 – compatible Locator.
  4. DNS returns a list of IP addresses that match the target domain in the SRV record (that is, IP addresses of domain controllers in the specified domain) sorted by priority and weight, as described in RFC 2052. The client pings each IP address in the order returned. The ping is a UDP LDAP query to port 389. The client pings each domain controller from the list. After each ping, the client waits one-tenth of a second for a response to the ping (or to any previous ping), and then pings the next domain controller. Choosing the domain controllers at random provides a first level of load balancing. Doing multiple pings in quick succession ensures that the discovery algorithm terminates in a finite amount of time.
  5. The pinging continues until a viable response has been received or all the returned domain controllers have been tried.
  6. When a domain controller responds to the ping, the information supplied in the response is compared to the information specified to DsGetDcName. If the information does not match, the response is ignored.
  7. The first domain controller to respond to a ping is returned to the caller.
  8. If the client does not have site information or if none of the returned domain controllers responds, query DNS for the non -site-specific DNS name.

Windows NT 4.0–Compatible Locator Process for Non-IP/DNS Clients

When the IP/DNS Locator cannot be used, domain location proceeds using the Windows NT 4.0–compatible Locator. The IP/DNS Locator is not used under any of the following conditions:

  • A NetBIOS domain name is supplied to DsGetDcName.
  • IPX or NetBEUI is the only available transport.
  • A Windows NT 3.51 or Windows NT 4.0 domain is being located.
  • A Windows 3.1, Windows for Workgroups 3.1, Windows for Workgroups 3.11, Windows NT 3.51, Windows NT 4.0, Windows 95, or Windows 98 client is doing the locating.

In these cases, the Windows NT 4.0–compatible Locator is used to locate a domain controller in the domain. In general, the Windows NT 4.0–compatible Locator works as follows:

  1. The client discovers a domain controller in a domain by sending a NETLOGON_SAM_LOGON_REQUEST message to \mailslot\net\ntlogon mailslot on the DomainName[1C] NetBIOS name of the domain whose domain controller is being discovered.
  2. The DomainName[1C] NetBIOS name is registered by every Windows NT domain controller in the domain. The specific name resolution mechanism and datagram delivery mechanism used is transport-specific. The client uses the first domain controller that responds to the message.

Note

The algorithm described here locates any domain controller in the domain. A similar algorithm, implemented in NetGetDcName in Windows NT 4.0, is used when the caller specifies finding a primary domain controller.

Domain Controller Request

A client requests a domain controller using the NETLOGON_SAM_LOGON_REQUEST message. In Windows 2000, this message is enhanced to contain the following new information:

  • The NtVersion field specifies that Windows 2000 – specific fields are present and that the response should contain more information.
  • The RequestedDomainName field is used by Netlogon to identify the queried domain if the RequestedDomainGuid field is not present. This field immediately follows the existing DomainSid field.
  • The RequestedDomainGuid field is used by Netlogon to identify the queried domain. This field immediately follows the RequestedDomainName field.

A Windows NT 3.51–based or Windows NT 4.0–based domain controller ignores the additional information in the query message.

Note

When a Windows 2000 domain has an external trust relationship with a non – Windows 2000 domain (a Windows NT 3.51 or Windows NT 4.0 domain), discovery of domain controllers in the external trusted domain is performed immediately when the client starts. Discovery at logon is not possible because the accounts in the trusted domain, which is outside the forest, are not available in the Global Catalog. the Global Catalog is required to log on to the domain.

Domain Controller Response

A domain controller responds to the NETLOGON_SAM_LOGON_REQUEST message with a NETLOGON_SAM_LOGON_RESPONSE mailslot message, as follows:

  1. A Windows NT 3.51–based or Windows NT 4.0–based domain controller returns a NETLOGON_SAM_LOGON_RESPONSE mailslot message.
  2. A Windows 2000–based domain controller returns a NETLLOGON_SAM_LOGON_RESPONSE mailslot message to a Microsoft® Windows 3.1, Microsoft® Windows® for Workgroups 3.1, Microsoft® Windows® for Workgroups 3.11, Windows NT 3.51, or Windows NT 4.0 client.
  3. A Windows 2000–based domain controller returns a NETLOGON_SAM_LOGON_RESPONSE_EX message to a Windows 2000 client. All characters in this message are in the UTF-8 character set. The response message contains the following additional information:
    • The NtVersion field indicates that Windows 2000–specific fields are present.
    • The DomainGuid field returns the GUID of the domain.
    • The DnsDomainName field returns the DNS name of the domain.
    • The DnsForestName field returns the DNS domain name of the forest in which the domain controller is located.
    • The DcSiteName field returns the name of the site in which the domain controller is located.
    • The ClientSiteName field returns the name of the site in which the client is located.
    • The DcSockAddr field returns the IP address of the domain controller.
    • The Flags field indicates the following information about the domain controller:

    Whether it is the primary domain controller.

    Whether it supports the Global Catalog.

    Whether it supports Active Directory.

    Whether it is in the site closest to the client.

The Windows NT 4.0–compatible Locator cannot completely implement the DsGetDcName flag, which requires that a returned domain controller support the directory service API (that is, the domain controller is running Windows 2000). If the DomainGuid parameter is NULL, WINS is configured, and no Windows 2000–based domain controllers are among the 25 closest domain controllers in the domain, DsGetDcName fails as though no domain controller were available.

Re-Querying to Find the Closest Site

A Windows 2000 client using the Windows NT 4.0–compatible Locator to find a domain controller attempts to find a domain controller in the site closest to it. After a domain controller is found, the mailslot response is inspected to determine the following:

  • Whether the DNS domain name of the domain was returned (is not true if the domain controller is running Windows NT 3.51 or Windows NT 4.0).
  • Whether the ClientSiteName was returned (is not true if there is no subnet object that matches the IP address of the client).
  • The domain controller did not indicate that it is in the site closest to the client.

If all of the above have the value TRUE, DsGetDcName calls DsGetDcName again and passes it the DNS domain name and the site name. This new call to DsGetDcName uses the IP/DNS Locator to try to find a domain controller in the named site. If a domain controller is found, that domain controller is returned to the client as the result of the original DsGetDcName call. If no domain controller is found, the original domain controller is returned.


Tree and Forest Structure

In accordance with DNS naming standards, Active Directory domains are created in an inverted tree structure, with the root at the top. In addition, this Windows 2000 domain hierarchy is based on trust relationships, that is, the domains are linked by interdomain trust relationships.

Note

The default interdomain trust relationships are created by the system during domain controller creation. The number of trust relationships that are required to connect n domains is n-1, whether the domains are linked in a single, contiguous parent-child hierarchy or they constitute two or more separate contiguous parent-child hierarchies.

When domains in the same organization have different namespaces, administrators create a separate tree for each namespace, and the roots of the trees are linked by a trust relationship. Trees linked by a trust relationship form a forest. A single tree that is related to no other trees can by itself constitute a forest of one tree.

The tree structures for the entire Windows 2000 forest are stored in Active Directory in the form of parent-child and tree-root relationships. These relationships are stored as trust account objects (class trustedDomain) in the System container within a given domain partition. For each domain in a forest, information about its connection to a parent domain, or in the case of a tree root, to another tree root domain, is added to the configuration data that is replicated to every domain in the forest. Therefore, every domain controller in the forest has knowledge of the tree structure for the entire forest, including the links between trees. You can view the tree structure in Active Directory Domain Tree Manager.

For more information about configuration data, see “Active Directory Data Storage and Name Resolution” in this book.


Tree: Implementation of a Domain Hierarchy and DNS Namespace

A Windows 2000 tree is an instance of a DNS namespace: it has a single root and is built as a strict hierarchy; each domain below the root has exactly one superior, or parent, domain. The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it, as illustrated in Figure 2.5.

Figure 2.5 A Contiguous Tree Hierarchy

In Windows 2000, the following rules determine the way trees function in the namespace:

  • A tree has exactly one name. The name of the tree is the DNS name of the domain at the root of the tree. The tree name is stored as the treeName attribute on the domainDNS object for each domain in the tree. The value is established when the first instance of the root domain is installed and is propagated during setup to replicas and all children of the root domain.
  • Child domains of the tree root are always contiguous with it in the namespace.
  • The DNS names of the child domains of a tree’s root domain reflect this organization; therefore, the children of the root domain somedomain are always children of somedomain in the DNS namespace, as for example, child1.somedomain, child2.somedomain, and so forth.

Domains within an Active Directory domain tree share a common directory schema, configuration information, and Global Catalog. They also have transitive trust relationships that allow users in each domain access to available resources in all other domains in the tree.

Note

The directory schema and configuration data are shared because they are stored in separate partitions that are replicated to domain controllers in every trust-related domain. (See “Active Directory Data Storage and Name Resolution” in this book.) The data relative to a given domain is replicated only to domain controllers in the same domain. (See “Active Directory Sites and Replication” in this book.) The Global Catalog is a partial replica of Active Directory that makes it possible to search for objects at the forest level rather than at the tree level.

Root Domain

The first Windows 2000 domain you create, the root domain, is the parent of all subsequent Active Directory child domains and is special in that it has no domain above it, that is, no parent domain. The root domain is also called the forest root. The root domain stores the following types of information:

  • Configuration information that defines the structure of a forest — what domains share trust relationships and the nature of the trust relationships, for example, parent-child relationships or trust relationships between trees.
  • Service information that provides access to Active Directory.
  • Site topology information that is required for replication.
  • The directory schema, which defines the objects that can be created in the directory.

Configuration and directory schema information from the root domain is copied to new child domains as they are created. When Active Directory is installed on a Windows 2000 Server–based computer, configuration and directory schema information is copied from the parent domain to the new server. Updates to configuration and directory schema information are replicated to all domain controllers throughout the forest. The distribution of this configuration and directory schema information ensures that every domain controller is aware of all other trust-related domains and of the replication topology, which makes finding and using resources in other domains possible. (For more information, see “Active Directory Data Storage and Name Resolution” in this book.)

Note

The root domain should not be confused with the root of the directory. The tree formed by a given Active Directory hierarchy has a beginning point, simply called a root, which is superior to all domains, including the so-called root domain. This Active Directory hierarchy root is a figurative object that has no name — that is, it has no LDAP distinguished name; it is not an “entry” in the directory but is represented as a null distinguished name. It also has attributes and is known to LDAP as rootDSE. RootDSE is required by LDAP as an entry point to the directory. The distinction should be clear between this root — the set of attributes that LDAP uses to connect to a particular portion of the directory (it cannot connect to the entire thing because the directory is partitioned), and the root domain of the forest, which stores some number of these partitions. In addition, both of these “roots” should be kept distinct from the root of the DNS hierarchy, which is the empty space at the top of the hierarchy represented as “.” and which is required as an entry point to the DNS hierarchy.

For more information about rootDSE and the directory tree, see “Active Directory Storage and Name Resolution” in this book. For more information about the DNS root, see “Understanding DNS” in the TCP/IP Core Networking Guide.

Child Domains

Below the root domain, other domains can be created as logical subdivisions of the root domain. These subordinate domains are called child domains. A child domain can be the parent of other child domains. All domains in a hierarchy are children of the root domain and are named accordingly.

Child domains can represent geographical entities (for example, the United States and Europe), administrative entities within the organization (for example, sales and marketing departments), or other organization-specific boundaries, according on the needs of the organization. The domains are created below the root to minimize Active Directory replication and to provide a means for creating domain names that do not change. Changes in the overall domain architecture, such as domain collapses and domain re-creation, create difficult and potentially IT-intensive support requirements. A good namespace design should be capable of withstanding company reorganizations without the need to restructure the existing domain hierarchy.

Note

Administrative privileges do not extend from parent domains to child domains. Privileges must be granted explicitly for each domain.

For information about namespace design and the rationale for naming the root domain and creating child domains, see “Designing the Active Directory Structure” and “Determining Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide. For information about administrative privileges, see “Authentication” and “Access Control” in this book.


Forest: The Implementation of Multiple Trees

A forest is a collection of one or more Windows 2000 Active Directory trees, organized as peers and connected by two-way, transitive trust relationships between the root domains of each tree. A single tree constitutes a forest of one tree. A forest is synonymous with Active Directory — that is, the set of all partitions in a given directory service instance comprise a forest.

Trees in the same forest do not form a contiguous namespace. They form a discontiguous namespace that is based on different DNS root domain names. However, trees in a forest share a common directory schema, configuration, and Global Catalog. This sharing of common data, in addition to trust relationships between their roots, distinguishes a forest from a set of unrelated trees. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory. A forest exists as a set of cross-reference objects and trust relationships supported by Kerberos v5 authentication and known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources. (For more information about cross-reference objects, see “Active Directory Storage andName Resolution” in this book.)

Important

Trees and forests are specific to Windows 2000 domains. A Windows NT 4.0 domain that is configured to trust or be trusted by a Windows 2000 domain is not part of the Windows 2000 forest.

The forest structure provides companies with the option of constructing their enterprise from separate, distinct, noncontiguous namespaces. Having a separate namespace is desirable under some conditions where, for example, an acquired company’s namespace should remain intact. If you have business units with distinct DNS names, you can create additional trees to accommodate the names. An example of this type of organization is shown in Figure 2.6.

Figure 2.6 Example of a Forest with Two Trees

For more information about the contents of Active Directory configuration, directory schema, and Global Catalog, see “Active Directory Data Storage and Name Resolution,” in this book.

Forest Root

The first domain created in the forest is the forest root; that is, the root domain is the root of the entire forest, not just the initial tree. The forest root cannot be changed or renamed. When you create a new tree, you specify the root domain of the initial tree, and a trust relationship is established between the root domains of the second tree and the initial tree. If you create a third tree, a trust relationship is established between the root of the third tree and the forest root. Because trust is transitive and bidirectional, the root of the third tree also has two-way trust with the second tree.

Global Catalog and Forest-Wide Searches

The mechanism for searching in Active Directory is the LDAP query, which is limited to the objects stored by the domain controller where the search begins. Searches can be carried out within a tree by a system of referrals to other domains when a query is not resolved in the current domain. Because each domain is aware of all other domains in the tree, an LDAP search can be passed from domain to domain until a match is found. However, although each domain is aware of other trees in the forest, the maximum scope of LDAP referrals is the tree.

To accommodate forest-wide searches in forests that consist of two or more trees and to eliminate potentially lengthy referrals within trees, a catalog of all objects in the forest is generated by default when the forest root domain is created. This catalog, called the Global Catalog, contains only a subset of attributes for each object and is therefore only a partial replica of the entire directory. The Global Catalog allows users and applications to find objects in an Active Directory tree given one or more attributes of the object for which they are searching.

The default attributes in the Global Catalog are those most frequently used in search operations (for example, a user’s first and last names, logon names) and those required to locate a full replica of the object. The Global Catalog allows users to find objects of interest quickly without knowing the names of the domains in which the objects are located and without requiring a contiguous namespace.

A default set of attributes is stored in the Global Catalog, but administrators can change (add or remove) these attributes by selecting them in the directory schema. The decision to add more attributes to those stored in the Global Catalog should be weighed against the additional cost of replicating more data between all of the domain controllers in the forest. Global catalog servers are domain controllers that store a local domain full replica as well as the Global Catalog forest-wide partial replica. By default, the first domain controller installed in the forest stores the Global Catalog. The number and placement of Global Catalog servers should be based on need, although as a general rule, at least one Global Catalog should be available in each site. Use the Active Directory Sites and Services MMC snap-in to configure a domain controller as a Global Catalog server.

Global Catalog searches are LDAP queries that are specified as such by including “gc:” in the query and are received on a different port than the port used for LDAP queries. A regular LDAP query must identify a search base (where to start from) that is at or below the root domain. Any query that originates at a level above the forest root — that is, at the null directory root level — is referred to the Global Catalog port 3268 instead of to the standard LDAP port 389. When such a request is received, Active Directory translates the null distinguished name to the root domain distinguished name. If the query contains a request for an attribute that is stored in the Global Catalog, the query is resolved in the same manner as an LDAP query.

For more information about LDAP and Global Catalog queries, see “Active Directory Data Storage and Name Resolution” in this book.


Trust Relationships

Active Directory provides security across multiple domains through interdomain trust relationships. When there are trust relationships between domains, the authentication mechanism for each domain trusts the authentication mechanism for all other trusted domains. If a user or application is authenticated by one domain, its authentication is accepted by all other domains that trust the authenticating domain. Users in a trusted domain have access to resources in the trusting domain, subject to the access controls that are applied in the trusting domain.

Note

“Access to resources” in any discussion of trust relationships always assumes the limitations of access control. Trust relationships allow users and computers to be authenticated (to have their identity verified) by an authentication authority. Access control allows authenticated users to use the resources (files, folders, virtual containers) that they have been authorized to use and prohibits them from using (or even seeing) resources that they are not authorized to use. For more information about resource authorization, see “Access Control” in this book.

Transitive and Nontransitive Trust

In Windows NT 3.51 and Windows NT 4.0, trust relationships must be created explicitly in one direction. A two-way trust relationship is established by creating two one-way trust relationships. Domains can be connected by explicit one-way or two-way trust relationships for the purpose of enabling access to resources, but they are not necessarily related in any other way.

In Windows 2000, domains can be joined to a domain tree or forest, and each child domain has an automatic two-way trust relationship with the parent domain. This trust relationship is also transitive. Transitive trust means that the trust extended to one domain is automatically extended to any other domain that is trusted by that domain. Transitive trust is applied automatically for all domains that are members of the domain tree or forest. Therefore, when a grandchild domain is created, the trust relationship between the parent and child domains is accepted by the grandchild domain, and vice versa. For example, if a user account is authenticated by the parent domain, the user has access to resources in the grandchild domain. Similarly, if the user is authenticated by a child domain, the user has access to resources in the parent domain as well as in the grandparent domain.

All domains that are members of a domain tree or forest have transitive trust relationships with all other domains in the same forest. Therefore, there is complete trust between all domains in an Active Directory forest.

Important

Transitive trust relationships are always two-way trust relationships.

A nontransitive trust relationship can be created between Windows 2000 domains when a transitive trust relationship is not appropriate, but this trust relationship must be created explicitly. It can be created, for example, between the roots of two forests or between a domain in one forest and a domain in a different forest.

A trust relationship between a Windows 2000 domain and a Windows NT 4.0 domain is always a nontransitive trust relationship. If one of these domains is an account domain and the other is a resource domain, the trust relationship is usually created as a one-way trust relationship. If there are user accounts in both domains, two one-way trust relationships can be created between them.

The trust relationship between two domains — whether one-way or two-way, transitive or nontransitive — is stored as an interdomain trust account object in Active Directory.

For more information about the nature and management of interdomain trust objects, see “Authentication” in this book. For information about mixed-mode trust relationships, see “Determining Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide.

Direction of Trust

In describing trust relationships, arrows illustrate the direction of trust between domains, as follows:

  • If B is the trusting domain and A is the trusted domain, then BàA indicates that Domain B trusts Domain A. (The same trust can be illustrated as AßB, that is, A is trusted by B.)
  • When Domain B trusts Domain A (BàA), users with accounts in Domain A can be authenticated for access to resources in Domain B. However, users with accounts in Domain B are not trusted to be authenticated for access to resources in Domain A.

A hierarchy of Windows 2000 domains is implemented by interdomain trust relationships. The direction of trust between a parent and child domain in Active Directory is two-way (AßàB), with the following restrictions:

  • The parent-child relationship between two domains in a domain tree is defined by a subordinate name relationship. For example, noam.reskit.com is a child of reskit.com, but noam.com is not a child of reskit.com. A parent-child trust relationship requires both a parent-child relationship and a direction of trust, as follows: Domain A can be specified as the parent of Domain B only if BàA and B is a subordinate name of A.
  • When a new domain joins a domain tree as a child, a parent-child trust relationship is defined automatically that establishes transitive trust.

Note

Automatic configuration of replication topology requires that all parent-child trusts within the forest are bidirectional and transitive.

The use of transitive trust relationships reduces management time because it decreases by more than half the number of trust relationships that must be managed, as the diagram in Figure 2.7 illustrates.

Figure 2.7 A Comparison of Two-Way Trust Relationships in Windows 2000 and Windows NT 4.0

Authentication Protocols

Windows 2000 authenticates users and applications using one of two protocols: the Kerberos v5 authentication protocol or the NTLM authentication protocol. The protocol to be used is determined by the capabilities of the client and the server; if the client does not recognize the Kerberos protocol (for example, a computer that is running Windows NT 3.51 or Windows NT 4.0), authentication occurs using the NTLM challenge-response protocol. Conversely, if the resource server does not support Kerberos authentication, the client uses NTLM to authenticate to the server.

The Kerberos v5 protocol is the default protocol for network authentication on computers that are running Windows 2000. The Distributed Systems Client upgrade for Windows 95 and Windows 98 enables Kerberos authentication on clients that are running those operating systems as well.

The NTLM protocol is the default for network authentication in Windows NT 4.0. It is retained in Windows 2000 for compatibility with previous versions of Windows clients and servers. But the protocol of choice in Windows 2000, when there is a choice, is the Kerberos v5 protocol.

In Windows 2000 domains, the NTLM protocol is used to authenticate logons as follows:

  • Computers that are running Windows NT 3.51 or Windows NT 4.0 logging on for network authentication in Windows 2000 domains.
  • Computers that are running Windows 2000 logging on to servers that are running Windows NT 4.0.
  • Computers that are running Windows 2000 when they request access to resources in Windows NT 4.0 domains or resources on a computer in a Windows 2000 domain that is running Windows NT 4.0.

The essential difference between the two protocols is this:

  • With the NTLM protocol, the server must contact a domain authentication service on a domain controller to verify the client’s credentials. A server authenticates a client by forwarding the client’s credentials to a domain controller in the client’s account domain.
  • With the Kerberos v5 protocol, the server does not have to contact the domain controller. A client gets a ticket for a server by requesting one from a domain controller in the server’s account domain; the server validates the ticket without consulting any other authority.

For more information about the Kerberos v5 and NTLM authentication protocols, see “Authentication” in this book.

Trust Path

A trust path is defined by a series of trust links from one domain to another domain for passing authentication requests. For example, when a user makes a request for information from a server computer in a domain other than the domain in which a user is currently logged on, the server computer must be able to authenticate the user. Before authentication can occur, Windows security must determine whether the domain that is requested (the domain in which the contacted server is located) has a trust relationship with the logon domain of the user account. To make this determination, the Windows 2000 security system computes a trust path between the domain controller for the server that receives the request and a domain controller in the requesting user’s account domain.

In the Windows 2000 distributed security model, every workstation and server has a direct trust path to a domain controller in the domain in which it is located. The trust path is implemented by the Netlogon service through an authenticated remote procedure call (RPC) connection to the trusted domain authority, namely, the domain controller. In addition, a secure channel extends to other Windows 2000 domains through interdomain trust relationships. The secure channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups.

Every Windows 2000 domain has knowledge of all other domains in the forest, as well as of all external domains that it directly trusts or that trust it. With this information, a domain controller builds the shortest path for authentication. When building the trust path, each domain is first checked to see whether it is the requested domain and then checked for any cross-link trusts to the requested domain. If none of these conditions exists, the request is passed (referred) to the parent domain (because by definition, the child domain trusts the parent domain); however, if there is no transitive trust relationship, the request is denied. If the request is passed all the way to the root domain, it can be referred to a different domain tree root in the forest or to a domain in a different forest, if an external trust relationship exists.

Note

A cross-link trust relationship is a trust relationship that is explicitly created to shorten the trust path between domains that are in the same forest.

If the authentication request is referred, a path is computed for either NTLM pass-through authentication or for a Kerberos referral by using the information about the tree and current cross-link trust relationships to find the path to the destination domain. In this computation, cross-link trust relationships play the role of circumventing the higher domains in the hierarchy. At each level of the tree, a check is made of the cross-link trust relationships that might exist. If one is found to the destination domain, the next domain in the tree does not have to be checked.

Processing Referrals

When the request for authentication is referred, trust relationships must be taken into account relative to their direction and whether they are transitive or nontransitive. Referrals are processed differently by the two Windows authentication protocols.

Kerberos v5 Authentication Protocol

If the client uses the Kerberos v5 authentication protocol, the client requests a ticket to the server in the target domain from a domain controller in its account domain. The Kerberos KDC is a service that acts as a trusted intermediary between a client and server; it provides a session key that enables the two parties to authenticate each other. If the target domain is different from the current domain, the KDC uses the following logic to determine whether an authentication request can be referred:

  • Is the current domain directly trusted by the requested server’s domain?
    • If yes, send the client a referral to the requested domain.
    • If no, go to the next step.
  • Is there transitive trust between the current domain and the next domain on the trust path?
    • If yes, send the client a referral to the next domain on the trust path.
    • If no, send the client a logon-denied message.

Identification of the domain to which the referral is to be routed is based on cross-reference information in the Configuration container. A path to the referred domain is computed to use a maximum of one hop out of the forest. Because transitive trust is not supported for external trust relationships between domains from different forests, one hop is the maximum distance a referral can be extended outside a forest.

NTLM Authentication Protocol

If the client uses the NTLM authentication protocol, the initial request for authentication goes directly from the client to the resource server in the target domain. This server sends the user’s security credentials to a domain controller in its computer account domain. This domain controller checks the user account against its security accounts database. If the account does not exist, the domain controller uses the following logic to perform pass-through authentication, forward the request, or deny the request:

  • Does the current domain have a direct trust relationship with the user’s domain?
    • If yes, the domain controller sends the client’s credentials to a domain controller in the user’s domain for pass-through authentication.
    • If no, process the next step.
  • Does the current domain have a transitive trust relationship with the user’s domain?
    • If yes, pass the authentication request on to the next domain in the trust path. This domain controller begins the process again by checking the user’s credentials against its security accounts database.
    • If no, send a logon-denied message to the client.

For more information about NTLM authentication and Kerberos v5 authentication mechanisms, see “Authentication” in this book. For more information about cross-reference objects in the Configuration container, see “Active Directory Data Storage and Name Resolution” in this book.

Types of Trusts

The following types of trust relationships can be established with Windows 2000 domains:

Tree-Root
A tree-root trust relationship is the trust relationship that is established when you add a new tree to a forest. The Active Directory installation process automatically creates a trust relationship between the domain you are creating (the new tree root) and the forest root. The forest root is the first domain created in the forest; this domain is always the forest root and cannot be renamed. A tree-root trust relationship has the following restrictions:
  • It can be set up only between the roots of two trees in the same forest.
  • It must be transitive and, therefore, two-way.

Parent-Child
A parent-child trust relationship is the trust relationship that is established when you create a new domain in a tree. The Active Directory installation process automatically creates a trust relationship between the new domain and the domain that immediately precedes it in the namespace hierarchy (for example, noam.reskit.com is created as the child of reskit.com). The parent-child trust relationship has the following characteristics:
  • It can exist only between two domains in the same tree and namespace.
  • The parent domain is always trusted by the child domain.
  • It must be transitive. The bidirectional nature of transitive trust relationships allows the global directory information in Windows 2000 to replicate throughout the hierarchy.

Cross-Link
A cross-link (shortcut) trust relationship is a manually created trust relationship that improves the efficiency of remote logons by shortening the trust path. If users in Domain A often need access to resources in Domain C, you might want to create a direct link through a cross-link trust relationship so that Domain B can be bypassed in the trust path. A cross-link trust relationship has the following characteristics:
  • It can be established between any two domains in the same forest.
  • It must be set up explicitly as one-way or two-way.
  • It can be transitive.

External
An external trust relationship is a manually created trust relationship between Windows 2000 domains that are in different forests or between a Windows 2000 domain and a domain whose domain controller is running Windows NT 4.0 or earlier. An external trust relationship has the following characteristics:
  • It is one-way and must be set up manually in each direction to establish a two-way trust relationship.
  • It is nontransitive.

Non-Windows Implementation with a Windows 2000 Domain
A non-Windows implementation with a Windows 2000 domain is a trust relationship between an MIT-based Kerberos v5 protocol implementation on a UNIX system and a Windows 2000 domain. This trust relationship allows cross-platform interoperability for authentication purposes. This type of trust relationship has the following characteristics:
  • It is one-way by default. To establish a two-way trust relationship, a one-way trust relationship in each direction must be set up manually.
  • It is nontransitive.

Use Active Directory Domains and Trusts to manage trust relationships by using the Properties of a domain object. The Properties page shows two lists: one shows the trusted domains, the other the trusting domains for the current domain.

For more information about establishing trust relationships using Active Directory Domains and Trusts, see Windows 2000 Server Help. For more information about planning trust relationships, see “Determining Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide.

Trusts Between Windows 2000 and Windows NT 4.0 Domains

Windows 2000 and Windows NT 4.0 domains can trust each other for mutual authentication, but they can do so only if explicit, one-way trust relationships have been created mutually between them. Such trusts are always between a member of a Windows 2000 tree and a domain outside the tree. (Transitive trust is possible only between two Windows 2000 domains.)

The following examples illustrate the effect of the direction of trust between a Windows 2000 domain and a Windows NT 4.0 domain.

  • A (Windows 2000 domain, may be part of a tree) à B (Windows NT 4.0 domain). This trust relationship indicates that users in Domain B have access to resources in Domain A but do not have access to resources in any other domain within the tree.
  • B (Windows NT 4.0 domain) à A (Windows 2000 domain, may be part of a tree). This trust indicates that only users in Domain A (not users in other domain within the tree) have access to resources in Domain B.

Mixed-Environment Scenario

Figure 2.8 illustrates a mixed environment of two Windows 2000 forests and a Windows NT 4.0 domain. In all, four separate namespaces are implemented: A.com, D.com, G.com, and F.

The following conditions are represented in Figure 2.8:

  • A.com and D.com are the roots of separate trees in Forest 1. The two-way, transitive, tree-root trust between them provides complete trust between all domains in the two trees of Forest 1.
  • E.D.com uses resources in C.A.com for everyday business operations. To shorten the trust path between the two domains, C.A.com trusts E.D.com directly. This trust does not have to be bidirectional or transitive; it serves only the purpose of shortening the trust path for authenticating E.D.com users to use resources in C.A.com. The path is shortened by cutting the number of hops required for authentication from three (E.D.com to D.com, D.com to A.com, and A.com to C.A.com) to one (E.D.com to C.A.com), which increases the speed of authentication.
  • G.com is the root of a single tree that makes up Forest 2. The two-way, transitive trust between G.com and H.G.com allows both domains to use each others’ resources.
  • Domain G.com in Forest 2 implements an explicit one-way external trust relationship with domain D.com in Forest 1; users in domain D.com are trusted to use resources in domain G.com. Because the trust is nontransitive, no other domains in Forest 1 have access to resources in G.com, and D.com does not have access to resources in H.G.com.
  • Domain F is a Windows NT 4.0 domain that provides support services to the users in E.D.com. This one-way nontransitive trust does not extend to any other domains in Forest 1.

Figure 2.8 A Mixed Environment of Two Forests and an Extranet


Active Directory Objects

Active Directory objects represent the physical entities that make up a network. An object is an instance of storage of a class. A class is defined in the Active Directory schema as a specific set of mandatory and optional attributes — that is, an attribute can be present in an object in Active Directory only when that attribute is permitted by the object’s class. Classes also contain rules that determine the classes of objects that can be superior (parents) and subordinate (children) to an instance of the class. Each attribute is also defined in the directory schema. The attribute definitions determine the syntax for the values the attribute can have.

When you create an object in Active Directory, you provide values for the attributes of an instance of a given class, and you do so according to the rules of the directory schema. For example, when you create a user object, you provide alphanumeric values for the user’s first and last names, the logon identifier, and perhaps other values, such as telephone number and address. You cannot create the user successfully without providing acceptable values for the user name and logon name because these attributes are mandatory, according to the directory schema.

Applications that create or modify objects in Active Directory use the directory schema to determine what attributes the object must and might have, and what those attributes can look like in terms of data structures and syntax constraints. For this reason, the directory schema is maintained forest-wide so that all objects created in the directory conform to the same rules.

Objects are either container objects or leaf objects. A container object stores other objects, and, as such, it occupies a specific level in a given subtree hierarchy. A leaf object does not store other objects, and, as such, it occupies the end-point of a subtree.

For more information about how Active Directory objects are stored, see “Active Directory Data Storage and Name Resolution” in this book. For more information about the directory schema, see “The Active Directory Schema” in this book.


Object Naming

Active Directory is an LDAP-compliant directory service, which means that all access to directory objects occurs through LDAP. LDAP requires that names of directory objects be formed according to RFC 1779 and RFC 2247, which define the standard for object names in an LDAP directory service.

Distinguished Name

Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name (known as a DN). The name of the object itself, separate from the path to the object, is defined by the relative distinguished name.

The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy. It contains sufficient information for an LDAP client to retrieve the object’s information from the directory.

For example, a user named James Smith works in the marketing department of a company as a promotions coordinator. Therefore, his user account is created in an organizational unit that stores the accounts for marketing department employees who are engaged in promotional activities. James Smith’s user identifier is JSmith, and he works in the North American branch of the company. The root domain of the company is reskit.com, and the local domain is noam.reskit.com. The diagram in Figure 2.9 illustrates the components that make up the distinguished name of the user object JSmith in the noam.reskit.com domain.

Figure 2.9 The Distinguished Name for the User Object JSmith

Note

Active Directory snap-in tools do not display the LDAP abbreviations for the naming attributes domain component (dc=), organizational unit (ou=), or common name (cn=), and so forth. These abbreviations are shown only to illustrate how LDAP recognizes the portions of the distinguished name. Most Active Directory tools display object names in canonical form, as described in “Active Directory Name Formats” later in this chapter. Because distinguished names are difficult to remember, it is useful to have other means for retrieving objects. Active Directory supports querying by attribute (for example, the building number where you have to find a printer), so that an object can be found without having to know the distinguished name. (See “Active Directory Data Storage and Name Resolution” in this book.)

Relative Distinguished Name

The relative distinguished name (known as an RDN) of an object is the part of the name that is an attribute of the object itself — the part of the object name that identifies this object as unique from its siblings at its current level in the naming hierarchy. In the example in Figure 2.9 in the preceding section, the relative distinguished name of the object is JSmith. The relative distinguished name of the parent object is Users. The maximum length allowed for a relative distinguished name is 255 characters, but attributes have specific limits imposed by the directory schema. For example, in the case of the common name, which is the attribute type often used for naming the relative distinguished name (cn), the maximum number of characters allowed is 64.

Active Directory relative distinguished names are unique within a given parent; that is, Active Directory does not permit two objects with the same relative distinguished name under the same parent container. However, two objects can have identical relative distinguished names but still be unique in the directory because within their respective parent containers, their distinguished names are not the same. (For example, the object cn=JSmith,dc=noam,dc=reskit,dc=com is recognized by LDAP as different from cn=JSmith,dc=reskit,dc=com.)

The relative distinguished name for each object is stored in the Active Directory database. Each record contains a reference to the parent of the object. By following the references to the root, the entire distinguished name is constructed during an LDAP query. (See “Active Directory Data Storage and Name Resolution” in this book.)

Naming Attributes

As illustrated in “Distinguished Name” earlier the chapter, an object name consists of a series of relative distinguished names that represent the object itself and also every object in the hierarchy above it, up to the root object. Each portion of the distinguished name is expressed as attribute_type=value (for example, cn=JSmith). The attribute type that is used to describe the object’s relative distinguished name (in this case, cn=) is called the naming attribute. If you were to create a new classSchema object (that is, a new class in the Active Directory schema), the optional RdnAttID attribute could be used to specify the naming attribute for the class. In Active Directory, instances of default objects that you create have a default mandatory naming attribute. For example, part of the definition of the class User is the attribute cn (Common-Name) as the naming attribute. For this reason, the relative distinguished name for user JSmith is expressed as cn=JSmith.

The naming attributes shown in Table 2.1 are used in Active Directory, as described in RFC 2253.

Table 2.1 Default Active Directory Naming Attributes

Object Class | Naming Attribute | Schema Description
User | cn | Common-Name
Organizational unit | ou | Organizational-Unit-Name
Domain | dc | Domain-Component

Other naming attributes described in RFC 2253, such as o=for organizationName, c=for countryName, and l=for localityName, are not used in Active Directory, although they are recognized by LDAP.

The use of distinguished names, relative distinguished names, and naming attributes is required only when programming for LDAP using Active Directory Service Interface (ADSI) or other scripting or programming languages. The Windows 2000 user interface does not require you to enter such values.

For more information about creating new classSchema objects, see “The Active Directory Schema” in this book. For more information about using ADSI, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation, and look for the “Active Directory Programmers Guide.” Search for MSDN at http://microsoft.com.

Object Identity and Uniqueness

In addition to its distinguished name, every object in Active Directory has a unique identity. Active Directory is identity-based, that is, objects are known internally by their identity, not by their current name. Objects might be moved or renamed, but their identity never changes. The identity of an object is defined by a GUID, a 128-bit number that is assigned by the Directory Service Agent when the object is created. The GUID is stored in an attribute, objectGUID, that is present on every object. The objectGUID attribute is protected such that it cannot be altered or removed. When storing a reference to an Active Directory object in an external store (for example, a SQL Server database), the objectGUID value should be used. Unlike a distinguished name or a relative distinguished name, which can be changed, the GUID never changes.

Active Directory Name Formats

Several formats for providing object names are supported by Active Directory. These formats accommodate the different forms a name can take, depending on its application of origin. Active Directory administrative tools display name strings in a default format, which is the canonical name. The following formats are supported by Active Directory and are based on the LDAP distinguished name:

LDAP Distinguished Name
LDAP v2 and LDAP v3 recognize the RFC 1779 and RFC 2247 naming conventions, which take the form cn=common name, ou=organizational unit, o=organization, c=country. Active Directory uses the domain component (dc) instead of o=organization, and does not support c=country. The LDAP distinguished name lists relative distinguished names beginning at the leaf and ending at the root, as follows:
cn=jsmith,ou=promotions,ou=marketing,dc=noam,dc=reskit,dc=com
LDAP Uniform Resource Locator (URL)
Active Directory supports access via the LDAP protocol from any LDAP-enabled client. LDAP URLs are used in scripting. An LDAP URL names the server holding Active Directory services and the attributed name of the object (the distinguished name); for example:
LDAP://server1.noam.reskit.com/cn=jsmith,ou=promotions, ou=marketing,dc=noam,dc=reskit,dc=com.
Active Directory Canonical Name
By default, the Windows 2000 user interface displays object names using the canonical name, which lists the relative distinguished names from the root downward and without the RFC 1779 naming attribute descriptors; it uses the dotted DNS domain name. For the LDAP distinguished name in the previous example, the respective canonical name would appear:
noam.reskit.com/marketing/promotions/jsmith

DNS-to-LDAP Distinguished Name Mapping

Although DNS domain names match Active Directory domain names, they are not the same thing. Active Directory names have a different format, which is required by LDAP to identify directory objects. Dotted DNS domain names are therefore mapped to Active Directory domain names, and vice versa, as described in RFC 2247.

All access to Active Directory is carried out through LDAP. LDAP uses distinguished names to provide unique names to directory objects; every object in Active Directory has an LDAP distinguished name. A distinguished name is a naming structure that consists of a string of the hierarchical components that make up the complete object. Each distinguished name component is the relative distinguished name of an object in the hierarchy, beginning with the object itself and ending with the root object in the domain tree. An algorithm automatically provides an LDAP distinguished name for each DNS domain name.

The algorithm provides a domain component (dc) attribute-type label for each DNS label in the domain name. Each DNS label corresponds to the relative distinguished name of an Active Directory domain. For example, the DNS domain noam.reskit.com is translated to the LDAP distinguished name that has the form dc=noam,dc=reskit,dc=com.

Logon Names

Security principals are objects to which Windows security is applied in the form of authentication and authorization. Users are security principals, and they are authenticated (their identity is verified) at the time they log on to the domain or local computer. They are authorized (granted or denied access) when they use resources.

Security principals have two types of logon names:

NetBIOS Name
A NetBIOS name is a name that is compatible with the format required by NetBIOS APIs. This form of logon name is required for backward compatibility with NetBIOS applications and with Windows NT 3.x and Windows NT 4.0 domains. NetBIOS names are sometimes referred to as downlevel names (to indicate earlier versions of software), SAM account names (because security principals in earlier versions of Windows NT are stored in SAM), or flat names (because there is no hierarchy in the naming, so every name must be unique in the domain). These names are all used to distinguish names as other than DNS hierarchical names.
User Principal Name
A user principal name (user principal name) is a“friendly” name that is shorter than the distinguished name and easier to remember. The user principal name consists of a shorthand name that represents the user and usually the DNS name of the domain where the user object resides, or any other designated name.

The user principal name format is the user name, the “@” character, plus a user principal name suffix. For example, the user James Smith, who has a user account in the reskit.com domain, might have the user principal name JSmith@reskit.com. The user principal name is independent of the distinguished name of the user object, so a user object can be moved or renamed without affecting the user logon name.

The user principal name is an attribute (userPrincipalName) of the security principal object, just like a phone number or description. If a user object’s userPrincipalName attribute has no value, the user object has a default user principal name of userName@DnsDomainName.

If you create no other user principal name, the user principal name suffix for a security principal is the domain in which the account is created (for example, @reskit.com). You can create additional user principal name suffixes and assign them to security principal accounts if you don’t want to use the default domain name (for example, if the DNS domain name is extremely long and hard to remember). The e-mail name can also be used as the user principal name suffix. For example, in a large organization that has many domains, a user’s e-mail address might be simply userName@companyName.com.

You can manage user principal name suffixes for a domain in the Active Directory Domains and Trusts MMC snap-in. To add or remove a user principal name suffix, open the properties for the Active Directory Domains and Trusts node. user principal names are assigned at the time a user or group is created. If you have created additional suffixes for the domain, you can select from the list of available suffixes when you create the user or group account. The suffixes appear in the list in the following order:

  • Alternate suffixes. If you have created additional suffixes, the last one you created appears first.
  • Root domain.
  • The current domain.


Domain Controllers

A domain controller is a computer that is running Windows 2000 Server and hosts Active Directory. Domain controllers run the KDC service, which is responsible for authenticating domain user logons. A domain controller stores Active Directory partitions. Partitions, or naming contexts, correspond to distributed segments of Active Directory that are replicated as discrete units. These segments correspond to the following naming contexts:

  • A domain, of which there can be many in a given forest/directory.
  • The directory schema, of which there is one in a given forest/directory.
  • The Configuration container, of which there is one in a given forest/directory.

In addition to the domain partition for which it is authoritative, every domain controller stores a replica of the Schema naming context and the Configuration naming context. (For more information about naming contexts, see “Active Directory Data Storage and Name Resolution” in this book.)

Multimaster Operations

A given domain can deploy many domain controllers, and all domain controllers can accept Active Directory changes. Earlier versions of Windows NT used multiple domain controllers, only one of which was allowed to update the directory database. This single-master scheme required all changes to be replicated from the primary domain controller to the backup domain controllers.

In Windows 2000, every domain controller receives changes, and the changes are replicated to all other domain controllers. The day-to-day operations that are associated with managing users, groups, and computers are typically multimaster operations, that is, changes to these objects can be made on any domain controller. There are some operations, however, that are not performed as multimaster operations because they must occur at only one place and time. For these operations, there are specially designated domain controllers that manage the operations singly.

Single-Master Operations

Most operations can be made at any domain controller and the effects of these operations (for example, deleting a user object) are replicated to all other domain controllers because all domain controllers store replicas of the same set of directory partitions. However, there are certain operations that must occur at only one domain controller. Examples of these operations include the following:

  • Relative ID Pool Allocation

    One domain controller is responsible for assigning “pools” of relative identifiers to other domain controllers. Relative identifiers are identifiers that are used in association with a domain identifier to make up the SID for each security principal created in Active Directory. To ensure uniqueness in a forest, relative identifiers are assigned by a single domain controller from a single pool of relative identifiers.

  • Schema Modification

    Changes to the same schema objects on different domain controllers can result in an inconsistent directory schema and corrupt data. For this reason, directory schema changes are single-master operations.

  • Primary Domain Controller Election

    For compatibility with Windows NT 3.51–based and Windows NT 4.0–based servers, which can operate as backup domain controllers in a Windows 2000 domain but still require a primary domain controller, a specific Windows 2000–based domain controller takes on the role of the primary domain controller. The domain controller is a Windows 2000–based domain controller, but it is perceived by the Windows NT 3.51–based and Windows NT 4.0–based servers as a primary domain controller. There can be only one primary domain controller per domain, so the performance of this role is a single-master operation.

    For information about upgrading Windows NT 3.51 and Windows NT 4.0 domains to Windows 2000 domains, see “Determining Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide.

  • Certain Infrastructure Changes

    When objects are moved or deleted, a single domain controller must keep track of references to the object.

  • Domain Naming

    A single domain controller is responsible for ensuring that domain names are unique in the forest and that cross-reference objects to external directories are maintained.

    The domain controllers that are assigned to manage single-master operations are called flexible single-master operations (operations master, pronounced “fizmo”) role owners. (For more information about managing single-master operations, see “Managing Active Directory” in this book.)


Organizational Units

Active Directory allows administrators to create a hierarchy within a domain that meets the needs of their organization. The object class of choice for building these hierarchies is organizationalUnit, a general-purpose container that can be used to group most other object classes together for administrative purposes. An organizational unit in Active Directory is analogous to a directory in the file system; it is a container that can hold other objects.

Administrative Hierarchy

Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users, groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy within a domain is independent of the structure of other domains; each domain can implement its own hierarchy. Likewise, domains that are managed by a central authority can implement similar organizational unit hierarchies. The structure is completely flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is centralized or decentralized.

Organizational units can accommodate separate administration of internal areas of the organization, or they can accommodate the management of remote offices that have neither the hardware nor support resources to maintain a separate domain. By nesting organizational units, you can also provide an organizational hierarchy that accommodates promoting organizational units to domains in the future, if such a need arises.

Group Policy

Group policy can be applied to organizational units to determine the abilities of groups of computers and users contained within the organizational units. Levels of control range from complete desktop lockdown to a relatively autonomous user experience. Group policies are applied at every logon and affect functionality, such as what applications are available to a group of users, what features within an application are accessible on a given computer, where documents are saved, the access and user permissions, or where, when, and how application and operating system updates or special scripts are applied.

Policies are stored as Group Policy objects in Active Directory, and a Group Policy object can be associated with one or more Active Directory containers, such as a site, a domain, or an organizational unit.

For more information about Group Policy, see “Introduction to Desktop Management” and “Group Policy” in this book. For information about planning and implementing an organizational unit hierarchy, see “Designing the Active Directory Structure” in the Deployment Planning Guide.

Delegation of Control

The Windows 2000 object-based security model implements default access control that is propagated down a given subtree of container objects. You use this technology to determine the security for an entire group of objects according to the security that you set on the organizational unit that contains the objects, which effectively delegates administrative control to individuals in the organization. The best way to take full advantage of delegation and inherited control on directory objects is to organize the hierarchy to match the way the directory is administered.

Note

Because Active Directory is indexed, there is no need to organize the tree for ease of browsing, which is likely to run counter to administrative objectives.

Control over directory objects can be applied to organizational units through access control (delegation). There is a security descriptor called an access control list (ACL) that is present on every Active Directory object. Use the Delegate Control command in the context menu of an organizational unit to set the access limits for appropriate groups or individual users. (For more information about access control, see “Access Control” in this book.)

Nesting and Object Retrieval

As stated earlier, organizational units are nested to create a hierarchy, and a hierarchy can be useful for delegating administration through ACLs and for setting Group Policy for a given segment of the domain.

However, a deep object-hierarchy increases the cost of searching — the deeper the hierarchy, the longer it takes to process the name and retrieve the object. Along the same lines, deeply nested groups increase the cost of obtaining the group SIDs that are required at logon for Universal groups and Global groups in the user’s logon domain and at resource connection time for Global groups outside the user’s logon domain. (For more information about nesting of organizational units, see “Designing the Active Directory Structure” and “Determining Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide.)


Object Security

Authentication of user accounts determines that the user who logs on to a Windows 2000 domain is who the user claims to be and that the user does indeed have an account either in the domain or in a domain that is trusted. After the user is authenticated, however, Active Directory must provide security to determine what objects the authenticated user can view or change and what kinds of changes are allowed. This type of security is achieved through access control.

Note

The information presented here is provided as a security overview in the context of understanding basic Active Directory functionality. For more information about Active Directory security, see the chapters under “Distributed Security” in this book.

Access Control

All Active Directory objects are protected by an ACL. ACLs determine who can see the object and what actions each user can perform on the object. The existence of an object is never revealed to a user who is not allowed to see it.

An ACL is a list of Access Control Entries that are stored with the object the ACL protects. In Windows 2000, an ACL is stored as a binary value called a security descriptor. Each Access Control Entry contains a SID that identifies the principal (the user or group) to whom the Access Control Entry applies and also information about what type of access the Access Control Entry grants or denies.

ACLs on Active Directory objects contain Access Control Entries that apply to the object as a whole and Access Control Entries that apply to the individual attributes of the object. This structure allows an administrator to control not just which users can see an object, but what properties those users can see. For example, all users might be granted read access to the e-mail and telephone number attributes for all other users, but the security properties of users might be denied to all but members of a special security administrators group. Individual users might be granted write access to personal attributes such as the telephone and mailing addresses on their own user objects.

For more information about access control, see “Access Control” in this book. For more information about built-in object security, see “Active Directory Data Storage and Name Resolution” in this book.

Delegation

Delegation is one of the most important security features of the Active Directory. Delegation allows a higher administrative authority to grant specific administrative rights for containers and subtrees to individuals and groups. This eliminates the need for domain administrators with sweeping authority over large segments of the user population.

Access Control Entries can grant specific administrative rights on the objects in a container to a user or group. Rights are granted for specific operations on specific object classes via Access Control Entries in the container’s ACL. For example, to allow the user James Smith to be an administrator of the Corporate Accounting organizational unit, you add Access Control Entries to the ACL on Corporate Accounting as follows:

“James Smith”;Grant;Create, Modify, Delete;Object-Class User
“James Smith”;Grant;Create, Modify, Delete;Object-Class Group
“James Smith”;Grant;Write;Object-Class User;Attribute;Password

Now James Smith can create new users and groups in Corporate Accounting and set the passwords on existing users, but he can neither create any other object classes nor affect users in any other containers (unless, of course, he is granted that access by Access Control Entries on the other containers).

For more information about delegation, see “Access Control” in this book.

Inheritance

Inheritance allows you to propagate a given Access Control Entry from the container where it was applied to all children of the container. Inheritance can be combined with delegation to grant administrative rights to a whole subtree of the directory in a single operation. (For more information about inheritance, see “Access Control” in this book.)


The Active Directory Schema

A schema contains the definitions for the universe of objects that can be stored in a directory and enforces the rules that govern both the structure and content of the directory. Active Directory™, the directory service included with Microsoft® Windows® 2000 Server, extends the features of previous Windows-based directory services and adds entirely new features. One powerful new feature is the ability to dynamically extend the schema, which means that an application can extend the schema with new attributes and classes and use the extensions immediately.

In This Chapter

Introduction to the Active Directory Schema

Location of the Schema

Active Directory Schema Objects

The Schema Cache

Extending the Schema

Related Chapters in the Resource Kit

  • For an overview of the Active Directory physical structure, see “Active Directory Data Storage and Name Resolution” in this book.
  • For more information about Active Directory tools, see “Managing Active Directory” in this book.
  • For information about extending the schema with service publication, see “Publishing Services Within Active Directory” in this book.


Introduction to the Active Directory Schema

Definitions exist for every class of object that Active Directory recognizes. The base schema that ships in Windows 2000 contains all of the object classes and attribute definitions used by Windows 2000 and Windows 20000 components. For each object class, the schema defines mandatory and optional attributes, the additional attributes it might have, and what object class can be a parent of the current object class. Each object stored in the directory is an instance of one class in the schema. Therefore, a class in the schema defines the type of object that can be present in the directory. For example, the schema contains a class called User. Sue and Mary can be two objects in the directory that are instances of the class User.

A class defines a discrete type of object that can be stored in Active Directory. Every object is an instance of one structural class defined in the schema. A class also defines the attributes for an object of that class and specifies what attributes are mandatory and what attributes are optional. User, Computer, and printQueue are all examples of classes.

Attributes define properties — the types of information that an object can hold. For example, the schema contains an attribute called phoneNumber. The object Mary might contain the attribute phoneNumber with the value 4258828080.

The schema also contains syntax objects that determine what data type an attribute can have. Active Directory defines a set of standard syntax objects that can be used uniformly across namespaces. These predefined syntaxes do not actually appear in the directory, and you cannot add new syntaxes. Syntaxes define the type of value an attribute can have. For example, the attribute phoneNumber can be defined to take values of syntax String(numeric), which means that the value can only contain the digits 0 through 9.

The Active Directory schema is represented by a set of objects known as schema objects. Corresponding to every class and to every attribute in the schema, there is an object that specifies the class or the attribute. There are two classes of schema objects:

  • classSchema objects
  • attributeSchema objects

For each class in the schema, there is a classSchema object that specifies the class; for each attribute in the schema, there is an attributeSchema object that specifies the attribute. The classSchema object that corresponds to a class specifies various attributes of the class and, among other things, describes the following constraints on objects that are instances of this class:

  • The mandatory attributes that must be present on any object that is an instance of this class (mustContain attributes).
  • The list of attributes (mayContain attributes) that, in addition to the mustContain attributes, can be found on an object that is an instance of this class. An object can have only attributes that belong to either the mustContain or the mayContain list of the class.
  • Hierarchy rules that determine the possible parents in the directory tree of an object that is an instance of the class.

Administrators and applications can extend the schema by adding new attributes and classes or modifying existing ones. Schema definitions are required by applications that need to create or modify objects in Active Directory. Applications that are “directory-enabled” are programmed to recognize the attributes and syntaxes that are required to interact with the directory. Storing the schema in the directory has many advantages. For example, user applications can read it to discover what objects and properties are available.


Location of the Schema in Active Directory

The objects stored in Active Directory are arranged in a hierarchy called the Directory Tree. Active Directory ships with a preconfigured directory that contains the information required to install and run Windows 2000 and Active Directory ( commonly referred to as the base DIT). The base DIT is the directory that is installed during a fresh install of a Windows 2000 domain controller. One section of the base DIT is the base schema. The directory tree is divided into naming contexts. An Active Directory naming context is a tree of directory objects that forms a unit of replication.

The Schema container, which is also a naming context, is a child of the Configuration container. It contains all of the class and attribute definitions that are required to create and locate objects in Active Directory. The Schema container is in the schema naming context, which is replicated to all domain controllers in the forest. The Configuration container is a naming context that is also replicated to every domain controller in the forest. A container is a special type of Active Directory object that contains other objects.

Note

The schema is a naming context in its own right to prevent potential dependency problems that can arise because of the way directory objects are replicated. For more information on the schema naming context and why the schema is a separate naming context, see “Active Directory Data Storage and Name Resolution” in this book.

Every Active Directory object can be referenced by a unique and unambiguous name known as the Distinguished Name (DN). The distinguished name identifies the domain that holds the object as well as the complete path through the container hierarchy by which the object is reached.

The distinguished name of the Schema container can be expressed as follows:

cn=schema,cn=configuration,DC=<domain-name>,DC=<domain-root>

The diagram in Figure 4.1 illustrates the location of the Schema container in Active Directory.

Figure 4.1 Location of the Schema Container


Finding the Schema Container

The Schema container contains all of the class and attribute definitions that are required to create objects and browse objects in Active Directory. The Schema container (cn=schema,cn=configuration,dc=<domainName>,dc=<domainName>) does not appear in the Configuration container, but the schema naming context contents are viewable using the Active Directory Schema snap-in. You can also bind to the schema naming context and view schema objects using the ADSI Edit snap-in or the LDP tool. (For information about the LDP tool, see “Managing Active Directory” in this book.)

It is possible to locate the Schema container without knowing the domain name. Installation scripts and other applications that might not know what domain they are to be used in are able to gain access to the schema because they bind to a special entry at the top of the logical namespace called rootDSE, which provides the schema location The rootDSE (DSA-specific Entry) represents the top of the logical namespace for one domain controller and, therefore, the top of the LDAP search tree. The attributes of rootDSE identify, among other things, the naming contexts specific to one domain controller — that is, the domain, schema, and configuration naming contexts — as well as the forest root domain naming context. One attribute, schemaNamingContext provides, the location of the schema so that applications connecting to any domain controller can find and read the schema. (For more information about the rootDSE, see, “Active Directory Data Storage and Name Resolution.” located in this book.)

To identify the Schema naming context using ADSI Edit

  1. Start the ADSI Edit snap-in.
  2. Right-click ADSI Edit, and then click Connect to.

    The Connection dialog box is displayed.

  3. In the Connection Point box, make sure Naming Context is selected.
  4. Select RootDSE from the Naming Context box, and then click OK.
  5. In the left pane, double-click My Connection.

    The RootDSE folder is displayed.

  6. Right-click the RootDSE folder, and then click Properties.
  7. From the Select property to view box, select schemaNamingContext from the list of properties.
  8. View the Value(s) box to see distinguished name of the schema naming context.

Note

ADSI Edit is not one of the default snap-ins that is provided with Windows 2000 Server. To make it appear in the list of available snap-ins, you must first copy the Adsiedit.dll file from the \Support folder on the Microsoft® Windows® 2000 Server Resource Kit companion CD to your %systemroot%\System32 folder and then run regsvr32 on the DLL from a command prompt or the Run command on the Start menu.


Subschema Subentry

The rootDSE also carries a mandatory attribute called the subSchemaSubEntry. Its value is the distinguished name of a subSchema object in the directory in which the server makes available attributes (in attributeTypes) and classes (in objectClasses) that specify the schema. This special object, an instance of the unique subSchema class, is used for administering information about the schema, in particular the object classes and attribute types that are supported. This enables client applications to retrieve the information by querying the subSchema entry. Clients must only retrieve attributes from a subSchema entry by requesting a base object search of the entry, where the LDAP search filter is "(objectClass=subSchema)". The location of the subschemaSubentry container is as follows:

CN=Aggregate,CN=Schema,CN=Configuration,DC=<DomainName>,DC=<DomainRoot>


Schema Files

Active Directory is implemented on top of an Indexed Sequential Access Method (ISAM) table manager, historically called “Jet.” Windows 2000 has its own version of Jet called the Extensible Storage Engine (ESENT).

The directory database is actually stored in a file named Ntds.dit. The Ntds.dit file contains all of the information stored in Active Directory. It is actually an ESE database that contains the entire schema, the Global Catalog, and all of the objects that are stored in the directory. The location of the Ntds.dit file is an option that is set during the promotion process while you create the directory. The default location for the database and database log files is %systemroot%\Ntds. (For more information about the Ntds.dit file, see “Active Directory Data Storage and Name Resolution” in this book.)

Another file, the Schema.ini initialization file contains the information that is necessary for creating the default directory objects and the default security for the DIT, as well as the Active Directory display specifiers. For information about display specifiers, see “Managing Active Directory” in this book. Although this file is named Schema.ini, the schema itself is actually preloaded and is contained in the base version of Ntds.dit that is installed by the Active Directory Installation wizard.


Active Directory Schema Objects

The attributes and classes in Active Directory are stored in the Schema container as directory objects called schema objects. The Schema container itself is represented in Active Directory by an object that is an instance of the Directory Management Domain (dMD) class. dMD is an X.500 class for data that pertains to the authoritative domain for an enterprise.

Attributes are defined by attributeSchema objects and classes are defined by classSchema objects. Therefore, every class is actually an instance of the classSchema class, and every attribute is an instance of the attributeSchema class. For a complete listing of Active Directory attributes and classSchema objects, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Develop Kit (SDK) documentation about Active Directory. Search for MSDN at http://microsoft.com.


Attribute-Schema Objects

Attributes are data items used to describe the classes defined in the schema. They are defined in the schema separately from the classes, which allows a single attribute definition to be applied to many classes.

Attributes are attributeSchema objects. The attributeSchema object lists the following:

  • The name of the attribute.
  • The LDAP display name of the attribute.
  • The object identifier for the attribute.
  • The globally unique identifier (GUID) for the attribute.
  • The syntax of the attribute.
  • The range for the attribute. For integers, range defines the minimum and maximum value; for strings, range defines the minimum and maximum length.
  • Whether the attribute is multivalued. Note that multivalued attributes hold a set of values with no particular order. There is no guarantee that multivalued properties are ever going to be returned in the order in which they were stored (or in any other order).
  • Whether and how the attribute is indexed.

Each attributeSchema object is an instance of the attributeSchema class. Object attributes for the attributeSchema class are described in Table 4.1.

Table 4.1 Attributes for the attributeSchema Class

Attribute
Syntax
Mandatory? 		Multi-valued?
Description
cn | Unicode1 | Yes | No | Descriptive relative distinguished name (RDN).
attributID | object identifier | Yes | No | object identifier that uniquely identifies this attribute.
lDAPDisplayName | Unicode | No | No | Name by which LDAP clients identify this class.
schemaIDGUID | String(Octet) | Yes | No | GUID that uniquely identifies this attribute.
mAPIDisplayType | Integer | No | No | Integer by which Messaging Application Programming Interface (MAPI) clients identify this attribute.
attributeSecurityGUID | GUID | Yes | No | GUID by which the security system identifies the property set of this attribute.
attributeSyntax | object identifier | Yes | No | Syntax object identifier of this attribute.
oMSyntax | Integer | Yes | No | Syntax of this attribute as defined by the XAPIA XOM (X/Open Object Model) specification.
isSingleValued | BOOL | Yes | No | Indicates whether this attribute is single-valued or multivalued. Note that multivalued attributes hold a set of values with no particular order. There is no guarantee that multivalued properties are ever going to be returned in the order in which they were stored (or in any other order).
extendedCharsAllowed | BOOL | Yes | No | Indicates whether extended characters are allowed in the value of this attribute. Only applies to attributes of syntax String (Teletex).
rangeLower | Integer | No | No | Lower range of values allowed for this attribute.2
rangeUpper | Integer | No | No | Upper range of values allowed for this attribute.2
searchFlags Integer No No The four currently defined bits for this attribute are as follows: 1 = Index over attribute only; 2 = Index over container and attribute;
4 = Add this attribute to the Ambiguous Name Resolution (ANR) set (should be used in conjunction with 1);
8 = Preserve this attribute on logical deletion (that is, make this attribute available on tombstones).
systemOnly | BOOL | Yes | No | If TRUE, only the system can modify this attribute. No user-defined attribute should ever have this flag set.
objectClass | object identifier | Yes | Yes | Class of this object, which is always attribute Schema.
nTSecurityDescriptor | NT-Sec-Des | Yes | No | Security descriptor on the attributeSchema object.
oMObjectClass | String(Octet) | No | No | For object-syntaxed attributes (oMSyntax = 127), a binary value that describes the type of object.
linkID Integer No No Whether a linked-attribute or not, an even integer denotes a forward link, an odd integer a back link

A forward link is a pointer to another object in the directory; a back link points back to the first object that has a forward link to it. (For more information about links, see “Active Directory Data Storage and Name Resolution” in this book.)

1. Unicode is a 16-bit character set that contains all of the characters commonly used in information processing.

2. When rangeLower and rangeUpper are defined for attributes that are integers, they define the limits of the value held by the attribute. When they are defined for attributes that are strings, they define the number of characters that can be held in the string.

System and Changeable Attribute Pairs

Some aspects of a class-definition object are contained in pairs of attributes, where the value of one of these attributes can be changed by administrators and the other not. These attribute pairs are mustContain/systemMustContain, mayContain/systemMayContain, possSuperiors/systemPossSuperiors, and auxiliaryClass/systemAuxiliaryClass.

In each of these pairs, the value of the attribute that begins with the word system-cannot be changed by administrators. This enables Active Directory to protect certain key attributes of certain classes and ensure that the schema stays consistent and usable. System only properties can only be changed by the Directory System Agent (DSA). System only properties are those properties on which Windows 2000 and Active Directory depend for normal operations. For example, the attributeID and governsID attributes in the schema are system-only attributes.

The value of the other (nonsystem) attributes in each pair can be changed by administrators.

Mandatory Attributes

The term mandatory attributes refers to object attributes for which values must be specified. If you do not specify a value for a mandatory attribute, one of the following happens:

  • The attribute takes on a default value.
  • The object is not created until you specify a value for the attribute.

Which of the object’s attributes are mandatory is determined by the class to which the object belongs.

Some mandatory attributes are inherited. Because every schemaClass object belongs to a subclass called top in the class hierarchy, each schemaClass object inherits the mandatory attributes that belong to top. Table 4.2 is a list of the mandatory attributes that every object inherits from top. To see a graphical representation of the Active Directory class hierarchy, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation. Search for MSDN at http://microsoft.com.

Table 4.2 Mandatory Attributes That All schemaClass Objects Inherit

Inherited Mandatory Attribute | Default Status
instanceType | No default. Administrator must specify.
nTSecurityDescriptor | Defaults if not specified. The default value depends on the default security descriptor for the classSchema class.
objectCategory | Defaults to the value of defaultObjectCategory of the class (which is usually the class itself). Can be changed after the class is created.
objectClass | No default. Administrator must specify the class.

Note

You can view an object’s mandatory attributes by using the Active Directory Schema snap-in. (The attributes are displayed on the Attributes tab in the Properties dialog box.) Because some of an object’s mandatory attributes are inherited from its parent class, you might need to view the attributes of the parent class in order to identify all of the mandatory attributes of your object. The Active Directory Schema snap-in is an Microsoft Management Console (MMC) tool that is provided by Windows to enable administrators to modify the schema using a graphical interface.

Single-Value or Multivalued Attributes

Attributes might be single-valued or multivalued. Single-valued and multivalued attributes are defined by the singleValued attribute being set to TRUE or FALSE. The Active Directory Schema snap-in reports this as "single-valued" or "multivalued" rather than as an attribute-value pair.

A multivalued attribute can contain multiple values, all of uniform syntax. Note that multivalued attributes hold a set of values with no particular order. There is no guarantee that multivalued properties are ever going to be returned in the order in which they were stored (or any other order).

Note

The LDAP protocol reads a multivalued attribute as a single entity. This can be inconvenient or even impossible when the number of values in a multivalued attribute becomes large. An Internet draft titled “Incremental Retrieval of Multivalued Properties” defines an option called Range that can be specified as part of an attribute description to retrieve the values of a multivalued attribute incrementally. Servers might or might not honor the range option. Servers that support the range option include the object identifier 1.2.840.113556.1.4.802 in the supportedControls operational attribute on the rootDSE. Clients should not use the range option unless this object identifier is present. The range option is a constant, case-insensitive string value, "Range=", followed by a range-specifier that lists the initial and terminal values in the range.

Indexed Attributes

Making an attribute indexed means that directory searches involving that attribute are going to be more efficient than if the attribute had no index. Attributes are indexed when the least significant bit in their searchFlags attribute is set to the value 1. Changing the value of the bit to 1 dynamically builds an index; changing the value to 0 or deleting it drops an index for the attribute in question. The index is built automatically by a background thread on the directory server.

Ideally, indexed attributes should be single valued with highly unique values, evenly distributed across the set of instances. Multivalued attributes can be indexed, but the cost to build the index is larger in terms of storage, update, and search time. Even with single-valued attributes, keep in mind that the more indexed attributes a class has, the longer it takes to store instances of the class.


classSchema Objects

A class is a formal description of a discrete, identifiable type of object that can be stored in the directory. Active Directory classes are defined in the schema by other objects called classSchema objects. The classSchema object is essentially a template that contains the “rules” for creating objects in an Active Directory class. When a new object is created in a class, the classSchema object ensures that this new object has the same properties as all other objects in the class. After an object has been created, the object's class can never be changed.

The classSchema object contains the following information:

  • The name of the class.
  • The LDAP display name of the class.
  • The object identifier for the class.
  • The GUID for the class.
  • The attributes that must be present for an instance of the class.
  • Other attributes that can be present for an instance of the class.
  • The classes to which the parent of instances of this class might belong.
  • The superclass from which this class inherits characteristics.
  • Other Auxiliary classes from which this class inherits attributes.
  • The type of class (Abstract, Structural, or Auxiliary).
  • The default hiding state for the class. If you do not want instances of your class displayed by the end-user user interface, you can define the class as hidden by default. Table 4.3 is a list of the attributes a classSchema object can have.

Table 4.3 The Attributes of a classSchema Object

Attribute | Syntax | Mandatory? | Multi-valued? | Description
cn | Unicode | Yes | No | Descriptive relative distinguished name (RDN) for the schema object.
governsID | object identifier | Yes | No | object identifier that uniquely identifies this class.
lDAPDisplayName | Unicode | No | No | Name by which LDAP clients identify this class.
schemaIDGUID | String(Octet) | Yes | No | GUID that uniquely identifies this class.
mAPIDisplayType | Integer | No | No | Integer that defines the set of display templates that MAPI clients use to display objects of this class.
rDNAttID | object identifier | No | No | RDN type of instances of this class (OU, CN).
subClassOf | object identifier | Yes | No1 | The class from which this object inherits attributes.
systemMustContain | object identifier | No | Yes | The list of mandatory attributes for instances of this class. This list cannot be changed.
mustContain | object identifier | No | Yes | The mandatory attributes for instances of this class.
systemMayContain | object identifier | No | Yes | The optional attributes for instances of this class.
mayContain | object identifier | No | Yes | The optional attributes for instances of this class.
systemPossSuperiors | object identifier | No | Yes | The classes that can be parents of this class in the directory hierarchy.
possSuperiors | object identifier | No | Yes | The classes that can be parents of this class in the directory hierarchy.
systemAuxiliaryClass | object identifier | No | Yes | The Auxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes.
auxiliaryClass | object identifier | No | Yes | The Auxiliary classes from which this class inherits its optional (mayContain) and mandatory (mustContain) attributes.
defaultSecurityDescriptor | String(Octet) | No | No | The default security descriptor that is assigned to new instances of this class if no security descriptor is specified during creation of the class.
objectClassCategory | Integer | Yes | No | The class type. Class types are defined as follows: 88 Class = 0; Structural Class = 1; Abstract = 2; Auxiliary = 3.
systemOnly | BOOL | No | No | If TRUE, only the system can create and modify instances of this class.
objectClass | Object | Yes | Yes | This object's class, which is always classSchema.
nTSecurityDescriptor | NT-Sec-Desc | Yes | No | Security Descriptor on the classSchema object.
defaultObjectCategory | DN | No | No | The default object category of new instances of this class if none has been specified.
1 Objects cannot inherit from more than one class using this attribute. Use the Auxiliary Classes attribute to define additional parent classes.

Note

When you look at the attributes in a class-schema object’s must-contain attribute list, you are not seeing the complete set of attributes that must be present for an instance of a class to exist. For example, in the class A, the classSchema object A specifies a list of mustContain attributes that an instance of A must have through the systemMustContain and mustContain attributes. However, because mandatory attributes are also inherited, the complete list of attributes for an instance of class A includes the inherited mustContain attributes from all classes from which A inherits — that is, all classes in the subClassOf and auxiliaryClass list of the classSchema object A. The mayContain attributes for A are also defined this way. The possSuperiors are defined this way as well, except that possSuperiors are inherited only from classes in the subClassOf list, not from the classes in the auxiliaryClass list.

Types of Classes

Different categories of classes allow for defining structure in the directory. Classes of the abstract category have the sole function of providing attributes for subordinate classes, called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is derived, called its superclass, in addition to those specific to the class itself. Likewise, the subclass of that class contains all attributes of both superclasses, and so forth. The four categories of classes are applied as follows:

  • Structural Classes

    Structural classes are the only classes that can have instances in the directory. That is, you can create directory objects whose class is one of the structural classes. A Structural class can be used in defining the structure of the directory and is derived from either an Abstract class or another Structural class. A Structural class can include any number of Auxiliary classes in its definition. This type of class is specified by a value of 1 in the objectClassCategory attribute.

  • Abstract Classes

    Abstract classes are templates that are used only to derive new Structural classes. Abstract classes cannot be instantiated in the directory. This means that no object can belong only to an Abstract class. Each object of an Abstract class also belongs to some non-abstract subclass of that class. A new Abstract class can be derived from an existing Abstract class. This type of class is specified by a value of 2 in the objectClassCategory attribute.

  • Auxiliary Classes

    Auxiliary classes are like "include" files; they contain a list of attributes. Adding the Auxiliary class to the definition of a Structural or Abstract class adds the Auxiliary class's attributes to the definition. An Auxiliary class cannot be instantiated in the directory; but new Auxiliary classes can be derived from existing Auxiliary classes. This type of class is specified by a value of 3 in the objectClassCategory attribute.

    For example, the securityPrincipal class is an auxiliary class, and it derives its attributes from the parent abstract class top. Although you cannot create a security principal object in the directory (because auxiliary classes cannot have instances), you can create an object of the structural class user, which has the securityPrincipal class as an auxiliary. The attributes of the securityPrincipal class contribute to making the user object recognizable to the system as a security account. Similarly, the group class has securityPrincipal as an auxiliary class

  • Classes

    If the category of the class is not specified, it is treated as an 88 class. Class categorization was not present in the X.500 1988 specification, and the X.500 1993 specification requires classes to be one of the explicit categories, that is, object classes are required to be classified as Structural, Abstract, or Auxiliary. Classes defined before 1993 are not required to fall into one of these categories. Classes that have a special category (that of having no category according to the X.500 1993 standards), the 88 class. This type of class is specified by a value of 0 in the objectClassCategory attribute. You should not define new 88 classes.

Note

Active Directory does not return an error for these classes, but simply performs looser semantic checking. For example, an 88 class can be used as an abstract superclass, but it can also be directly instantiated. When you define new schema classes, you should use one of the new X.500 1993-style categories.

Inheritance

Inheritance, which is also referred to as derivation, is the ability to build new object classes from existing object classes. The new object is defined as a subclass of the parent object. Subclass is a classSchema object that inherits from some other classSchema object, for example, a subclass inherits structure and content rules from the parent object. The parent object becomes a superclass of the new object. Superclass is a classSchema object from which one or more other classSchema objects inherit. The inherited information includes mandatory and optional attributes (systemMustContain, mustContain, systemMayContain, and mayContain) and its parent classes in the directory hierarchy (systemPossSuperiors and possSuperiors). The diagram in Figure 4.2 illustrates an object class hierarchy.

Figure 4.2 Object Class Hierarchy

For example, you can specify a Salesperson class that defines information about the salespeople in your company, including specialized information, such as commission rate and travel route. You can specify the Salesperson class as a subClassOf of the User class. This would cause the Salesperson class to inherit all the mandatory and optional attributes and directory-parent classes of the User class after the schema cache is updated. You would not have to define these attributes for each salesperson in your company.

All structural object classes are subclasses, directly or indirectly, of a single abstract object class, which is called top. Every object represented in the directory belongs to top and, as a result, every entry must have an objectClass attribute. When you create a new class, you must specify the superclass: if you are not creating a subclass of an existing class, the new class is a subclass of top.

A new class can inherit mandatory and optional attributes from more than one existing class. However, any additional classes must be specified by the auxiliaryClass attribute.

Note

If you add another attribute later to a class that has subclasses or auxiliary subclasses, the new attribute is automatically added to the subclasses after the schema cache has been updated.

To view a graphical representation of the Active Directory class hierarchy, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation about the Active Directory schema. Search for MSDN at http://microsoft.com.


Syntaxes

The syntax for an attribute defines the storage representation, byte ordering and matching rules for comparisons of property types. This includes whether the attribute value must be a string, a number, a unit of time, and so forth. Every attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined. You cannot add new syntaxes.

When you define a new attribute, you must specify both the attributeSyntax and the oMSyntax numbers of the syntax you want for the attribute. The attributeSyntax and oMSyntax numbers have a special format associated with object identifiers. object identifiers are unique numbers that Active Directory uses to identify every class, attribute, and syntax. The oMSyntax is defined by the XOM (X/Open Object Model) specification. This model provides a relatively fine-grained definition of syntax. For example, there are distinct oMSyntaxes to distinguish among several types of printable strings, according to factors such as the supported character set and whether case is significant. Table 4.4 is a list of the valid syntaxes for attributes in the Active Directory schema.

Table 4.4 Valid Syntaxes for Attributes in the Active Directory Schema

Syntax1 | Attribute Syntax | OM Syntax | ASN 1- Encoded object identifier | Description
Undefined | 2.5.5.0 |  | \x550500 | Not a legal syntax.
Object(DN-Binary) | 2.5.5.1 | 127 | \x550501 | The fully qualified name of an object in the directory.
String(Object-Identifier) | 2.5.5.2 | 6 | \x550502 | The object identifier.
Case-Sensitive String | 2.5.5.3 | 27 | \x550503 | Teletex. Differentiates upper-case and lowercase.
String(Teletex) | 2.5.5.4 | 20 | \x550504 | Teletex. Does not differentiate upper-case and lowercase.
String(Printable), String(IA5) | 2.5.5.5 | 19, 22 | \x550505 | Printable string or IA5-String.
String(Numeric) | 2.5.5.6 | 18 | \x550506 | A sequence of digits.
Object(OR Name) | 2.5.5.7 | 127 | \x550507 | An X400 mail address.
Boolean | 2.5.5.8 | 1 | \x550508 | TRUE or FALSE values.
Integer, Enumeration | 2.5.5.9 | 2, 10 | \x550509 | A 32-bit number or enumeration.
String(Octet), Object(Replica-Link) | 2.5.5.10 | 4, 127 | \x55050A | A string of bytes.
String(UTC-Time), String(Generalized-Time) | 2.5.5.11 | 23, 24 | \x55050B | Elapsed seconds because 1/1/1610. UTC Time or Generalized-Time.
String(Unicode) | 2.5.5.12 | 64 | \x55050C | Unicode string.
Object(Presentation-Address) | 2.5.5.13 | 127 | \x55050D | Presentation Address.
Object(DN-String) | 2.5.5.14 | 127 | \x55050E | DN String.
String(NT-Sec-Desc) | 2.5.5.15 | 66 | \x55050F | A Windows NT Security descriptor.
LargeInteger | 2.5.5.16 | 65 | \x550510 | A 64-bit number.
String(Sid) | 2.5.5.17 | 4 | \x550511 | SID.
1The oMSyntax names are specified against the syntax numbers to enable correct choice.

Note

A complete syntax specification consists of both the attribute-syntax and the oMSyntax. Wherever more than one oMSyntax can be used with an attribute-syntax, the correct oMSyntax must be used.


Object Identifiers

object identifiers are unique numeric values that are granted by various issuing authorities to identify data elements, syntaxes, and other parts of distributed applications. Because they are globally unique, object identifiers ensure that the objects that are defined by these issuing authorities do not conflict with one another when separate directories, such as Active Directory and Novell Directory Services (NDS), are brought together in a global directory.

object identifiers are found in Open Systems Interconnection (OSI) applications, X.500 directories, Simple Network Management Protocol (SNMP), and other applications in which uniqueness is important. object identifiers are based on a tree structure in which a superior issuing authority allocates a branch of the tree to a subordinate authority, which in turn allocates sub-branches of the tree.

LDAP requires a directory service, like Active Directory, to identify object classes and attributes with an object identifier syntax. The object identifier is the value for the governsID attribute in a class-schema object and for the attributeID attribute in an attributeSchema object. These are required attributes; therefore, object identifiers are necessary when you create new classes or attributes.

object identifiers in the Active Directory base schema include some issued by the ISO for X.500 classes and attributes and some issued by Microsoft. object identifier notation is a dotted string of non-negative numbers (for example 1.2.840.113556.1.5.4), the components of which are shown in Table 4.5.

Table 4.5 Components of a Sample object identifier (1.2.840.113556.1.5.4)

Numerical Values of the Sample object identifier | What the Numerical Values Denote
1 | ISO ("root” authority) issued 1.2 to ANSI, which in turn . . .
2 | ANSI issued 1.2.840 to USA, which in turn . . .
840 | USA issued 1.2.840.113556 to Microsoft, which . . .
113556 | Microsoft internally manages several object identifier branches under 1.2.840.113556 that include . . . .
1 | Active Directory a branch called Active Directory that includes . .
5 | Classes a branch called Classes that includes . . . .
4 | Builtin-Domain a branch called Builtin Domain.

object identifiers ensure that every object is interpreted appropriately, just as, for example, a telephone number is not mistaken for an employee number. A series of widely used objects and attributes is standardized for use in object identifiers. New object identifiers are issued by standards authorities, and they form a hierarchy below which new object identifiers can be managed internally. An object identifier is represented as a dotted decimal string (for example, 1.2.3.4). Enterprises (and individuals) can obtain a root object identifier from an issuing authority and use it to allocate additional object identifiers internally. For example, Microsoft Corporation has been issued the root object identifier 1.2.840.113556. Microsoft manages further branches from this root internally. One of these branches is used to allocate object identifiers for Active Directory classes, another for Active Directory attributes, and so forth.

Most countries in the world have an identified National Registration Authority (NRA) responsible for issuing object identifiers to enterprises. In the United States, the NRA is the American National Standards Institute (ANSI). The NRA issues root object identifiers. An enterprise can register a name for the object identifier as well. There is a fee associated with registering the root object identifiers and registered names. Contact the NRA for your country for details. The International Standards Organization recognizes NRAs and maintains a list of contacts on their Web site. You can also obtain object identifiers from Microsoft by sending mail to object identifierS@microsoft.com.

The issuing authority assigns an object identifier space that is a branch of the ISO-ITU object identifier tree. Assume that your company is assigned the space 1.2.840.111111. You can extend this space internally as you want (within constraints of the structure of an object identifier). For example, you can subdivide this space further (by appending dotted decimals to the object identifier root) and assign these subspaces to various divisions within your company. Each division, in turn, can further subdivide the subspace allotted to it. Using the sample object identifier 1.2.840.111111, your company could have the subspace 1.2.840.111111.1.4 for attributes and 1.2.840.111111.1.5 for classes. An internal issuing authority within the company, using an Administrator account, could then allocate object identifiers from this space on request. The governsID attribute on every classSchema object and the attributeID attribute on every attribute schema object are mandatory attributes that contain an object identifier string. In this example, all of your company-created class-schema objects have a governsID of the form 1.2.840.111111.1.5.x, where x is a decimal number. Similarly, all of your company-created attributeSchema objects have an attributeID of the form 1.2.840.111111.1.4.x.


Structure and Content Rules

The schema enforces rules that govern both the structure and the content of Active Directory. When you add, delete, or modify objects, validation takes place using these schema rules to insure the integrity of the directory. Structure rules define the possible tree structure(s). When you create a new object, structure rules determine the validity of the object class to which you designate that it belongs. You cannot create an object that belongs to a nonexistent class. You must first create the new class. Conversely, these rules do not allow you to delete or modify an object that has already been deleted In Active Directory the structure rules are completely expressed by the possSuperiors attribute that is present on each classSchema object. This attribute specifies the possible classes from which this class can inherit attributes.

Content rules determine the mandatory and optional attributes of the class instances that are stored in the directory. New objects must contain all of the mandatory attributes that are specified by the classSchema object in the schema and can contain none or more of the optional attributes. In Active Directory, the content rules are completely expressed by the mustHave and mayHave attributes of the schema definitions for each class.


The Schema Cache

All changes made to Active Directory are validated first against the schema. For performance reasons, this validation takes place against a version of the schema that is held in memory on the domain controllers. This “in-memory version,” called the schema cache, is updated automatically after the on-disk version has been updated. The schema cache provides mapping between attribute identifiers such as database column identifier, attribute identifier, and MAPI identifier and in-memory structures that describe those attributes. The schema cache also provides lookups for class identifiers to get in-memory structures describing those classes.

The schema cache consists of ATTCACHE and CLASSCACHE structures, one for each class and attribute, respectively, in the schema. The cache is a set of hash tables of ATTCACHE and CLASSCACHE structures with lookups that are based on either the attributeID, lDAPDisplayName, or mAPIID attributes for attributeSchema objects and by the governsID or lDAPDisplayName attributes for classShema objects. The schema cache table sizes are dynamic. After the first schema cache load when the server is started, the system keeps a running count of the number of attributes and classes in the schema and uses this count to decide whether the schema cache table sizes need to be dynamically increased.

When the computer is started, the schema cache is loaded from the underlying database and updated automatically after the on-disk version has been updated. When changes are made to the schema, the schema cache is automatically updated 5 minutes after the first change was applied. Applying another change to the schema during the 5-minute interval resets the timer for another 5 minutes. During this interval before the schema updates are copied to the schema cache, objects that reference a new or modified class or attribute cannot be added. This behavior keeps the cache consistent, but it can be confusing because changes do not "appear" in the schema until the cache is updated, even though they were applied on disk.

There is also a mechanism for updating the schema cache on demand. You would use this when you modify the schema. You can add the schemaUpdateNow attribute to the rootDSE with value of 1. The rootDSE is a DSA-specific entry that holds the attributes that pertain to the local domain controller, such as naming contexts, server name, and supported LDAP version numbers. The schemaUpdateNow attribute is defined as an operational attribute. An operational attribute is an attribute used only for administering the directory server itself. It is an artifact attribute that is never defined in the schema and does not require any storage. Generally, when you set an operational attribute, you trigger some immediate action on the server.

Adding the schemaUpdateNow attribute causes a schema cache update to start immediately. The call is blocking, which means that if the call returns with no error, the cache is updated and all schema updates are ready to be used. An error return, however, indicates that the cache update is not successful. Applications that want to take advantage of this feature should be designed to accommodate the blocking write, particularly in giving the user feedback, if the program or script executes interactively.

When the schema cache is updated, a new cache is actually built from the schema database, however the old cache remains in memory to serve existing program threads. When the new cache is built, any new threads refer to it, and existing threads continue using the old cache until they have completed.

Important

It is recommended that you force an immediate schema cache update only once and that after all required schema updates are finished. If multiple cache updates occur, it is possible to have multiple versions of the schema cache in memory at once, which would cause a temporary memory drain on the server.


Extending the Schema

When the existing class and attribute definitions in the schema do not meet the needs of your organization, the schema can be extended by adding or modifying schema objects. The Active Directory schema can be extended dynamically. That is, an application can extend the schema with new attributes and classes and use the extensions immediately. Schema updates are accomplished by creating or modifying the schema objects that are stored in the directory. This allows you to make the objects that are meaningful to your organization available throughout the enterprise.

Note

As is true for every object in the Active Directory, schema objects are protected by Access Control Lists (ACLs), so only authorized users can alter the schema. (For more information about ACLs , see “Authentication” in this book.)

Adding or modifying class or attribute definitions in the schema involves adding or modifying the corresponding classSchema or attributeSchema object. The operations involved are similar to adding or modifying any object in Active Directory, except that additional checks are performed to ensure that the changes do not cause inconsistencies or problems in the schema in the future.


When to Extend the Schema

You should modify the schema only when absolutely necessary. Schema modifications cannot be reversed, so you need to make sure they are planned and well thought out before they are implemented. Modifying the schema is a major event, with implications throughout the directory. Improper schema modifications can have serious consequences.

It is imperative that you make schema modifications only after you have completed thorough planning and preparation. Inconsistencies in the schema can cause significant problems that impair or disable Active Directory. These problems might or might not be evident immediately.

Planning for schema modification involves examining the default schema that comes with Active Directory to verify that there is no way to use the existing classes or attributes for your needs. It is then necessary to understand the types of modifications that can be made and, conversely, what cannot be changed. The following are the modifications that can be made to the schema:

  • Creating classes.
  • Modifying existing classes.
  • Creating attributes.
  • Modifying existing attributes.
  • Deactivating classes and attributes.

The most likely modification you might need is adding a new class. There are three ways to effectively add a new class:

  • Extend an existing class by adding attributes or additional possible parents.
  • Derive a new subclass from an existing class. The subclass has all the attributes of the original class and any additional attributes you specify.
  • Create an entirely new class with any attributes you want.

You should extend an existing class when the following conditions apply:

  • The existing class needs additional 0attributes but otherwise meets your needs. For example, you might want to add a purchasingLimit attribute to the User class and add it to the user object for people who are cost center managers and have purchasing authority.
  • You have no need to identify the extended class as a distinct class from the original class.
  • You want to use the existing Active Directory Manager snap-in to manage the extended attributes of the objects. This requires the addition of property pages to the set defined for the object you are extending.

You should derive a subclass from an existing class when the following conditions apply:

  • The existing class needs additional attributes but otherwise meets your needs.
  • You do want to identify the extended class as a distinct class from the original class.
  • You want to use the existing Active Directory Manager snap-in to manage the extended attributes of the objects.

Note

One exception is the User class. It is almost always better to extend the class rather than to derive a subclass because you cannot alter the class of an object after it has been created. Therefore, existing users can never be changed to the new subclass, and instances of the subclass can never be changed back into "standard" users. You should create a class only when no existing class meets your needs.


How to Extend the Schema

After you have decided that you have to make changes to the schema and you have carefully planned the types of changes you are going to make, you can proceed. Because this is an extremely significant operation, and not without the possibility of causing serious problems, Windows 2000 has three safety features, or interlocks, that control modification of the schema:

  • By default, schema modification is disabled on all domain controllers. To enable schema modification at a particular domain controller, use the Active Directory Schema snap-in on a domain controller to permit write access to the schema on that domain controller.
  • The schema object is protected by the Windows 2000 Security model. Therefore, administrators must be given explicit permissions or be a member of the Schema Administrators group (Schema Admins in the UI) to effect changes to the schema.
  • Only one domain controller in the enterprise, the one holding the Schema Master Role, is allowed to write to the schema. This role is one example of a Flexible Single Master Operation (operations master) role.

Modifying the Schema

To allow a domain controller to modify the schema, use the Active Directory Schema snap-in on the selected server.

Note

Because of the serious nature of schema modification, the Active Directory Schema snap-in is not listed with the default snap-ins provided with Windows 2000 Server. To make it appear in the list of available snap-ins, you must run regsvr32 on the DLL (Schmmgmt.dll) from a command prompt or the Run command on the Start menu.

To enable schema modification

  1. Start the Active Directory Schema snap-in.
  2. Right-click Active Directory Schema (Manager), and select Operations Master.
  3. Select The Schema may be modified on this server checkbox.
  4. Click OK.

The value of the The Schema may be modified on this server checkbox option is stored in the registry in the Schema Update Allowed entry (in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters). Active Directory adds this entry to the registry when you use the snap-in to change the default value. Whenever possible, use the Active Directory Schema snap-in to change the value of this entry. Do not edit the registry.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

The Schema Administrators Group

To modify the schema, you must use an account that is a member of the Schema Administrators group. By default, the only member in that security group is the Administrator account in the root domain of the enterprise. If you want to add other accounts, you have to add them explicitly. It is important to use discretion when adding accounts to the Schema Administrators group, because improper schema modifications can have serious consequences.

Caution

Membership in the Schema Administrators group should be highly restricted to prevent unauthorized access to the schema.

One way to verify that an account is a member of the Schema Administrators group is to use the Active Directory Users and Computers snap-in.

To verify that an account is a member of Schema Administrators

  1. Start the Active Directory Users and Computers snap-in.
  2. Expand the domain for the account by clicking the plus (+) sign next to it.
  3. Double-click the Users folder.
  4. Double click the Schema Admins security group, and then click the Members tab.
  5. If the account is not listed under Members, add it by clicking Add.
  6. Select an account from the displayed list, or type its name.
  7. Click Add, and then click OK.

The Schema operations master Role

Although Active Directory is based on a multimaster administration model, certain operations must be performed on only one server at a time. Schema management is one of those operations because simultaneous schema updates at two different machines could conflict with each other. The one domain controller in the enterprise that is allowed to perform schema updates at any given time is referred to as the schema master.

Note

To update the schema, the domain controller holding the schema master role must be online.

You can change the domain controller that serves as the schema master at any time as needed. This is what is meant by the word flexible in operations master.

The current schema master in the enterprise is identified by the value of the fSMORoleOwner attribute on the Schema container of the domain. By default, the first domain controller installed in the enterprise is the initial schema master.

Although the domain controller that is the current operations master Role Owner for schema operations is the only one that can make the actual schema modifications, you do not have to be connected to that domain controller when you make schema modifications. If you are connected to a domain controller that does not have that role, it generates a referral to the current operations master Role Owner to process the modifications.

If you want to do so, you can transfer the role of schema master to another domain controller by using the Active Directory Schema snap-in.

To view or change the current Schema Master by using the Active Directory Schema snap-in

  1. Open an MMC console, and add the Active Directory Schema snap-in.
  2. Right-click the Active Directory Schema, and then click Operations Master.
  3. The Current Operations Master that is displayed is the Schema Master. Click OK to leave it as is.

    – Or –

    Click Change to change the server that is the current operations master Role Owner for the schema. If the current domain controller (the one which is listed in Current Focus) is also the current operations master, you must use the Active Directory Tree snap-in to focus on another domain controller before you can change the operations master. This is because you must be connected to the domain controller that you want to have as the operations master Role Owner. You cannot direct the connected domain controller to make another domain controller the operations master Role Owner.

Note

Another way to view or search for the schema master is by using an lDAPDisplayName search string fSMORoleOwner. Search strings can be entered using the LDP tool. You would use the following string while you search the Schema container:(&(objectClass=*)(fSMORoleOwner=*))

For more information about using the Active Directory Schema snap-in, see “Managing Active Directory” in this book.

There is also a command line tool that you can use to transfer the Schema operations master. It is called Ntdsutil, and it resides in the \%systemroot%\System32 folder. For more information about transferring operations master roles using Ntdsutil, see “Managing Active Directory” in this book.

To change the Schema Master by using Ntdsutil

  1. Start Ntdsutil by typing ntdsutil at the command prompt. Note that at any prompt in this tool, you can type ? to see the list of valid commands for that prompt.
  2. At the Ntdsutil prompt, type:

    roles

  3. At the fsmo maintenance prompt, type:

    connections

  4. To display the current connection information, at the server connections prompt, type:

    info

    If necessary, type the appropriate command to connect to the server that is to become the schema master. (Use the ‘?’ command to see a list of valid commands.

  5. To return to the fsmo maintenance prompt, type:

    quit

  6. To do a graceful transfer of the schema operations master, type:

    transfer schema master

You can also perform the schema master role transfer in a program. Before a program can make changes to the schema, it must check explicitly whether the domain controller is the current schema master and, if it is not, explicitly request the transfer operation.

To understand the transfer process, consider a scenario in which machine A is the current operations master Role Owner and machine B wants to perform some schema updates. To request a operations master Role Owner transfer from machine A, a program must add the operational attribute becomeSchemaMaster with value of 1, to the rootDSE (that is, the object with a blank DN) on machine B. An operational attribute is an attribute used only for administering the directory server itself. It is an artifact attribute that is never defined in the schema and does not require any storage. Generally, when you set an operational attribute, you trigger some immediate action on the server.

In this case, the action taken on the server (machine B) is that it sends out a request to machine A for a role transfer. Machine A, on receiving such a request, changes the fSMORoleOwner attribute on its Schema container to the name of machine B and sends this new attribute value back to machine B. It also sends back any schema changes that were implemented at machine A but not yet incorporated by machine B (this is possible due to replication latencies). Machine B, on receiving the reply from machine A, applies all changes that were sent back from machine A and, in the process, becomes the current schema master.

Note

Machine B, the new schema master, now has all previous schema updates in the enterprise and, hence, the latest version of the schema.

If the old schema master is unavailable or has crashed, you can forcefully transfer (seize) the schema operations master so that a new server can make schema changes. However, any schema changes made at the old schema master might not have been propagated to the new master and might be lost.

To seize the schema master by using Ntdsutil

  1. Start Ntdsutil by typing ntdsutil at a command prompt. Note that at any prompt in this tool, you can type ? to see the list of valid commands for that prompt.
  2. At the Ntdsutil prompt, type:

    roles

  3. At the fsmo maintenance prompt, type:

    connections

  4. To display the current connection information, at the server connections prompt, type:

    info

    If necessary, type the appropriate command to connect to the server that is to become the schema master. (Use the ‘?’ command to see a list of valid commands.)

  5. To return to the fsmo maintenance prompt, type:

    quit

  6. To perform a forced transfer (seizure) of the schema operations master, type:

    seize schema master

Caution

You should only perform a forced transfer (seizure) of the schema operations master when you are sure that the current schema master is no longer able to function and that if it is brought back online, it is guaranteed to have connectivity to the other domain controllers. It is always preferable to transfer the schema operations master role gracefully.

Microsoft recommends that you use utmost caution when deciding whether to manually change the fSMORoleOwner value. Consider the following scenario. You change the role manually and make schema changes at the new master. The old master is subsequently brought online and has changes not yet sent to the new master. If the two sets of changes do not conflict with each other, they send their changes to each other and to the rest of the enterprise and everything is fine. If, however, the schema changes at the old master and new master conflict, some of the changes are lost or might require offline cleanup of the directory.

For more information about operations master, see, “Managing Active Directory.” in this book.

Order of Processing When Extending the Schema

If you decide to extend the schema programmatically or by using scripts, you should apply updates in the following order:

  1. Add new attributes.
  2. Add new classes.
  3. Add attributes to existing classes. New attributes or classes referenced in this step must be referred to by their object identifiers because their names are not present in the schema cache at this point.
  4. Trigger a cache update.

Note

A cache update is not necessary if the schema extensions are not to be used immediately. Depending on system load, the extensions appear in the schema cache in approximately 5 minutes.


Adding and Modifying Schema Objects

Because schema objects are just another kind of directory object, you can use the same methods you would use to add or modify any directory object. Windows 2000 provides an administrative tool called Active Directory Schema that provides a straightforward user interface, and, of course, you have the option of making changes to the schema programmatically.

Adding an Attribute

You should try to use existing attributes wherever possible. However if you decide that you need to create a new attribute, you should adhere to the following guidelines:

  • Use cn as the name (RDN) attribute — this is the default for most classes, including those derived directly from top. cn is an indexed attribute and makes searching for your object by name efficient.
  • Large multivalued attributes are costly to store and retrieve; you should avoid them. Active Directory implements an LDAP extension to allow an incremental read of large multivalued attributes, but not all LDAP clients know how to use this extension.
  • Remember that attributes are "flat,” which means that there is no implied substructure to an attribute. All attributes in a given class should relate directly to instances of that class. This is also good data normalization practice.

To add a new attribute, you add a new schema-definition object with all the desired attributes. After you remove the Active Directory safety interlocks, as described in “How to Extend the Schema” earlier in this chapter, make sure that you do the following before you add an attribute:

  1. Choose a name for the attribute.
  2. Obtain a valid object identifier from an issuing authority.
  3. Determine the syntax of the attribute.
  4. Decide whether the attribute should be single or multivalued.
  5. Decide whether the attribute should be indexed.
  6. Decide whether the attribute should be replicated to the Global Catalog.

Some attributes are mandatory for every attribute that you define; these attributes are listed in Table 4.6.

Table 4.6 Mandatory and Optional Attributes for New Attribute-Definition Objects

Mandatory Attributes | Default Status
cn | No default. Administrator must be specify a name..
objectClass | No default. Administrator must specify as attributeSchema.
AttributeID | No default. Administrator must specify as an object identifier string.
AttributeSyntax | No default. Administrator must specify one of the syntaxes recognized by Active Directory.
OMSyntax | No default. Administrator must specify an oMSyntax that matches the corresponding attribute syntax.
SchemaIDGUID | No default. Administrator must specify a value.
NTSecurityDescriptor | Defaults if the administrator does not specify. The default value depends on defaultsecuritydescriptor of classSchema class.
IsSingleValued | Defaults to FALSE if not specified by the administrator.
LDAPDisplayName | Defaults from the common name if not specified by the user.
Optional Attributes | Default Status
Min-Range | The minimum valid range, if any.
Max-Range | The maximum valid range, if any.
SearchFlags | No default. The four currently defined bits for this attribute are as follows: 1 = Index over attribute only; 2 = Index over container and attribute; 4 = Add this attribute to the Ambiguous Name Resolution (ANR) set (should be used in conjunction with 1); 8 = Preserve this attribute on logical deletion (that is, make this attribute available on tombstones).

As an example, suppose you want to add a new attribute called Name. Each instance of a Name attribute stores exactly one unicode string of at least one character and not more than 1,000 characters. In this case, you would add the following attribute definition:

  • cn = Name
  • objectClass = attributeSchema
  • attributeID = 1.2.567.8901234.5.6.879 (valid object identifier value)
  • attributeSyntax = 2.5.5.12 (Syntax value for unicode string)
  • oMSyntax = 64 (Syntax value for unicode string)
  • isSingleValued = TRUE (The intention is to store exactly one value.)
  • rangeLower = 1 (Minimum length of the string)
  • rangeUpper = 1000 (Maximum length of the string)

Modifying an Attribute

To modify an attribute, modify the existing attribute-definition object that represents the class. Some attributes of each attribute-definition object are designated as system only, for consistency and security reasons. You cannot modify system only attributes of a attribute object, not even for new classes that you originally created. System only attributes are designated by having the systemOnly attribute of the attribute set to TRUE.

The following attributes of a attribute-definition object are system only and cannot be modified:

  • attributeID
  • schemaIDGUID
  • attributeSyntax
  • oMSyntax
  • isSingleValued
  • extendedCharsAllowed
  • systemOnly
  • objectClass
  • instanceType

Adding a Class

To add a new class, you add a new schema-definition object with all the desired attributes. After you remove the Active Directory safety interlocks, as described in “How to Extend the Schema” earlier in this chapter, make sure that you have done the following before you add a class:

  1. Choose a name for the class.
  2. Obtain a valid object identifier from an issuing authority.
  3. Determine the object class category.
  4. Determine the class from which this inherits.

Some attributes are mandatory for every class, as shown in Table 4.7. If you do not define values for some of these attributes, they are given default values.

Table 4.7 Mandatory and Optional Attributes for New Class-Definition Objects

Mandatory Attribute | Default Status
cn | No default. Administrator must specify a name.
objectClassCategory | Defaults to 88 class because it is assumed to be a class with no category. Other options are Structural, Abstract, or Auxiliary.
governsID | No default. Administrator must specify an object identifier string.
possSuperiors | No default. Administrator must specify the structural class(es) that are legal parents of instances of this class.
subClassOf | No default. Administrator must specify a value.
SchemaIDGUID | No default. Administrator must specify a value.
nTSecurityDescriptor | Defaults if not specified. The default value depends on the default security descriptor of the classSchema class.
lDAP-DisplayName | Defaults from the common name if not specified.
Optional Attributes | Default Status
auxiliarClass | The list of additional (auxiliary) classes from which this class is derived.

For a new class, you must define cne, objectClass, and governsID. However, to make the new class actually useful, you would probably also want to define some attributes in mustContain, mayContain, and possSuperiors. Any attributes you specify when you add a new class must already exist. So, if you want to add a new class with new attributes, you must add the new attributes to the schema first.

When you add a new class, the object identifier specified in governsID must be unique, not only in your enterprise but throughout the world.

Note

The system imposes rules that restrict the addition of schema objects.

As a simple example of adding a class, suppose you want to add a new class, Friend, to store information about a friend. Any Friend object must contain the name of the friend and might also contain her address and/or phone number. And because a friend is a person, you want objects of the Friend class to have the same mandatory attributes, optional attributes, and directory superiors as the Person class you have already defined. In this case, you add the following class definition:

  • cn = Friend
  • objectClass = classSchema
  • subClassOf = Person
  • governsID = 1.2.345.678901.2.3.45 (valid object identifier value)
  • mustContain = givenName, sn
  • mayContain = Address, phone-number

Modifying a Class

To modify a class, simply modify the existing class-definition object representing the class. Some attributes of each class are designated as system only, for consistency and security reasons. You cannot modify system only attributes of a class-definition object, not even for new classes that you originally created. System only attributes are designated by having the systemOnly attribute of the attribute set to TRUE.

The following attributes of a class-definition object are system only and cannot be modified:

  • governsID
  • schemaIDGUID
  • rDNAttID
  • subClassOf
  • systemMustContain
  • systemMayContain
  • systemPossSuperiors
  • systemAuxiliaryClass
  • objectClassCategory
  • systemOnly
  • objectClass
  • instanceType


System Checks and Restrictions Imposed on Schema Additions and Modifications

When you complete the addition or modification of a class or attribute, Active Directory performs some checks to make sure the changes do not cause inconsistencies or other problems in the schema. The checks can be divided into two classes:

  • Consistency checks
  • Safety checks

Consistency checks maintain the consistency of the schema and safety checks reduce the possibility of a schema update by one application breaking another application.

Consistency Checks

For both class and attribute changes, the system makes sure that the values of lDAPDisplayName and schemaIDGUID are unique and also that lDAPDisplayName is valid.

The class-schema object addition and modification extensions are successful only if the new class definition passes all of the following tests as well as the normal extension checks.

  • The value of governsID must be unique.
  • All attributes defined in the systemMayContain, mayContain, systemMustContain and mustContain lists must already exist.
  • All classes defined in the subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors, and possSuperiors lists must already exist.
  • All classes in the systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors , and possSuperiors lists must have either 88 Class or Auxiliary Class specified as their objectClassCategory
  • Classes in the subClassOf list must follow certain X.500 specifications for inheritance hierarchy. These specifications are that Abstract classes can inherit only from other Abstract classes, Auxiliary classes cannot inherit from Structural classes, and Structural classes cannot inherit from Auxiliary classes.
  • The attribute specified in the rDNAttID attribute must have String(Unicode) as its syntax..

For attribute changes, the system also checks the following:

  • The value of attributeID must be unique.
  • The value of mAPIID, if any, must be unique.
  • If rangeLower and rangeUpper are present, rangeLower must be smaller than rangeUpper.
  • attributeSyntax and oMSyntax must match.
  • If the attribute is object-syntaxed (oMSyntax=127), it must have the correct oMObjectClass, which depends on its attributeSyntax, as shown in Table 4.8.
  • The linkID, if any, must be unique. In addition, a back link must have a corresponding forward link. (For more information about links, see “Active Directory Data Storage and Name Resolution” in this book.)

Table 4.8 is a list of attributeSyntax values with corresponding syntaxes.

Note

A complete syntax specification consists of both the attributeSyntax and the oMSyntax. Hence, wherever more than one oMSyntax can be used with an attributeSyntax, the correct oMSyntax must be used.

Table 4.8 attributeSyntax Values and Corresponding Syntaxes

attributeSyntax Value1 | Matching oMSyntax
2.5.5.1 | 127 [Object(DN-Binary)]
2.5.5.2 | 6 [String(Object-Identifier)]
2.5.5.3 | 27 [String(Case sensitive)]
2.5.5.4 | 20 [String(Case insensitive)]
2.5.5.5 | 19 [String(Printable)], 22 [String(IA5)]
2.5.5.6 | 18 [String(Numeric)]
2.5.5.7 | 127 [Object(OR-Name)] or [Object(DN-Binary)]. Distinction is oMObjectClass value.
2.5.5.8 | 1 [Boolean]
2.5.5.9 | 2 [Integer], 10 [Enumeration]
2.5.5.10 | 4 [String(Octet)], 127 [Object(Replica-Link)]
2.5.5.11 | 23 [String(UTC-Time)], 24 [String(Generalized-Time)]
2.5.5.12 | 64 [String(Unicode)]
2.5.5.13 | 127 [Object(Presentation-Address)]
2.5.5.14 | 127 [Object(Access-Point)] or [Object(DN-String)]. Distinction is oMObjectClass value.
2.5.5.15 | 66 [String(NT-Sec-Desc)]
2.5.5.16 | 65 [LargeInteger)]
2.5.5.17 | 4 [String(Sid)]
1The oMSyntax names are specified with the syntax numbers to enable the correct choice.

For attributes with oMSsyntax=127, the oMObjectClass also must be correctly specified according to the attribute-syntax. For attributes with any other oMSyntax value, it is not relevant and need not be specified. Because oMObjectClass, being a binary value, is somewhat inconvenient to specify and because in most cases there is a one-to-one mapping between the attribute-syntax and oMObjectClass, the value defaults if none is specified by the user. There are a couple of cases where the mapping is not one to one, however, and the value defaults to the more common value. Table 4.9 is a list of oMObjectClass values that correspond to the different attribute syntax values for attributes with oMSyntax=127.

Table 4.9 attributeSyntax and Corresponding oMObjectClass

attributeSyntax | oMObjectClass1
2.5.5.1 | \x2B0C0287731C00854A [Object(DS-DN)]
2.5.5.7 | \x56060102050B1D [Object(OR-Name)] or \x2A864886F7140101010B [Object(DN-Binary)]. Defaults to Object(OR-Name) if none specified by user.
2.5.5.13 | \x2B0C0287731C00855C [Object(Presentation-Address)]
2.5.5.14 | \x2B0C0287731C00853E [Object(Access-Point)] or \x2A864886F7140101010C [Object(DN-String)] Defaulted to Object(Access-Point) if none specified by he user.
1The syntax names are specified in brackets for easy reference.

As an example, suppose that you need to define a new attribute called myName that is intended to store exactly one unicode string of at least one character and not more than 1000 characters. The following shows the attribute-schema object addition that represents this new attribute:

  • cn = myName
  • objectClass = attributeSchema
  • attributeID = 1.2.840.113556.1.4.999 (valid object identifier value)
  • attributeSyntax = 2.5.5.12 (Syntax value for unicode string)
  • oMSyntax = 64 (Syntax value for unicode string)
  • isSingleValued = TRUE (Because the intention is to store exactly one value)
  • rangeLower = 1 (Minimum length of the string)
  • rangeUpper = 1000 (Maximum length of the string)

Note that schemaIDGUID is defaulted and that the oMObjectClass is not necessary (nor is it defaulted) because the oMSyntax is not 127. The LDAP display name is set to myName (generated from the common name) because it is not specified explicitly.

Safety Checks

The purpose of the safety checks is to reduce the possibility of schema updates by one user or application breaking another application. These checks are necessary because multiple applications might share a schema definition.

When you modify existing schema objects, the modifications are subject to certain restrictions enforced by Active Directory. In some cases, these restrictions are determined according to whether the objects are part of the original schema or they have been added after the original installation. So the schema objects are really divided into two categories:

  • Category 1 objects
  • Category 2 objects

Category 1 objects are the default base schema objects that ship with Windows 2000 in the base schema. Category 2 objects are objects that are added subsequently to the schema by administrators or applications. You can determine the category in which an object is located by looking at the second bit (starting at the least significant bit) in the systemFlags attribute. If it is on, it has the value FLAG_SCHEMA_BASE_OBJECT, which indicates that the object is part of the base schema, that is, Category 1. If this bit is not set or the attribute is not present, the object is Category 2.

The following restrictions apply to both Category 1 and Category 2 objects:

  • You cannot add a new mustContain attribute to a class (directly, or through inheritance by adding an auxiliary class).
  • You cannot delete any mustContain, mayContain, or possSuperiors of a class (directly or through inheritance)

The following restrictions apply to Category 1 schema objects:

  • You cannot change the rangeLower and rangeUpper of an attribute.
  • You cannot change the atributeSecurityGUID of an attribute.
  • You cannot deactivate a class or an attribute (make it defunct).
  • You cannot change the lDAPDisplayName of a class or attribute.
  • You cannot rename a class or an attribute.
  • You cannot change the defaultObjectCategory of a class.
  • You cannot change the objectCategory of instances of a class.


Deactivating Schema Objects

You cannot deactivate schema objects that are part of the default schema that ships with Active Directory. You can only deactivate schema objects that have been added to the default schema.

You might want to delete schema classes or attributes that are not needed in your organization. However, deleting schema objects raises some serious issues. For instance, what would happen to any other schema objects that use the class or attribute that you have deleted? Because doing an enterprise-wide check and cleanup could prove very time-consuming and costly, Active Directory does not support the actual deletion of schema objects. Rather it provides a mechanism for deactivating schema objects, also referred to as making them defunct. When you deactivate a schema object, you make it unusable for most purposes, and you get most of the benefits of deletion.

A class or an attribute can be deactivated by setting the Boolean attribute isDefunct to TRUE on the schema object. At any point in time, there are a number of ways to identify the defunct schema objects in the system. Programmatically, the user can search for all schema objects that have the attribute isDefunct set to TRUE (or if a particular schema object has isDefunct set to TRUE, to check whether the object is defunct). You can also use the Search function of the LDP tool to search the schema with a filter set to (isDefunct=TRUE). For more information about the LDP tool, see “Managing Active Directory” in this book.

Note

There is currently no method in the user interface for viewing defunct schema objects. To do this, you can use one of the methods described in the preceding paragraph.

As with additions or modifications of classes or attributes, there are some special validation checks performed when a class or an attribute is made defunct. This is to ensure the consistency of the schema. In particular, on an attempt to make a class defunct, Active Directory verifies that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors list of any existing nondefunct class. Similarly, on an attempt to make an attribute defunct, Active Directory checks that the attribute is not used in the mustContain or mayContain of any existing nondefunct class.

A defunct schema object can be resurrected, that is, made nondefunct again, by either deleting the isDefunct attribute from the object or by setting the value of the isDefunct attribute to FALSE. This can also be done easily using the Active Directory Schema snap-in. Because making a defunct schema object nondefunct is similar to adding a new schema object as far as subsequent schema updates go, Active Directory performs the same validation checks here as it does on the addition of a new schema object.

To resurrect a class or attribute by using the Active Directory Schema snap-in

  1. Start the Active Directory Schema snap-in.
  2. Double-click the Classes folder or Attributes folder to display the schema classes or attributes.
  3. Right-click the desired class or attribute, and then click Properties.
  4. Click the checkbox labeled Deactivate this class (attribute) to clear it, and then click OK.

To resurrect a class or attribute using the ADSI Edit snap-in

  1. Start the ADSI Edit snap-in.
  2. Right-click ADSI Edit, and then click Connect to.

    The Connection dialog box is displayed, as shown in Figure 4.3.

Figure 4.3 The Connection Dialog Box

  1. In the Connection Point box, make sure Naming Context is selected.
  2. Select Schema from the Naming Context box, and then click OK.
  3. In the left pane, double-click My Connection.

    The Schema folder is displayed.

  4. Double-click the Schema folder to display a list of attributes and classes in the right pane. This might take a few moments.
  5. Right-click the desired class or attribute, and then click Properties.
  6. Select Optional in the Select which properties to view box, and then select isDefunct in the Select a property to view box.
  7. In the Edit Attribute box (shown in Figure 4.4), type:
FALSE
  1. Click Set, and then click OK.

Figure 4.4 The Attribute Properties Dialog Box

A schema object can be resurrected at any time. The only restriction imposed is that in any such modification, the isDefunct attribute is the only attribute present in the modify call. This is done to achieve a clean semantics.

The only modification allowed on a defunct class or attribute is to modify the isDefunct attribute on it to make the class or attribute active again if required. No other modifications are allowed on a defunct class or attribute. The assumption is that because the object has been deactivated, it is not going to be used for any new modifications, and so there should not be any need to modify it. For example, if other attributes on a schema object are being modified in the same call as the one making the object defunct, it is controversial whether to apply the changes and then make the object defunct because no modifications of defunct schema objects other than making them nondefunct are allowed.

The Effect of Deactivating a Schema Object on All Objects

After a class A is made defunct, any subsequent addition or modification of instances of A fails as if A has been deleted from the system, that is, the same error codes are returned as if A never existed at all. For example, creating a new instance of A fails and trying to modify/rename an existing instance of A fails. Similarly, if an attribute B is made defunct, B is treated as nonexistent for new object creations and attempts to modify (add or replace) the value of B in an existing object fails.

However, any search or deletion in an object behaves as if no schema objects have been made defunct, the only exception being that schema objects are not allowed to be deleted. So in the above case, the user still is able to search for all existing instances of A and delete them if necessary. Similarly, the user can search for all instances that has a value for the attribute B and delete B from such an existing object. This behavior is retained to allow the user to clean up if necessary after a schema object is made defunct. For example, the administrator can decide that a class is not needed anymore and make it defunct so that no one can use it for any modifications. The existing instances of the class can then be cleaned up by searching for all instances and deleting them. Active Directory does not perform any cleanup after a schema object is made defunct. Similarly, an attribute can be made defunct, and all its uses can be cleaned up. Note that you can only allow delete the entire attribute from the object, not the values of the attribute. For example, in the above case, if B is a multivalued attribute and an object had more than one value for B, trying to delete a value of B from the object fails. This behavior is enforced because there should be no reason not to delete the attribute totally when cleaning up a defunct object.

The Effects of Deactivating a Schema Object on Schema Updates

In addition to the effects on the instances of the schema object, there are some additional effects of making a schema object defunct on subsequent schema updates. The additional effects arise mostly because schema updates are subject to special validation checks to which nonschema object updates are not subjected.

If a class/attribute A is made defunct, subsequent schema updates show the following behavior:

  • The only modification allowed on the defunct class/attribute A is to modify the isDefunct attribute on it to make the class active again if required. No other modifications are allowed on a defunct class/attribute. The assumption is that because the class/attribute is made defunct, it is not going to be used for any new modifications, and so there should not be any need to modify it anyway, except to make it active again if the administrator decides later that it is needed.
  • Validation checks performed while adding a new class/attribute or modifying an existing nondefunct class/attribute treats A as nonexistent, except that trying to add/modify a class/attribute to have the same DN, object identifier, lDAPDisplayName, mAPIID, or schemaIDGUID as A fails. As an example, if A is an attribute, then trying to modify an existing nondefunct class B by adding mayContain=A fails, as the validation checks performed at schema modification time fails as if A did not exist. Or if A is a class, then trying to add a new class with subClassOf=A fails, as A is treated as nonexistent by the validation checks performed during the addition of the class. However, trying to create a new class with the same object identifier as A fails (so in this case A is treated just as a nondefunct schema object to ensure schema consistency is not violated).

This ability to make schema objects defunct can be very useful in production environments in different ways. Schema objects that are no longer needed can be cleaned up by making them defunct. Then existing instances of those classes or attributes can be deleted if desired. At the same time, if the same schema object is found to be of use later, it can be quickly brought back by simply modifying the object by removing (or set the value to FALSE) the isDefunct attribute on it. This also protects against accidental removal of a schema object (by making it defunct) by mistake. The operation can be easily reversed with no side-effects. Note that because Active Directory does not do any cleanup after a schema object is made defunct, all instances of the schema object (that was made defunct by mistake) remain and become valid, normal objects when the defunct schema object is made active again.


Prefix Table Management

Every schema object, class or attribute, is uniquely identified by an object identifier string. The attributeID attribute of an attributeSchema object is an object identifier that is the unique name of the attribute. Similarly, the governsID of a classSchema object is the object identifier of the class. object identifiers are an inconvenient way to name attributes and classes for two reasons. First, object identifier strings are variable in length, and second, object identifier strings are large, which makes them difficult and inefficient to manipulate. Therefore, object identifiers are internally represented as 32-bit, unsigned integers. Informally, each object identifier string is broken up into a prefix and a suffix, and each prefix is assigned an unique index. The one-to-one mapping between object identifier and the internal representation is local to a domain controller and is stored as a Schema Prefix Table.

For example, an object identifier value of 1.2.3.4.5.6.7.8 would be internally held as the four-byte integer 00270008, where there was an entry in the prefix map stating that "1.2.3.4.5.6.7." was mapped to 0x27 The prefix table contains the set of object identifier prefixes that are currently being used in the Schema for various attributes and classes.

When new attributes and classes are created, Active Directory encounters new object identifiers and potentially new prefixes. This usually happens when a new software package is installed and it needs to create new classes and attributes for its functioning. The user simply adds new object identifiers as part of schema object adds, and Active Directory transparently generates and persists any new prefixes that might be created. Note that the prefix table imposes a limit on the last portion of any object identifier presented to the directory; that piece of the object identifier cannot be higher than 16383.

The prefix table is integrated into the schema cache and is loaded and unloaded from the memory with schema cache load/unload. Like the attribute and class tables, the prefix table is grown dynamically if necessary. Also, as with attributes and classes, there can be temporary inconsistencies between the prefix table in the schema cache and the actual set of prefixes persisted in the database. This can be removed by doing a schema cache update.

Persistent Storage for Prefixes

The implementation distinguishes between two classes of prefixes ;prefixes that are used in the schema objects in the base schema shipped with the product, and new prefixes that are added by the user in course of extending the base schema. The Microsoft-specific prefixes are still hard-coded in the source. The new prefixes created by the user in the course of a schema-extension are persisted in a single attribute in the Schema container. The storage of this attribute in the Schema container ensures enterprise-wide integrity of the set of known prefixes because the Schema container is replicated throughout the enterprise.

The attribute, called prefixMap, is a system-only, single-valued binary attribute. The system-only nature prevents modification of this attribute from outside the directory, because this value (and the concept of prefixes in general) should not be visible from outside the directory anyway. The prefixes are encoded sequentially in the single binary value as follows. Each prefix is encoded as a sequence of bytes. The first two bytes represent the index assigned to the prefix (recall that this is the 16-bit value that goes in the upper 16 bits of the 32-bit internal identifier that corresponds to an object identifier). The next two bytes represent the size (in bytes) of the prefix. And the remaining bytes represent the actual prefix. The first four bytes in the prefixMap attribute is the total number of prefixes in the map and the next four bytes is the total size (in bytes) of the value. The remaining bytes in the value are just the sequence of prefixes encoded in the above format. Encoding the total size of the value of the attribute in the first four bytes enables a new prefix to be easily appended to the end of the map.

Gaining Access to the Prefix Table

The prefix table is implemented as a part of the schema cache. Every thread has a thread-specific schema cache pointer to gain access to the schema cache. One of the components of this schema pointer is the pointer to the prefix table. The global schema cache, pointed to by the global schema pointer, thus holds a pointer to the global prefix table, which contains the set of prefixes currently known to the system. The prefix table to which a thread has gained access can either be this global table or a thread-specific prefix table, depending on whether the thread’s schema pointer is pointing to the global schema cache or to a thread-specific cache. During normal operations, the thread-specific schema pointer points to the global schema cache, and hence the global prefix table is used. A thread-specific table is used only during dynamic schema changes for validating the proposed changes against the existing schema and during updating the global schema cache after a schema change.

Loading and Unloading the Prefix Table

Because the prefix table is a component of the schema cache, the prefix table is loaded or unloaded whenever the schema cache is loaded or unloaded respectively.

The loading of the prefix table is a two-step process. First, the base schema hardcoded prefixes are loaded into the table. Next, the prefixMap attribute in the Schema container is read and decoded to load any new user-defined prefix.


Issues Related to Modifying the Schema

When you modify the schema, you must be aware of the implications and of the potential problems that can arise. There are three main issue involved with modifying the schema: replication, concurrency control, and handling invalid object instances.

Replication

Because the schema is replicated across all domain controllers in the forest, a schema update performed at one domain controller is guaranteed to be propagated throughout the forest. This guarantees a schema that is consistent forest-wide. However, because of replication latencies, there can be temporary inconsistencies.

For example, consider that a new class A is created at a server X, and then an instance of this class (B) is created at the same server (X). However, when the changes are replicated to another server Y, the object B is replicated out before the class-schema object A. When the change arrives at server Y, the replication of B fails because Y’s copy of the schema still does not contain the class schema object A., Hence, Y does not know about the existence of A.

Active Directory solves this problem in such scenarios by explicitly replicating the Schema container from the originating server when such failures occur. Additionally, the replication of the Schema container triggers an immediate schema cache update on the target server. Active Directory then re-replicates the object that failed.

In the example, re-replication brings in class-definition object A and also puts it into Y’s schema cache. Retrying the replication of B after this now succeeds.

Concurrency Control

Active Directory must ensure that different program threads do not perform simultaneous, conflicting schema updates (such as when one thread is deleting an attribute and another is adding it to the mustContain list of a class).

To ensure this, any thread that attempts to perform a schema update also automatically writes a special attribute (schemaUpdate) on the Schema container as part of the same transaction. (Active Directory automatically causes the thread to write the attribute — you do not have to do so in your program code.) Only one thread can write this attribute at any one time.

This method guarantees schema consistency, but it does not guarantee which of the updates is successful. You must be aware of this when schema updates are made in a batch (such as in the case of the installation of directory-enabled applications).

For example, consider a scenario in which two Active Directory–aware programs, A and B, are being installed simultaneously, each of which creates several new schema objects. Because Active Directory creates one thread per object update, it is possible that some of the objects in program A and some of the objects in program B get created (if the internal threads do not overlap), and then one of the installations fails (because a thread for a schema object creation for program A overlaps with a thread for a schema object creation for program B).

Assume that program A fails. Now running A back from scratch again does not work because some of the objects that program A creates are already created in the schema; trying to re-create them in the second run (existing objects) returns an error. Therefore, it is recommended that programs that modify the schema not be run concurrently, unless provisions are made in the program to first check if the schema update that is about to be made has already been made, and then proceed accordingly.

Handling Invalid Object Instances

A schema update can make an existing instance of an object invalid. For example, suppose object X is an instance of class Y. Class Y has an attribute, Z, in its mayContain list. Therefore, because object X is an instance of class Y, object X can have this attribute defined on it and assume that X does indeed have this attribute currently defined in it.

Now a schema update is performed that modifies class Y by deleting attribute Z from its mayContain list. Note that this change makes the instance of object X invalid because X now has an attribute, Z, that it is not allowed to have according to the class definition of Y (of which object X is an instance).

Active Directory allows the now-invalid objects to remain in the directory and ensures that they do not cause any problems to the rest of the schema. Active Directory does not automatically clean up invalid objects, but invalid objects and attributes appear in searches and can be deleted manually.


Methods for Extending the Schema

Windows 2000 gives you some choices regarding the way you accomplish schema extension. You can use one of the two command line tools (LDIFDE and CSVDE) that provide the directory with the ability to import or export data in standard formats. You can perform schema extension programmatically by using the Active Directory Services Interface (ADSI). You can also extend the schema from the user interface with the Active Directory Schema snap-in. (For more information about ADSI, see “Managing Active Directory” in this book.)

Using LDIFDE and CSVDE

Directory Information Exchange is a Windows 2000 mechanism for sharing directory information among various directory services. It enables information to be exchanged between directories where no formal ongoing relationship is intended. Directory Information Exchange supports two data formats, LDAP Data Interchange Format (LDIF) and Comma Separated Value (CSV). The tools that are provided with Windows 2000 Server (LDIFDE and CSVDE) correspond to these two formats, respectively.

LDIFDE and CSVDE utilize files that contain directory data in the appropriate format. These files can be imported or exported to LDAP-based directory servers as a means of populating a directory or modifying objects in a directory. Because the Active Directory schema exists as a collection of directory objects, either of these tools can be used to extend the schema.

Note

At present, the CSVDE tool can be used only for additions to the directory, not for modifications to the directory.

The LDIF File Format

The LDIF format is a draft Internet standard for a file format that can be used to perform batch operations on directories that conform to LDAP standards. It is suitable for additions to the directory as well as modifications and deletions of directory objects. A record in an LDIF file consists of a sequence of lines that either describe a directory entry or a set of changes to a single directory. This format can be used for all LDAP operations.

The preferred method to use when modifying the schema is to use the Active Directory Schema snap-in to edit the schema on a practice system that is isolated from your real enterprise. You can then use the LDIFDE export to produce a script, which you can then run against your live system. The following example represents the contents of a sample LDIF file that can be used to add a new attribute to Active Directory.

dn: CN=New-Attribute-Name,CN=Schema,CN=Configuration, DC=microsoft,DC=com
changetype: add
objectClass: attributeSchema
ldapDisplayName: newAttributeName
adminDisplayName: New-Attribute-Name
adminDescription: New-Attribute-Name
attributeId: 1.2.840.113556.1.4.1250 <- the id has to be unique
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
systemOnly: FALSE
searchFlags: 0
showInAdvancedViewOnly: TRUE

For more information about the LDIF format and using LDIFDE, see, “Managing Active Directory” in this book.

The CSV File Format

The CSV file format is a simple format whose big benefit is ease of use. In the CSV file format, each line represents a discrete object in the directory, with the object’s attributes separated by commas or another user-definable character. The first line of the file always contains all of the attribute names. Each subsequent line represents a different entry in the directory. If an entry cannot fit on one line, you can continue it to the next line by appending an ampersand ("&") character to the end of the line. Values for multivalued attributes can also be specified, and are delimited by the colon (:) character.

Because this format is compatible with the Microsoft® Excel CSV format, it enables you to dump directory information to an Excel spreadsheet or import data from a spreadsheet into Active Directory. This format can be used only for additions to the directory. The following example represents the contents of a sample CSV file that can be used to add a user to Active Directory:

ObjectClass,cn,sn,givenName,telephoneNumber.otherTelephoneNumber,&
Street,l,c

User,Penny Lane,Lane,Penny,555-456-7890,555-123-4567$555-123-4444,&
123 Magnolia Ave.,Redmond,US

Both the CSVDE and LDIFDE tools have command line help that can be viewed by typing the command name at an MS-DOS prompt. Because both of these tools allow data to be imported and exported, there are a number of different uses for them.

  • Migration to Active Directory

    By using either of these tools, users of other directory services can import data to Active Directory. This works for any directory that is LDAP compatible as long as the attribute names match.

  • Publishing Information from the Directory

    You can use either of these tools to export directory data to another application that can read either the LDIF or CSV format. You can also export to other LDAP-compatible directory services, provided there are matching attribute names.

  • Adding Resources to the Directory

    In addition to the Directory Manager tool, and the ADSI programming interface, administrators can choose to use one of these tools to add objects to a directory. The tools lie somewhere in between the other options in terms of ease of use and flexibility. Because the schema is represented in Active Directory as directory objects, you can use LDIFDE or CSVDE to extend the schema with new or modified schema objects. In fact, if your application requires schema modifications, the best way to accomplish this is to distribute an LDIF or CSV file with the application that is to be imported to the schema.

Figure 4.5 demonstrates one way that LDIF can be used to extend Active Directory:

Figure 4.5 Extending Active Directory with LDIF

For detailed information about using the LDIFDE and CSVDE tools, see “Managing Active Directory” in this book.

Using Active Directory Service Interfaces and VB Scripts

Although one potential benefit of using an LDIF or CSV file is that the administrator can look at it to see what it does, consider the merits of extending the schema programmatically:

  • A programmatic extension is invariant; it is a Windows executable. The binary cannot be tampered with, unlike an LDIF or a CSV file, either of which can be edited inadvertently or maliciously.
  • Programs can detect and recover from errors and provide intelligent feedback.
  • Programs handle Unicode without resorting to Base64 encoding. (Unicode is a 16-bit character set which contains all of the characters commonly used in information processing.)
  • Programs can leverage the Microsoft Installer (MSI) setup Application Programming Interfaces (APIs).
  • Programs can be signed to prove their authenticity.

Active Directory provides a set of interfaces that enable you to gain access to directory objects, including schema objects, programmatically. ADSI defines a directory service model and a set of COM interfaces that you can easily use with a variety of programming languages. ADSI conforms to the Component Object Model and supports standard COM features.

By using VB Script and ADSI, you can write scripts easily to accomplish various directory modifications, including extending the schema.

These are the specific ADSI interfaces to use when you extend the schema:

  • IADsContainer

    Use IADsContainer::Create to create new classSchema and attributeSchema objects.

  • IADs

    Use IADs::Get (or GetEx) to read the attributes of classSchema and attributeSchema objects. Use IADs::Put (or PutEx) to set the attributes of classSchema and attributeSchema objects. PutEx is particularly useful in manipulating the lists of mustContain and mightContain attributes because it is designed specifically for handling multivalued attributes.

The code in the example that follows represents a sample script that you can use to add a user to Active Directory.

Dim oDomain
Dim oUser

Set oDomain=GetObject("LDAP://OU=Marketing,DC=antipodes,DC=com")
Set oUser = oDomain.Create("user","cn=John Smith")
oUser.Put "samAccountName","JSmith"
oUser.Put "givenName","John"
oUser.Put "sn","Smith"
oUser.Put "userPrincipalName","jsmith@antipodes.com"
oUser.SetInfo
MsgBox "User created " & oUser.Name
Set oDomain = Nothing
MsgBox "Finished"
WScript.Quit

For information about ADSI, see “Managing Active Directory” in this book.

Using the Active Directory Schema Snap-In

The Active Directory Schema snap-in allows members of the Schema Administrators group to manage the schema through a graphical interface. With it, you can create and modify classes and attributes and also specify what attributes are indexed and what attributes are replicated to the Global Catalog.

After you start the Active Directory Schema snap-in, the first thing you must do is make sure the tool is focused on the schema master for your enterprise.

To view or change the current schema master using the Active Directory Schema snap-in

  1. Open an MMC console, and add the Active Directory Schema snap-in.
  2. Right-click Active Directory Schema, and then click Operations Master.
  3. The Current Operations Master that is displayed is the schema master. Click OK to leave it as is

    – Or –

    Click Change to change the server that is the current operations master Role Owner for the schema. If the current domain controller (the one which is listed in Current Focus) is also the current operations master, you must use the Active Directory Tree snap-in to focus on another domain controller before you can change the operations master.

After you have verified that the tool is focused on the current schema master, you can use it to add, modify, or deactivate attributes and classes. Remember that the account you are using must be a member of the Schema Administrators group and that the server must be set to allow schema modifications.

Note

Schema objects that are part of the default base schema cannot be deactivated.

For detailed information about using the Active Directory Schema snap-in, see “Managing Active Directory” in this book.


Active Directory Data Storage and Name Resolution

A directory service consists of both a directory storage system (called the directory store) and a mechanism that is used to locate and retrieve information from the system. Active Directory™, the directory service in Microsoft® Windows® 2000, stores objects that provide information about the real things that exist in an organization’s network and that are associated with one or more domains, such as users, specific groups of users, computers, applications, services, files, distribution lists, and so forth. It then makes this information available to users and applications throughout the organization.

In This Chapter

Active Directory Architecture

Active Directory Data Storage

Related Chapters in the Resource Kit

  • For information about Active Directory hierarchy and DNS naming, domain controller location, and tree and forest structure, see “Active Directory Logical Structure” in this book.
  • For information about intersite and intrasite replication, see “Active Directory Sites and Replication” in this book.
  • For information about understanding and modifying the Active Directory schema, see “The Active Directory Schema” in this book.
  • For information about using Microsoft DNS, see “Windows 2000 Implementation of DNS” in the Microsoft Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.


Active Directory Architecture

Understanding the interactions of Active Directory™ architectural components provides the basis for understanding how Active Directory stores and retrieves data. The first step is understanding the relationship of Active Directory to the rest of the Microsoft® Windows® 2000 Server operating system.


Active Directory and Windows 2000 Architecture

The Windows 2000 operating system employs modules and modes that combine to provide operating system services to applications. Two processor access modes, kernel and user, divide the low-level, platform-specific processes from the upper-level processes, respectively, to shield applications from platform differences and to prevent direct access to system code and data by applications. Each application, including service applications, runs in a separate module in user mode, from which it requests system services, that is, provides an application programming interface (API) that gains limited access to system data. An application process begins in user mode and is transferred to kernel mode, where the actual service is provided in a protected environment. The process is then transferred back to user mode. The security subsystem in user mode is the module in which the Active Directory service application runs. The security reference monitor, which runs in kernel mode, is the primary authority for enforcing the security rules of the security subsystem. Figure 6.1 shows the location of Active Directory within Windows 2000.

Figure 6.1 Active Directory Within the Windows 2000 Operating System

The tight integration of the directory service and security services is key to the implementation of Windows 2000 distributed systems. Access to all directory objects first requires proof of identity (authentication), which is performed by components of the security subsystem, and, thereafter, validation of access permissions (authorization), which is performed by the security subsystem in conjunction with the security reference monitor. The security reference monitor enforces the access control applied to Active Directory objects.

For more information about the Windows 2000 operating system, see “Understanding Microsoft Windows 2000 Architecture” in the Microsoft® Windows® 2000 Professional Resource Kit, which contains information about the core technologies for both Microsoft Windows 2000 Professional and Microsoft Windows 2000 Server. For information about authentication, see “Authentication” in this book.


Security Subsystem Architecture

Windows 2000 includes a set of security components that make up the Windows security model. These components ensure that applications cannot gain access to resources without authentication and authorization. Components of the security subsystem run in the context of the Lsass.exe process and include the following:

  • Local Security Authority (LSA)
  • Netlogon service
  • Security Accounts Manager service
  • LSA Server service
  • Secure Sockets Layer
  • NTLM and Kerberos authentication protocols

The security subsystem keeps track of the security policies and the accounts that are in effect on the computer system. In the case of a domain controller, these policies and accounts are those that are in effect for the domain in which the domain controller is located, and they are stored in Active Directory.

The Local Security Authority (LSA) is a protected subsystem that maintains the information about all aspects of local security on a system (collectively known as the local security policy), and provides various services for translation between names and identifiers.

In general, the LSA performs these functions:

  • Manages local security policy.
  • Provides interactive user authentication services.
  • Generates tokens, which contain user and group information as well as information about the security privileges for that user. After initial logon is complete, all users are identified by their security identifier (SID) and the associated access tokens.
  • Manages the Audit policy and settings. When an audit alert is generated by the Security Reference Monitor, the LSA is charged with writing that alert to the appropriate system log.

The local security policy identifies the following:

  • The domains trusted to authenticate logon attempts.
  • Who can have access to the system and in what way (for example, interactively, over the network, or as a service).
  • Who is assigned privileges.
  • What security auditing is to be performed.
  • Default memory quotas, that is, paged and nonpaged memory pool usage.

Figure 6.2 shows a local perspective of Active Directory within the security subsystem (Lsass.exe)

Figure 6.2 Active Directory Within the Local Security Authority (Lsass.exe)

The LSA has the following components:

Netlogon.dll. Maintains the computer’s secure channel to a domain controller. It passes the user’s credentials through a secure channel to the domain controller and returns the domain security identifiers and user rights for the user. In Windows 2000, the Netlogon service uses DNS to resolve names to the Internet Protocol (IP) addresses of domain controllers. Last of all, Netlogon is the replication protocol for Microsoft® Windows® NT version 4.0 primary domain controllers and backup domain controllers.

Msv1_0.dll
The NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication.
Schannel.dll
The Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel, as opposed to a less-secure clear channel.
Kerberos.dll
The Kerberos v5 authentication protocol.
Kdcsvc.dll
The Kerberos Key Distribution Center (KDC)service, which is responsible for granting ticket-granting tickets to clients.
Lsasrv.dll
The LSA server service, which enforces security policies.
Lsarpc.dll.
Lsassrv.dll
Lsass.exe.
Samsrv.dll
The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies, and supports APIs.
Ntdsa.dll
The Directory Service module, which is the Windows 2000 replication protocol that supports Lightweight Directory Access Protocol (LDAP) and manages partitions of data.
Secur32.dll
The multiple authentication provider that holds all of the components together.

For information about the LSA and its components, see “Authentication” in this book. For information about access control, see “Access Control” in this book.


Directory Service Architecture

Active Directory functionality can be illustrated as a layered architecture in which the layers represent the server processes that provide directory services to client applications. Active Directory consists of three service layers and several interfaces and protocols that work together to provide directory services. The three service layers accommodate the different types of information that is required to locate records in the directory database. Above the service layers in this architecture are the protocols and APIs that enable communication between clients and directory services.

The diagram in Figure 6.3 shows the Active Directory service layers and their respective interfaces and protocols. The direction of the arrows indicates the manner in which the different clients gain access to Active Directory through the interfaces. LDAP and MAPI clients gain access to the directory by calling functions, indicated by one-way arrows into the Directory System Agent. The Security Accounts Manager (SAM) and replication transports (REPL) exist as separate data link libraries (DLLs) and can call only entry points exported by the Directory System Agent DLL, Ntdsa.dll. All other components are in Ntdsa.dll itself and are linked to the functions they want to call. Thus, a two-way interaction is required between the two DLLs.

Figure 6.3 Active Directory Service Layers and Interface Agents

The key service components include the following:

  • Directory System Agent. Builds a hierarchy from the parent-child relationships stored in the directory. Provides APIs for directory access calls.
  • Database Layer. Provides an abstraction layer between applications and the database. Calls from applications are never made directly to the database; they go through the database layer.
  • Extensible Storage Engine. Communicates directly with individual records in the directory data store on the basis of the object’s relative distinguished name attribute.
  • Data store (The database file Ntds.dit). This file is manipulated only by the Jet database engine. You can administer the file by using the Ntdsutil tool.

For information about the Ntdsutil tool, see “Managing Active Directory” in this book.

Clients obtain access to Active Directory by using one of the following mechanisms that is supported by the directory system agent:

  • LDAP/ADSI. Clients that support LDAP use it to connect to the directory system agent. Active Directory supports LDAP v3 (defined by RFC 2251) and LDAP v2 (defined by RFC 1777). Windows 2000 clients, as well as Windows 98 and Windows 95 clients that have the Active Directory client components installed, use LDAP v3 to connect to the directory system agent. Active Directory Services Interface (ADSI) is a means of abstracting LDAP API; however, only LDAP is exposed by Active Directory.
  • MAPI. Legacy MAPI clients, such as Microsoft® Outlook® clients, connect to the directory system agent by using the Messaging API (MAPI) remote procedure call (RPC) interface.
  • SAM. Windows clients that use Windows NT 4.0 or earlier use the SAM interface to connect to the directory system agent. Replication from backup domain controllers in a mixed-mode domain goes through the SAM interface as well.
  • REPL. When performing directory replication, Active Directory directory system agents connect to each other using a proprietary RPC interface.

Active Directory service comprises the following files:

  • Ntdsa.dll
  • Ntdsapi.dll
  • Ntdsatq.dll
  • Ntdsbcli.dll
  • Ntdsbsrv.dll
  • Ntdssetup.dll
  • Ntdskcc.dll
  • Ntdsmsg.dll
  • Ntdsperf.dll
  • Ntdsxds.dll
  • Ntds.dit

Directory System Agent

The directory system agent (DSA) is the process that provides access to the store. The store is the physical store of directory information located on a hard disk. “DSA” is an X.500 term that describes the server-side process that instantiates a directory service; that is, applications bind to a DSA. Clients use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write Active Directory objects and their attributes.

For all practical purposes, a DSA is the equivalent of a domain controller in that it represents a discrete segment of Active Directory to which applications can bind. Active Directory is partitioned so that individual domains do not store the entire directory. The unit of partitioning is the naming context. At the very least, a DSA holds a single Windows 2000 domain naming context plus the two non-domain naming contexts that store forest-wide data — the Configuration and Schema naming contexts. Domain controllers that store a replica of a given DSA are loosely considered to be equivalent to the DSA; but in fact, the DSA is a single entity that can have multiple replicas, that is, multiple domain controllers that store the same data.

An Active Directory naming context is a hierarchy of directory objects that forms a unit of replication. Each naming context requires an identity by which it can be replicated. That identity is stored in the ObjectGuid attribute of the object directly above the naming context. For a domain naming context, this object is the domain object immediately above it in the namespace. The Schema and Configuration naming contexts are located in the namespace under the forest root domain object. Although the state of replicas of a naming context do not always agree in all respects at any given moment, they do always agree about the naming context globally unique identifier (GUID) because the naming context root object never changes (that is, you cannot change the forest root domain, the domain name, or the position of a domain naming context in the domain tree) and the forest root domain object GUID also never changes.

The DSA layer exposes interfaces to support the following set of core operations:

  • Object Identification

    Every object in Active Directory has a permanent GUID that is associated with a string form of the object name. The object name is not permanent; that is, it can be changed. All permanent references to the object are kept in terms of the GUID; the object name is used for hierarchy navigation and display purposes. The DSA maintains the GUID association with a given object when the object’s string name changes.

  • Transaction Processing

    The DSA provides APIs that map directly onto the X.500 abstract operations (for example, bind, read, modify, search) in a two-to-one manner, where one is a wrapper around the other one, which is a “worker” function. The wrapper function is responsible for opening a transaction, verifying that a replica of the relevant naming context exists on the local server, calling the worker function, and then committing or rolling back the transaction as appropriate.

  • Schema Enforcement of Updates

    In addition to conflicting updates on two directory entry objects, a conflict can arise because of an update to a classSchema or attributeSchema object. In a multimaster system, a change to a schema object in one replica might conflict with existing objects in that replica and also with objects in other replicas. In Windows 2000, schema change is a single-master operation, so if an update does not produce a conflict at the originating replica, the update is considered acceptable at all replicas. Thus, replicated updates do not perform any schema checks. Making the replicas of an object consistent with each other is the primary goal; their consistency with a changing schema is secondary. The worker functions are the enforcers of schema and security limitations in the directory, as well as containers for the programmatic hooks used to implement schema modifications.

  • Access Control Enforcement

    The worker functions are the enforcers of security limitations in the directory. The DSA layer reads SIDs on the access token that is presented by an application process thread.

  • Support for Replication

    The worker functions contain the hooks for replication notifications. All object updates ultimately must go through the appropriate function for the directory service to work properly.

  • Referrals

    DSA manages the directory hierarchy information (referred to as “knowledge”), which it receives from the database layer. DSA is responsible for cross-references of Active Directory domain objects up and down the hierarchy, and also out to other domain hierarchies.

Database Layer

The database layer isolates the upper layers of the directory service from the underlying database system. The database layer is a layer only; it does not exist as a separate program or dynamic-link library (DLL). The database layer exposes APIs to the DSA layer; it also has internal functions and structures that are not exposed. No database access calls are made directly to the Extensible Storage Engine; instead, all database access is routed through the database layer.

Access to the database layer is accomplished within the context of a database layer session. Database layer sessions cannot be shared between threads. Each thread must have its own session and, in fact, might have multiple sessions. Each session maintains a current record. All attribute and attribute value accesses are made to this current record.

The database layer provides a view of the database that is tailored to the directory service application. It does not provide visibility for all the capabilities of the underlying database package, but rather implements methods of traversing a directory tree and maintains the tree structure. Figuratively speaking, the database layer “understands” the parent-child relationships that exist in the database and provides these relationships to the DSA, which implements the cross-reference connections between parent domains and child domains.

Specifically, the database layer performs these functions:

  • Separates the Extensible Storage Engine from direct access by applications.
  • Provides a hierarchy to the DSA for the tabular data in the database. This hierarchy is called the directory tree.
  • Provides APIs for creating, retrieving, and modifying database objects. A significant portion of the database layer is involved in optimizing resolution of distinguished names.

The Active Directory database model is a tree of named objects. Each object is uniquely identified by its individual naming attribute, called the relative distinguished name (RDN). The RDN and the chain of successive parent object names make up the object’s distinguished name (DN). The database stores the RDN for each object as well as a reference to the parent object. The database layer follows these parent references and concatenates the successive RDNs to form DNs.

A major function of the database layer is to translate each DN into an integer (type ULONG) structure called the distinguished name tag (DNT), which is used for all internal accesses. The database layer guarantees the uniqueness of the DNT for each database record.

All data that describes an object is held as a set of attributes, which are stored as columns in the database. The database layer provides APIs to create, retrieve, and delete individual records, attributes within records, and values within attributes. To carry out these functions, the database layer uses the schema cache (an in-memory structure in the DSA) to get information about the attributes that it needs. The schema cache provides the mapping between attribute ID, MAPI syntax, and JET column. The information about attributes held by the schema cache is used by the database layer to satisfy any request regarding attributes.

All access to the database layer is made within the context of a database layer session. Each session maintains a current record, and all attribute and attribute value accesses are made to this current record. Modifications to objects are made against an in-memory image of the object. All changes are made to this copy, and the object must be explicitly committed to the in-memory database before the changes are reflected in the permanent database.

For information about the schema cache, see “The Active Directory Schema” in this book. For information about APIs, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK). Search for MSDN at http://microsoft.com.

Extensible Storage Engine

The Active Directory service is implemented on top of an Indexed Sequential Access Method (ISAM) table manager, historically called “Jet.” This same table manager is used by Microsoft® Exchange Server version 5.5, the file replication service, the security configuration editor, the certificate server, WINS, and various other Windows components. Windows 2000 has its own version of Jet, which is the Extensible Storage Engine (ESE). The ESE (Esent.dll) is an improved version of the Jet database that was used in Microsoft® Exchange Server version 4.x and Exchange Server 5.5. It implements a transacted database system, which means that it uses log files to ensure that committed transactions are indeed safe. Thus, the directory service has the notion of data files and log files. The data file is named Ntds.dit.

The ESE stores all Active Directory objects. Because Active Directory is a pervasive information service and not a central database stored in a file in one location, the ESE enables you to create a database up to 16 terabytes in size, which can theoretically hold many millions of objects per domain.

Note

Testing of the database has been carried out to a maximum of 1.5 million objects per domain.

The ESE is well-suited to the storage needs of Active Directory for the following reasons:

  • ESE update operations are transacted for stability and integrity across system failures.
  • ESE handles sparse rows well, that is, rows in which many of the properties do not have values.
  • When an object is created in Active Directory, the system selects a copy of the store and writes the object there. The replication system replicates the object to all other replicas.

Active Directory comes with a predefined schema that defines all of the attributes that are required and allowed for a given object. ESE reserves storage only for the space that is used, that is, only for the attributes that are assigned to an object, not for all possible attributes. For example, if a user object already has 50 attributes defined in the schema and you create a user with only four attributes, storage space is allocated only for those four attributes. If more attributes are added later, more storage is allocated for them.

Also, the ESE is able to store attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user without requiring a different phone number attribute for each phone number.

Active Directory is a functional superset of the Exchange Server directory service; it offers additional functionality, such as rename-safe objects, a dynamically extensible schema, and per-property replication and reconciliation.

The ESE comprises the following files:

  • Esent.dll
  • Esentperf.dll
  • Esentutl.exe

Esent.dll exposes the Jet database API. It has no knowledge of the content of Active Directory; instead, it implements the search and retrieval functionality of the underlying database.


Protocols and Interfaces to Active Directory

The protocols and interfaces in the Active Directory architecture diagram (Figure 6.3) represent the means by which client applications can gain access to Active Directory. For example, the DSA layer exposes both directory service (LDAP) and address book (MAPI) interfaces that clients call when they want access to directory services. When ADSI is used, LDAP calls are abstracted through the ADSI LDAP provider, which in turn enables LDAP access to directory services.

In addition, replication must have access to directory services. SAM interacts with Active Directory to provide compatibility with Windows NT 4.0 domain clients that are authenticating to a Windows 2000 domain controller and to replicate directory data in mixed-mode domains where Windows NT 4.0 backup domain controllers are still in use.

LDAP/ADSI

LDAP is the core protocol used by Active Directory. Active Directory Services Interface (ADSI)is a single set of directory service interfaces that can be used by clients to gain access to and manage network resources in disparate directory services through providers written specifically for those directory services. In addition to LDAP v2 and LDAP v3, Windows 2000 Server includes ADSI directory-specific providers for Novell Netware Directory Service (NDS), Netware 3.x, and Windows NT 4.0. For LDAP directory services, client applications can be written with ADSI instead of the more tedious LDAP C API, which can be used to program directly for an LDAP directory. Developers are encouraged to use ADSI when they write programs so that their applications have access to directories other than LDAP.

LDAP comprises the following files:

  • Wldap32.dll
  • Ldapsvc.dll
  • Ldapacl.dll
  • Ldapdb.dll
  • Ldapkey.dll

Directory Replication Service

Active Directory replication is performed using the Directory Replication Service (DRS) APIs, which are represented in the Active Directory architecture diagram as REPL. The DRS APIs are responsible for notifying domain controllers of changes to domain objects. For intersite replication, DRS is used over three replication transport protocols: RPC, IP, and Simple Mail Transfer Protocol (SMTP). Intersite RPC replication can be scheduled and compressed. Intrasite RPC replication is not compressed. For intrasite replication, RPC is always used. Thus, Windows 2000 directory replication recognizes three degrees of connectivity:

  • Uniform, high-speed connectivity (intrasite/domain, RPC over IP).
  • Point-to-point, synchronous, low-speed connectivity (intersite/domain, RPC over IP).
  • Mail-only connectivity (intersite/domain, SMTP over intersite messaging).

On each DSA, replication employs a single thread to receive changes from other servers and apply them locally by using either RPC synchronous transport or intersite messaging asynchronous transport. The choice of transport is determined by the RepsFrom attribute on the naming context. Both synchronous and asynchronous transports operate on a request-response basis.

Note

Mail-based (SMTP-based) replication can be used to substitute mail messaging for the RPC transport for inter-site replication of the Global Catalog and the Schema and Configuration naming contexts. SMTP replication uses intersite messaging asynchronous transport. The message syntax is the same as it is for RPC-based replication. (See “Active Directory Sites and Replication” in this book.)

The difference between the transports is that RPC transport expects a response to any request more or less immediately. As a result, only one inbound RPC connection to a naming context replica is active at a time. With a synchronous interface over a slow link, serialization can occur where no changes are being applied locally during the time it takes the thread to receive the next set of changes. Intersite messaging transport accommodates much longer delays between a request and a response. For this reason, multiple inbound intersite messaging connections to a naming context replica can be active at the same time.

For information about Active Directory replication, see “Active Directory Sites and Replication” in this book.

MAPI

Messaging clients gain access to the Exchange Server directory service using MAPI, including the MAPI transport, the MAPI information store, and MAPI address book providers. For compatibility with existing messaging clients, Active Directory supports the RPC interfaces (MAPI address book providers) that allow access to Active Directory — for example, to find the telephone number of a user.

Note

In Windows 2000, the MAPI address book provider is provided solely for backward compatibility with MAPI clients, such as Microsoft® Outlook® 98 and Microsoft® Outlook® 99.

SAM

SAM is a protected subsystem that manages user and group account information in the registry. SAM maintains a database of aliases, users, groups, and domains; in this database, a computer is considered a local domain. In Windows 2000, workstation security account data is stored by SAM in the local computer registry, and domain controller security account data is stored in Active Directory. In Windows NT 4.0, both local and domain security principals are stored in SAM. In mixed-mode domains where Windows NT 4.0–based backup domain controllers are still in use, clients that run Microsoft® Windows® NT version 3.51 or Windows NT 4.0 communicate with the SAM server via SAM APIs, which are required for replication and for authentication against the SAM database. In native-mode domains, authentication of clients that run Windows NT 3.x or Windows NT 4.0 requires the SAM APIs to direct the request to Active Directory.

Most SAM operations are structured as reads and writes of properties. For workstation accounts, operations are reads from and writes to the registry Domain-controller account operations are performed on Active Directory objects and their corresponding properties. Properties of Active Directory objects are stored ultimately as directory database column values.

The SAM client calls public SAM routines, which in turn call internal routines that encapsulate the remote procedure call. On the server side, the internal SAM routines do the bulk of the work.

In Windows NT 4.0, all access to account information is accomplished through internal SAM routine (SAMR) calls to the accounts database that is stored in the registry. In Windows 2000, SAM effectively splits off the domain-controller account information from the workstation-account information and places it in the directory instead of the registry.

In particular, access to domain-controller account information is by means of routines such as DirAddEntry and DirRead, which are implemented as part of the DSA process on the server. These routines are the underlying helper routines that implement the X.500 calls, such as ds_add_entry. The routines are intended to be called in-process on the server and offer the ability to search, read, and write directory service objects. Remoting (SAMR) of Windows 2000 SAM API is done via the existing SAM routines.

The interactions between the SAM client and server and the storage of domain and local accounts are depicted in Figure 6.4:

Figure 6.4 SAM Client and Server Interactions and Account Storage


Active Directory Data Storage

Active Directory™ stores data for an entire forest. “Directory” and “forest” can be considered synonymous. Although there is a single directory, data storage is distributed among one or more domains, while maintaining consistent data throughout the forest that applies to all domains. Computers that store Active Directory are called domain controllers.

Some naming contexts, which are the units of directory replication, store forest-wide configuration and schema information, and other naming contexts store information that is specific to individual domains. The naming contexts that store domain information are replicated to domain controllers in only that domain. The naming contexts that store configuration and schema information are replicated to domain controllers in all domains. In this way, Active Directory provides a data repository that is logically centralized but physically distributed. Because all domains store forest-wide configuration and schema information, each domain can reference any other domain if the information that is requested is not stored locally. In addition, a partial replica called the Global Catalog stores a replica that contains an abbreviated set of attributes for every object in the forest. The Global Catalog can therefore be queried to find any object in the forest.

The way Active Directory data is stored can be summarized as follows:

Domain-Wide Data:

  • Domain-specific data is stored in a domain container, which is named for the domain and is the topmost object (head) of the domain naming context.
  • A full, writable replica of the domain naming context is replicated to every domain controller in the domain.

Forest-Wide Data:

  • Forest-wide data is stored in two containers — the Configuration container and the Schema container. The Configuration container is the head of the Configuration naming context; the Schema container is the head the Schema naming context.
  • A full replica of the Configuration and Schema naming contexts is replicated to every domain controller in the forest.
  • A partial replica of every domain naming context in the forest is stored on domain controllers that are designated as Global Catalog servers. The replica in the Global Catalog is a “partial” replica because it stores only some of the attributes for each object. A Global Catalog server is a Windows 2000–based domain controller that stores a replica of a domain naming context plus the Global Catalog for the forest.


Data Characteristics

The key characteristics of the data stored by a directory service correspond to size and latency. Active Directory should store objects that are not so large that they hamper replication and not so unstable that they change before a replication cycle reaches completion. Therefore, unstructured, large data sets and data values that change frequently are not appropriate for storage in Active Directory.

In general, Active Directory is appropriate for storage of data with the following characteristics:

  • The data is globally useful information in the domain that needs to be replicated to each Active Directory domain controller.
  • The data has well-defined object attributes and semantics. Binary large objects (BLOBs), which are used to describe the handling and storage of long strings of data (typically associated with image and video files), are acceptable provided a given attribute for such data always has the same semantics. However, discrete attributes are always preferable to data whose format and structure are unknown or size is variable.
  • The data is static information with a useful life that is at least two times the maximum replication latency for the domain. In general, if data can become outdated before the completion of a replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be able to tolerate the inability to update data for at least as long as it takes for the data to be replicated throughout the domain.
  • The data is no more than approximately 10 KB per attribute value in size, including multivalued attributes. An attribute value is replicated as a single block of data; therefore, an attribute that is x megabytes in size requires an equivalent amount of buffer space in the sending and receiving domain controllers. If the amount of required buffer space is large, this can affect performance.


Storage Limits

The Active Directory database has been tested for up to 1.5 million objects. Performance tests show logon performance for a single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1.1 MM objects — that is, the directory service does not slow measurably when the size of the database increases.

Note

In a mixed-mode environment in which backup domain controllers are running Windows NT 4.0, the recommended limit for number of security-principal objects per domain is 40,000 (the sum of users, groups, and computers). This limit is based on SAM database storage capacity.

Object Size vs. Maximum Database Record Size

The data store has a maximum database page size of 8 KB, which translates to the maximum size allowed for a single record. Although the maximum record size is 8 KB, all properties of an object are not stored in the record. The record stores references to Jet “large values,” which can be quite large. In theory, an object can contain 8 K of references to large properties, each of which is hundreds of kilobytes in size. In reality, however, the directory read/write model is optimized for small properties. The size of objects is not a problem if you use the recommended guidelines described in the preceding section.

Note

The Jet page size is not configurable. To enhance performance on domain controllers that must handle high request rates, install the Windows 2000 operating system on one drive, the Active Directory database file (Ntds.dit) on a second drive, and the log files on a third drive. Always use mirrored drives on domain controllers to prevent data loss from a hard-drive crash. (For information about Jet page sizes, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Development Kit (SDK). Search for MSDN at http://microsoft.com. For information about disk management, see “Storing and Managing Data” in the Microsoft® Windows® 2000 Professional Resource Kit, which contains information about core technologies for both Microsoft® Windows 2000 Professional and Microsoft® Windows 2000 Server.)

Garbage Collection

Garbage collection is a housekeeping process that runs on every domain controller. At regular intervals (the default is 12 hours), garbage collection deletes objects and files that are no longer needed by the directory service. If a domain controller is rebooted at intervals of less than the garbage collection interval, the database and log files continue to grow. For this reason, it is important to maintain domain controller operation for at least the length of the garbage collection interval.

Garbage collection consists of three tasks:

  • Deleting log files.
  • Deleting tombstones (objects that are removed from the directory but not yet deleted)
  • Defragmenting the database file.

There are two parameters that control how garbage collection runs and what it removes:

  • Tombstone lifetime (default = 60 days) is the length of time that an object lives as a tombstone in the directory before being collected as garbage.
  • Garbage collection interval (default = 12 hours) controls how often a domain controller examines its database for expired tombstones that can be collected.

The garbage collection interval is set in the garbageCollPeriod attribute, and the tombstone lifetime is set in the tombstoneLifetime attribute, both on the object cn=DirectoryServices,cn=WindowsNT,cn=Services,cn=Configuration,dc= DomainName.

Deleting Log Files

When all changes (and all previous log files) have been written to the database file, a log file is no longer needed and is deleted.

Deleting Tombstones

Rather than physically delete objects from the database, the directory service removes most attributes and then tags the object as being in the tombstone state to alert replication partners that the object was deleted. Tombstones are used to replicate object deletions.

It is important that tombstone lifetime be substantially longer than the expected replication latency. The interval between cycles of deleting tombstones must be at least as long as the maximum replication propagation delay across the forest. Because expiration of a tombstone lifetime is based on the time when an object was deleted logically, rather than on the time when a particular server received that tombstone via replication, an object’s tombstone is collected as garbage approximately simultaneously on all servers. If the tombstone has not yet replicated to a particular server, that server never records the deletion. Likewise, if you restore a domain controller from a backup that is older than the tombstone lifetime, the domain controller does not have a record of some deletions, which leads to inconsistencies between domain controllers.

Database Defragmentation

To update the directory database file, the database system uses the quickest way to fill database pages, which is not always the most efficient way. Defragmentation rearranges how the data is written in the database to compact it. You can defragment the database file online or offline using the Ntdsutil command-line tool. Defragmentation can take place online (while the computer is running as a domain controller) or offline (while the computer is running as a member server).

  • Online Defragmentation

    ESE supports online defragmentation, which effectively rearranges pages within the data file but does not release space back to the file system. ESE invokes online defragmentation automatically at regular intervals after garbage collection.

  • Offline Defragmentation

    The directory database file cannot be managed while the computer is running as a domain controller. Offline defragmentation is performed in Directory Services Repair mode, which restarts the computer as a member server — that is, the computer runs offline. In Directory Services Repair mode, you can use the Ntdsutil command-line tool to defragment the Ntds.dit file. Offline defragmentation produces a defragmented version of the database file in a separate directory. You can archive the original Ntds.dit file and move the defragmented file into the NTDS directory. (For more information, see Ntdsutil Help.)

    You can use offline defragmentation to test database growth by comparing the defragmented version of the file with the fragmented version. For example, on a newly installed domain controller, if you perform a bulk load of objects and then defragment offline, the difference between the two files is the space occupied by the new objects.

    To defragment the database file offline, boot the domain controller into directory service repair mode, as follows:

    • Intel computer: Press F8 during the boot options phase, and then select Directory Services Repair mode.
    • Alpha computer: Select Directory Service Repair mode from the boot selection.

    Follow these recommended defragmentation procedures:

    • Use offline defragmentation only when you know database contents have decreased considerably (for example, when a Global Catalog server becomes a normal domain controller) and you need to reclaim space for other uses.
    • Retain the original Ntds.dit file until the domain controller has restarted with the defragmented file. After you have no doubt that the directory database is in a consistent state, you can delete the fragmented (original) database file.

    When you test the effects of loading a specific set of objects on database growth, keep the following in mind:

    • When the directory contains objects you have added recently, the database is in a fragmented state, which makes it impossible to tell how much space the objects actually occupy in the database file.
    • Online defragmentation makes space available, but it does not reduce the size of the database file.
    • Only offline defragmentation provides you with a clear picture of the amount of space consumed.

    The differences between fragmented and defragmented files are illustrated in some of the database load tests described in the following section.

Growth Estimates for Active Directory Users and Organizational Units

A series of tests has been performed to arrive at average object sizes for objects that are typically stored in Active Directory. These tests begin with the size of the default Ntds.dit file immediately following the promotion of a domain controller.

Important

Ntds.dit grows by large increments and uses fractional pages in the BTrees to avoid page splits. Therefore, if you add objects, the database size seems larger than the actual data.

The database file size is not updated until the file has been closed. Because Active Directory always keeps its database open, Windows 2000 always reports the wrong file size. However, the free space that remains on the drive is reported correctly, so through subtraction you can reconstruct the correct file size.

To find the approximate size of data plus indices, use the Ntdsutil command-line tool to compact the database offline.

Directory Database Sizing Tests

In general, two kinds of directory database sizing tests were performed. In the first series of tests, the database was loaded with large numbers of identical objects to show how the database grows when objects are loaded, and how much space is consumed for the object types in each test. In the second series of tests, a blueprint for a company with user objects, group objects, and files shares was created. This second series was designed to show how large the database can become for small, medium, and large companies.

Most of the tests used several steps for the object load operation. The empty database size was recorded, and then the first set of objects was loaded. An offline defragmentation was performed and the fragmented and the defragmented versions of the database were measured. The fragmented version was used when the next set of objects was loaded.

The objective of the single-object load tests was to find what the increase in database size is with respect to an increase in attribute value size. Because the database engine consumes space only for attributes for which values are set, the number of object attributes that have values makes a significant difference in the size of an object. In tests conducted only for user and organizational unit (OU) objects, only mandatory attributes were set. Mandatory attributes must contain value(s) in order for the directory service to create the object. Subsequent tests show how adding attributes to an object affects object size.

User Objects

Because user objects play a significant role in directory deployment, you have to know how big user objects are to determine how big the database will grow when you add users. Up to 500,000 users were loaded in the database in increments of 100,000 users. The results of the test are shown in Table 6.1

Table 6.1 User Object Growth Test Results

Fragmented Database |  |  |  | Defragmented Database
Number of Users | KB per Database | Growth (in KB) | Bytes per User |  | KB per Database | Growth (in KB) | Bytes per User
0 | 10,256 | -- | -- |  | 10,256 | -- | --
100,000 | 516,064 | 505,808 | 5,179 |  | 364,560 | 354,304 | 3,628
200,000 | 899,088 | 383,024 | 4,551 |  | 720,912 | 356,352 | 3,639
300,000 | 1,294,352 | 395,264 | 4,383 |  | 1,079,312 | 358,400 | 3,649
400,000 | 1,675,280 | 380,928 | 4,262 |  | 1,435,664 | 356,352 | 3,649
500,000 | 2,060,328 | 385,048 | 4,199 |  | 1,792,016 | 356,352 | 3,649

The database file growth pattern shown in Table 6.1 is linear. In fact, the growth between two load operations is always almost identical: approximately 385,000 KB in the fragmented version of the file and approximately 356,000 KB in the defragmented version of the file. The only exception to this linear growth pattern is the load operation in the first step, when the first 100,000 users are loaded. Here the increase in file size is much greater, about 516,000 KB.

This test illustrates how online defragmentation affects database size. Between the time the first set of objects (100,000 users) was added on the first day and the time the size of the file was checked on the next day, online defragmentation had occurred and rearranged the objects in the database. The online defragmentation made space available for new objects, but it did not shrink the database file size. Therefore, the size of the file is much greater for the fragmented version than when the next set of 100,000 user objects is loaded and the space in the database file can be used. The increase in file size for the fragmented version of the file is not much different from the increase in file size for the defragmented database version.

Loading 500,000 users (with values for only the mandatory attributes set) into Active Directory requires about 1.8 GB. To compute the size of one user object, subtract the size of an empty store, and then divide the store size by the number of users. In this case, one user object is 3,649 bytes in size. User objects in Active Directory are larger than most other objects because they contain many mandatory attributes.

Organizational Units

Because information in Active Directory is organized in a hierarchy of OUs, a series of tests was conducted to measured the effect of adding OU objects on the database size. Table 6.2 shows the results of these tests.

Table 6.2 OU Object Growth Test Results

Fragmented Database |  |  |  | Defragmented Database
Number of Users | KB per Database | Growth (in KB) | Bytes per User |  | KB per Database | Growth (in KB) | Bytes per User
0 | 10,256 | -- | -- |  | 10,256 | -- | --
2,000 | 12,304 | 2,048 | 1,049 |  | 10,256 | 0 | --
4,000 | 16,440 | 4,136 | 1,583 |  | 12,304 | 2,048 | 524
6,000 | 18,448 | 2,008 | 1,398 |  | 14,352 | 2,048 | 699
8,000 | 20,496 | 2,048 | 1,311 |  | 18,448 | 4,096 | 1,049
10,000 | 24,592 | 4,096 | 1,468 |  | 20,496 | 2,048 | 1,049
12,000 | 26,640 | 2,048 | 1,398 |  | 22,544 | 2,048 | 1,049
14,000 | 28,688 | 2,048 | 1,348 |  | 24,592 | 2,048 | 1,049
16,000 | 32,784 | 4,096 | 1,442 |  | 26,640 | 2,048 | 1,049

The results in Table 6.2 show that the growth pattern for OUs also is linear. The size of one OU is 1,049 Bytes.

Adding Attributes

The next series of tests enlarged the user objects with extension attributes 1 through 10. The attributes are defined in the schema as string-valued attributes. Each string was filled with 10 characters.

The test began with a store that contained 100,000 user objects with only their mandatory attribute set. The server was demoted to a non-domain controller, promoted back to a domain controller, and then loaded with 100,000 user objects again, this time with one extension attribute. The process was repeated with two attributes, then three attributes, and so forth. The results are shown in Table 6.3.

Table 6.3 Test Results for Extension Attributes with a User Object

Number of Extension Attributes | KB per Database | Bytes per User | Database/ Defrag. | Bytes per User | Bytes per Attribute
0 | 522,256 | 5,242 | 364,560 | 3,627 | --
1 | 413,712 | 4,130 | 364,560 | 3,627 | 0
2 | 413,712 | 4,130 | 364,560 | 3,627 | 0
3 | 485,392 | 4,864 | 382,992 | 3,816 | 63
4 | 663,568 | 6,689 | 405,520 | 4,046 | 105
5 | 698,384 | 7,045 | 405,520 | 4,046 | 84
6 | 706,576 | 7,129 | 407,568 | 4,067 | 73
7 | 704,528 | 7,108 | 444,432 | 4,445 | 117
8 | 702,480 | 7,087 | 444,432 | 4,445 | 102
9 | 497,680 | 4,990 | 444,432 | 4,445 | 91
10 | 497,680 | 4,990 | 444,432 | 4,445 | 82
11 | 497,680 | 4,990 | 444,432 | 4,445 | 74

In the fragmented version of the database, the size of the database increases by significantly larger increments at some steps than at others. This variation occurs when the database engine allocates space for new pages. Such large increases do not occur for the defragmented version of the database.

The growth of the defragmented database is again very linear. One additional attribute with a string size of 10 characters adds approximately 100 bytes to an object’s size.

For information about capacity planning, see the Microsoft Windows® 2000 Server Resource Kit Deployment Planning Guide.

Windows 2000 SAM Storage

The Windows NT 4.0 SAM uses the registry as its underlying persistent storage for account information. The registry provides simple name resolution, minimal transactions, replication, and secure storage for account information. In Windows 2000, SAM is retained for compatibility with those domains and applications that depend on it, but it is also used by Windows 2000–based computers for local account storage.

In Windows 2000, account information can be separated into two types of accounts: workstation accounts and domain accounts. Workstation accounts, which include user and group accounts on workstations and member servers, are limited in scope to the physical computer where the accounts reside. A domain account has a broader scope than a workstation account; it extends to all physical computers within the domain. A workstation administrator, for example, has administrative privileges on the local computer (a workstation or member server), but a domain administrator has administrative privileges on all computers within the domain.

In Windows NT 3.51 and Windows NT 4.0, both categories of accounts are stored in the SAM database (in the registry). In Windows 2000, domain-controllers store user, group, and computer accounts only in Active Directory; workstations and member servers continue to store local accounts in the registry.

In addition, the Windows 2000 SAM supports the following:

  • Multimaster account replication among peer domain controllers.
  • Creation and deletion of user properties.
  • Read, write, and query of third-party properties as defined by supplemental security packages in the LSA. (For information about the LSA, see “Access Control” in this book.)

Because domain account information is stored in Active Directory, SAM can utilize the Active Directory namespace for domain-wide name resolution by Windows NT 3.51–based and Windows NT 4.0–based backup domain controllers operating in a mixed-mode domain.

Note

The terms “mixed mode” and “native mode” refer to the state of the domain, not of the domain controller.

In mixed mode, where there can be backup domain controllers that are running Windows NT 3.51 and Windows NT 4.0, user, group, and computer accounts are stored in Active Directory, but clients continue to contact SAM for authentication. The same is true in a Windows 2000 native-mode domain for Windows NT 4.0 and Windows NT 3.51 clients (workstations and member servers). The PDC Emulator is a single Windows 2000 domain controller that acts as the primary domain controller for such clients.

For information about the PDC Emulator role of a Windows 2000 domain controller, see “Managing Active Directory Servers” in this book, and see “Determining Domain Upgrade Strategies from Windows NT” in the Deployment Planning Guide.

Mixed-Mode Storage Considerations

When Windows NT 4.0–domain controllers are located in a Windows 2000 domain, account storage capacity is limited by the SAM database, which is still used for domain accounts on the backup domain controllers. A Windows NT 4.0–based backup domain controller is able to store approximately 40,000 security principal accounts. The SAM database size does not decrease when you delete objects, but it becomes fragmented and contains “empty” space. This empty space is reclaimed as new objects are added but this can result in less available storage than the number of accounts might indicate. For example, changing group membership leaves an unoccupied storage space for the membership that was removed.

Note

Running REGBACK against the SAM database can remove the spaces, but only if the physical RAM of the computer is at least twice as large as the current SAM (because of the way REGBACK works). The following Microsoft Knowledge Base article describes some techniques for compressing the SAM database: “User Account Database Fails to Shrink after Deleting Accounts [winnt]”: (Q140380).

Structure

The Windows 2000 SAM consists of two containers — the Builtin domain and the Account domain. The Builtin domain contains several workstation groups that have the same SID on every system.

In Windows 2000, the Account domain continues to contain the same objects as in Windows NT 4.0, as well as several additional properties on certain objects. All objects in the domain continue to share a common namespace as well, rather than a hierarchical namespace. This restriction requires that, for example, a user object and an alias object cannot have the same name.

New capability in the Windows 2000 SAM enables third-party properties to be defined on user objects and to be used by supplemental security packages in LSA.

Objects

The term “object” has a different meaning in the Windows 2000 SAM than in Windows NT 4.0. In Windows 2000 SAM, object refers to an item in Active Directory, carrying with it whatever semantics are defined by the directory. The relationship between Windows NT 4.0 and Windows 2000 objects are as follows:

  • “Normal” user accounts are represented as user objects in Active Directory.
  • “Computer” user accounts (also called machine accounts) are objects of the class computer, which is a derived class of user and is exposed as the base class (user) to downlevel clients and domain controllers. (For information about derived classes and base classes, see “The Active Directory Schema” in this book.) By default, these accounts are placed in the Computers container after an upgrade, although there is no restriction that requires computer accounts to be confined to the Computers container. A flag on the user account identifies the account type as a workstation, domain controller, or normal user account. Windows 2000 maintains the Windows NT 4.0 semantics (the flags that determine the nature of objects — for example, a computer versus a user object) for workstation user accounts.
  • Global group accounts are represented as group objects in Active Directory.
  • Local group accounts from the “SAM account domain” are represented as group objects in Active Directory.
  • Builtin local group accounts from the SAM Builtin domain (for example, the Administrators group) are stored as domain local group objects in Active Directory in the Builtin container. Groups from the SAM Builtin domain have constant SIDs.
  • Backup domain controller computer accounts are represented identically to workstation computer accounts except that a different flag is set to distinguish them.
  • LSA account objects grant privileges on the workstation computer to a particular account. They are maintained in the registry and synchronized between the domain controllers by being replicated to the workstation policy. By default, each domain controller in the domain has the same workstation policy. Therefore, a change to an LSA account object updates the corresponding workstation policy for the PDC Emulator. The workstation policy change replicates to every other Windows 2000 domain controller in the domain.

The upgrade from a given Windows NT 4.0 SAM account to the corresponding Windows 2000 SAM object is summarized in Table 6.4:

Table 6.4 Upgrade of Windows NT 4.0 Accounts to Windows 2000 SAM Objects

Windows NT 4.0 SAM | Windows 2000 SAM
Normal user account | User object.
Workstation user account | Computer object, where the user account control flag indicates a workstation trust account.
Domain controller account | Computer object, where the user account control flag indicates a server trust account.
Global group in account domain | Group object, where the group type indicates a global group.
Local group in account domain | Group object, where the group type indicates a local group.
Local group in Builtin domain | Group object, where the group type indicates a local group as well as Builtin group (for example, Administrators, Backup Operators, and so forth).
Domain trust account | Trusted domain object. (Assumes the role of both inbound and outbound halves of the trust; there is also a domain trust account of class user for backward compatibility.)
Trusted domain object | Trusted domain object, upgraded.

Windows 2000 Server That Becomes a Domain Controller

When Active Directory is installed on a computer that is running Windows 2000 to create a domain controller, either a new domain can be created or the domain controller can contain a copy of an existing domain.

If the domain controller contains a copy of an existing domain, the local SAM database of the server is lost and is replaced by the domain database of the domain of which this server is a copy.

If you create a new domain, the existing SAM database is preserved as follows:

  • User accounts become user objects in Active Directory.
  • Local groups in the account domain become group objects in Active Directory. The group type indicates a local group.
  • Builtin local groups become group objects in Active Directory. The group type indicates a Builtin local group. These groups retain their constant SIDs and are stored in the Builtin container.

For information about upgrade issues, see “Determining Domain Upgrade Strategies from Windows NT 3.51 and Windows NT 4.0” in the Deployment Planning Guide.


Data Model

The Active Directory data model is derived from the X.500 model of objects and attributes. An object is a distinct, named set of attributes that represents something concrete, such as a user, a printer, or an application. Thus, Active Directory holds objects that represent entities of various sorts, which are described by attributes (also called “properties”). For example, attributes of a user object might include the user’s given name, surname, and e-mail address.

The universe of objects that can be stored in Active Directory is defined in the schema. For each object class, the schema defines what attributes an instance of the class is required to have, what optional additional attributes it can have, and what object class can be a parent of the current object class. LDAP defines a means for a client to view and query the schema.

Note

Active Directory is not an X.500 directory; it uses LDAP instead of the X.500 protocols. Active Directory is compatible with any LDAP v2 or LDAP v3 directory service, including X.500, if an LDAP gateway is provided by a third party. LDAP supports the X.500 information model without requiring X.500 overhead.


Container Objects and Leaf Objects

Container objects have child objects below them. Container is a structural object class, which means that container objects can be created in Active Directory. Other objects can be “container” objects in the general sense of the word (that is, they can have child objects), but they are not of the container class. For example, an OU is a container object, although its class is organizationalUnit, not container. An organizational unit object has many attributes that provide functionality that an ordinary container does not have; for example, an organizational unit can have a mailing address and can receive mail as a distribution list.

A leaf object has no child objects and, as such, occupies an end point in a tree. However, a leaf becomes a container as soon as it gains a child, and a container becomes a leaf as soon as its last child is removed.

For more information about container and leaf objects, see “The Active Directory Schema” in this book.


The Directory Tree

The directory tree represents the hierarchy of Active Directory objects for a given forest. The hierarchy provides the basis for both using names for navigation and for scoping search requests.

Note

The scope of Active Directory is large. It can include every object (printer, file, user, server, and domain) in a single wide-area network. It can also include several wide-area networks combined. It is important to keep in mind that Active Directory can scale from a single computer, to a single computer network, to many computer networks combined.

For every object in Active Directory, information is stored in the directory database that identifies (references) the parent object; each object has exactly one parent. By virtue of these parent references, the hierarchy of objects managed by Active Directory forms a tree structure in which the vertices are the directory entries (class instances, or objects) and the connecting lines are the parent-child relationships between the entries. The objects that populate the directory create this tree structure according to the rules of the schema, which defines what classes of objects are allowed to be created in which positions relative to other objects. For example, the schema might dictate that a given class of object can be the child of one class, but not of another.

There are several architectural restrictions and requirements within the directory tree:

  • Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the child of an organizational unit.
  • The root of the directory tree is called rootDSE, or directory root. RootDSE is an “imaginary” object that has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of a given domain controller. Thus, rootDSE constitutes the root of the directory tree from the perspective of the domain controller to which you are connected.
  • Below the root of the tree, every directory has a root domain, which is the first domain created in a forest. This domain always has a child container called Configuration, which contains configuration data for the forest. The configuration data includes information about all services, sites, and other domains (partitions) in the forest. The Configuration container has a child container called Schema. The domain and the Configuration container, with its child Schema container, represent the three default Active Directory naming contexts.

For information about parent-child relationships , see “The Active Directory Schema” and “Active Directory Logical Structure” in this book.

RootDSE

The rootDSE (DSA-Specific Entry) represents the top of the logical namespace for one domain controller, and therefore the top of the LDAP search tree. There is only one root for a given directory, but the information stored in the root is specific to the domain controller to which you connect. The attributes of rootDSE identify the naming contexts specific to one domain controller — that is, the domain, schema, and configuration naming contexts, as well as the forest root domain naming context. Thus, the rootDSE provides a “table of contents” for a given domain controller.

The rootDSE attribute values can be retrieved from an LDAP v3 server by using a Base-level search with a null BaseDN and with filter ObjectClass=*. The root DSE publishes information about the LDAP server including which LDAP versions it supports, any supported SASL mechanisms, supported controls as well as the distinguished name (DN) for its subschemaSubentry. In addition to server information, operational attributes might be exposed that allow for extended administration functionality. For more information about this LDAP v3 requirement, see RFC 2251.

The functional attributes on the rootDSE object are defined by values as follows:

  • subschemaSubentry

    The name of a subschema entry, which is used to administer information about the schema, in particular the object classes and attribute types that are supported. (For information about subschemaSubentry, see “The Active Directory Schema” in this book.)

  • namingContexts

    Naming contexts that this server masters (stores as a writeable replica) or shadows (stores as a read-only replica). This attribute allows a client to choose suitable base objects for searching when it has contacted a server.

  • altServer

    Uniform Resource Locators (URLs) of other servers that can be contacted when this server becomes unavailable. If the server does not know of any other servers that could be used, this attribute is absent. Clients can cache this information in case their preferred LDAP server becomes unavailable later.

  • supportedExtension

    Object identifiers (object identifiers) that identify the supported extended operations that the server supports. If the server does not support any extensions, this attribute is absent.

  • supportedControl

    object identifiers that identify LDAP controls that the server supports. If the server does not support any controls, this attribute is absent.

  • supportedSASLMechanisms

    The names of supported Simple Authentication and Security Layer (SASL) mechanisms that the server supports. SASL is a standard for negotiating an authentication and (optionally) an encryption mechanism. If the server does not support any mechanisms, this attribute is absent.

  • supportedLDAPVersion

    The versions of LDAP that the server implements. In addition to the functional attributes described in the preceding paragraphs, Active Directory also supports the following informational attributes:

currentTime.
The current time based on ‘Zulu’ time in the format xxxx(year)xx(month)xx(day)xxxxxx.x(hours,minutes,seconds military time)’Z’.
dsServiceName
NTDS settings.
DefaultNamingContext
The default naming context for a particular server. This value should be the path to the domain naming context for which this domain controller is authoritative.
SchemaNamingContext
The naming context for the forest schema.
configurationNamingContext.
The naming context for the forest Configuration container.
RootDomainNamingContext
The DN for the domain naming context that is the root domain for this forest.
SupportedLDAPPolicies
Supported LDAP management policies.
HighestCommittedUSN
Highest USN committed to the database on this domain controller.
DnsHostName
The DNS name of this domain controller.
ServerName
The fully qualified DN for this domain controller.

Active Directory also supports operational attributes. An operational attribute is an attribute that is used only for administering the directory database. It is an artifact attribute that is never defined in the schema and does not require any storage. Generally, when you set an operational attribute, you trigger some immediate action on the server. The following operational attributes are supported by Active Directory:

  • becomeDomainMaster
  • becomeRidMaster
  • becomeSchemaMaster
  • recalcHierarchy
  • schemaUpdateNow
  • becomePdc
  • fixupInheritance
  • abandonFsmoRoles
  • invalidateRidPool
  • abandonReplication

For more information about rootDSE and rootDSE attributes, go to the Microsoft Developer Kit (MSDN) Web site for a link to the Software Development Kit (SDK). Search for MSDN at http://microsoft.com. Then look for the RFC 2251 and ADSI 2.5 documentation

Viewing RootDSE

You can use ADSI Edit to see the contents of RootDSE for a given domain controller. ADSI Edit is a Microsoft Management Console (MMC) snap-in that you can add to an MMC console. (For instructions about how to add a snap-in to an MMC console, see Microsoft Windows 2000 Server Help.)

Note

ADSI Edit is not one of the default snap-ins that is available to be added to an MMC console. To add ADSI Edit to the list of available snap-ins, copy the Adsiedit.dll file from the \Support folder on the Microsoft® Windows® 2000 Server Resource Kit companion CD to your %systemroot%\System32 folder. Then on the Start menu, click Run. Type regsvr32 adsiedit.dll, and then click OK.

To connect to rootDSE using ADSI Edit

  1. Add ADSI Edit to an MMC console.
  2. In ADSI Edit, right-click the ADSI Edit icon, and then click Connect to.
  3. In the Name box, type a name (for example, RootDSE) if you want to name the connection. You can save this named connection and then open it subsequently from the ADSI Edit File menu.
  4. Under Connection Point, click Naming Context.
  5. In the Naming Context list, click RootDSE and then click OK.

You can view the attributes and values for the DSA to which you are connected.

Querying RootDSE

You can use the LDP tool to query rootDSE and receive a listing of attributes stored on the domain controller to which you are connected. Ldp.exe is a graphical tool that allows you to perform LDAP operations, such as connect, bind, search, modify, add, and delete, against any LDAP-compatible directory, such as Active Directory.

The following printout shows the results of a Connect operation using the LDP tool. In the Connect dialog box, if you leave the server name blank, you are connected to a domain controller in the current domain. Port 389 is the default port for LDAP; port 3268 is the default port for the Active Directory Global Catalog.

Upon successful connection to a domain controller, the rootDSE information is be displayed in the results pane, as shown in the following example:

Results of querying the RootDSE on
Retrieving base DSA information...
Matched DNs:
Getting 1 entries:
>> Dn:
1> currentTime: 19981119203514.0Z;
1> subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration, ,DC=mabat3,DC=microsoft,DC=com;
1> dsServiceName: CN=NTDS Settings,CN=Davidste,CN=Servers,CN=Bld28,CN=Sites,CN=Configuration, DC=mabat3,DC=microsoft,DC=com;
3> namingContexts: CN=Schema,CN=Configuration, ,DC=mabat3,DC=microsoft,DC=com; CN=Configuration, DC=mabat3,DC=microsoft,DC=com;DC=mabat3,DC=microsoft,DC=com;
1> defaultNamingContext:DC=mabat3,DC=microsoft,DC=com;
1> schemaNamingContext: CN=Schema,CN=Configuration,DC=mabat3,DC=microsoft,DC=com;
1> configurationNamingContext: CN=Configuration,DC=mabat3,DC=microsoft,DC=com;
1> rootDomainNamingContext:,DC=mabat3,DC=microsoft,DC=com
13> supportedControl: 1.2.840.113556.1.4.319; 1.2.840.113556.1.4.801; 1.2.840.113556.1.4.473; 1.2.840.113556.1.4.528; 1.2.840.113556.1.4.417; 1.2.840.113556.1.4.619; 1.2.840.113556.1.4.841; 1.2.840.113556.1.4.529; 1.2.840.113556.1.4.805; 1.2.840.113556.1.4.521; 1.2.840.113556.1.4.970; 1.2.840.113556.1.4.1338; 1.2.840.113556.1.4.474;
2> supportedLDAPVersion: 3; 2;
12> supportedLDAPPolicies: InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxActiveQueries; MaxNotificationPerConn; MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MaxPoolThreads; MaxDatagramRecv;
1> highestCommittedUSN: 3733;
1> supportedSASLMechanisms: GSSAPI;
1> dnsHostName: DAVIDSTE01.mabat3.microsoft.com;
1> ldapServiceName:mabat3..microsoft.com:DAVIDSTE01@MABAT3@MICROSOFT.COM;
1> serverName: CN=DAVIDSTE01,CN=Servers,CN=Bldg28,CN=Sites,CN=Configuration, DC=MABAT3,DC=microsoft,DC=com;
1> supportedCapabilities: 1.2.840.113556.1.4.800;

For more information about rootDSE, see RFC 2251.


Directory Partitions

The directory database stores all forest objects uniformly — that is, there is not a separate database for each domain, nor is each domain even a specific table in the database. However, objects of the entire forest are not all stored on each domain controller. Instead, the directory is partitioned so that domain controllers store only the portion of Active Directory that relates to that domain, as well as certain configuration information about all the other domains in the forest. Each domain is responsible for storing its own domain data. The means to distributing storage in this manner is the naming context. Active Directory partitions are identified physically as naming contexts.

Because a domain defines a security boundary and also represents the logical boundary of objects that belong to the same administration, it follows that each domain should be mapped to a different naming context so that the objects belonging to two different domains can be maintained and replicated independently. Likewise, information that is relevant to the entire forest must be replicated as separate and discrete units.

Naming contexts provide two critical functions:

  • Identifying partitions as units of replication.
  • Enabling referrals from one domain to another.

Each domain controller holds some subset of the directory. Dividing Active Directory data into naming contexts provides the division of data into configuration information, schema, and discrete domains. This structure provides for forest-wide searches, domain-level security, and replication.

In theory, a naming context could be any arbitrary subtree of the directory tree, but Active Directory limits naming contexts to subtrees that represent one of the following:

  • Configuration Naming Context

    Contains the Configuration container, which stores configuration objects for the entire forest in cn=configuration,dc=forestRootDomain. Updates to this container are replicated to all domain controllers in the forest. Configuration objects store information about sites, services, and partitions. The contents of the Configuration container can be viewed using ADSI Edit.

  • Schema Naming Context

    Contains the Schema container, which stores class and attribute definitions for all existing and possible Active Directory objects in cn=schema,cn=configuration,dc=forestRootDomain. Updates to this container are replicated to all domain controllers in the forest. The contents of the Schema container are displayed in the Active Directory Schema MMC snap-in.

  • Domain Naming Context

    Contains a domain container, which stores objects for a single Windows 2000 domain. Updates to the domain container are replicated only to domain controllers within the domain. The domain container object is displayed in the Active Directory Users and Computers MMC snap-in. The hierarchy of domain naming contexts can be viewed in the Active Directory Domains and Trusts MMC snap-in, and trust relationships between domains also can be managed.

Each naming context is a contiguous portion of the directory tree, starting at a single point (the naming context head) and spreading downward to either leaf objects or to the heads of other naming contexts. Each naming context therefore has exactly one naming context immediately above it in the tree (except for the root domain naming context, which has only the rootDSE above it), and possibly more naming contexts immediately below it. For domain naming contexts, this order manifests itself in the hierarchical infrastructure discussed in the chapter “Active Directory Logical Structure” in this book.

There is an important distinction between the physical storage of a naming context and its logical occurrence in the directory tree. Physically, all objects are stored in a single database table, regardless of the naming context to which they are assigned. Logically, the head of a naming context appears in the naming hierarchy as the topmost object — that is, the domain container, the Configuration container, and the Schema container each has a DN that identifies its position in the hierarchy. The respective naming contexts contain those objects, or heads — the domain naming context contains an object named dc=domainName; the Configuration naming context contains an object named cn=configuration, dc=domainName; the Schema naming context contains an object named cn=schema,cn=configuration,dc=domainName.

Figure 6.5 shows a conceptual diagram of the directory tree hierarchy, including the directory root (rootDSE) and the default naming contexts below it.

Figure 6.5 Default Active Directory Naming Contexts

Each domain controller in the forest holds a master replica of the Configuration and Schema naming contexts, which are copied to a domain controller during domain controller promotion. All updates to Configuration and Schema naming contexts are replicated to every domain controller in the forest. In this way, site, service, schema, and domain partition information is kept consistent throughout the forest.

The Forest Root Domain

The forest root domain is the first domain created in a forest, and, as such, it is the root domain in the domain namespace hierarchy. Because this domain naming context is at the top of the tree hierarchy, the head of the forest root domain naming context is the parent of the Configuration container in the hierarchy. Thus the distinguished name of the Configuration container, cn=configuration,dc=forestRootDomainName, reflects the naming hierarchy. Although the Configuration container is a child of the root domain object, the Configuration naming context is not part of the root domain naming context.

Similarly, the Configuration naming context head is the parent of the Schema container. The distinguished name of the Schema container, cn=schema,cn=configuration,dc=forestRootDomainName, shows the location of the schema to be in the root domain. Although the Schema container is a child of the Configuration container, the Schema naming context is not part of the Configuration naming context.

For more information about site replication see “Active Directory Sites and Replication” in this book.

The Configuration Naming Context

The Configuration naming context is created initially when the first Windows 2000 domain is created during Active Directory installation and stores the Configuration container object. As child domains are added beneath the forest root domain or new trees are created that trust the forest root domain, the Configuration naming context is copied to each domain controller during Active Directory installation and is thereafter replicated to every domain controller in the forest.

Viewing the Configuration Container

You can view the Configuration container by using ADSIEdit.exe.

Note

ADSI Edit is not one of the default snap-ins that is available to be added to an MMC console. To add ADSI Edit to the list of available snap-ins, copy the Adsiedit.dll file from the \Support folder on the Microsoft® Windows® 2000 Server Resource Kit companion CD to your %systemroot%\System32 folder. Then on the Start menu, click Run. Type regsvr32 adsiedit.dll, and then click OK.

To view the Configuration container

  1. Add ADSI Edit to an MMC console.
  2. Right-click the ADSI Edit icon, and then click Connect to.
  3. In the Name box, you can type a name (for example, Configuration) if you want to name the connection. (You can save this named connection and then open it subsequently from the ADSI Edit File menu.)
  4. Under Connection Point, click Naming Context.
  5. In the Naming Context list, click Configuration. Then click OK.

Figure 6.6 illustrates the contents of the Configuration container.

Figure 6.6 The Configuration Container Contents

The following objects are child containers within the Configuration container:

  • Schema

    The Schema container, which is the head of the Schema naming context, contains all of the class and attribute definitions required to create and locate objects in Active Directory. The contents of the schema can be viewed and managed in the Active Directory Schema MMC snap-in.

Note

Although the Schema container is a child of the Configuration container, the Schema container (cn=schema,cn=configuration,dc=domainName,dc=domainName) does not appear when viewing the Configuration container through ADSI Edit. The schema is a separate naming context and can be viewed using ADSI Edit or using the Active Directory Schema MMC snap-in.

  • DisplaySpecifiers

    Objects that allow for different user interfaces (for example, context menus and property pages) to display directory objects. For example, display specifiers are responsible for an administrator seeing something different using the Active Directory Schema snap-in than what a user sees in the product user interface, even though they are referencing the same objects. The display specification system stores information for property sheets, context menus, icons, creation wizards, and localized class and attribute names. The display specification system uses this information to form different user interfaces for administrators and end users — one set of elements, such as property pages, context menus, and so forth, can be associated with administrative applications, and a different set of elements can be associated with end-user applications. The DisplaySpecifiers container stores containers that correspond to each locale supported by Windows 2000. These locale containers are named using the hexadecimal representation of the locale ID, (LCID). Thus the US/English locale’s container is named 409. DisplaySpecifier objects are named by appending the LDAP Display Name of the class object with the string “-Display.” For example the user class has a corresponding DisplaySpecifier object called “user-Display.” Thus when you bind to an object of a particular class, you look up the DisplaySpecifier object based on the same name as the class and within the container for the current locale. Because Active Directory allows the schema to be modified by creating new classes and attributes or modifying existing classes, displaySpecifier objects can be modified to reflect any new user interface elements that schema modifications require.

  • Extended-Rights

    The set of all extended rights for the forest, stored as controlAccessRight objects. Access control on custom actions or operations are called control access rights, or extended rights. Access control determines who is permitted to perform operations on Active Directory objects. Access to standard actions or operations is controlled by two major types of permissions: container operations and property-based access. Other operations can have semantics that are not tied to specific properties, and these operations might also require access control. For example, the user class can be granted a Send As right that can be used by Exchange Server, Outlook, or any other mail program, to determine whether a particular user can have another user send mail on their behalf. To add an extended right to Active Directory, you create a controlAccessRight object in the Extended-Rights container. For more information about extended rights, see “Access Control” in this book. For information about creating extended rights objects, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK). Search for MSDN at http://microsoft.com. When you find the SDK, look for “Windows 2000 Active Directory Programmer’s Guide.”

  • LostAndFoundConfig

    Stores global configuration objects created in containers that are simultaneously being deleted elsewhere. If an object has been created in, or moved to, a location that is missing after replication, the “lost” object is added to the LostAndFoundConfig container. A LostAndFound container in each domain naming context serves the same purpose for domain-specific objects.

  • Partitions

    A repository for cross-references to every partition (naming context) in the forest, including Configuration, Schema, and all domain naming contexts. The knowledge of these partitions makes referrals to other domains possible during LDAP searches. Domain partitions can be viewed and managed in the Active Directory Domains and Trusts MMC snap-in.

  • Physical Locations

    For future use.

  • Sites

    Identifies all of the sites in the enterprise network, the domain controllers in those sites, and the replication topology. These translate to inter-site transports, subnets, and the first site created, which is called Default-First-Site-Name. The contents of the Sites container can be viewed and managed in the Active Directory Sites and Services MMC snap-in. For information about the Sites container objects, see “Active Directory Sites and Replication” in this book.

  • Services

    The Services container is the central repository for network-wide, service-specific information that applications use to connect to instances of services in the forest, irrespective of the computer on which the service runs. This service information includes system volumes, network services, and Routing and Remote Access Service (Rremote access). The contents of the Services container can be viewed and managed in the Active Directory Sites and Services MMC snap-in. For information about the Services container objects, see “Active Directory Sites and Replication” in this book.

  • Well-Known Security Principals

    Special identities defined by the Windows 2000 security system, such as Everyone, Local System, Principal Self, Authenticated User, Creator Owner, and so forth.

Other information can be stored in the Configuration container, but some strict criteria should be applied to such data, as follows:

  • The information should be truly globally interesting (for example, the default configuration and policy information for all instances of a given service in the enterprise).
  • The information should be very highly available, such that referencing the information stored in another domain is not sufficient.
  • The volatility of the information should be very low.
  • The volume of the information should be very small.

Note

Global information should be stored in one of two places: in a child of the Services container or in a child of a site object.

The Active Directory Domains and Trusts MMC snap-in displays the hierarchy of domain naming contexts, as named in the Partitions container within the Configuration container. You can use this tool to manage interdomain trust relationships. For information about managing interdomain trust relationships, see “Authentication” in this book.

Managing Configuration Data

Three administrative tools in Windows 2000 enable you to manage different portions of the Configuration container. The following tools are available from the default Administrative Tools menu (on the Programs menu on the Start menu):

  • Active Directory Sites and Services. You can manage the objects in the cn=sites,cn=configuration,dc=domainName,…dc=domainName container and the cn=services,cn=configuration,dc=domainName,…dc=domainName container.
  • Active Directory Tree. You can manage the trust relationships between the domain naming contexts represented in the cn=partitions,cn=configuration,dc=domainName,…dc=domainName container. For information about managing trust relationships, see “Authentication” in this book.
  • Active Directory Schema. You can manage classSchema and attributeSchema objects stored in the Schema container (cn =schema cn=configuration,dc=domainName,…dc=domainName). Active Directory Schema is available as an MMC snap-in that you can install through the MMC Console menu. For information about how to install an MMC snap-in, see Microsoft Windows 2000 Server Help. For information about managing the schema, see “The Active Directory Schema” in this book.

For more information about managing configuration data, see “Managing Active Directory” in this book.

The Schema Naming Context

The Active Directory schema consists of a set of classes, attributes, and syntaxes. Active Directory must enforce the rules of the schema so that objects are created and modified with consistency. Active Directory has a default set of classes and attributes, but these can be modified and added to, according to the needs of the users of the directory service. (For information about default classes and schema, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Development Kit (SDK). Search for MSDN at http://microsoft.com.)

A forest shares a single, partitioned, distributed directory. Because schema consistency is required for object creation and modification throughout that directory, all domains in the forest must have current copies of the schema at all times. For this reason, the schema is implemented as a separate naming context that can be synchronized at will. Consider the scenario where the schema is modified, and then a new instance of the object is created, on one domain controller. Replication of the new object depends on all other domain controllers in the forest receiving the schema update prior to receiving the newly created object. If the changes to both the schema and the domain object were tied to each other, replication could not occur unless the schema change were replicated first. To accommodate this eventuality, Active Directory stores the schema as a separate naming context. In the event replication is blocked because of a modified schema, the schema can be updated separately, allowing normal replication to proceed.

In addition, because the schema stores only schema objects, it can always be synchronized without requiring any additional schema information. The rate of updates to the schema naming context is always likely to be less than those of the Configuration naming context, so synchronizing the schema separately from the Configuration naming context is relatively quick and unencumbered by implications of forest-wide configuration changes.

You can use ADSI Edit to view the Schema naming context objects and properties. Follow the instructions presented in “To view the Configuration container” earlier in this chapter, but select Schema instead of Configuration.

Use the Active Directory Schema MMC snap-in to manage the classSchema and attributeSchema objects.

For information about managing the schema objects, see Microsoft Windows 2000 Server Help. For detailed information about the schema and its contents and about extending the schema, see “The Active Directory Schema” in this book.

Domain Naming Context(s)

When you create a new domain, a domain naming context is created in Active Directory. This naming context represents an Active Directory domain partition. As such, the domain object is created as a container object in Active Directory (class domainDns), and is also added to the list of domain partitions in the Partitions container.

Each domain container has the following child containers:

  • Users

    The default storage area for new users created through legacy APIs that are not Active-Directory–aware.

  • System

    Built-in system settings for the various system service containers and objects.

  • LostAndFound

    Default container for orphaned objects. Whenever replication cannot resolve an object’s location, the object is stored in LostAndFound. For example, if a user deletes a container object from one domain controller and, prior to replication of that deletion, a user on another computer creates an object in that container, the new object is stored in the LostAndFound container.

  • Builtin

    Objects representing the default built-in groups (for example, Builtin\Administrators).

  • Deleted Objects

    A special container where objects are moved when they are deleted. The Deleted Objects container is itself deleted and has a timestamp so far in the future that garbage collection never removes it. This arrangement prevents the directory from filling up with tombstones. The contents of the Deleted Objects container are visible if you search with the 1.2.840.113556.1.4.417 control, which enables you to see deleted objects. In the LDP tool, add the control with no value and specify a search type of “extended” in the search options. (To install LDP, see the Support directory on the Windows 2000 Professional and Windows 2000 Server operating system CDs. For information about using LDP, see LDP Help.)

  • Domain Controllers

    Default container for new Windows 2000 domain controllers.

  • Infrastructure

    Holds information used by the infrastructure master, which keeps interdomain object references up to date. The infrastructure master creates deleted child objects in the Infrastructure container. When these deleted objects replicate, they have the effect of removing outdated phantom records.

  • Computers

    Default storage area for new computers created through legacy APIs that are not Active-Directory-aware.

  • ForeignSecurityPrincipals

    Proxy objects for security principals from downlevel domains or different forests that are added to Windows 2000 groups.

Note

Unlike the Configuration and Schema naming contexts, a full replica of the domain naming context is replicated only between domain controllers within the same domain, not among all domains in the forest. Domain-specific data is replicated in the Global Catalog among domains in the same forest only as partial replicas.


The Directory Data Store

Ntds.dit is a Jet database file. The Windows 2000 Jet database is an improved version of the Jet “Blue” ISAM database. Two copies of Ntds.dit actually are present in separate locations on a given domain controller:

  • %SystemRoot%\NTDS\Ntds.dit

    This file stores the database that is in use on the domain controller. It contains the values for the domain and a replica of the values for the forest (the Configuration container data).

  • %SystemRoot%\System32\Ntds.dit

    This file is the distribution copy of the default directory that is used when promoting a computer running Windows 2000 to a domain controller. The availability of this file allows DcPromo.exe to be run without using the installation CD. During the promotion process, Ntds.dit is copied from the %SystemRoot%\System32 directory into the %SystemRoot%\NTDS directory. Active Directory is then started from the new copy of the file, and replication updates this file from other domain controllers.

    Ntds.dit has two main tables: the data table and the link table. Each object in the directory is represented as one row in the data table, and each attribute is represented as one column in the table. The only exceptions are certain attributes whose values are stored as individual rows in the link table. (See “The Link Table” later in this chapter.) The data table hosts all objects for a given replica, and a replica can host multiple naming contexts — that is, all naming contexts in a replica share a single table.

    To achieve maximum performance, store the directory data file (Ntds.dit) and database log files on separate physical disks. If possible, they should also be separate from the disk(s) that contain the system and page files. DcPromo provides the opportunity to select the location for the Ntds.dit file, the NTDS log files, and the SYSVOL directory.

Note

The drive containing Ntds.dit must be configured for basic storage, not dynamic. In addition, the SYSVOL directory requires NTFS v5.

The Data Table

The data table is the primary table for storing information about objects. Each nonlink attribute has a column in this table, as well as some non-attribute columns used by the directory to maintain the structure of the directory tree. In addition to simply storing the attributes, this table also has a number of indices defined. Some of the indices are over the non-attribute columns and are used by Active Directory to easily traverse the tree and still maintain the directory structure. The remainder of the indices are over specific attributes in the schema, and exist in order to speed searches and to allow sorted output.

The data table contains a relatively small number of fixed columns, where storage is allocated for the column on every row, and a large number of tagged columns, where storage is allocated only if a value is present. The fixed columns are used to maintain the structure of the directory and are generally invisible to clients, while the tagged columns contain the attributes that clients actually see and care about. This division implies that while the tagged columns are replicated from server to server, the fixed columns are managed independently by each server.

Fixed Columns

The fixed columns in the data table are as follows.

  • DNT

    The distinguished name tag (DNT), which is the main identifier for records within the database and is unique for the replica. All references from one object to another within Active Directory are actually stored as the DNT of the referenced object. For example, a user object might have an attribute that defines that user’s manager; the value for that attribute is the DNT of the user object that represents the manager in the database.

  • PDNT

    The parent of the DNT, which is used for navigating the tree hierarchy (for example, “list the children of X” becomes a database query for objects whose PDNTs are equal to the DNT of X). The value in this column is set when the object is created. The user specifies the full name for the new object. The DSA removes the RDN to determine the parent name, then finds that object and gets its DNT, which is used for the PDNT for the newly created object. If the object is later moved to another container in the tree, a similar procedure occurs and the value of the object’s PDNT is changed to the DNT of its new parent.

  • OBJ

    A flag on every record that is used to distinguish phantoms (and objects in the process of being created or destroyed) from real objects. A nonzero setting indicates that the object is real.

  • RDN

    The naming attribute used to hold the RDN of an object. Given the DN of an object, a search uses the RDN to find its record in the database and, hence, its DNT.

  • RDN type

    Holds the attribute type of the RDN for the object as a 4-byte value in an internal and undocumented format. Attribute types are numeric assignments of the string names by which you can recognize attributes. Examples of values stored in the RDN and RDN columns are as follows:

    • For the object ou=BSD,dc=MS,

    RDN would hold “BSD”

    RDN type would hold 11 (the attribute type for organizationalUnitName).

    • For the object cn=printers,ou=BSD,dc=MS,

    RDN would hold “printers”.

    RDN type would hold 3 (the attribute type for commonName).

  • Count

    The reference count on objects, used to tell when it is possible to physically remove the record from the database. A record gets one reference count for each place in the database where the DNT of this record stored.

  • Time

    The deletion time of objects, stored in seconds from Jan 1, 1601, format. This value is used for garbage collection.

  • NCDNT

    The DNT of the object’s naming context master (that is, the object at the top of the naming context containing this object). This value is used in indices to speed replication queries.

  • Ancestors

    Ancestors represents a search optimization. An index over the Ancestors column equates an object’s position in the directory tree to a filter expression and optimizes the filter accordingly.

  • IsVisibleInAB

    Objects that are not visible through the MAPI interface (such as tombstones and objects marked as hidden) must be excluded from the indices used to implement the MAPI address book containers. This column determines whether the object is visible through the MAPI interface. It is computed based on the visibility criteria and is set to the value 1 if the object is to be visible and to NULL (no value) if it is not. All the address book navigation indices are defined as IgnoreAnyNull, which makes objects whose IsVisibleInAB is not set to 1 vanish from the index.

Tagged Columns

The tagged columns store the attributes that can be viewed and managed as object properties. In the database, however, the tagged columns are encoded so that the Database layer can map the attribute ID, which the schema understands, to a Jet column ID that the database understands. This information is used to read the schema objects into the cache (which provides the mapping information) when Active Directory starts.

Phantom Records

As described earlier, all references from one object to another within Active Directory are stored as the DNT of the referenced object. If the referenced object does not exist (for example, a user account in one domain has a manager in a different domain, and a server that is not a Global Catalog server is contacted), a “phantom” is created as a record in the database, and the DNT of that record is used. A phantom record contains the GUID, the SID (for references to security principals), and the DN of the object being referenced. If a copy of the object named in the attribute exists in the local database, no phantom is needed. When an object references an object in an external naming context, the local database uses a phantom record. For example, if an object in the domain dc=noam,dc=itreskit,dc=com holds a reference to an object in dc=europe,dc=itreskit,dc=com, there is a phantom for that object and its parents in dc=noam,dc=itreskit,dc=com. The infrastructure master cleans up phantom objects when the objects they reference are renamed or deleted. For information about the infrastructure master, see “Active Directory Logical Structure” and “Managing Active Directory Servers” in this book.

The Link Table

Some interobject references in the directory require back-references for either usability or administrative purposes. For example, if managedBy is an object property, you can look at ObjectA and determine that ObjectA is managed by ObjectB. Likewise, it is sometimes helpful to be able to look at ObjectB and determine what objects ObjectB manages (the values of the managedObjects property). The two properties on the two objects must be kept synchronized to be useful, which is accomplished by the link table data structure.

Two attributes that are “linked” in this way are marked in the schema as having the same link-pair ID; \ one is marked as the forward link and the other as the back link. Unlike other attributes, whose values are stored in the data table, the values of linked attributes are stored in the link table. For security and replication reasons, only the forward link attribute can be modified. For example, in the managedBy/managedObjects link pair, managedBy is the forward link. Therefore, to adjust the managedObjects attribute on a user object, you must go to the objects you want to add or remove from that user’s managedObjects value and modify the managedBy value on each object. Back-link attributes are computed from the link table when requested.

Note

When extending the schema, you have to know when to make an object a link object. For information about extending the schema, see “The Active Directory Schema” in this book.

The link table has five columns, three of which are important to understand:

  • The DNT of the object that has the forward-link attribute. (In the example, this object is ObjectA, which has the single-valued link attribute managedBy.)
  • The DNT of the object that has the back-link attribute. (In the example, this object is ObjectB, which has the multivalued back-link attribute managedObjects.)
  • link_base. The link-pair ID for this link. (In the example, this pair consists of the attributes managedBy and managedObjects.)

To find all of the objects that ObjectB manages, the link table is examined for all records in which the link_base is the base of managedBy/managedObjects and the backlink_DNT is the DNT of ObjectB. The link_DNTs of those records provide the DNTs of all the records (objects) that are managed by ObjectB.

The managedBy and managedObjects example uses a single-valued forward link and a multivalued back link, respectively, but there is no requirement that the forward link be single-valued. For example, distribution list membership is implemented as a link/back-link pair. The back-link objects would be the objects that store the isMemberOfDl attribute. The forward-link member attribute is multivalued, which allows a user to be a member of more than one distribution list. The back link must always be multivalued because it is impossible to restrict who creates links to various objects.

Table 6.5 shows three columns of a link table that contain some examples of an object (ObjectB) that is the manager of several other objects (ObjectA, ObjectC, and ObjectD). The distribution list (DL1) is an example of an object that has several objects as members.

Table 6.5 Columns in the Link Table That Contain Link (Forward) and Back-Link Data

link_DNT | backlink_DNT | link_base
ObjectA | ObjectB | managedBy/managedObjects
ObjectC | ObjectB | managedBy/managedObjects
ObjectD | ObjectB | managedBy/managedObjects
ObjectE | DL1 | member/memberOfDl
ObjectF | DL1 | member/memberOfDl
ObjectG | DL1 | member/memberOfDl

The remaining two columns in the link table are used to store certain syntaxes that combine a DN with extra data. For example, the wellKnownObjects attribute on domainDNS objects has a value that is a GUID-DN pair. In this case, one of the extra columns in the link table holds the GUID.

Linked attributes are treated specially at object delete time, when all linked attributes are deleted. For example, in the preceding scenario about the managedBy and objectsManaged, if ObjectA were deleted, the managedObjects multivalued attribute on ObjectB would suddenly (and silently, with no change to the update sequence number nor to the whenChanged attribute) lose a value. Similarly, if ObjectB were deleted, the value of the managedBy attribute on ObjectA would suddenly be blank. Nothing about the object changes in either case, except that the attribute value is gone.

Searching on Back Links

When you request the value of a back link on a particular object (for example, “What objects are managed by ObjectB?”), the system implicitly does a search for all objects whose corresponding forward link names the original object (that is, “What objects have ObjectB as the value in their managedBy attribute?”). The results of that search, and hence the apparent contents of the back-link attribute, depend on what the LDAP port is to which the client is bound; that is, the results can differ depending on whether the client binds to the local domain (LDAP port 389) or the Global Catalog (LDAP port 3268).

For example, suppose you are looking at the user object named JohnDoe. You are interested in discovering the groups in which JohnDoe has memberships. Suppose further that JohnDoe is an object in the child domain B that has a parent domain A. If you bind to the JohnDoe object in domain B and read the memberOf property, you will get a list of all group memberships in domain B, including both domain local and global groups; however, you will not see any memberships in groups outside of domain B. On the other hand, if you bind to the copy of the JohnDoe object in the global catalog and read the memberOf attribute, you will see the group memberships in all universal groups in the forest. You will not see any domain local group memberships, however, because local groups are not replicated to the global catalog. Thus, to see all of an object’s memberships, you must search both the local and global catalog copies of the object.

For example, suppose you are interested in discovering the groups in which JohnDoe has memberships. As mentioned earlier, the system implicitly searches for all objects whose forward links name the object (that is, “What group objects have “JohnDoe” as a value for the member attribute?”). Suppose further that JohnDoe is an object in the child domain B that has a parent domain A. Where more than one domain exists in a forest, you must take into account the following group behaviors:

  • By definition, global groups cannot have members from other domains. Therefore, only global groups that are in one domain (the domain to which JohnDoe belongs) can possibly have JohnDoe as a member.
  • Domain local groups can contain members from other domains; however, although domain local group objects are replicated to the Global Catalog, their member attribute is not.

If you bind to the JohnDoe object in domain B and read the memberOf attribute, Active Directory lists all groups in domain B that have JohnDoe as a member, including both local and global groups; however, no groups except for domain B, the domain to which JohnDoe belongs, are visible.

If you bind to the copy of the JohnDoe object in the Global Catalog and read the memberOf attribute, which of the groups are listed depends on what domain stores the Global Catalog.

  • If the Global Catalog is stored in domain A, Active Directory lists the group memberships in all global groups in the forest. However, Active Directory does not list domain local groups in domain B because although domain local group objects are replicated to domain controllers, their member attributes are not. Thus, to see all of an object’s memberships, you must search both the local domain (domain B) and Global Catalog copies (in domain A) of the object, unless the domain controller is a Global Catalog server.
  • If the Global Catalog server is also a domain controller in domain B, Active Directory lists both global groups and domain local groups of which JohnDoe is an immediate member. Assuming that there is a Global Catalog server in the local domain, this local Global Catalog server is the best server to search.

Note

Memberships in domains external to the forest are not found in either type of search because they are outside of the scope of the forest. These memberships must be discovered using the respective virtual container.

Group Members from External Domains

If you add a member of a trusted domain from a different forest to a group in your domain, Active Directory creates a placeholder object of the class foreignSecurityPrincipal (FSPO). This object takes the place of the real object, about which Active Directory has no information because the object exists in a different forest. When you list the members of a group, Active Directory lists the DNs of the group members. For a member that is from an external domain, Active Directory displays the DN of the FSPO in the form of a NetBIOS name. For example, the user JohnD from the domain Acquired.com would appear as JohnD in Acquired, shown in Figure 6.7.

Figure 6.7 The Members Tab for a Group that Displays the Distinguished Name of an FSPO

If you open the properties on the foreign group member, a message is displayed that explains that the member is not a real object in Active Directory but a placeholder, as shown in Figure 6.8.

Figure 6.8 The Properties for a Member from an External Domain

The object SID is displayed in the title bar of the dialog box. You could use this value in an LDAP query to determine the LDAP name of the object. Such a query would involve enumerating all trusted domains and then issuing a query on each one for the object whose objectSid attribute value matches the SID of the FSPO.

Atomic Transactions

Procedure calls to Active Directory are atomic — that is, they are either completed in full or are not begun at all. Any updates that a transaction might effect on a system are completed in their entirety. If for any reason an error occurs and the transaction is unable to complete all of its steps, the system is returned to the state it was in before the transaction was started. An example of an atomic transaction is an account transfer transaction. The money is removed from account A, then placed into account B. If the system fails after it removes the money from account A, the transaction processing system puts the money back into account A, and, thus, returns the system to its original state — that is, it rolls back the transaction.

Log-based Recovery

The Active Directory logging and recovery system is designed to guarantee data integrity and consistency in the case of a system crash or media failure. Logging is the process of recording database operations in a log file. Recovery is the process of using the log file to restore a database to a consistent state after a system crash and to restore a database from a backup to the most recent state recorded in the log file after a media failure.

Transaction operations are logged and the log is written to disk during each commit to transaction level 0 (that is, to a level that is not inside any other transaction). Thus, the recovery operation can re-do updates made by transactions committed to transaction level 0 and undo updates made by transactions that did not commit to transaction level 0. This type of recovery is often referred to as a roll-forward/roll-backward recovery scheme.

For information about backing up and recovering Active Directory, see “Managing Active Directory” in this book.

Circular vs. Sequential Logging

Active Directory uses sequential (noncircular) logging, which creates a binary-format log file. Binary files can record intermittent data instances that stop and start while the log is running. Sequential logging truncates the logs during normal garbage collection operations, which occur at a set interval. (The default interval is every 12 hours.)

Circular logging keeps the log file size to a minimum by overwriting data that is no longer needed as rapidly as possible.

Active Directory logging defaults to sequential, as specified by a 0 value in the CircularLogging entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. If you prefer to use circular logging to minimize the space taken by log files, you can activate circular logging by changing the CircularLogging value from 0 to 1.

When all changes have been written to the database file, a log file is usually no longer needed. However, having several hours worth of log files is a protective measure in the event of database corruption and provides better ability to trace the source of the corruption.

For information about using the Ntdsutil tool to managing log files, see the Support directory on the Microsoft® Windows® 2000 Server operating system CD.

Attribute Indexing

A database table is a homogeneous collection of records, where each record has one or more values for each defined column. The rows, or records, represent objects in the directory; the columns represent the attributes of which the objects are composed. The names of all possible columns in a record are defined for the entire table. In this sense, any record is potentially like any other record in the table. However, it is possible to define many columns for a table, yet have any given record contain only a small number of non-NULL column occurrences, in effect accommodating a number of different record classes in the same table.

The columns, or attributes, can be indexed to decrease the time required to locate a record in a large database — that is, a certain attribute or combination of attributes can be used to uniquely identify a record. Tables can have zero or more indexes to allow random access to records by attribute values. An index on a table specifies a particular ordering for the records and provides a means for direct record retrieval. An index key is a sequence of attributes from the table, also called a key segment, whose value uniquely identifies each row in the table. Ascending or descending order is specified by the DSA for any key segment. Any number of indexes can be defined for a table.

In Active Directory, many default attributes are indexed. You can select other attributes for indexing by using Active Directory Schema Manager. When you open the properties for an attribute object, you can see whether the attribute is already selected for indexing and, if it is not, you can select it. When you select an attribute to be indexed, you set the “make index” flag. The value of this flag is replicated, and the indexing is performed by the DSA when the schema is refreshed. Likewise, if you reverse the selection, the change is effected when the schema is refreshed.

Table Space Allocation

To localize disk access, particularly sequential scans, table space is allocated in contiguous extents of storage on the disk. Table growth beyond the initial allocation is incremented in fractions of the initial allocation. Records are physically stored in chronological order, if no clustered index is specified, or in clustered index order, if a clustered index is specified. If an insert or update operation causes a page to overflow, the page is split; a new page is allocated and is logically chained in between two previous pages. Because the new page is not physically adjacent to its logical neighbors, access to it is not as efficient; therefore, tables subject to frequent insertions can be reorganized periodically using Ntdsutil to defragment the database.


Authentication

The default protocol for network authentication in Microsoft® Windows® 2000 is the Kerberos v5 authentication protocol. An emerging authentication standard, the Kerberos protocol provides a foundation for interoperability. It also enhances the security of enterprise-wide network authentication. Key components of the protocol’s implementation in Windows 2000 include the following:

  • Integration of initial authentication with the Winlogon single sign-on architecture.
  • Use of Active Directory™, the directory service included in Windows 2000,in the Windows 2000 domain as the domain’s security account database.
  • Implementation of the Kerberos client as a Windows 2000 security provider through the Security Support Provider Interface (SSPI).

In This Chapter

Basic Concepts of Authentication

Authentication Protocols

How Kerberos Authentication Works

Kerberos Components in Windows 2000

Authorization Data

Interactive Logon

Related Chapters in the Resource Kit

  • For more information about how network clients find a domain controller, see “Active Directory Data Storage and Name Resolution” in this book.
  • υFor more information about authorization, see “Access Control” in this book.
  • For more information about Kerberos authentication policy, see “Security Policies” in this book.


Basic Concepts of Authentication

Authentication is a process for verifying the identity of something or someone. When you authenticate an object, the goal is to verify that you have the genuine article. When you authenticate a person, the goal is to verify that you are not dealing with an imposter.

Both kinds of authentication occur when you cross an international border. A guard asks for credentials; you present a passport. The guard authenticates the passport by verifying that it was issued by a security authority the local government trusts — trusts, at least, to issue passports. The guard authenticates you by verifying that your face matches the face of the person pictured on the passport. If the passport proves to be valid and you prove to be its owner, you are allowed to proceed. Otherwise, you are denied access to the country you want to enter.

The kind of authentication that takes place at an international border is based on trust. The local government does not know you, but it trusts that your government does. When your government issued your passport, it did not know you either. It trusted the agency that issued your birth certificate. The agency that issued your birth certificate in turn trusted the physician who signed the certificate. The physician witnessed your birth and stamped the certificate with your footprint, direct proof of your identity. Trust transferred in this way, through trusted intermediaries, is transitive. Transitive trust between security authorities is the foundation for network security in Windows 2000.


Interactive Logon

Logging on at the keyboard of a computer running Windows 2000 is like crossing an international border. A guard asks for identification; you present credentials issued by a trusted authority. In this case, the guard is Winlogon, a security service running in a process it shares with the Local Security Authority (LSA). Winlogon displays a dialog box that asks you to identify your account and the security authority who issued it. It also requires you to substantiate your claim that you are the account holder, which on standard Windows 2000 systems you do by typing a password. On specially equipped systems, your credentials might be taken from a smart card that you insert into a card reader. Whatever proof of identity you supply, Winlogon collects it, packages it in a data structure, and passes everything to the LSA for verification. If the LSA can verify that your account is valid and that you are the account holder, Winlogon sets up an interactive session on the computer. Otherwise, you are denied access to the computer.

How the LSA verifies your identity depends on where your account was issued. If your account was issued by the LSA itself, the LSA can validate your information by checking its own account database. If you are using an account issued by the security authority for the local domain or by the security authority for a trusted domain, the LSA must contact the issuing authority and ask it to verify that the account is valid and that you are the account holder.


Remote Logon

No matter where your credentials are authenticated, the process establishes your identity with just one security authority — the LSA on the computer where you are logging on. The fact that you are able to use a domain account means only that the LSA on your workstation trusts the security authority for the domain. Other Windows 2000 computers in the domain share the same trust, yet before you can browse those computers you must log on to each of them as well. It does not matter that your “passport” was stamped at the border of the last computer where you logged on. You must show it again whenever you want access to another network client that is running Windows 2000.

When you want access to a system across the network that is running Windows 2000 from the computer where you have logged on, you are not required to provide information in a dialog box as you are required to do when you log on at a keyboard. Instead, the LSA on your workstation establishes your identity with the LSA on the remote computer by using the credentials that were cached during your initial interactive logon to the network.


Security Principals

In Windows 2000, any entity that can initiate action is a security principal. Thus, security principals can be either human users or inanimate entities such as computers or services (“daemons,” if you are from the UNIX world). Security principals establish a context for their actions by presenting credentials from a security authority that is trusted by the LSA on the computer where the principal intends to act.

For example, Windows 2000 computers participate in a network domain by communicating with a domain controller, and they do this even when no human user is logged on. To initiate communications, the computer must have an account in the domain and must present credentials to prove that it is the account holder. Before accepting communications from the computer, the LSA on the domain controller authenticates the computer’s identity just as it would for a human security principal.

Although most Windows 2000 applications run in the security context of the user who starts them, this is not true of services. Windows 2000 services are started by the service controller, often automatically when the computer boots. They continue to run long after the last human user has logged off. Services have to log on to domain accounts to gain access to domain resources, just as human users and Windows 2000 computers do. Before starting a service, the service controller logs on to the account designated for the service and presents the service’s credentials for authentication by the LSA.

For example, when a Windows 2000 computer joins a domain, the Netlogon service on the computer connects to a domain controller and opens a secure channel to it. To obtain an authenticated connection, Netlogon must have credentials that are trusted by the remote computer’s LSA. It uses credentials for the local computer’s domain account, just as all other services running as Local System do. Any service not running as Local System must have its own domain account.


Authentication Protocols

Windows 2000 supports several protocols for verifying the identities of users who claim to have accounts on the system. These include protocols for authenticating dial-up connections and protocols for authenticating external users who are trying to connect to the network over the Internet. However, there are only two choices for network authentication within and between Windows 2000 domains:

  • Kerberos v5 Protocol

    The Kerberos v5 authentication protocol is the default for network authentication on computers that are running Windows 2000. Kerberos authentication is also available on computers that run either Microsoft® Windows® 95 or Microsoft® Windows® 98 if you install the Distributed Systems Client upgrade on these computers.

  • NTLM Protocol

    The Windows NTLM protocol was the default for network authentication in Microsoft® Windows NT® version 4.0. It is retained in Windows 2000 for compatibility with clients and servers that are running versions of Windows NT 4.0 and earlier. It is also used to authenticate logons to standalone computers that are running Windows 2000.

The Kerberos protocol is the protocol of choice in Windows 2000, when there is a choice. Computers that are running Microsoft® Windows® version 3.11 or Windows NT 4.0 must use the NTLM protocol for network authentication in Windows 2000 domains. Computers that are running Windows 2000 must use NTLM when they are authenticating to servers that are running Windows NT 4.0 and when they are requesting access to resources in Windows NT 4.0 domains.


How Kerberos Authentication Works

The Kerberos authentication protocol provides a mechanism for mutual authentication between a client and a server before a network connection is opened between them. The protocol assumes that initial transactions between clients and servers take place on an open network — an environment where most clients and many servers are not physically secure and packets traveling along the network can be monitored and modified at will. In other words, the protocol is designed for an environment that is much like today’s Internet, where an attacker can pose easily as either a client or a server and readily eavesdrop on or tamper with communications between legitimate clients and servers.


Basic Concepts for the Kerberos Protocol

The Kerberos protocol relies heavily on an authentication technique that makes use of shared secrets. The basic concept is quite simple: If a secret is known by only two people, either person can verify the identity of the other by confirming that the other person knows the secret.

For example, let’s suppose that Alice often sends messages to Bob and that Bob needs to be sure that a message from Alice really has come from Alice before he acts on its information. They decide to solve their problem by selecting a password, and they agree not to share this secret with anyone else. If Alice’s messages can somehow demonstrate that the sender knows the password, Bob will know that the sender is Alice.

The only question left for Alice and Bob to resolve is how Alice will show that she knows the password. She could simply include it somewhere in her messages, perhaps in a signature block at the end — Alice, Our$ecret. This would be simple and efficient and might even work if Alice and Bob can be sure that no one else is reading their mail. Unfortunately, that is not the case. Their messages pass over a network used by people like Carol, who has a network analyzer and a hobby of scanning traffic in hope that one day she might spot a password. So it is out of the question for Alice to prove that she knows the secret simply by saying it. To keep the password secret, she must show that she knows it without revealing it.

The Kerberos protocol solves this problem with secret key cryptography. Rather than sharing a password, communication partners share a cryptographic key, and they use knowledge of this key to verify one another’s identity. For the technique to work, the shared key must be symmetric — a single key must be capable of both encryption and decryption. One party proves knowledge of the key by encrypting a piece of information, the other by decrypting it.

Authenticators

A simple protocol that uses secret key authentication begins when someone is outside a communications door and wants to go in. To gain entry, this person presents an authenticator in the form of a piece of information encrypted in the secret key. The information in the authenticator must be different each time the protocol is executed, otherwise an old authenticator could be reused by anyone who happens to overhear the communication. Upon receiving an authenticator, the person guarding the door decrypts it and knows from what is inside it whether the decryption was successful. If it was successful, the doorkeeper knows that the person presenting the authenticator has the correct key. Only two people have the key; the doorkeeper is one of them, so the person who presented the authenticator must be the other one.

If the person outside the door wants mutual authentication, the same protocol can be executed in reverse, with a slight difference. The doorkeeper can extract part of the information from the original authenticator, encrypt it in a new authenticator, and then give the new authenticator to the person waiting outside the door. The person outside the door can then decrypt the doorkeeper’s authenticator and compare the result with the original. If there is a match, the person outside the door will know that the doorkeeper was able to decrypt the original, so he must have the correct key.

It might help to walk through an example. Suppose Alice and Bob decide that before transferring any information between their computers, each will use knowledge of a shared secret key to verify the identity of the party at the other end of the connection. In situations where Alice is the wary guest and Bob is the suspicious host, they agree to follow this protocol:

  1. Alice sends Bob a message containing her name in plaintext and an authenticator encrypted in the secret key she shares with Bob. In this protocol, the authenticator is a data structure with two fields. One field contains information about Alice. For simplicity, let’s say this is another instance of her name. The second field contains the current time on Alice’s workstation.
  2. Bob receives the message, sees that it is from someone claiming to be Alice, and uses the key he shares with Alice to decrypt the authenticator. He extracts the field that contains the time on Alice’s workstation and evaluates the time.

    Bob’s task will be easier if his clock is reasonably synchronized with Alice’s clock, so let’s suppose both Alice and Bob use a network time service to keep their clock times fairly close. Let’s say the time skew is never more than five minutes. This way, Bob can compare the time from the authenticator with the current time on his clock. If the difference is greater than five minutes, he can automatically reject the authenticator.

    If the time is within the allowable skew, it’s probable that the authenticator came from Alice, but Bob still does not have proof that it actually came from her. Another person might have been watching network traffic and might now be replaying an earlier attempt by Alice to establish a connection with Bob. However, if Bob has recorded the times of the authenticators that were received from Alice during the past five minutes, he can defeat attempts to replay earlier messages by rejecting any message with a time that is the same as or earlier than the time of the last authenticator. If this authenticator yields a time later than the time of the last authenticator from Alice, then this message must be from Alice.

  3. Bob uses the key he shares with Alice to encrypt the time shown on Alice’s message and sends the result back to her.

    Note that Bob does not send back all of the information taken from Alice’s authenticator, just the time. If he sent back everything, Alice would have no way of knowing whether someone posing as Bob had simply copied the authenticator from her original message and sent it back to her unchanged. He sends just a piece of the information in order to demonstrate that he was able to decrypt the authenticator and manipulate the information inside. He chooses the time because that is the one piece of information that is sure to be unique in Alice’s message to him.

  4. Alice receives Bob’s reply, decrypts it, and compares the result with the time in her original authenticator. If the times match, she can be confident that her authenticator reached someone who knows the secret key needed to decrypt it and extract the time. She shares that key only with Bob, so it must be Bob who received her message and replied.

This process is illustrated in Figure 9.1.

Figure 9.1 A Simple Protocol for Mutual Authentication

Key Distribution

One problem with the simple protocol described in the preceding section is that it does not explain how or where Alice and Bob got a secret key to use in their communications with each other. If they are people, Alice and Bob could meet, perhaps in an alley, and agree on a secret key. But if Alice is a client program that is running on a workstation and Bob is a service that is running on a computer somewhere across the network, that method will not work. There is the further problem that the client, Alice, will want to talk to many services and will need keys for each of them. Likewise, the service, Bob, will talk to many clients and will need keys for each of them. If each client needs a key for every service and each service needs a key for every client, key distribution could quickly become a difficult problem to solve. And the need to store and protect so many keys on so many computers would present an enormous security risk.

The name Kerberos suggests how the protocol resolves the problem of key distribution. Kerberos (also known as Cerberus) was a figure in classical Greek mythology, a three-headed dog who kept living intruders from entering the Underworld. Like the mythical guard dog, the protocol has three heads, which in this case are a client, a server, and a trusted third party that mediates between the client and server. The trusted intermediary in the protocol is known as the Key Distribution Center (KDC).

The KDC is a service that runs on a physically secure server. It maintains a database with account information for all security principals in its realm — the protocol’s equivalent of a Windows 2000 domain. Along with other information about each security principal, the KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long-term key. In most implementations of the protocol, the long-term key is derived from a user’s logon password.

When a client wants to talk to a server, the client sends a request to the KDC, and the KDC distributes a unique session key for the two parties to use when they authenticate each other, as illustrated in Figure 9.2. The server’s copy of the session key is encrypted in the server’s long-term key. The client’s copy of the session key is encrypted in the client’s long-term key.

Figure 9.2 Key Distribution (in Theory)

In theory, the KDC could fulfill its role as a trusted intermediary by sending the session key directly to each of the security principals involved, as illustrated in Figure 9.2. But, in practice, that procedure would be extremely difficult to implement. For one thing, it would mean that the server would have to retain its copy of the session key in memory while it waited for the client to call. Moreover, the server would need to remember a key not just for this client but for every client who might ask for service. Key management would consume considerable resources on the server and would thus limit its scalability. In addition, given the vagaries of network traffic, a client’s request for service might reach the server before the KDC’s message arrived there with the session key. The server would have to suspend its reply to the client while it waited to hear from the KDC. This would require the server to save state, imposing still another burden on the server’s resources. What actually happens in the Kerberos protocol is considerably more efficient.

Session Tickets

The KDC responds to the client’s request to talk to a server by sending both copies of the session key to the client, as shown in Figure 9.3. The client’s copy of the session key is encrypted with the key that the KDC shares with the client. The server’s copy of the session key is embedded, along with authorization data for the client, in a data structure called a session ticket. The entire structure is then encrypted with the key that the KDC shares with the server. The session ticket — with the server’s copy of the session key safely inside — becomes the client’s responsibility to manage until it contacts the server.

Figure 9.3 Key Distribution (in Practice)

Note that the KDC is simply providing a ticket-granting service. It does not keep track of its messages to make sure they reach the intended address. No harm will be done if the KDC’s messages fall into the wrong hands. Only someone who knows the client’s secret key can decrypt the client’s copy of the session key. Only someone who knows the server’s secret key can read what is inside the ticket.

When the client receives the KDC’s reply, it extracts the ticket and the client’s copy of the session key, putting both aside in a secure cache, which is located in volatile memory, not on disk. When the client wants admission to the server, it sends the server a message that consists of the session ticket, which is still encrypted with the server’s secret key, and an authenticator, which is encrypted with the session key, as illustrated in Figure 9.4. The session ticket and authenticator together are the client’s credentials to the server.

Figure 9.4 Mutual Authentication (Client/Server)

When the server receives credentials from a client, it decrypts the session ticket with its secret key, extracts the session key, and uses the session key to decrypt the client’s authenticator. If everything checks out, the server knows that the client’s credentials were issued by a trusted authority, the KDC. If the client has asked for mutual authentication, the server responds by using the session key to encrypt the timestamp from the client’s authenticator. The server then returns the encrypted timestamp to the client, just as Bob returned the encrypted timestamp to Alice in the communication illustrated in Figure 9.1.

One benefit of using session tickets is that the server does not have to store the session key that it uses with this client. It is the client’s responsibility to hold a session ticket for the server in its credentials cache and present the ticket each time it wants access to the server. Whenever the server receives a session ticket from a client, it can use its secret key to decrypt the ticket and extract the session key. When the server no longer needs the session key, it can discard it.

Another benefit of using session tickets is that the client does not have to go back to the KDC each time it wants access to a particular server. Session tickets can be reused. As a precaution against the possibility that someone might steal a copy of a ticket, session tickets have an expiration time that is specified by the KDC in the ticket’s data structure. How long a session ticket is valid depends on the Kerberos policy for the domain. Typically, tickets are good for no longer than eight hours, about the length of a normal logon session. When the user logs off, the credentials cache is flushed and all session tickets — as well as all session keys — are destroyed.

Ticket-Granting Tickets

A user’s long-term key is derived from a password. When Alice logs on, for example, the Kerberos client on her workstation accepts her password and then converts it to a cryptographic key by passing the text of the password through a one-way hashing function.

The KDC gets its copy of Alice’s long-term key from her record in its account database. When it receives a request from the Kerberos client on Alice’s workstation, the KDC searches its database for Alice, pulls up her account record, and takes her long-term key from a field in the record.

This process of computing one copy of the key from a password and fetching another copy of the key from a database actually takes place only once, when a user initially logs on to the network. Immediately after accepting the user’s password and deriving the user’s long-term key, the Kerberos client on the user’s workstation asks the KDC for a session ticket and session key that it can use in subsequent transactions with the KDC during this logon sesssion.

The KDC responds to the client’s request by returning a session ticket for itself. This special session ticket is called a ticket-granting ticket (TGT). Like an ordinary session ticket, a TGT contains a copy of the session key that the service (in this case the KDC) will use in communicating with the client. The message that returns the TGT to the client also includes a copy of the session key that the client can use in communicating with the KDC. The TGT is encrypted in the KDC’s long-term key. The client’s copy of the sesssion key is encrypted in the user’s long-term key.

When the client receives the KDC’s reply to its initial request, it uses its cached copy of the user’s long-term key to decrypt its copy of the session key. It can then discard the long-term key derived from the user’s password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, it is called a logon session key.

From the client’s point of view, a TGT is just another ticket. Before it attempts to connect to a service, the client first checks its credentials cache for a session ticket to that service. If it does not have one, it checks the cache again for a TGT. If it finds a TGT, the client fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a session ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain — it requires a session key, an authenticator, and a ticket (in this case, a TGT).

From the KDC’s point of view, TGTs allow it to shave a few nanoseconds off the turnaround time for ticket requests. The KDC looks up the user’s long-term key only once, when it grants an initial TGT. For all other exchanges with this client, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the client’s authenticator.

Authentication Across Domain Boundaries

The functions of the KDC are divided into two distinct services: an authentication service, whose job is to issue TGTs, and a ticket-granting service, whose job is to issue session tickets. This division of labor allows the Kerberos protocol to operate across domain boundaries. A client can get a TGT from the authentication service of one domain and use it to get session tickets from the ticket-granting service of another domain.

The easiest way to grasp how cross-domain authentication works is to consider the simplest case — a network that has only two domains. For our example, let’s say one domain is East and the other domain is West. If the administrators for these domains are members of the same organization (or if for some other reason, they are willing to treat each other’s domain users as their own), they can enable authentication across domain boundaries by sharing interdomain keys. (In Windows 2000 this happens automatically when two domains establish a trust relationship.) Once this is accomplished, the ticket-granting service in each domain is registered as a security principal with the other domain’s KDC. This means the ticket-granting service in each domain can treat the ticket-granting service in the other domain as just another service, something for which properly authenticated clients can request and receive session tickets.

When a user with an account in East wants access to a server with an account in West, the Kerberos client on the user’s workstation sends a request for a session ticket to the ticket-granting service in the user’s account domain, East. The ticket-granting service in East sees that the desired server is not a security principal in its own domain, so it replies by sending the client a referral ticket. This is simply a TGT that is encrypted with the interdomain key shared by the KDC in East and the KDC in West. The client uses the referral ticket to prepare a second request for a session ticket, and this time sends the request to the ticket-granting service in the server’s account domain, West. The ticket-granting service in West uses its copy of the interdomain key to decrypt the referral ticket. If decryption is successful, it sends the client a session ticket to the desired server in its domain.

The referral process is more complicated on networks with more than two domains. In theory, the KDC in each domain could establish a direct link to the KDC in every other domain on the network, in each case sharing a different inter-domain key. In practice, the number and complexity of these relationships could easily become unmanageable, especially on a large network. The Kerberos protocol solves the problem by making direct links unnecessary. A client in one domain can get a ticket to a server in another domain by traveling a referral path through one or more intermediate domains.

For example, consider a network with three domains, East, West, and CorpHQ. The KDC in East does not share an inter-domain key with the KDC in West, but both East and West do share inter-domain keys with CorpHQ. In this case, when a user with an account in East wants access to a server with an account in West, the referral path begins at the KDC for the user’s account domain, East, passes through an intermediate domain, CorpHQ, and ends at the KDC for the server’s account domain, West. The client must send its request for a session ticket three times, to three different KDCs.

  1. The client asks the KDC for East to give it a ticket to the server in West.

    The KDC for East sends the client a referral ticket to the KDC for CorpHQ. This ticket is encrypted in the interdomain key East shares with CorpHQ.

  2. The client asks the KDC for CorpHQ to give it a ticket to the server in West.

    The KDC for CorpHQ sends the client a referral ticket to the KDC for West. This ticket is encrypted in the interdomain key CorpHQ shares with West.

  3. The client asks the KDC for West to give it a ticket to the server in West.

    The KDC in West replies by sending a ticket for the server in West.


Subprotocols

he Kerberos protocol is comprised of three subprotocols. The subprotocol in which the KDC gives the client a logon session key and a TGT is known as the Authentication Service (AS) Exchange. The subprotocol in which the KDC distributes a service session key and a session ticket for the service is known as the Ticket-Granting Service (TGS) Exchange. The subprotocol in which the client presents the session ticket for admission to a service is called the Client/Server (CS) Exchange.

To see how the three subprotocols work together, let’s look at how Alice, a user at a workstation, gets access to Bob, a service on the network.

AS Exchange

Alice begins by logging on to the network. She types her logon name and her password. The Kerberos client running on Alice’s workstation converts her password to an encryption key and saves the result in its credentials cache.

The client then sends the KDC’s authentication service a Kerberos Authentication Service Request (KRB_AS_REQ). The first part of this message identifies the user, Alice, and the service for which she is requesting credentials, the ticket-granting service, as illustrated in Figure 9.5. The second part of the message contains pre-authentication data that proves Alice knows the password. This data is usually a timestamp encrypted with Alice’s long-term key, although the protocol permits other forms of pre-authentication data.

Figure 9.5 AS Exchange

When the KDC receives KRB_AS_REQ, it looks up the user, Alice, in its database, gets her long-term key, decrypts the pre-authentication data, and evaluates the timestamp inside. If the timestamp passes the test, the KDC can be assured that the pre-authentication data was encrypted with Alice’s long-term key and thus that the client is genuine.

After it has verified Alice’s identity, the KDC creates credentials that the Kerberos client on her workstation can present to the ticket-granting service. First, the KDC invents a logon session key and encrypts a copy of it with Alice’s long-term key. Second, it embeds another copy of the logon session key in a TGT, along with other information about Alice, such as her authorization data. The KDC encrypts the TGT with its own long-term key. Finally, it sends these credentials back to the client in a Kerberos Authentication Service Reply (KRB_AS_REP).

When the client receives the reply, it uses the key derived from Alice’s password to decrypt her logon session key and stores the key in its credentials cache. Then the client extracts the TGT from the message and stores that in its credentials cache as well.

TGS Exchange

The Kerberos client on Alice’s workstation requests credentials for the service, Bob, by sending a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ), as illustrated in Figure 9.6. This message includes the user’s name, an authenticator encrypted with the user’s logon session key, the TGT obtained in the AS Exchange, and the name of the service for which the user wants a ticket.

Figure 9.6 TGS Exchange

When the KDC receives KRB_TGS_REQ, it decrypts the TGT with its secret key and extracts Alice’s logon session key. It uses the logon session key to decrypt the authenticator and evaluates that. If the authenticator passes the test, the KDC extracts Alice’s authorization data from the TGT and invents a session key for the client, Alice, to share with the service, Bob. The KDC encrypts one copy of this session key with Alice’s logon session key. It embeds another copy of the session key in a ticket, along with Alice’s authorization data, and encrypts the ticket with Bob’s long-term key. The KDC then sends these credentials back to the client in a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).

When the client receives the reply, it uses Alice’s logon session key to decrypt the session key to use with the service, and stores the key in its credentials cache. Then it extracts the ticket to the service and stores that in its cache.

CS Exchange

The Kerberos client on Alice’s workstation requests service from Bob by sending Bob a Kerberos Application Request (KRB_AP_REQ), as illustrated in Figure 9.7. This message contains an authenticator encrypted with the session key for the service, the ticket obtained in the TGS Exchange, and a flag indicating whether the client wants mutual authentication. (The setting of this flag is one of the options in configuring Kerberos. The user is never asked.)

Figure 9.7 CS Exchange

The service, Bob, receives KRB_AP_REQ, decrypts the ticket, and extracts Alice’s authorization data and the session key. Bob uses the session key to decrypt Alice’s authenticator and then evaluates the timestamp inside. If the authenticator passes the test, Bob looks for a mutual authentication flag in the client’s request. If the flag is set, he uses the session key to encrypt the time from Alice’s authenticator and returns the result in a Kerberos Application Reply (KRB_AP_REP).

When the client on Alice’s workstation receives KRB_AP_REP, it decrypts Bob’s authenticator with the session key it shares with Bob and compares the time returned by the service with the time in the client’s original authenticator. If the times match, the client knows that the service is genuine, and the connection proceeds. During the connection, the session key can be used to encrypt application data, or the client and server can share another key for this purpose.


Tickets

What is in a ticket, how ticket expiration times are calculated, and how much of a ticket’s content is known by the client are important things to know when you want to configure Kerberos policy; therefore, they deserve a closer look.

What Is in a Ticket

Kerberos messages and tickets have a precise data structure and format. For more detailed information about ticket fields and flags, see RFC 1510.

How the KDC Limits a Ticket’s Lifetime

Kerberos tickets have a start time and an expiration time. At any time after the start time but before the expiration time, a client holding a session ticket for a particular service can present the ticket and gain access to the service, no matter how many times the client has used the ticket previously. To reduce the risk of a ticket or its corresponding session key being compromised, administrators can set a maximum lifetime for tickets. This value is one element of Kerberos policy an administrator can set for the domain.

When a client asks the KDC for a session ticket to a service, it can request a specific start time. If this time is missing from a request or it is a time already past, the KDC sets the ticket’s starttime field to the current time.

Whether or not clients specify a start time, their requests must include an expiration time. The KDC determines the value of a ticket’s endtime field by adding the maximum ticket life fixed by Kerberos policy to the value of the ticket’s starttime field. It then compares the result with the requested expiration time. Whichever of these times is earliest becomes the ticket’s endtime.

Renewable Tickets

Encryption keys wear out with frequent use. The more often an encryption key is used, the more examples of the key an attacker has available to study and the greater the temptation for this person to expend the effort necessary to break the code. The keys used most often in the Kerberos protocol are the session keys. Clients use the same key each time they connect to a server, for as long as the session ticket remains valid. When the ticket expires, the client gets a new ticket with a fresh session key, but until then, the key is not changed.

One way to limit the exposure of session keys to potential attackers is to force the session keys to change often. You can do this by setting Kerberos policy so that the maximum session ticket life is relatively short. Another strategy is to permit tickets to be renewed, which allows session keys to be refreshed periodically without having to issue a completely new ticket. If Kerberos policy permits renewable tickets, the KDC sets a RENEWABLE flag in every session ticket it issues and sets two expiration times in the ticket. One expiration time limits the life of the current instance of the ticket. The second expiration time sets a limit on the cumulative lifetime of all instances of the ticket.

The expiration time for the current instance of a session ticket is held in the endtime field. Just as for nonrenewable session tickets, endtime is the value of the starttime field plus the maximum ticket life specified by the Kerberos policy. A client holding a renewable ticket must present it to the KDC for renewal before the endtime is reached and present a fresh authenticator as well. When the KDC receives a session ticket for renewal, it checks a second expiration time held in the renew-till field. This time is set when the ticket is first issued; the value is the session ticket’s starttime plus the maximum cumulative ticket life specified by the Kerberos policy. When the KDC renews the ticket, it checks to see that the renew-till time has not yet arrived. If it has not arrived, the KDC issues a new instance of the session ticket with a later endtime and a new session key.

This means that administrators can set Kerberos policy can so that session tickets must be renewed at relatively short intervals — every day, perhaps. When tickets are renewed, a new session key is issued, which minimizes the value of a compromised key. At the same time, administrators can also set the cumulative session ticket life for a relatively long period — one month, one year, or whatever. At the end of that time, the session ticket expires and is no longer valid for renewal.

What Happens When Tickets Expire

When a session ticket expires, ongoing operations are not interrupted because session tickets are used only to authenticate new connections with servers. After the connection has been set up, it no longer matters whether the session ticket is still valid. However, when a TGT expires, the Kerberos client might have to interrupt the activities of the user to ask for a password.

The KDC does not notify clients when their session tickets or TGTs are about to expire. In fact, it does not keep track of transactions with clients beyond the short-term records required to prevent replay attacks. If a client presents an outdated TGT to the KDC’s ticket-granting service, the service responds with an error message. Network servers also return error messages when they receive expired tickets. All responsibility for renewing or replacing tickets rests with the client.

What Clients Know About Tickets

Clients have to know some of the information that is inside session tickets and TGTs in order to manage their credentials cache. When the KDC returns a ticket and session key as the result of an AS Exchange or TGS Exchange, it packages the client’s copy of the session key in a data structure that includes the information in the ticket’s flags, authtime, starttime, endtime, and renew-till fields. The entire structure is encrypted in the client’s key and returned in a KRB_AS_REP or KRB_TGS_REP reply message.


Delegation of Authentication

Multi-tier client/server applications present a special situation for the Kerberos protocol. In this kind of application, a client might connect to a server that must connect to a second server on the back end. For this to happen, the first server must have a session ticket to the second server. Ideally, this session ticket should limit the first server’s access on the second server to what the client is authorized to do, rather than what the server is authorized to do.

The Kerberos protocol deals with this situation through a mechanism known as delegation of authentication. Essentially, the client delegates authentication to a server by telling the KDC that the server is authorized to represent the client.

Delegation can be done in two ways. One way is for the client to get a session ticket for the back-end server and give it to the front-end server. Tickets obtained in this way — by a client for a proxy — are called proxy tickets. The difficulty with using proxy tickets is that the client must know the name of the back-end server. This difficulty is overcome by the second method of delegation, which allows the client to give the front-end server a TGT that the front-end server can use to request session tickets for the back-end server as needed. Session tickets obtained in this way — with credentials forwarded by a client — are called forwarded tickets. Whether the KDC allows clients to obtain proxy tickets or forwardable TGTs is determined by the Kerberos policy set by an administrator for the domain.

Proxy Tickets

When the KDC issues a TGT to a client, it checks the Kerberos policy for the domain to see if proxy tickets are allowed. If they are allowed, the KDC sets the PROXIABLE flag in the TGT that the KDC issues to the client.

The client obtains a proxy ticket by presenting a TGT to the ticket-granting service and asking for a session ticket to the back-end server. The client’s request includes a flag that signals it wants a proxy ticket; the request also includes the name of the server that will represent the client. When the KDC receives the client’s request, it creates a session ticket for the back-end server, sets the PROXY flag in the session ticket, and sends the ticket back to the client. The client then sends the session ticket to the front-end server, which uses it for access to the back-end server.

Forwarded Tickets

If a client wants to delegate the task of obtaining session tickets for a back-end server to a front-end server, it must ask the KDC for a forwardable TGT. It does this through an AS Exchange by indicating to the KDC the name of the server that will act on the client’s behalf. If Kerberos policy permits forwarding, the KDC creates a TGT for the front-end server to use in the client’s name, sets the FORWARDABLE flag in the TGT, and sends the ticket back to the client. The client then forwards the TGT to the front-end server.

When the front-end server requests a session ticket to the back-end server, it presents the client’s TGT to the KDC. When the KDC issues a session ticket for the back-end server, it sees the FORWARDABLE flag in the TGT, sets the FORWARDED flag in the session ticket for the requested server, and returns the session ticket to the front-end server. The option of setting the FORWARDED flag in a session ticket provides an added level of security because it permits administrators to configure individual servers to reject session tickets that have been forwarded.


Kerberos Components in Windows 2000

Windows 2000 implements the KDC as a domain service. It uses Active Directory as its account database and gets additional information about security principals from the Global Catalog.

As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services.

  • Authentication Service

    The authentication service issues TGTs that are good for admission to the ticket-granting service in its domain. Before network clients can get tickets for services, they must obtain a TGT from the authentication service in the user’s account domain.

  • Ticket-Granting Service

    The ticket-granting service issues tickets that are good for admission to other services in its own domain or for admission to the ticket-granting service of a trusted domain. When clients want access to a service, they must contact the ticket-granting service in the account domain of the service, present a TGT, and ask for a session ticket. If the client does not have a TGT for admission to the ticket-granting service in the other domain, it must obtain one through the referral process that begins at the ticket-granting service in the account domain of the user and ends at the ticket-granting service in the account domain of the service.

The KDC is located on every domain controller, as is the Active Directory service. Both services are started automatically by the domain controller’s Local Security Authority (LSA) and run in the process space of the LSA. Neither service can be stopped. Windows 2000 ensures availability of these services by allowing each domain to have several domain controllers, all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain’s KDC.

The security principal name used by the KDC in all Windows 2000 domains is krbtgt, as specified by RFC 1510. An account for this security principal is created automatically when a new Windows 2000 domain is created. The account cannot be deleted, nor can the account name be changed. A password is assigned to the KDC’s account automatically; this password, like the passwords assigned to domain trust accounts, is changed on a regular schedule. The password for the KDC’s account is used to derive a secret key for encrypting and decrypting the TGTs it issues. The password for a domain trust account is used to derive a Kerberos inter-realm key for encrypting and decrypting referral tickets.

All instances of the KDC in a domain use the domain account for the security principal krbtgt. Clients address messages to a domain’s KDC by including both the service’s principal name (krbtgt) and the name of the domain. Both items of information are also used in tickets to identify the issuing authority.


Account Database

The account database that provides information about security principals to the KDC is the domain’s Active Directory. Each security principal is represented by an account object in Active Directory. The cryptographic key used in communications with a user, a computer, or a service is stored as an attribute of that security principal’s account object.

Only domain controllers are Active Directory servers. Each domain controller keeps a writable copy of the directory so that accounts can be created, passwords reset, and group memberships modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows 2000 does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for Active Directory by using a proprietary multimaster replication protocol over a secure channel between replication partners.

Physical storage of account data is managed by the Directory System Agent (DSA), a protected process that is integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client that wants access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA and then search for, read, and write directory objects and their attributes.

Requests for access to an object or attribute in the directory are subject to validation by Windows 2000 access control mechanisms. Like file and folder objects in the NTFS file system, objects in Active Directory are protected by access control lists (ACLs) that specify who can have access to the object and in what way. Unlike files and folders, however, Active Directory objects have an ACL for each of their attributes. Thus, attributes for sensitive account information can be protected by permissions that are more restrictive than permissions granted for other attributes of the account.

The most sensitive information about an account is, of course, its password. Although an account object’s password attribute stores an encryption key that is derived from the password, not the password itself, this key is just as useful as the password to a would-be intruder. Therefore, access to an account object’s password attribute is granted only to the account holder, never to anyone else, not even to administrators. Only processes with Trusted Computer Base privilege — processes running in the security context of the LSA — are allowed to read or change password information.

To hinder an offline attack by someone with access to a domain controller’s backup tape, an account object’s password attribute is further protected by using a system key to encrypt its value. This key can be stored on removable media so that it can be safeguarded separately, or it can be stored on the domain controller and protected by a dispersal mechanism. Administrators can choose where the system key is stored and which of several algorithms is used to encrypt password attributes.


Kerberos Policy

Kerberos policy is defined at the domain level and is implemented by the domain’s KDC. Kerberos policy is stored in Active Directory as a subset of the attributes of domain account policy. By default, policy options can be set only by members of the Domain Administrators group. The policy includes these options:

  • Allow forwardable tickets.
  • Allow renewable tickets.
  • Set maximum ticket age.
  • Set maximum ticket renewal age.
  • Set maximum proxy ticket age.
  • Forcibly log off users when tickets expire.

Although Kerberos policy for a domain can permit delegated authentication by allowing forwardable tickets, that aspect of policy need not apply to all users or to all computers. An attribute of an individual user account can be set to disable forwarding of that user’s credentials by any server. An attribute of an individual computer’s account can be set to disable forwarding of credentials from any user. In both cases, delegation can be disabled by creating a Group Policy that applies to all users or to all computers in an organizational unit of Active Directory. (For more information about setting security policy, see “Security Policies” in this book.)


Kerberos Security Support Provider

The Kerberos authentication protocol is implemented as a security support provider (SSP) — a dynamic-link library (DLL) that is supplied with the operating system. Windows 2000 also includes an SSP for NTLM authentication. By default, both the Kerberos protocol and the NTLM protocol are loaded by the LSA on a computer that is running Windows 2000 when the system boots. In Windows 2000 domains, either of these SSPs can be used to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection. The Kerberos SSP is always the first choice.

System services and transport-level applications have access to SSPs through the Microsoft Security Support Provider Interface (SSPI). The SSPI is a Microsoft® Win32® interface with methods for enumerating the SSPs available on a computer, selecting one, and then using it to obtain an authenticated connection. The methods provided in the SSPI are generic, black-box routines that developers can use without knowing the details of a particular protocol. For example, when a client/server connection is authenticated, the application on the client’s side of the connection sends credentials to the server using the SSPI method InitializeSecurityContext. If the Kerberos SSP has been selected, InitializeSecurityContext generates a KRB_AP_REQ message from the client. The application on the server’s side of the connection responds with the SSPI method AcceptSecurityContext, which generates a KRB_AP_REP message from the server. After the connection has been authenticated, the LSA on the server uses information from the client’s session ticket to build an access token. The server then invokes the SSPI method ImpersonateSecurityContext to attach the access token to an impersonation thread for the service.

After the LSA establishes the security context for an interactive user, another instance of the Kerberos SSP might be loaded by a process running in the user’s security context to support message signing and sealing. But no process other than the LSA is ever permitted access to session keys or tickets in the credentials cache.

All distributed services in Windows 2000 domains use the SSPI for authentication. Thus, all domain services support the Kerberos protocol. Services that use the Kerberos protocol for authentication include:

  • Print spooler services
  • Common Internet File System/Server Message Block (CIFS/SMB) remote file access
  • Lightweight Directory Access protocol (LDAP) queries to Active Directory
  • Distributed file system management and referrals
  • Internet Protocol Security (IPSec) host-to-host security authority authentication
  • Reservation requests for network Quality of Service
  • Intranet authentication to Internet Information Services (IIS)
  • Remote server or workstation management using authenticated remote procedure call (RPC)
  • Certificate requests to the Certificate Services for domain users and computers


Credentials Cache

Windows 2000 stores tickets and keys obtained from the KDC in a credentials cache, an area of volatile memory protected by the LSA. Only processes running in the LSA’s security context have access to the cache. Its memory is never paged to disk. All objects stored there are destroyed when a security principal logs off or the system is shut down.

The credentials cache is managed by the Kerberos SSP, which runs in the LSA’s security context. Whenever tickets and keys must be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task.

The credentials cache is also used to store a copy of an interactive user’s password-derived key. If the user’s TGT expires during a logon session, the Kerberos SSP uses its copy of the password-derived key to obtain a new TGT without interrupting the user’s logon session. The password-derived key is not stored permanently on the computer, and the local copy in the credentials cache is destroyed when the credentials cache is flushed.

Password-derived keys for services and computers are handled differently. They are stored in a secure area of the computer’s registry, just as they were in earlier versions of Windows 2000. Password-derived keys for user accounts on the local system, which are used only for access to computers in standalone mode, are also stored in the registry. These keys are never used for network access.


Finding the KDC

When the Kerberos SSP wants to send an initial authentication request to the KDC in a user’s account domain, it must locate a domain controller for that domain. It finds the domain controller by using the domain controller locator. For more information about the locator, see “Active Directory Logical Structure” in this book.

The locator can only find KDCs that are in Active Directory–based domains. When computers that are running Windows 2000 participate in other Kerberos realms, the Domain Name System (DNS) names for KDC servers must be stored in the client computer’s registry. The Kerberos SSP looks in the registry for the DNS domain name of the user’s Kerberos realm and then resolves this name to an Internet Protocol (IP) address by querying a DNS server.


IP Transport

According to RFC 1510, when a client contacts the KDC, the client should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC’s IP address. The KDC should respond with a reply datagram to the sending port at the client’s IP address. UDP is a connectionless transport protocol, which makes it a logical choice when an exchange of messages must precede a connection. UDP is also well suited to applications that send one message and expect one response, such as the exchange between a client and a KDC. However, UDP works best when each datagram is transmitted as a single unit — that is, within a single frame.

The Maximum Transmission Unit (MTU) for an Ethernet frame is 1500 octets. If the physical network is Ethernet, this means Kerberos messages sent as UDP datagrams can carry up to 1500 octets of data. Windows 2000 authorization data can easily total more than 1500 octets. But because Windows 2000 authorization data is needed only by computers that are running Windows 2000, this data is omitted from session tickets to computers with other operating systems. As a result, messages to other systems are well within the limits of UDP transport, and that is how they are transmitted.

Messages that carry session tickets for computers that are running Windows 2000 are transmitted by using the Transport Control Protocol (TCP), which has a much greater capacity than the UDP. Although transmitting messages through TCP rather than UDP is a departure from RFC 1510, it is limited to communications between computers that are running Windows 2000 and should pose no barrier to interoperability with other implementations of the protocol.


Authorization Data

The Kerberos protocol is a protocol for authentication, not authorization. It verifies that security principals are who they say they are but does not determine the objects to which they can have access or what type of access they can have. The Kerberos protocol provides a field for authorization data in session tickets, but it does not specify the form of the data or how servers should use it. These decisions are left to whatever access control mechanism is available on the system.


Name-based vs. Identity-based Authorization

On some operating systems, applications are required to implement their own mechanisms for determining the level of a user’s authorization. Applications often do this by maintaining private lists that contain the names of users who are authorized access. Database applications, for example, often maintain private authorization tables to control the fields in a record that a particular user can view or change. This kind of access control mechanism can be integrated with Kerberos authentication simply by ensuring that the authorization data field of a session ticket carries some form of the security principal’s name.

Unfortunately, private authorization mechanisms are just that — private. A database application is powerless to prevent an unauthorized user from running another application and using it to edit the data file. On Windows 2000, access to resources is controlled by the operating system itself. Applications can implement their own private authorization mechanisms, but whether they do or not, the Windows 2000 operating system’s access control mechanism protects all files and other objects that can be shared by two or more processes.

The header of every securable object includes a security descriptor with an ACL. The ACL is maintained by the object’s owner, who decides which security principals can have access to the object and how they may gain access to it. The operating system enforces the owner’s decisions by performing an access check whenever an application requests a handle to a protected object. Before the operating system returns the handle, it examines the object’s ACL to see whether the security principal who is using the application is authorized access. If the security principal is not authorized access, the application is denied access.

Another important difference from other access control mechanisms is that security principals are not identified by name, either by the operating system or in ACLs. Instead, each security principal is assigned a unique Security Identifier (SID), an alphanumeric value with a structure similar to a telephone number. Like the country code used in international calling, the first part of a SID identifies the domain where the SID was issued. Like the number for a specific telephone within a country, the second part of a SID identifies an account within the issuing domain. The value for a domain is unique within an enterprise, and the value for an account is unique within a domain. Unlike telephone numbers, however, SIDs are never reused. There is no possibility that a user could be assigned a SID that once belonged to another user.

A third important difference from name-based access control is that authorization is determined by not only the user’s identity but also the user’s membership in one or more security groups. In fact, the preferred method of controlling resources is to grant access to groups rather than to individuals, adjusting the level of a group’s authorization according to the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on networks that have thousands of users and millions of objects. Group membership can be managed centrally by administrators, who can change a particular user’s level of authorization for many resources simply by adding or removing the user from a group.

Windows 2000 makes resource security still easier to manage by allowing groups to be nested. A group created in one domain can be added to the membership of a group created in another domain or to the membership of a universal group used throughout a tree of trusted domains. As a result, when employees change jobs, their level of authorization can be changed throughout the enterprise without touching the ACLs on specific objects.

Like individual security principals, Windows 2000 security groups also have SIDs. A user’s level of authorization is determined, then, by a list of SIDs — the SID for the user and the SID for each security group to which the user belongs.

For more information how the operating system determines a user’s level of authorization, see “Access Control” in this book.


How the KDC Prepares Authorization Data

When the Kerberos protocol is used for authentication, the list of SIDs that identify a security principal and the groups to which this principal belongs is transported to the local computer in the authorization data field of a session ticket. Authorization data is gathered in two separate steps — when the KDC in a Windows 2000 domain prepares a TGT and when the KDC prepares a session ticket for a server in the domain.

When a user requests a TGT, the KDC in the user’s account domain queries the domain’s Active Directory. The user’s account record includes an attribute for the user’s SID as well an attribute with SIDs for any domain security groups to which the user belongs. The list of SIDs returned by the KDC’s query is placed in the TGT’s authorization data field. In a multiple-domain environment, the KDC also queries the Global Catalog for universal groups that include the user or one of the user’s domain security groups. If it finds any, the SIDs for these groups are added to the list in the TGT’s authorization data field.

When the user requests a session ticket for a server, the KDC in the server’s domain copies the contents of the TGT’s authorization data field to the session ticket’s authorization data field. If the server’s domain is different from the user’s account domain, the KDC queries Active Directory to find out whether any security groups in the local domain include the user or one of the user’s security groups. If there are any such groups, their SIDs are added to the list in the session ticket’s authorization data field.


How Services Use Authorization Data

In Windows 2000, services act in their own security contexts only when they are trying to gain access to resources on their own behalf. For the most part, this happens only when they are doing their own housekeeping — reading or writing configuration data stored in registry keys, binding to communications ports, and completing other tasks that are not related to work for a particular client. When a service is doing something for a client, it impersonates the client and acts in the client’s security context. This means that in addition to verifying the identity of a client, Windows 2000 services also must take on some of their client’s characteristics — specifically, the client’s level of authorization on the system.

When a service sets up housekeeping on a computer that is running Windows 2000, it calls the SSPI method AcquireCredentialsHandle to gain access to its own credentials (the secret key for the account under which the service runs). The service then binds to a communications port, where it listens for messages from prospective clients.

When a client requests a connection and presents a session ticket, the service asks the Kerberos SSP to verify the client’s credentials by calling the SSPI method AcceptSecurityContext and passing as an argument the client’s session ticket along with a handle to the service’s secret key. The SSP verifies the ticket’s authenticity, opens it, and passes the contents of the authorization data field to the LSA. If the data includes a list of SIDs, the LSA uses them to build an access token that represents the user on the local system. In addition, the LSA queries its own database to determine whether the user or one of the user’s security groups is a member of a security group created on the local system. If any such groups are found, the LSA adds these SIDs to the access token. The LSA then confirms for the calling service that the client’s identity has been authenticated and encloses a reference to the client’s access token.

Upon receiving confirmation, the service completes its connection with the client and attaches the client’s access token to an impersonation thread by calling ImpersonateSecurityContext. When the impersonation thread requires access to an object, it presents the client’s token. The operating system performs an access check by comparing the SIDs in the token to the SIDs in the object’s ACL. If the operating system finds a match, it checks to see that the entry in the ACL grants the level of access requested by the thread. If the authorized level of access matches the level of access requested, the thread is allowed access to the object. Otherwise, access is denied.


Why Authorization Data Is Signed

Session tickets are encrypted with the secret key for the account under which the service starts. When a service acquires a handle to its own credentials on the system, it gains access to that secret key. The difficulty is that an unscrupulous user with a legitimate network account but limited authorization on the local computer could install a rogue service on the computer. This user could request a session ticket for the service, and the service could decrypt the ticket, modify the authorization data by adding the SID for a privileged group, encrypt the altered ticket, and present it to the LSA in a call to AcceptSecurityContext. The result would be the elevation of the user’s level of authorization on the computer where the service is running.

To prevent tampering with authorization data, the data is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data invalidates the signature. The LSA on a Windows 2000 computer always checks the validity of this signature when session tickets are presented by untrusted services. The LSA trusts calls to AcceptSecurityContext from services running under the Local System account. This account is used by services installed with the operating system — by the native Server service, for example. Other services can be configured to use the Local System account, but this must be done by a member of the Administrators group. The assumption is that the administrator who installs the service can vouch for its security.

The LSA does not trust services running under any other account. If a session ticket is presented by an application that is not running as Local System, the LSA asks the KDC in its domain to verify the signature on the ticket’s authorization data. The question is asked and answered by an RPC over Netlogon’s secure channel to the domain controller. Requests for verification do not need to travel beyond the local domain because session tickets are always issued — and, therefore, authorization data is always signed — by the KDC in the destination computer’s domain.


Interactive Logon

Users have a natural tendency to think that logging on to an account in a Windows 2000 domain gives them access to the network. That is, of course, not true. When the Kerberos protocol is used for network authentication, what you actually get when you first log on is access to the domain’s authentication service. Specifically, you get a TGT that you can present when requesting session tickets for other services in the domain.

When you log on to a domain account from a computer that is running Windows 95 or Windows 98, you do not have to present your TGT and request a session ticket until you try to gain access to a network service — until you browse Network Neighborhood, for example, or try to gain access to a network file server. Conceivably, you could work at the computer for an entire logon session without ever using a domain resource. In that case, you would never need a session ticket.

When you log on to a domain account from a computer running Windows 2000, you always need at least one session ticket — a ticket for the computer where you are logging on. Computers with the Windows 2000 operating system, unlike computers with other operating systems, also have accounts in the domain; these are essentially service accounts. Remote users gain access to resources on a computer that is running Windows 2000 by submitting requests to the computer’s Server service. Interactive users of the computer gain access to resources in the domain by submitting requests to the computer’s Workstation service. To gain admission to either of these services or to any other service running as Local System, you must present a session ticket for the computer.


The Kerberos Logon Process

When a user with an account in a Windows 2000 domain logs on at the keyboard of a computer that is running Windows 2000, the user’s logon request is processed in three stages:

  1. The user asks for admission to the ticket-granting service for the domain.

    This is accomplished through an AS Exchange between the Kerberos SSP on the computer and the KDC in the user’s account domain. The result is a TGT that the user can present in future transactions with this KDC.

  2. The user asks for a ticket for the computer.

    This is accomplished through a TGS Exchange between the Kerberos SSP on the computer and the KDC for the computer’s account domain. The result is a session ticket that the user can present when he or she requests access to system services on the computer.

  3. The user asks for admission to Local System services on the computer.

    This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer.

If the computer’s account domain is a different domain than the user’s domain, an extra step is involved. Before the Kerberos SSP can request a session ticket for the computer, it must ask the KDC in the user’s domain for a TGT that is good for admission to the KDC in the computer’s domain. The SSP can then present the TGT to the KDC in the computer’s domain and get a session ticket for the computer.

Exactly how the logon process works depends on how you configure the computer. With standard configurations of Windows 2000, interactive users log on with a password. In another optional configuration of Windows 2000, users log on with a smart card. Although the basic process is the same for both configurations, there are some differences.


Password Logon

Suppose Alice has a network account in the domain named West. The computer she normally uses, Workstation, also has an account in West. When Alice logs on to the network, she begins by pressing the key combination CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS) on computers with a standard Windows 2000 configuration.

In response to the SAS, Winlogon switches to the logon desktop and dispatches to a DLL called the Graphical Identification and Authentication (GINA), a component loaded in Winlogon’s process. GINA is responsible for collecting the logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Third parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component (MSGINA.dll) supplied with the Windows 2000 operating system. MSGINA displays the standard logon dialog box.

Alice types her user name and password. She selects West from the drop-down list of domain names. When she clicks OK to dismiss the dialog box, MSGINA returns her logon information to Winlogon. Winlogon then sends the information to the LSA for validation by calling LsaLogonUser.

Upon receiving a data structure with Alice’s logon data, the LSA immediately converts Alice’s cleartext password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache, where the hashed password can be retrieved when it is needed for encryption and decryption.

To validate Alice’s logon information and set up her logon session on the computer, the LSA must obtain the following:

  • A TGT that is good for admission to the ticket-granting service.
  • A session ticket that is good for admission to the computer.

The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the domain’s KDC, as illustrated in Figure 9.8.

Figure 9.8 Kerberos Exchanges for Interactive Logon

The messages follow this sequence:

  1. The LSA sends a KRB_AS_REQ message to the KDC’s authentication service in the domain West.

    The message includes:

    • The user’s principal name (Alice).
    • The name of the account domain (West).
    • Pre-authentication data encrypted with the secret key derived from Alice’s password.
  2. The KDC’s authentication service replies with a KRB_AS_REP message.

    The message includes:

    • A session key for Alice to share with the KDC, encrypted with the secret key derived from Alice’s password.
    • A TGT for the KDC in the domain West, encrypted with the KDC’s secret key. The TGT includes a session key for the KDC to share with Alice and authorization data for Alice.

    The authorization data includes the SID for Alice’s account, SIDs for security groups in the domain West that include Alice, and SIDs for universal groups in the enterprise that include either Alice or one of her domain groups.

  3. The LSA sends a KRB_TGS_REQ message to the KDC’s ticket-granting service in the domain West.

    The message includes:

    • The name of the destination computer (Workstation).
    • The name of the destination computer’s domain (West).
    • Alice’s TGT.
    • An authenticator encrypted with the session key Alice shares with the KDC.
  4. The KDC replies with a KRB_TGS_REP message.

    The message includes:

    • A session key for Alice to share with Workstation, encrypted with the session key Alice shares with the KDC.
    • Alice’s session ticket to Workstation, encrypted with the secret key Workstation shares with the KDC.

    The session ticket includes a session key for Workstation to share with Alice and authorization data copied from Alice’s TGT.

Upon receipt of Alice’s session ticket, the LSA decrypts it with the computer’s secret key and extracts her authorization data. It then queries the local Security Accounts Manager (SAM) database to determine whether Alice is a member of any security groups local to the computer and whether she has been given any additional user rights on the local computer. It adds any SIDs returned by this query to the list taken from the ticket’s authorization data. The entire list is then used to build an access token. A handle to the access token is then returned to Winlogon, along with the identifier for Alice’s logon session and confirmation that her logon information is valid.

Winlogon creates a window station and several desktop objects for Alice, attaches her access token, and starts the shell process she will use to interact with the computer. Alice’s access token is subsequently inherited by any application process that she starts during her logon session.


Smart-Card Logon

In standard logons, a user initially proves his or her identity to the KDC by demonstrating knowledge of a secret known only to the user and to the KDC. This shared secret is the cryptographic key derived from the user’s password. The same key is used for both encryption and decryption. For this reason, shared secret keys are said to be symmetric. The cryptographic key derived from the user’s password is used only during the AS Exchange for the following:

  • When the client encrypts pre-authentication data.
  • When the KDC decrypts pre-authentication data.
  • When the KDC encrypts the logon session key.
  • When the client decrypts the logon session key.

To support smart-card logons, Windows 2000 implements a public key extension to the Kerberos protocol’s initial AS Exchange. In contrast to shared secret key cryptography, public key cryptography is asymmetric, that is, two different keys are needed — one to encrypt, another to decrypt. Together, the keys needed to perform both operations make up a private/public key pair.

When a smart card is used in place of a password, a private/public key pair stored on the user’s smart card is substituted for the shared secret key derived from the user’s password. The private key is known only to the owner of the pair and is never shared. The public key can be made available to anyone with whom the owner wishes to exchange confidential information.

In the public key extension to the Kerberos protocol, the initial AS Exchange is modified so that the KDC encrypts the user’s logon session key with the public half of the user’s key pair. The client decrypts the logon session key with the private half of the pair.

The logon process begins when the user inserts a smart card into a card reader attached to the computer. When a computer that is running Windows 2000 is configured for smart-card logon, the insertion of the card signals the SAS, just as the key combination CTRL+ALT+DEL signals the SAS on computers configured for password logon. In response, Winlogon dispatches to MSGINA, which displays a logon dialog box. But in this case, the user types just one item of information, a Personal Identification Number (PIN).

MSGINA sends the user’s logon information to the LSA by calling LsaLogonUser, just as it does with a password logon. The LSA uses the PIN for access to the smart card and extracts the user’s private key along with an X509 v3 certificate that contains the public half of the key pair.

The Kerberos SSP on the client computer sends the user’s public key certificate to the KDC as pre-authentication data in its initial authentication request, the KRB_AS_REQ message. The KDC validates the certificate, extracts the public key, and then uses the public key to encrypt a logon session key. It returns the encrypted logon session key and a TGT in its KRB_AS_REP reply message to the client. If the client is in possession of the private half of the key pair, it will be able to use the private key to decrypt the logon session key. Both the client and the KDC then use this logon session key in all further communications with one another. The remainder of the authentication process is the same as for standard logon.


Pre-Authentication Data

By default, the Kerberos SSP on a client computer sends the KDC pre-authentication data in the form of an encrypted timestamp. On systems configured for smart-card logon, the Kerberos SSP sends pre-authentication data in the form of a public key certificate. Other forms of pre-authentication data are possible.


Security Solutions Using Public Key Technology

Microsoft® Windows® 2000 includes many enhanced security features that use public key technology to provide strong and scalable security solutions for networks. The information in this chapter can help Information Technology managers, planners, and implementers and business decision-makers understand the types of security solutions that are available to them.

In This Chapter

Weaknesses in Open Network Security

Security With Windows 2000 Technologies

Security Solutions

Standards and Interoperability

Cryptography Export Restrictions

Related Chapters in the Resource Kit

  • For information about the concepts of public key infrastructure and public key technology, see “Cryptographic Technologies for Open Network Security” in this book.
  • For information about the design, implementation, and maintenance of Microsoft Certificate Services, see “Microsoft Certificate Services” in this book.
  • For more information about distributed security, see the other chapters under “Distributed Security” in this book.


Weaknesses in Open Network Security

The open nature of today’s enterprise promotes information exchange and collaboration on an unprecedented level. However, the very nature of open networks makes it more difficult for organizations to protect valuable network resources and business information.

In a recent Computer Security Institute survey, 64 percent of the 520 respondents reported computer security breaches in a 12-month period; an alarming 16-percent increase over the previous year. Yet, perhaps even more alarming, 241 respondents disclosed corporate losses that total 136 million dollars; a 36-percent increase over the previous year. There is clearly a need for stronger security on intranets and on the Internet.

Although Internet Protocol (IP) networks such as the public Internet and private intranets provide for open communication between users and computers, they are vulnerable to compromised security and malicious attack by intruders. Information sent over IP networks is open to anyone who can gain access to the network. Authorized network users, as well as intruders, can view, modify, and disrupt IP network communications easily by using software tools that are readily available on the Internet. Both internal and external intruders can exploit the open nature of IP networks easily to do any of the following:

  • Steal proprietary information and eavesdrop on private communications.
  • Impersonate users, clients, or servers on the network.
  • Intercept and modify information before it arrives at its destination.
  • Intercept and redirect information to other destinations.
  • Cause denial-of-service attacks that exploit the inherent weakness of IP networks or bugs in protocol implementation to cause harm to organizations and users on the networks.

Both the software industry and Internet communities have developed a wide range of new technologies and standards to address these problems and improve the security and privacy of information on open networks.


Security with Windows 2000 Technologies

Windows 2000 distributed security systems support a wide range of open standards for network and information security, as recommended by the Internet Engineering Task Force (IETF) and other standards bodies. Because Windows 2000 security is based on open standards, the security solutions you implement can operate with most standards-compliant, third-party operating systems and applications. Distributed security technologies allow you to provide a wide range of network and information security solutions.


Distributed Security Technologies

The distributed security technologies available in Windows 2000 include the following:

  • Kerberos v5 network logon authentication, including smart card logon in association with permitted extensions to the Kerberos protocol.
  • Routing and remote access services to support secure remote access to network resources. Routing and remote access services support:
    • Integration with Active Directory™ directory service to manage remote user authentication that is based on domain network user accounts and Group Policy.
    • Remote Authentication Dial-In User Service (RADIUS) to manage remote user authentication by using a variety of authentication protocols.
    • User authentication that is based on the Extensible Authentication Protocol and Transport Layer Security (EAP-TLS) to support authenticating users by means of public key certificates and smart-card logon.
    • Confidential communications over public Internet lines through the use of the Layer 2 Tunneling Protocol (L2TP) and the Point-to-Point Tunneling Protocol (PPTP).
    • Remote network access and logon via virtual private networks (VPNs) that are hosted by public internet service providers.
  • IP Security to support IP-level end-to-end authentication, integrity, anti-replay, and encrypted communications over open IP networks, including the Internet.
  • Encrypting File System to enable users to encrypt folders and files for safekeeping and also to enable administrators to recover files when users’ private keys are damaged or lost.

Each of these security technologies uses public key technology as either an integral or an optional component of security. The Windows 2000 public key infrastructure and Microsoft Certificate Services can support all of your public key information security needs.


Public Key Technology

Windows 2000 includes a public key infrastructure that is based on the open standards recommended by the Public Key Infrastructure X.509 working group of the IETF. Public key security in Windows 2000 makes use of industry-standard, X.509 version 3 digital certificates that are issued by trusted Certification Authorities (CAs). You can use public key technology in conjunction with other security technologies to provide comprehensive security for intranets, extranets, and the Internet. You can deploy CAs by using Microsoft Certificate Services, or you can obtain certificate services from third-party vendors. For more information about public key infrastructure and public key technology, see “Cryptographic Technologies for Open Network Security” in this book.

In Windows 2000, public key security solutions can include these features:

  • Smart card logon for local and remote network logon authentication by using extensions to the Kerberos v5 protocol and the EAP-TLS protocol.
  • Smart-card authentication and storage of digital certificates and private keys.
  • Secure mail through use of Secure Multipurpose Internet Mail Extensions (S/MIME) mail servers and clients.
  • Secure Web communications via Microsoft® Internet Information Services with the Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) protocols.
  • Secure access to Web site resources through use of Internet Information Services and certificate mapping to network user accounts.
  • Digitally signed software to ensure the authenticity and integrity of software that is distributed on the intranet or on the Internet.
  • Encrypted folders and files through the use of the Encrypting File System.
  • Laptop computers protected by the Encrypting File System and Windows 2000 System Key.
  • IP Security authentication that is based on optional digital certificates.
  • Secure mail and secure Web communications through use of FORTEZZA Crypto Cards with a Federal Information Processing Standard 140-1–compliant Cryptographic Service Provider.


Security Solutions

You can use Windows 2000 to provide network and information security solutions such as the following:

  • Secure mail
  • Secure Web communications
  • Secure access to Web site resources
  • Digitally signed software
  • Security with Encrypting File System
  • Security with IP security
  • Security with smart cards
  • Security with FORTEZZA Crypto Cards

The following sections describe the types of security solutions you can deploy as well as how public key technology can be incorporated into each solution. Each section also describes how you can deploy Microsoft Certificate Services to support security solutions.


Secure Mail

You can deploy secure mail to ensure the integrity of messages and to enable confidential mail communications within your organization.

The Need for Secure Mail

Standard Internet mail is sent as plaintext over open networks with no security. In today’s increasingly interconnected network environments, the open nature of Internet mail poses many problems for mail security. Intruders can monitor your mail servers and network traffic to obtain proprietary or sensitive information. You also risk exposure of proprietary and confidential business information when you send mail over the Internet from within your organization. Messages sent over the Internet can be intercepted and read by eavesdroppers who are monitoring Internet traffic or even by legitimate administrators of the mail servers and connectors that process and route the messages.

Even in organizations with security policies that prohibit the exposure of proprietary business information on the Internet, employees sometimes forward their office mail to personal Internet mail accounts. Employees also can inadvertently send proprietary mail to the wrong mail alias or to a mail alias that includes the addresses of people who don’t have a need to know the information in the message.

Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using readily available tools to counterfeit the originating IP address and mail headers. With standard Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid. Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks for example, by sending attachments that contain viruses.

For these reasons, many organizations have placed a high priority on implementing secure mail services that provide confidential communications, data integrity, and nonrepudiation. However, until recently, many secure mail systems have been proprietary or were not scalable for global communication.

Standards-based Mail Clients

The Secure Multipurpose Internet Mail Extensions (S/MIME) working group of the IETF developed the open S/MIME standard to extend the original Multipurpose Internet Mail Extensions (MIME) standard. The S/MIME standard enables the digital signing and encryption of mail. Secure mail can be exchanged between S/MIME clients that run on any platform or operating system. They can send S/MIME messages over the Internet without regard to the mail servers that handle the messages because all cryptographic functions are performed on the mail clients, not on the mail servers. The only function of Internet mail servers is to route MIME messages; they do not alter the contents of messages in transit.

Microsoft supports S/MIME in the Microsoft® Outlook 98 messaging and collaboration client and is working with the S/MIME working group as well as with other vendors to ensure maximum interoperability of Outlook 98 with other S/MIME applications. Most of the other leading mail clients from third-party vendors also support S/MIME.

Secure mail with S/MIME uses the industry-standard X.509 version 3 digital certificates and public key technology. Secure mail clients can perform the following tasks:

  • Sign messages before sending them by using the private key to provide data integrity and nonrepudiation. A recipient uses the sender’s public key to verify the message.
  • Generate random secret encryption keys and bulk encrypt messages for confidentiality.
  • Encrypt the secret encryption key by using each recipient’s public key and send the encrypted secret key along with the encrypted message to each recipient. Recipients use their private keys to decrypt the secret key, and then they use the secret key to decrypt the message.

Considerations for Secure Mail Clients

With secure mail, senders are assured that only the intended recipients can read the encrypted mail, and recipients are assured that the message is genuine. Secure mail clients must each have a valid certificate for secure mail to work properly. Certificates can be published in directories and public folders to facilitate the distribution of certificates and public keys.

Secure mail clients must trust the certificates from other correspondents. You can configure secure mail for your organization to trust secure mail certificates issued by CAs in your organization or to trust secure mail certificates issued by third-party CAs. You can use Certificate Trust Lists (CTLs) to specify third-party CAs that you want to trust for secure mail.

The strength of the encryption cryptography that is available for secure mail clients depends on export restrictions. The actual strength available to your mail clients varies depending on current export policies and the country where mail clients are deployed.

You can deploy Microsoft Certificate Services to issue secure mail certificates that work with S/MIME-compliant secure mail clients such as Outlook 98. You can deploy Web enrollment pages to enroll users and issue secure mail certificates. If you use Microsoft® Exchange Server for your mail servers, you can deploy and use the Key Management server (KM server) to manage certificate enrollment, as described in the following section.

Key Management and Recovery Servers

Because the S/MIME secure mail standard is client-based, it does not specify key management or key recovery requirements. However, most organizations might want to deploy secure mail with centralized key management and key recovery services. Otherwise, administrators cannot manage key recovery centrally.

Without key recovery, an encrypted message that is sent to a user cannot be decrypted if the private key has somehow been corrupted or destroyed. For example, if a secure mail user’s hard disk crashes and cannot be restored, people can still use the user’s public key to send encrypted messages. Unless the private key can be restored, the user cannot read the encrypted messages. Therefore, private keys for secure mail should be maintained in a protected key recovery database for at least the lifetime of the corresponding secure mail certificates. When the certificate expires, the public key cannot be used any longer to send secure mail.

The Windows 2000 public key infrastructure does not provide key recovery or dedicated certificate enrollment services for secure mail. However, Microsoft® Exchange Server version 5.5 provides the KM server to manage secure mail enrollment and private keys. The KM server maintains a protected key recovery database that contain all issued nonexpired private keys. Administrators can use KM server to manage certificate enrollment for secure mail users and to recover private keys that are lost or corrupted.

Microsoft® Exchange Server version 5.5 Service Pack 1 uses Microsoft Certificate Services to issue the secure mail certificates. Earlier versions of Exchange did not use Microsoft Certificate Services; instead, the KM server issued the obsolete and inflexible X.509 version 1 certificates. To use Microsoft Certificate Services with Exchange 5.5 Service Pack 1, you install a CA with a special Exchange Policy module. The CA uses the Exchange Policy module to issue secure mail certificates upon valid requests from the Exchange KM server.

For Exchange 5.5 Service Pack 1, the Exchange Policy module only issues secure mail certificates to the KM server and cannot provide any other certificate services. For more information about the Exchange Policy module and about. using Microsoft Certificate Services with Exchange to provide secure mail services, see the documentation for Exchange Server.


Secure Web Communications

You can deploy secure Web communications to ensure the integrity of Web communications and to provide confidential Web communications in your organization.

The Need for Secure Web Communications

Web communications that are based on the Transfer Control Protocol/Internet Protocol (TCP/IP), such as the Hypertext Transfer Protocol (HTTP), Telnet, and File Transfer Protocol (FTP), are not secure because all communication occurs in plaintext. Confidential or sensitive information that is transmitted with these protocols can easily be intercepted and read, unless the information is protected by encryption technology.

In addition, Web servers that use only standard HTTP to communicate with Web clients are easy targets for denial-of-service attacks because any Web client can send HTTP requests and exploit weaknesses in HTTP or its implementation. Moreover, Web clients that communicate using standard HTTP are easy targets for rogue Web servers that can impersonate legitimate Web sites and might contain virus-laden software or malicious Microsoft® ActiveX® controls.

Types of Secure Web Communications

Secure Web communication protocols provide a way to authenticate clients and servers on the Web and protect the confidentiality of communications between clients and servers. A variety of secure communications standards that use public key technology have been developed. The leading general-purpose, secure Web communications protocols are SSL 3.0 and the open TLS protocol that is based on SSL. The SSL and TLS protocols are widely used to provide secure channels for confidential TCP/IP communications on the Web.

One disadvantage of SSL and TLS is that the cryptographic strength for secure communications is subject to cryptography export restrictions. The strength of cryptography available to export-controlled servers and clients is much higher than for nonexport-controlled servers and clients. Therefore, at the beginning of SSL and TLS sessions, servers and clients negotiate the cryptographic strength to be used for secure sessions. The server chooses the strongest cryptographic strength that is available to both the server and the client. Thus, maximum security for secure SSL and TLS communications is available only between servers and clients that support strong export-controlled cryptography.

For financial transactions, other specialized protocols that use strong encryption technology (as allowed by cryptography export restrictions) have been developed, such as the Secure Electronic Transaction (SET) protocol and the Server Gated Cryptography (SGC) protocol. Internet Information Services supports SGC, and Microsoft® Wallet (which is available for Microsoft® Internet Explorer 5) supports SET. For more information about SGC and SET, see the Microsoft Security Advisor Web site at http://microsoft.com/security.

Web Communications with Internet Information Services

Windows 2000 Server includes Internet Information Services. You can use Internet Information Services to deploy Web sites on your intranets, extranets, or the Internet. You can use the Internet Information Services Microsoft Management Console (MMC) snap-in to configure and manage Web sites easily, including configuring secure SSL and TLS Web communications.

Secure Web communications requires a Web server and a Web client to have valid authentication certificates. You can deploy Microsoft Certificate Services to issue client and server authentication certificates that work with Internet Information Services and Internet Explorer, as well as with many third-party Web server and Web client products. You can also use third-party certificate services to provide certificates for secure Web communications.

You can use the Internet Information Services MMC snap-in to install server authentication certificates and to configure secure Web sites for Web communications. You can also create CTLs that specify the issuing CAs that are trusted for Web communications for each Web site.

The Benefits of Secure Web Communications

Secure Web communications that use SSL and TLS can provide the following protection for Web communications:

  • Mutual authentication between servers and clients that is based on the possession of valid and trusted certificates. Both servers and clients can choose to trust only certificates issued by a trusted CA.
  • Confidential Web communications that use an encrypted, secure channel. The server generates a random secret encryption key, encrypts the key by using the client’s public key, and sends the encrypted key to the client. The client uses its private key to decrypt the secret key, and then uses the secret key to encrypt and decrypt secure communications with the server.
  • Data integrity that is based on message digests. Secure channels are protected from tampering by an intruder because transmitted information is accompanied by message digests that must be verified before transmitted information is accepted by the receiving client or server.

Considerations for Secure Web Communications

You also can configure Internet Information Services to prevent clients without a valid and trusted certificate from communicating with Web sites, which reduces the risk of denial-of-service attacks. You can require secure channels for all Web communications to protect confidential information, or you can use secure channels to transmit only selected information, such as personal information and credit card numbers. You can also configure Web sites to require the maximum cryptographic strength for clients so that clients with weaker cryptography cannot communicate.

For Web sites on the Internet, you often want to allow clients with weak exportable cryptography to communicate over secure channels with your Web servers. However, for your intranets you might be able to deploy export-restricted clients and servers that support the maximum security for secure SSL and TLS channels.

Secure channels require that information be encrypted and decrypted both on the server and on the clients. Most of the client computers in use today can handle the encryption and decryption load of secure channels easily. However, multiple concurrent secure channels can place a large load on Web servers. To improve the performance of secure channel Web servers, you can use very fast multiple processor computers and crypto-accelerator boards. You can also design Web sites to use secure channel sessions for only a portion of the content on the Web site. For example, you can design Web pages to specify secure channels for only the forms that are used to submit confidential information, such as credit card numbers.


Secure Access to Web Site Resources

Windows 2000 Server includes Internet Information Services. You can configure Internet Information Services to provide granular security for your Web sites. You can use the Internet Information Services MMC snap-in to configure security for an entire site, as well as for each of the folders and files in the site. You can set general security for a Web site and then add other security requirements for specific folders and files in the site. Internet Information Services provides the following methods to control access to Web site resources:

  • Anonymous access
  • Authenticated access
  • NTFS file system access control lists
  • IP addresses and domain names
  • Certificate mapping to user accounts

Anonymous Access

Users log on to the Web site under a local user account. Internet Information Services provides a default user account that grants users limited rights and permissions to a Web site. When anonymous access is enabled, users can log on and use the selected Web resources without having to enter user names and passwords. Anonymous access is generally suitable for Web sites that contain information for public consumption, but not for Web sites that contain proprietary and confidential information.

Authenticated Access

Users must enter a user name and password to access the selected Web resources. Authentication options determine whether users’ passwords are sent over the network as plaintext, as a message digest, or as ciphertext. You can specify the user account and password used to gain access to the selected Web resources. Authenticated access is generally appropriate for providing low-level security on Web sites, but secure SSL and TLS channels and certificate mapping provide much stronger security.

NTFS Access Control Lists

You can use Internet Information Services folder and file properties Security pages to specify access control lists to control access to the selected folder or file. You grant rights and permissions for listed user accounts and security groups. When folders and files have access control lists, Internet Information Services prompts users to enter user names and passwords for authenticated access, even when anonymous access is enabled. NTFS access control lists extend the granular security available for Web sites. This security is not available for File Allocation Table (FAT) or FAT32 file systems, so consider using NTFS file system for all of your Web sites.

IP Addresses and Domain Names

You can list IP addresses and domain names to grant access to selected Web resources or to deny access to selected Web resources. You can list individual computers or groups of computers on the basis of subnet address or domain names. Extensive use of domain names can slow Web performance because of time-consuming Domain Name System (DNS) lookups. Controlling Web access through IP addresses and domain names provides weak security because attackers can forge the originating IP address and domain name information easily to gain access to your Web site.

Certificate Mapping to User Accounts

You can map certificates to Windows 2000 user accounts to control access to selected Web resources. Internet Information Services authenticates users on the basis of mapped certificates, and it grants rights and permissions that are based on the user account information. Certificate mapping can be one-to-one or many-to-one.

For one-to-one mapping, you map specific, individual certificates to user accounts. Internet Information Services authenticates users with the listed certificates and grants rights and permissions that are based on the user account information. You can import certificates manually, or you can design Active Server Pages that add certificates to mapped accounts.

For many-to-one mapping, you create rules to define certificate criteria for mapping. For example, you can specify rules listing a specific issuing CA or specific subject names. If certificates match the rules, you can specify that Internet Information Services either authenticates and maps matching certificates to the user account or you can specify that Internet Information Services refuses Web access to users with the matching certificates.

You can deploy Microsoft Certificate Services to issue client authentication certificates for certificate mapping. You can also use third-party certificate services to provide certificates for mapping.


Digitally Signed Software

You can digitally sign the software you distribute on your intranets or the Internet to ensure its integrity and to assure others that the software can be trusted.

The Need to Sign Software

Software downloaded from the Internet to users’ computers can contain rogue programs or viruses that are intended to cause malicious damage or provide clandestine network access to intruders. As networks become more interconnected, the threat of malicious software and viruses has extended to the intranet.

The Benefits of Code Signing

To counter this growing threat, Microsoft developed Authenticode™ technology, which enables developers to digitally sign software by using standard X.509 certificates. The last thing developers must do before releasing software is digitally sign the software. Any modification to the software after it is signed, invalidates the digital signature. Signed software ensures that users can verify the origin of the software, as well as verify that no one has tampered with the software. In addition to Authenticode, several other third-party code signing technologies use X.509 certificates to sign software.

Considerations for Code Signing in Your Organization

Executable programs, Java applets, Scripts, and ActiveX controls distributed in Windows 2000 domains should be digitally signed by trusted developers. To protect your network from malicious programs and viruses, you can configure Internet Explorer to specify security settings for several Security zones, including the Internet and Trusted Intranet Security zones. You can specify security settings that prevent users from downloading and running unsigned software from both the intranet and Internet. You can also configure Internet Explorer to trust specific Trusted Publishers so that software signed by these publishers is downloaded automatically without notifying the users. For more information, see the Microsoft® Windows 2000 Server Resource Kit Internet Explorer 5 Resource Guide.

In addition, you can configure public key Group Policy for each domain to specify the CAs for code signing that are trusted in your organization. You can trust specific certificate types issued by commercial CAs or by your CAs. You can also create and use CTLs to trust code signing certificates.

You can use Microsoft Certificate Services to issue digital signing certificates to developers who create software for distribution on your intranet.

Considerations for Code Signing on the Internet

For software distributed on the Internet, users are more likely to trust software that is signed by certificates issued by a reputable commercial CA. Using commercial CAs also removes the liability placed on your organization from assuming the responsibilities of a commercial CA for external software distribution. Therefore, if you distribute software on the Internet, consider obtaining the services of a commercial CA to issue digital signing certificates to your external software developers.

For private keys used to sign code, consider providing special protection for the keys. If someone obtains access to a private key, they could impersonate your organization, distribute signed but defective or malicious code, and damage your organization’s reputation. Some third-party vendors offer smart card solutions that enable code signing with smart cards. You can establish a smart card program for code signers to provide additional protection for their private keys.


Security with Encrypting File System

Windows 2000 includes the Encrypting File System (EFS) for encrypting files to provide confidentiality of information. EFS enables individual users to encrypt files, so others cannot read or modify the files.

Summary of How the EFS Works

EFS uses an encryption attribute to designate folders and files for EFS protection. When a file’s encryption attribute is on, EFS stores the file as encrypted ciphertext. When the authorized user opens an encrypted file in an application, EFS transparently decrypts the file in the background and provides a plaintext copy to the application. The user can view or modify the file and EFS transparently saves any changes as ciphertext. Others, except for designated and trusted recovery agents, are denied permission to view or modify EFS-encrypted files. EFS-protected files are bulk encrypted to provide confidentiality even from intruders who bypass EFS and attempt to read files using low-level disk utilities.

Because EFS operates transparently in the background, applications can save temporary files as plaintext to non-EFS-protected folders and inadvertently compromise confidentiality. Therefore, encryption is enforced at the folder level rather than the file level. You do not encrypt individual files, but instead you designate folders as EFS-protected folders. All files added to EFS-protected folders are encrypted. To specify EFS protection for a folder, you use the folder properties page in Windows Explorer.

EFS is only supported for the version of NTFS included with Windows 2000. It does not work with any other file system, including the previous versions of NTFS. For more information about EFS, see “Encrypting File System,” in the Microsoft Windows 2000 Professional Resource Kit, which contains core technologies for both Windows 2000 Professional and Windows 2000 Server.

File Encryption and Public Key Technology

For EFS to work, the EFS user must have a valid EFS Users certificate, and at least one EFS recovery agent must have a valid EFS Recovery certificate. EFS does not require a CA to issue certificates because EFS automatically generates it’s own certificates to users and to default recovery agents.

When EFS encrypts a file, it does the following:

  1. Generates a bulk symmetric encryption key.
  2. Encrypts files by using the bulk encryption key.
  3. Encrypts the bulk encryption key by using the EFS users public key.
  4. Stores the encrypted bulk key in a special field called the Data Decryption Field (DDF), which is attached to the EFS file.

EFS can then use the user’s private key to decrypt the bulk encryption key and decrypt the file as necessary. Because the private key is possessed only by the user, others cannot unlock the DDF. Every time EFS saves the encrypted file, it generates a new DDF using the user’s public key.

In addition, EFS enables designated recovery agents to decrypt and recover the file in case the user’s private key is lost or damaged. For each designated recovery agent, EFS does the following:

  1. Encrypts the bulk encryption key by using the EFS recovery agents public key.
  2. Stores the encrypted bulk key in a special field called the Data Recovery Field (DRF), which is attached to the EFS file.

The DRF can contain information for multiple recovery agents. Every time EFS saves the encrypted file, it generates a new DRF using information for the most current recovery agents. Recovery agents are determined by Encrypted Data Recovery Agents policy.

Encrypted Data Recovery Agent Policy

Recovery agents listed in the DRF can use their private keys to decrypt files for recovery when the user’s private key is unavailable, for example, when an employee is terminated for cause. Recovery agents can use the command line utility, cipher, to recover files.

Encrypted Data Recovery Agents policy is a subset of Public Key Group Policy. You can configure Group Policy to designate recovery agent accounts for domains, organizational units (OUs), or standalone computers. Central administrators can use the recovery agent account to recover EFS encrypted files for the domains or OUs where the EFS Group Policy applies. To restore files, recovery agents must use a computer where the recovery agent’s private key is stored.

By default, the domain Administrator user account is the recovery agent for computers connected to the network. On standalone computers, the local Administrator users account is the default EFS recovery agent. EFS automatically generates the EFS Recovery certificates for the default Administrator accounts.

Note

You can disable EFS for a domain, OU, or a standalone computer by applying an empty Encrypted Data Recovery Agents policy. An empty policy is not the same as no policy. When “no policy” is specified, the default recovery agents are used by EFS. However, an empty policy in effect designates no recovery agent, and EFS cannot operate without a recovery agent.

Considerations for Recovery Agents

The default EFS recovery policy agents might meet the needs of some organizations. However, other organizations might want to issue EFS Recovery certificates to designate other recovery agents for more flexible EFS recovery management. For example, you can issue recovery certificates to dedicated EFS recovery machines rather than to the default Administrator user account on domain controllers. You can also configure Encrypted Data Recovery Agents policy for laptop computers to use the same recovery agents when connected to the domain or when operated as standalone computers.

Rather than attempt to manage EFS recovery on a domain-wide basis, consider designating recovery agents to manage recovery for each OU. You can allow several OU administrators to use one recovery account to recover users files as necessary for that OU.

You can deploy Microsoft Certificate Services to issue EFS User certificates to users and EFS Recovery certificates to recovery accounts. If an issuing CA is available, EFS requests EFS certificates from the CA rather than generate its own certificates. Using a CA to manage EFS certificates provides the benefits of centralized certificate management, including the ability to control the lifetime of issued EFS certificates and to publish certificate revocation lists (CRLs).

Because old EFS files might contain out-of-date recovery agent information, you should maintain a recovery agent archive to ensure EFS files can be recovered using obsolete recovery agent private keys. For more information about EFS recovery, see “Microsoft Certificate Services” in this book.

Security for Laptop Computers

One of the primary uses of EFS is to encrypt data files on laptop computers to protect data in case the laptop is stolen. EFS protection is usually applied by using the Folder properties page in Windows Explorer. However, you can also use the EFS command line utility, cipher, to apply EFS protection.

To provide EFS security for laptops, do the following:

Make sure users’ My Documents folders are empty, and then apply EFS protection to each user’s My Documents folder. All new files stored in the EFS protected folder are encrypted. Then all new subfolders created in the EFS-protected folder also are EFS-protected. If you encrypt any files in My Documents, other users cannot gain access to the files.

Enable EFS for temporary folders used by applications. Because EFS operates transparently in the background, applications only deal with the plaintext and can save temporary files as plaintext to non-EFS-protected folders. You can also configure applications to store temporary files in EFS-protected folders.

Configure NTFS access control lists to prevent users from creating non-EFS-protected folders or changing EFS settings. Users can create as many folders in My Documents as needed; these folders are also EFS-protected.

Use the Windows 2000 System Key (SysKey) to protect EFS private keys. SysKey uses strong encryption techniques to increase protection of the users’ protected stores, including private keys.


Security with IP Security

Windows 2000 incorporates IP Security (IPSec). IPSec is a suite of protocols that are based on standards developed by the IP Security working group of the IETF. IPSec operates at the IP transport level (OSI network layer 3) and is transparent to the operating system and applications. IPSec provides end-to-end security between sending and receiving computers on IP networks. IPSec performs the following security tasks:

  • Authenticates the sender of IP data packets on the basis of Kerberos authentication, digital certificates, or a shared secret key (password).
  • Ensures the integrity of the IP data packets that are transmitted over the network.
  • Encrypts all data that is sent over the network for full confidentiality.
  • Hides the originating IP addresses from observation while they are en route.

For Kerberos clients, you configure IPSec policy to authenticate clients on the basis of Kerberos authentication. However, you can configure IPSec policy to use certificates to authenticate non-Kerberos clients. You can deploy Microsoft Certificate Services to issue authentication certificates to non-Kerberos IPSec clients. For more information about IPSec, see “Internet Protocol Security” in the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.


Security with Smart Cards

You can deploy smart cards and smart card readers to provide stronger user authentication and nonrepudiation for a range of security solutions, including network logon, secure Web communications, and secure mail. For more information about smart cards, see “Microsoft Certificate Services” in this book.

The Benefits of Smart Cards

Smart cards are credit card sized plastic cards that contain integrated circuit cards (ICCs). Smart cards are tamper proof and can be used to store users’ certificates and private keys. Smart cards can perform sophisticated public key cryptography operations, such as digital signing and key exchange.

Smart Cards provide the following benefits:

  • Because private keys are stored on the tamper resistant smart card rather than on a less secure medium such as the user’s hard disk, smart cards provide stronger security for user authentication and nonrepudiation,.
  • Because cryptographic operations are isolated from the operating system, smart cards are not susceptible to attacks on the operating system, such as buffer overflow and memory dump attacks to reveal secret keys or cryptographic secrets.
  • Because logon credentials accompany the user, you can issue a single smart card to each network user to meet local and remote network logon needs.

In addition, a smart card is protected from misuse by a personal identification number (PIN), which is known only to the smart card’s owner. To use the smart card, a user inserts the smart card in a smart card reader attached to a computer and, when prompted, enters the PIN. The smart card can be used only by someone who possesses the smart card and knows the PIN.

In addition, the smart card locks after only a few attempts to guess the PIN. Therefore, smart card PINs are not subject to dictionary or brute force attacks, where an attacker tries numerous PIN combinations in an attempt to “guess” the PIN. Because PINs are similar to passwords, security policies for passwords generally apply to PINs as well.

Network Smart Card Logon

Windows 2000 supports smart card logon for network logon using the extensions to the Kerberos v5 protocol that are permitted. For normal network logon, users press CTL+ALT+DEL to initiate the Windows 2000 secure logon sequence. When Smart Card logon is enabled, a user inserts his or her smart card to initiate the Windows 2000 secure logon sequence. The user is then prompted to enter the PIN for the smart card. If the user’s PIN and smart card credentials are valid, the user is logged on and granted rights and permissions for the appropriate user account.

Note

Allowing the CTL+ALT+DEL secure logon sequence defeats the purpose of smart card logon. During the transition to smart cards, you usually enable both logon methods. However, after smart card users are trained and smart card logon is tested in each domain, you can configure Group Policy to disable the CTL+ALT+DEL secure logon to force users to log on with smart cards.

Remote Access Logon

Microsoft® Windows® 2000 Server includes routing and remote access services to authenticate remote access network users. Routing and remote access services support smart-card logon authentication by using the EAP-TLS extension to the Point-to-Point Protocol (PPP). When EAP-TLS is enabled, a remote access user is prompted to insert his or her smart card and enter the PIN during network logon authentication. If the user’s PIN and smart card credentials are valid, the user is logged on and granted rights and permissions for the appropriate network user account. For more information about EAP-TLS, see the Microsoft® Windows® 2000 Server Resource Kit Internetworking Guide.

Other Smart Card Applications

A variety of third-party vendors manufacture PC/SC smart cards and readers that work with computers that are running Windows 2000, Windows 95, Windows 98, or Microsoft® Windows NT® version 4.0. You can deploy smart cards and readers in your organization to provide stronger security for Web communications, Web site access, and secure mail using smart card–aware applications.

Smart-card aware applications, such as Microsoft® Internet Explorer 5 and Outlook 98, can use smart cards to perform public key cryptography operations. For example, Internet Explorer can use smart cards to authenticate users for secure SSL and TLS communication sessions on the Web. Outlook 98 can use smart cards to perform S/MIME operations for secure mail.

Third-party vendors provide a variety of smart card applications that might meet your needs. For example, some third-party vendors provide code-signing applications that use smart cards to digitally sign software by using Authenticode technology. You can also build your own custom applications that use smart cards. For example, you can develop your own code-signing application to sign code using smart cards. For more information about developing custom applications, go to the Microsoft Developers Network (MSDN) Web site for a link to the Software Developer Kit (SDK) documentation. Search for MSDN at http://microsoft.com.

Note

Some third-party file encryption products support smart cards. EFS however does not support smart cards because EFS is designed to work transparently in the background without the need for user interaction.

Smart Card Enrollment

You can use Microsoft Certificate Services and the enrollment Web page to issue smart card certificates on the behalf of users. Security administrators can centrally issue and manage the smart card program to provide a high level of network user assurance. If you allow users to request their own smart card certificates, it weakens the overall security provided by smart cards.

Tip

Many organizations today issue employee card key and identification badges. You can add employee card keys and photographs to smart cards to provide a single solution for building and network access. Such combination cards can be used to grant physical access to buildings and secure rooms, as well as to grant network logon. Combination cards can also be used for electronic payment debit systems, for example, to pay for employee purchases at the organization’s cafeteria or store. For more information about combining card keys and picture badges with smart cards, contact the various smart card vendors.

You can choose to allow smart card certificates to be renewed automatically for Windows 2000 clients. However, to ensure the highest levels of network security, many organizations might want to re-issue smart cards and PINs on a periodic basis.

Smart Card Compatibility

Microsoft supports plug-and-play smart cards and readers that have been authorized to display the Windows-compatible logo. The Windows-compatible logo ensures that smart card products work in Windows 2000 and ensures interoperability between smart cards and readers from different vendors.

Microsoft provides drivers and support for Windows-compliant logo smart-card readers. Some vendors might provide drivers for noncompliant smart-card readers that do not work with other vendors’ smart cards. Some vendors might also provide noncompliant smart cards that do not work with other vendors’ smart-card readers. To ensure maximum continuing support and interoperability of smart cards and smart-card readers, it is recommended that you deploy only Windows-compatible logo smart cards and smart-card readers with Windows 2000.

For more information about the Windows-compatible logo program, visit the Hardware Testing at Microsoft Web page at http://microsoft.com/hwtest. For the list of currently compatible smart card products, visit the Microsoft Windows Hardware Compatibility List Web page at http://microsoft.com/hwtest/hcl.


Security with FORTEZZA Crypto Cards

Windows 2000 supports FORTEZZA Crypto Cards and FIPS 140-1, two federal cryptographic standards that are important to the protection of United States government communications. For more information about these standards, see the Microsoft Security Advisor Web site at http://microsoft.com/security.

FORTEZZA Crypto Cards

The FORTEZZA Crypto Cards is a Personal Computer Memory Card International Association (PCMCIA) card developed by the National Security Agency. FORTEZZA Crypto Cards are tamper resistant, hardware-based security tokens that provide cryptographic services such as data confidentiality, user authentication, and data integrity. FORTEZZA Crypto Cards function similarly to smart cards and readers but have more memory and more powerful processors and implement the cryptographic algorithms that were chosen to secure the Defense Message System.

Like smart cards, FORTEZZA Crypto Cards can be used for secure mail and secure Web communications. FORTEZZA Crypto Cards are usually used to protect sensitive but unclassified information, but enhanced versions of FORTEZZA Crypto Cards are also available to protect classified information.

Microsoft supports FORTEZZA Crypto Cards for secure mail by using the Defense Message System– compliant versions of Exchange and the Outlook 98 messaging and collaboration client. In Windows 2000, Internet Explorer, and Internet Information Services support FORTEZZA Crypto Cards for secure Web communications.

FORTEZZA Crypto Cards require the installation of PCMCIA interfaces on desktop computers and are much more expensive to deploy than industry-standard smart cards and smart-card readers. Smart cards provide nearly the same level of security as FORTEZZA Crypto Cards, but for much less cost. Therefore, some United States government agencies are deploying industry-standard smart cards to provide strong security for mail and Web communications as well as interoperability with industry standard public key information security and messaging systems.

For example, the United States Department of Defense has proposed two components of their public key infrastructure — a FORTEZZA-based High Assurance Messaging System and a smart card–based Medium Assurance Messaging System. High Assurance Messaging Systems use expensive FORTEZZA Crypto Cards and FIPS 140-1–compliant cryptographic modules to provide high-level information security. However, FORTEZZA-based systems are not compatible with industry-standard public key information security systems.

Medium Assurance Messaging Systems use inexpensive, industry-standard smart cards and public key infrastructure to provide medium-level information security. Moreover, non-Department of Defense organizations can conduct secure communications with Department of Defense agencies by using industry standard messaging and information security systems, without a need to invest in expensive FORTEZZA technology.

FORTEZZA Crypto Cards are available from a variety of National Security Agency–approved third-party vendors. For more information about FORTEZZA Crypto Cards, contact card vendors.

FIPS 140-1

The FIPS 140-1 standard was developed by the National Institute of Standards and Technology (NIST). FIPS 140-1, titled “Security Requirements for Cryptographic Modules,” specifies the United States government requirements for the proper design and implementation of hardware and software cryptographic modules that perform cryptographic operations for sensitive but unclassified information. FIPS 140-1 has been adopted by the Canadian Communication Security Establishment (CSE), and the American National Standards Institute. FIPS 140-1 is widely regarded as a de facto standard for cryptographic modules and has been incorporated into the International Standards Organization’s International Standard 15408, “Evaluation Criteria for Information Technology Security.”

The NIST certifies modules that are FIPS 140-1 compliant. Vendors can submit hardware and software cryptographic modules, such as FORTEZZA Crypto Cards, to the NIST for certification testing. FIPS 140-1 provides for increasing levels of security: Level 1, Level 2, Level 3, and Level 4. These levels cover a wide range of applications and environments where cryptographic modules are used. For more information about FIPS 140-1, see the NIST Web site at http://csrc.nist.gov.

Microsoft provides a FIPS 140-1 level-2 cryptographic service provider for use by organizations that require FIPS 140-1 level certification. The FIPS 140-1 Level 2 cryptographic service provider is subject to export restrictions and might not be available in your locality. For more information about obtaining the Microsoft FIPS 140-1 Level-2 cryptographic service provider, see the Microsoft Security Advisor Web site at http://microsoft.com/security.


Standards and Interoperability

To maximize the interoperability of Windows 2000 public key infrastructure with third-party applications that use public key technology, the public key infrastructure is based on the standards recommended by the Public Key Infrastructure X.509 (PKIX) working group of the IETF. Other standards recommended by the IETF have significant impact on public key infrastructure interoperability, including TLS, S/MIME, and IP Security. Microsoft is heavily involved in collaborations to develop standard within the IETF. Microsoft is also committed to assuring that its public key infrastructure products are compliant with the standards recommended by the IETF. For more information about IETF drafts and recommendations, see the IETF Web site at http://www.itef.org.

For cryptographic technology, the de facto standards are the Public Key Cryptography Standards (PKCS) developed and maintained by RSA Data Security, Inc. For more information, see their site at http://www.rsa.com. PKCS technologies are broadly deployed in products today and provide a basic, but well-tested and well-understood framework for interoperability. In fact, when the PKIX working group proposed another standard for certificate management, the S/MIME working group created its own proposal that is based on PKCS. This response is typical of IETF practices and reflects market awareness. De facto standards are most often the best kind, and Microsoft has taken advantage of these standards in its current public key infrastructure implementation to maximize interoperability.

Standards do not insure interoperability, although they help. The historic problem with standards is that commercial product deployment outpaces the collaborative process. This has been especially true for public key technology, where the IETF currently has multiple working groups actively developing proposed standards for public key technology. Yet many of the applications which are potential beneficiaries of these standards are already shipping products. Moreover, no standard can anticipate every application requirement and dependency. Even the most comprehensive standards get watered down in implementation. Interoperability, then, is the result of standards tempered over time by vendors working together to interoperate their products.

Interoperability between commercially available PKIX-compliant products is not guaranteed because the technology is still in an early stage. Today, SSL and TLS and S/MIME work well across the products of many vendors. As standards develop and vendors work together, more and more components of public key infrastructure are compatible. One day, interoperability could be largely taken for granted. Until then, however, the only way to know for sure how well products and features from different vendors work together is to test them in the lab.


Cryptography Export Restrictions

Some governments, including the United States government, currently place export restrictions on encryption technology. Some governments might place import restrictions on encryption technology. The availability of encryption technology described in this guide and the actual strength of the encryption you can use for security varies, according to the export or import restrictions for your geographic location.

United States polices and restrictions on encryption technology are subject to change at any time. Therefore, the export restrictions and license requirements for United States products that contain encryption technology can change at any time. For the latest information on export restrictions and license requirements for cryptography in Microsoft products, see the Microsoft Security Advisor Web site at http://microsoft.com/security.


Cryptographic Technologies for Open Network Security

Designing an appropriate security system to protect your organization’s confidential and proprietary information requires developing a set of appropriate solutions for specific risk scenarios. Microsoft® Windows® 2000 provides a range of technologies from which to choose in developing your security plan. Understanding the basic concepts underlying modern electronic cryptographic technologies is the starting point for making the right choices for your organization.

In This Chapter

The Basics of Cryptography

Public Key Infrastructure

How To Choose Appropriate Security Solutions

Related Chapters in the Resource Kit

  • For more information about security solutions, see “Security Solutions Using Public Key Technology” in this book.
  • For more information about Microsoft Certificate Services, see “Microsoft Certificate Services” in this book.

Additional Resources

For more information about cryptography, see the following publications:

  • Applied Cryptography: Protocols, Algorithms, and Source Code in C, B. Schneier, 1995, New York: John Wiley & Sons.
  • Internet Cryptography, R. E. Smith, 1997, Reading: Addison-Wesley.

For more information about public key technology and security on intranets and the Internet, see these publications:

  • Web Security & Commerce, S. Garfinkel and G. Spafford, 1997, Sebastopol: O'Reilly & Associates.
  • Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, W. Ford and M. S. Baum, 1997, Upper Saddle River: Prentice Hall PTR.
  • Understanding Digital Signatures: Establishing Trust over the Internet and Other Networks by G. L. Grant, 1997, New York: McGraw-Hill.
  • Digital Certificates : Applied Internet Security, J. Feghhi, J. Feghhi, and P. Williams, 1998, Reading: Addison-Wesley.


The Basics of Cryptography

Cryptography is the science of protecting information to ensure its confidentiality. It has been used for thousands of years as a means in attempts to provide secret communication between military forces, between political conspirators, and between espionage agents. The simplest form of cryptography is the mere substitution or transposition of letters to create a hidden message. The method of forming a hidden message has traditionally been called a cipher. The cipher is used to transform a readable message called plaintext into an unreadable, scrambled or hidden message called ciphertext.


Encryption

The process of converting plaintext into ciphertext is called encryption. As you would expect, the process of reconverting ciphertext to plaintext is called decryption. Traditionally, ciphers have used special information contained in secret keys to encrypt and decrypt messages. Modern systems of electronic cryptography use digital keys (bit strings) and special mathematical algorithms called encryption algorithms to encrypt and decrypt information.

There are two types of encryption: symmetric key encryption and public (asymmetric) key encryption. Symmetric key and public key encryption are used, often in conjunction, to provide a variety of security functions for network and information security.

Symmetric Key Encryption

Encryption algorithms that use the same key for encrypting and decrypting information are called symmetric key algorithms. The symmetric key is also called a secret key because it must be kept as a shared secret between the sender and the recipient of information. Otherwise, the confidentiality of the encrypted information is compromised. Figure 13.1 shows basic encryption and decryption that uses symmetric keys.

Figure 13.1 Encryption and Decryption With a Symmetric Key

Public Key Encryption

Encryption algorithms that use different keys for encrypting and decrypting information are most often called public key algorithms, but they are sometimes also called asymmetric key algorithms. Public key encryption uses a private key (held only by its owner) and a public key (one that is available to other entities on the network). A public key, for example, can be published in the directory so that it is accessible to users in the organization. The two keys are separate but complementary in function. Information that is encrypted with the public key can be decrypted only with the corresponding private key of the set. For some public key technologies, the public key can also be used to decrypt information encrypted with the private key. Figure 13.2 shows basic encryption and decryption with asymmetric keys.

Figure 13.2 Encryption and Decryption With Asymmetric Keys

Uses of Symmetric Key and Public Key Encryption

Symmetric key encryption and public key encryption are often used in conjunction to provide a wide range of network and online information security solutions. In Windows 2000, for example, secure mail, secure Web communications, Kerberos authentication, Encrypting File System (EFS), and Internet Protocol Security (IPSec) use a variety of symmetric key and public key encryption technologies.

Symmetric key encryption is much faster than public key encryption—often 100 to 1000 times faster. Public key encryption places a much heavier computational load on computer processors. than symmetric key encryption. Therefore, symmetric key technology usually is used to provide secrecy for bulk encryption and decryption of information. Public key technology is most often used to exchange symmetric keys securely over open networks, to digitally sign software and forms, and to authenticate clients and servers on the network.


The Security Functions of Cryptography

When most people think of cryptography, they usually think of secrecy, that is, the confidentiality of information that cryptography provides. However, good cryptography also can provide the following functions:

  • Authentication

    Verifies the identity of the entities that send information over the network. Without authentication, anyone with network access can use readily available tools to forge originating Internet Protocol (IP) addresses and impersonate others.

  • Confidentiality

    Protects information sent to intended recipients. Without confidentiality, anyone with network access can use readily available tools to eavesdrop on network traffic or intercept proprietary information. Intruders who gain illicit network rights and permissions can easily steal proprietary information that is contained in unencrypted files and documents.

  • Integrity

    Verifies that the contents of transmitted information have not been altered in route. Without integrity, anyone with network access can use readily available tools to alter information in route.

  • Nonrepudiation

    Ensures the sender of information cannot falsely deny having sent the information. Without nonrepudiation, anyone with network access can use readily available tools to forge originating IP addresses and impersonate others.

Windows 2000 distributed security technologies use symmetric key cryptography and public key cryptography to provide these functions. Security solutions usually require two or more of these functions to provide adequate levels of network and information security. If your security goal is to enable the exchange of confidential messages between executive staff members, you must provide for message confidentiality, authentication, integrity, and nonrepudiation. However, if you want only to ensure the authenticity and integrity of routine business messages between employees, you need only provide authentication and integrity for messages. Your security goals and requirements determine what functions you need to provide.


Symmetric Key Cryptography

Today, symmetric key cryptography is widely used to provide confidentiality for electronic information and network communications. Symmetric key encryption can be 100 to 1000 times faster than public key encryption, so it is usually used for the bulk encryption and decryption of information.

Symmetric Key Cryptography in Windows 2000

The Windows 2000 distributed security technologies use symmetric key cryptography to provide confidential online communications and to encrypt bulk information. For example, the Layer 2 Tunneling Protocol (L2TP), Internet Protocol Security (IPSec), and Transport Layer Security (TLS) protocols use symmetric key encryption to provide confidential online communications. Symmetric key encryption also is used to encrypt Secure Multipurpose Internet Mail Extensions (S/MIME) e-mail and EFS files.

The specific symmetric key algorithms and the length of the secret keys that are used vary with the security technology and protocol. For more information about the specific encryption algorithms and symmetric key lengths used for Windows 2000, see the applicable security chapters in other books of the Microsoft® Windows® 2000 Server Resource Kit and the distributed security entries in Microsoft® Windows® 2000 Server Help.

Improved Performance for Bulk Encryption

Bulk encryption can place significant load on client computers and server computers. Clients running today’s fast Pentium processors can typically handle bulk encryption with little problem, but servers that are providing encrypted communications can experience serious performance degradation as a result of the encryption performance load. Many third-party vendors provide crypto-accelerator boards that offload symmetric and public key encryption tasks from the server processors to optimized encryption hardware on the board. If you use a server to provide high-volume encrypted communications, such as L2TP or TLS communications, you should evaluate the benefits of adding crypto-accelerator boards.


Message Digest Functions

Message digest functions, also called hash functions, are used to produce digital summaries of information. Message digests, also called hashes, are bit strings that are usually from 128 bits to 256 bits in length and provide a unique digital thumbprint for each digital file or document. Message digest functions are mathematical functions that process information to produce a different message digest for each unique document. Identical documents have the same message digest; but if even one bit of the document changes, the message digest changes. Figure 13.3 shows the basic message digest process.

Figure 13.3 Message Digest Process

Message digest functions are commonly used to provide integrity for electronic files and documents. For example, message digests can be created and transmitted with e-mail messages. The recipient of an e-mail message can use the same message digest function to compute the digest and if the two message digests don’t match, the recipient knows the message was altered or corrupted en route. Of course, it’s possible for an intruder to intercept the message, modify it, and create a new valid message digest to fool recipients. To prevent such tampering, message digests often are digitally signed by using public key technology. Figure 13.4 shows a basic integrity check process for a message digest.

Figure 13.4 Message Digest Integrity Check Process

Windows 2000 distributed security technologies support a variety of message digest algorithms and digest lengths. For more information, see the applicable chapters of this book and the distributed security entries in Windows 2000 Server Help.


Public Key Cryptography

Today, public key cryptography plays an increasing role in providing strong, scalable security on intranets and the Intranet. Most public key cryptography is based on private key and public key sets, where the private keys are kept secret by the owners and the corresponding but different public keys can be known and used by anyone else. When a public key is used to produce ciphertext, only the corresponding private key can decrypt it. For some public key algorithms, a public key can be used to produce ciphertext, in which case only the corresponding private key can decrypt it.

A variety of public key algorithms have been developed to perform the following functions:

  • Encrypt symmetric secret keys for secure key exchange over public networks.
  • Authenticate the identity of both senders and recipients of communications over public networks.
  • Verify the integrity of data transmitted over public networks using digital signatures to ensure any tampering is detected.
  • Ensure the sender cannot later falsely deny sending communications. The sender’s digital signature is unique and cannot be counterfeited.

Windows 2000 supports a variety of public key technologies. The following sections briefly describe the basic public key technologies used with distributed security systems. For more specific information, see the applicable sections in this book and in distributed security entries in Windows 2000 Server Help.

Secret Key Exchange

Two common methods of exchanging secret keys using public key technology are the following:

  • Exchange of the key without the use of public key encryption by using the Diffie-Hellman Key Agreement algorithm.
  • Encryption of the secret key by using the recipient’s public key.

Both methods of key exchange provide for highly secure key exchange between communicating parties. An intruder who intercepts network communications cannot guess or decode the secret key necessary to decrypt communications. The exact method and algorithm used for key exchange varies for each security technology.

Diffie-Hellman Key Agreement

Public key cryptography was first proposed in 1975 by Whitfield Diffie and Martin Hellman, then researchers at Stanford University, to provide a secure solution for confidentially exchanging information online. Figure 13.5 is a simplified diagram of the Diffie-Hellman key agreement process. For technical discussions of Diffie-Hellman key agreement, see the professional literature on cryptography.

Figure 13.5 Diffie-Hellman Key Exchange

Diffie-Hellman key agreement is not based on encryption and decryption, but instead relies on clever mathematical functions that enable two parties to exchange information confidentially online. Each party randomly generates a public value and sends it to the other party. Each then generates a private secret value and uses its private value with the other party’s public value to generate the same secret key for sharing information confidentially. The shared secret key cannot be derived from the public values that were exchanged. Only each party’s public value is exposed on the network. The secret session key is known only to each party and is never exposed on the network. The shared secret keys can then be used with symmetric key encryption algorithms to encrypt and decrypt communications between the parties.

Key Exchange Using Public Key Encryption

Secret keys can be exchanged securely over a public network by encrypting the secret key with the intended recipient’s public key. Only the intended recipient can decrypt the secret key using the recipient’s private key. Any third party who intercepts the encrypted shared secret key cannot decrypt and use the secret key. Figure 13.6 shows a basic key exchange that uses public key encryption.

Figure 13.6 Key Exchange With Public Key Cryptography

The Rivest-Shamir-Adleman (RSA) algorithm is the most widely used public key cryptography system in use today. Patented by RSA Data Security, Inc., the RSA algorithms can be used to share secret keys as shown in Figure 13.6.

Digital Signatures

Digital signatures identify the originator of data and ensure the integrity of the data. The uses for digital signatures include the following:

  • Verifying the authorship or origin of digital data and ensuring the integrity of the data against tampering. For example, the S/MIME secure mail protocol can be used to digitally sign senders’ e-mail messages.
  • Safeguarding software programs that are distributed on the intranet or Internet to prevent tampering and the spread of viruses and other malicious code. For example, Microsoft Authenticode™ can be used to digitally sign software programs.

One possible way to create a digital signature is for the sender to create a signature by encrypting all of the data with the sender’s private key and then sending the encrypted data with the original data. Anyone with the sender’s public key can decrypt the signature and compare the decrypted message to the original message. Because only someone with the private key can create the signature, the integrity of the message is verified when the decrypted message matches the original. If an intruder alters the original message during transit, the intruder cannot also create a new valid signature. If an intruder alters the signature during transit, the signature does not verify properly and is invalid.

However, encrypting all data to provide a digital signature is impractical for two important reasons:

  • The ciphertext signature is the same size as the corresponding plaintext, so message sizes are doubled, which consumes large amounts of bandwidth and storage space.
  • Public key encryption is slow and places heavy computational loads on computer processors, so network and computer performance can be degraded significantly.

RSA Data Security Digital Signature Process

RSA Data Security, Inc., developed an efficient way to create digital signatures. In the RSA Data Security digital signature process, the private key is used to encrypt only the message digest (digital thumbprint). The encrypted message digest becomes the digital signature and is attached to the original data. Only a small amount of data is encrypted, so performance is fast, and the size of the digital signature has a negligible effect on bandwidth or storage space. Figure 13.7 shows the basic RSA Data Security digital signature process.

Figure 13.7 Basic RSA Data Security Digital Signature

To verify the contents of RSA Data Security -signed data, a recipient generates a new message digest from the received data, decrypts the original message digest with the originator’s public key, and compares the decrypted digest with the newly generated digest. If the two digests match, the integrity of the message is verified. The identify of the originator is also confirmed because the public key can decrypt only data that has been encrypted with the corresponding private key.

Digital Signature Security Standard

Another widely used public key cryptography system, is the Digital Signature Security Standard (DSS) developed by the National Security Agency (NSA) and adopted by the United States government as its digital signature standard. DSS defines the Digital Signature Algorithm (DSA), which functions in a similar manner as RSA, but DSA is used only for digital signatures and makes no other provisions for data encryption (for example, to provide secure secret key exchange). Therefore, DSA is not usually subject to the export restrictions of RSA. The digital signature algorithms for DSA and RSA are generally considered to be equally strong. However, the DSA signature verification process increases the processor load significantly relative to other algorithms, all other conditions being equal.

Public Key Algorithms Available In Windows 2000

Public key algorithms that you can use to provide network and information security solutions are available in the RSA-based Microsoft cryptographic service providers (CSPs) and several third-party CSPs that are included in Microsoft® Windows® 2000 Server. The Microsoft CSPs support RSA, Diffie-Hellman, and DSS algorithms. You can also obtain and use additional CSPs from third party vendors. For more information about Microsoft CryptoAPI and cryptographic service providers, see “Microsoft Certificate Services” in this book.


Public Key Infrastructure

You must have a public key infrastructure (known as a PKI) in place before public key cryptography is easily used and managed on public networks. Without this infrastructure, public key technology is not suitable for large-scale deployment in an enterprise. The public key infrastructure provides the framework of services, technology, protocols, and standards that enable you to deploy and manage a strong information security system that is based on public key technology. Major components of a public key infrastructure include digital certificates, certificate revocation lists (CRLs), and certification authorities (CAs).

Windows 2000 includes a public key infrastructure that is based on the recommendations of the Public Key Infrastructure X.509 (PKIX) working group of the Internet Engineering Task Force (IETF). Because the Windows 2000 PKI is standards-based, Windows 2000 public key solutions provide maximum interoperability with compliant third-party products. For example, you can trust and use digital certificates issued by PKIX-compliant third-party certificate services for secure mail and secure web communications. For more information about standards and interoperability, see “Standards and Interoperability” in “Security Solutions Using Public Key Technology” in this book.

For more information about the specific components of the Windows 2000 public key infrastructure, see “Microsoft Certificate Services” in this book. For more information about public key infrastructure and the PKIX working group, see the IETF Web site at http://www.itef.org.


The Need to Establish Trust for Private Keys

Public key cryptography typically uses public keys and private keys to provide confidentiality, integrity, and authentication. However, by itself public key cryptography cannot provide nonrepudiation or provide proof of the actual identity of the owner of a private key. There has to be a way to verify with a high degree of confidence the identify of the owner of a public key and private key set. There has to be a way to establish trust for geographically dispersed entities on intranets and the Internet.

On a public network, Bob can send a message to Alice, which is signed by his private key and accompanied by the corresponding public key. Alice can then use the public key to verify the integrity of the message, but how can she verify that the sender is really Bob? Perhaps Eve, an intruder, has intercepted Bob’s original message and substituted a counterfeit message to Alice along with a counterfeit public key. Eve might also be impersonating Bob by forging Bob’s network IP address.

In addition, if Alice receives a message from Bob, how does Alice know she can trust Bob? How does she know that Bob won’t falsely deny sending the message?

Peer-to-Peer Trust

For Alice to trust Bob’s private key, she needs assurance of Bob’s identity and verification that the public key is indeed Bob’s. If Alice knows Bob and obtains Bob’s public key in person, she can use Bob’s public key to verify digital signatures created by his private key with a high level of trust and assurance. If Eve attempts to impersonate Bob, Alice can use Bob’s public key to detect whether the message is signed by Bob’s private key or whether the message was altered. However, such peer-to-peer trust is generally limited to a small group of people who work in the same locality or who know each other well. Peer-to-peer trust works well for a small circle of people who choose to trust each other’s public keys, but peer-to-peer trust is not very scalable to the public Internet or to large and often geographically distributed enterprises.

Trust in Certification Authorities

To establish widespread trust for public keys on open networks, there have to be certification authorities that can certify identities on the network and that can provide assurance that public keys correspond to the identities of these entities on the network. Certifying authorities must positively verify the identity of each online entity, and they must provide a high level of assurance that online entities are who they claim to be.

Windows 2000 uses digital certificates that are issued by CAs to establish trust on the Internet. A digital certificate provides proof that the identity named in the certificate is the owner of the private key. Other entities on the network can have a high level of assurance that a public key really belongs to the owner of the private key.

If Alice trusts a CA on the basis of its good reputation, she can then choose to trust Bob’s public key when it is signed by the CA, even though she does not know Bob. Alice can be confident that Bob is who he claims to be during online communication. Furthermore, Alice can be confident that Bob cannot falsely deny sending a message that was signed with his private key.


Digital Certificates

Digital certificates are electronic credentials that certify the online identities of individuals, organizations, and computers. Certificates function similarly to identification cards such as passports and drivers licenses. identification cards are issued by recognized government authorities. When someone requests an identification card, a government authority verifies the identity of the requestor, certifies that the requestor meets all requirements to receive the card, and then issues the card. When the identification card is presented to others, they can verify the identify of its owner because the card provides the following security benefits:

  • It contains personal information to help identify and trace the owner.
  • It contains the photograph and the signature of the rightful owner to enable positive identification.
  • It contains the information that is required to identify and contact the issuing authority.
  • It is designed to be tamper resistant and difficult to counterfeit.
  • It is issued by an authority that can revoke the identification card at any time (for example, if the card is misused or stolen).
  • It can be checked for revocation by contacting the issuing authority.

Certification Authorities

A digital certificate is issued by a CA. The CA verifies the identities of requestors and issues digital certificates to qualified entities called subjects. CAs generate the public key and private key set used for public key cryptography. CAs digitally sign issued certificates to prevent anyone from tampering with certificates after the certificates have been issued. CAs also publish and maintain revocation lists of the certificates issued.

You can deploy Microsoft Certificate Services to create and manage CAs. You can also use a variety of commercially available third-party CA services.

A certificate contains information to identify the subject and the issuer CA as entities on the network. A certificate also contains the subject’s public key and binds the subject’s identity to the private key. The certificate is public information that is available to anyone and that can be published in directories. The certificate is digitally signed by using the CA’s private key, so anyone can verify that the certificate is valid and has not been tampered with by using the CA’s public key. Figure 13.8 shows how a certificate is signed by the issuing CA.

Figure 13.8 Certificate Signing Process

The subject’s public key is contained in the certificate; therefore, distributing the certificate also distributes the public key. Depending on the public key infrastructure, certificates can be published and distributed by way of directories, public folders, or Web pages.

Uses of Certificates

Digital certificates contain information that specifies how the certificate may be used. The basic uses of digital certificates include the following:

  • Digital signing of electronic files to verify file origin and the integrity of data.
  • Authentication and nonrepudiation of data sent by entities that are communicating over networks.
  • Secret key encryption to protect symmetric secret encryption keys (for example, to exchange secret keys safely over open networks).

Digital certificates can be used to provide a variety of security functions. Some common security functions of digital certificates include the following:

  • Secure mail to provide authentication, integrity, and nonrepudiation for e-mail communications and to provide confidentially between authorized senders and recipients.
  • Secure Web communications to provide authentication, integrity, nonrepudiation, and confidentiality between Web clients and servers.
  • Code signing to provide authentication, integrity, and nonrepudiation for executable code to be distributed on public networks.
  • Local network and remote access logon to authenticate users of network resources.
  • IPSec authentication to authenticate clients that do not use Kerberos authentication or shared secret passwords for IPSec communications.

Windows 2000 distributed security systems use digital certificates to provide a wide range of strong, scalable security functions. For more information about the uses of digital certificates in Windows 2000, see “Security Solutions Using Public Key Technology” in this book.


Certificate Services

You can deploy Microsoft Certificate Services to issue trusted certificates in your organization. You can also obtain certificate services from third-party vendors. For more information about Microsoft Certificate Services, see “Microsoft Certificate Services” in this book. For more information about deployment choices for certificate services, see “Planning Distributed Security” in the Microsoft® Windows® 2000 Server Deployment Planning Guide.

Certificate Authorities in the Enterprise

The role of commercial CAs on the Internet is well established today. Commercial CAs follow a number of standard practices and processes. Most digital certificates in use today are obtained from commercial CAs. However, an increasing number of organizations are deploying certificate services to implement CAs for issuing certificates on their intranets.

The role and function of CAs is basically the same, whether on an intranet or on the Internet. Nevertheless, because software and machines cannot assume legal responsibility, merely deploying certificate services in an organization by itself does not create a CA. Each CA is legally responsible for the management, security, and integrity of the certificates it issues. Therefore, the CA is the group that deploys and manages a certificate server to provide certificate services for the organization. CAs perform the following services:

  • Process certificate requests to verify the identity of the requestor and then issue a certificate based on the policy for that CA.
  • Manage certificate audit trail from enrollment to expiration or revocation.
  • Renew certificates before they expire.
  • Revoke certificates as necessary.
  • Maintain and publish certificate revocation lists (CRLs).
  • Handle legal and liability issues for compromised security.

Each CA is certified with a CA certificate and uses its private key to sign all of the certificates it issues. Protecting each CA’s private key is crucial to ensure the continuing integrity of CA trust. For more information, see “Protecting Keys for Certification Authorities,” in “Microsoft Certificate Services” in this book.

Your organization should develop the following policies to deploy CAs properly:

  • Certificate policies, which state the requirements for all certificates to be issued.
  • Certification Practices Statements (CPSs), which describe how each CA is to implement the certificate policies.

Certificate Trust in the Enterprise

In Windows 2000, you can choose to trust certificates issued by the CAs you deploy or by third-party CAs. Certificates issued by nontrusted CAs are treated as invalid. You can use Public Key Group Policy to specify certificate trust for each domain. All certificates issued by a trusted CA usually are valid in the domain; however, you can use Certificate Trust Lists (CTLs) to restrict how trusted certificates can be used in a domain.

For more information about certificate trust in Windows 2000, see “Public Key Group Policy,” “Certificate Trust Lists,” and “Certification Authority Trust Chain” in “Microsoft Certificate Services” in this book.


Certificate Lifecycle

The public key infrastructure provides the infrastructure, components and features necessary for managing digital certificates and keys throughout the certificate lifecycle. The certificate lifecycle includes the following:

  • Certificate requests and enrollment.
  • Certificate issue and distribution.
  • Certificate audit trail tracking.
  • Certificate revocation and publication of revocation lists.
  • Certificate expiration and renewal.

The lifetime of certificates is an important consideration when you design a public key infrastructure. For more information about the certificate lifecycle, see “Defining Certificate Lifecycles” in “Microsoft Certificate Services” in this book.

Certificate Enrollment

Users and computers must enroll to request and receive certificates from a CA. When a request is received by a CA, the CA verifies that the requestor is qualified to receive the certificate and either approves or denies the request. The enrollment process varies with the CA and its policies.

The Windows 2000 public key infrastructure provides several enrollment methods, including Web-based enrollment and automatic enrollment for computer certificates. For more information, see “Certificate Enrollment and Renewal” in “Microsoft Certificate Services” in this book.

Certificate Distribution

When certificates are issued, they must be distributed to the requestor as well as to distribution points where other users can have access to the certificates, as necessary. For example, user certificates for secure mail are usually distributed to a directory where others can easily gain access to and use the certificate and corresponding public key to communicate securely with the owner of the private key. However, EFS certificates need only be distributed to the local computers for the EFS users and EFS recovery agents.

Microsoft Certificate Services provides Exit modules to distribute certificates to a variety of distribution points, including Microsoft Active Directory™, public folders, Web pages, and local computers. For more information, see “Exit Modules” in “Microsoft Certificate Services” in this book.

Certificate Audit Trail

Each CA must maintain an audit trail of certificate requests and certificates issued until they expire. The audit trail is necessary to meet legal and security obligations of the CA. The CA’s administrators must be able to provide records to law enforcement agencies (for example, when an issued certificate was used for an illegal activity or fraudulent transaction). The CA’s administrators also need records so they can monitor for breaches in security (for example, to detect a failed request or to see whether someone has obtained certificates improperly).

The audit trail records all relevant information that is included in the certificates that are issued. The audit trail provides the information that is required to revoke certificates and add them to the revocation list. The CA’s administrators can query the audit trail to locate and view information about all certificates that have been issued by the CA.

Microsoft Certificate Services includes the Certificate Database that stores information about all certificate transactions, which provides a comprehensive audit trail for CAs. CA administrators can use the Certificate Services Manager to manage the audit trail. For more information, see “Certificate Database” and “Certificate Services Manager” in “Microsoft Certificate Services” in this book.

Certificate Revocation Lists

CAs publish Certificate Revocation Lists (CRLs) to identify certificates that have been revoked (for example, when a certificate’s user has left the organization or when the private key has been compromised). Certificates listed in CRLs are invalid and should not be trusted. The certificate validation process that is used by software can check CRLs to see whether certificates are still valid. When certificates expire, they are no longer published in the CRL. To prevent someone from tampering with CRLs, the CA uses its private key to sign CRLs digitally.

For more information about CRLs in Windows 2000, see “Certificate Revocation Lists” in “Microsoft Certificate Services” in this book.

Certificate Expiration and Renewal

When a certificate reaches its expiration date, the certificate is invalid and cannot be used any longer. However, certificates can be re-issued or renewed with a new, valid expiration date and a new public key and private key set. The renewal process is generally the same as the enrollment process, but certificate renewal also can be automated sometimes.

For a public key infrastructure that uses Microsoft Certificate Services, computer certificates can be renewed automatically. However, user certificates must be renewed manually. For more information, see “Certificate Enrollment and Renewal” in “Microsoft Certificate Services” in this book.


Key Management

Managing private keys is a crucial function of the public key infrastructure. Private keys must be securely generated, delivered to their owners, and stored. If attackers can obtain private keys, public key security is defeated.

Ideally, only the owners of private keys have the key, the key is stored in a protected place that is inaccessible to others, and no other copies of the key exist. However, sometimes (for example, to obtain a cryptography export license) a key escrow or key recovery system is required for the storage of private keys.

Key Security

In Windows 2000, private keys are managed and stored by CryptoAPI and CSPs. For more information, see “Microsoft CryptoAPI and Cryptographic Service Providers” in “Microsoft Certificate Services” in this book.

Protecting the private keys of CAs is critical to ensuring the security and integrity of the deployed public key infrastructure. For more information, see “Protecting Keys for Certification Authorities” in “Microsoft Certificate Services” in this book.

Key Escrow and Key Recovery

It is sometimes necessary to use a key escrow or key recovery system to store private keys that are used to encrypt secret keys for the bulk encryption of persistent data, such as EFS files and secure mail. Private keys that are stored in a key escrow or a key recovery system can be used to decrypt the files that have been encrypted with the corresponding public key. This would be necessary, for example, if the original private key had somehow been destroyed.

Important

The existence of a duplicate copy of a private key that is used for digital signing or authentication compromises the integrity and nonrepudiation of the information because someone else then can gain access to the duplicate of the key and impersonate the key’s owner. Therefore, private keys that used for digital signing and authentication should never be stored in a key escrow or key recovery system.

In a key escrow system, a third party holds the private keys. Key escrow systems are sometimes required to obtain government export licenses for encryption technologies. Key escrow systems are often used to enable government officials to obtain the private keys that have been used to encrypt information. Windows 2000 Server does not provide key escrow services. However, third-party applications and CSPs might support key escrow systems for use with Windows 2000 network and information security systems.

In a key recovery system, a copy of private keys are maintained in a protected store so that trusted administrators can recover keys when necessary. Windows 2000 Server does not provide automatic key recovery services, but you can implement key recovery systems manually (for example, for CA recovery and EFS recovery). For more information, see “Backing Up and Restoring Certification Authorities” and “Archiving and Recovering Keys for Encrypting File System” in “Microsoft Certificate Services” in this book.

You can also use other products to provide automated key recovery solutions. For example, Microsoft® Exchange Server version 5.5 provides an automated secure mail key recovery system. For more information, see “Recovering Keys for Secure Mail” in “Microsoft Certificate Services” in this book.


How To Choose Appropriate Security Solutions

You can use Windows 2000 distributed security technologies to provide a wide range of strong, scalable, cryptography-based solutions to protect network and information security. For more information about specific security solutions, see “Security Solutions Using Public Key Technology” in this book.

Cryptography-based security solutions can meet a wide range of security needs in your organization. The levels of security you choose for your organization are going to be determined by the value of the information that you want to protect and the costs to implement the various levels of security.

In general, making appropriate decisions about information security involves the following activities:

  • Analyzing business information and communications.
  • Defining communications and information security goals.
  • Determining communications and information security requirements.
  • Assessing cryptographic risks.
  • Assessing export restrictions that might apply to the cryptography technology you have chosen.
  • Assessing the costs and benefits of various security measures.
  • Testing each security solution that you choose to develop to ensure that it is the right choice for your organization.


Analyzing Business Information and Communications

Since the advent of the intranet and open networking, many organizations have allowed their electronic information and communications infrastructure to develop in an ad hoc manner. Often, security is taken for granted or overlooked when information is placed online; thus, proprietary information on intranets is readily available to intruders and to otherwise legitimate network users who do not have the need to know this information.

In addition, many organizations fail to provide security measures to protect their electronic mail, which would ensure the integrity of messages and their confidentiality. Messages that contain sensitive personal information or proprietary business information are routinely sent unencrypted over unprotected open networks. Therefore, you should analyze your organization’s existing business information and communications to identify areas of compromised or weak security and determine how you might improve your information security. The analysis process includes the following activities:

  • Defining the information classification levels and security policies for public, proprietary, and highly classified or sensitive information in your organization.
  • Evaluating all of the information that your organization stores (such as files and databases) on your networks, including both your extranets and the Internet.
  • Evaluating all of the information that your organization sends over internal networks and over the Internet or extranets.


Defining Communications and Information Security Goals

After you analyze your organization’s existing business information and communications, you have to define realistic security goals for your organization. This is an important step in controlling the overall cost of the security measures you eventually implement. Realistic security goals help ensure that you provide acceptable levels of security at acceptable costs.

The following are examples of realistic communications and information security goals:

  • Provide strong network logon authentication and at the same time reduce the help desk costs that are associated with supporting users who forget their passwords or who let their passwords expire.
  • Provide increased Internet security by preventing users from downloading or executing nontrusted and nonsigned content from the Internet.
  • Provide increased intranet security by preventing users from downloading or executing nontrusted and nonsigned content from the intranet.
  • Provide integrity and nonrepudiation for general business e-mail sent within your organization and enable users to send confidential e-mail as needed.
  • Provide integrity, nonrepudiation, and confidentiality for all business e-mail between members of the executive management and trusted executive staff.
  • Provide integrity, nonrepudiation, and confidentiality for all business e-mail that is sent over the Internet.
  • Provide strong user authentication for those project Web sites that are used for product development and project collaboration.
  • Provide authentication, integrity, and confidentiality for online cost accounting transactions.
  • Provide strong remote network logon using a single set of user network logon credentials to reduce the administrative overhead of maintaining separate local and remote network logon accounts for the same users.

Setting unrealistic security goals (for example, specifying an unnecessarily high level of security) can result in security requirements that cost too much to implement or maintain. Unrealistic security goals also can exceed the limits of existing technology and performance capabilities. For example, setting a goal to provide IP-level authentication, integrity, and confidentiality for all of your network communications might be achievable in a few years, but it is generally not feasible with today’s network infrastructures and the existing IPSec technology. IPSec can place a substantial load on network traffic, and many clients and applications do not yet support IPSec.


Determining Communications and Information Security Requirements

After you establish your security goals, determine what levels of security are required for specific types of information to meet your goals. This involves the following activities:

  • Creating information and communication scenarios that reflect the types of information you must protect and the flow of information between entities on the network(s).
  • Determining the security levels that are required for each scenario.
  • Defining the technical requirements for meeting the security goals.

For example, you might develop three different scenarios that reflect the information transfer in your company. One scenario might be private e-mail communications between executive staff members. A second scenario might be Web-based project collaboration and information sharing for classified product development projects. A third scenario might be network traffic and communications between members of the legal department.

In the first scenario, you might determine that communications between executive staff members requires secure, confidential e-mail that can be read only by the executive staff and a few other approved staff. You might also determine that the technology that is implemented must be strong and safe from attacks.

In the second scenario, you might determine that only approved members of the project team can have access to Web site content. You might also determine that some types of highly-classified information require very secure protection when they are transmitted over the network.

In the third scenario, you might determine that all network traffic between computers in the legal department must be very securely protected. You might also determine that communications with computers outside the legal department are not to be allowed.

On the basis of the requirements you identify during this process, you can choose the security measures that meet your requirements at the acceptable level of risk and acceptable level of cost.


Assessing Cryptographic Risks

There is no simple formula for determining how safe a specific cryptographic security solution is from attack. However, in general, the risk of key attacks and cryptanalysis attacks and the subsequent compromise of cryptographic systems are determined by the following factors:

  • Symmetric key length
  • Public key length
  • Cryptanalysis
  • Strength of the cryptographic algorithm and its implementation
  • Strength of the protocols used
  • Key lifetimes
  • Secure storage of secret and private keys
  • Randomness of generated keys

The following sections are a summary of the complex topics you need to understand when you are evaluating risks for cryptographic-based security. For more detailed information about the following topics, see the professional literature on cryptography and cryptanalysis.

Symmetric Key Length

Symmetric key encryption is subject to key search attacks (also called brute force attacks). Attackers try each possible key until the right key is found to decrypt the message. For example, for a 40-bit key, there are 240 possible values. By using a personal computer that can try 1 million keys per second, an attacker can try all possible keys in about 13 days. Of course, most attacks are successful before all possible keys are tried, and the processing power of personal computers continues to increase at a rapid pace. In fact, with the fastest off-the-shelf personal computers that are available today, an attacker can break 40-bit encryption in mere hours rather than days.

As the price of powerful computers becomes less expensive, successful key search attacks are becoming more common. Recently, the Electronic Frontier Foundation in San Francisco, California, built a supercomputer from off-the-shelf components for a cost of less than $250,000 and in July of 1998 used it to launch a brute force attack to decrypt a message that was encrypted with the widely implemented 56-bit Data Encryption Standard (DES) algorithm. The computer searched 92 billion keys per second and decrypted the message in 56 hours after trying about 25 percent of the possible keys. Some leading cryptography experts had previously estimated that the cost of building such a computer would likely be several million dollars or more.

In contrast to a 56-bit symmetric key, a 128-bit key has 2128 possible values. If you could use a computer that would allow you to try 100 billion keys a second and you used 10 million of these computers, it would take about 1013 years to try every possible 128-bit key value. This is nearly 1000 times longer than the estimated age of the universe (15 billion to 20 billion years). Therefore, all else being equal, the longer the key, the more protection you have from attacks. For symmetric key encryption, increasing the key size by 1 bit doubles the effort that is required for an exhaustive key search attack. Doubling the key size squares the amount of effort required.

However, the time that is required to discover a symmetric key in a key search attack becomes less as the computing power available to attackers increases. For example, in January of 1999, the Electronic Frontier Foundation used an improved version of its off-the-shelf supercomputer to break a message encrypted using 56-bit DES in about 22 hours—less than half the time it took to break 56-bit DES only 6 months earlier.

As the power of personal computers increases (historically the power of personal computers has doubled approximately every 18 months), the time required to launch key search attacks has diminished correspondingly. Furthermore, attackers often develop new techniques and algorithms to improve the efficiency of key search attacks. Therefore, estimates of the time required for key search attacks must be revised downward as the computing power and resources available to attackers increases.

In general, you can minimize the risk of key search attacks by choosing longer key lengths and shorter key lifetimes. A shorter key lifetime means the key is used to encrypt less information, which reduces the potential damage that is caused if a key is compromised.

Public Key Length

Public key cryptography is generally more susceptible to attacks than symmetric key cryptography, given a key of the same length. Public key cryptography is usually subject to attack methods such as factoring attacks, where attackers try all of the combinations of numbers that can be used with the algorithm to decrypt ciphertext. Factoring attacks are similar to key search attacks, but the number of possible factors varies with each algorithm and with the size of the public key and private key that are used. For a given key length, a factoring attack on public key cryptography requires fewer attempts than are required by a key search attack on symmetric key cryptography.

In addition, in comparison to symmetric key encryption algorithms, public key encryption algorithms are more likely to produce patterns and clues in ciphertext that help attackers decipher the plaintext. Furthermore, unlike symmetric key cryptography, the public key is available to attackers to help them discover the corresponding private key.

Finally, because public key algorithms are based on difficult-to-prove mathematical anomalies and number theory, attackers might discover a method for resolving the mathematical problems that provide the basis for public key algorithms. An attacker might discover an unknown mathematical short-cut to break the public key cryptography schemes in far less time than cryptography experts had predicted.

Although an 128-bit, symmetric key is generally considered unbreakable today, a 256-bit public key offers no protection from a knowledgeable attacker. As the size of public keys and private keys are increased, the effort required to compromise the keys by factoring attacks increases greatly—but at less than the exponential rate for symmetric keys. Therefore, the recommended size of public keys today is a minimum length of 512 bits. Just as for symmetric keys, the longer the public key or private key are used, the more likely it is that an attacker could compromise whatever public key cryptography system is used.

To protect valuable information and highly confidential communications with public key technology, use large keys (greater than 512 bits in length) and short key lifetimes. However, using large public and private keys can place a significantly higher performance load on computer processors.

Cryptanalysis

Key length is only one factor in the strength of a cryptographic algorithm. Key search or factoring attacks are seldom required to reveal the contents of encrypted information. Cryptanalysis, the science of interpreting ciphertext, can be used to find the plaintext, even when the cryptanalyst doesn’t know the encryption algorithm. If plaintext has known information, such as standard e-mail headers, cryptanalysts can use the known plaintext to break the encryption scheme for the rest of the ciphertext. If cryptanalysts can choose plaintext and submit it to be encrypted, they can analyze the ciphertext that corresponds to the chosen plaintext, identify subtle differences and patterns, and quickly break the encryption.

In general, you can reduce the risk of cryptanalysis attacks by doing the following:

  • Use industry-standard cryptographic algorithms that produce ciphertext that is resistant to cryptanalysis.
  • Limit the amount of ciphertext. For example, choosing shorter key lifetimes limits the amount of ciphertext available for cryptanalysis for that key. The smaller the amount of ciphertext, the smaller the amount of material that is available for cryptanalysis, which reduces the risk of cryptanalysis attacks.
  • Minimize the encryption of known plaintext. For example, if you encrypt known information such as system files on a hard disk, the known plaintext is available for cryptanalysis. You can reduce the risk of known plaintext attacks by not encrypting known files and sections of the hard disk.
  • Minimize the amount of plaintext that is encrypted with the same key. For example, during communication of encrypted online Web information, an attacker might be able to submit known plaintext for cryptanalysis. If the session key that is used to encrypt information is changed frequently, the amount of ciphertext produced by a single session key is limited; this reduces the risk of plaintext attacks.

Strength and Implementation of Cryptographic Algorithms

The strength of cryptographic encryption depends on the strength of the encryption algorithm and its implementation. A weak or poorly implemented cryptographic algorithm can be exploited to decrypt any ciphertext it produces. For example, a weak algorithm can produce ciphertext that contains hints or patterns that greatly aid cryptanalysis. A poorly implemented algorithm might also provide unintentional backdoors that attackers might discover and exploit.

For maximum protection, encryption keys should be generated randomly; however, faulty implementations of random generators also can produce keys that are predictable. Furthermore, the implementations of encryption algorithms also can be attacked at either the system level or the application level. An intruder might be able to start a computer from the floppy disk and use low-level disk tools to locate encryption keys stored on the hard disk. If an operating system caches secret keys in memory, attackers might be able to force buffer overflows or core dumps to reveal keys. Attackers also might be able to plant a rogue application or virus to modify how an encryption implementation works, for example, to generate random-looking keys that are known to the attacker.

In general, you can reduce the risk of weak algorithms and implementations by doing the following:

  • Use cryptographic algorithms that have been analyzed by the cryptology community (professional cryptographers and cryptanalysts) over time and that have no known significant security flaws or weaknesses.
  • Use implementations of the cryptographic algorithms that have been analyzed satisfactorily over a period of time. Some emerging distributed security technologies, such as IPSec, are new, and implementations might not have not been analyzed over a long period of time.
  • Use published, well-known, and patented algorithms rather than unpublished algorithms that are maintained as trade secrets. Published, well-known algorithms are widely analyzed by the cryptology community to help expose any flaws or weaknesses. However, cryptographic algorithms maintained as trade secrets are not widely tested by the cryptology community and could contain hidden flaws. Someone might reverse engineer the algorithm, expose hidden flaws, and exploit this secret knowledge to read and steal encrypted information.
  • Update security applications and systems when security patches and fixes become available to correct security problems as they are discovered. Many vendors, including Microsoft Corporation, make timely security fixes available for their products.
  • Use hardware-based cryptographic algorithms rather than software-based cryptographic algorithms. For example, many third-party vendors provide cryptography boards. All cryptography takes place in the crypto-hardware so that cryptographic operations are isolated and protected from the computer’s operating system and memory. An attacker would need physical access to the crypto-hardware to attempt an attack.

Strength of the Protocols

Cryptography-based security technologies must be implemented by using protocols. For example, secure mail systems can be implemented by using the S/MIME protocol, and secure network communications can be implemented by using the IPSec protocol. Secure Web communications can be implemented by using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.

Protocol standards, whether proprietary or open standards, often contain weaknesses or limitations that attackers can exploit (for example, for launching denial of service attacks). Even the best implementations of the protocol standards contain the weaknesses and limitations inherent in the standard. Furthermore, protocol standards usually enable support for weaker cryptography by design. For example, the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocol standards enable communications to default to weak encryption to support government-imposed export restrictions that have been placed on cryptography.

In general, you can reduce the risk of weaknesses or limitation in protocols by doing the following:

  • Use protocols that have been analyzed by the cryptology and technology communities over time and that have well understood limitations with acceptable security risks for the security systems you choose.
  • Use the most recent versions of protocols, which offer stronger security or fix identified weaknesses in previous versions of the protocol. Protocols are revised occasionally to improve the protocol and add new benefits and features.
  • Use the strongest security options that are available with the protocol to protect valuable information. When it’s feasible, require strong cryptography and do not allow systems to default to lower strength cryptography settings unless the value of the information to be protected is low.
  • Prohibit the use of older and weaker versions of protocols when you want to protect valuable information. For example, require SSL version 3 and TLS for secure Web communications, and prohibit SSL version 2 communications, which are less secure.

Key Lifetimes

The longer that secret keys or private keys are used, the more susceptible they are to attack. The longer a key is used, the more information is encrypted with the key. Longer key lifetimes also give attackers more time to exploit weaknesses in the cryptographic algorithms or their implementation.

In general, the more valuable the information is that is protected by keys, the shorter the key lifetimes should be. A shorter key lifetime not only minimizes the amount of ciphertext available for cryptanalysis, it also limits the damage that is caused if a key is compromised after a successful key attack.

Many security protocols, such as TLS and IPSec, use short-lived session keys to encrypt information. Other security technologies, such as S/MIME and EFS, generate a new, secret, bulk encryption key for each message or file that is encrypted. Bulk encryption keys are usually protected by encrypting the bulk encryption key with the users’ private keys. Because the private keys are used to encrypt small amounts of information, not much ciphertext is available for cryptanalysis. In the case of private keys, however, the public key is available for attackers to exploit in their attempts to decrypt the information.

The private key is valid only as long as the digital certificate is valid. When the certificate expires or is revoked, the private key and public key are no longer used. The lifetime of public keys is controlled by the lifetime of the digital certificate. When certificates are renewed, renewal systems might allow you to renew the private key as well. However, renewing the private key is generally not recommended. The certificate lifetime generally provides a good and reasonable limit on the time that private keys and public keys are in use.

Secure Storage of Secret and Private Keys

Even the longest encryption keys used with the best implemented encryption algorithms are worthless if either the secret (symmetric) key or private key is compromised. Anyone who can obtain a secret key can use it to decrypt and read all ciphertext that was encrypted with the key. Anyone who can obtain a private key can use it to impersonate the rightful owner during all communications and transactions on intranets or the Internet. The security of both the secret key and the private key is the weakest link in symmetric key and public key cryptography systems. Therefore, these keys must be in the possession only of authorized users, and they must be protected from unauthorized use.

For many encryption systems, such as EFS, secret encryption keys are stored on the local computer hard drive in a protected store. For EFS, encryption keys are protected by encrypting the bulk encryption key with the authorized user’s public key. The protected bulk encryption key can only be unlocked using the appropriate private key. Therefore, the security of the bulk encryption keys depends on various factors, such as the length of the private key, the strength of the public key algorithm, and how well the private key is protected.

For software-based cryptography, such as the cryptography used for standard TLS Web communications, secret session keys in use are typically temporarily stored or cached in the local computer’s memory. Attackers might be able to force buffer overflows or memory dumps to obtain the secret keys. Even if the secret key is protected by encryption while it is in memory, obtaining the protected key is the first step in a potential attack to discover what the key is. Therefore, software-based cryptography is inherently less secure than hardware-based cryptography.

In general, you can reduce the risk of compromising private keys by doing the following:

  • Use cryptography systems that have been analyzed by the cryptology community over time.
  • Use crypto-accelerator boards or other physical tokens that are available from third-party vendors. They provide a higher level of security because private keys are stored on tamper-resistant hardware rather than on the computer’s hard drive. All cryptography takes place in the crypto-hardware, so the secret key is never revealed to the operating system nor cached in memory. An attacker would need physical access to the crypto-hardware to attempt an attack.
  • Provide physical and network security for computers and devices where keys are generated and stored. For example, you can store servers used for CAs or TLS Web communications in locked data centers and configure network and computer security features to minimize the risks of attacks.
  • Use the Windows 2000 Systems Key (SysKey) to provide additional protection for private keys that are stored on local hard disks. For more information about SysKey, see Windows 2000 Server Help.

Randomness of Keys

To prevent key generation from being predictable, keys must be generated randomly. However, keys generated by computer software are never generated in a truly random manner. At best, software-key generators use pseudorandom processes to ensure that the keys that are generated are nearly impossible to predict. If attackers can predict the major variables that are used in key generation, they also can predict the keys that are generated.

Historically, some software applications have implemented random key generators that attackers were able to exploit to predict what keys would be generated. These flaws in software were soon discovered and corrected by software patches. The risks of poor random key generation is generally limited to new and unanalyzed products and technologies.

However, there is always a slight risk associated with keys that are generated by computer software, no matter how well the random key generator is implemented. To reduce the risk to a minimum and to provide maximum protection of highly valuable keys, choose security solutions that use truly random, hardware-generated keys. A variety of hardware-based cryptographic security solutions, including random key generators, are available from third-party vendors. For more information about hardware-based key generators, contact the specific vendors.


Assessing Export Restrictions for Cryptography

Cryptography is subject to export restrictions. Some governments, including the United States government, currently place export restrictions on encryption technology. Other governments also place import restrictions on encryption technology. The availability of the encryption technologies that are described in this guide and the actual strength of the encryption that you are allowed use for security varies according to the export or import restrictions for a specific geographical area. For more information, see “Export Restrictions” in “Security Solutions Using Public Key Technology” in this book.

Windows 2000 might be export-controlled in geographic areas where your organization has offices. If so, your security systems are going to be limited in cryptographic strength for those areas. Take cryptographic export restrictions into account when you are planning your security system.

Exportable security technology usually limits you to using much shorter symmetric encryption keys than the key length you are allowed to use for the nonexportable version of the same technology. For example, the nonexportable version of EFS uses bulk encryption keys with an effective length of 128 bits; bulk encryption keys for the exportable version of EFS can be limited to an effective key length of 40 bits or 56 bits. Likewise, bulk encryption keys for the nonexportable version of Microsoft® Outlook® 98 secure mail are 128 bits long, whereas the keys of the exportable version can be limited to 40 bits or 56 bits. Shorter encryption keys are much more vulnerable to brute force attacks than are longer keys. If you use exportable cryptography, limit key lifetimes to shorter periods to minimize the risk of brute force attacks.

Export restrictions also affect the strength of the keys and the algorithms that are available for public key cryptography operations. In Windows 2000, exportable CSPs support shorter public keys, shorter private keys, and fewer cryptographic algorithms. Because the exportable CSPs provide less cryptographic strength than non-exportable CSPs, consider choosing shorter certificate lifetimes when you use exportable CSPs. For more information, see “Microsoft CryptoAPI and Cryptographic Service Providers” in “Microsoft Certification Services” in this book.

In general, products and technology with exportable cryptography provide much less security than the nonexportable versions of the same products and technologies. Security between groups that use exportable technology and groups that use nonexportable technology is limited to the level of security that is provided by the exportable technology (which is always lower). For example, the confidential exchange of secure mail between groups using nonexportable technology and groups using exportable technology requires the use of the shorter encryption keys that are supported by the exportable technology.


Assessing the Costs and Benefits of Security Solutions

The overall cost of a specific security solution includes the following:

  • Resources necessary to plan, design, test, and deploy the system you choose.
  • Resources necessary to administer and maintain the solution after deployment.
  • Resources necessary to educate users about the new system and teach them how to use the new technology.
  • Resources necessary to support users (help desk) for the new technology.
  • Lost user productivity that is a result of the restrictions imposed by the security system.
  • Increased load and reduced performance of computers and networks that result from the increased load of cryptographic operations.

Assess the costs of security solutions to determine what solutions provide reasonable security benefits at acceptable costs and performance for your organization. The cost to implement and maintain security solutions by using Windows 2000 distributed security technologies can vary considerably and depends on your security goals and requirements.

For example, if you deploy smart cards to implement smart card network logon authentication, you also have to deploy a smart card program to enroll users and to support users who lose or leave their smart cards at home. The smart card security policies you choose affect the costs of the program significantly. If users who misplace their smart cards cannot quickly and easily obtain temporary access to the network, employees lose productivity. However, if you allow employees to log on to the network without smart cards, network security is reduced. The smart card program and policies you choose affect user support costs, employee productivity, and overall network security.

If you use secure Web communications to provide strong confidentiality for information on classified projects, you can deploy and manage certificate services to issue and maintain digital certificates for all project members who need to use the classified Web sites. Costs include the resources required for implementing and maintaining certificate services. Furthermore, high volumes of secure Web traffic place a large performance burden on Web server processors. Therefore, you might have to install expensive cryptographic accelerator boards in your Web servers to achieve acceptable Web performance. The overall cost varies according to the number of users that need to be supported and the volume of confidential communications. If you can realistically keep the amount of confidential Web communications to a low volume, the additional cost of cryptographic accelerators might not be necessary.


Testing Your Proposed Security Plan

No matter what security solutions you choose, always test them in test labs and in pilot programs before you deploy them in your production environment. Testing ensures that you have designed the right system for the needs of your organization. Always test the system in simulations of the actual network environments that are used your organization. For more information about testing and deploying security systems, see the Microsoft® Windows® 2000 Server Deployment Planning Guide.

In the testing process, be sure the system not only performs properly, but also that it provides the level of security you expect. Test all features and functions of the system. Develop and use formal test plans to help ensure that all security measures are thoroughly tested.

In addition to testing their proposed systems in test laboratories and pilot programs, many organizations now employ special security teams to launch real-world security attacks on their network security to discover and report weaknesses in their systems. Through these efforts, organizations frequently discover and correct security weaknesses before real attackers have a chance to discover and exploit them. Consider implementing an ongoing program to continuously field test and improve your network and information security systems. Regular field testing provides the maximum level of assurance for the security of your information.


Interpreting the Cluster Log

This chapter is based on Microsoft® Windows® 2000 applications and technologies that are under development. Future versions of this chapter will reflect subsequent changes in Windows 2000.

The cluster log is a record of the Cluster service (Clussvc.exe and associated files) activity in a server cluster member. Its completeness as a diagnostic log makes it a powerful troubleshooting tool. This chapter describes how to enable cluster logging and interpret the different types of cluster log entries. Specifically, it dissects a basic entry, identifies entries that are descriptive and need not be documented or interpreted, shows typical sets of entries for various situations, and provides guidelines for using logs to debug the cluster.

In This Chapter

  • Cluster Log Basics
  • Portions of the Cluster Log
  • Failure Scenarios
  • Tips
  • Starting the Cluster Log
  • State Codes
  • Context Numbers

Related Chapters in the Resource Kit

For more information on the Cluster service, see “Windows Clustering” earlier in this book and in Windows 2000 Server Help.

Additional Resources

  • For more information about the Microsoft Cluster service, see the Software Development Kit (SDK) documentation in the MSDN Library at http://msdn.microsoft.com.


Cluster Log Basics

In this chapter, the term cluster always refers to a server cluster, which is a group of servers linked by Cluster service that provides high availability and application-failover support while presenting a single IP address to clients. The Cluster service comprises Clussvc.exe and associated dynamic-link libraries (DLLs) and executable files.

Cluster activity is the sum of any and all events that take place in a cluster. Cluster processes are distinct threads or major blocks of activity, such as the initialization, join, and form processes.

The cluster log is a diagnostic log that is a more complete record of activity than the Microsoft® Windows® 2000 event log; the cluster log records the Cluster service activity that leads up to the events recorded in the event log. The event log can point you to a problem; in the cluster log, you can get at the root of the problem. (For more information about correlating the entries in the event log and the cluster log, see “Correlating the Windows 2000 Event Log and the Cluster Log” later in this chapter.)

Note

The cluster log only records the events of a single member in a server cluster. It does not record events for either network load balancing or for component load balancing. To record all the events in a Cluster service cluster, you must enable logging for each member of the cluster.

To successfully interpret the cluster log, you should be familiar with the following areas:

  • Anatomy of a cluster log entry.
  • Meanings of abbreviations such as [DM], [RGP], and [JOIN].
  • Meanings of state codes codes.
  • Techniques for tracking the source of a problem.

Important

The sample cluster log entries in this chapter were taken from a Microsoft® Windows NT® 4.0 Cluster service log, but the entries for Windows 2000 Cluster service logs are the same, with the exception that resources and resource groups are identified in each entry by their names as well as by their globally unique identifiers (GUIDs).


Anatomy of a Cluster Log Entry

Though cluster log entries may seem impenetrable at first glance, they are actually fairly easy to parse. Consider the following entry, the first line in the body of a typical cluster log:

0ae::01-20:42:17.976 Cluster Service started - Cluster Version 2.224.

Its main elements, common to every line of the log, include the following:

  • The ID of the thread issuing the log entry, for example, 0ae.
  • The time stamp in Greenwich Mean Time, for example, 01-20:42:17.976, where “01” is the day, “20” is the hour, “42” is the minute, and “17.976” is the second carried to thousandths.
  • The event description, such as “Cluster Service started.”

There are two types of cluster log entries, Component Event Log Entries and Resource DLL Log Entries.

Component Event Log Entries

The Cluster service comprises a number of components, such as the Database Manager and the Global Update Manager. The logging of their interactions is what makes the cluster log such a powerful diagnostic tool.

Here’s a typical example of a cluster log entry for a component event:

0ae::01-20:42:51.625 [FMX] Found the quorum resource fd2d5b4d-3d15-11d2-a398-0000f80629b5.

Entries describing component events follow the thread ID and time stamp with:

  • One of two types of abbreviations, enclosed in square brackets, such as [INIT] or [JOIN]. Capitalization is not significant; [dm] and [DM] both signify the Database Manager. The two types of abbreviations are:
    • The component that wrote the event to the cluster log (in this entry, [FMX], the transaction portion of the Failover Manager).
    • The state of the node from which the entry was written to the cluster log.

    The node state reflects the process that is in progress, such as [INIT] or [JOIN].

    A cluster log abbreviation may combine a component and state, as in [NMJOIN].

  • The event description (“Found the quorum resource fd2d5b4d-3d15-11d2-a398-0000f80629b5.”).

    In this event description, “fd2d5b4d-3d15-11d2-a398-0000f80629b5” is the globally unique identifier (GUID) for the resource that the component found. In Windows 2000, the resource or group name as well as the GUID is written to the cluster log.

Meanings of Abbreviations

Cluster log abbreviations for components and node states are shown in Table 16.1.

Table 16.1 Cluster Log Abbreviations for Components and Node States

Abbreviation | Node State or Component
[API] | API support. These entries come from the Cluster service component that provides support for the Cluster service API.
[ClMsg] | Cluster messaging. The component that Regroup (also known as Membership Manager—see later in this table) uses to send and receive its messages.
[ClNet] | Cluster network engine. Generic code to determine a node’s network configuration.
[CP] | Checkpoint Manager. Cluster resources can store operational and configuration information in the Windows NT registry. In order to properly failover a resource, the Cluster service might need to replicate this data on other nodes in the cluster before bringing the resource online. A resource can register subkeys of the registry with the Checkpoint Manager, which then monitors any changes to the key. These changes are recorded in the quorum log, a change file stored in the quorum log area. On the node to which the resource is being failed over, the resource key in the registry is updated with changes from the quorum log before the resource is brought online.
[CPROXY] | Cluster proxy. The cluster proxy is the component that is actually registered with the service controller as the Cluster service. The proxy starts and stops the Cluster service when requested by the service controller. When the cluster proxy receives the shutdown request from the service controller, it communicates with the Cluster service process (Clussvc.exe). Clussvc.exe, in turn, notifies all resource monitor processes (Resrcmon.exe) to shut down as well. The cluster proxy also detects abnormal termination of the Cluster service process and restarts the service when that occurs.
[CS] | Cluster service. This abbreviation is assigned to messages that come out of the Cluster service rather than one of its components.
[DM] | Database Manager. The agent through which other components read or make changes to the cluster configuration database.
[EP] | Event Processor. Components of the Cluster service register with the Event Processor to receive internal cluster events, such as a node’s going up or down.
[FM] | Failover Manager. Coordinates the moving of a group from one node to another based on failure criteria specifed by the group’s properties.
[FMX] | The transaction portion of the Failover Manager.
[GUM] | Global Update Manager. A cluster-wide, broadcast-like RPC mechanism that evicts a node from the cluster if the requested operation (update) fails on that node.
[INIT] | The initial state of a node prior to joining or forming a cluster.
[JOIN] | The node state that follows [INIT] when the node attempts to join a cluster. If the join operation succeeds, the state of the node then moves to cluster member.
[LM] | Log Manager. Maintains the quorum log.
[NM] | Node Manager. Keeps track of the state of other nodes in the cluster as well as maintaining the cluster-wide network configuration.
[OM] | Object Manager. Maintains an in-memory database of entities, or objects (nodes, networks, groups, and so on). Each object has an associated type and a set of methods with which other components can manipulate it. Each cluster object is represented in the Object Manager space. The Object Manager does not differentiate between types of objects.
[RGP] | The Membership Manager, also known as Regroup. Tracks which nodes are members of the cluster. Regroup writes entries to the log during initialization, form operations, and join operations, and when cluster membership changes.
[RM] | Resource Monitor. Any of the child processes (Resrcmon.exe) of the Cluster service that actually monitor individual resources.

Resource DLL Log Entries

Because resources and their groups are the basic unit of failover, resource DLL entries are key to understanding cluster activity. The following entry is an example of a Cluster log entry for a resource DLL event:

07d::01-20:43:07.960 Physical Disk <disk i>: CheckCorruption: ChkNtfs returned status of 0 for Disk I:.

Instead of listing an abbreviated component name between the time stamp and event description as component log entries do, entries describing resource DLL events list the following information:

  • Resource type (“Physical Disk”)
  • Resource name (“<Disk I:>”)

The event description in this example is “CheckCorruption: ChkNtfs returned status of 0 for Disk I:.”.

Meanings of State Codes and Status Codes

Interpreting state and status codes is a crucial part of deciphering the cluster log.

To find the meaning of the status codes

  1. On the command line, use the “nt helpmsg [error_number]” command.

    For example, in the following entry, “error 127” is the error number.

075::11-18:35:52.593 [RM] Failed creating resource e558e4a3-320d-    11d2-9b64-00805fa63b1b, error 127.

—or—

  1. Examine the Winerror.h file, which comes with Windows 2000 Advanced Server (For more information on finding the meaning of a status code in Winerror.h, see “Tips” later in this chapter.)

    For instance, in the following entry, “error 127” provides the number to search for in Winerror.h, where you find that the error is ERROR_PROC_NOT_FOUND, or, “The specified procedure could not be found.”

075::11-18:35:52.593 [RM] Failed creating resource e558e4a3-320d-    11d2-9b64-00805fa63b1b, error 127.

However, you need to study the context to discover the cause of the error. For the solution to this example, see “Failure Scenarios” later in this chapter.

To find the meaning of state codes

  1. From the event description in the cluster log, note the type of object—group, resource, node state, network, or net interface—associated with the entry.

Note

In Windows 2000, the resource name is given along with the GUID.

In Microsoft® Windows NT® 4.0, you need to find the GUID in the registry for the resource name. For more information on finding the resource name in the registry, see “Identifying GUIDs in the Registry” later in this chapter.

  1. In “State Codes” later in this chapter, find the meaning in the appropriate table.

For example, in the following entry, “state 129” means ClusterResourceOnlinePending.

0ae::01-20:42:51.671 [FM] FmpRmOnlineResource: Returning. Resource     fd2d5b4d-3d15-11d2-a398-0000f80629b5, state 129, status 997.


Techniques for Tracking the Source of a Problem

It’s often helpful to go to the end of the log to find the oldest failure that caused your problem and work your way backward.

You can also use the following for tracking processes in the cluster log:

  • Time stamps
  • GUIDs
  • Resources
  • Groups
  • Thread IDs
  • GUM sequence numbers
  • The gdwQuoBlockingResources global variable counts of shared locks

Time Stamps

Scan the time stamps for breaks of one second or more to find periods of inactivity in the Cluster service. A break might indicate that all threads of activity have completed.

For example, consider the following two entries from the logging of a cluster form process and cluster join process.

099::01-20:43:16.929 [FM] FmpRmWorkItemHandler: Exit
07f::01-20:43:42.859 [NM] [NmGetClusterOperationalVersion]     ClusterHighestVer=0x000200e0 ClusterLowestVer=0x000200e0     Flags=0x00000001

The first entry reports the last step in the local node’s having completed forming a cluster and brought resources and groups online. Note the 26-second break before the next event (at 43:42.859), the beginning of a JOIN attempt by the other node.

Rarely, time stamps can violate chronological order. For example, note that in the following series, the entry with the time stamp 01-20:43:09.257 (“[GUM] Thread 0x7f UpdateLock wait on Type 1”) appears out of order.

07b::01-20:43:09.304 [GUM] DoLockingUpdate successful, lock granted to 2
07b::01-20:43:09.304 [GUM] GumSendUpdate: Locker dispatching seq 1191        type 1 context 0
07b:    :01-20:43:09.304 [dm]DmWriteToQuorumLog Entry Seq#=1191 Type=0     Size=152
07b::01-20:43:09.304 [dm]DmWriteToQuorumLog Entry Seq#=1191 Type=0         Size=152
07b::01-20:43:09.304 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
07b::01-20:43:09.304 [GUM] GumSendUpdate: completed update seq 1191    type 1 context 0
07f::01-20:43:09.257 [GUM] Thread 0x7f UpdateLock wait on Type 1
07f::01-20:43:09.304 [GUM] DoLockingUpdate successful, lock granted to 2
07f::01-20:43:09.304 [GUM] GumSendUpdate: Locker dispatching seq 1192    type 1 context 4098
07f::01-20:43:09.304 [dm]DmWriteToQuorumLog Entry Seq#=1192 Type=4098 Size=180
07f::01-20:43:09.304 [DM] DmUpdateSetValue
07f::01-20:43:09.304 DM: Setting value InterfaceInstance for key     Resources\9fa85727-3942-11d2-a398-0000f80629b5\Parameters\2
07f::01-20:43:09.304 [dm]DmWriteToQuorumLog Entry Seq#=1192 Type=4098     Size=180
07f::01-20:43:09.304 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
07f::01-20:43:09.304 [GUM] GumSendUpdate: completed update seq 1192    type 1 context 4098

This happens because the logging process obtains the system time and then contends for the print lock. In this case, thread 07b acquired the print lock before thread 07f, which had the time but not the print lock.

To find why 07f didn’t acquire the print lock when it got the time, scan for the 07f thread ID. The following two lines show that 07f was interrupted by 0ae in the middle of a GUM update:

07f::01-20:43:09.257 [GUM] GumSendUpdate:  Locker waiting type 1     context 4098
0ae::01-20:43:09.265 [GUM] GumSendUpdate:  Locker waiting type 0     context 8

Resources and Groups

In Windows NT 4.0, one way to track a resource is to find the entry that reports the assigning of a GUID to the resource, then follow that GUID through the log.

In Windows 2000, however, log entries include resource and group names as well as GUIDs, making it much easier to navigate by tracking individual resources.

The Cluster service’s model for bringing resources online is to bring everything online as quickly as possible. The service can bring hundreds of resources online simultaneously.

In the following example, the Cluster service creates and brings online three resources simultaneously. In the cluster log from which these entries were extracted, quite a few entries intervene between the ones reproduced here.

Note also that for each resource, the Cluster service has already created the object in its memory and is now telling the resource monitor to create the resource and bring that resource online.

0ae::01-20:43:09.210 FmpRmCreateResource: creating resource 9fa85727-    3942-11d2-a398-0000f80629b5 in shared resource monitor
072::01-20:43:09.234 IP Address <dhcp IP addr>: NBT interface     \Device\NetBt_If2 (instance 0xD3F6B0E0) is no longer valid.
0ae::01-20:43:09.265 FmpRmCreateResource: creating resource bf37b6a6-    391d-11d2-a397-0000f803f3da in shared resource monitor
072::01-20:43:09.281 IP Address <Cluster IP Address>: NBT interface     \Device\NetBt_If4 (instance 0xD3F6B368) is no longer valid.
0ae::01-20:43:09.296 FmpRmCreateResource: creating resource bf37b6a7-    391d-11d2-a397-0000f803f3da in shared resource monitor
0aa::01-20:43:09.320 Network Name <Cluster Name>: Successful open of     resid 1378144

For information on examining the registry of Windows NT 4.0 systems to find the resource name or group name associated with a GUID, see “Identifying GUIDs in the Registry” later in this chapter.

Thread IDs

Use thread IDs to trace threads’ activities and interactions. This is especially helpful for finding out why a particular process is taking too long. One caveat, however: Related events can have different thread IDs in the cluster log. For example, the following two entries have different thread IDs, even though the activity they report—creation of a single resource—occurs as a single logical operation:

08c::01-20:48:53.281 FmpRmCreateResource: creating resource bf37b6a7-    391d-11d2-a397-0000f803f3da in shared resource monitor
082::01-20:48:53.304 Network Name <Cluster Name>: Successful open of     resid 1376480

GUM Sequence Numbers

The Global Update Manager (GUM) uses a unique sequence number for each transaction, incrementing by one each time. In the following log entry, “1166” is the sequence number:

0ae::01-20:42:51.664 [GUM] GumSendUpdate: Locker dispatching seq 1166    type 0 context 8

0ae::01-20:42:51.664 [GUM] GumSendUpdate: completed update seq 1166    type 0 context 8

GUM sequence numbers are useful for correlating the activities of two or more nodes in a cluster. For instance, a “Locker dispatching seq xxx” message has a corresponding “s_GumQueueLockingUpdate: dispatching seq xxx” in the other node’s log, where “xxx” represents the same sequence number. This can help you synchronize time periods between two logs. In the following pair of examples, note the continuity of the sequence number (“seq 1166”).

The following entries were logged on the node issuing a GUM update:

0ae::01-20:42:51.664 [GUM] GumSendUpdate: Locker dispatching seq 1166    type 0 context 8.
0ae::01-20:42:51.664 [GUM] GumSendUpdate: completed update seq 1166    type 0 context 8

The following entries were logged on the node receiving the same GUM update:

07f::01-20:42:51.998 s_GumQueueLockingUpdate: dispatching seq 1166    type 0 context 8.
07f::01-20:42:51.998 s_GumQueueLockingUpdate: completed update seq 1166    type 0 context 8

Shared Locks and gdwQuoBlockingResources

When something in your cluster is preventing the Quorum resource from being taken offline (as in a failover or move of the Quorum resource from one node to the other), you can use the gdwQuoBlockingResources count of shared locks to identify the root cause of the problem.

Locks prevent access to the Quorum resource by components other than the holder of the lock; there are two modes of locks on the Quorum resource: shared and exclusive.

  • Shared lock

    Dependent resources acquire quorum lock in shared mode when they need to access the quorum device and therefore need the quorum device to stay online. A shared lock prevents the Cluster service from taking the Quorum resource offline.

  • Exclusive lock

    The Cluster service acquires quorum lock in exclusive mode when the Quorum resource is going to go offline, because the information in the Quorum resource can only be modified by a thread that acquired the quorum lock in exclusive mode.

Clearly, acquisition of an exclusive lock must not supersede existing shared locks. That is, the Cluster service cannot acquire an exclusive lock and take the Quorum resource offline while components are in the middle of operations that require the Quorum resource to be online.

On the other hand, once existing processes that require access to the quorum device have completed their tasks, the Cluster service must have an opportunity to take the Quorum resource offline.

The Cluster service solves this problem with the gdwQuoBlockingResources global variable and a rule. The gdwQuoBlockingResources global variable is a count of the number of existing shared locks, which functions as follows:

  • When a process acquires a shared lock, the gdwQuoBlockingResources count increases by one.
  • When the process releases the shared lock, the gdwQuoBlockingResources count decreases by one.
  • When the gdwQuoBlockingResources count reaches zero, the Cluster service acquires the exclusive lock and is free to take the Quorum resource offline.

The rule is that a request for an exclusive lock is queued behind existing shared locks.

If there is a request to take the Quorum resource offline and the count is not zero, the “InterlockedIncrement” and “InterlockedDecrement” entries include the count of currently shared locks.

The following “InterlockedIncrement/InterlockedDecrement” pairs of entries bracket the acquisition of shared locks on the Quorum resource by resources that are dependent on the Quorum device’s staying online.

0b6::01-20:44:41.140 [FM] FmpRmOfflineResource: InterlockedIncrement on     gdwQuoBlockingResources for resource 9fa85727-3942-11d2-a398-    0000f80629b5
0b6::01-20:44:41.148 [FM] FmpRmOfflineResource: InterlockedDecrement on     gdwQuoBlockingResources for resource 9fa85727-3942-11d2-a398-    0000f80629b5
0b6::01-20:44:41.156 [FM] FmpRmOfflineResource: InterlockedIncrement on     gdwQuoBlockingResources for resource bf37b6a7-391d-11d2-a397-    0000f803f3da
0b6::01-20:44:41.171 [FM] FmpRmOfflineResource: InterlockedDecrement on     gdwQuoBlockingResources for resource bf37b6a7-391d-11d2-a397-    0000f803f3da

Now that you are acquainted with the elements of log entries, component abbreviations such as [RGP], and some techniques for reading the cluster log, you’re ready to see what the cluster log can tell you about cluster activities.


Portions of the Cluster Log

As you read entries in the cluster log, you notice the beginnings and endings of major processes, even though there are no divisions between the entries—it goes right from the last entry of an unsuccessful join to the first of a successful form, if that’s the next loggable event. An unsuccessful join starts at this entry and ends at that one; a successful form starts at that one and ends at this one.

The following major processes or groups of activities span large groups of cluster log entries:

  • Initializing the node
  • Joining a cluster (unsuccessful attempt)
  • An attempt by a node to form a cluster
  • Activity after a successful join or form operation

The following sections look in detail at each of those process-defined groups of log entries.


Initializing the Node

The following entries represent initialization of the local node, which is complete when the join attempt begins at 01-20:42:18.062 (the last entry).

0ae::01-20:42:17.984 [DM]: Initialization
0ae::01-20:42:17.984 [DM] DmpRestartFlusher: Entry
0ae::01-20:42:17.984 [DM] DmpStartFlusher: Entry
0ae::01-20:42:17.984 [DM] DmpStartFlusher: thread created
0ae::01-20:42:17.984 [NM] Initializing...
0ae::01-20:42:17.992 [NM] Local node name = CHARLWIT1-SP4.
0ae::01-20:42:17.992 [NM] Local node ID = 2.
0ae::01-20:42:17.992 [NM] Creating object for node 2 (CHARLWIT1-SP4)
0ae::01-20:42:17.992 [NM] Initializing networks.
0ae::01-20:42:17.992 [NM] Initializing network interfaces.
0ae::01-20:42:17.992 [NM] Initialization complete.
0ae::01-20:42:17.992 [FM] Starting worker thread...
0ae::01-20:42:17.992 [API] Initializing
0ae::01-20:42:17.992 [lm] :LmInitialize Entry.
0ae::01-20:42:17.992 [lm] :TimerActInitialize Entry.
0ae::01-20:42:18.000 [CS] Initializing RPC server.
0a8::01-20:42:18.031 [FM] Worker thread running
0ae::01-20:42:18.062 [INIT] Attempting to join cluster CLWCLUS

In the above sequence, highlighted entries give the name and ID of the node whose activity this log tracks.


Joining a Cluster (Unsuccessful Attempt)

The entries in this section are the complete record of a failed JOIN operation. They record the attempts of the joining node to find a sponsor in the available addresses and node names.

The first entry is a state entry, reporting the [INIT] state of the node attempting to join.

0ae::01-20:42:18.062 [INIT] Attempting to join cluster CLWCLUS

In all the following entries, the state of the node is [JOIN].

The following four entries record the spawning of threads that try to connect to the sponsor node. The service always tries to join a cluster through the:

  • Cluster’s IP address (“172.31.224.86”).
  • Sponsor’s name (“CHARLWIT2”).
  • Network interfaces that are marked for internal cluster communication on the sponsor node. In this example, that includes the sponsor node’s IP addresses “172.31.229.172” and “10.0.0.101”:
    0ae::01-20:42:18.062 [JOIN] Spawning thread to connect to sponsor     172.31.224.86
0ae::01-20:42:18.062 [JOIN] Spawning thread to connect to sponsor     10.0.0.101
0ae::01-20:42:18.062 [JOIN] Spawning thread to connect to sponsor     172.31.229.172
0ae::01-20:42:18.070 [JOIN] Spawning thread to connect to sponsor     CHARLWIT2
0ae::01-20:42:18.070 [JOIN] Waiting for all connect threads to     terminate.

The following entries record requests to join the cluster:

09f::01-20:42:18.070 [JOIN] Asking 172.31.224.86 to sponsor us.
084::01-20:42:18.078 [JOIN] Asking 10.0.0.101 to sponsor us.
0ac::01-20:42:18.078 [JOIN] Asking 172.31.229.172 to sponsor us.
075::01-20:42:18.085 [JOIN] Asking CHARLWIT2 to sponsor us.

The following entries report the failures (or successes) of the requests to join:

Note that in both the request entry and response entry for network address 172.31.229.172, the thread ID is “0ac.” Thread IDs are similarly consistent for the request and response entries for each of the other three network addresses.

0ac::01-20:42:18.085 [JOIN] Sponsor 172.31.229.172 is not available     (JoinVersion), status=1753.
075::01-20:42:18.101 [JOIN] Sponsor CHARLWIT2 is not available     (JoinVersion), status=1753.
09f::01-20:42:51.593 [JOIN] Sponsor 172.31.224.86 is not available     (JoinVersion), status=1722.
084::01-20:42:51.593 [JOIN] Sponsor 10.0.0.101 is not available     (JoinVersion), status=1722.
0ae::01-20:42:51.593 [JOIN] All connect threads have terminated.
0ae::01-20:42:51.593 [JOIN] Unable to connect to any sponsor node.
0ae::01-20:42:51.593 [INIT] Failed to join cluster, status 0


Forming a Cluster

The process of forming a cluster involves the following stages:

  • Starting an instance of the Resource Monitor (Resrcmon.exe).
  • Bringing the Quorum resource online, including:
    • Applying the quorum-log changes to the cluster database.
    • Recreating groups and resources in the cluster database.

    The Cluster service may have used stale object information at startup; now it needs to destroy and then recreate all the group and resource objects in order to refresh their information.

  • Configuring the networks.
  • Bringing resources online, which may involve updating resources’ registry keys.

    The cluster may be successfully formed before all the resources have been brought online.

The form operation starts at the following entry:

0ae::01-20:42:51:593 [INIT] Attempting to form cluster CLWCLUS

The form operation ends at the following entry, which may be many pages of text file later:

099::01-20:43:16:929 [FM] FmpRmWorkItemHandler: Exit

The following sections discuss some of the significant entries in a form operation.

Starting Resrcmon.exe

Multiple instances of the Resource Monitor can run, each managing as many or as few resources as is optimal for your cluster. This event is only the first, and occurs in the following entry:

0ab::01-20:42:51.609 [RM] Main: Initializing.

Bringing the Quorum Resource Online

These entries describe bringing the Quorum resource online. Note that the “Found the quorum resource” entry (fourth in the following entries) identifies fd2d5b4d-3d15-11d2-a398-0000f80629b5 as the Quorum resource. In clusters running on Windows 2000, the name “Quorum resource” will be provided along with the GUID.

Note that in the following entries, the resource is initialized, the other node is added as a possible owner for failover support, and the resource dependencies are created:

0ae::01-20:42:51.625 [FM] Creating resource fd2d5b4d-3d15-11d2-a398-    0000f80629b5
0ae::01-20:42:51.625 [FM] FmpQueryResourceInfo:initialize the resource     with the registry information
0ae::01-20:42:51.625 [FM] FmpAddPossibleEntry adding 2 to fd2d5b4d-3d15-    11d2-a398-0000f80629b5 possible node list
0ae::01-20:42:51.625 [FMX] Found the quorum resource fd2d5b4d-3d15-11d2-    a398-0000f80629b5.
0ae::01-20:42:51.625 [FM] All dependencies for fd2d5b4d-3d15-11d2-a398-    0000f80629b5 created

In the following entry, the node arbitrates for the ownership of the Quorum resource. Then, in the “Physical Disk” resource entry (the sixth in the following entries), its ownership of the quorum is confirmed. For more information on arbitration for the Quorum resource, see “Windows Clustering,” earlier in this book.

0ae::01-20:42:51.625 [FM] arbitrate for quorum resource id fd2d5b4d-    3d15-11d2-a398-0000f80629b5.
0ae::01-20:42:51.625 [FM] FmpQueryResourceInfo:initialize the resource     with the registry information
0ae::01-20:42:51.625 FmpAddPossibleNodeToList:: Warning, Node 1 not     found
0ae::01-20:42:51.625 FmpRmCreateResource: creating resource fd2d5b4d-    3d15-11d2-a398-0000f80629b5 in shared resource monitor
0ae::01-20:42:51.656 FmpRmCreateResource: created resource fd2d5b4d-    3d15-11d2-a398-0000f80629b5, resid 1425872
07c::01-20:42:51.664 Physical Disk <disk i>: Arbitrate returned status     0.
0ae::01-20:42:51.664 [FM] FmGetQuorumResource successful
0ae::01-20:42:51.664 [FM] FmpRmOnlineResource: bringing resource     fd2d5b4d-3d15-11d2-a398-0000f80629b5 (resid 1425872) online.
0ae::01-20:42:51.664 [CP] CppResourceNotify for resource disk I

In the fifth of the preceding entries, note “resid 1425872.” A resid is a pointer to a distinct resource object in the Resource Monitor process. From outside Resource Monitor, a resid is opaque.

Within the process of bringing the Quorum resource online, the following [GUM] entries report a successful GUM update. GUM relies on one node to be the master when issuing the updates to the other nodes. This master is called the “locker.”

Note that the sequence number is 1166. You can use this sequence number to track the update.

0ae::01-20:42:51.664 [GUM] GumSendUpdate:  Locker waiting type 0 context     8
0ae::01-20:42:51.664 [GUM] Thread 0xae UpdateLock wait on Type 0
0ae::01-20:42:51.664 [GUM] DoLockingUpdate successful, lock granted to 2
0ae::01-20:42:51.664 [GUM] GumSendUpdate: Locker dispatching seq 1166    type 0 context 8
0ae::01-20:42:51.664 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
0ae::01-20:42:51.664 [GUM] GumSendUpdate: completed update seq 1166    type 0 context 8

In the above entries, “type 0 context 8” occurs frequently. “Type 0 context 8” means that GUM is updating the Failover Manager, and that the update concerns a change in the state of a resource (in this case, the Quorum resource). Here’s why:

Type Code | Type
0 | GumUpdateFailoverManager
1 | GumUpdateRegistry
2 | GumUpdateMembership

  • In the string, “type” refers to update type. There are the three above types.
  • Each update type contains a certain number of routines. The context number indicates which routine is called. “Context Numbers,” later in this chapter, lists, in tables per update type, the context numbers and their meanings.

In the following entries, the state of the Quorum resource is propagated to the cluster nodes, then the Quorum resource is brought online.

0ae::01-20:42:51.664 [FM] FmpPropagateResourceState: resource fd2d5b4d-    3d15-11d2-a398-0000f80629b5 pending event.
0ae::01-20:42:51.664 [FM] FmpRmOnlineResource: Resource fd2d5b4d-3d15-    11d2-a398-0000f80629b5 pending
0ae::01-20:42:51.671 [FM] FmpRmOnlineResource: Returning. Resource     fd2d5b4d-3d15-11d2-a398-0000f80629b5, state 129, status 997.
07d::01-20:43:07.960 Physical Disk <disk i>: CheckCorruption: ChkNtfs     returned status of 0 for Disk I:.
07d::01-20:43:08.031 Physical Disk <disk i>: Online, created registry     watcher thread.
09b::01-20:43:08.031 [FM] NotifyCallBackRoutine: enqueuing event
099::01-20:43:08.031 [DM] DmpQuoObjNotifyCb: Quorum resource is online

Applying Quorum Log Changes to the Cluster Database

The quorum log, also known as the change log, records changes to the cluster configuration made since the last checkpoint was taken. If only one node is up and the cluster configuration changes, the Cluster service on other nodes must be able to determine the current cluster configuration from the cluster database and quorum log when they join the cluster.

Once the Quorum resource is online, the Cluster service:

  • Opens the quorum log.
  • Validates all the log records for integrity.
  • Reads log records.
  • Applies log changes to the configuration stored in the registry.

In the following entries, the Cluster service opens the quorum log:

099::01-20:43:08.031 [DM] DmpQuoObjNotifyCb: Quorum resource is online
099::01-20:43:08.031 [DM] DmpQuoObjNotifyCb: Own quorum resource, try     open the quorum log
099::01-20:43:08.031 [DM] DmpQuoObjNotifyCb: the name of the quorum file     is I:\MSCS\quolog.log
099::01-20:43:08.031 [lm] LogCreate : Entry FileName=I:\MSCS\quolog.log     MaxFileSize=0x00010000
099::01-20:43:08.031 [lm] LogpCreate : Entry

The service mounts the log and prepares it so that the log can be read and written.

099::01-20:43:08.031 [lm] LogpMountLog : Entry pLog=0x0016a220
099::01-20:43:08.031 [lm]:LogpMountLog::Quorumlog File size=0x00008000

In the following entries, the Cluster service reads log records at the given offset in the file.

099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x00000408
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x00000438
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x00000678
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x000006a8
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x000006d8
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x00000708
099::01-20:43:08.062 [lm]:LogpMountLog::checking LSN 0x00000738
099::01-20:43:08.070 [lm]:LogpMountLog::reading 1024 bytes at offset     0x00000800

Applying quorum log changes involves:

  1. Checking for a file tombstone.
  2. Propagating state changes to the local registry copy of the cluster database.

Checking for a Tombstone File

A tombstone file is created when a cluster node’s quorum-device information is outdated. A tombstone is a file that alerts the Cluster service that its quorum-device information is outdated. Practically speaking, it tells the Cluster service that ownership of the quorum device is not what the Cluster service’s configuration currently says it is.

For example, if node A was not running when the quorum device was changed from node A to node B, node A has outdated quorum-device information, while node B has the current quorum-device information. If node B now goes down and node A comes up, node A’s outdated quorum-device information points it to a “tombstone” file. The tombstone file doesn’t point to the new Quorum resource. The result is that node A can only join the cluster; it cannot form a cluster.

In the following entries, the Database Manager checks whether a valid quorum tombstone exists. The return value of zero in the second entry means the DmpChkQuoTombstone function encountered no errors in trying to validate the tombstone information, and the form process can continue.

0ae::01-20:43:08.109 [dm] DmpChkQuoTombStone - Entry
0ae::01-20:43:08.109 [DM] DmpChkQuoTombStone: Exit,dwError=0x00000000

If DmpChkQuoTombstone had found a valid quorum tombstone, the Database Manager would have logged an error in the event log, and the Cluster service would have exited immediately. In that case, you wouldn’t see the Exit statement from DmpChkQuoTombstone in the cluster log.

Propagating State Changes

When GUM sends out an update of any kind (passed to GUM as an argument list for it to run a procedure with), the update behaves like a remote procedure call (RPC), with the additional transactional qualification that if the update fails, the node for which it failed is evicted from the cluster. (The update is still a success.) This requirement makes sure all nodes have a consistent view of the cluster’s combined state.

An example of GUM’s propagating a state change is in the earlier section, “Bringing the Quorum Resource Online.” In the next example, GUM propagates the change described by the entries discussed in the previous section, “Applying Quorum Log Changes.” Both of these examples are typical of entries describing propagation of a state change.

Note

  • GUM assigns the sequence number (1167).
  • As in the earlier section, “Bringing the Quorum Resource Online,” type 0 context 8 indicates an update of the Failover Manager with a new resource state.

099::01-20:43:08.101 [GUM] GumSendUpdate:  Locker waiting
    type 0 context 8
099::01-20:43:08.101 [GUM] Thread 0x99 UpdateLock wait on Type 0
099::01-20:43:08.101 [GUM] DoLockingUpdate successful, lock granted to 2
099::01-20:43:08.101 [GUM] GumSendUpdate: Locker dispatching seq 1167    type 0 context 8
099::01-20:43:08.101 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
099::01-20:43:08.101 [GUM] GumSendUpdate: completed update seq 1167    type 0 context 8

Unrolling the Log

In unrolling the quorum log, the Database Manager:

  • Finds the last cluster database checkpoint.
  • Uploads it to the cluster hive.
  • Applies the changes recorded in the quorum log to the cluster database.

In the following entries, the Database Manager finds the last cluster database checkpoint:

0ae::01-20:43:08.109 [lm]:LogGetLastChkPoint::Entry
0ae::01-20:43:08.117 [DM] DmpLogFindStartLsn: LogGetLastChkPt rets,     Seq#=1165 ChkPtLsn=0x00001b88

The Database Manager uploads the checkpoint to the cluster hive:

0ae::01-20:43:08.117 [DM] DmpLogFindStartLsn: uploading chkpt from     quorum log
0ae::01-20:43:08.117 [DM] DmpRestartFlusher: Entry
034::01-20:43:08.117 [DM] DmpRegistryFlusher: restarting

The Database Manager loads the cluster database and applies the changes in the quorum log to the loaded cluster database:

0ae::01-20:43:08.140 [DM]: Loading cluster database from     D:\NT40sp4\cluster\CLUSDB
0ae::01-20:43:08.476 [DM] DmpLogFindStartLsn: chkpt uploaded from quorum     log
0ae::01-20:43:08.476 [DM] DmpLogFindStartLsn: LSN=0x00001b88,     dwError=0x00000000
0ae::01-20:43:08.476 [DM] DmpApplyChanges: The LSN of the record to     apply changes from 0x00001b88

Now that the quorum log entries have been read, validated, and propagated to the cluster’s database copies, the Cluster service is ready to recreate its groups and resources.

Recreating Groups and Resources

In order to start, the Cluster service may have used stale object information from the registry.

To refresh the object information, the Cluster service recreates the cluster configuration by destroying the in-memory copies of all the current objects (groups, resources, and so on) and recreating them from the updated registry information.

Destroying Groups and Resources

The following entries report the destruction of:

  • A group (bf37b6a8-391d-11d2-a397-0000f803f3da).
  • A DHCP IP Address resource (9fa85727-3942-11d2-a398-0000f80629b5).
  • The Quorum resource (fd2d5b4d-3d15-11d2-a398-0000f80629b5, identified earlier as the Quorum resource).

0ae::01-20:43:08.507 [FM] FmFormNewClusterPhase1, Entry.  Quorum group     will be deleted
0ae::01-20:43:08.507 [FM] DestroyGroup: destroying bf37b6a8-391d-11d2-    a397-0000f803f3da
0ae::01-20:43:08.507 [FM] DestroyResource: destroying 9fa85727-3942-    11d2-a398-0000f80629b5
0ae::01-20:43:08.507 [OM] Deleting object dhcp IP addr (9fa85727-3942-    11d2-a398-0000f80629b5)
0ae::01-20:43:08.507 [FM] FmpDestroyResource Exit.
0ae::01-20:43:08.507 [FM] DestroyResource: destroying fd2d5b4d-3d15-    11d2-a398-0000f80629b5
0ae::01-20:43:08.515 [FM] FmpDestroyResource Exit.
0ae::01-20:43:08.515 [FM] FmpDestroyGroup: Group bf37b6a8-391d-11d2-    a397-0000f803f3da destroyed.
0ae::01-20:43:08.515 [OM] Deleting object Disk Group 1 (bf37b6a8-391d-    11d2-a397-0000f803f3da)

Creating Groups and Resources

The forming cluster builds up the memory database by recreating first the groups and then the resources that it just destroyed.

Configuring the networks (covered in the next section) happens after the Cluster service has destroyed the groups and resources, and before it recreates them.

The process of recreating the groups and resources begins with:

0ae::01-20:43:09.187 [FM] FmFormNewClusterPhase2, Entry.

In the subsequent entries, up to “0ae::01-20:43:09.203 [FM] All groups created,” the forming node:

  • Creates and initializes groups:
    0ae::01-20:43:09.187 [FM] Creating group bf37b6a5-391d-11d2-a397-000    f803f3da
0ae::01-20:43:09.187 [FM] Initializing group 0x00166108
  • Reads group attributes from the registry:
    0ae::01-20:43:09.187 [FM] FmpQueryGroupInfo: reading group     information from the registry
  • Creates and initializes resources:
    0ae::01-20:43:09.195 [FM] Group bf37b6a5-391d-11d2-a397-0000f803f3da     contains bf37b6a6-391d-11d2-a397-0000f803f3da.
0ae::01-20:43:09.195 [FM] Creating resource bf37b6a6-391d-11d2-a397-    0000f803f3da
0ae::01-20:43:09.195 [FM] FmpQueryResourceInfo:initialize the     resource with the registry information
  • Adds possible owners to the resources and groups.

    In these two entries, the Cluster service adds first the local node (node 2) and then the other one as possible owners of resource bf37b6a6-391d-11d2-a397-0000f803f3da:

    0ae::01-20:43:09.195 [FM] FmpAddPossibleEntry adding 2 to bf37b6a6-    391d-11d2-a397-0000f803f3da possible node list
0ae::01-20:43:09.195 [FM] FmpAddPossibleEntry adding 1 to bf37b6a6-    391d-11d2-a397-0000f803f3da possible node list
  • Creates dependencies for the resources, as defined by registry information:
    0ae::01-20:43:09.195 [FM] All dependencies for bf37b6a6-391d-11d2-    a397-0000f803f3da created
  • Finally, after the service has created all the groups:
    0ae::01-20:43:09.203 [FM] All groups created.

With the group and resource objects recreated and initialized and their possible owners added, the Cluster service is ready to configure the cluster’s network information.

Configuring the Networks

In this phase of cluster formation, the Cluster service creates network objects and makes sure the information about them is accurate and consistent across the cluster. To do so, the network configuration engine:

  • Creates in-memory objects of the node, network, and network interface information in the registry (that is, the cluster database, as modified by the quorum log).
  • Collects system information.
  • Performs a local update.
  • Sets a database entry for the interface and network.
  • Recreates the networks and interface objects.
  • Registers the networks and interfaces with cluster transport.
  • Brings the networks and interfaces online with the Cluster service and transport.
  • Calculates NodeHighestVersion and NodeLowestVersion.
  • As the interfaces come online, notes their state changes.

The following entry begins the network-configuration process:

0ae::01-20:43:08.515 [NM] Synchronizing node information.

Creating In-Memory Objects

The Cluster service creates node objects that represent the members of the cluster, according to the cluster database.

Note that this cluster is being formed with only one node.

0ae::01-20:43:08.515 [NM] Creating node objects.
0ae::01-20:43:08.515 [NM] Creating object for node 1 (CHARLWIT2)

Collecting System Information

The Cluster service collects information from the system about network adapters and network connection objects.

Interfaces are IP addresses; an adapter can have multiple IP addresses (interfaces) associated with it.

Updating the Local Cluster Database and Setting Database Entries

0ae::01-20:43:08.523 [dm] DmBeginLocalUpdate Entry
0ae::01-20:43:08.890 [dm] DmBeginLocalUpdate Exit,     pLocalXsaction=0x00168498 dwError=0x00000000
0ae::01-20:43:08.890 [NM] Setting database entry for interface     4459cade-391e-11d2-a9c0-0000f8755f48
0ae::01-20:43:08.898 [dm] DmCommitLocalUpdate Entry
0ae::01-20:43:08.898 [dm] DmCommitLocalUpdate Exit, dwError=0x00000000
0ae::01-20:43:08.898 [dm] DmBeginLocalUpdate Entry
0ae::01-20:43:09.164 [dm] DmBeginLocalUpdate Exit,     pLocalXsaction=0x00168348 dwError=0x00000000
0ae::01-20:43:09.164 [NM] Setting database entry for interface     4459cadc-391e-11d2-a9c0-0000f8755f48
0ae::01-20:43:09.164 [dm] DmCommitLocalUpdate Entry
0ae::01-20:43:09.164 [dm] DmCommitLocalUpdate Exit, dwError=0x00000000

The following entry is good news; it means that all the previously existing adapters were matched to their previous networks.

0ae::01-20:43:09.164 [NM] Matched 2 networks, created 0 new networks.
0ae::01-20:43:09.164 [NM] Resynchronizing network information.
0ae::01-20:43:09.164 [NM] Resynchronizing interface information.

Recreating Network and Interface Objects

The Cluster service creates these objects based on changes detected in the current network configuration.

0ae::01-20:43:09.164 [NM] Creating network objects.
0ae::01-20:43:09.164 [NM] Creating object for network 4459cadd-391e-    11d2-a9c0-0000f8755f48
0ae::01-20:43:09.164 [NM] Creating object for network bf37b6a3-391d-    11d2-a397-0000f803f3da
0ae::01-20:43:09.171 [NM] Creating interface objects.
0ae::01-20:43:09.171 [NM] Creating object for interface 4459cadc-391e-    11d2-a9c0-0000f8755f48.

Registering Networks and Interfaces and Bringing Them Online

In this stage, the Node Manager:

  • Registers networks and network interfaces with cluster transport.

    Cluster transport is clusnet, a transport driver that sits on top of the User Data Protocol (UDP) and that the Cluster service uses to send messages to other cluster members.

  • Creates objects for the interfaces.
  • Brings the networks online.

0ae::01-20:43:09.171 [NM] Registering network bf37b6a3-391d-11d2-a397-    0000f803f3da with cluster transport.
0ae::01-20:43:09.171 [NM] Bringing network bf37b6a3-391d-11d2-a397-    0000f803f3da online.

In this section, you will notice event descriptions such as “Registering interface 4459cadc-391e-11d2-a9c0-0000f8755f48 with cluster transport, addr 172.31.224.87, endpoint 3343.” In this description:

  • “endpoint 3343” is the UDP socket number for clusnet’s (the cluster transport’s) socket.
  • “addr 172.31.224.87” is the relevant IP Address.

Thus, the description “Registering interface 4459cadc-391e-11d2-a9c0-0000f8755f48 with cluster transport, addr 172.31.224.87, endpoint 3343” means:

  • The node’s network interface is registered.
  • Socket 3343 on the node’s IP address has been opened.

0ae::01-20:43:09.171 [NM] Registering interfaces for network bf37b6a3-    391d-11d2-a397-0000f803f3da with cluster transport.
0ae::01-20:43:09.171 [NM] Registering interface 4459cadc-391e-11d2-a9c0-    0000f8755f48 with cluster transport, addr 172.31.224.87, endpoint     3343.
0ae::01-20:43:09.171 [NM] Creating object for interface 4459cade-391e-    11d2-a9c0-0000f8755f48.
0ae::01-20:43:09.171 [NM] Registering network 4459cadd-391e-11d2-a9c0-    0000f8755f48 with cluster transport.
0ae::01-20:43:09.171 [NM] Bringing network 4459cadd-391e-11d2-a9c0-    0000f8755f48 online.
0ae::01-20:43:09.171 [NM] Registering interfaces for network 4459cadd-    391e-11d2-a9c0-0000f8755f48 with cluster transport.
0ae::01-20:43:09.171 [NM] Registering interface 4459cade-391e-11d2-a9c0-    0000f8755f48 with cluster transport, addr 10.0.0.102, endpoint 3343.
0ae::01-20:43:09.171 [NM] Creating object for interface 9fa8568d-3942-    11d2-a398-0000f80629b5.
0ae::01-20:43:09.171 [NM] Registering interface 9fa8568d-3942-11d2-a398-    0000f80629b5 with cluster transport, addr 10.0.0.101, endpoint 3343.
0ae::01-20:43:09.171 [NM] Creating object for interface bf37b6a4-391d-    11d2-a397-0000f803f3da.
0ae::01-20:43:09.171 [NM] Registering interface bf37b6a4-391d-11d2-a397-    0000f803f3da with cluster transport, addr 172.31.229.172, endpoint     3343.
0ae::01-20:43:09.171 [NM] Initializing membership...

Regroup initialization is one of the four operations during which Regroup (the Membership Manager) writes entries to the cluster log. Regroup provides clusnet with cluster membership information, so that clusnet messages only go to nodes that are active members of the cluster.

0ae::01-20:43:09.179 [RGP] Node 2: RGP Init called : 0x2, 0x10,     0x303a60, 0x310ad0.
0ae::01-20:43:09.179 [ClMsg] Initializing.
0ae::01-20:43:09.179 [NM] Membership initialization complete.

NodeHighestVersion and NodeLowestVersion

It is highly desirable that the cluster’s various nodes run the same version of the Cluster service and its related files.

However, if the cluster nodes are running different versions, the Cluster service computes the version associated with the cluster as a whole. The Cluster service computes this cluster version from the versions of all the active members of the cluster. As other members join the cluster, the existing members compute a new version of the cluster.

In the following two pairs of entries, Cluster service computes a cluster version based on the versions of all the active members of the cluster, even when there is only one active member. The version number falls into two 16-bit numbers:

  • The top 16 bits represent the cluster major version.
  • The lower 16 bits represent the cluster build number.

First the Cluster service retrieves the NodeHighestVersion and NodeLowestVersion properties for each active member.

  • NodeHighestVersion reflects the version of the Cluster service that is running on the member.
  • NodeLowestVersion reflects the lowest version of Cluster service with which this active member can communicate.

0ae::01-20:43:09.179 [NM] NmpValidateNodeVersion: Node=2,     HighestVersion=0x000200e0, LowestVersion=0x000100e0

In the second pair of entries, the Cluster service calculates:

  • ClusterHighestVersion

    Roughly the minimum of all NodeHighestVersion properties, this indicates which versions of Cluster service are running on all active members, if the cluster is a mixed-mode cluster.

  • ClusterLowestVersion

    Roughly the maximum of all NodeHighestVersion properties, this indicates which version of Cluster service must be running on a server for it to join this cluster.

0ae::01-20:43:09.179 [NM] NmpCalcClusterVersion: status = 0     ClusHighestVer=0x000200e0, ClusLowestVer=0x000200e0
0ae::01-20:43:09.179 [NM] [NmpResetClusterVersion]     ClusterHighestVer=0x000200e0 ClusterLowestVer=0x000200e0

Cluster version 1 corresponds to the NT4/SP3 release and version 2 to the NT4/SP4 release.

Reporting interface state changes

In the following four entries, Node Manager reports that the state (“3”) of two interfaces and two networks has changed: namely, each is now up. For more information about the meanings of state codes for network interfaces and networks, see “State Codes” later in this chapter.

0ae::01-20:43:09.179 [NM] Setting interface 4459cadc-391e-11d2-a9c0-    0000f8755f48 state to 3
0ae::01-20:43:09.179 [NM] Setting network bf37b6a3-391d-11d2-a397-    0000f803f3da to state 3
0ae::01-20:43:09.179 [NM] Setting interface 4459cade-391e-11d2-a9c0-    0000f8755f48 state to 3
0ae::01-20:43:09.179 [NM] Setting network 4459cadd-391e-11d2-a9c0-    0000f8755f48 to state 3

Bringing Resources Online

This is the last stage in forming a cluster: The Cluster service creates resources and tries to bring them online. (In the section “Resources and Groups,” the following entries indicated that resource bf37b6a6-391d-11d2-a397-0000f803f3da is an IP Address resource and that resource bf37b6a7-391d-11d2-a397-0000f803f3da is a Network Name resource. In Windows 2000, these resource names appear directly in the cluster log.)

0ae::01-20:43:09.265 FmpRmCreateResource: creating resource bf37b6a6-    391d-11d2-a397-0000f803f3da in shared resource monitor
072::01-20:43:09.281 IP Address <Cluster IP Address>: NBT interface     \Device\NetBt_If4 (instance 0xD3F6B368) is no longer valid.

0ae::01-20:43:09.296 FmpRmCreateResource: creating resource bf37b6a7-    391d-11d2-a397-0000f803f3da in shared resource monitor
0aa::01-20:43:09.320 Network Name <Cluster Name>: Successful open of     resid 1378144

The following entries describe the Cluster service’s attempt to bring both resources online:

0ae::01-20:43:09.320 [FM] FmpOnlineGroup: trying to bring group     bf37b6a5-391d-11d2-a397-0000f803f3da online
0ae::01-20:43:09.320 [FM] OnlineGroup for bf37b6a5-391d-11d2-a397-    0000f803f3da
0ae::01-20:43:09.328 [FM] FmpRmOnlineResource: bringing resource     bf37b6a6-391d-11d2-a397-0000f803f3da (resid 1410064) online.
0ae::01-20:43:09.328 [CP] CppResourceNotify for resource Cluster IP     Address

In the following entry, the IP Address resource (note second following entry) acquires a shared lock on the Quorum resource, thus increasing the gdwQuoBlockingResources count. As long as the gdwQuoBlockingResources count is greater than zero, the Quorum resource cannot be taken offline. For more information, see “Shared Locks and gdwQuoBlockingResources” earlier in this chapter.

If you have difficulty interpreting the following entries, check these sections of this chapter:

  • “Anatomy of a Cluster Log Entry”
  • “Shared Locks and gdwQuoBlockingResources”
  • “Bringing the Quorum Resource Online”
  • “Bringing Resources Online”
  • “State Codes”
  • “Winerror.h”

0ae::01-20:43:09.328 [FM] FmpRmOnlineResource: called     InterlockedIncrement on gdwQuoBlockingResources
072::01-20:43:09.328 IP Address <Cluster IP Address>: Bringing resource     online...
0ae::01-20:43:09.328 [GUM] GumSendUpdate:  Locker waiting    type 0     context 8
0ae::01-20:43:09.328 [GUM] Thread 0xae UpdateLock wait on Type 0
0ae::01-20:43:09.328 [GUM] DoLockingUpdate successful, lock granted to 2
0ae::01-20:43:09.328 [GUM] GumSendUpdate: Locker dispatching seq 1195    type 0 context 8
0ae::01-20:43:09.328 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
0ae::01-20:43:09.328 [GUM] GumSendUpdate: completed update seq 1195    type 0 context 8
0ae::01-20:43:09.328 [FM] FmpPropagateResourceState: resource bf37b6a6-    391d-11d2-a397-0000f803f3da pending event.
0ae::01-20:43:09.328 [FM] FmpRmOnlineResource: Resource bf37b6a6-391d-    11d2-a397-0000f803f3da pending
0ae::01-20:43:09.328 [FM] FmpRmOnlineResource: Returning. Resource     bf37b6a6-391d-11d2-a397-0000f803f3da, state 129, status 997.
0ae::01-20:43:09.328 [FM] OnlineResource: bf37b6a7-391d-11d2-a397-    0000f803f3da depends on bf37b6a6-391d-11d2-a397-0000f803f3da. Bring     online first.

In the following entries, the Database Manager has set a new value in the cluster configuration database stored in the registry. It takes a checkpoint of the key and stores it on the quorum disk (I: ). If the Cluster service on this node were to crash right after this operation and the other node were started, the other node would have access to the recorded changes and could apply them.

0ae::01-20:43:09.351 [LM] DmpGetSnapshotCb::checkpoint file name     =I:\MSCS\chk4AF.tmp Seq#=1199
0ae::01-20:43:09.960 [dm] DmpGetSnapShotCb - DmpGetDatabase returned     0x00000000
0ae::01-20:43:09.960 [LM] LogCheckPoint: ChkPtFile=I:\MSCS\chk4AF.tmp     Chkpt Trid=1199
0ae::01-20:43:09.960 [lm] LogFlush : pLog=0x0016a220 writing the 1024     bytes for active page at offset 0x00002400

Finally—after the formation of the cluster has succeeded—the IP Address resource comes online. For the meaning of the cluster resource state codes 129 and 2, see “State Codes” later inthis chapter.

099::01-20:43:16.875 [FM] HandleResourceTransition: Resource Name =     bf37b6a6-391d-11d2-a397-0000f803f3da old state=129 new state=2

Bringing resource bf37b6a7-391d-11d2-a397-0000f803f3da (the Network Name resource) online takes longer. In the first four entries, the Network Name resource is trying to come online, but must wait for bf37b6a6-391d-11d2-a397-0000f803f3da, the IP Address resource on which the Network Name resource depends, to come online first.

0a8::01-20:43:16.882 [FM] OnlineWaitingTree, bf37b6a7-391d-11d2-a397-    0000f803f3da (129) depends on bf37b6a6-391d-11d2-a397-0000f803f3da     (2). Start now
0a8::01-20:43:16.882 [FM] OnlineWaitingTree, Start resource bf37b6a7-    391d-11d2-a397-0000f803f3da
0a8::01-20:43:16.882 [FM] OnlineResource: bf37b6a7-391d-11d2-a397-    0000f803f3da depends on bf37b6a6-391d-11d2-a397-0000f803f3da. Bring     online first.
0a8::01-20:43:16.882 [FM] FmpRmOnlineResource: bringing resource     bf37b6a7-391d-11d2-a397-0000f803f3da (resid 1410904) online.

An update of the Network Name resource’s new state is sent to the other nodes in the cluster by the locker node:

0a8::01-20:43:16.882 [GUM] GumSendUpdate:  Locker waiting    type 0     context 8
0a8::01-20:43:16.882 [GUM] Thread 0xa8 UpdateLock wait on Type 0
0a8::01-20:43:16.882 [GUM] DoLockingUpdate successful, lock granted to 2
0a8::01-20:43:16.882 [GUM] GumSendUpdate: Locker dispatching seq 1206    type 0 context 8
0a8::01-20:43:16.882 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
0a8::01-20:43:16.882 [GUM] GumSendUpdate: completed update seq 1206    type 0 context 8
0a8::01-20:43:16.882 [FM] FmpPropagateResourceState: resource bf37b6a7-    391d-11d2-a397-0000f803f3da pending event.
0a8::01-20:43:16.882 [FM] FmpRmOnlineResource: Resource bf37b6a7-391d-    11d2-a397-0000f803f3da pending
0a8::01-20:43:16.882 [FM] FmpRmOnlineResource: Returning. Resource     bf37b6a7-391d-11d2-a397-0000f803f3da, state 129, status 997.
0a8::01-20:43:16.882 [FM] OnlineWaitingTree, online for resource     bf37b6a7-391d-11d2-a397-0000f803f3da returned pending.
07d::01-20:43:16.898 [DM] DmUpdateSetValue

In the following bold entries, the Cluster service updates a value for the registry key for resource bf37b6a7-391d-11d2-a397-0000f803f3da in the cluster database and writes the change to the quorum log.

07d::01-20:43:16.898 DM: Setting value LastName for key     Resources\bf37b6a7-391d-11d2-a397-0000f803f3da\Parameters\2
07d::01-20:43:16.898 [dm]DmWriteToQuorumLog Entry Seq#=1208 Type=4098     Size=174
07d::01-20:43:16.898 [lm] LogWrite : Entry TrId=1208 RmId=5 RmType =     4098 Size=174
07d::01-20:43:16.898 [lm] LogWrite : Exit returning=0x00002678
07d::01-20:43:16.898 [GUM] GumpDoUnlockingUpdate releasing lock     ownership
07d::01-20:43:16.898 [GUM] GumSendUpdate: completed update seq 1208    type 1 context 4098
0b1::01-20:43:16.914 Network Name <Cluster Name>: Registered server name     CLWCLUS on transport \Device\NetBt_If8.
0b1::01-20:43:16.921 Network Name <Cluster Name>: Registered workstation     name CLWCLUS on transport \Device\NetBt_If8.
0b1::01-20:43:16.921 Network Name <Cluster Name>: Network Name CLWCLUS     is now online
    09b::01-20:43:16.929 [FM] NotifyCallBackRoutine: enqueuing event

In the following entry, a shared lock on the Quorum resource that was acquired earlier is released. For more information about shared locks and the gdwQuoBlockingResources global variable, see “Shared Locks and gdwQuoBlockingResources” earlier in this chapter.

099::01-20:43:16.929 [FM] HandleResourceTransition: call InterlockedDecrement on gdwQuoBlockingResources, Resource bf37b6a7-391d-11d2-a397-0000f803f3da
099::01-20:43:16.929 [FM] HandleResourceTransition: Resource Name = bf37b6a7-391d-11d2-a397-0000f803f3da old state=129 new state=2

With the preceding events marking successful completion of that phase of the form process, the Cluster service takes a checkpoint (a snapshot) of the quorum database:

0ae::01-20:43:09.335 [FM] FmFormNewClusterPhase2 complete.
0ae::01-20:43:09.335 [dm]DmUpdateFormNewCluster - taking a checkpoint
0ae::01-20:43:09.335 [LM] LogCheckPoint entry
0ae::01-20:43:09.335 [lm] LogpAppendPage : Writing 1024 bytes to disk at     offset 0x00002000

Cluster Successfully Formed

In the following entry, the Initialization process reports that the node has successfully formed a cluster:

0ae::01-20:43:10.132 [INIT] Successfully formed a cluster.

The gap between the following two entries indicates that this major process is completed. In the gap, the Cluster service has pinged its own IP Address to make sure the IP Address is unique.

08f::01-20:43:10.148 [CPROXY] clussvc initialized
09f::01-20:43:15.867 IP Address <dhcp IP addr>: IP Address 10.0.0.103 on     adapter DC21X41 online


Log Summary of Cluster Formation

You have looked in detail at the typical cluster log entries for cluster formation, in which the Cluster service:

  • Started the Resource Monitor, the manager of the cluster’s resources.
  • Brought the Quorum resource online.
  • Updated all copies of the cluster database.
  • Recreated groups and resources.
  • Configured the networks, recreated network and interface objects, registered the networks and interfaces with cluster transport, and brought them online.
  • Brought all resources online.
  • Finally took a checkpoint of the cluster database.

And the cluster is formed. The process continues bringing resources online after the cluster formation is reported complete.


Failure Scenarios

The scenarios in this section are either created in laboratory conditions or reported from field situations. They illustrate how various failures in the cluster appear in the cluster log.


Resource Failures

Resource failures are some of the most common types of failures that occur in clusters.

Missing DLL

A support engineer trying to start the Cluster service got the message, “Could not start the Cluster Server service on [server name] Error 127: The specified procedure could not be found.”

The relevant entries in the cluster log were as follows. Note particularly the last two entries, which tell us that the reason the procedure could not be found was that the problem was an error loading Clusres.dll, which manages the resource in question; as a result, we were not able to create a resource to manage the service, and so could not start it.

0ab::11-18:35:52.546 [FM] arbitrate for quorum resource id e558e4a3-320d-11d2-9b64-00805fa63b1b.
0ab::11-18:35:52.546 [FM] FmpQueryResourceInfo:initialize the resource with the registry information
0ab::11-18:35:52.562 FmpAddPossibleNodeToList:: Warning, Node 2 not found
0ab::11-18:35:52.562 FmpRmCreateResource: creating resource e558e4a3-320d-11d2-9b64-00805fa63b1b in shared resource monitor
075::11-18:35:52.593 [RM] Error loading resource dll clusres.dll, error 127.
075::11-18:35:52.593 [RM] Failed creating resource e558e4a3-320d-11d2-9b64-00805fa63b1b, error 127.


Tips

The following strategies can help you read the cluster log.


Reading the Log in Word or Wordpad

Most cluster logs are too big to read in Notepad.

If you read the cluster log in either Microsoft Word or Wordpad, you can take advantage of search and other capabilities to follow thread IDs and resource and group IDs or names throughout the log.


Correlating the Windows 2000 Event Log and the Cluster Log

To home in on the cluster log entries relevant to your problem, correlate the Global Update Manager (GUM) update numbers between the Windows event log and the cluster log.

You can also use time stamps to correlate events between the two logs, but they likely will not align precisely.


Decoding Error Codes

To find the meaning of error codes (such as “status 997,” which means “I/O pending”), do either of the following:

  • Consult Winerror.h, which lists them all.

    Winerror.h ships with all Microsoft development tools, Microsoft® Visual C++® versions 5.0 and 6.0, the Microsoft Platform SDK, and the Microsoft Windows 2000 Software Development Kit (SDK).

  • On the command line, enter the command:
     net helpmsg <error_number>

Whichever you use, you need to study the context to discover the cause of the error. For an example, see “Failure Scenarios” earlier in this chapter.


Identifying GUIDs in the Registry

Although in Windows 2000 resource and group names as well as GUIDs are logged directly to the cluster log, the following procedure can still be valuable.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

To find a GUID in the cluster registry

  1. In a registry editor, either:
    • Click on the HKEY_LOCAL_MACHINE subtree.

    or

    • From the menu, choose HKEY_LOCAL_MACHINE.
  2. Open the HKEY_LOCAL_MACHINE subtree.

    If the CLUSTER key is present, go to step 5.

    If the Cluster service has not started since the last reboot, you need to load the Cluster hives.

  3. To load the Cluster hive:
    • Click on the HKEY_LOCAL_MACHINE subtree.
    • From the registry menu, select Load Hive.
    • Navigate to the cluster directory.
    • Select clusdb (not clusdb.log).

    The Load Hive dialog box appears, prompting you to supply a key name.

  4. Type:

    CLUSTER.

  5. Open the CLUSTER key.

    GUIDs are located under the Groups, NetworkInterfaces, Networks, and Resources subkeys.

  6. Open each of these subkeys to find the GUID of interest.
  7. Open the GUID and note the entry Name.


Logging When Running the Cluster Service with the -debug Option

If diagnostic logging is enabled and the Cluster service fails to start because of a logon error for the service account or another system-related error, the Cluster service might not have a chance to run, and the log file may be empty. If there was a previously existing log file, that file might persist.

An alternative is to run the Cluster service temporarily from a command prompt, with the -debug option set.

When running the Cluster service from a command prompt, you can set the level of diagnostic logging either of two ways:

  • By placing a system environment variable.
  • On the command line by setting the -loglevel option.

    For the command-line syntax, see the following procedure.

Before running the Cluster service with the -debug option, consider the following:

  • This method runs the Cluster service outside the normal environment provided by the Service Control Manager.
  • To use these procedures, you must be logged on with administrative rights.
  • Do not use the -debug option for normal use. The Cluster service does not run as efficiently when this option is set.

To run the Cluster service from a command prompt

  1. Open a new command prompt window.
  2. Change directories to the cluster directory on the local system.

    Usually, the local cluster directory is %SystemRoot%\cluster.

  3. At the command prompt, type:
CLUSSVC -debug [-loglevel #]

where # is an integer from 0 through 2. For the meaning of these integers, see “Starting the Cluster Log” later in this chapter.

In the command prompt window, the Cluster service prints outputs similar to the normal entries in the log file.

To print the Cluster service output to a file

At the command prompt, start the Cluster service with the following command:

CLUSSVC -debug > c:\debug.log\

To stop the Cluster service

Press CTRL+C.


Starting the Cluster Log

To enable cluster logging in Windows 2000, place two new variables in the Windows environment variables list: ClusterLog and ClusterLogLevel. The ClusterLog variable enables cluster logging. The ClusterLogLevel variable specifies which events are written to the cluster log—that is, the level of logging—but only when the Cluster service is run from the command line. For instance, setting the level of logging would come into play if you are running the Cluster service with the -debug option.

For more information about cluster logging while running the Cluster service from the command line, see “Logging When Running the Cluster Service with the -debug Option,” earlier in this chapter.

To enable diagnostic logging

  1. In Control Panel, double-click System.
  2. Click the Advanced tab.
  3. Click the Environment Variables button.
  4. In the System Variables group box, click the New button.
  5. In the Variable Name text box, type:
ClusterLog
  1. In the Variable Value text box, type the path and filename where you want to store the diagnostic log file (the cluster log).

    For example:

C:\Temp\Cluster.log

The system variable name is not case-sensitive.

Note that Cluster service does not create a folder if the path you specify includes a nonexistent folder.

  1. Click OK.

    Remain in the System Variables group box to set the logging level.

To set the logging level

  1. Click the New button.
  2. In the Variable Name text box, type:
  3. ClusterLogLevel
  4. In the Variable Value text box, type an integer from 0 through 3s.
    • means no logging takes place.
    • means only errors are logged.
    • means errors and warnings are logged.
    • means all events, including those not written to the event log, are logged.
  5. Click OK until all dialog boxes are closed, and then shut down and restart the system.

Important

After you restart the computer, you should verify that you entered the variables correctly by typing set at the command prompt.


State Codes

The following state codes are derived from the Windows Clustering header files.


State Codes for Cluster Nodes

The state codes for cluster nodes are as follows:

State Code | State
-1 | ClusterNodeStateUnknown
0 | ClusterNodeUp
1 | ClusterNodeDown
2 | ClusterNodePaused
3 | ClusterNodeJoining


State Codes for Cluster Groups

The state codes for cluster groups are as follows:

State Code | State
-1 | ClusterGroupStateUnknown
0 | ClusterGroupOnline
1 | ClusterGroupOffline
2 | ClusterGroupFailed
3 | ClusterGroupPartialOnline


State Codes for Cluster Resources

The state codes for cluster resources are as follows:

State Code | State
-1 | ClusterResourceStateUnknown
0 | ClusterResourceInherited
1 | ClusterResourceInitializing
2 | ClusterResourceOnline
3 | ClusterResourceOffline
4 | ClusterResourceFailed
128 | ClusterResourcePending
129 | ClusterResourceOnlinePending
130 | ClusterResourceOfflinePending


State Codes for Network Interfaces

The state codes for network interfaces are as follows:

State Code | State
-1 | ClusterNetInterfaceStateUnknown
0 | ClusterNetInterfaceUnavailable
1 | ClusterNetInterfaceFailed
2 | ClusterNetInterfaceUnreachable
3 | ClusterNetInterfaceUp


State Codes for Networks

The state codes for networks are as follows:

State Code | State
-1 | ClusterNetworkStateUnknown
0 | ClusterNetworkUnavailable
1 | ClusterNetworkDown
2 | ClusterNetworkPartitioned
3 | ClusterNetworkUp


Context Numbers

The following tables list the update functions for the three GUM update types:

FailoverManager (GUM update type 0)

Context Value | Update Name
0 | ChangeResourceName
1 | ChangeGroupName
2 | DeleteResource
3 | DeleteGroup
4 | AddDependency
5 | RemoveDependency
6 | ChangeClusterName
7 | ChangeQuorumResource
8 | ResourceState
9 | GroupState
10 | PostClusterWideEvent
11 | GroupNode
12 | PossibleNodeForResType
65537 | FailureCount
65538 | GroupOwner
65539 | CreateGroup
65540 | CreateResource
65541 | Join
65542 | AddPossibleNode
65543 | RemovePossibleNode
65544 | CreateResourceType
65545 | DeleteResourceType
65546 | ChangeGroup

GumUpdateRegistry (GUM update type 1)

Context Value | Update Name
0 | CreateKey
1 | SetSecurity
4097 | DeleteKey
4098 | SetValue
4099 | DeleteValue
4100 | Join

GumUpdateMembership (GUM update type 2)

Context Value | Update Name
0 | CreateNode
1 | PauseNode
2 | ResumeNode
3 | EvictNode
4 | CreateNetwork
5 | SetNetworkName
6 | SetNetworkPriorityOrder
7 | SetNetworkCommonProperties
8 | CreateInterface
9 | SetInterfaceInfo
10 | SetInterfaceCommonProperties
11 | DeleteInterface
12 | JoinBegin
13 | JoinAbort
14 | JoinBegin2
15 | SetNetworkAndInterfaceStates
16 | PerformFixups
65537 | JoinComplete


Copywright

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unpublished work. © 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, and other names of Microsoft products and/or services referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Any RFC excerpts are subject to the following statement:

Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.