Workgroups and Domains

Let's step back even farther in time to find out how earlier versions of Windows provided for authentication and access controls before the concept of the domain was created.

In many ways, a domain is similar to a Windows 3.1 workgroup, but with one major exception: The domain has a single, centralized security accounts manager (SAM) database that holds all security information for the domain. In a workgroup, each computer in the network has its own security database, and the user of that computer can set passwords on resources that the computer provides to the network. Whereas a domain provides for centralized administration of the network's resources and users, the workgroup provides a highly decentralized, peer-to-peer networking model.

The disadvantages to the workgroup method include not only the decentralized management functions, but also the ways in which the workgroup method impacts the end user. For example, to access a resource on another computer in a workgroup, the user needs to know the password associated with that share-level resource. Because a different person can potentially manage each computer or workstation, you often need to know as many different passwords as you have resources to which you need to connect. Keeping track of multiple passwords usually leads to lax security because you must write them all down so that you don't forget them.

In a domain the administrator is in charge of the security policy for the entire domain. Users need only a single username and password to log on to the network and access resources throughout the domain. There are limits, however, to what a single domain can do in a network. As the network grows in size, whether it is in users, resources, or geographical size, using a single security database can have some drawbacks. Specific computers are designated to be domain controllers. These computers are the repositories of the security database ”the SAM. This database contains data for four types of security objects, or accounts:

• User accounts

• Computer accounts

• Global group accounts

• Local group accounts

As you can see, in addition to keeping track of usernames, passwords, and other information about the users on the network, the SAM also keeps track of which computers have joined the domain and which user groups have been defined, along with the members of each group. Note that only Windows NT computers are tracked in the database. Users on other platforms, such as Windows 95/98/Me, can log on to a Windows NT domain, but their computers will not have computer accounts in the domain. Windows NT computers actually join the domain when the administrator creates a computer account for that workstation in the SAM.

The number of accounts that a single Windows NT 4.0 domain can accommodate, according to Microsoft figures, is around 40,000 due mostly to the maximum size to which the SAM database can grow. This figure can vary, depending on the information you store in the SAM. For example, you might have a lot of computer and user accounts but only a few trust relationships stored in the SAM. Or you might have a large number of trust relationships stored in the SAM, and this would mean you would have less room for computer and user accounts. You would need more than one domain for a larger network.

Note

There are actually two places where you can find the SAM for Windows NT. The domain controllers hold copies of the domain database, and this is used to validate domain logons and grant users the ability to access resources in the domain. However, any Windows NT Server or Windows NT Workstation computer that is not a domain controller also has its own local security database, much like a Windows for Workgroups computer. The local user can create individual user accounts on the local computer and can grant access to resources on the computer to these users. However, users who are validated by a computer's local database cannot use this logon to access domain resources, unless their username/password on the local computer matches one on the Windows NT computer, as long as the administrator creates an account on the Windows NT computer with the same name /password. This is called pass-through authentication . Additionally, when a Windows NT computer joins a domain, the domain administrator's global group is, by default, placed into the local domain administrator's group, giving the domain administrators the ability to control security functions on the local computer.

Of course, it will probably be a rare thing to find a domain that actually has 40,000 user or computer accounts. When a network grows this large, a solution needs to be found that provides a convenient method of managing users and controlling access to network resources.

The solution is to create multiple domains in the network and allow them to interact with each other so that users can access resources anywhere on the network, while still using only a single username and password to log on. In Windows NT this is done using a concept called a trust relationship between domains .

Interdomain Trust Relationships

To support the concept of one username and one password throughout a collection of domains, the trust relationship is used to allow domains to share information contained in the security database. Without a trust relationship you would have to create a new user account in the database of each domain to which a user would need to have access. This would be sort of like the workgroup model, only on a larger scale using domains instead of individual computers.

When a user account is created in a domain, it is assigned a unique identifier, called an SID , which stands for security identification descriptor . If you create several accounts in different domains for a user, with the same logon username and password, the SID will not be the same from one domain to another. The user's logon name is ordinary text, which is used for the convenience of humans who must remember it. The SID is the actual method that the network uses when identifying a particular user (and to identify the domain, which holds the user account) and deciphering what access that user is allowed, based on Access Control Lists (ACLs).

For more information on ACLs, see Chapter 43, "Rights and Permissions."

Because there should be only one username and password for any user throughout the network, no matter how many domains are created, a method is needed to allow a domain to recognize that a user has already been validated in another domain. If this can be communicated between domains, it becomes possible to simply trust a user if a domain trusts the domain from which the user comes.

A trust relationship is created when an administrator from one domain uses the User Manager for Domains utility to create a specific relationship with another domain. For example, if domain A has a trust relationship whereby it trusts the users in domain B, then the administrator of domain A can grant access to resources in domain A to users who reside in domain B. A trust relationship, however, is a one-way street. So this example does not give users in domain A access to resources in domain B.

Note

A trust relationship does not automatically give users in one domain access to resources in another domain. Just as users in a domain are granted access to resources by their domain administrators, users from trusted domains must be granted the necessary access rights and privileges in a trusting domain before they can access resources. The trust relationship that is set up between two domains is merely the prerequisite that allows users to be granted access to resources in another domain.

A trust relationship enables the Windows NT LSA (local security authority) to use pass-through authentication to validate a user. When a user from a trusted domain tries to access a resource, the netlogon service contacts the domain in which the user account resides to confirm that the user account is valid. The LSA receives copies of the user's SIDs (the account SID and the SIDs for any global groups of which the account is a member). After this pass-through authentication process, the LSA has all the information it needs in order to evaluate the user against the Access Control List entries that might be present in an ACL for a particular resource.

For users in both domains to have access to resources in both domains, the administrators of each domain must create two trust relationships.

Creating a Trust Relationship

The domain administrator uses the User Manager for Domains utility to create trust relationships. To start the utility, select Start, Programs, Administrative Tools, and finally User Manager for Domains. In Figure 40.1 you can see the utility as it looks when it is first started, showing a list of user accounts in the domain at the top and a list of user groups at the bottom.

Figure 40.1. The User Manager for Domains is used to create a trust relationship.

To create a trust relationship the administrator in both domains will have to run the utility and enter the other domain's name into the list of domains it trusts or is trusted by. To bring up the dialog box that is used to accomplish this task, select the Policies menu at the top of the utility and select Trust Relationships (see Figure 40.2).

Figure 40.2. The Trust Relationships dialog box is used to create a trust relationship with another domain.

The order in which a trust relationship is established is important. The administrator of the domain that will be trusted should run the utility first to add the name of the domain that will trust his domain. To do this, click the Add button next to the Trusting Domains list. The Add Trusted Domain dialog box appears. Here you enter the name of the domain that will trust your domain, and an optional password, and click OK.

The administrator of the domain that will trust this domain must perform the same function, this time clicking the Add button next to the Trusted Domains list. In the Add Trusted Domain dialog box, the administrator will put the name of the domain it will trust and then the same password that was entered by the administrator of the trusted domain.

Although the password is optional, you should always use one. The password is not used later by domain controllers that are performing pass-through authentication. It is used only to verify both ends of this process of creating the trust relationship. After the trust relationship has been established, the domain controllers will use SID information to validate each other.

After the trusting domain has entered the correct password, a message is displayed indicating that the trust relationship was set up. Each administrator then sees the other domain listed in the trusted or trusting section of the Trust Relationships dialog box. If you have a network that has multiple domains and a large number of administrators, from a security viewpoint, it is a good idea to regularly check this dialog box to be sure that the trusts you expect to exist are there and that no others have been added. Remember that a trust relationship gives a user with administrative privileges the capability to grant rights and privileges to users outside your domain. This is a very powerful capability.

Again, remember that each trust relationship under Windows NT 4.0 is unidirectional. If you want both domains to allow users from the other domain to access resources in each domain, you will have to repeat the process and create two trust relationships between the two domains.

When it becomes necessary to remove a trust relationship, all you have to do is select the domain from either the trusted or trusting domains lists in the dialog box and click the Remove button.

Domain Controllers

The domain controller is a computer that holds a copy of the SAM. Domain controllers authenticate users when they log on to the network. In Windows NT there are two kinds of domain controllers:

• Primary Domain Controller (PDC) ” This type of domain controller is where the master copy of the SAM resides for the domain. Updates to the SAM can be made only on the PDC, which then propagates the changes to the other domain controllers. Because there can be only one master copy of the domain's SAM, there can be only one PDC in any given domain.

• Backup Domain Controller (BDC) ” This domain controller holds a copy of the SAM and receives updates to this copy via replication from the PDC. A BDC can authenticate users, but changes to the SAM must be done on the PDC. Because the BDC holds a copy of the SAM, there can be multiple BDCs in the network. BDCs are usually used to offload processing from a busy PDC, provide quick network access to the SAM in network segments that are distanced from the PDC, or provide for fault-tolerance so that users can still log on to the network when the PDC becomes unavailable.

Only a Windows NT Server computer can be used to create a domain controller, and this must be done during the initial installation of the operating system. Without a complete reinstallation of the operating system, Windows NT Servers that are installed as ordinary "member servers" cannot be upgraded later to become a PDC. Nor can a domain controller be downgraded to a standard member server without a complete reinstall. Windows NT Workstation computers cannot be used as domain controllers in any fashion. However, a Windows NT Workstation has its own local SAM database that can be used to allow users to log on to the local workstation, but not the network. This can be useful in small networks in which a domain controller is not necessary. However, in such a situation, if a user needs to access resources on more than one workstation, the user must have a user account on each workstation to which it needs access.

Note

Windows 2000 Server does not use the concept of primary and backup domain controllers. Instead, all domain controllers are the same, and they exchange information among themselves . The way in which Windows 2000 enables you to "promote" a server to be a domain controller is discussed in Chapter 41.

All Windows NT computers that participate in a network run a service called the netlogon service. You can see it listed in the Services applet found in the Control Panel. This service is responsible for taking a user's logon request and communicating with a domain controller to process the logon. It also is the entity that handles synchronization between the PDC and the BDC copies of the SAM database.

Windows NT Domain Models

The single logon principle that is so important in Microsoft networking is enhanced by allowing domains to trust each other's user base by using trust relationships. However, in a network that contains a large number of domains, it is important to decide on a model to use when establishing trust relationships to make them easy to manage for the particular needs of your environment. Although it would be very easy to create trust relationships among all domains in a large network, that is not the way it's usually done. Instead, four basic models are often used:

• Single domain model

• Master domain model

• Multiple master domain model

• Complete trust domain

Deciding on which domain model to use depends on many factors, but the basic things to consider are the size of the network (in users) and the organization of the business, along with management and geographical factors.

The Single Domain Model

For a small organization that has a centralized management team for its network, a single domain might be sufficient. In this model, all the user accounts are created in a single domain, along with all the network resources, such as file and print services. There are no interdomain trust relationships to worry about because there is only one domain.

In this model there is only one PDC, but one or more BDCs are typically created for fault-tolerance purposes. If users are located at different sites geographically , you can use this model and put a BDC at each site to reduce network traffic associated with logons, allowing users to be validated by the local BDC. Having a BDC at each site also enables users to continue working if the network link between them and the site that has the PDC goes down.

The Master Domain Model

In a large enterprise it might be desirable to have one central database that contains all the user accounts, while maintaining other departmentalized databases that hold security information about resources in the network. In the master domain model one domain is designated to be the master domain, and all user accounts are created in this domain. Additional resource domains are then created, which do not have to contain any user accounts other than those used for the local administrators to manage resources. Because of the concept of trust relationships, you don't even have to create accounts for these administrators in their own domains. By using global and local groups, it is possible to give a user account from the master domain the capability to administer another domain by placing that user account in a special Domain Admins user group.

In the resource domains, file and print shares are created and can be managed locally in the resource domain by the domain's administrators. User accounts can be managed from a central location ”by administrators in the master domain. In this model each resource domain has a one-way trust relationship with the master domain whereby it trusts the users in the master domain, as shown in Figure 40.3.

Figure 40.3. Resource domains trust the users validated by the master domain in this model.

This type of domain model is ideal if you need a central place to manage user accounts but want to let local administrators take responsibility for managing resources in their area of the network. In a large company you might want the personnel or human resources department to be responsible for creating accounts for new employees and deleting accounts when users leave the company. The accounting department then can take charge of managing printers and other resources in their own domain, while those in charge of the warehouse can similarly be responsible for granting access to resources in their domain.

The Multiple Master Domain Model

The multiple master domain model is similar to the master domain model, but in this case there can be more than one master domain. Resource management is still decentralized by allowing resource domain administrators to control local resources, but instead of one master domain to hold all user accounts, there are several. In Figure 40.4 you can see an example of this model in which users in the United States are managed by one domain, while users in the United Kingdom are managed by a separate master domain.

Figure 40.4. In the multiple master domain model there can be more than one master domain to hold user accounts.

This model is the most scalable domain mode because you can just add another master domain if you need to add more users when the existing master domains become highly populated , or when a new geographical area is brought into the company. In fact, if you have a large network that already has more than 40,000 user accounts and you want some degree of centralized user administration, then the multiple master domain model is the best method to use. It provides for local administration of resources but also allows you to separate users into large administrative groups for management purposes.

In an enterprise that has a global network, this model can be used to allow large divisions of a company to control users located in their area. User account management is still centralized, but into several large groups that each division manages . If trust relationships are set up correctly, a user still needs only one logon to be granted access to resources that exist anywhere throughout a worldwide global network.

Another reason you might choose the multiple master domain model over the master domain model is to minimize network replication traffic. Remember that updates to the SAM are made to the database residing on the PDC, and are then sent to BDCs during the replication process. If you have a user base that experiences frequent changes, replication traffic on a global scale can consume valuable network bandwidth. By having several master domains, one for each location, you reduce the bandwidth consumption because replication occurs only within each domain.

The Complete Trust Model

This domain model provides for decentralized user account management and decentralized resource management. Each domain in the network has a two-way trust relationship with every other domain in the network, as shown in Figure 40.5. Administrators can still manage their own local resources but also can manage their own user database. This method requires good communication skills among domain administrators to make sure that users are properly granted access to the resources in other domains.

Figure 40.5. The complete trust model provides the highest degree of decentralized management in a large network.

Although this model has the greatest chance of causing confusion when one is trying to troubleshoot logon or resource access problems, it can be a good method to choose under some circumstances. For example, in the highly competitive business environment of the past decade , in which growth is achieved by acquisition, this model can be used to quickly join networks when companies merge. This assumes, of course, that both business entities are using a Microsoft Windows NT network.