When I'm helping someone set up a new Windows NT network, one question I hear often is: "What exactly is the difference between a workgroup and a domain?" To build a workgroup, you need only PCs running Windows for Workgroups (WFW), Windows 95, Windows NT Workstation, or a combination. In contrast, a domain requires that at least one machine run Windows NT Server. You can't get around it. (Back in the old days, you could use a LAN Manager server, but that's another story.)
I'm over-simplifying when I say this, but a domain is basically a workgroup with an extra function--security--added. This definition implies something of an odd marriage, because the workgroup function and the security function aren't that closely related. A workgroup's main job is to keep a directory of available servers on a network. A domain performs that function but adds a database of security information: Who's allowed to do what on the network. (Again, that's a very simplified explanation.)
Browse Masters
To understand what a workgroup does, consider what a user does whenever he
or she logs on to your network. On my network, just about everybody connects to
a share called public on a server named orion01. Let's assume for argument's
sake that all the users in my office agreed to map their P (P for public) drive
to that share. The mapping command looks like this: netusep:\\orion01\public.
That's a command-line command that you can insert into a login batch script, an
AUTOEXEC.BAT file, or the like.
If you've been a network administrator for any time at all, you probably know that command, but stay with me for a minute while I pick the command apart. The netusep: says that you want to map P to something, and \\orion01\public is what you want. The name \\orion01\public is Microsoft's way of saying, "the share named public on the server named orion01." That string is a Universal Naming Convention (UNC) address.
The syntax of the command isn't that bizarre, but a real problem arises with the \\orion01\public name. How did I know that the server's name was orion01, and how did I know what shares were available on it?
Back in 1985, Microsoft started selling its MS-NET product, the great-great grandmother of NT Server. Even then, networked PCs needed netuse commands, double backslashes and all. Again, the commands were--and are--cryptic but necessary: To get to a server, you had to know the server and share names. At the time, I said to a manager of the MS-NET group that the network needed a netscan command or something to make finding the names of servers and shares easy. He replied that this lack of a netscan command wasn't a shortcoming of the network, but rather a positive feature--how many times have we heard that one? He claimed that this lack assisted in network security: If you don't know what something's called, you probably don't have a right to access it. (Yeah, sure, it's a feature!)
Nowadays, however, you don't need to know server names and share names to use network resources. To find a network resource, you type netview if you're at a DOS workstation, click on Disk/Connect Network Drive... from an NT Workstation or WFW workstation, or open up the Network Neighborhood from a Windows 95 workstation. No matter how you do it, you'll see a list of available servers and shares. Where that list comes from explains workgroups.
Microsoft needed some way for a user to quickly get a list of the servers on the network and their shares, something to automatically take a census of the servers and shares. This is clearly a computable kind of problem. Microsoft's answer was a kind of name server, or directory server, that the company calls a master browser, or browse master. (Microsoft uses both terms in its literature.)
Every time a server comes up, it announces itself to a particular machine designated as the browse master for the network. (Selecting the browse master is an automatic process.) The browse master keeps a list--the browse list--of all the servers it's heard from and provides that list to any workstation that asks for it. Think of the browse master as a client/server tool: It runs the Browser service, which is the server application, and the workstations run netview, Network Neighborhood, or whatever, which are the client applications.
Thus, Microsoft networks can easily provide a list of available servers. But just providing a list of active servers wouldn't be of value to organizations of any appreciable size. Why? Because virtually every WFW, Windows 95, and NT Workstation is a server in the sense that it can share data over the network. So every one of those workstations would end up on the browse list. In other words, sheer size would soon make the browse list for a large company unmanageable, difficult to browse, and slow to retrieve. That's where workgroups come in.
A workgroup is a subset of your company's servers, a way to present a smaller number of servers to a workstation. So, for example, salespeople might be part of a workgroup called SALES. If they request a browse list, they get only the servers that are part of the SALES workgroup. Note, however, that it is the salesperson's PC that is a member of the SALES workgroup. Workgroups have no notion of a user account, so your machine receives the browse list for the workgroup it belongs to. The list doesn't care who you are or what groups you belong to.
You don't really have to do anything special to create a workgroup. Just put a server in a workgroup, and the workgroup exists. The workgroup will select its browse master automatically. Then any workstation or server that you put into the workgroup will get--and perhaps contribute to--the browse list for that workgroup.
Domains and PDCs
NT networks expand on the notion of a workgroup by adding security. Groups
of servers recognize a set of users because those users have user accounts. The
accounts are really just a simple database containing a user's name, password,
what groups the user belongs to, what shares he or she is allowed to access, and
the like.
The database resides on an NT server machine. Again, it must be a server; a workstation can't do this. Just as a master browser heads up a workgroup, a domain has a boss, a database-holding machine that heads a domain and is called a Primary Domain Controller (PDC). Other NT Servers and Workstations can choose to join the domain. If they do, the PDC will create accounts for them, too, increasing its database to include both machines and people.
The machine accounts not only include machine names, but also share information--the shares that each machine offers on the network. When any workstation attempts to access a share on any server in the domain, the server will stop and check with the PDC first before releasing any data. In effect, the server says, "Hey, PDC, do you know this guy who's requesting my data? Is it safe to give it to him?" Because the PDC holds the database of permissions, it can then give the yea or nay to the access request. If the simple workgroup function provides server and share names, making it a name server, the domain function adds a central machine as clearinghouse for security information, making it a security server.
In a few places, this situation becomes confusing. First, logging on to a domain is different from joining a domain. Users log on to domains from any kind of workstation. They can explicitly log on to a domain, in which case, their login script runs. Or they implicitly log on to a domain the first time they try to access a resource whose access the domain controls. Either way, the PDC checks them out before they get to any domain resources.
Second, only machines may join a domain, and only NT machines--NT Workstations and NT Servers--at that. By joining a domain, a machine says to its PDC, "I'll let you determine whether particular users can access my shared resources." But every domain is also a workgroup, and domain controllers also act as browse masters.
This situation leads to another source of confusion. A browse master keeps a list of every kind of server, including the Windows 95 and WFW machines that aren't members of the domain but are members of the workgroup. So suppose you have a domain named FOLKS. All the NT machines have joined the FOLKS domain, and the Windows 95 and WFW machines are part of the workgroup named FOLKS. (Remember, because Windows 95 and WFW don't know what a domain is, they see FOLKS as a workgroup, even though an NT domain controller is the browse master.) The PDC of FOLKS keeps track of the names of all the servers whose workgroup name is FOLKS but acts only as a security guard for the NT machines in the domain named FOLKS.
Separate Functions
Personally, I wish Microsoft had kept the name-service function separate
from the security-service function. But since it didn't, you need to understand
the difference between workgroups and domains. Maybe Microsoft will separate the
two in Cairo. Maybe? I can hope.
| Contact Info |
|
Microsoft * 206-882-8080 Web: http://www.microsoft.com |
