Sams Teach Yourself Samba in 24 Hours
Hour 2: Windows Networking
Previous
Hour
|
Sections in this Chapter: |
|
|
|
||
|
||
|
|
Sams Teach Yourself Samba in 24 Hours |
|
|||||||||||||
|
Hour 2: Windows Networking |
|
|||||||||||||
|
Before PCs, the network model revolved around a central computer server and terminals that users could access. These terminals had no autonomous computing power of their own. They provided the user only with an interactive view of the server.
With the invasion of personal computers in the late 1980s, people began to store their files on the local hard drive space available on their PC. This however, proposed a problem to sharing files: something that was trivial when everyone was logging into the same machine (that is, mainframe) from their terminal. People wanted to store their files locally so that they would be accessible during a server outage (something which they had no control over) while still allowing other users to access the files from their own computer. This PC-centric distributed model was named peer networking because all the machines were equally likely to be clients and servers and could operate in both modes.
The idea of a workgroup goes hand in hand with the concept of peer networking. A workgroup is a unit of people who share responsibilities to achieve a common goal. Each one has to pull his or her own weight. A computer workgroup is no different. As you will see, a computer workgroup can be used in two contexts.
The first
concept of a workgroup is as an administrative group of machines that do not
share user and group account information. Remember
step 2 of the SMB protocol overview? That is when the client sends a username
and some proof of identity. The question then becomes "Who will validate
the request?" Each machine has a separate and local copy of an account
database. Therefore, all validation is done locally. Remember that this is called
peer networking, or sometimes peer-to-peer networking, because
all machines are essentially equal. Each PC has the capability to serve files
and printers as well as validate access requests. This equality does not mean
that all machines perform the functions equally well, of course.
Figure 2.8 illustrates the idea of the workgroup authentication model. The client, shown on bottom, attempts to access the disk share on SERVER1. SERVER1 alone is responsible for validating the session setup against its local account database, whatever that might be. When the client attempts to access the printer share on SERVER2, that server is responsible for validating the connection. The outcome is entirely distinct from the outcome of the connection to SERVER1. Each server has a local distinct account database that is unrelated to the other's.
Figure
2.8
A sample workgroup networking model.
Another context for the concept of a computer workgroup is used in browsing which is covered more in Hours 19 and 20. The motivation for network browsing is the manner in which resources appear and disappear from the network as hosts start and stop. Unlike a central computing model, such as a mainframe or terminal solution, where everything is located on one machine, it is much more difficult to survey a large number of hosts that can come on and off the network at the whim of the PC's owner. Browsing allows users to view the current servers and resources available dynamically. In this context, a domain and a workgroup are equivalent.
A domain is similar to a workgroup with one major exception. In a domain, there is a central authentication server that maintains the domain's user and group accounts. Resources in the domain are accessed regardless of what machine they are located on by validating against the domain controller. This is still peer networking because all machines maintain the capability to serve files and printers and perform the necessary validation. The difference is that the validation is performed against a remote account database located on the domain controller.
Domains grew out of the need to get rid of the mass of passwords that was necessary when every machine had its own local account database. The solution provided users with one account that could allow access to all resources if so desired.
Figure 2.9 shows a sample connection to a server that is a member of some domain. First, the client sends the connection request containing the user information to SERVER1 asking to access some disk share. SERVER1 then sends a validation request to the domain controller (DC). The validation request contains the user information originally sent by the client. If the DC successfully validates the user, it sends a positive response to SERVER1 that then sends a positive connection response back to the client. This means, assuming that the access control mechanisms such as permission lists allow it, that a client can connect to any server in the domain using a single username and password. In Figure 2.8, the client needed a separate username and password to connect to each server.
Figure
2.9
Domain example.
|
Sams Teach Yourself Samba in 24 Hours |
|
|||||||||||||
|
Hour 2: Windows Networking |
|
|||||||||||||
|
© Copyright Macmillan USA. All rights reserved.
){kind=link}
){kind=link}