1.3.5 Datagrams and Sessions
At this point, let's digress to introduce another responsibility of NBT: to
provide connection services between two NetBIOS machines. There are
actually two services offered by NetBIOS over TCP/IP: the session service
and the datagram service. Understanding how these two services work is not
essential to using Samba, but it does give you an idea of how NBT works
and how to troubleshoot Samba when it doesn't work.
The datagram service has no stable connection between one machine and
another. Packets of data are simply sent or broadcast from one machine to
another, without regard for the order that they arrive at the destination, or
even if they arrive at all. The use of datagrams is not as network intensive as
sessions, although they can bog down a network if used unwisely (remember
broadcast name resolution earlier?) Datagrams, therefore, are used for
quickly sending simple blocks of data to one or more machines. The
datagram service communicates using the simple primitives shown in Table
1.4.
Table 1.4: Datagram Primitives
Primitive Description
Table 1.4: Datagram Primitives
Primitive Description
Send Datagram Send datagram packet to machine or groups of
machines.
Send Broadcast
Datagram
Broadcast datagram to any machine waiting with a
Receive Broadcast Datagram.
Receive Datagram Receive a datagram from a machine.
Receive Broadcast
Datagram
Wait for a broadcast datagram.
The session service is more complex. Sessions are a communication method
that, in theory, offers the ability to detect problematic or inoperable
connections between two NetBIOS applications. It helps to think of an NBT
session in terms of a telephone call.[ 5
] A full-duplex connection is opened
between a caller machine and a called machine, and it must remain open
throughout the duration of their conversation. Each side knows who the
caller and the called machine is, and can communicate with the simple
primitives shown in Table 1.5
.
[5] As you can see in RFC 1001, the telephone analogy was strongly evident
in the creation of the NBT service.
Table 1.5: Session Primitives
Primitive Description
Call Initiate a session with a machine listening under a specified
name.
Listen Wait for a call from a known caller or any caller.
Hang-up Exit a call.
Send Send data to the other machine.
Receive Receive data from the other machine.
Session
Status
Get information on requested sessions.
Sessions are the backbone of resource sharing on an NBT network. They are
typically used for establishing stable connections from client machines to
disk or printer shares on a server. The client "calls" the server and starts
trading information such as which files it wishes to open, which data it
wishes to exchange, etc. These calls can last a long time - hours, even days -
and all of this occurs within the context of a single connection. If there is an
error, the session software (TCP) will retransmit until the data is received
properly, unlike the "punt-and-pray" approach of the datagram service
(UDP).
In truth, while sessions are supposed to be able to handle problematic
communications, they often don't. As you've probably already discovered
when using Windows networks, this is a serious detriment to using NBT
sessions. If the connection is interrupted for some reason, session
information that is open between the two computers can easily become
invalidated. If that happens, the only way to regain the session information is
for the same two computers to call each other again and start over.
If you want more information on each of these services, we recommend you
look at RFC 1001. However, there are two important things to remember
here:
• Sessions always occur between two NetBIOS machines - no more and
no less. If a session service is interrupted, the client is supposed to
store sufficient state information for it to re-establish the connection.
However, in practice, this is rarely the case.
• Datagrams can be broadcast to multiple machines, but they are
unreliable. In other words, there is no way for the source to know that
the datagrams it sent have indeed arrived at their destinations.
1.4 Microsoft Implementations
With that amount of background, we can now talk about some of Microsoft's
implementations of the preceding concepts in the CIFS/SMB networking
world. And, as you might expect, there are some complex extensions to
introduce as well.
1.4.1 Windows Domains
Recall that a workgroup is a collection of SMB computers that all reside on
a subnet and subscribe to the same SMB group. A Windows domain goes a
step further. It is a workgroup of SMB machines that has one addition: a
server acting as a domain controller. You must have a domain controller in
order to have a Windows domain.[ 6
] Otherwise, it is only a workgroup. See
Figure 1.11
.
[6] Windows domains are called "Windows NT domains" by Microsoft
because they assume that Windows NT machines will take the role of the
domain controller. However, because Samba can perform this function as
well, we'll simply call them "Windows domains" to avoid confusion.
Figure 1.11: A simple Windows domain
There are currently two separate protocols used by a domain controller
(logon server): one for communicating with Windows 95/98 machines and
one for communicating with Windows NT machines. While Samba currently
implements the domain controller protocol for Windows 95/98 (which
allows it to act as a domain controller for Windows 9 x machines), it still
does not fully support the protocol for Windows NT computers. However,
the Samba team promises that support for the Windows NT domain
controller protocol is forthcoming in Samba 2.1.
Why all the difficulty? The protocol that Windows domain controllers use to
communicate with their clients and other domain controllers is proprietary
and has not been released by Microsoft. This has forced the Samba
development team to reverse-engineer the domain controller protocol to see
which codes perform specific tasks.
1.4.1.1 Domain controllers
The domain controller is the nerve center of a Windows domain, much like
an NIS server is the nerve center of the Unix network information service.
Domain controllers have a variety of responsibilities. One responsibility that
you need to be concerned with is authentication. Authentication is the
process of granting or denying a user access to a shared resource on another
network machine, typically through the use of a password.
Each domain controller uses a security account manager (SAM) to maintain
a list of username-password combinations. The domain controller then forms
a central repository of passwords that are tied to usernames (one password
per user), which is more efficient than each client machine maintaining
hundreds of passwords for every network resource available.
On a Windows domain, when a non-authenticated client requests access to a
server's shares, the server will turn around and ask the domain controller
whether that user is authenticated. If it is, the server will establish a session
connection with the access rights it has for that service and user. If not, the
connection is denied. Once a user is authenticated by the domain controller,
a special authenticated token will be returned to the client so that the user
will not need to relogin to other resources on that domain. At this point, the
user is considered "logged in" to the domain itself. See Figure 1.12
.
Figure 1.12: Using a domain controller for authentication
1.4.1.2 Primary and backup domain controllers
Redundancy is a key idea behind a Windows domain. The domain controller
that is currently active on a domain is called the primary domain controller
(PDC). There can be one or more backup domain controllers (BDCs) in the
domain as well, which will take over in the event that the primary domain
controller fails or becomes inaccessible. BDCs frequently synchronize their
SAM data with the primary domain controller so that, if the need arises, any
one of them can perform DC services transparently without impacting its
clients. Note that BDCs, however, have only read-only copies of the SAM;
they can update their data only by synchronizing with a PDC. A server in a
Windows domain can use the SAM of any primary or backup domain
controller to authenticate a user who attempts to access its resources and
logon to the domain.
Note that in many aspects, the behaviors of a Windows workgroup and a
Windows domain overlap. This is not accidental since the concept of
Windows domains did not evolve until Windows NT 3.5 was introduced,
and Windows domains were forced to remain backwards compatible with
the workgroups present in Windows for Workgroups 3.1. The key thing to
remember here is that a Windows domain is simply a Windows workgroup
with one or more domain controllers added.
Samba can function as a primary domain controller for Windows 95/98
machines without any problems. However, Samba 2.0 can act as a primary
domain controller only for authentication purposes; it currently cannot
assume any other PDC responsibilities. (By the time you read this, Samba
2.1 may be available so you can use Samba as a PDC for NT clients.) Also,
because of the closed protocol used by Microsoft to synchronize SAM data,
Samba currently cannot serve as a backup domain controller.
1.4.2 Browsing
Browsing is a high-level answer to the user question: "What machines are
out there on the Windows network?" Note that there is no connection with a
World Wide Web browser, apart from the general idea of "discovering
what's there." And, like the Web, what's out there can change without
warning.
Before browsing, users had to know the name of the specific computer they
wanted to connect to on the network, and then manually enter a UNC such
as the following into an application or file manager to access resources:
\\HYDRA\network\
With browsing, however, you can examine the contents of a machine using a
standard point-and-click GUI - in this case, the Network Neighborhood
window in a Windows client.
1.4.2.1 Levels of browsing
As we hinted at the beginning of the chapter, there are actually two types of
browsing that you will encounter in an SMB/CIFS network:
• Browsing a list of machines (with shared resources)
• Browsing the shared resources of a specific machine
Let's look at the first one. On each Windows workgroup (or domain) subnet,
one computer has the responsibility of maintaining a list of the machines that
are currently accessible through the network. This computer is called the
local master browser, and the list that it maintains is called the browse list.
Machines on a subnet use the browse list in order to cut down on the amount
of network traffic generated while browsing. Instead of each computer
dynamically polling to determine a list of the currently available machines,
the computer can simply query the local master browser to obtain a
complete, up-to-date list.
To browse the actual resources on a machine, a user must connect to the
specific machine; this information cannot be obtained from the browse list.
Browsing the list of resources on a machine can be done by clicking on the
machine's icon when it is presented in the Network Neighborhood in
Windows 95/98 or NT. As you saw at the opening of the chapter, the
Không có nhận xét nào:
Đăng nhận xét