Domains and Trust Relationships

Use the correct domain model, and establish effective trusts

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 relationshippossibilities. Some administrators complain, perhaps unfairly, about thedifficulty 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 usefor administration and organization. Each domain has one NT server that acts asthe Primary Domain Controller (PDC). A domain can have one or more NT serversthat act as Backup Domain Controllers (BDCs). You use domains to validate usersand to control access to resources.

You can establish domains when you install NT on the PDC. NT generates adomain identifier (a security ID--SID) that identifies the domain on thenetwork. You must supply the domain name. You can change this name, but if youdo so, you must also change it on other network settings (e.g., securitysettings). Avoid underscores, dashes, and other nonalphanumeric characters indomain names. These characters might work in NT, but they cause problems inother applications, such as SQL Server, Exchange, and the Internet.

Network users log on to the NT domain, whether they are running NT, Windows95, or Windows for Workgroups (WFW). When you log on, the PDC or one of the BDCsvalidates your username and password. After initial logon, you should not needto supply a password to access domain resources.

Trust Relationships
In a trust relationship, users can log on to Domain A and then accessresources 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 otherdomains. 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: thesingle 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 andnetwork 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. Youneed 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 anothercompany. Each company has an accounts domain. You must maintain these separateaccounts domains until you consolidate them.

In the multiple master domain model, user accounts belong to masterdomains, and shared resources belong to resource domains. The IS administratorhandles the account domains, and the local administrators handle resourceaccess. You need to establish trust relationships so that the resource domainstrust each accounts domain.

The maximum number of trusts between accounts domains and resource domainsis the number of accounts domains (A) multiplied by the number ofresource domains (R): A * R. You might not need all thepossible trusts. For example, if two companies merge, users might not needaccess to all resources.

You can establish trusts between accounts domains to let administratorsadminister remote domains. The number of trust relationships between accountsdomains is A * (A - 1).

The maximum number of trust relationships required is (A * R)+ [A * (A - 1)]. The resource domains do not need to trustone another because they do not contain user accounts.

How you split accounts between the master accounts domains determines howmany trust relationships you truly need and how easily you can administer thedomains. You might arrange resource domains by function, such as Engineering,Production, Sales, and Human Resources (HR). You can then put Engineering andProduction users in one accounts domain (perhaps called Technical) and Sales andHR users in another accounts domain (perhaps called Support). The Engineeringand Production domains do not need a trust relationship with the Support domainif the technical users do not need access to Support resources. However, theSales staff probably needs access to Engineering and Production information, sothe Sales domain needs a trust relationship with the Technical domain. Tosimplify administration, establish only the necessary trust relationships.

One of the worst methods for splitting accounts between the master accountsdomains is by users' last names. If you divide your accounts by last name, youwill have to build trusts from each resource domain to each accounts domainbecause your user distribution is random. In addition, users' last names canchange, forcing you to move accounts.

The complete trust model. Figure 4 illustrates the completetrust model. This model often occurs by default when several departments migrateto NT at different times and then need access to one another's resources. Thedepartments build trust relationships as needed, and eventually everyone trustseveryone else.

Some administrators see the complete trust model as identifying a lack ofplanning or design. However, in some situations this model is deliberate and appropriate. For example, I encountered a situation in which various agencies forseveral counties in a metropolitan area established trusts to share data. Eachcounty agency's IS department maintained its domain (e.g., controlling useraccounts, performing backups). The trusts simply provided access to data. As Iexplained previously, establishing a trust relationship does not automaticallygive users rights in other domains. In this case, no cross-administrationoccurred between agencies.

One problem with the complete trust model is that no one is in charge. Abigger problem is the number of trusts. For N domains, you mustestablish N * (N - 1) trusts. For 100 domains, you would need9900 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 9accounts 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 domainmodel 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.