The key to the scalability of the Windows NT next generation Directory Server is the domain tree. Unlike directory services that consist of a single tree structure and require a complex "top down" partitioning process, the Windows NT next generation Directory Server provides a simple and intuitive "bottom up" method for building a large tree. In the Windows NT next generation Directory Server, a single domain is a complete partition of the directory. Domains are subdivided into Organizational Units (OUs) for administrative purposes. This can be seen in the following figure .
A single domain can start very small and grow to contain over 10 million objects. When a more complex organizational structure is required, or a very large number of objects must be stored, multiple Windows NT domains can be easily joined to form a tree. With the next generation Directory Server, a domain tree can contain many tens of millions of objects.
The Windows NT Directory Service namespace is organized into a "tree of trees" in which each subtree is a Windows NT Domain. Each domain publishes its existence in DNS, allowing clients to find Directory Servers ("Domain Controllers") and Directory Servers to find each other.
The LDAP protocol is used by clients to communicate with the directory; the LDAP protocol requires the names of objects in the directory to be formed according to RFC 1779. RFC1779 defines the X.500 style of name as the standard name for objects in a directory. For example, a typical user object for "James Smith" might be named:
CN=James Smith,OU=Recruiting,OU=HR, OU=Europe,O=ArcadiaBay,C=US
To accommodate the requirements of LDAP, the Domain objects in the Windows NT Directory Service are built by derivation. That is, there is an Auxiliary form of the Domain object that is used to provide the attributes needed to define a domain, and derived forms of the Domain object that are created by deriving subclasses from the auxiliary object and the standard X.521 base objects: Country, Locality, Organization, and Organizational-Unit.
The resultant objects are:
Each object has the attributes and containment rules of both Domains and the standard X.500 object classes from which they are derived. For example, Organizational-Unit has the "Organization-Name" property, and Domain has the Auditing-Policy property. The Domain-Organizational-Unit object has both the Organization-Name and Auditing-Policy Properties. The Object Class of the derived object contains the class of the object itself, and the class of all its superclasses. This means that to a Windows NT or Windows® 95 client, the directory structure can be viewed as a tree of domains. To a "generic" LDAP client, the directory structure appears to be a tree structured according to X.521 structure rules, with RFC 1779 naming:
The standard form of Domain in the Windows NT Directory Service is the Domain-Organizational-Unit. This is the default domain object class used when creating a new domain. Domain-Organizational-Units provide the greatest flexibility when forming a tree because there are very few restrictions on their number and placement.
A Domain-Organizational-Unit may be:
Domain-Locality offers similar flexibility, and is most useful for tree structures that are geographically partitioned. In practice, the Domain-Organizational-Unit offers similar flexibility and capability, and should serve the needs of both organizational and geographical tree structures.
Domain-Organization exists primarily for enterprises that have put a "top down" deployment strategy in place; this structure tends to be somewhat more rigid than one based on Domain-Organizational-Unit, since there can be at most one Domain-Organization in the enterprise. Deploying a tree structure with a Domain-Organization as the root domain should be done only after careful consideration and planning. Domain-Country exists for compatibility with X.500 and should not be used by commercial users.
All objects stored in the Windows NT next generation Directory Service have an entry in the Global Catalog (GC), a service that contains summary information from all of the objects in the tree. Designed for fast searching, the GC allows users to easily find an object, regardless of where it is in the tree, while searching by selected attributes. As a result, many common queries can be resolved from the GC without requiring a lookup in the source domain. A typical use of the global view is to provide a global address book for purposes of mail or any mail-enabled application.
Using the Container Hierarchy to Model the Organization The ability of the container hierarchy in the next-generation Windows NT Directory Server to nest Organizational Units within Domains (as well as within other OUs) provides a hierarchical name space which administrators can use to reflect their organization and to delegate administrative control. A container contains a list of contents, which could be major company divisions. In this scenario, it is then possible to select a division below a previous division and open it, and so on. Moving to a container hierarchy such as this with a finer-grained administrative model solves many problems. Large domains will still be possible. Finding things will still be easy because everything that exists in the domain tree will show up in the global catalog, a service that allows users to easily find an object, regardless of where it is in the tree.
The manner in which a directory stores information directly determines the performance and scalability of that directory service. Directory services must handle a very large number of queries compared to the number of updates. Typically the ratio is 99% query and 1% update. For this reason, replicated storage is important. By creating multiple replicas of the directory and keeping them consistent, the number of queries that can be handled with no performance degradation is increased.
The Windows NT next generation Directory Service offers multi-master replication. Some directory services use a master-slave approach to do updates: all of the updates must be made to the master copy of the directory, and these are then replicated to the slave copies. This is adequate for a directory with a small number of copies and an environment where all of the changes can be applied centrally, but this approach does not scale beyond small-sized, or address the needs of decentralized, organizations.
Because the Windows NT next generation Directory Server offers multi-master replication, individual changes made in one copy of the directory are automatically replicated to all other appropriate copies of the directory, whether they are connected via point-to-point or store-and-forward links.
For urgent changes, such as disabling a user account or changing a password, push replication is used, which means that after a change is made on one copy of the directory, the machine holding that copy pushes the change to its partners.
Some directory services use time stamps to track updates. In a master-slave directory where all updates are made centrally, this is adequate, but in a multi-master replicating directory using time stamps is inadvisable. Unless time is perfectly synchronized among all copies of the directory, there is a chance for data loss or directory corruption. The Windows NT next generation Directory Server does not depend upon time stamps for detecting updates. Instead, it uses Update Sequence Numbers (USNs).
Any time anything is written into an object in the directory, it gets a new update sequence number (USN), which is held per machine, and a version number which incremented any time a change is made to that object. If a user on one machine updates a user record, the current value for the version number on that object is incremented, and is then written into the object along with a new USN and a unique signature of the machine that wrote that change. The object also carries a USN and version number for each property. When a property is updated, the property version is advanced and a new USN is applied.
During each replication cycle the replication partners of one machine ask for all of its changes greater than the last USN received. The source machine will then search through the directory and find each object whose update sequence numbers are greater than the one presented by the partner machine.
Property changes are reconciled individually; when a change is replicated, only properties with a higher USN are updated. Collisions are detected by version number. When one property has been updated by two different machines, the one with the later time stamp wins. This use of time stamp is simply as an arbitrary "tie breaker," so time synchronization is unimportant.
Per-property reconciliation keeps the chance of collisions to a minimum.
The Windows NT next generation domains can be organized into a hierarchical domain tree. Transparent Trust within the tree allow users with accounts defined anywhere in the tree to be granted secure access to resources anywhere in the tree. Transparent trust within the tree effectively eliminates the need for trust management.
The Windows NT next generation Directory Service supports two forms of trust relationships:
Two-way transitive trust between domains that are part of the Windows NT scaleable namespace. This is the default; trust relationships among domains in the tree are established and maintained automatically. Transitive trust is a feature of the Kerberos system, which provides the distributed authentication and authorization in Windows NT next generation systems.
one-way trust relationships to domains not part for the same tree. This capability is provided to support connection to existing Windows NT 4.x and earlier domains, and to allow the configuration of trust relationships with domains in other trees.
The following diagram shows the two styles of trust relationship:
Transitive trust between domains eliminates the management of inter-domain trust accounts. Domains that are members of the domain tree automatically participate in a transitive, bi-directional trust relationship with their parent domain. All domains implicitly trust other domains in the tree. If there are specific domains where transitive trust is not appropriate, explicit one-way trust relationships can still be defined.