This chapter covers the following:
One primary strength of Windows NT Server is its domain facility for providing access to and control of network resources wherever needed. Windows NT Server provides file, print, and application services to a variety of clients in various environments. Access to these services doesn't need to be limited by geography or network bandwidth. More importantly, control and administration of these services can be distributed to fit either a centralized or decentralized support model. Windows NT Server uses domains to provide unified access to and administration of resources in large, distributed networks.
This chapter emphasizes the value domains bring to your Windows NT network environment, and how to take best advantage of domains in LANs and WANs. The chapter also shows you how to use the Domain Planner tool of the Windows NT 4.0 Resource Kit to establish the architecture of your domains.
In the simplest terms, a Windows NT domain is a logical grouping of servers, workstations, users, groups, and printers within a physical network. The architecture of Windows NT domains is quite complex, involving security issues, different types of user groups, and trust relationships. For this introductory discussion, you can consider a domain to be a group of resources (Windows NT objects) that are bound by a common membership into a single administrative unit. The purpose of domains is to permit distributed network management by segmenting the resources of large networks into sets of manageable sizes.
If you've used Windows for Workgroups, you're familiar with the concept of small groupings of users who need access to common resources, such as files and printers, which reside either on members' PCs or on a central peer-to-peer file server. Domains are extensions of workgroups designed to support larger sets of users who may be located at geographically distant sites. Figure 16.1 illustrates the concept of a domain named SalesCo, which consists of two servers (HQ and Regional), plus client PCs for UserA through UserF. The Regional server for the Sales user group and the HQ server for the Accounting user group are connected by a telecommunications link. The HQ server, a Primary Domain Controller (PDC), is the administrative site for the domain. The Regional server is a Backup Domain Controller (BDC). The relationships between PDCs and BDCs is the subject of the later section "Understanding the Roles of Domain Controllers."
16.1
A domain containing servers, printers, client PCs, users, and groups.
Windows NT Server authenticates users when they log on to a server in a domain (authentication is the process by which users gain access to the resources for which they have rights). Unlike earlier network operating systems, such as Novell NetWare 3.x, users log on once to the domain, rather than log on to each server they want to access. Likewise, administrators can assign rights to a Domain User or Domain Group, and these rights are applied universally to any domain resource users want to access.
Windows NT Server's single-logon approach extends to server-based applications, such as the members of Microsoft's BackOffice suite. If you install BackOffice applications with Windows NT Server's integrated security feature, users aren't required to separately log on to SQL Server, Exchange Server, System Management Server, or SNA Server. All BackOffice products use Windows NT's built-in security model to authenticate users to these BackOffice services.
Beyond the concept of grouping user, machine, and server resources into logical domains, Windows NT provides a mechanism to secure a resource's right to the domain. That is, when a server or client joins a domain, or when a user or user group is created within a domain, Windows NT Server provides a mechanism to guarantee that the new resource is uniquely associated with the domain. From a security standpoint, this mechanism also assures that a user or machine that isn't properly identified to the domain can't access resources in the domain. Windows NT uses a SID (Security Identifier), in addition to a name, to identify each domain resource, group, or user. The SID is generated at the time of creation of the resource and is unique. You can't duplicate a SID, because the SID is based on a variety of CPU information at the instant of the SID's creation.
When you establish a new domain by installing Windows NT Server as the Primary Domain Controller, which is the default for your first Windows NT Server installation, the domain receives its own SID. As you add servers, clients, groups, and users to the domain, their unique SIDs include a reference to the original domain SID. If you move a client PC from one domain to another, the client's SID references the wrong domain and can't use the resources of the new domain. Figure 16.2 illustrates this situation with Server Manager; WORKSTATION1's SID doesn't refer to Primary Domain Controller SERVERA's SID, so WORKSTATION1 appears with its icon disabled (grayed). Overcoming problems with SIDs that reference the wrong domain is one of the subjects of the later section "Moving Machines Between Domains and Renaming Domains."
16.2
Server Manager displaying invalid domain client PCs.
The advantages of a secure logical grouping of resources become apparent when you must manage large groups of users and machines. Network security is paramount in Windows NT Server's domain architecture. Fortunately, Windows NT Server's administrative tools, such as User Manager for Domains and Server Manager, shield network administrators from most (but not all) of the complexity of SIDs. One of Microsoft's guiding principles in the design of Windows NT is that features to make network administration more convenient must not compromise network security in any way.
Users of clients running Windows for Workgroups 3.1+, Windows 95, and Windows NT can create independent peer-to-peer workgroups within a Windows NT domain. Workgroup members share files, printers, and other resources independently of Windows NT's domain security services. Most Windows NT network administrators discourage the establishment of peer-to-peer workgroups because of their lack of security.
Windows NT Server supports the following two types of domain controllers, both of which are network servers:
The PDC is by default the first server you install in a new Windows NT network. When you install a new Windows NT server in an existing network and choose to create a new domain, the Setup program scans your network for a domain controller with the name you specified. If no PDC with the same name is found, the server becomes the PDC.
When installing a new server in an existing domain, make sure that the server has network access to the existing PDC. You can install a BDC only if you have a functioning network connection to the PDC. If you install the unconnected server as a second PDC with the same domain name and later connect the original PDC to the network, you have two PDCs in the same domain with different domain SIDs. Any clients or servers can't authenticate to the domain. In this situation, you must reinstall Windows NT Server 4.0 on the new server while the PDC is connected to the network. If you reinstall Windows NT Server 4.0 as a BDC, the PDC replicates user and group information to the new BDC.
The PDC's role is critical to Windows NT networking. The PDC is the keeper of all user, group, and machine account information for the domain. This information is stored in the SAM (Security Accounts Manager) database, which resides in files in the %systemroot%\system32\config folder on the PDC's fixed disk. The PDC is responsible for maintaining the master version of the domain SAM. When you change user passwords, add or remove user and group accounts, or add or remove machines in the domain, the PDC's SAM records these changes.
You can use the Getsid.exe command-line application included in the Windows NT Resource Kit to determine the SID for a specified user account. Getsid.exe is useful for troubleshooting user authentication problems. You can't, however, change the user account SID with Getsid.exe. Use the getsid command as follows:
getsid \\servername accountname \\servername accountname
getsid requires two account names because part of its function is to compare the SIDs of each to determine whether they're the same. Figure 16.3 shows an example of the output of getsid.
16.3
Comparing and displaying SID information with getsid.
If the PDC is the only domain controller in your domain, the PDC is responsible for maintaining the domain SAM, plus performing routine domain tasks, such as authenticating user logon requests and maintaining user accounts. If you have a large number of users in a domain, routine domain management tasks can occupy a substantial percentage of server resources, slowing normal file, printer, and application server operations.
If servers and clients are connected to a remote PDC by a low-speed network connection, such as Switched-56 or ISDN lines, authentication by the PDC can become very slow. To avoid problems that arise from overload or remote PDCs, Windows NT supports the concept of Backup Domain Controllers (BDCs). A BDC is a Windows NT server installed into a domain after the PDC is installed. The BDC's function is to offload some of the routine domain-related tasks from the PDC and provide redundancy in the event that the PDC becomes unavailable. The BDC contains a copy of the domain SAM, which is replicated (copied) from the PDC on a periodic basis.
The BDC has a local copy of the SAM, so the BDC also can authenticate users. If you have a geographically dispersed network, you assign a BDC to serve remote users. If a user wants to change his password or an administrator wants to create a new user group, the BDC handles the change, and then passes the new password or user account to the PDC during the synchronization process. If the PDC is shut down or otherwise unavailable, you aren't allowed to make changes, such as user passwords or new accounts, to the domain SAM. Even if the PDC isn't available, you can authenticate existing users, and access resources on the BDC and other servers in the domain.
When the PDC fails or is unavailable for an extended period of time, or if you want to change PDC machines, you can promote any BDC in the domain to the PDC. The promoted PDC takes over the role of maintaining the master copy of the SAM database, and the old PDC becomes a BDC just as any other. To promote a BDC to a PDC, follow these steps:
16.4
16.5You can choose to add servers to your network that aren't domain controllers. To do so, select the Server option during installation of Windows NT Server 4.0 on the machine. Non-domain servers use Windows NT Workstation security, one of the subjects of the later section "Adding Windows NT Clients to the Domain." You install non-domain servers primarily for the following reasons:
To spread the load of authentication across BDCs that may reside anywhere on your network, including WANs with slow or unreliable links, Windows NT performs a periodic domain synchronization process. By default, every five minutes a Backup Domain Controller sets up a connection with the PDC, sends all SAM changes that originated on the BDC during the interval, and receives changed information from the PDC's SAM. The PDC keeps track of the revision level (the current version) of the SAM for each BDC in the domain; thus, the PDC sends only the incremental changes needed to keep the SAMs in synchronization. If the BDC loses communication with the PDC for an extended period, the PDC performs a full synchronization by copying the BDC's changes to the PDC's SAM and sending a complete copy of the PCD's SAM to the BDC; this process ensures that the BDC's database is complete and up-to-date.
If you make a large number of changes to the domain SAM, or make changes
that must take effect immediately (such as unlocking a user's account),
you can perform a full or partial manual synchronization with Server Manager.
Server Manager's Computer menu offers the following synchronization
options:
16.6
The message you receive when using Server Manager to synchronize a BDC with a PDC.
As a rule, it's best to synchronize the entire domain from the PDC. Doing so ensures that all changes are pushed to the entire domain. Only changes get pushed, not the entire SAM, so in most cases (less than a 100 changes), network traffic due to domain synchronization is insignificant.
If you're concerned that a large number of SAM changes might affect network performance, you can change Registry values on each BDC to control the replication frequency and the percentage of system resources assigned to perform synchronization.
See "The Danger of Changing Registry Values," (Ch. 9)
You add the following new values to the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters key of a BDC or PDC to control how much data is sent from the BDC to the PDC and how often SAM replication from the PDC is performed:
16.7
Adding a Pulse value to the PDC's NetLogon\Parameters key with the Registry Editor.
Even in a small, self-contained domain, you should have at least one BDC to accommodate user logons in the event of failure of the PDC. If you're building a large domain, you must determine the number of BDCs needed to accommodate all your users. Microsoft recommends a maximum of 2,000 users per BDC, but your network architecture is more likely to determine this number. For instance, if you have a branch office that connects to the rest of your network with a slow link, it makes sense to place a BDC in the remote office for local authentication, as well as file and printer sharing. Fortunately, it's a relatively simple matter to add BDCs as required to handle the authentication load. Later in this chapter, the section "Deciding on the Right Design" provides recommendations for distributing BDCs within one or more domains.
If you're building a number of BDCs to be placed on remote networks with slow links, it's a good idea to start the BDC with a local network connection to the PDC. The initial SAM replication occurs quickly and completely over the LAN. You then move the BDCs (as quickly as possible) to your remote network locations and resynchronize the BDC SAMs to the PDC during the startup operation. This process ensures that only incremental changes to the SAM occur over the WAN link.
After you install the PDC and one or more initial BDCs, you add the network clients to your domain. When a Windows client is added to the domain, Windows NT Server creates a domain machine account for the client. The machine account is a unique SID assigned to the client name to identify the client to the PDC and BDC(s) so that users logging on to the client can access domain resources. Before a client running Windows NT Workstation 4.0 is installed to a domain, it's part of its own workgroup. Figure 16.8 illustrates the NTWS1 client installed to the workgroup WORKGROUP. NTWS1 maintains its own local SAM database of user and group accounts, which you can view by running User Manager (see fig. 16.9) from the Start menu by choosing Programs and then Administrative Tools.
See "Connecting Windows NT Workstation 4.0 Clients," (Ch. 11)
16.8
A Windows NT 4.0 client installed as a member of a workgroup.
16.9
Viewing the local SAM database of a Windows NT 4.0 client with User Manager.
When you join a PC client running Windows NT Workstation to the domain, the client's local SAM database is "hooked" into the domain SAM database of the BDC or PDC. The Domain Administrators global group automatically is made a member of the client's Administrators local group so that Domain Administrator members have access to the client's resources. When you log on to the client, the local SAM authenticates the logon name and password for access to the client's resources. Next, the logon name and password is passed to the BDC or PDC for domain authentication and access to domain resources. This process, called workstation security, permits logging on to the client without the need to join the domain.
Windows NT Workstation is the only Microsoft client that uses the concept of machine accounts. Windows 3.1+ and Windows 95 clients don't create machine accounts in a Windows NT domain. When you want to authenticate to resources in a domain from these clients, you're simply using your domain user ID for authentication. The machine account provides an additional level of security for Windows NT Workstation. That is, a valid machine account enables an administrator to restrict access to domain resources based on a user authenticating from a specific domain workstation.
Also, workstations with machine accounts can be administered from Server Manager. From Server Manager, you can view a workstation's shares, files in use, or where to send alerts generated by that workstation.
The unique SID of the machine account contributes to Windows NT security, but the SID creates problems when you want to move devices into and out of domains, or to rename a domain. The following sections describe the issues involved with reconfiguring clients and servers for use in different domains.
You may find a need to move a client from one domain to another. For example, a user in the Accounting domain may be relocating to the Sales domain. Moving a client to the new domain means changing that client's domain SID to match that of the new domain.
When you move a client running Windows NT Workstation to a new domain,
you connect to the new domain by changing the domain's name in the Identification
page of Control Panel's Network property sheet. If you log on to the client
as a member of the Domain Administrators group, you can change the domain
to which the client is assigned and receive a new SID for its machine account
when you connect it to the new domain. To let users change domains on their
own, a member of Domain Administrators must choose Add
Computer to Domain from Server Manager's Computer menu
to create a new account for the client in the other domain.
If you have a Windows NT Workstation client in DomainA that you want to move temporarily to DomainB, you must re-create a machine account for that machine when reconnecting it to DomainA. The DomainA SID originally assigned to the client can't be re-created on re-entering DomainA.
Windows 3.1+ and Windows 95 clients don't use machine accounts, so moving a client from one domain to the other is simply a matter of providing that client a user ID in the new domain.
Moving a domain controller from one domain to another isn't a step to be taken lightly. If you want to rename a domain, all domain controllers must be renamed. You can change the domain name of a PDC or BDC to a new, unique domain name (as described in the next section), but changing the domain name doesn't change the domain SID. Thus, you can't move a PDC or BDC to a new domain simply by changing its domain name; a truly new domain requires a new SID, which requires a new installation of Windows NT Server 4.0. After you reinstall Windows NT Server 4.0, you also must reinstall as upgrades other applications running on the server, such as SQL Server or Exchange Server.
The need to reinstall server applications when moving a PDC or BDC to a new domain is one of the reasons for running BackOffice and other server-based applications on a non-domain (plain) Windows NT 4.0 server. Moving a plain server to a new domain follows the same process as moving a client running Windows NT Workstation 4.0. The plain server receives a new machine account SID, but the new SID is transparent to clients that access the server-based applications.
See "Choosing the Type of Domain Controller," (Ch. 6)
If you must move a server that's now functioning as the PDC from DomainA to existing DomainB, follow these general steps:
When you move a Primary Domain Controller from one domain to another, all references to user and group accounts that existed in DomainA (such as file and folder permissions for NTFS volumes) are lost. File and folder permissions for the server in the new domain appear as Account Unknown. Groups and users in the new domain are identified with the new domain's SID as a prefix to the group and user SID.
As noted in the preceding section, the original DomainA SID remains as the DomainB SID when you rename a PDC from DomainA to DomainB. Renaming a domain requires you to change the domain names of all devices installed in the renamed domain. Changing the domain name of every device, including BDCs and clients, may be a huge task if you've installed Windows NT to many servers and clients across a dispersed network. If DomainA participates in trust relationships with other domains, renaming the domain breaks the trust relationships, and you must re-create them. (Windows NT trust relationships are the subject of the next section.)
If you must change a domain name, follow these steps:
16.10
16.11See the earlier section "Moving Clients Between Domains" for instructions on how to change domain names for clients running Windows NT Workstation.
The objective of Windows NT Server's domains and trusts is to provide users with a single logon to authenticate them to Windows NT Server resources, no matter where these resources are physically and logically located. An understanding of the authentication process is necessary to take maximum advantage of Windows NT Server 4.0's domain and trust architecture. Familiarity with the authentication process also is necessary to optimize the logical topology of your network to balance logon speed with the performance of applications running on your Windows NT 4.0 servers.
This book uses the term logon to include the authentication process. Technically, authentication precedes logon, because users can't log on to the network until they're authenticated. Unless otherwise indicated in the text, logon includes both authentication and logon operations.
One of the principal roles a PDC and BDC(s) provide in a domain is authentication of Windows NT client and server machines, and all users, including users of Windows 3.1+ and Windows 95 clients. Domain controllers verify that a particular user or machine running Windows NT has valid access to the domain.
The authentication process is provided by the NetLogon service, which runs on Windows NT servers and clients using Windows NT Workstation. The NetLogon service provides a secure channel for messages associated with authentication and domain synchronization. A secure channel is a connection between the NetLogon services on two machines that's established and maintained internally by Windows NT's security subsystem, using its own set of user names and passwords. Administrators have no access to this connection.
When a client running Windows NT Workstation is powered up, the client goes through a series of steps to authenticate to the domain in which the client is installed. The authentication process depends, in part, on the network protocol in use. TCP/IP, the recommended protocol for new Windows NT networks, takes the following steps to authenticate a Windows NT client when the Windows Internet Naming Service (WINS) is installed:
The Windows NT client-installed as a p-node or h-node type WINS client-stores
its domain name locally and queries the WINS server database first for
all domain name entries of 16th Byte type <1C> for the client's domain.
See "NetBIOS Node Types," (Ch. 15)
See "Windows Internet Naming Service (WINS)," (Ch.
17)
After the machine is authenticated to the domain by the fastest-responding domain controller, any user that logs on to that machine uses the responding domain controller's domain SAM database to verify his identity by means of a user name and password.
You can view which server a client uses for authentication by inspecting the value of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\CacheLastController Registry entry.
The process a client uses to choose an authentication domain controller is based on the fact that the controller responding most quickly to the request provides the authentication service to the client. There's no simple means to specify particular domain controllers to provide authentication to a set of workstations. If you have domain controllers across a slow link, there's an off chance that those domain controllers might respond first to client requests, and provide authentication services across that slow link. This is an undesirable situation if the link is very slow. The goal is to prevent unwanted responses from remote domain controllers. In a routed TCP/IP environment, where WINS provides the list of candidate domain controllers, the challenge is to remove the remote domain controller from the 1C list for that domain. You can restrict candidate domain controllers by creating a static mapping in WINS of a domain name type with a list of only those domain controllers that you want to respond for authentication services.
In the case of a network that's broadcast-based, such as NetBEUI or NWLink, you can control where the broadcasts go by using bridge filters and limiting broadcast forwarding between network segments. Any DCs that reside on the same physical network segment as a client, however, always receive the broadcast request for authentication.
Deciding where to place your domain controllers depends on the network protocol you're using and the topology of your network. In a heavily segmented, routed TCP/IP environment, it makes sense to put all your domain controllers and other servers in a centralized server farm. A server farm consists of one or more network segments wherein all servers reside (see fig. 16.12). Each workstation segment has an equal opportunity to access both authentication and file and print services provided by the server farm.
16.12
Domain controller placement in a highly segmented network.
In a less-segmented (flat), bridged, or broadcast-based environment such as that illustrated by figure 16.13, it's more efficient to place one or more domain controllers, plus associated file and print services, on the same client segment. In this configuration, the domain controllers and other servers can quickly service large numbers of workstations, regardless of the network protocol used.
16.13
Domain controller placement in a flat network.
If you're designing a domain to support remote offices that access your corporate network over slow links, such as ISDN or Switched-56 lines, install a BDC in each remote office (see fig. 16.14), especially if the office has more than one or two users that need to access domain resources. The BDC also provides file and printer sharing services for the remote office.
16.14
Installation of Backup Domain Controllers in remote offices.
The majority of traffic on Windows NT networks isn't authentication, domain synchronization, or name and browser requests, which occur relatively infrequently. File and print services provided to users probably account for 80 percent or more of network usage. Where the extra traffic related to authentication and synchronization becomes a problem is in remote offices with low-bandwidth links. Twenty percent more traffic can mean the difference between a reliable connection to the corporate LAN and many dropped packets.
Microsoft recommends the following amounts of RAM for PDCs running Windows NT Server 4.0:
Memory requirements increase if most of your BDCs also must perform other tasks, such as file and printer sharing, or application serving. Using the PDC and BDC(s) for ordinary network services is common in smaller networks serving 100 or fewer users. As the number of users increases, bursts of authentication and domain synchronization activity temporarily affect the performance of other services provided by PDCs and BDCs. Users may notice a significant performance drop in client/server applications, such as database front ends to SQL Server or the Exchange client for Exchange Server, during these bursts. Fortunately, it's relatively easy to add a new BDC to the domain to distribute the server load and to back up the existing BDC, in the event you must promote the existing BDC to a PDC. If you have multiple BDCs, consider demoting the BDC running server-based applications to a "plain" (non-domain) server.
You can use relatively low-cost configurations for added BDCs, because a second BDC doesn't need to have RAID drives or other high-end server features. (RAID for backing up a backup is overkill.) You can assign BDCs relatively low-priority tasks, such as printer sharing and fax server duties. Similarly, a low-end BDC is an ideal server for CD-ROM jukeboxes, because the data rate of even 8X CD-ROM drives (about 1,200kbps) is low compared with fixed-disk drives and the network's capacity.
If you support a large organization with multiple departments or divisions that want to manage their own resources, use Windows NT Server's trust relationships. A trust relationship connects two or more domains and lets users in one domain access resources in another domain. A single logon provides user access to domains having the appropriate trust relationship.
There's also a trust relationship between a client and the domain, and between domain controllers and the domain. When this trust relationship becomes corrupted-usually by problems with the domain SAM database-you're likely to receive a message indicating that the trust relationship between a client or a server and the domain has failed. Trust relationships between domain resources and their domain are different from the domain-to-domain trusts that are the subject of this section.
You often see domain diagrams depicting one-way or two-way trust relationships (with arrows pointing in one or two directions, respectively, between domains, as in fig. 16.15).
16.15
A diagrammatic view of one-way and two-way trusts.
Domains are described as either trusted by or trusting another domain. Resources in the trusting domain (also known as the resource domain) are accessed by user accounts residing in the trusted domain (also called the account domain). Figure 16.16 illustrates the one-way trust relationship between a trusted and a trusting domain.
16.16
A one-way relationship between trusted and trusting domains.
When discussing trusts, it's difficult to remember which domain is trusted and which is trusting. A good mnemonic is to picture the diagram of a one-way trust, indicated by an arrow pointing from one domain to the other. The trusting domain is at the base of the arrow and the trusted domain at the arrowhead.
A two-way trust between two domains, indicated by a two-headed arrow, permits users and groups in either domain to access resources in the other domain. In this case, the two domains are both trusted and trusting.
A trust lets an administrator in the resource domain assign, for example, file permissions to users or groups in the account domain from a file utility such as Explorer. A trust provides only the connectivity between two domains. You must explicitly grant access to resources in the trusting domain for users in the trusted (account) domain, in the same manner you grant access for users in their own domain.
Trusts allow you to distribute management of resources between multiple domains. For example, your IS department may want to manage creation of all user accounts and certain centralized server resources in the IS-MASTER domain, while providing users and administrators in the Accounting department the ability to manage resources in their own domain, called Accounting. A one-way trust relationship-with Accounting as the trusting domain and IS-MASTER as the trusted domain-accomplishes this objective. The accounting users log on to the IS-MASTER domain but are permitted to access and manage resources in Accounting by means of the trust relationship.
In most account-resource domain relationships, a Windows NT client's machine account is installed to the resource domain, not the account domain. This approach allows all workstation resources to be managed in the resource domain, while the user accounts that log on to the workstations are managed in the account domain. Managing of the account domain is simpler, because the domain contains only user and group accounts, plus the domain's servers.
Establishing trusts is a relatively simple process. By using the User Manager for Domains utility, you can create one- and two-way trusts between domains. As an administrator, you'll need to have access to a Windows NT Server Domain Controller in each domain that's part of the trust in order to establish the trust relationship.
Follow these steps to create a one-way trust relationship between the account and resource domains:
16.17
16.18Windows NT Server then attempts to contact the trusted domain in order to establish the trust. If the trust fails, refer to Chapter 15, "Troubleshooting Network Problems," for a discussion of troubleshooting trust problems.
See "Troubleshooting Trusts," (Ch 15)
If you're creating a two-way trust, repeat steps 1 through 5. However, starting on the resource domain, define the account domain as the trusting domain. Then from the resource domain, add the account domain to the resource domain's trusted domain list.
You can use the Domain Monitor utility of the Windows NT 4.0 Resource Kit to monitor the status of your trust relationships.
When the trust is established, you have access to users and groups in the account domain from any domain utility you run in the resource domain, such as Explorer, User Manager for Domains, or Print Manager.
As useful as trusts are, they have limitations. In Windows NT Server 3.51, a single domain could be trusted by only up to 128 trusting domains. In Windows NT Server 4.0, this number is much larger but still limited. There's also the issue of trying to manage large numbers of trusts. If you're supporting a large environment with many one-way or two-way trusts between domains, the complexities associated with setting up and maintaining a large number of trust relationships aren't trivial. Obviously, you must balance the benefits of providing resources anywhere to anyone against the complexity of the domain design required to provide these resources.
When you begin the design of your Windows NT network environment, you have a choice of four standard domain models to use for your organization, as well as hybrids of the standard models. Before you decide on a specific model, carefully analyze how the model matches the business methods of your organization. When you've installed a large network infrastructure, changing your domain design requires a major effort. Thus, careful up-front planning is a must.
If you must change your domain structure, it's much easier to build trust relationships between domains than take them away. In the latter case, you're likely to be forced to reinstall user accounts and groups, and reassign permissions to resources when you move account information from a resource domain into an account domain, as in the case of moving from a two-way trust environment to a one-way trust model.
The Single Domain model is the simplest. As its name implies, it involves only a single domain, which holds all account information and resources (see fig. 16.19). The Single Domain model doesn't use trust relationships, because there's only one domain.
16.19
The simple Single Domain model.
The Single Domain model is best suited for an organization with centralized administration, a homogeneous user population, and less than 5,000 users. Beyond 5,000 users, it makes sense to start breaking up domains into resource and account domains.
The Single Master model (see fig. 16.20) uses a single master account domain to provide user and group access to multiple resource domains. This model is best suited to an organization with centralized corporate support and a number of departmental or regional groups that want to manage their own resources.
16.20
The Single Master model, with multiple resource domains.
Users log on to the single account domain, so you need to provide account domain BDCs in close proximity to resource domains, especially if the resource domains are spread out across your network and across slow links. In the case where you have remote offices across slow links, and those offices are part of the resource domains, you must have a resource domain server and a BDC from the account domain in the remote office. If you don't have a local account domain BDC, users must authenticate across the slow link to the closest account domain BDC.
In any one-way trust model, users logging on to the account domain from clients in the resource domain are pass-through authenticated to the account domain. That is, the BDC or PDC that authenticates a resource domain workstation passes a user logon to a BDC or PDC in the account domain using the trust relationship.
The Multiple Master model is similar to the Single Master, but seeks to provide load-balancing of the Master account domain by providing for multiple account domains, which are two-way trusted with each other (see fig. 16.21). Users in one account domain can access resources of another account domain if the users have been granted permissions in the other account domain.
16.21
The Multiple Master model, with multiple account domains.
The Multiple Master is a good choice for large organizations, and organizations where either a centralized or decentralized support structure is used. The Multiple Master model lets you distribute responsibility for each account domain to a separate support organization, with each support organization administering its own set of resource domains.
A Complete Trust between multiple domains is one where all domains are two-way trusted with every other (see fig. 16.22). In the Complete Trust model, all users and groups potentially can access resources in every other domain. This model is best suited to a fully distributed support organization. The Complete Trust model also assumes that you have some level of trust in administrators from each domain, because they potentially have administrator access to all accounts and all resources in every domain.
16.22
The Complete Trust model implemented by a network of trusts.
Another advantage to the Complete Trust model is that users from one domain can log on to a workstation in any other domain and access their resources as though they were at their home workstation. This is valuable for organizations where employees frequently travel from office to office.
A disadvantage of the Complete Trust model, however, is that for each additional domain you add, you need to establish a two-way trust with every other domain. As you increase the number of two-way domains, the number of two-way trusts you manage quickly grows to unmanageable proportions.
In addition to the preceding four models, there's opportunity to combine two or more of the standard models to create a hybrid model that best fits your organization. For example, you might like the concept of the Multiple Master domain model, but you don't want the Master Account Domains to trust each other. Instead, you want to create a number of Single Master Domains, each with its own resource domains. You also want to give a subset of users in your organization, such as network administrators, access to all domains everywhere, as in the Complete Trust.
You can build a new Master Account Domain, called Shared, for users requiring cross-resource access (see fig. 16.23). In this case, all your existing resource domains also are trusting to the cross-resource domain. Users requiring cross-resource access log on to the Shared domain, and are granted access to as many resource domains as needed.
16.23
An example of a hybrid domain model.
There are many other options for domain models. The only caveat is that one-way trust relationships aren't transitive. That is, if DomainA resources are trusting DomainB users, and DomainB resources are trusting DomainC users, there's no relationship between DomainA resources and DomainC users (see fig. 16.24).
16.24
An example of one-way trusts that lack a transitive relationship.
The right design for your organization depends on the following factors:
In the real world, it's the "soft" needs, such as requirements of your end users and the role your support organization plays, that drives the domain design. You can develop creative strategies to accommodate limited bandwidth or large numbers of users, but if the environment can't be supported or doesn't provide the flexibility end users want or need, you may as well not even install the infrastructure. Given the nature of Windows NT domain designs and the difficulty of changing established domain models, it's important to choose the right domain model from the beginning.
If you have a decentralized but centrally coordinated support team with users whose needs are flexible, the Multiple Master model is the best choice, followed by the Complete Trust model. Some network administrators argue that the Complete Trust "leaves the barn door wide open," but if your support organization is disciplined and communicates well between support units, the complete trust model provides the maximum flexibility.
If your organization has centralized support but end users demand the flexibility to do what they want with their resources, either the Single Master or the Multiple Master model is a good choice. In a large organization with 5,000 or 10,000 users, make sure that you have a well-defined group in charge of user accounts and resource access. Otherwise, maintaining such a large SAM quickly becomes an overwhelming task.
The Windows NT Resource Kit includes a tool called Domain Planner that, while limited in its creativity, provides a mechanism for planning the actual details of your domain. The facility it provides lets you specify the number of users, locations, and support characteristics, and provides you with an inventory of domain controllers and servers needed for your environment.
Domain Planner is fairly simple in its methodology, applying one of the four domain models based on the information you provide. Domain Planner is a good first step toward understanding domain design and can help you create an effective domain plan for your environment.
The "Domain Planning for Your Enterprise" white paper, available from http://www.microsoft.com/ntserver/enter.htm, and the "Microsoft Windows NT Server Directory Services" white paper, available from http://www.microsoft.com/backoffice/techbriefs/tech5000.htm, are useful documents to aid the domain planning process.
After you install your domains and the trusts are in place, you must assign user and group accounts access to resources in your resource domains. As noted earlier in this chapter, creating a trust relationship in and of itself doesn't provide users with immediate access to resources. You must explicitly permit users or groups from the Account Domain access to the Resource Domain, using tools such as User Manager for Domains and Explorer. Generally, the best way to do this is by assigning permissions by groups. Chapter 12, "Managing User and Group Accounts," and Chapter 13, "Sharing and Securing Network Resources," discuss creating global groups and sharing resources with groups, respectively.
This chapter explained the concept of Windows NT domains, a logical grouping of servers, client workstation, users, and groups. The chapter also described the role of Primary and Backup Domain Controllers, and discussed how BDCs can help take the load off the PDC for authentication services. The BDC synchronizes with the PDC to keep the domain SAM database up-to-date on all domain controllers. The difficulties of moving and renaming domains was a major topic of this chapter.
The balance of the chapter dealt with trust relationships and domain models, including the differences between trusted account domains and trusting resource domains, and one-way and two-way trusts. Suggestions for criteria to apply when deciding on a Domain Model also were provided. The chapter concluded with a brief description of how to implement resource sharing after you establish a trust relationship between domains.
For further information about the topics covered in this chapter, see the following:
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
