Single Domain Model

The single domain model, as shown in Figure 15.1, includes a primary domain controller and optionally, one or more backup domain controllers and servers. This model is the basis for all the other domain models. It is the simplest model Microsoft has to offer, and it can perform well for you if you meet the following criteria:

•  A small network with less than 300 users.

•  Less than 15 servers.

•  An administrative group, like an MIS department, that can administer the network.

•  Do not have a Wide Area Network (WAN).

Figure 15.1  The single domain model.

The preceding items are not hard-and-fast rules; rather, the list is based on my experience. You can play with the numbers for the maximum number of users and servers, as long as you keep in mind that the real issue is acceptable performance. If you have fast servers, single or dual CPU Pentiums for example, and a high performance backbone, 100MB/sec. fiber optics, for instance, you will not see the same performance limitation as a company with 80486-based servers on a 10Mb/sec. backbone.

The single domain model provides several benefits. It allows any network administrator to administer all the servers from any server or workstation on the network. Because only one user database contains all the user accounts (local and global groups), resource administration is completely centralized. There is only a single domain, so no trust relationships have to be created to access resources in other domains.

Of course, there are some limitations of the single domain model, as well. For instance, browsing for resources is based on the domain, and as the number of computers in your domain increases, performance problems might arise. As the number of users in your domain grows, so does the list you have to search through to find an individual user account. And as you make changes to your accounts, either by creating or modifying user accounts and groups, these changes have to be replicated to every backup domain controller on the network, which can eat up a lot of your network bandwidth. Finally, if your company has multiple departments that do not want you to administer their network, or have access to confidential files, you’ll have to split your domain and choose another domain model.

Master Domain Model

The master domain model, shown in Figure 15.2, includes a single master domain with one or more resource domain(s) that trust the master domain. The master domain contains all the user accounts and global groups. There are no user accounts or global groups defined in the resource domains. Because no user accounts exist on the resource domains, all logons and authentications are referred to the master domain.

Figure 15.2  The master domain model.

It follows then, that because all user logons and authentications are processed by the master domain, if the PDC fails, no users will be able to log on to the network or access shared resources. Of course, you can avoid this chaos if you include at least one BDC in the master domain.

The master domain model enables you to split your network based on departmental resource allocations without sacrificing centralized administration of your network. The master domain model is well-suited for organizations that have:

•  Less than 1,000 users.

•  Less than 50 servers.

•  An administrative group, like an MIS department, that can administer the network.

Notice, however, that while each resource domain trusts the master domain, they do not trust each other. This is because the user accounts and groups are defined in the master domain. Plus, each resource domain trusts the master domain, and a user or group can be granted access to the resource domain, so no additional trust relationships are required. One of the other interesting capabilities of this model is that the central administration group can be limited to just creating user accounts in the master domain. The resource domain administrators can then determine who will be granted access to the resources on their domain by creating global groups which include user accounts from the master domain.

There are a couple of downsides to this model, which you might want to keep in mind. For instance, a user list that includes 1,000 users can be pretty intimidating and can be slow to browse. And, replicating the entire user list to your backup controllers can generate enough network traffic to make your users scream (which is why I recommend that you do this after normal working hours). The limiting factor here is your network bandwidth and the speed of your servers. If your network bandwidth is insufficient to carry the user logon and authentication requests provided by your servers, or your servers cannot process the logon requests quickly enough, your network performance will suffer. Consider a resource domain situated on a WAN, for example. All user logons and authentications will have to travel across the slow WAN link to the master domain, even when they are accessing resources on servers in their local resource domain.