This document provides a technical overview of the Active Directory, including important concepts and features, an introduction to the Active Directory architecture, information on migrating from Microsoft® Windows NT operating system version 4.0 to Windows 2000, and a frequently asked questions (FAQ) section. The Active Directory is the foundation for the Windows 2000 Distributed System, which is the platform on which the Microsoft BackOffice® family of integrated products is built.

Introduction

This document provides a technical introduction to the Active Directory, the new directory service provided by the Microsoft® Windows® 2000 Server operating system. This document includes detailed explanations of important Active Directory concepts, architectural elements, and features. The section "Important Concepts" describes the terms you'll need to understand before tackling the Active Directory itself. The next two sections, "Architecture" and "Active Directory Features," go into more detail on what the Active Directory accomplishes, what features it brings to Windows, and how it is implemented. The "Migration" section covers migrating domain models and directory structures from Windows NT 4.0 to Windows 2000. The last section, "Frequently Asked Questions," answers a set of practical questions about the Active Directory and how it works.

A directory is an information source used to store information about interesting objects. A telephone directory stores information about telephone subscribers. In a file system, the directory stores information about files.

In a distributed computing system or a public computer network such as the Internet, there are many interesting objects, such as printers, fax servers, applications, databases, and other users. Users want to find and use these objects. Administrators want to manage how these objects are used.

In this document, the terms directory and directory service refer to the directories found in public and private networks. A directory service differs from a directory in that it is both the directory information source and the services making the information available and usable to the users.

A directory service is one of the most important components of an extended computer system. Users and administrators frequently do not know the exact name of the objects they are interested in. They may know one or more attributes of the objects and can query the directory to get a list of objects that match the attributes: for example, "Find all duplex printers in Building 26." A directory service allows a user to find any object given one of its attributes.

A directory service can:

• Enforce security defined by administrators to keep information safe from intruders.
• Distribute a directory across many computers in a network.
• Replicate a directory to make it available to more users and resistant to failure.
• Partition a directory into multiple stores to allow the storage of a very large numbers of objects.

A directory service is both a management tool and an end-user tool. As the number of objects in a network grows, the directory service becomes essential. The directory service is the hub around which a large distributed system turns.

The Active Directory is the directory service included with Windows 2000 Server. It extends the features of previous Windows-based directory services and adds entirely new features. The Active Directory is secure, distributed, partitioned, and replicated. It is designed to work well in any size installation, from a single server with a few hundred objects to thousands of servers and millions of objects. The Active Directory adds many new features that make it easy to navigate and manage large amounts of information, generating timesavings for both administrators and end users.

Important Concepts

Some concepts and terms that are used to describe the Active Directory are new and some are not. Unfortunately, some of the terms that have been around for a while are used to mean more than one particular thing. Before going on, it is important that you understand how the following concepts and terms are defined in the context of the Active Directory.

The scope of the Active Directory is large. It can include every single object (printer, file, or user), every server, and every domain in a single wide area network. It can also include several wide area networks combined. Some of the following terms apply to more than a single network, so it is important to keep in mind that the Active Directory can scale from a single computer, to a single computer network, to many computer networks combined.

The Active Directory is primarily a namespace, as is any directory service. A telephone directory is a namespace. A namespace is any bounded area in which a given name can be resolved. Name resolution is the process of translating a name into some object or information that the name represents. A telephone directory forms a namespace in which the names of telephone subscribers can be resolved to telephone numbers. The Windows file system forms a namespace in which the name of a file can be resolved to the file itself.

The Active Directory forms a namespace in which the name of an object in the directory can be resolved to the object itself.

An object is a distinct, named set of attributes that represents something concrete, such as a user, a printer, or an application. The attributes hold data describing the subject that is identified by the directory object. Attributes of a user might include the user's given name, surname, and e-mail address.

Figure 1 A user object and its attributes

A container is like an object in that it has attributes and is part of the Active Directory namespace. However, unlike an object, it does not represent something concrete. It is a container for a group of objects and other containers.

Tree is used throughout this document to describe a hierarchy of objects and containers. Endpoints on the tree are usually objects. Nodes in the tree (points at which the tree branches) are containers. A tree shows how objects are connected or the path from one object to another. A simple directory is a container. A computer network or domain is also a container. A contiguous subtree is any unbroken path in the tree, including all members of any container in that path.

Figure 2 A contiguous subtree of a file directory

A name is used to identify every object in the Active Directory. There are two different kinds of names.

Distinguished Name

Every object in the Active Directory has a 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. A typical DN might be

/O=Internet/DC=COM/DC=Microsoft/CN=Users/CN=James Smith

This DN identifies the "James Smith" user object in the Microsoft.com domain.

Figure 3 A graphical representation of a distinguished name

Relative Distinguished Name

The Relative Distinguished Name (RDN) of an object is the part of the name that is an attribute of the object itself. In the preceding example, the RDN of the "James Smith"` user object is CN=James Smith. The RDN of the parent object is CN=Users.

The Active Directory is made up of one or more naming contexts or partitions. A naming context is any contiguous subtree of the directory. Naming contexts are the unit of replication.

In the Active Directory, a single server always holds at least three naming contexts:

• The schema
• The configuration (replication topology and related metadata)
• One or more user naming contexts (subtrees containing the actual objects in the directory)

A domain is a single security boundary of a Windows NT or Windows 2000 computer network. (For more information on domains, see your Windows documentation.) The Active Directory is made up of one or more domains. On a stand-alone workstation, the domain is the computer itself. A domain can span more than one physical location. Every domain has its own security policies and security relationships with other domains. When multiple domains are connected by trust relationships and share a common schema, configuration, and global catalog, you have a domain tree. Multiple domain trees can be connected together into a forest.

A domain tree (a tree) is comprised of several domains that share a common schema and configuration, forming a contiguous namespace. Domains in a tree are also linked together by trust relationships. The Active Directory is a set of one or more trees.

Trees can be viewed two ways. One view is the trust relationships between domains. The other view is the namespace of the domain tree.

Viewing Trust Relationships

You can draw a picture of a domain tree based on the individual domains and how they trust each other.

Windows 2000 establishes trust relationships between domains based on the Kerberos security protocol. Kerberos trust is transitive and hierarchical—if domain A trusts domain B and domain B trusts domain C, domain A trusts domain C as well.

Figure 4 A domain tree viewed in terms of its trust relationships

Viewing the Namespace

You can also draw a picture of a domain tree based on the namespace. You can determine an object's distinguished name by following the path up the domain tree's namespace. This view is useful for grouping objects together into a logical hierarchy. The chief advantage of a contiguous namespace is that a deep search from the root of the namespace will search the entire hierarchy.

Figure 5 Viewing a domain tree as a namespace

A forest is a set of one or more trees that do not form a contiguous namespace. All trees in a forest share a common schema, configuration, and Global Catalog. All trees in a given forest trust each other via transitive hierarchical Kerberos trust relationships. Unlike a tree, a forest does not need a distinct name. A forest exists as a set of cross-reference objects and Kerberos trust relationships known to the member trees. Trees in a forest form a hierarchy for the purposes of Kerberos trust; the tree name at the root of the trust tree can be used to refer to a given forest.

Figure 6 Multiple trees in a forest

A site is a location in a network that contains Active Directory servers. A site is defined as one or more well-connected TCP/IP subnets. "Well-connected" means that network connectivity is highly reliable and fast (for example, LAN speeds of 10 million bits per second or greater). Defining a site as a set of subnets allows administrators to quickly and easily configure the Active Directory access and replication topology to take advantage of the physical network. When a user logs on, the Active Directory client finds Active Directory servers in the same site as the user. Because machines in the same site are close to each other in network terms, communication among machines is reliable, fast, and efficient. Determining the local site at logon time is accomplished easily because the user's workstation already knows what TCP/IP subnet it is on, and subnets translate directly to Active Directory sites.

Architecture

This short section introduces some of the primary architectural components of the Active Directory.

The Active Directory data model is derived from the X.500 data model. The directory holds objects that represent things of various sorts, described by attributes. The universe of objects that can be stored in the directory is defined in the schema. For each object class, the schema defines what attributes an instance of the class must have, what additional attributes it may have, and what object class can be a parent of the current object class.

The Active Directory schema is implemented as a set of object class instances stored in the directory. This is very different from many directories that have a schema, but store it as a text file to be read at startup. Storing the schema in the directory has many advantages. For example, user applications can read the schema to discover what objects and properties are available.

The Active Directory schema can be updated dynamically. That is, an application can extend the schema with new attributes and classes, and can use the extensions immediately. Schema updates are accomplished by creating or modifying the schema objects stored in the directory. Like every object in the Active Directory, schema objects are protected by access control lists (ACLs), so only authorized users may alter the schema.

The directory is part of the Windows 2000 Trusted Computing Base and is a full participant in the Windows 2000 security infrastructure. ACLs protect all objects in the Active Directory. The Windows 2000 access validation routines use the ACL to validate any attempt to access an object or attribute in the Active Directory.

Authorized users perform administration in the Active Directory. A user is authorized by a higher authority to perform a specified set of actions on a specified set of objects and object classes in some identified subtree of the directory. This is called delegated administration. Delegated administration allows very fine-grained control over who can do what and enables delegation of authority without granting elevated privileges.

The Directory System Agent (DSA) is the process that manages the directory's physical storage. Clients use one of the supported interfaces to connect to the DSA and then search for, read, and write directory objects and their attributes. The DSA provides client isolation from the physical storage format of the directory data.

Active Directory Features

This section describes some of the major features and components of the Active Directory.

The Active Directory is tightly integrated with the Domain Name System (DNS). DNS is the distributed namespace used on the Internet to resolve computer and service names to TCP/IP addresses. Most enterprises with intranets use DNS as the name resolution service. The Active Directory uses DNS as the location service.

Windows 2000 domain names are DNS domain names. For example, "Microsoft.com" is a valid DNS domain name and could also be the name of a Windows 2000 domain. Tight DNS integration means that the Active Directory fits naturally into Internet and intranet environments. Clients find directory servers quickly and easily. An enterprise can connect Active Directory servers directly to the Internet to facilitate secure communications and electronic commerce with customers and partners.

Location Service

Active Directory servers publish their addresses such that clients can find them knowing only the domain name. Active Directory servers are published via Service Resource Records (SRV RRs) in DNS. The SRV RR is a DNS record used to map the name of a service to the address of a server offering that service. The name of a SRV RR is in this form:

<service>.<protocol>.<domain>

Active Directory servers offer the LDAP service over the TCP protocol so that published names are in the form:

ldap.tcp.<domain>

Thus, the SRV RR for "Microsoft.com" is "ldap.tcp.microsoft.com." Additional information on the SRV RR indicates the priority and weight for the server, allowing clients to choose the best server for their needs.

When an Active Directory server is installed, it publishes itself via Dynamic DNS (explained next). Since TCP/IP addresses are subject to change over time, servers periodically check their registrations to make sure they are correct, updating them if necessary.

Dynamic DNS

Dynamic DNS is a recent addition to the DNS standard¹ . Dynamic DNS defines a protocol for dynamically updating a DNS server with new or changed values. Prior to Dynamic DNS, administrators needed to manually configure the records stored by DNS servers.

An object has exactly one name, the distinguished name (DN). The DN uniquely identifies the object and contains sufficient information for a client to retrieve the object from the directory. The DN of an object may be quite long and difficult to remember. Moreover, the DN of an object may change. Since the DN of an object is composed of the RDN of the object and its ancestors, a rename of the object itself or any ancestor will change the DN.

Since DNs are complex to remember and subject to change, it is useful to have other means for retrieving objects. The Active Directory supports querying by attributes, so an object can be found even if the exact DN is unknown or has changed. To simplify the process of finding objects by query, the Active Directory schema defines two useful properties² :

• Object globally unique identifier (GUID)—A 128-bit number, guaranteed to be unique. Objects have a GUID assigned when they are created. The GUID is never changed, even if the object is moved or renamed. Applications can store the GUID of an object and be assured of retrieving that object no matter what the current DN is.
• User Principal Name—Security Principals (users and groups) each have a "friendly" name, the User Principal Name (UPN), which is shorter than the DN and easier to remember. The User Principal Name is composed of a "shorthand" name for the user and the DNS name of the domain tree where the user object resides. For example, user James Smith in the microsoft.com tree might have a UPN of "JamesS@Microsoft.com."

Uniqueness of Names

Distinguished names are guaranteed to be unique. The Active Directory does not permit two objects with the same RDN under the same parent. DNs are composed of RDNs and are therefore unique. GUIDs are unique by definition; an algorithm that ensures uniqueness generates GUIDs. Uniqueness is not enforced for any other attributes.

Access to the Active Directory is via wire protocols. Wire protocols define the formats of messages and interactions of client and server. Various application programming interfaces (APIs) give developers access to these protocols.

Protocol Support

Supported protocols include:

• LDAP—The Active Directory core protocol is the Lightweight Directory Access Protocol (LDAP). LDAP version 2 and version 3³ are supported.
• MAPI-RPC—The Active Directory supports the remote procedure call (RPC) interfaces supporting the MAPI interfaces.
• X.500—The Active Directory information model is derived from the X.500 information model. X.500 defines several wire protocols that Active Directory does not implement. These protocols are:

  DAP – Directory Access Protocol

  DSP – Directory System Protocol

  DISP – Directory Information Shadowing Protocol

  DOP – Directory Operational Binding Management Protocol

  The Active Directory does not implement these protocols for the following reasons:

  • There is very little interest in these protocols and there are few implementations.
  • These protocols are dependent on OSI networking. OSI is an alternative to TCP/IP, which is not widely implemented. Transporting OSI across a TCP/IP network is less efficient than using TCP/IP directly.
  • LDAP provides the most important functions offered by DAP and DSP and is designed to work over TCP/IP without the overhead of "enveloping" OSI in TCP/IP.
  • There is sufficient ambiguity in the 1993 and 1997 DISP and DOP specifications that conforming implementations are not guaranteed to interoperate, thus dramatically reducing the value of these protocols.

Application Programming Interfaces

Supported APIs include:

• ADSI—Active Directory Service Interfaces (ADSI) provide a simple, powerful object-oriented interface to the Active Directory⁴ . Developers can use many different programming languages, including Java, Visual Basic® programming system, C, C++, and others. ADSI is fully scriptable for ease of use by system administrators. ADSI hides the details of LDAP communications from users.
• LDAP API—The LDAP C API, defined in RFC 1823, is a lower-level interface available to C programmers.
• MAPI—The Active Directory supports MAPI for backward compatibility. New applications should use ADSI or the LDAP C API.

The Active Directory allows other directories to be exposed via Virtual Containers. A Virtual Container allows any LDAP compliant directory to be accessed transparently via the Active Directory. The Virtual Container is implemented via "knowledge information" stored in the Active Directory. The knowledge information describes where in the Active Directory the foreign directory should appear, and contains the DNS name of a server holding a copy of the foreign directory and the distinguished name (DN) at which to begin search operations in the foreign DS.

The Active Directory can consist of many partitions or naming contexts. The distinguished name (DN) of an object includes enough information to locate a replica of the partition that holds the object. Many times, however, the user or application does not know the DN of the target object or which partition might contain the object. The Global Catalog (GC) enables users and applications to find objects in an Active Directory domain tree if the user or application knows one or more attributes of the target object.

The Global Catalog contains a partial replica of every user-naming context in the directory. It contains the schema and configuration naming contexts as well. This means the GC holds a replica of every object in the Active Directory, but only holds a small number of their attributes. The attributes in the GC are those most frequently used in search operations (such as a user's first and last names, login names, and so forth) and those required to locate a full replica of the object. The GC allows users to quickly find objects of interest without knowing what domain holds them and without requiring a contiguous extended namespace in the enterprise.

The Active Directory replication system automatically builds the Global Catalog and generates the replication topology. The properties replicated into the Global Catalog include a base set defined by Microsoft. Administrators can specify additional properties to meet the needs of their installation.

This is only an overview of security in the Active Directory. For more information about the Windows 2000 security model, refer to the "Secure Networking Using Microsoft Windows 2000 Distributed Security" white paper.

Object Protection

All objects in the Active Directory are protected by Access Control Lists (ACLs). 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 (ACEs) stored with the object it protects. In Windows 2000, an ACL is stored as a binary value called a Security Descriptor. Each ACE contains a Security Identifier (SID), which identifies the principal (user or group) to whom the ACE applies and information on what type of access the ACE grants or denies.

ACLs on directory objects contain ACEs that apply to the object as a whole and ACEs that apply to the individual attributes of the object. This 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 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.

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.

ACEs 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 ACEs in the container's ACL.. For example, to allow user "James Smith" to be an administrator of the "Corporate Accounting" organizational unit, you would add ACEs 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 cannot create any other object classes and he cannot affect users in any other containers (unless, of course, ACEs grant him that access on the other containers).

Inheritance

Inheritance lets a given ACE propagate 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.

The Active Directory provides multi-master replication. Multi-master replication means that all replicas of a given partition are writeable. This allows updates to be applied to any replica of a given partition. The Active Directory replication system propagates the changes from a given replica to all other replicas. Replication is automatic and transparent.

Update Propagation

Some directory services use timestamps to detect and propagate changes. In these systems, it is very important to keep the clocks on all directory servers synchronized. Time synchronization in a network is very difficult. Even with very good network time synchronization, it is possible for the time at a given directory server to be incorrectly set. This can lead to lost updates.

Windows 2000 provides distributed time synchronization, but the Active Directory replication system does not depend on time for update propagation. Instead, the Active Directory replication system uses Update Sequence Numbers (USNs). A USN is a 64-bit number maintained by each Active Directory server. When the server writes any property to the Active Directory, the USN is advanced and stored with the property written. This operation is performed atomically—that is, the incrementing and storage of the USN and the write of the property succeed or fail as a single unit of work.

Each Active Directory server also maintains a table of USNs received from replication partners. The highest USN received from each partner is stored in this table. When a given partner notifies the Directory Server that replication is required, that server requests all changes with USNs greater than the last value received. This is a very simple approach and does not depend on the accuracy of timestamps.

Because the USN stored in the table is updated atomically for each update received, recovery after a failure is also simple. To restart replication, a server simply asks its partners for all changes with USNs greater than the last valid entry in the table. Since the table is updated atomically as the changes are applied, an interrupted replication cycle will always pick up exactly where it left off, with no loss or duplication of updates.

Collision Detection – Version Numbers

In a multi-master replication system like the Active Directory, it is possible for the same property to be updated at two or more different replicas. When a property changes in a second (or third, or fourth, and so on.) replica before a change from the first replica has been fully propagated, a replication collision occurs. Collisions are detected through the use of property version numbers. Unlike USNs, which are server-specific values, a property version number is specific to the property on an Active Directory object. When a property is first written to an Active Directory object, the version number is initialized.

Originating writes advance the version number. An originating write is a write to a property at the system initiating the change. Property writes caused by replication are not originating writes and do not advance the version number. For example, when a user updates his or her password, an originating write occurs and the password version number is advanced. Replication writes of the changed password at other servers do not advance the version number.

A collision is detected when a change is received via replication in which the property version number received is equal to the locally stored property version number, and the received and stored values are different. When this occurs, the receiving system will apply the update that has the later timestamp. This is the only situation where time is used in replication.

When the received version number is lower than the locally stored version number, the update is presumed stale and discarded. When the received version number is higher than the locally stored version number, the update is accepted.

Propagation Dampening

The Active Directory replication system allows loops in the replication topology. This allows the administrator to configure a replication topology with multiple paths among the servers for performance and availability. The Active Directory replication system performs propagation dampening to prevent changes from propagating endlessly and to eliminate redundant transmission of changes to replicas that are already up-to-date.

The Active Directory replication system employs up-to-date vectors to dampen propagation. The up-to-date vector is a list of server-USN pairs held by each server. The up-to-date vector at each server indicates the highest USN of originating writes received from the server in the server–USN pair. An up-to-date vector for a server in a given site lists all the other servers in that site.

When a replication cycle begins, the requesting server sends its up-to-date vector to the sending server. The sending server uses the up-to-date vector to filter changes sent to the requesting server. If the high USN for a given originating writer is greater than or equal to the originating write USN for a particular update, the sending server does not need to send the change; the requesting server is already up-to-date with respect to the originating writer.

A Windows 2000 domain tree is a hierarchy of Windows 2000 domains, each consisting of a partition of the Active Directory. The shape of the tree and the relationship of the tree members to each other are determined by the DNS names of the domains. The domains in a tree must form a contiguous namespace, such that a.myco.com is a child of myco.com, and b.myco.com is a child of a.myco.com, and so forth.

Transitive Bi-directional Trust

When a domain is joined to a Windows 2000 domain tree, a transitive bi-directional trust relationship is automatically established between the joined-from domain and its parent in the tree. Because the trust is transitive and bi-directional, no additional trust relationships are required among tree members. The trust hierarchy is stored as part of the directory metadata in the Configuration container.

These required objects are created in the directory when a domain is joined to the tree.

Namespace

The domains in a Windows 2000 domain tree must form a contiguous namespace. By default, the immediate children of each domain are contiguous and already part of their namespace. This means that the distinguished name of every object in the child domains has the name of the parent domain as a prefix. Disjointed trees can be joined into a forest.

Figure 7 The parent domain and child domain form a contiguous namespace because the name of the child domain is an immediate subordinate of the name of the parent domain

For example, a parent domain, O=Internet/DC=COM/DC=Microsoft, and a child domain, O=Internet/DC=COM/DC=Microsoft/DC=PBS, form a contiguous naming tree, because the root object in the parent domain, O=Internet/DC=COM/DC=Microsoft, is the immediate parent of the root object in the child, O=Internet/DC=COM/DC=Microsoft/DC=PBS. Because the parent and child form a naming tree, a deep search initiated in the parent will automatically search the child as well.

When to Form a Domain Tree

The Windows 2000 domain tree is the enterprise-wide Active Directory. All Windows 2000 domains in a given enterprise should belong to the enterprise domain tree. Enterprises that need to support disjointed DNS names for their domains will need to form a forest.

How to Form a Domain Tree or Forest

Windows 2000 domains are joined to a domain tree during the installation process. During the installation of a new Windows 2000 server (or upgrade from an earlier version of Windows NT), the administrator is given the following options:

• Creating the first tree in a new forest
• Creating a new tree in an existing forest
• Creating a new replica of an existing domain
• Installing a child domain

To join a domain tree, select Install a Child Domain and identify the parent domain for the new child domain. A future update to Windows will add the capability of joining two (or more) existing trees together into a single, larger tree.

Domains within an existing tree can be freely moved to change the overall tree shape. Planning a good tree is very important, but what is good is highly subjective and based on the specific needs of your organization. The ability to reshape the tree as needed reduces the importance of knowing the right design in advance.

A site is an area of the network where connectivity among machines is assumed to be very good. Windows 2000 defines a site as one or more IP subnets. This is based on the assumption that computers with the same subnet address are connected to the same network segment, typically a LAN or other high-bandwidth⁶ environment such as Frame Relay, ATM, or others.

Windows 2000 uses site information to locate an Active Directory server close to the user. When a user workstation connects to the network, it receives a TCP/IP address from a DHCP server, which also identifies the subnet to which the workstation is attached. Workstations that have statically configured IP addresses also have statically configured subnet information. In either case, the Windows 2000 domain controller (DC) locator will attempt to locate an Active Directory server located on the same subnet as the user, based on the subnet information known to the workstation.

Sites and Replication

The Windows 2000 replication system automatically generates a ring topology for replication among Active Directory servers in a given site. Within a site, directory replication is performed via remote procedure call (RPC). Between sites, replication can be selectively configured to use RPC or messaging. Windows 2000 provides simple SMTP messaging as a standard feature. If Microsoft Exchange is available, inter-site replication can be carried via Exchange, using any of the many mail transports supported by Exchange (this includes SMTP, X.400, and others).

Planning Sites

A minimal site consists of a single IP subnet. Windows 2000 assumes that all machines located in the same site share a common high-bandwidth network. Given this, a good site design is one in which all subnets assigned to a given site share such a network. Areas of a network that are separated by a wide area network, multiple routers, or other slower links should be in separate sites.

The Active Directory schema defines the set of all object classes and attributes that can be stored in the directory. For each object class, the schema defines where it can be created in a directory tree by specifying the legal parents of the class. The content of a class is defined by the list of attributes that the class must or may contain.

When to Extend the Schema

Users and applications extend the schema when there are no existing object classes that meet the need at hand. Extending the schema is a simple, straightforward process.

Adding Attributes

New attributes can be added to the schema at any time. An attribute definition consists of a name, a unique Object Identifier (OID), a syntax that defines what kind of data the attribute can hold, and optional range limits. For strings, the value limits set the minimum and maximum length of the string. For integers, the value limits set the minimum and maximum value of the integer.

Query performance in the Active Directory is directly related to the availability of an index that can be used to optimize a given query. When no index is available to satisfy a given query, the LDAP server must read the entire partition to satisfy the query. When you define an attribute, you have the option of creating an index for that attribute. It is also possible to create an index over a given attribute by setting the searchFlags attribute in the attributeSchema object to 1. You should define an attribute as indexed when:

• The attribute will frequently be used in queries. Adding an index consumes storage and affects insert performance (because the index must be maintained when an item is inserted), so you should not add an index if it will not be used often.
• The values in the attribute must be highly unique. Boolean attributes should never be indexed, because a Boolean attribute will only have two possible values: True or False. Employee numbers and surnames are highly unique and therefore make good indexes.
• The attribute will occur on objects of interest. Indexing an attribute lets you quickly find objects that have that attribute instantiated. Before adding an index, make sure the attribute you are indexing is a must-have or may-have on the objects you wish to retrieve.

Adding New Objects

New object classes can be added to the schema at any time. An object definition consists of a name, an Object Identifier (OID), a list of may-contain and must-contain attributes, the list of classes that can be parents of the object, the class the object is derived from, and a list of any auxiliary classes that apply to the object.

How to Extend the Schema

Because the schema controls what can be stored in the directory and describes what is already stored, write access to the schema is limited to administrators by default. A schema management snap-in for the Microsoft Management Console (MMC) is provided with Windows 2000. To extend the schema, a suitably privileged user can create new attributes and classes. Attributes can then be added to new or existing classes. For each new attribute or class, an OID is required.

Object Identifiers (OIDs)

An Object Identifier is a number unambiguously identifying an object class or attribute in a directory service⁷ . OIDs are issued by issuing authorities and form a hierarchy. An OID is represented as a dotted decimal string (for example, "1.2.3.4"). Enterprises (and individuals) can obtain a root OID from an issuing authority and use it to allocate additional OIDs. For example, Microsoft has been issued the root OID of 1.2.840.113556. Microsoft manages further branches from this root internally. One of these branches is used to allocate OIDs for Active Directory classes, another for Active Directory attributes, and so on.

Many countries in the world have an identified National Registration Authority (NRA) responsible for issuing OIDs to enterprises. In the United States, the National Registration Authority is the American National Standards Institute (ANSI). The National Registration Authority issues root OIDs. An enterprise can register a name for the OID as well. There is a fee associated with both root OIDs and registered names. Contact the National Registration Authority for your country for details⁸ http://www.iso.ch/ ..

Publishing is the act of creating objects in the directory that either directly contain the information you want to make available or provide a reference to the information you want to make available. For example, a user object contains useful information about users, such as their telephone numbers and e-mail addresses, while a volume object contains a reference to a shared file system volume.

When to Publish

Information should be published in the Active Directory when it is useful or interesting to a large part of the user community and when it needs to be highly accessible.

Information published in the Active Directory has two major characteristics:

• It is relatively static and changes infrequently. Telephone numbers and e-mail addresses are examples of relatively static information suitable for publishing; the user's currently selected e-mail message is an example of highly volatile information.
• It is structured and can be represented as a set of discrete attributes. A user's business address is an example of structured information suitable for publishing; an audio clip of the user's voice is an example of unstructured information better suited to the file system.

Operational information used by applications is an excellent candidate for publishing in the Active Directory. This includes global configuration information that applies to all instances of a given application. For example, a relational database product could store the default configuration for database servers as an object in the Active Directory. New installations of that product would collect the default configuration from the object, simplifying the installation process and enhancing consistency of installations in an enterprise.

Applications can also publish their connection points in the directory. Connection points are used for a client/server rendezvous. The Active Directory defines an architecture for integrated service administration using Service Administration Point objects and provides standard connection points for RPC, Winsock, and COM applications. Applications that do not use the RPC or Winsock interfaces for publishing their connection points can explicitly publish Service Connection Point objects in the directory.

Application data can also be published in the directory using application-specific objects. Application-specific data should meet the criteria discussed above. That is, data should be globally interesting, relatively non-volatile, and structured.

How to Publish

The means of publishing information varies according to the application or service:

• RPC—RPC applications use the RpcNs* family of APIs to publish their connection points in the directory and to query for the connection points of services that have published theirs.
• Windows Sockets—Windows Sockets applications use the Registration and Resolution family of APIs available in Winsock 2.0 to publish their connection points and query for the connection points of services that have published theirs.
• DCOM—DCOM services publish their connection points via the DCOM Class Store, which resides in the Active Directory.

Windows 2000 introduces new group features

• Groups can be treated as distribution lists if the next major release of Exchange is installed.
• Groups can contain non-security members (this is important when the group is used for both security and distribution list purposes).
• Security usage of groups can be disabled (this is important when the group is solely used as a distribution list).
• Groups can be nested.
• A new group type, the Universal group, is introduced.

A Universal group is the simplest form of group. Universal groups can appear in ACLs anywhere in the forest, and can contain other Universal groups, Global groups, and users from anywhere in the forest. Small installations can use Universal groups exclusively and not concern themselves with Global and Local groups.

A Global group can appear in ACLs anywhere in the forest. A Global group can contain users and other Global groups from its own domain.

A Domain Local group can be used in ACLs only it its own domain. A Domain Local group can contain users and Global groups from any domain in the forest, Universal groups, and other Domain Local groups in its own domain.

The three group types provide a rich and flexible access control environment while reducing replication traffic to the Global Catalog caused by group membership changes. A Universal group appears in the GC, but will contain primarily global groups from domains in the forest. Once the Global groups are established, the membership in the Universal group will change infrequently. Global groups appear in the GC, but not their members. Membership changes in Global groups are not replicated outside of the domain where they are defined. Domain Local groups are valid only in the domain where they are defined and do not appear in the GC at all.

Migration

This section presents an overview of migration from earlier versions of Windows NT. Migration is discussed in detail in a number of separate documents available from http://www.microsoft.com/ntserver .

You can upgrade Windows NT 3.51 and 4.0 systems directly to Windows 2000. Windows NT 3.1 and 3.5 systems must be upgraded to Windows NT 3.51 or 4.0 before they can be upgraded to Windows 2000. A new installation of Windows 2000 can be performed on any system listed in the Windows 2000 Hardware Compatibility List.

Domain Controllers keep a copy of the directory. In Windows NT 3.51 and 4.0, there are two kinds of Domain Controllers–Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). Primary Domain Controllers hold a read/write copy while Backup Domain Controllers hold a read-only copy.

In Windows 2000, all Domain Controllers for a given domain hold a writeable copy of the directory. There is no distinction between primary and backup; all domain controllers are equal.

To migrate a Windows NT 3.51 or 4.0 domain to Windows 2000, you must first upgrade the Primary Domain Controller for the domain to Windows 2000. This automatically loads the users and groups from the domain directory into the Active Directory. As part of the upgrade process, you specify whether this domain will be:

• The root of a new tree in a new forest
• The root of a new tree of domains in an existing forest
• A child of an existing tree of domains

At this point, the domain is a mixed domain. You can use the Windows 2000 administration tools to manage the domain, and you can create a hierarchical structure of Organizational Unit folders in the directory to delegate administrative authority. The Backup Domain Controllers, member servers, and clients are unchanged and unaware that the PDC is now an Active Directory server.

To migrate the Backup Domain Controllers, upgrade each one to Windows 2000. The upgrade process recognizes the Backup Domain Controller, automatically installs it as an Active Directory replica, and inserts it into the replication topology. When all domain controllers have been upgraded to Windows 2000, the domain is no longer a mixed domain, and nested groups are supported.

To migrate member servers, upgrade them to Windows 2000. Local users and local groups are stored in the registry of the member server and are not moved into the Active Directory. Upgrading a member server to Windows 2000 allows it to participate in Kerberos security, adds support for Active Directory-aware applications, and adds the Microsoft Management Console and Active Directory-aware shell and common dialogs.

To migrate Windows NT Workstation-based clients, upgrade them to Windows 2000 Professional. You can migrate Windows 95-based clients by installing a service pack containing the additional software components needed to make them Active Directory-aware. Upgrading a client allows it to participate in Kerberos security, adds support for Active Directory-aware applications, and adds the Active Directory-aware shell and common dialogs.

When a downlevel PDC (3.51 or 4.0) is upgraded to Windows 2000, the users are migrated to the Active Directory and placed in a container called "Users" in the domain root.

When a downlevel PDC (3.51 or 4.0) is upgraded to Windows 2000, the machine accounts are migrated to the Active Directory and placed in a container called "Computers" in the domain root.

When a downlevel PDC (3.51 or 4.0) is upgraded to Windows 2000, the Groups are migrated to the Active Directory and placed in a container called "Users" in the domain root. Built-in groups are in a special container called "Built-in."

Frequently Asked Questions

A workstation discovers its site by presenting its subnet to the first Active Directory server contacted. The workstation determines the subnet by applying its subnet mask to its IP address. The subnet mask and IPO address can be assigned by DHCP or statically configured. The first server contacted uses the presented subnet to locate the Site object for the site where the workstation is located. If the current server is not in that site, the server notifies the workstation of a better server to use.

A workstation finds a directory server by querying DNS. Directory servers for a given domain publish SRV Resource Records in DNS with names in the form

LDAP.TCP.<domain name>

Thus, a workstation logging in to Microsoft.com will query DNS for SRV records for LDAP.TCP.Microsoft.com. A server will be selected from the list and contacted. The contacted server will use the subnet information presented by the workstation to determine the best server as described in the previous answer.

A user can use a variety of names in a variety of formats to log on to a Windows 2000 Professional. These include the name formats supported by the Win32® application programming interface DsCrackNames, which are used to convert these name forms as necessary.

• Domain NETBIOS name and SAM-Account-Name—This is the Windows NT 4.0-style logon name. The domain NETBIOS name is the name the domain had prior to migration. The SAM-Account-Name is the account name the user had prior to migration.
• User Principal Name—This is in the format <friendly name>@<dotted-dns-domain-name>. If the name is not unique, the logon attempt will fail with an Unknown User error.

Access control lists are not affected directly by migration. If all Windows NT 3.51 and Windows NT 4.0 domains are migrated in place, nothing changes from an ACL perspective.

If you move servers from a resource domain into an organizational unit in migrated account domains and delete the resource domain, you will need to edit any ACLs that hold ACEs referring to the now deleted domain. This is not a function of the Windows 2000 migration; if you delete a domain in any version of Windows NT, security identifiers issued by that domain become invalid.

To reduce the effort involved in reapplying ACL resources, if you have a resource domain in Windows NT 3.51 or 4.0 and you plan to replace it with an OU and delete it in Windows 2000, you should not put groups from the resource domain into ACLs. Note that this does not affect local groups from member servers; it affects only those from Domain Controllers.

As part of Windows 2000, Microsoft will provide tools to assist in reapplying ACLs to resources.

When you create a group in a domain, it has a Security Identifier (SID) issued by that domain. When you put that SID into an ACL, it grants access to users who have that SID in their token. Users get the SID in their token by logging on to the domain that issued the SID. This can be a network logon and happen transparently.

When you edit an ACL, the LookupAccountName API is called with the SID. If you delete the domain that issued the SID, you will see "Unknown User" in the list of users and groups for the ACL. This happens in Windows NT 3.51 and Windows NT 4.0 if you delete a domain or remove a trust link.

There are two parts to this answer:

• Part 1: Local Groups on Member Servers—Local groups on a member server stay local; they exist only in the SAM on the member server and are not migrated to the Active Directory. A typical use of a local group on a member server is to hold global groups from account domains. The server administrator puts the local group in the ACLs on the server's resources and adds the global groups to the local group. This does not change in Windows 2000. The only difference is that the global groups become normal groups and are published in the Active Directory.
• Part 2: Local Groups on PDCs and BDCs—Backup Domain Controllers have a read-only SAM. When you create a local group on a BDC, the create operation is remoted to the PDC and replicated back to all BDCs. Semantically, these local groups are identical to the local groups on a member server, but they exist on the PDC and on all BDCs. When you upgrade to Windows 2000, the upgrade process creates a Domain Local group object in the Active Directory for each of these.

A search of the global catalog is initiated in one of several ways:

• By a subtree or one-level LDAP search rooted at the null DN (the root of the namespace)—this generates a reference to the Global Catalog.
• By a direct reference to the GC port at a GC replica (although client programs are unlikely to take this approach).
• By an explicit reference to the GC ADSI provider (GC://).

No. There are significant advantages to using Microsoft DNS, but any RFC-compliant DNS server will work. Dynamic DNS is recommended because, with a Dynamic DNS server, Active Directory servers can automatically register the necessary records in DNS. Static DNS servers work equally well, but the DNS registration for each Active Directory server must be accomplished manually.

The DNS server included with Windows 2000 is an RFC and BIND compliant implementation of Dynamic DNS. It is a native implementation for Windows 2000, not a port of the public domain BIND implementation. The Microsoft DNS server stores the DNS zones for which it is authoritative in the Active Directory. DNS data is replicated among Microsoft DNS servers by Active Directory replication, not Zone Transfer. The Microsoft DNS server supports standard DNS Zone Transfer for interoperability with other DNS servers.

The DHCP server is largely unchanged for Windows 2000. The DHCP client is DNS-aware and uses the services of Dynamic DNS to register addresses issued by DHCP directly in DNS. The DHCP client will continue to register with WINS if DHCP identifies a WINS server.

WINS is unchanged for Windows 2000. Windows 2000 clients (and Windows 95 clients with the Active Directory upgrade installed) no longer need to use the NETBIOS namespace. WINS is still required for downlevel clients to find servers and vice versa. When there are no more downlevel clients in the enterprise, the WINS servers can be turned off.

For More Information

For the latest information on Windows 2000 Server, check out Microsoft TechNet or our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on MSN, The Microsoft Network (GO WORD: MSNTS).

© 1998 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, BackOffice, the BackOffice logo, MSN, Visual Basic, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

1298

1 RFC 2136.

2 The schema defines many useful properties, these are particularly useful in searching.

3 LDAP v3 (RFC 2251) is a Proposed Standard as of this writing (8/12/98).

4 ADSI provides common access to multiple directories, including all LDAP directories, Windows NT 4.0, NetWare 3.x, and NetWare 4.x.

5 These "ACEs" are for illustration only, the actual syntax of an ACE will be different than that given in the example.

6 "High bandwidth" means Ethernet speed (10 million bits per second) or better in this context.

7 OIDs are used in many other applications as well, but OIDs are best known for their use in directory service applications.