Abstract
In this chapter, you will develop an understanding of the domain model and learn about where and how to deploy Windows NT domains, the advantages and disadvantages of the different domain models, and find solutions for integrating NT domains and Unix networks.
The good news is that Windows NT domains are becoming more powerful and full-featured in Windows 2000 Server. The bad news is that you now may have to manage Windows 2000 Server domains and mixed NT 4.0 domains along with your distributed Unix servers! As a result, understanding the fundamentals of the domain model, learning about where and how to deploy NT domains, comparing the advantages and disadvantages of the different domain models, and finding solutions for integrating NT domains and Unix networks are critical.
The questions we address in this chapter are
What is a workgroup?
What is a domain?
What is the difference between a domain and a workgroup?
What problems are solved by using domains?
What are the network components/services I need to make a domain work?
How do domains work — that is, when they do work?
What are the different domain models and how do I deploy them?
What are trust relationships?
How can I easily manage users and resources?
What solutions are available for integrating distributed NT and Unix networks?
WORKGROUPS
The terms workgroup and domain are used extensively in Microsoft networking and refer to the management mechanisms available to network members. Workgroups imply decentralized management, whereas domains imply centralized control.
Workgroups are collections of computers grouped just for viewing purposes; each computer user is responsible for managing its security functions. A workgroup can consist of NT Workstations, NT Servers, Unix computers running Server Message Block (SMB) services, and others. They communicate using a common set of networking protocols at all seven layers of the OSI model.
Tip:A workgroup exists within a local area network or in a TCP/IP subnetwork. It’s important to understand the implications of this statement. If you use switches and logical networks or if your network design changes and you have members of a workgroup in two different subnetworks, essentially you have two workgroups with the same name. In each workgroup, you will see some of the members of the previous single workgroup.
Purpose
You can set up workgroups to share resources such as printers, files, fax and telephony links, and remote network connections. Each user controls his/her computer and has access to all the resources on that specific computer. The user can control all access to that computer.
Workgroups can be very useful in environments where “knowledge workers” want complete control of their machines. A small engineering company with a few engineers and draftsmen, for example, may prefer to use a workgroup. A workgroup lets each engineer secure information about his/her own project and work independently of other users on the network. Each engineer can provide drawings and project information selectively to specific users. Several NT Workstations or Servers could be used in this scenario as print and file servers and for other general purposes.
Also, if you have consultants or other employees who need temporary access to resources and at the same time want to control their own environment, a workgroup may be a good solution.
Workgroups may consist of Windows 95, Windows 98, Windows for Workgroups, and NT systems. Unix systems can also be part of a workgroup if they support the SMB protocol that is used on all Windows machines. You also need software such as SAMBA on the Unix systems to make it possible for them to participate in the workgroup.
In small networks (typically fewer than 50 computers), it is possible for a network administrator to manage and control resources. But the larger the workgroup, the more diverse the requirements become. As a result, it is usually preferable to set up a domain.
DOMAINS
Domains are collections of computers grouped for management purposes; they share a group name. Domains let users access resources using a single logon. Administrators don’t have to create multiple user accounts for a single user to give that user access to all domain resources.
From a security perspective, a domain is a set or collection of computers that share a common security database and a common security policy. NT domains advance the concepts seen in LAN Manager for Unix and LAN Server domains. Each domain has a unique domain name.
Special Note: The terms domain and workgroup seem to be used interchangeably whenever Microsoft documentation and third-party authors discuss concepts related to browsing. However, in relation to authentication and security issues, the terms domain and workgroup mean totally different things, and you should not confuse them.
Purpose
You can use a domain to give users access to all of an organization’s network resources with a single logon. Users who are authenticated by the domain controller using information in the security database are allowed to run processes on various computer systems that are members of the domain.
The domain controller is responsible for maintaining the security database and for allowing access to the security database by members of the domain. Recall from Chapter 3 that there are two types of domain controllers in an NT 4.0 environment — primary domain controllers (PDCs) and backup domain controllers (BDCs — also called logon servers).
You give users access to resources and add new user accounts on the PDC. The BDCs copy account and security information from the PDCs and can share the load of authenticating users and computers. The PDC maintains a read/write copy of the domain security database with information about user accounts and groups and allows all BDCs to copy this information periodically. The BDCs have a read-only copy of this database. As a result, the PDC must be available on the network at all times to allow any changes to the security database.
Unlike this single-master replication model that NT 4.0 uses, Windows 2000 networks allow multiple-master replication. That is, there is no PDC. All domain controllers have read/write copies, and changes are propagated to all domain controllers.
Special Note: The following points about NT 4.0 domain controllers were discussed in Chapter 3 but are worth repeating because it’s so easy to forget their implications:
If you install a computer as a domain controller in one domain, you can’t use it as a domain controller in a different domain without reinstalling NT.
If you install an NT Server computer as a standalone server, you must reinstall NT to make it a domain controller.
If you install an NT Server computer as a domain controller and later want to make it into a standalone server, you must reinstall NT.
If a BDC is promoted to a PDC, the PDC automatically gets demoted to a BDC. Always ensure that the PDC is up and available on the network before promoting a BDC. If you promote a BDC while the PDC is not accessible, you may end up having two PDCs in the network.
In addition, the software on BDCs and PDCs should be at the same version number and service pack number. If at all possible, apply post-service-pack hot-fixes identically among all domain controllers.
Because Windows 2000 separates the core operating system installation from the Directory Service, domain controllers can be added or removed without having to reinstall the operating system.
Domains offer two primary benefits:
Single user logon for universal resource access — Users can access resources on the network securely with just one logon. Users don’t need to log on individually or manually to each system to access resources across the network.
Centralized administration — Administrators can track and manage multiple systems and users from one central point.
NETWORK COMPONENTS REQUIRED FOR A DOMAIN
Of course, you can have an NT domain with just an NT 4.0 Server installed as a PDC. But in typical networks, the following components are required to operate and manage an NT domain smoothly:
AN NT 4.0 Server set up as the PDC or a Windows 2000 Server set up as a domain controller.
NT 4.0 Server(s) set up as BDC(s) or Windows 2000 Server(s) set up as domain controller(s).
NT Workstations that are members of the domain. These workstations need computer accounts that are set up either from the Server Manager (Select Computer, Add to Domain) on the domain controller or from the Network applet on the workstation.
DHCP and WINS for NT 4.0 domains; DHCP and DNS for Windows 2000 Server domains; and DHCP, WINS, and DNS for mixed NT 4.0 and Windows 2000 Server domains.
Connectivity from all networks to networks that contain the domain controllers. The links should have enough bandwidth to support all user authentication and other activities with a response time of less than two seconds. If you are connected to the PDC and BDCs through slow links, consider adding a BDC on each remote network.
DOMAINS — WHY EVEN BOTHER?
Domains solve one of the major problems in distributed computing — maintaining separate user names and passwords on multiple computers. To ensure that users don’t have to worry about where user accounts are located, we have to make the network consistent. Consistency implies that any user name or password changes are propagated throughout the network, and that is not a scalable approach. The domain concept solves this problem. Instead of maintaining on each individual computer separate copies of password files, group files, and so on, the domain structure allows all domain members to trust the domain controller’s version of the password and group files.
There are subtle differences between membership in a domain and membership in a workgroup. For example, let’s say you are installing a standalone server in a workgroup. Assume that you want to use NTFS permissions and create home directories for users with the default permissions. You may find that anyone who is logged on to the NT Server is able to access any of the home directories. If the NT Server is installed as a standalone server in a domain, then each new home directory that is created will be set up automatically so that users are able to access only their own home directories, even though they are interactively using the NT Server.
Domains let you centralize the management of users and resources. If necessary, you can also separate the management of users from the management of resources using the various domain models.
THE FOUR DOMAIN MODELS
The different domain models are covered very well in the Microsoft Windows NT Resource Kit, various third-party books, and in a variety of white papers and documents from Microsoft. We add a few more practical technical details and compare Microsoft’s domain concepts with typical Unix-based solutions.
There are four distinct models for implementing domains within organizations:
Single domain model
Single-master domain model
Multiple-master domain model
Complete trust model
We look at each of these in detail in the following sections.
Single Domain Model
The single domain model is ideal for organizations that want to control all computing resources and user accounts from a central location. This model includes one organization-wide security database, and a centralized IS department can grant or deny users access to specific resources.
Each NT computer and other members that want access to resources from the domain must get the user authenticated by the PDC or a BDC.
The single domain model does not imply that the network must be located in one geographical area. Depending on the connectivity and the availability of high-speed lines, a single domain can serve the needs of large organizations. The main criterion for adopting this model is whether you want centralized control from one part of your organization.
Theoretically, an NT domain can handle 220 users, but practical considerations limit this number to about 15,000 per domain (40,000 with some planning). If you have more than 15,000 users in your organization, you may want to consider the multiple-master domain model.
If your network is dispersed over different geographical areas, you can still use the single domain model but you may want to set up a domain controller in each location. The PDC sends a signal — a pulse — to these BDCs, notifying them that security information has changed. When the BDCs receive the pulse, they download the update to their information. By default, this process is performed every 300 seconds. The Netlogon service sends the information; it sends the serial numbers of the changes in the netlogon.chg file. The BDCs look at the serial numbers in their database and download the changes. Setting up BDCs in each location reduces the need for high-speed connections and increases the response time for users logging on to the domain.
Single-Master Domain Model
If you want different parts of your organization to control specific groups of resources but want a centralized IS department to control the user accounts, you should consider the single-master domain model. In this model, the organization has several domains. The user domain, or the domain where all the user accounts are set up, is the master domain; all users log on to this domain. The resource domains, or the domains controlled by the individual divisions or departments, use the master domain for authentication purposes. The resource domains don’t contain any user accounts.
For example, a pulp and paper company is usually divided into several divisions — Pulping, Newsprint, Marketing, and Forestry. Each division controls completely different resources and may require specialists trained in each area. In this case, a single-master domain model is ideal because the Newsprint division can control who can access the Newsprint resources, but the master domain authenticates the users.
What happens is both simple and elegant. Administrators of the resource domains allow specific groups of users to have access to the resources. The master domain’s Administrators decide which groups each user can belong to.
In this setup, the resource domains are said to trust the master domain. When a user who has an account on the master domain accesses a resource — a computer or a printer or a database — the resource domain contacts the master domain to verify that the user has a valid account and is authenticated. In this way, user accounts don’t have to be duplicated on the resource domain.
Trust relationships between domains are binary. Either you establish a trust relationship or you don’t. There is no such thing as Domain A trusts Domain B a little bit. You establish degrees of trust through selectively allowing and denying specific users (preferably specific groups of users) access to various resources in a resource domain.
Multiple-Master Domain Model
In a multiple-master domain model, you have many master domains. Any of the master domains can provide user authentication to any of the resource domains. The administrators of each of the resource domains still define resource access. Each master domain can authenticate users who are accessing resources from each of these domains.
The multiple-master domain model is ideal for very large organizations because it allows centralization in a decentralized way. If you have more than 15,000 users, this model may be the only practical way to go.
Complete Trust Model
In a complete trust model, an organization has many domains and each domain contains users and resources. This model may be useful for organizations that are divided into multiple divisions, with each division managing its own resources. Many companies that operate as multiple “virtual organizations” or that have multiple lines of business use the complete trust model.
The complete trust model is similar to the workgroup in the sense that the organization is a collection of domains, each of which manages its own resources individually, just as a workgroup is a collection of computers in which each user manages his/her own computer.
In general, the complete trust model is more difficult to manage than the other models outlined here. Management standards and policies must be set up and maintained strictly; organizing and maintaining them can be a chore. But in certain situations, in which you want each organization to set up, manage, and maintain its own policies, the complete trust model is the best choice. It combines the decentralized nature of workgroups with the rigorous policies and management mechanisms of domains.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
