Some of the main topics in this chapter are
A medium-scale enterprise requires resource management beyond what the single domain structure provides but only requires a single SAM database. The range of users accommodated is from 500 to 15,000. There is considerable gray area on both ends of the range where the organization could adopt the methods of either a small- or large-scale enterprise.
The medium-scale enterprise is assumed to already have an organizational structure in place and adequate IT support staff to manage some complexity. The enterprise can be centralized or dispersed and can adopt any of the Windows NT domain models. This chapter details the single master domain model and the multiple master domain model, both of which are popular in medium-sized enterprises. Typically, smaller and simpler organizations adopt the single master domain model.
For the purposes of this discussion, a medium-scale enterprise is one in which a single domain model is no longer sufficient to supply either the validation load that NT services require, or the number of users in the organization. Because small-scale enterprises (described in Chapter 61) top off at 100 users for the single domain model, a medium-scale enterprise starts at 100 users at the low end. Realistically, there's a gray area between 100 and 500 users, which could be classified as either small or medium scale.
As an arbitrary upper level, this chapter considers that a medium-scale enterprise ends when it is no longer possible or convenient to maintain a single security database (SAM) in a master domain. The ultimate limit for that database is comfortably set at 40,000 users for Windows servers but is more typically in the range of 12,000-15,000 users.
Using Windows NT 4 and the latest generation of multiprocessor servers, an organization can push this limit for a single master domain up to as high as 70,000 user accounts. There is rarely little need to push the limits of what a single master domain is capable. Typically, the need to provide for organizational subdivision to enhance security and provide for multiple site location outweighs the need to grow a domain as large as possible.
This chapter examines the single master domain and multiple master domain models that are favored by medium-scale enterprises. The remaining domain model, the independent lines of business model is typically installed in larger organizations and is described in the next chapter.
All other domain models require the establishment of trust relationships. Trust relationships are one-way, allowing the trusted domain access to all the services and resources of the trusting domain. To establish a mutually trusting set of domains, you need to create two separate trust relationships. That way, a domain administrator retains control over access to his own domain. You establish trust relationships in the User Manager for Domains.
In a trust relationship, the two domains create a network link between them. Account information is shared, and a trusted domain can validate the services of its users so that they can have access to the services in the trusting domain. In a multidomain network, validation occurs in a single domain. The request for services accompanied by validation from the originating domain flows across the network. Multiple domains use trust relationships for the following reasons:
You can create 128 incoming trust relationships in a domain. There is no limit on outgoing trust relationships.
You can log on to a domain from any trusted domain in the enterprise, even if you don't have an account in the current domain. Verification uses a pass-through authentication. An access token is created at logon, and the user's SID is sent to the account domain (a trusted domain) where authentication is done. Pass-through authentication occurs not only for logon, but whenever a resource in the trusting domain is requested (both directions).
Two-way trust relationships are allowed in the directory structure allowed in NT 5 and are described in the last section of this chapter.
In a single master domain, one domain administers all other domains in the enterprise. The network administrator puts all user and computer accounts into the SAM of the master domain. Then other domains are populated with servers and clients to distribute network resources. The central administrative domain is called a first-tier domain, and the other domains are referred to as second-tier domains or resource domains.
Resource domains each contains a PDC (required by a domain by definition), BDCs, NDCs, and client computers, as well as network resources. What a resource domain doesn't have are user accounts. The resource domain manages machine accounts and any necessary global groups for the resources it contains.
Fast network connections in the single master domain are a critical performance factor. For WAN connections, you should install a BDC of the master domain locally to speed up authentication of resource requests. Because many WAN connections use TCP/IP as their protocol, adding a DHCP server, which automatically configures addressing, can speed up authentication.
The single master domain is made possible through the use of one-way trust relationships between the first-tier domain and the second-tier domains. The master domain is the trusted domain, and all other domains are trusting domains. Figure 62.1 shows the topology.
The single master domain topology is a good topology for a medium-scale enterprise that requires centalized administration capabilities.
Any organization that wants to establish central control or a single administrative unit will favor the single master domain model. The maximum size of this enterprise is about 26,000 users (the same as the single domain model). One advantage of this model is that resource management can be decentralized and handed off to local administrators, typically by functional unit or by department.
The single master domain model is noted for the flexibility that it allows an administrator. By centralizing user accounts in a single database on one domain, you eliminate the need to have duplicate accounts in the resource domains. Through the one-way trust relationships between resource domains and the master domain, you can consolidate administration of user and machine accounts. An administrator can also delegate resource domains to local administrators. Network users still only require a single logon to access a resource in any of the domains. To summarize, the single master domain model is best used when:
Note that this model doesn't support an unlimited number of second-tier domains. Creating too many second-tier domains will overwhelm your network with traffic. Therefore, it is wise to try and consolidate offices or departments into as few second domains as both geography and your network architecture support.
There is a serious downside to the single master domain. Your entire validation services depend on the master domain. So should the master domain fail, your entire enterprise is out of commission. Extra caution establishing fault tolerance is recommended. However, the failure of a non-critical resource domain leaves the remainder of the enterprise relatively unaffected.
It is typical to find a single master domain in a company with a central main office and branch offices. Often modem connections are used and a BDC for the master domain is placed in every branch. To be safe, many organizations put a second BDC in the branch for fault tolerance. The single master domain model is a popular topology for medium-sized organizations.
For a widely separated enterprise, it's worth giving some thought to the factors that influence account replication across a WAN or over a phone connection through RAS. When you first set up the domain structure, an entire SAM file might be required to be transferred from a PDC to a BDC. In Windows NT Server, every time 2,000 changes to users and groups occur in a database in less than an hour, the operating system requires that the entire domain SAM be fully synchronized with each BDC. This is a major network performance hit--especially painful over slow connections.
A WAN connection within a domain might be too slow even with T1, 56K, or ISDN lines for your purposes. So the installation of a high-speed backbone is a good investment in large enterprises.
Any WAN connection in a domain requires a local BDC. For slow WAN connections in a domain, enterprises may establish the security database on a BDC locally to the PDC and then ship the BDC overnight to its intended location to avoid fully replicating the SAM over WAN connections.
The worksheet in Table 62.1 lets you calculate the monthly replication time for your network.
| Events | Factors | Sizes |
| Password changes per month | Number of user accounts Password expires in how many calendar days Divide by 30 User account changes A * C |
A _____________ B _____________ C _____________ D _____________ |
| Additional changes per month | Number not known, use 5% of D New user accounts Group changes New machine accounts * .5 |
E _____________ F _____________ G _____________ H _____________ |
| Amount of data to be replicated per month Total monthly replication time | D - E + F + G line speed in bps | I ______________ |
| Total monthly replication time | Compute throughput: modem In KB, multiply by 1024 KB (i.e. 56 KB = 57344 bps) J1 * 8 (in bytes) J2 * 60 seconds/minute J3 * 60 minutes/hours = total throughput I/J = total replication time in hours/month |
III _____________ III _____________ III _____________ J ______________ K _____________ |
NOTE: If you see that a BDC is engaged in full synchronization often, then it is recommended that you raise the ChangeLogSize to a higher number. At a buffer size of 64K (the default), the ChangeLogSize accommodates 2,000 changes without requiring full synchronization. You can make that buffer larger.
The largest enterprises tend to install the multiple master domain model. In this model, two or more master domains provide account services. User and machine accounts are spread out across the master domains, and each is administered by the domain admins for that domain. Master domains are related to other master domains through two-way trust relationships, and thus behave as if they were almost a single domain. Creating this relationship slows down validation somewhat. This model does not need a central MIS department overseeing the multiple master domain, although this is often the case.
As in the single multiple domain model, the multiple master domain contains second-tier resource domains that provide network resources. Resource domains do not contain account information and are related through one-way trust relationships with the master domains as the trusting domains. Figure 62.2 shows you this topology.
The multiple master domain model enables a medium-scale enterprise to distribute its administration of resources among different groups, as well as geographically.
In a multiple master domain, you have a much greater theoretical limit. Any enterprise with greater than 40,000 users typically uses this model, and there are BackOffice installations of more than 100,000 users being installed in large corporations at the moment.
In a multiple master domain, when a resource domain goes offline, the rest of the network continues to function--minus those resources. When a master domain fails, only the group of users and machine accounts in that domain are removed from service. Both the single master and multiple master domain models benefit from the minimization of the number of resource domains and speedy interdomain connections. The advantages that the multiple master domain offers over a single master domain are:
You can calculate roughly the number of master domains required in a multiple master domain model by factoring in the number of accounts and groups that must be accommodated. Table 62.2 is a simple worksheet that determines the number of master domains.
| Purpose | Factors | Sizes |
| Calculate SAM database file size | Number of users * 1 KB | A _____________ |
| Number of machines * 0.5 KB | B _____________ | |
| Number of custom groups * 4 KB | C ______________ | |
| Built-in local groups (NT has 11 local groups) | D _________44 KB | |
| Total SAM size A + B - C + D | E ______________ | |
| Convert SAM size to M E * 0.001024 | F ___________M | |
| Minimum number of domains F / 40 | G ______________ |
© Copyright, Macmillan Computer Publishing. All rights reserved.