Last month, I discussed group strategies in Windows NT, and I explained how to use local and global groups in the NT domain model. This month, I discuss domains and trust relationships.
Microsoft has been criticized for the domain model, but this model works well in small and midsized organizations. The domain model has limitations in large organizations (more than 50,000 users), but Microsoft addresses these limitations in NT 5.0.
An enterprisewide domain structure can be one of four basic domain models, or some combination of those models, with various trust relationship possibilities. Some administrators complain, perhaps unfairly, about the difficulty of establishing and maintaining trust relationships between domains. The key to effective trust relationships is planning.
NT Domains
A domain is a group of users in a centralized accounts database that you use
for administration and organization. Each domain has one NT server that acts as
the Primary Domain Controller (PDC). A domain can have one or more NT servers
that act as Backup Domain Controllers (BDCs). You use domains to validate users
and to control access to resources.
You can establish domains when you install NT on the PDC. NT generates a domain identifier (a security ID--SID) that identifies the domain on the network. You must supply the domain name. You can change this name, but if you do so, you must also change it on other network settings (e.g., security settings). Avoid underscores, dashes, and other nonalphanumeric characters in domain names. These characters might work in NT, but they cause problems in other applications, such as SQL Server, Exchange, and the Internet.
Network users log on to the NT domain, whether they are running NT, Windows 95, or Windows for Workgroups (WFW). When you log on, the PDC or one of the BDCs validates your username and password. After initial logon, you should not need to supply a password to access domain resources.
Trust Relationships
In a trust relationship, users can log on to Domain A and then access
resources in Domain B without supplying a username and password a second time. Domain A is the trusted domain, and Domain B is the trusting domain. Domain B trusts Domain A that the user is legitimate. The converse is not true: Domain A does not trust Domain B unless you set up a reciprocal trust relationship.
A trust relationship does not automatically give users access to other domains. Trust relationships enable users from one domain to have permissions in another domain, at the administrator's discretion. A trust relationship must exist before an administrator can grant permissions for users from other domains to access resources in the trusting domain.
The Four Domain Models
Microsoft has four domain models that range from simple to complex: the
single domain model, the master domain model, the multiple master domain model, and the complete trust model. You can use a combination of these models.
The single domain model. The single domain model is simple to implement because it requires no trust relationships. Figure 1, page 206, illustrates the single domain model. Users and resources are in one domain, so assigning permissions is easy.
You might wonder why more organizations don't use the single domain model. This model comfortably supports as many as 10,000 users. I have heard of domains with as many as 40,000 users, which is too many to administer. Sometimes an administrator avoids the single domain model because of political reasons. For example, departments might have already set up independent domains. In addition, some departments might not be willing to work closely and share resources with other departments.
The master domain model. The master domain model is slightly more complex than the single domain model. Figure 2, page 206, illustrates the master domain model. User accounts belong to one domain--the master domain--and resources (e.g., files, folders, databases, printers) belong to resource domains. You must establish trust relationships so that the resource domains trust the accounts domain. The accounts domain does not need to trust the resource domains, and the resource domains do not need to trust each other.
Centralization of user accounts simplifies administration. Systems and network administrators, who typically belong to the IS group, decide who can log on and which groups a user belongs to. The local administrator on the resource domain controls the resources. Local resource managers trust the master domain to ensure that only authenticated users can access the network. If a new employee joins the company, the IS administrator adds the new user account and assigns the appropriate group memberships to grant resource access. If an employee leaves the company, the IS administrator removes the user account.
The resource domain contains only a few administrative user accounts. All other user accounts belong to the master domain. You can assign computer accounts to the master domain or a resource domain. NT computers have an entry in the accounts database, but other clients, such as Win95 computers, do not. If you consider computers to be departmental resources, you can put the computer accounts in a resource domain. Putting computer accounts in a resource domain reduces the size of the accounts domain, which might improve performance. (For information about determining the size of the accounts database, see "The Accounts Database," February 1997.)
The multiple master domain model. Figure 3 illustrates the multiple master domain model. This model is useful if the accounts database is too large for one server. The size of the accounts database for 1000 users is about 1MB. The accounts database needs to be in memory for users to log on with acceptable speed. Microsoft recommends memory equal to three times the size of the database (in addition to NT's memory requirements). Thus, a 20,000-user domain requires 96MB of RAM. You need to partition the accounts database before it gets too large. NT does not let you move users from one domain to another (although you can write script files to move users). You must delete users from one domain and add them to another domain. Therefore, the most efficient method is to split the accounts database across multiple domains when you create it. NT 5.0 lets you move users across domains.
You might have multiple master domains if your company merges with another company. Each company has an accounts domain. You must maintain these separate accounts domains until you consolidate them.
In the multiple master domain model, user accounts belong to master domains, and shared resources belong to resource domains. The IS administrator handles the account domains, and the local administrators handle resource access. You need to establish trust relationships so that the resource domains trust each accounts domain.
The maximum number of trusts between accounts domains and resource domains is the number of accounts domains (A) multiplied by the number of resource domains (R): A * R. You might not need all the possible trusts. For example, if two companies merge, users might not need access to all resources.
You can establish trusts between accounts domains to let administrators administer remote domains. The number of trust relationships between accounts domains is A * (A - 1).
The maximum number of trust relationships required is (A * R) + \[A * (A - 1)\]. The resource domains do not need to trust one another because they do not contain user accounts.
How you split accounts between the master accounts domains determines how many trust relationships you truly need and how easily you can administer the domains. You might arrange resource domains by function, such as Engineering, Production, Sales, and Human Resources (HR). You can then put Engineering and Production users in one accounts domain (perhaps called Technical) and Sales and HR users in another accounts domain (perhaps called Support). The Engineering and Production domains do not need a trust relationship with the Support domain if the technical users do not need access to Support resources. However, the Sales staff probably needs access to Engineering and Production information, so the Sales domain needs a trust relationship with the Technical domain. To simplify administration, establish only the necessary trust relationships.
One of the worst methods for splitting accounts between the master accounts domains is by users' last names. If you divide your accounts by last name, you will have to build trusts from each resource domain to each accounts domain because your user distribution is random. In addition, users' last names can change, forcing you to move accounts.
The complete trust model. Figure 4 illustrates the complete trust model. This model often occurs by default when several departments migrate to NT at different times and then need access to one another's resources. The departments build trust relationships as needed, and eventually everyone trusts everyone else.
Some administrators see the complete trust model as identifying a lack of planning or design. However, in some situations this model is deliberate and appropriate. For example, I encountered a situation in which various agencies for several counties in a metropolitan area established trusts to share data. Each county agency's IS department maintained its domain (e.g., controlling user accounts, performing backups). The trusts simply provided access to data. As I explained previously, establishing a trust relationship does not automatically give users rights in other domains. In this case, no cross-administration occurred between agencies.
One problem with the complete trust model is that no one is in charge. A bigger problem is the number of trusts. For N domains, you must establish N * (N - 1) trusts. For 100 domains, you would need 9900 trusts.
Setting Up Trust Relationships
A common misconception is that setting up trusts is a complicated,
time-consuming process. The largest domain model I have encountered has 9
accounts domains, 250 resource domains, and 250,000 users. Using the multiple master domain model, this company needs (9 * 250) + (9 * 8) trusts, for a total of 2322 trust relationships, which sounds like a lot of work. However, each resource domain administrator must set up only nine trusts. You can establish nine trust relationships, including phone calls and setup, in about 2 hours. Each accounts domain administrator has to configure 258 trusts, but this NT conversion will take about a year (260 working days). Thus, accounts domain administrators must establish an average of only one trust relationship per day. Maintaining user permissions across trusts is more time consuming than establishing the trusts.
NT 5.0 Domains
Rumors are flying about the domain model's future. In NT 5.0, the domain
model will be part of a new Directory Services package. Microsoft is enhancing and expanding the current domain models to become part of the NT 5.0 directory structure. Thus, domain work you do now will not be wasted effort.
