Domains and Trust Relationships

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.