Steve Judd
Microsoft Corporation
November 26, 1996
The purpose of this article is to help customers who have existing implementations of Microsoft® Windows NT® Server understand how to migrate to Microsoft's next generation Directory Service. This is an introduction and an overview of migration to the next generation Directory Service; it is not a tutorial on how to design great Windows NT directory trees. Two of the main features of the next generation Directory Services are: 1) complete interoperability with Windows NT 3.x and 4.x, and 2) a very easy migration from Windows NT 4.x domains. This article will give you examples of how such a migration will take place for the traditional Windows NT 4.x domain models.
As we proceed through the document there are three things to remember about migrating to the next generation Directory Service:
When migrating to any new infrastructure you need to understand where you are, where you are going, and why you are going there. Before we explain how migration occurs, we will discuss the new concepts and technologies introduced with the next generation Directory. This will help you understand how the next generation Directory Services will fit into your environment.
As you read this document you should be thinking about the following issues:
There are no universal right or wrong answers. The method you choose will depend on your organization's needs and how you plan on supporting this infrastructure in the future.
The key concepts in understanding the next generation Directory Service are:
The directory stores objects. These objects represent real things such as users, groups of users, workstations, applications, data, distribution lists, etc. Each object has its own unique attributes. A user object will have attributes like full name, password, telephone number, and so on. The formal definition of all object types that can be stored in the directory is called the schema. The definition in the schema consists of a class definition for each type of object and an attribute definition for each attribute. The class definitions list the attributes that can be used to describe the class.
There are no set limits to the type of objects and their attributes that can be defined within a directory. The ISO has published a recommended set of attributes and objects in the X.520 and X.521 Recommendations. These are objects and attributes that the ISO membership has agreed provide useful information for a global "white pages" directory. There are international standards for syntaxes for select object attributes; phone numbers for example. Although some attributes have become standardized, others will never come to a global or national standard. This is perfectly reasonable; individual users have diverse needs and a directory service must accommodate a wide range of uses.
The Windows NT next generation Directory Service architecture is designed to take advantage of the best features of the Internet Domain Name System (DNS) service and X.500, while not imposing the limitations of either.
Windows NT Directory Service (NTDS) takes advantage of DNS for name resolution. The next generation of Windows NTDS uses DNS as the location service that allows a client to find a directory server containing the desired copy of the directory.
DNS is the most widely used directory service in the world. DNS is the location service used on the Internet and in most private intranets. The location service is used to translate a name, for example MyMachine.ArcadiaBay.Com, into a TCP/IP address. DNS is designed to scale to very large numbers of entries (it supports the entire Internet), while remaining "lightweight" enough for use in a system with just a few computers.
The Windows NT next generation Directory Service uses DNS as its location service; that is, Windows NT Domain Names are DNS names. Users will find the same simple naming used on the Internet in NTDS. ArcadiaBay.Com can be both a DNS domain (e.g., an area of addressing) and a Windows NT Domain. JamesSmith@ArcadiaBay.Com is both an Internet e-mail address and a user name in the ArcadiaBay.Com domain. Windows NT domains can be located on the Internet and on intranets the same way any resource is located on the Internet: by means of DNS.
The X.500 family of standards was developed jointly by the International Standards Organization (ISO) and the International Telecommunications Union (ITU). It was designed to promote the development of an international white pages directory service made of up of large numbers of Directory System Agents (DSAs) connected in an Open Systems Interconnection (OSI) network using protocols defined in the standard. There have been several significant barriers to the deployment of X.500 directories:
The X.500 family of standards is most useful for providing interoperability among directories. The communications protocols can be carried over a TCP/IP network, thus eliminating the dependence on OSI. The existence of well-defined protocols and formats makes interoperation among different directory services practical.
The Windows NT next generation Directory Service will provide subsets of the 1993 X.500 protocols that are required to enable participation in an existing X.500 directory; and it will interoperate with directories and tools that support the X.500 protocols. The relevant X.500 protocols are:
Figure 1. Protocols for access and interoperability
Support for these protocols allows the Windows NT next generation Directory Service to participate in mixed Internet and X.500 environments. The end user benefits from the implementation features of the next generation Windows NT Directory Service without the burdensome overhead of X.500.
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.
Figure 2. The tree of trees means scalability
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.
Figure 3. DNS is the location service
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. RFC 1779 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.
Figure 4. Inheritance of schema properties
The resultant objects are:
Domain-Country
Domain-Organization
Domain-Locality
Domain-Organizational-Unit
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:
Figure 5. X.500 naming structure
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:
The following diagram shows the two styles of trust relationship:
Figure 6. Both Kerberos and Windows NT 4.0-style trust supported
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.
The Windows NT Next-generation Directory provides a complete separation of the logical structure of the domain hierarchy from the physical structure.
The logical structure of the directory is defined by the container hierarchy. This is the view seen by users. The Windows NT next generation Directory Service allows you to design a hierarchy that makes sense to the users who will use it and to the administrators who will manage it. The physical structure of the underlying network, the location of directory replicas, and the distribution of shared file volumes and printers across servers is not visible to the users. Users can find the objects of interest by querying the directory, as in the following:
"find me a postscript printer with duplex capability on the second floor of building 5"
The other option is to navigate through the directory hierarchy. Familiar desktop metaphors such as "favorites" folders and shortcuts all take advantage of the logical view of resources provided by the directory.
The physical structure of the next generation Windows NT Directory is based on servers and sites. A server is a Windows NT Server that holds a replica of a domain (a "Domain Controller"). A site is an area of good connectivity, typically a LAN or other fast network.
A site allows you to map the replication traffic to your physical infrastructure. Within a single site, replicas of a given domain replicate among each other. Designated servers in each site are responsible for replicating changes to partners in other sites. You can have replicas of as many different domains as you need within a site. This lets you establish domain replicas wherever needed for availability and performance, independent of the logical structure of the Windows NT Directory Scalable Namespace.
Let's look at an example. Assume your company has five different locations with in a region. These locations are connected by 56K leased lines.
Figure 7. Site topology
Before you begin your migration you should design your initial site topology. It is a good idea to set up your site topology in accordance with your physical network.
Figure 8. Network topology
As time goes by, your physical infrastructure may change and the network load may change. Changing your site topology is easy using the administration tools provided by the next generation Directory Service. This gives you great flexibility to allow your site topology to evolve with your networking and organizational needs.
There are many different types of objects that can be stored within your directory. Some common ones are the User, Group, Workstations, Printers, etc. You can also put references to an application's object or component. You can use the directory to located distributed applications across your infrastructure. Most of the objects you are accustomed to have been expanded to allow the directory to hold more useful information. You can also expand the properties to suit your own specific needs. For example, you might also want to place an employees "Signing Limit" for Purchase Orders with your user's object. This would allow a purchasing workflow application to easily determine if further approvals are needed.
The Windows NT next generation Directory Service dramatically simplifies the creation and management of security Groups. There is no concept of a "local group" or a "global group" from the Directory's point of view. A group created in the directory service is available to all domains in the tree. A group created using a local administrative tool on a particular server or workstation is "local" to that machine because it does not appear in the Directory. It is stored on the machine where it was created and can only be used there.
Several different name forms are provided and are described below.
RFC822 names are in the form somename@somedomain and are familiar to most users as Internet e-mail addresses; for example JamesSmith@ArcadiaBay.Com. The Windows NT next generation Directory Service provides a "friendly name" in RFC822 form for all objects. For example, a user can use a "friendly name" as an e-mail address, suitable for display on a business card, and as the name used to log in.
The Windows NT next generation Directory Service supports access from Web browsers via the HTTP protocol and the Microsoft Internet Information Server, the full-service Web server built in to Windows NT Server. HTTP URLs are familiar to most users who have Web browsers, and are in the form HTTP://somedomain/path-to-page. The next generation Windows NTDS supports access to its contents via HTTP URLs in which "somedomain" refers to a server running the next generation Directory Service and "path-to-page" is the path through the next generation Directory Service hierarchy to the object of interest. For example:
HTTP://WWW.ArcadiaBay.Com/User.ASP?path=/OU=Division/ OU=Product/OU=IT/CN=JamesSmith
LDAP URLs and X.500 Names The Windows NT next generation Directory Service supports access via the LDAP protocol from any LDAP-enabled client. LDAP names are less intuitive than Internet names, but the complexity of LDAP naming is usually hidden within an application. LDAP names use the X.500 naming convention, called attributed naming. An LDAP URL names the server holding the next generation Directory Service and the attributed name of the object. For example:
LDAP://SomeServer.ArcadiaBay.Com/CN=jamessmith,OU=IT, OU=Product,U=Division,O=ArcadiaBay,C=US
The Windows NT next generation Directory Service supports the Universal Naming Convention used in Windows NT Server-based networks to refer to shared volumes, printers, and files. A user can refer to a shared file on a volume published in the Windows NT next generation Directory Service by a UNC name; for example:
\\Europe.ArcadiaBay.Com\FinanceSpreadsheets\ XLSheets\Budget.XLS
In this sample, "Europe.ArcadiaBay.Com" is the DNS name of the domain where the shared volume is published, "FinanceSpreadsheets" is the name of the shared volume published in the DS, and "\XLSheets\Budget.XLS" is the directory and file on the shared volume.
In the current release, Windows NT account information is stored in a secure portion of the Registry on Domain Controllers. Using domain trust and pass-through authentication, a two-level hierarchy of domains provides a degree of flexibility for organizing account management and resource servers. Within a domain, however, accounts are maintained in a flat name space with no internal hierarchical organization.
The next generation of Windows NT security uses the Windows NT Directory Services as the repository for account information. The Directory Service provides significant improvements over the Registry-based implementation in the areas of performance, scalability, and feature-rich administrative environment.
The advantages of integrating security account management with the Windows NT Directory Service are:
Storing the security account information in the Windows NT Directory Service means users and groups are represented as objects in the Directory. Read and write access to objects in the Directory can be granted to the object as a whole, or to individual properties of the object. Administrators have fine-grain control over who can update user or group information. For example, a Telecom operator group can be granted write access to only user account properties related to office telephone equipment without requiring full Account Operator or Administrator privileges.
The concepts of groups is also simplified because local and global groups are both represented by group objects in the directory. Existing programming interfaces for local group access are still supported for complete backward compatibility. However, groups defined in the directory can be used for domain-wide access control to resources or only for 'local' administration purposes on the domain controller.
Delegation of administration is a valuable tool for organizations to confine the security administration so that it applies only to defined subsets of the entire organization domain. The important requirement is to grant rights to a small set of users or groups to manage their area of responsibility, but not give them permissions to manage accounts in other parts of the organization.
Delegation of responsibility to create new users or groups is defined at the level of an Organizational Unit (OU), or container, where the accounts are created. Group administrators for one organizational unit will not necessarily have the ability to create and manage accounts for another organizational unit within a Domain. However, domain-wide policy settings and access rights defined at higher levels in the Directory tree can apply throughout the tree by using inheritance of access rights. There are three ways to define the delegation of administration responsibilities:
The Directory Service Administration user interface makes it easy to view the delegation information defined for containers. Adding new delegation of permissions is also easy to do by selecting who you want to delegate permission to and choosing what permissions they need.
Integrating the security account repository with the Windows NT Directory Service provides real benefits to manage the Enterprise. Performance, ease of administration, and scalability for large organizations are the direct result. Internet-based Enterprises can use Domain trees and hierarchical OUs to organize accounts for business partners, frequent customers, or suppliers with specific access rights to their system.
Large organizations typically depend on many individuals or groups to secure and manage the network account infrastructure. They need the ability to grant access rights for specific operations—such as resetting user passwords, or disabling accounts—to specific groups without also granting the permission to create new accounts or change other properties of user accounts.
The security architecture for Directory Service objects uses Windows NT security descriptors to control object access. Every object in the Directory has a unique security descriptor. The Access Control List (ACL) in the security descriptor is a list of entries that grant or deny specific access rights to individuals or groups. Access rights can be granted or denied with different levels of scope on the object and can be defined on any of the following levels:
Granting uniform read/write access to all properties of an object is the default access permissions for the creator of the object. Granting or denying object access permissions to a property set is a convenient way to define permissions for a group of related properties. The grouping of properties is defined by the property set attribute of a property in the schema. The property set relationship can be customized by changing the schema. Finally, the definition of access rights on a per-property level provides the highest level of granularity of permissions. Definition of per-property access is available on all objects in the Windows NT Directory Service.
Container objects in the directory also support fine grain access with respect to who has permissions to create child objects and what type of child objects they may create. For example, the access control defined on an Organizational Unit (OU) can define who is allowed to create User objects (accounts) in this container. Another entry in the access control for the OU might define who is allowed to create Printer objects. Fine grain access control on directory containers is an effective way to maintain organization of the directory name space.
A new implementation of the "ACL Editor," the common dialog control for viewing or changing object security permissions, provides an easy-to-use interface for defining access rights to Directory Service objects by property set or individual properties. The ACL Editor also supports defining "inherited" access rights on container objects that flow down to all sub-objects in that portion of the directory tree.
The Windows NT next generation Directory Service provides intuitive and powerful administration tools. Objects can be hierarchically organized so that they can model large organizations. And the graphical user interface delivers one of the most requested administrative tools—a drag-and-drop control console. This console has a graphical user interface that provides an object-view of administration. For example, to do pruning and grafting, the administrator would grab the top of the merge-from tree and then drag and drop it onto the target domain. A dialog box asks the administrator to confirm the action. Of course, the administrator must have rights in the merge-from tree to merge it with another tree, and in the merge-to domain to bring new trees into it.
Anything that can be done through a UI should be able to be done programmatically or from a script. To allow an administrator to write command procedures, the Windows NT next generation Directory Service provides full support for OLE automation and scripting. This makes it possible to add, change, move, copy, and perform other administrative functions by scripted manipulation using Active Directory, and a scripting language such as Java, Microsoft® Visual Basic® Scripting Edition, or others.
Now that we have discussed the new concepts and issues with Windows NT Directory Services, we can work through the migration of the traditional Windows NT domain model to the next generation model. The difference between the Windows NT 4.0 domain models model is the number of domains involved and the trusts between them. The migration process is grown through the different scenarios.
Windows NT 4.x and earlier support several domain models, distinguished by the number of domains and the trust relationships between the domains. Four domain models are described in the planning guide for earlier versions of Windows NT:
All of these models (and the variations on them) can be easily migrated to the next generation Directory Service. The migration process is divided into two parts:
These steps are performed the same way regardless of the domain model(s) in use. The only difference is the number of times each step needs to be performed. In the case of Resource domains, you have the option of (a) keeping the resource domain after migrating it or (b) folding the resource domain into one of the former "master" domains and using delegation of authority in the container hierarchy to provide the desired granularity of administrative responsibility.
Upgrading a domain is always performed the same way, regardless of the domain model in use. This is a simple, iterative process.
First, upgrade the Primary Domain Controller. This converts the Registry-based security data base to a next generation directory store. To Backup Domain Controllers and clients in the domain, the upgraded PDC looks like a Windows NT 4.x system, and operation continues normally. As soon as the PDC has been upgraded, you can begin using the Windows NT Common Console to perform administration. The partially upgraded domain is a "mixed" domain; to clients and other domains it looks and acts exactly like a Windows NT 4.0 domain.
Figure 9. Step 1 — Upgrade the PDC
After the PDC has been upgraded, you can upgrade the BDCs. You can proceed at your own pace.
Figure 10. Steps 2–n — Upgrade BDCs
When all BDCs have been upgraded, the domain is a "pure" Windows NT next generation domain, and is eligible to join a tree. Mixed domains cannot join domain trees, because the systems that have not been upgraded do not understand the new security system, transitive trust, and other advanced next generation facilities that implement the Scalable Namespace.
Figure 11. Migration complete
In the case of the single domain model, the upgrade is complete when Step 1 has been completed. The single domain model involves only one domain, so no tree formation is possible.
In the case of the master, multiple master, and complete trust models, tree formation is possible. The elimination of explicit trust, administrative streamlining and usability enhancements that accompany the Scalable Namespace make tree formation highly desirable for these domain models.
To form a Domain Tree, at least two domains must have been completely upgraded to be next generation domains. As described above, this simply means that all of the Domain Controllers in the domains have been upgraded. To form a domain tree, you must:
You must have special rights in both domains that allow you to perform tree operations. For purposes of illustration we will assume a simple case of two domains in a complete trust relationship. After upgrading both domains the Windows NT4 trust relationships are still in place. Users in the "Americas" domain can be granted access to resources in the "Europe" domain and vice versa.
Figure 12. Initial state
Now we can form a simple tree. In this example we have chosen to make the "Americas" domain the root of the tree. This is called the "joined to" tree. Even though "Americas" is a single domain, it is still a "tree" in next generation Directory Service terms. In the Administrative tool within the Common Console, we select the Americas domain and identify it as the "joined to" tree. We must be logged on to the "Americas" tree with a valid account that has the necessary rights to perform tree operations. We identify the "Europe" domain as the domain that we want to "graft" onto "Americas." We will be required to supply security credentials for the "Europe" domain. Like the "Americas" domain, the credentials we supply must be sufficient to give us the right to perform tree operations in the "Europe" tree.
Figure 13. Begin tree join process
The actual connection of the parent domain to the child is accomplished with a special object type in the Directory, a Domain Proxy object. Domain Proxy objects are stored in a special part of the directory reserved for directory metadata. The Domain Proxy object(s) are used by the next generation Directory to determine the shape of the directory tree. Creation and maintenance of the metadata objects is automatic is performed by the Administrative tool. As part of the Tree Graft operation the Next-generation software automatically detects the Windows NT4 trust links between the joined-to and joined-from trees (which are single domains in this case), and replaces then with an automatic, transitive Kerberos trust. This occurs without administrative intervention.
Figure 14. Automatic trust link creation
The end result is a simple domain tree, the beginning of a Windows NT next generation Scalable Namespace. Additional domains can be joined as children under the "Americas" or "Europe" domains, as needed, to provide the logical structure to meet the organization's needs.
Figure 15. Domain tree
A resource domain is simply a normal Windows NT 4.x (or 3.x) domain in which there are no user accounts. Resource domains are used to collect a group or resources (files shares, printers, etc.) for purposes of administrative control. Users gain access to the resources in a resource domain through a trust relationship; resource domains trust one or more master domains. Users with accounts in the master domains can be added to Access Control Lists on the resources in the resource domains.
The preceding examples have shown how a domain can be upgraded to the Next-generation simply and easily. Since a resource domain is a domain like any other, it too can be upgraded.
System administrators have a large investment in the Access Control Lists they have created on the resources in the resource domains. An Access Control list is simply a list of the Security Principals who are allowed (or forbidden) to use the resource protected by the ACL.
A Windows NT Access Control List contains the Security Identifiers of the relevant users and groups. When you upgrade a Windows NT 4.x domain to a Next-generation domain, the security identifiers of the users and groups in that domain are not changed. This means that any Access Control list that contains those security identifiers is still completely valid.
The explicit trust between a resource domain and the master domain(s) that existed before the upgrade remains in place until the domain is joined to the tree. If the domain is never joined to the tree, the explicit trusts remain, and the users can use the resources as they did before the upgrade. If the domain is joined to the tree, the explicit trust is automatically replaced with a Kerberos Transitive Trust, and the users can use the resources as they did before the upgrade.
Resource domains are put in place to give local administrators control of local resources. With the availability of the fine-grained delegation of authority in the Next-generation Directory Service, there is little advantage to retaining resource domains in the longer term.
Over time, the resources in most resource domains will very likely be absorbed by one or more parent domain. Individual resources can be moved into Organizational Units to provide the desired delegation of administrative authority.
Converting a resource domain is a simple matter of moving the resources (usually servers) from the resource domain to an Organizational Unit in one of the former master domains.
Figure 16. Domain tree with resource domain
In the preceding figure we see a Domain Tree with a resource domain joined to the bottom of the tree as a "leaf" node. To convert the resource domain to an Organizational Unit (or group of Organizational Units), all we need do is move the resources, in this case three member servers, from the resource domain to one of the parent (or peer) domains in the tree. This is shown in the following figure.
Figure 17. Resources moved to OU in parent domain
Moving a member server from the resource domain is accomplished by administratively removing it from the resource domain that is being dismantled and joining it to the desired domain in the tree. This is shown in the following figure.
Figure 18. Moving a member server
In the preceding example we simplified the domain tree by eliminating a resource domain. We eliminated the resource domain by moving the servers it contained into other domains. What effect does this have on the member servers?
As discussed earlier, the access controls lists that are applied to resources in resource domains are not affected by an upgrade the next generation Directory Service because the security identifiers of the principals (users and groups) are not changed.
Many existing Windows NT installations protect the resources on their member servers with Local Groups. A local group is a security group that is defined on a specific machine and is stored locally on that machine. For example, a print server might have a high-resolution large format color printer attached, which is for the exclusive use of the graphic arts department. In this case, a common practice is to create a local group on the print server and call it LARGE_FORMAT_PRINTER. The local group LARGE_FORMAT_PRINTER is granted access to the printer with an ACL that denies access to all others.
The employees in the graphic arts department are all members of the GRAPHIC_ARTS_DEPARTMENT global group. A global group is a security group in Windows NT 4.x and 3.5x that is valid anywhere in the domain where it is defined. By adding the GRAPHIC_ARTS_DEPARTMENT global group to the LARGE_FORMAT_PRINTER local group on the print server, anyone who is a member of the graphic arts department can gain access to the printer. When someone leaves the department, they will be administratively removed from the GRAPHIC_ARTS_DEPARTMENT group and thus no longer be allowed to use the printer.
What happens when we upgrade to the next generation Directory Service?
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver/ or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS). To access Other Windows NT Server information on the Web, go to http://www.microsoft.com/ and select Microsoft BackOffice.