Microsoft Corporation
September 1997
This article provides a technical overview of the Active Directory, including important concepts and features, an introduction to the Active Directory architecture, information on migrating from the Microsoft® Windows NT® version 4.0 operating system to Windows NT version 5.0, and a frequently asked questions (FAQ) section. The Active Directory is the foundation for the Windows NT distributed system, the platform on which the Microsoft BackOffice® family of integrated products is built.
This document provides a technical introduction to the Active Directory, the new directory service provided by the Microsoft Windows NT Server operating system version 5.0. 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 NT, and how it is implemented. The "Migration" section covers migrating domain models and directory structures from Windows NT 4.0 to Windows NT 5.0. 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:
A directory service is both a management tool and a 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 NT Server version 5.0. It extends the features of previous Microsoft 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 a time savings for both administrators and users.
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 (WAN). It can also include several WANs 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 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 NT 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
Any object in the directory can also be a container. A container is an object that can contain other objects. In the same way a file folder is a container for documents, a directory container is a container for directory objects.
Tree is used throughout this document to describe a hierarchy of objects. In a tree, the endpoints are called leaf objects. A leaf object does not contain other 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.
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=Some One
This DN identifies the "Some One" user object in the microsoft.com domain.
Figure 3. A graphical representation of a 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 "Some One" user object is CN=Some One. 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:
A domain is a single security boundary of a Windows NT computer network. (For more information on Windows NT domains, see your Windows NT 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 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.
You can draw a picture of a domain tree based on the individual domains and how they trust each other.
Windows NT 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.
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.
The Active Directory does not limit forming a contiguous namespace from discontiguous domains and directories. However, it may be advantageous to form contiguous trees that match the namespace such that name structure follows the same logic that the namespace presents.
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 Transfer Control Protocol/Internet Protocol (TCP/IP) subnets. Defining a site as a set of subnets lets administrators 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. This 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.
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 NT trusted computing base and is a full participant in the Windows NT security infrastructure. ACLs protect all objects in the Active Directory. Any attempt to access an object or attribute in the Active Directory is validated against the ACL by the Windows NT access validation routines.
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 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.
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 NT 5.0 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 NT 5.0 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.
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 Lightweight Directory Access Protocol (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. 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 is a recent addition to the DNS standard (RFC 2136). Dynamic DNS defines a protocol for updating a DNS server with new or changed values dynamically. Prior to Dynamic DNS, administrators manually configured 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 for all objects. The schema defines many useful properties, but these are particularly useful in searching:
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.
Supported protocols include:
Directory Access Protocol (DAP)
Directory System Protocol (DSP)
Directory Information Shadowing Protocol (DISP)
Directory Operational Binding Management Protocol (DOP)
The Active Directory does not implement these protocols for several reasons:
If there is sufficient demand, Microsoft will implement subsets of these X.500 protocols in the future.
Supported APIs include:
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 DN at which to begin search operations in the foreign directory service.
The Active Directory can consist of many partitions or naming contexts. The 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) lets users and applications 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 with only 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, logon 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 GC is built automatically by the Active Directory replication system. The replication topology for the GC is generated automatically. The properties replicated into the GC 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 NT 5.0 security model, refer to "Secure Networking Using Microsoft Windows NT 5.0 Distributed Security Services," (MSDN™ Library, PDC 97 Conference Papers).
All objects in the Active Directory 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 (ACEs) stored with the object it protects. In Windows NT, 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 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 "Some One" to be an administrator of the "Corporate Accounting" organizational unit, you would add ACEs to the ACL on "Corporate Accounting" as follows (These "ACEs" are for illustration only, the actual syntax of an ACE will be different than that given in the example.):
"Some One"; Grant; Create, Modify, Delete; Object-Class User
"Some One"; Grant; Create, Modify, Delete; Object-Class Group
"Some One"; Grant; Write; Object-Class User; Attribute Password
Now Some One 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 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 multimaster replication. Multimaster 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.
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 NT 5.0 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.
In a multimaster 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.
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 NT 5.0 domain tree is a hierarchy of Windows NT 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 trust relationships between domains (or partitions). There may also be a contiguous namespace that is different in shape from the trust relationships between domains.
When a domain is joined to a Windows NT 5.0 domain tree, a Kerberos trust relationship is automatically established between the joined-from domain and its parent in the tree. Kerberos trust is transitive, so no additional trust relationships are required among tree members. The trust hierarchy is stored in cross-reference objects in the directory. Cross-reference objects are stored as part of the directory metadata in the partitions container.
The partitions container is a child of the configuration container that contains cross-reference objects. There is a cross-reference object for each naming context in the enterprise. (Recall that each domain is a naming context.)
There may be cross-reference objects for virtual containers and for referrals to outside of the enterprise. cross-reference objects for naming contexts in the enterprise are identified with a flag. cross-reference objects have an NC-Name attribute that identifies the X.500-style name of the associated domain and a DNS-Root attribute that identifies the DNS name of the associated domain. Trusted domain objects in each domain contain more information about the trust relationship including passwords, direction, and type.
These required objects are created in the directory when a domain is joined to the tree.
The domains in a Windows NT 5.0 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 (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.
The Windows NT 5.0 domain tree is the enterprise-wide Active Directory. All Windows NT 5.0 domains in a given enterprise should belong to the enterprise domain tree.
Windows NT 5.0 domains are joined to a domain tree during the installation process. During the installation of a new Windows NT 5.0 server (or upgrade from an earlier version of Windows NT), the administrator is given the option of installing a child domain. To join a domain tree, select Install a Child Domain and identify the parent domain for the new domain. A future update to Windows NT 5.0 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 NT 5.0 defines a site as one or more Internet Protocol (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 ("high bandwidth" means ETHERNET speed (10 million bits per second) or better in this context) such as Frame Relay, ATM, or others.
Windows NT 5.0 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 Dynamic Host Configuration Protocol (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 NT 5.0 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.
The Windows NT 5.0 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 RPC. Between sites, replication can be selectively configured to use RPC or messaging. Windows NT 5.0 provides simple Simple Mail Transfer Protocol (SMTP) messaging as a standard feature. If Microsoft Exchange Server is available, inter-site replication can be carried via Exchange, using any of the many mail transports supported by Exchange that include SMTP, X.400, and others.
A minimal site consists of a single IP subnet. Windows NT 5.0 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.
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.
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:
New object classes can be added to the schema at any time. An object definition consists of a name, an 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.
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 NT 5.0. 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.
An Object Identifier (OID) is a number unambiguously identifying an object class or attribute in a directory service (OIDs are used in many other applications as well, but OIDs are best known for their use in directory service applications). 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 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 (The International Standards Organization (ISO) maintains a list of member organizations on their Web site at 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.
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:
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, Windows Sockets (Winsock), and Component Object Model (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, it should be globally interesting, relatively nonvolatile, and structured.
The means of publishing information varies according to the application or service:
This section presents an overview of migration from earlier versions of Windows NT. Migration is discussed in detail in a number of separate documents, including "Migrating from Windows NT 3.51 and 4.0 to Windows NT 5.0" (MSDN Library, PDC 97 Conference Papers).
You can upgrade Windows NT 3.51 and 4.0 systems directly to Windows NT 5.0. 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 NT 5.0. A new installation of Windows NT 5.0 can be performed on any system listed in the Windows NT 5.0 Hardware Compatibility List.
Domain controllers (DCs) keep a copy of the directory. In Windows NT 3.51 and 4.0, there are two kinds of DCs—Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). PDCs hold a read/write copy while BDCs hold a read-only copy.
In Windows NT 5.0, all DCs for a given domain hold a writeable copy of the directory. There is no distinction between primary and backup; all DCs are equal.
To migrate a Windows NT 3.51 or 4.0 domain to Windows NT 5.0, you must first upgrade the PDCfor the domain to Windows NT 5.0. 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:
At this point, the domain is a mixed domain. You can use the Windows NT 5.0 administration tools to manage the domain, and you can create a hierarchical structure of Organizational Unit folders in the directory to delegate administrative authority. But all changes must occur at the PDC. This is because the remaining BDCs have not been upgraded to Windows NT 5.0 and do not understand multimaster replication. The BDCs, member servers, and clients are unchanged and unaware that the PDC is now an Active Directory server.
To migrate the BDCs, upgrade each one to Windows NT 5.0. The upgrade process recognizes the BDC, automatically installs it as an Active Directory replica, and inserts it into the replication topology. When all domain controllers have been upgraded to Windows NT 5.0, the domain is no longer a mixed domain, and changes can be made to any replica.
To migrate member servers, upgrade them to Windows NT 5.0. 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 NT 5.0 allows it to participate in Kerberos security, adds support for Active Directory–aware applications, and adds the MMC and Active Directory–aware shell and common dialogs.
To migrate Windows NT Workstation–based clients, upgrade them to Windows NT 5.0. You can migrate Microsoft 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 NT 5.0, 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 NT 5.0, 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 NT 5.0, 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."
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 RRs in DNS with names in the form
LDAP.TCP.<domain name>
Thus, a workstation logging in to microsoft.com will query DNS for SRV RRs 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 NT Workstation 5.0. These include the name formats supported by the Microsoft Win32® application programming interface, DsCrackNames, which is used to convert these name forms as necessary.
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 NT 5.0 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 NT 5.0, 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 DCs.
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:
A search of the global catalog is initiated in one of several ways:
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 NT 5.0 is anRFC and BIND compliant implementation of Dynamic DNS. It is a native implementation for Windows NT, 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 NT 5.0. 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 NT 5.0. Windows NT 5.0 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 the latest information on Windows NT Server, see the Microsoft Windows NT Server 4.0 Web site (http://www.microsoft.com/ntserver/), or visit the Windows NT Server Forum on The Microsoft Network (GO WORD: MSNTS).
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 document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.