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.
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.
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.
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?
The GRAPHIC_ARTS_DEPARTMENT group automatically becomes a group in the Directory, visible and usable by all domains in the tree.
The local group on the print server is unaffected, because local groups are stored locally on the machine where they are used, and are not changed in any way by the upgrade. Because the security identifiers are unchanged, even though GRAPHIC_ARTS_DEPARTMENT is now a group in the Directory, the entry for GRAPHIC_ARTS_DEPARTMENT in the LARGE_FORMAT_PRINTER group is still perfectly valid. The protections on the printer are unchanged.
Moving the print server from the resource domain to another domain in the tree has no effect on the ACLs, because no security principals are involved in the move. It also has no effect on the LARGE_FORMAT_PRINTER group because this is a purely local group and is not affected by domain membership.