Understanding User Accounts, Groups, Domains, and Trust Relationships

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : April 1, 1998

This article is chapter 9 from the book titled "Inside Windows NT Server 4, Certified Administrator's Resource Edition."

Authors: Drew Heywood, Darin Camp, Michael Hayes, Howard Hilliker, Kathy Ivens, Brad McGehee, Barrie Sosinsky

Publisher: New Riders.

Contents: Organizing LAN Resources, Domains and Trust Relationships, Users and Groups, Built-In Groups and Users, What Happens When a Computer Joins a Domain, Testing Your Knowledge

If networks were always simple, if they never had more than a single server or a few users, they would be easy to administer and to use. All resources would be in one place, and all users would be local. There would be no confusion regarding where a resource was located or how to gain access.

Today, however, increasing numbers of networks are not simple. They incorporate multiple servers (file, print, fax, mail, and so on) and often span multiple locations. More often than not, servers will be storing many gigabytes of files. Clearly, expecting users to simply know where things are under those circumstances is not very realistic.

Network designers, therefore, have sought ways to simplify the location of network resources. This chapter introduces you to the technique chosen by the designers of Windows NT Server, which is based on domains and trust relationships. These building blocks enable you to build enterprise networks that are easy for you to manage and easy for your users to use.

On This Page

Organizing LAN Resources
Domains and Trust Relationships
Users and Groups
Built-In Groups and Users
What Happens When a Computer Joins a Domain
Testing Your Knowledge

Organizing LAN Resources

In Chapter 1, "Understanding Networks," you learned that LANs provide services in two ways: through peer-to-peer resource sharing or through central servers. Whichever method your network uses, the problem remains of enabling users to locate the resources that are available for use. This section surveys some of the following techniques that have been used for organizing network resources:

• Stand-alone services

• Directory services

• Workgroups

• Domains

Stand-Alone Services

The vast majority of early LANs incorporated only one server, so users had little difficulty locating files, printers, and other resources to be shared. NetWare 2.x and 3.x have long been the dominant network operating systems on small LANs, and statistics indicate that the average Novell 2.x and 3.x networks include a single server and 30 or fewer workstations.

With such an arrangement, there is little need for a sophisticated resource management service. Files can be found using DOS DIR commands, and printers can be selected easily from a list. In most cases, users' LAN environments are entirely pre-configured for them by the LAN administrator. Users are given access to specific printers, file access is preset, and users do not need a great deal of knowledge about the LAN to use it effectively.

Adding a second server can significantly complicate things, however. The problem arises because each stand-alone server maintains its own lists of users and resources. Figure 9.1 illustrates the problem. Server A is the host for applications such as WordPerfect and Lotus 1-2-3. Server B is the host for the company's e-mail, accounting applications, and sales database. Users who need to access the sales database and use the applications must be given accounts on both servers. Each of these user accounts must be created and maintained separately. Notice that some users have accounts on only one server. It is easy for servers to get out of synchronization when they must be updated manually.

The situation also complicates matters from the user's standpoint. The user must log on to and maintain a password on each server separately. This process can be automated, but it is a bit error-prone. Administrators of networks with several stand-alone servers are used to getting calls to re-synchronize user passwords among servers.

Two servers are about the most you would want to administer in this way, but even two servers can be too much. Assuming all users need to access all server resources, each user must be given an account on each server. It is easy to see how errors could occur in busy office environments where staff changes are frequent.

Users also have a problem with multiple stand-alone servers. To use a printer, the user must know which server hosts the printer. To access a file or program, the user must be aware of the server that maintains the file. Unless the user is given friendly tools for locating services, many of the network's capabilities will be difficult to access. The situation is much like trying to locate a plumber by using only the telephone directory's White Pages. Unless you already know the name of the plumber you want, finding one in your area of the city would be extremely difficult.

Given these limitations, LAN vendors have made considerable investments in making large LANs more manageable and usable. Two tools have come into use: directories and browseable services.

Directory Services

A network directory works much like a telephone directory's Yellow Pages. Resources can be grouped logically to make them easier to locate. Users can search the directory for the information they want, or they can browse the directory in a sensible fashion.

Directory services can be used to organize the resources on extremely large LANs. Several approaches are available:

• Banyan has long offered the StreetTalk directory service as part of its VINES network operating system. Banyan is now marketing StreetTalk as a directory service that can be used to integrate various network platforms.

• X.500 is an international standard for a directory service. It is not implemented currently in any LAN products.

• NetWare Directory Services (NDS) is incorporated into Novell's NetWare 4.x product line. NDS is based on X.500, but is not entirely compliant with the standard. At present, NDS can be used only with NetWare 4.x networks.

The concept of a directory service is attractive. Instead of logging on to several servers, a user now logs on to a network and is granted access to network resources by the directory service, regardless of which server is providing the service. The user sees a network directory with no indication of which server supports the user's account.

A directory service is an extremely formal way to organize network resources. Setting up such a service calls for careful planning that involves all departments in the organization. And directory services work best when one organization (such as a central MIS department) is responsible for maintaining the directory. Some directory services enable departments to have responsibility for portions of the directory, but one department must take primary responsibility. In organizations that do not have a central MIS department, it might be difficult to identify a primary directory manager.

In many organizations, LANs happened in departments long before they were discovered by the central MIS department. The departments that pioneered LANs often are reluctant to give up control and prefer to retain responsibility for managing their LAN resources. In Chapter 2, "Introducing Windows NT Server," you were cautioned that managing a LAN has political overtones. Setting up a directory service in a company that has well-established departmental networks can appear to threaten department autonomy and can run smack into those company politics. In most cases, users who are logged on to one directory structure cannot access resources that are controlled by another directory structure, making interdepartmental cooperation essential.

Directory services often add new complications as they solve old problems, and administrators of a directory need to be more skilled than administrators of stand-alone servers.

Almost any technology has up and down sides, and directory services are no exception. Although they can be very effective at organizing the resources of the largest LANs, directory services require skill and planning to administer correctly. They represent a formal approach to managing a network, and some organizations will take to directories more readily than others.

Workgroups

Workgroups are the conceptual opposites of directory services. Directories are formal and centrally administered; workgroups are informal and are operated by the users who are pooling their computing resources.

With a peer-to-peer approach to networking, users share the resources on their computers with other users. They might enable other users to print through their printers, access their files, or share a modem or CD-ROM. Individual users manage the sharing of resources on their PCs by determining what will be shared and who will be allowed access.

Peer-to-peer networking runs into two problems in large organizations:

• So many resources are available that users might have trouble locating them.

• Users who want to share resources often need an easy method of sharing resources with only a limited group of coworkers.

Microsoft introduced the metaphor of workgroup computing with the Windows for Workgroups (WfW) product. WfW enables users to share their workstation resources in a peer-to-peer mode, and workgroups make it easy to establish groups of related workers who easily can view and share each other's resources.

After someone joins a workgroup, he or she has access to all resources that are shared in that workgroup. You can share your hard drive with your coworkers simply by giving their workgroup rights to your printer. Figure 9.2 shows the Windows for Workgroups form that is used to share a printer.

Notice that the window in figure 9.2 enables the printer owner to assign a password that can be used to restrict access to specific individuals. Without a password, any member of the workgroup can use the printer. This is the only security provided by Windows for Workgroups.

To locate resources on a network, Microsoft uses a browsing service. Under Windows NT 4 or Windows 95, the Network Neighborhood or the Windows Explorer can be used to browse the network and identify resources to connect to. In figure 9.3, a user is browsing in the Network Neighborhood for sharable directories. Three such directories have been established on the workstation named Harold. Also shown is the Printers window which advertises a printer that is being shared by Harold.

Workgroups are more a convenience than anything else. They make resource sharing more efficient, but they do not organize services into a directory. They also do not make it easy to manage the shared resources in an efficient manner. Passwords can be used to restrict access to resources, but with one password for each resource, passwords proliferate rapidly. To change a password, everyone who uses the resource must be notified. If each resource has a different password, things get really complicated. It is difficult to maintain much security under those circumstances.

Figure 9.4 illustrates some of the problems with passwords in workgroups. When separate passwords are assigned by individual users, the number of passwords a user must remember can multiply rapidly. To make things easier, users tend to select passwords that are easy to remember, but such passwords also tend to be ones that are easy to guess.

To make matters worse, imagine that the network has dial-up capability, and that an employee has just left to work for your biggest competitor. You want to change all the passwords so that the employee cannot call in and get to your data. Obviously, changing all those passwords and informing everyone of the changes is going to be a big hassle.

The following Microsoft products can share their resources in workgroups:

• Windows for Workgroups

• Windows 95

• Windows NT Workstation

• Windows NT Server

• MS-DOS with the Workgroup add-on feature

These Microsoft products enable workstations to access workgroup resources:

• Windows 3.x with the Workgroup Connection

• MS-DOS with the Workgroup Connection feature

• LAN Manager for MS-DOS Enhanced and Basic Clients (not covered in this book)

• LAN Manager for MS OS/2 Client (Since this client has not been updated for the most recent versions of OS/2, it is not covered in this book.)

Organizations that are large or that want more control over their networks need something more than workgroups. Therefore, Microsoft has incorporated the domain concept into Windows NT Server.

Domains

Domains borrow concepts from workgroups and from directory services. Like workgroups, domains can be fairly informal and can be administered using a mix of central and local controls. Domains can evolve fairly easily and can be set up with less planning than typically is required for a directory.

Like a directory, a domain organizes the resources of several servers into one administrative structure. Users are given logon privileges to a domain rather than to each individual server. Because a domain controls the resources of several servers, it is easier to administer than a network with many stand-alone servers.

Servers within the domain advertise their services to users. Users who log on to a domain gain access to all resources in the domain for which they have been granted access. They can browse the resources in a domain much as they would browse the resources in a workgroup; however, domains are hosted by Windows NT Servers and can be made more secure than workgroups.

When networks become large enough to require several domains, administrators can establish trust relationships among domains. Trust relationships simplify administration because a user is required to have an account in only one domain. Other domains that trust the user's logon domain can rely on the logon domain to authenticate the user's logon.

Windows NT Server domains are not the same as domains found on TCP/IP networks. TCP/IP domains are discussed in Chapter 16, "Using TCP/IP."

Domains and Trust Relationships

Domains are essentially improved workgroups. Access to domain resources is controlled by a domain controller. The user is assigned a single domain account and a password that is used to control access to all domain resources. Windows NT Server domains also support the use of groups that enable administrators to assign and change permissions for large numbers of users more efficiently. You will learn about managing users and groups in Chapter 11, "Managing Users and Groups."

Domains and Domain Servers

A server in a domain has one of three roles:

• One Windows NT Server stores the master copy of the domain's user and group database. The PDC is responsible for synchronizing the account database with all BDCs.

• Other Windows NT Servers can store backup copies of the domain's user and group database.

• Servers can participate in a domain without being designated as primary or backup domain controllers.

Each of these roles is described more fully in the following sections.

The Primary Domain Controller

The first Windows NT Server in the domain is configured as a primary domain controller (PDC). The User Manager for Domains utility is used to maintain user and group information for the domain. This information is stored in a domain security database on the primary domain controller.

Backup Domain Controllers

Other Windows NT Servers in the domain can serve as backup domain controllers (BDC). Each backup domain controller stores a replica of the database on the primary domain controller, which is replicated periodically to distribute changes made to the main database on the PDC. Replication of the database has several advantages.

If the primary domain controller experiences a hardware failure, one of the backup domain controllers can be promoted to the primary role. Having one or more backup domain controllers builds a degree of fault tolerance into your network. Each domain should have at least one BDC.

Backup domain controllers also can participate in the logon process. When a user logs on to a domain, the logon request can be handled by any primary or backup domain controller. This spreads the logon processing load across the available servers and improves logon performance. This can be an important benefit in domains with large numbers of users.

Changes cannot be made to the domain database unless the PDC is functioning. If the PDC fails or is shut down for maintenance, you can promote a BDC to function as the PDC.

Although the PDC is required to make changes to the domain database, other domain operations are not dependent on the PDC. Users can log on to the domain using a BDC if the PDC is unavailable.

Servers

Computers running Windows NT Server can also function as independent or stand-alone servers, which may or may not participate in domains. The term servers represents member server or stand-alone server. These servers do not function as primary or backup domain controllers. They can take advantage of the user and group databases, however, that are maintained for a domain, and you can assign user and group permissions for the server using the User Manager for Domains.

The server also can maintain its own database of users, and users can log on to the server independently of the domain. When this is done, the server cannot utilize the user and group database of a domain, and the server handles accounts much like computers running Windows NT Workstation.

You might choose to configure a stand-alone Windows NT Member Server for several reasons:

• The server can be administered by different staff members. Many Windows NT Servers are used for application servers, such as SQL databases. If you configure a database server as an independent server, you can assign a member of your database staff as the server administrator.

• Attending to logon requests can use a significant part of a server's processing capability. If you configure the server as an independent server, it can concentrate on servicing a single function, such as providing application services.

• When a server is functioning as a primary or backup domain controller, it is difficult to move the server to a new domain. If there is a chance the server will move to a different domain, configure it as an independent server.

Synchronizing the Domain Directory Database

All changes to the domain directory database are first made on the PDC, after which they are distributed to the BDCs in a process called synchronization. Changes made to the PDC database—consisting of password changes, new and modified user and group accounts, and changes in rights assignments—are recorded in a change log on the PDC. When a BDC requests a database update, the changes that took place since the last update are copied to the BDC's database. An update that consists only of recent changes is a partial synchronization.

The PDC change database has a limited capacity. It operates as a circular buffer, meaning that older changes will be purged to make room for new changes. Consequently, a BDC that is off-line for a lengthy period of time may have missed changes that have been purged from the change database. Under these circumstances, it is necessary to perform a full synchronization in which the BDC receives a complete copy of the domain directory database from the PDC.

The NetLogon service is tasked with synchronizing the domain database. By default, the NetLogon service synchronizes BDCs at five minute intervals, which is usually adequate given the default capacity of the change database to store approximately 2,000 changes. If changes are being lost, it becomes necessary to increase the frequency of synchronization events or the size of the change log, both of which are determined by settings in the Registry.

When BDCs are separated from the PDC by a slow WAN link, full synchronization is undesirable. In such situations, you may want to increase the size of the change log and reduce the synchronization frequency to reduce WAN traffic, even to the point of scheduling partial synchronization to take place at night.

Chapter 10, "Managing Domains and Trust Relationships," describes several Registry parameters that control operation of the directory synchronization process. See the section, "Configuring Domain Synchronization," in that chapter.

Trust Relationships

Many organizations own several LAN servers—this is fine because domains make multiple servers easy to administer. There are several reasons an organization might need to establish two or more domains; for example:

• If too many servers are put in a domain, performance can suffer.

• For best performance, the domain database should be restricted in size to 40 MB, limiting the numbers of workstations, users, and groups that can be defined in a given domain.

• Some departments prefer to manage their own resources, which is easiest if they have their own domains.

So your organization decides to have several domains. If a user needs to access resources in several domains, is it necessary to create an account for that user in each domain? That could be just as bad as administering several stand-alone servers.

Fortunately, Windows NT Server enables you to establish trust relationships between domains. Figure 9.5 illustrates a simple, two-domain trust relationship. Domain B is configured to trust Domain A. As a result, if a user is successful at logging on to Domain A, Domain B assumes that the user has been authenticated properly. Therefore, Domain B accepts the user without forcing the user to explicitly log on to Domain B.

Trusts can flow both ways. In figure 9.6, Domains C and D are configured to trust each other. You will see several examples of network designs that use two-way trust relationships.

One more thing you should know about trust relationships is that trust does not flow through a domain. (Microsoft's term is that trusts are not transitive.) The top portion of figure 9.7 shows three domains that have established two-way trust relationships. Domains E and F trust one another, as do domains F and G. Domains E and G, however, do not trust each other because trusts do not pass through Domain F.

If all domains are to trust each other, it is necessary to establish trust relationships between each pair of domains. The bottom half of figure 9.7 shows how three domains can be made to trust each other.

Trust relationships do not automatically grant users access to resources in a trusting domain. A domain that trusts another domain relies on the trusted domain to authenticate users when they log on. The trusting domain still must grant those users access to resources.

Domain Models

Proper use of trust relationships enables organizations to build enterprise networks that still require only a single logon procedure for resource access. Microsoft has defined four models for domain trust relationships. If you are configuring a multi-domain network, you will want to consider the merits and disadvantages of each model.

There are two reasons for adding domains:

• For organizational reasons

• To improve network performance

Regarding network performance, you will find that Microsoft's descriptions are a bit vague. You can use a single domain model, for example, "if your network doesn't have too many users..." That doesn't give you much help during the planning stages. Unfortunately, there are many variables, and it is difficult to come up with a simple prescription for adding domains. Windows NT Server can, after all, run on everything from an Intel 80486 PC to a multiprocessor RISC system. Such a broad range of hardware makes performance generalizations difficult. Fortunately, Windows NT Server domains make it easy to reorganize the LAN as it grows.

The four domain models defined by Microsoft follow:

• Single domain

• Master domain

• Multiple-master domains

• Complete trust

Each domain is discussed in the following sections.

The Single Domain Model

Figure 9.8 illustrates the single domain model—the preferred model for small organizations. (Remember, size descriptions are very vague. More powerful servers enable a single domain to grow in size.) When all servers are located in a single domain, administration is simplified greatly. Also, there is no need to administer trust relationships—an activity that can get quite involved.

Large amounts of logon or browsing activity might degrade the performance of the domain. When a domain has a large number of servers, browsing can be inefficient, and you might find it advantageous to move some of the servers to another domain. Be alert to performance issues so that you can anticipate when you need to move to a different domain model.

A single domain network has several advantages:

• It is easier to manage because resources are centralized.

• No trust relationships are required.

• Group definitions are simpler.

You need to consider a multi-domain model in the following situations:

• If browsing is slow

• If too many users are degrading performance

• If your organization wants to assign domains to departments

• If you want to have some resources in their own domains

The Master Domain Model

The master domain model designates one domain to manage all user accounts. The master domain also supports global groups*. Global groups* can export group information to other domains. By defining global groups in the master domain, other domains can import the group information easily.

Figure 9.9 illustrates a network based on a master domain model. The master domain is named Keystone, and is managed centrally by the MIS staff. All users are defined in Keystone, as well as some groups that will make administration easier. Only the primary and backup domain controllers in the Keystone domain are used to store user and group account information. Because users cannot log on to the network without a working domain account database, a master domain always should include at least one backup domain controller in addition to the primary domain controller.

When users log on to the network, they always log on to the Keystone master domain. After they have logged on, they can access resources in other domains that trust Keystone.

In this example, the other domains are organized according to departments. After a user logs on through the master domain, most of the user's network activity relates to one of the department domains. Therefore, user network activity is distributed across several domains, removing much of the processing responsibility from the Keystone domain.

Each of the department domains is configured to trust Keystone. The assumption is that Keystone security will be sufficiently tight, and that other domains do not need to take special precautions of their own.

The department domains could be administered by MIS or by the individual departments. The master domain model makes it possible to delegate some management tasks while keeping the critical security function under the control of a central network authority. So that department domains are comfortable with the network security, administrators of the master domain should be well trained and security policies carefully defined.

A master domain network has several advantages:

• Security management is centralized.

• Non-master domains can be used to organize resources logically.

• Browsing activity is distributed through the department domains.

• Global groups in the master domain enable departments to easily establish local permissions.

• Departments that want to can manage the resources in their own domains.

The chief liability of the master domain model is that all logon activity takes place in a single domain. When performance begins to suffer in the master domain, you need to be prepared to move to a multiple master domain model.

Groups are essential ingredients of effective Windows NT Server management. Groups enable you to manage the privileges of large numbers of users more efficiently than would be possible if privileges were assigned to users individually.

Windows NT Server uses two types of groups: local and global. It can be difficult to grasp the differences between these group types and the appropriate uses of each. Consequently, this section does not dwell on that topic. Later in this chapter, the sections "Global Groups" and "Local Groups" investigate Windows NT Server groups thoroughly.

Because all accounts are concentrated in the master domain, a network designed with a single master domain is limited in scope by the size of the master domain's database. Typically, a master domain network will be limited to about 26,000 users and computers.

Although the master domain approach does not permit the network to support more users, it should result in performance improvements. After users have logged onto the network, their activities will be distributed across the department domains. There is less contention for network and server resources, and users should experience a performance improvement.

The Multiple Master Domain Model

The master domain model can be extended by introducing additional master domains. This is the primary technique used to scale Windows NT Server networks for larger enterprises. Figure 9.10 shows networks with two master domains and three department domains.

Each master domain supports about half the user accounts. This spreads the processing of logons over several domains. Each domain supports some of the groups that are accessed by the department domains.

Under this model, each master domain trusts every other master domain. This is a convenience for administrators, but is necessary for users only if they actually will be using resources on one of the master domains, which is not ordinarily the case. To reduce the likelihood of security holes, only administrators should be given permissions to access resources in the master domains. Users should be given permissions only in the department domains.

Each department domain trusts each master domain. It is not necessary for department domains to trust each other.

Because users are granted most privileges based on their memberships in master domain groups, it is a good idea to group related users into the same master domains. All your users in Accounting should log on to the same master domain, for example. Otherwise, you are forced to establish similar groups in each master domain. With more groups, it becomes far more difficult to establish privileges in the department domains.

The required number of trust relationships increases rapidly as you add domains. Figure 9.11 illustrates a network with three master domains and four department domains. The network in figure 9.10 required eight trust relationships. (Two trust relationships are required to enable the two master domains to trust one another.) The slightly larger network in figure 9.11 requires 18 relationships! Obviously, you do not want to expand the number of domains in your network unnecessarily.

The multiple master domain model has many desirable features:

• It is scalable to any organizational size.

• Security is managed centrally.

• Departments can manage their local domains, if desired.

• Related users, groups, and resources can be grouped logically into domains.

Disadvantages of the multiple master domain model include the following characteristics:

• The number of groups and trust relationships multiply rapidly as the number of domains increases.

• User accounts and groups are not located in a single location, complicating network documentation.

Theoretically, a multiple master domain network can grow to any size. Each master domain can support up to about 26,000 users and computers, and many master domains can be added. Because administration grows more complicated with each added master domain, however, it eventually becomes impractical to add more master domains to a network. It is probable, however, that few organizations will be faced with the limits. It is certainly practical to manage a network with three master domains, which can theoretically support 78,000 users. Is your network that large?

The Complete Trust Model

The master domain models assume that a central department exists that can take responsibility for managing user and group security for the complete organization.

If no such department exists, or if departments want to retain full responsibility for managing their own domains, you might choose to implement a complete trust model. An example of a complete trust network is shown in figure 9.12.

In the complete trust model, every domain is configured to trust every other domain. Users log in to their department domains and then access resources in other departments by means of trust relationships.

As with the multiple master domain model, the number of trust relationships required increases rapidly as domains increase. Three domains require six trust relationships (two between each pair of domains), whereas five domains require 20 trust relationships. If n is the number of domains, then the network requires n [infin](n–1) trust relationships.

As a believer in tight network security, I find the implications of the complete trust model extremely disturbing. The administrators of each domain must have complete faith that the administrators of every other domain will maintain a high level of security. For me, that is carrying trust a little too far.

In fact, Microsoft itself has backed off from an endorsement of the complete trust model, and recommends a multiple master domain model for large installations. Although the complete trust model was featured prominently in the documentation for earlier versions of Windows NT Server, coverage is omitted from the Concepts and Planning manual for Windows NT Server 4.

If your organization does not have a central MIS department, networking is a great reason for establishing one. Besides the need to maintain tight security, several other functions are best when centralized. Here are some examples:

• File backup

• Communications services

• E-mail maintenance

• Management of the network infrastructure (media, hubs, and so on)

Few departments have personnel who possess the expertise to do these jobs well. Also, network management in a large organization calls for personnel who are devoted completely to the task.

Therefore, I don't put much credibility into the advantages that Microsoft attributes to the complete trust model, but here they are nevertheless:

• No central MIS department is required.

• The model scales to any organizational size.

• Departments retain control of their users and resources. (But, it can be argued, they surrender that control by trusting everybody.)

• Users and resources are grouped logically by departments.

A few of the disadvantages of the complete trust model follow:

• Central security control is lacking.

• Large numbers of trust relationships are required.

• Departments are dependent on the management practices of other departments.

Estimating Domain Capacity

The big question when planning a domain-based network is, "What is the recommended maximum size for a domain?" This turns out to be a fairly complex question that is affected by the numbers of user, computer, and group accounts. It is also affected by the processing horsepower of the computers that are assigned as domain controllers. All the issues come down to the size of the file that is used to store the Security Accounts Manager (SAM) domain database.

The size of the SAM database file matters because the entire database is made resident in a domain controller's RAM. Large SAM databases have two effects: they hog a lot of the domain controller's RAM, and they take a long time to load, prolonging the process of booting the computer.

Three types of objects are stored in the SAM domain database:

• User accounts use 1,024 bytes (1 KB) each.

• Computer accounts use 512 bytes (0.5 KB) each (only Windows NT computers require computer accounts).

• Global group accounts use 512 bytes plus 12 bytes per users.

• Local group accounts use 512 bytes plus 36 bytes per user.

Assume that you have 1,000 users and 500 NT computers that require accounts. To organize the domain, you require 10 global groups with an average membership of 200 users. You also require 10 local groups with an average membership of 20. How large a SAM database would that generate?

1,000 users [infin] 1,024 bytes=1,024,000 bytes

512 computer accounts [infin] 512 bytes=262,144 bytes

10 global groups [infin] 512 bytes=5,120 bytes

2,000 global group members [infin] 12 bytes=24,000 bytes

10 local groups [infin] 512 bytes=5,120 bytes

200 local group members [infin] 36 bytes=7,200 bytes

Total SAM database size=1,324,589 bytes

The total size of the SAM database would be approximately 1.5 MB. That's not particularly large as SAM databases go, and you can easily support this network in a single domain.

Depending on its processing power and on the services it provides, a domain controller can support between 2,000 and 5,000 users. A domain with 26,000 users, therefore, might require from 6 to 13 domain controllers to ensure adequate performance.

These two factors (the maximum size of the domain database and the number of users a given domain controller can support) suggest some situations that might make it desirable to design a multi-domain network.

Microsoft recommends that a SAM domain database file not exceed a size of 40 MB. Above this limit, performance is likely to be unacceptable. Of course, performance depends on the power of the computers that are functioning as domain controllers, and less powerful servers will probably require you to further limit the size of the domain database. Regardless of the server platform, however, it is unlikely that you will want the database size to exceed 40 MB.

How large is a 40 MB SAM database? It will accommodate approximately 26,000 users, 26,000 workstations, and 250 group accounts.

A 40 MB SAM database is practical only on high-performance hardware. Table 9.1 offers some suggestions on the hardware required to support SAM files of varying sizes.

Table 9.1

Selecting Domain Controller Hardware

Users	SAM Size	Minimum CPU	Minimum RAM
7,500	<10 MB	486DX/66	32 MB
10,000	<15 MB	Pentium or RISC	48 MB
15,000	<20 MB	Pentium or RISC	64 MB
30,000	<30 MB	Pentium or RISC	128 MB
15,000	<20 MB	Pentium or RISC	166 MB

If the SAM database for your planned domain exceeds the recommended capacity for your hardware, you should partition your network into two or more domains.

Domains and Workgroups

Microsoft has designed its network products so that users and network administrators can use a mix of peer-to-peer and centralized services. Users can participate in a workgroup at the same time they are logged on to a Windows NT Server domain. This capability enables you to mix formal and informal network services to meet the needs of your users. It also enables you to manage some resources centrally, while other resources are shared under user control.

Mixing workgroup and domain models can complicate your life as a LAN administrator, however. When a user reports a problem, it might be unclear whether the problem is related to the Windows NT Server network or to the user's workgroup. My recommendation is that you use a centralized approach whenever possible.

Files can always be shared simply by placing them on a network server. Although Windows for Workgroups users cannot share their printers with a Windows NT Server network (except through peer-to-peer resource sharing in a workgroup environment), users of Windows NT Workstation can configure their workstations as network print servers, enabling them to share their printers as domain resources. Thus, most of the resource sharing that is made possible by workgroups also is possible under domain management. Windows NT Server domains are, however, much easier to manage and troubleshoot.

If the data is important enough to share, it is important enough to protect. The best place to protect your data is on a Windows NT Server computer where it can be properly secured and backed up. In my opinion, workgroup computing has no place where important data is being exchanged.

Users and Groups

Windows NT Server security is based on the following four types of entities:

• Global user accounts. User accounts that originate in the Windows NT environment.

• Local user accounts. User accounts that originate in server environments other than Windows NT.

• Global groups. Used to manage groups in a domain. Also can be used to export groups of users to other domains.

• Local groups. Used to manage users and to import global groups from other domains.

These entities are discussed in detail in the following sections.

User and group account information is stored in the domain database, which is maintained by the PDC. Each user and group account is identified by a security identifier (SID). The SID is a number that is generated by Windows NT when the account is created. The following is an example of a SID:

S-1-5-21-2087915065-398913830-1877560073-500

The SID is the actual identifier of the user or group, not the name that is designated by the administrator. When a user is given permission to access an object such as a printer or a file, the user's SID is recorded in an access control list (ACL) associated with the object.

Consequently, it is not possible to recreate a user or group account once it has been deleted. Even though the recreated account can be given the same name, it will be assigned a different SID which will not be recognized by any references to the old account in the domain database.

When a user logs on to a domain, the WinLogon service generates an access token that determines which resources the user is permitted to access. The access token includes the following information:

· The user's SID

· Group IDs of groups to which the user belongs

· Privileges assigned to the user account

When a user attempts to access a network object, Windows NT compares the SID in the user's access token with the ACL for the object. If the SID appears in the ACL, the user is given permissions to the object as described in the ACL.

Global User Accounts

In Windows NT Server terminology, a global entity can be used by domains other than the domain in which the entity was created.

User accounts that are created on Windows NT Servers have a globalscope—they can be used in any domain that trusts the domain in which the user account was created.

User accounts can be granted network privileges individually. It is more common, however, to include user accounts in groups and to grant privileges to the groups. This method makes it easier to alter the privileges of large numbers of users.

Because multi-domain Windows NT Server networks rely heavily on trust relationships, it is easy to see why global user accounts are desirable. A domain that trusts another domain can make use of any global user accounts that have been created in the trusted domain. This fact makes it unnecessary to give a user an account in more than one domain on the network.

Because global user accounts are the most common account types in Windows NT Networks, they simply are called user accounts in most situations.

Local User Accounts

When a user account originates on a network not running Windows NT, the account is a local account. Local entities cannot be used outside the domains in which they are created. Local user accounts can be placed in both global and local groups, however.

Local user accounts enable users from LAN Manager, IBM LAN Server, or NetWare environments to participate in Windows NT Server domains. Because they can be used only in the domains in which they are created, however, local user accounts are somewhat more difficult to administer than global user accounts.

Global Groups

Global groups are lists of user accounts from within a single domain. A global group can include user accounts only from the domain in which the global group was created. Global groups cannot contain other groups.

A global group created within one domain can be granted permissions in another domain. Figure 9.13 illustrates a two-domain network. The domain Keystone is used by all users to log on to the network. In Keystone, the administrator has created a global group named Domain Users. Users SLaurel, HLloyd, MNormand, and CChaplin have been established as members of Domain Users.

When Windows NT Server utilities reference the names of global groups, they frequently include the name of the domain in which the group was created. In the figure, the full name of the Domain Users group would be Keystone\Domain Users because the group is created in the Keystone domain. This notation is commonly used to describe a group in a domain other than the current domain.

The domain named Widgets trusts Keystone. This enables the Widgets administrator to assign permissions in the Widgets domain to the Keystone\Domain Users group. In figure 9.13, the administrator of Widgets has added the Keystone\Domain Users group as a member of the Widgets\Everybody local group. Any permissions that are assigned to the Widgets\Everybody group will be inherited by the members of Keystone\Domain Users.

Because it is important to understand this mechanism, let me express the idea a second way. When Widgets trusts Keystone, the Widgets administrator says, "I will accept the logon procedures in Keystone. Users who are authenticated by Keystone are also welcome in Widgets." Then the Widgets administrator proceeds to include global groups in Keystone as members of local groups in Widgets. By giving members of Keystone memberships in the Widgets local groups, those members are given permissions as though their accounts had been created directly in the Widgets domain.

The characteristics of global groups that you should remember follow:

• Global groups can contain users from the domain in which the group was created.

• Global groups cannot contain users from other domains.

• Global groups cannot contain other groups.

• Global groups can be assigned privileges in the domain in which the group was created.

• Global groups also can be assigned privileges in domains that trust the domain in which the group was created.

The word global indicates that global groups can be assigned privileges anywhere in the network (globally).

Local Groups

Local groups can be assigned privileges only in the account database in which they were created. The PDC and BDCs share an account database. Local groups can contain both users and global groups. This capability enables you to use a local group to collect entities from several domains and to manage them as a group in a local domain. When you assign privileges to a local group, all users and global groups in the local group inherit those privileges.

Figure 9: illustrates a three-domain network with the following features:

• The domain Blivets includes global users CChaplin, HLloyd, SLaurel, and MNormand.

• The domain Blivets includes a global group named SomeUsers. Users SLaurel, HLloyd, and MNormand are members of SomeUsers.

• Global users in the domain Doodads are BKeaton, FArbuckle, and OHardy.

• The domain Doodads includes a global group named MoreUsers. Only user OHardy is a member of MoreUsers.

The administrator of the domain Widgets would like to assign privileges to all the users in the Blivets and Doodads domains. One way to do that is to create a local group. In the figure, the local group is named Widgets\AllUsers. All the following entities can be added to AllUsers:

• Blivets\SomeUsers. A global group.

• CChaplin. A global user in the Blivets domain, who must be explicitly included since he is not a member of Blivets\SomeUsers.

• Doodads\MoreUsers. Another global group.

• BKeaton and FArbuckle. Global users in the domain Doodads, who must be explicitly included because they are not members of Blivets\SomeUsers.

A preferable approach would be to add all the users to the global groups Blivets\SomeUsers and Doodads\MoreUsers. This, however, would require the cooperation of the other domains. Fortunately, local groups enable you to include users when the global groups are not configured as you want.

The characteristics of local groups that you should remember follow:

• Local groups can contain users from the domain in which the local group was created.

• Local groups can contain global users from other domains that are trusted by the group's domain.

• Local groups can contain global groups from domains that are trusted by the local group's domain.

• Local groups can be assigned privileges in the group's local domain.

• Local groups cannot be assigned privileges in other domains.

Built-In Groups and Users

When you install Windows NT Workstation or Windows NT Server, several users and groups are created. These users and groups define various levels of access to workstations and servers and are the building blocks you use to secure your network.

The default users and groups can be modified by users with sufficient privileges. These groups cannot be deleted, however.

Built-In User Accounts

Every Windows NT Server or Windows NT Workstation has two default user accounts.

The Administrator user account enables you to manage the server when it first is installed. So that you cannot be locked out of the server, this account cannot be deleted or disabled, although it can be renamed. After you create other administrators, you can choose to give the Administrator account an especially secure password, store the password in a safe place, and put the Administrator account into semi-retirement.

The Guest user account cannot be deleted, but it can be disabled and renamed. Guest is disabled by default, but can be enabled if you want to permit guest users to have limited access to your domain or server.

Built-In Groups

You grant a user a set of capabilities on a domain, workstation, or server by adding the user to the correct group. The built-in groups are available in both global and local varieties to make management of the network more versatile.

Users can be assigned to multiple groups if required. To enable a user to manage printers and back up the system, add the user to the Print Operators and Backup Operators groups. These groups make it easy to configure layers of security on your network so that you can distribute responsibilities to various personnel.

Table 9.2 summarizes the built-in groups and whether they are installed on domain controllers, workstations, or servers. Each of the groups is discussed in the following sections.

Table 9.2

Windows NT Built-In Groups

Group	Local/Managed by Global	Windows NT Server Domains	Workstations and Servers	Automatic Contents
Administrators	Local Administrators	Yes	Yes	Domain Administrator (user)
Domain Admins	Global Administrators	Yes	No	Administrator
Backup Operators	Local Administrators	Yes	Yes	None
Server Operators	Local Administrators	Yes	No	None
Account Operators	Local Administrators	Yes	No	None
Print Operators	Local Administrators	Yes	No	None
Power Users	Local Administrators	No	Yes	Setup user
Power Users	Local Administrators	Yes	Yes	Domain users
Group	Local/Managed by Global Account Operators	Windows NT Servers Domains	Workstations and Servers	Automatic Contents Administrator (user)
Domain Users	Global Administrator Account Operators	Yes	No	Administrators New Users
Guests	Local Administrators Account Operators	Yes	Yes	Domain Guest (user)
Domain Guests	Global Administrators Account Operators	Yes	No	Guest
Replicator	Local Administrators	Yes	Yes	None

Administrators

• Local

• Domain Controllers, Workstations, and Servers

Members of Administrators local groups have nearly complete authority over the domain controllers, workstation, or server on which the group resides. Adding a user account to the Administrators group is all that is necessary to make the user an administrator. Administrators are limited in one respect: They cannot automatically access files on NTFS file systems. Each NTFS file has an owner who, by default, is the person who created the file. Unless the owner grants access permissions, even an administrator cannot access the file. Administrators can, however, take ownership of any file, as described in Chapter 12, "Sharing Drives, Directories, and Files."

Domain Admins

• Global

• Domain Controllers

Each domain also includes a built-in global group named Domain Admins. This group is added automatically to the Administrators local group, making all members of Domain Admins domain administrators.

You therefore have two ways to make a user a domain administrator: by adding the user directly to the Administrators local group, or by adding the user to the Domain Admins global group. The advantage of adding the user to the Domain Admins group is that this group can be included in the Administrators local group of other domains that trust this domain. This enables you to easily give administrators the permissions required to manage several domains.

When a Windows NT Workstation or a stand-alone Windows NT Server is brought into a domain, the Domain Admins group is added automatically to the workstation or server's Administrators group. If you want to prevent members of Domain Admins from managing the workstation or server, you must manually remove that entry from the Administrators group.

Backup Operators

• Local

• Domain Controllers, Workstations, and Servers

This group solves an old problem in LAN administration. Tape backups frequently are performed by operators who really should not have administrator privileges. Members of the Backup Operators group can back up and restore files, log on to the system locally, and shut down the system, but they are not granted the capability to manipulate security or perform other administrative functions.

Server Operators

• Local

• Domain Controllers

Each primary or backup domain controller has a Server Operators local group. Users in this group can perform many administrative functions but cannot manage security. They can share and stop sharing resources, format server disks, back up and restore files, log in locally to servers, and shut down servers.

Account Operators

• Local

• Domain Controllers

Account operators can manage user accounts and groups in the domain. They can create, delete, and modify most users, local groups, and global groups but cannot assign user rights. Account Operators cannot manage the accounts of administrators or modify the local groups' Administrators, Server Operators, Account Operators, Backup Operators, or Print Operators.

Print Operators

• Local

• Domain Controllers

Members of Print Operators can share, stop sharing, and manage printers running in a Windows NT Server domain. They can also log on to servers locally and shut them down.

Users

• Local

• Domain Controllers, Workstations, and Servers

Most users on workstations and servers will be members of the Users local group. On a PDC and BDCs, most users are members of Domain Users and Domain Users is a member of the Users local group. Members of Users are not permitted to log on locally to primary or backup domain controllers. They can access resources in the domain only through clients on the network. Users also can maintain a profile on a Windows NT Workstation (see Chapter 15, "Using Windows NT Clients"). Users can log on to domain controllers, workstations, and servers, however.

Power Users

• Local

• NT Workstations and Stand-alone Servers

Members of Power Users can perform user functions on workstations and servers. They can also create user accounts and modify the accounts they have created. Power Users can add user accounts to the built-in groups Users, Guests, and Power Users. They also can start and stop sharing of printers and files on the workstation or server.

If a Windows NT Workstation is operating in a Windows NT Server domain, a recommended strategy is to put the user's domain account into the Power Users group at the workstation. In that way, a single account enables the user to be a user in the domain and to administer the workstation.

Domain Users

• Global

• Domain Controllers

All user accounts in a domain are included in the Domain Users global group automatically. The Domain Users global group is in turn included in the local Users group, establishing all members of the Domain Users group as users of the domain.

In multi-domain networks, you can include the Domain Users group in the local Users groups of other domains that trust the logon domain. This is an easy way of granting users privileges on multiple domains.

Guests

• Local

• Domain Controllers, Workstations, and Servers

In domains, members of Guests are similar to members of Users. They can utilize domain resources, but may only do so by logging on through the network. Local server logons are not permitted.

Members of the Guests group on workstations and servers have limited rights. They can maintain a profile on a Windows NT Workstation, but they cannot manage local groups or lock the workstation.

Domain Guests

• Global

• Domains

The Guest user normally is included in the Domain Guests global group, which is included in the local Guests group. Other user accounts also can be added to the Domain Guests group. Members of the Domain Guests or Guest group have guest privileges in the domain.

In multi-domain networks, you can include the Domain Guests group in the local Guests groups of other domains that trust the logon domain. This is an easy way of granting users guest privileges on multiple domains.

Replicator

• Local

• Domain Controllers, Workstations, and Servers

Members of the Replicator group can manage the replication of files on the domain, workstation, or server.

What Happens When a Computer Joins a Domain

Windows NT computers cannot simply log on to a domain and start computing. Before they are permitted access to the domain, they must be added to the domain, a formal process by which the computer added to the Security Accounts Manager (SAM) database for the domain, in the process of which a SID is created for the computer. The effect this has depends on the computer's role in the domain.

Domain controllers (PDC and BDCs) fully participate in the domain security. This is most clearly seen in the case of administrators. Any user who is a member of the domain Administrators group (either directly or through membership in Domain Admins) is also an administrator of the domain controller computer. In other words, the Administrators group for the domain is also the Administrators group for the domain controller.

Stand-alone servers and Windows NT Workstation computers, however, behave quite differently. Each server and workstation retains its own security database that regulates access to resources on that computer alone. And each computer has its own set of local groups, including Administrators, Backup Operators, Power Users, Replicator, and Users. Servers and workstations have only local groups and cannot create global groups. Membership in a domain group does not guarantee membership in the corresponding local group on a server or a workstation. A member of the domain Controller Backup Operators group, for example, is not a member of the workstation Backup Operators group.

Once a Windows NT server or workstation is added to a domain, however, administrators can administer the computer and users can use it. How is this accomplished?

When the server or workstation is added to the domain, two group membership assignments are established:

• The domain Domain Admins account is added to the local Administrators account on the server or workstation.

• The domain Domain Users account is added to the local Users account on the server or workstation.

In this way, the server or computer indirectly participates in the core security established by the domain. If you need to extend on the basic security provided by the Administrators and Users groups, you can assign any of the following permissions to file and printer resources shared by the server or workstation:

• Individual users from the domain to which the computer belongs

• Individual users from domains trusted by the domain to which the computer belongs

• Global groups from the domain to which the computer belongs

• Global groups from domains trusted by the domain to which the computer belongs

Because all groups on servers and workstations are local groups—and local groups cannot contain other local groups—you cannot assign permissions to domain controller local groups.

This close relationship between Windows NT servers and workstations is a key reason why Windows NT computers make the best clients on a Windows NT Server network. MS-DOS, Windows for Workgroups, and Windows 95 clients don't have the ability to use the domain database to secure the resources they share. That's another good argument for placing critical resources on Windows NT computers, where they can be properly secured.

Testing Your Knowledge

Which one of the following Microsoft products cannot share its resources in workgroups?

1. Windows 3.x

2. Windows NT Workstation

3. Windows NT Server

4. Windows 95

5. Windows for Workgroups

6. MS-DOS with the Workgroup add-on feature

Which of the following server roles are consistent with a Windows NT Server that is connected to a domain and contains a user and group database?

1. Backup domain controller (BDC)

2. Server

3. Workstation

4. Primary domain controller (PDC)

1. If a domain model is not desired, you may set up a Windows NT Server with the __________ role.

2. All changes to the domain directory database are first made on the PDC, after which they are distributed to the BDCs in a process called __________.

   Why may it be necessary to establish two or more domains?

   1. If too many servers are put in a domain, performance can suffer.

   2. You may need to connect an additional NT Server to the network.

   3. For best performance, the domain database should be restricted to 40 MB.

   4. Some departments prefer to manage their own resources.

   Which type of trust relationship permits both trusting domains users to access each other's domains resources?

   1. One-way trust relationship

   2. Two-way trust relationship

   3. Two-domain trust relationship

   4. Simple trust relationship

   Which type of domain model is the most simple and is commonly used for small organizations?

   1. Single domain model

   2. Master domain model

   3. Multiple master domain model

   4. Complete trust model

   What type of domain model uses one domain to manage all user accounts?

   1. Single domain model

   2. Master domain model

   3. Multiple master domain model

   4. Complete trust model

   Which type of domain model is best suited for large enterprise situations?

   1. Single domain model

   2. Master domain model

   3. Multiple master domain model

   4. Complete trust model

   Which type of domain model is practical if each domain within an organization wants to retain full responsibility for managing its own domain?

   1. Single domain model

   2. Master domain model

   3. Multiple master domain model

   4. Complete trust model

   At what size of a SAM domain database file does Microsoft recommend you go to a multiple domain model type?

   1. 40 MB

   2. 166 MB

   3. 1,432,589 bytes

   4. 32 MB

3. When a user account originates on a network not running Windows NT, the account is a(n) __________.

4. A(n) __________ group is a list of user accounts from within a single domain. It can include user accounts only from the domain in which it was created and cannot contain other groups.

5. A(n) __________ group can be assigned privileges only in the domain in which it was created. It can contain both users and global groups.

   Which of the following is not a built-in group?

   1. Administrators

   2. Domain Administrators

   3. Operators

   4. Guests

   5. Power Users

   6. Replicator

Review Answers

1. A

2. A, D

3. server

4. synchronization

5. A, C, D

6. B

7. A

8. A, B

9. C

10. D

11. A

12. local account

13. global

14. local

15. C

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.