Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.

Windows Workgroups and Domains

Up to now, we’ve covered basic SMB technology, which
is all you would need if you had nothing more advanced than MS-DOS
clients on your network. We do assume you want to support Windows
clients, especially the more recent versions, so next
we’ll describe the enhancements Microsoft has added
to SMB networking—namely, Windows for Workgroups and Windows
domains.

Windows Workgroups

Windows
Workgroups are very similar to the SMB groups already described. You
need to know just a few additional things.

Browsing

Browsing
is the process of finding the other computers and shared resources in
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.” On the other hand, browsing the Windows
network is like the Web in that what’s out there can
change without warning.

Before browsing existed, users had to know the name of the 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:

\\toltec\spirit\

Browsing is much more convenient, making it possible to examine the
contents of a network by using the point-and-click GUI interface of
the Network Neighborhood (or My Network Places[5]) on a Windows client.

You will encounter two types of browsing in an SMB network:

Browsing a list
of computers and shared resources

Browsing the shared resource
of a specific computer

Let’s look at the first one. On each LAN (or subnet)
with a Windows workgroup or domain, one computer has the
responsibility of maintaining a list of the computers 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. Computers on a subnet use the browse
list 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 computers, the computer can simply
query the local master browser to obtain a complete, up-to-date list.

To browse the resources on a computer, a user must connect to the
specific computer; this information cannot be obtained from the
browse list. Browsing the list of resources on a computer can be done
by double-clicking the computer’s icon when it is
presented in the Network Neighborhood. As you saw at the opening of
the chapter, the computer will respond with a list of shared
resources that can be accessed after the user is successfully
authenticated.

Each server on a Windows workgroup is required to announce its
presence to the local master browser after it has registered a
NetBIOS name, and (theoretically) announce that it is leaving the
workgroup when it is shut down. It is the local master
browser’s responsibility to record what the servers
have announced.

Warning

The Windows Network Neighborhood can behave
oddly: until you select a particular computer to browse, the Network
Neighborhood window might contain data that is not up-to-date. That
means the Network Neighborhood window can be showing computers that
have crashed or can be missing computers that
haven’t been noticed yet. Put succinctly, once
you’ve selected a server and connected to it, you
can be a lot more confident that the shares and printers really exist
on the network.

Unlike the roles you’ve seen earlier, almost any
Windows system (including Windows for Workgroups and Windows 95/98/Me
or NT/2000/XP) can act as a local master browser. The local master
browser can have one or more
backup browsers on the local subnet
that will take over in the event that the local master browser fails
or becomes inaccessible. To ensure fluid operation, the local backup
browsers will frequently synchronize their browse list with the local
master browser.

Here is how to calculate the minimum number of backup browsers that
will be allocated on a workgroup:

If up to 32 Windows NT/2000/XP workstations are on the network, or up
to 16 Windows 95/98/Me computers are on the network, the local master
browser allocates one backup browser in addition to the local master
browser.

If the number of Windows NT/2000/XP workstations falls between 33 and
64, or the number of Windows 95/98/Me workstations falls between 17
and 32, the local master browser allocates two backup browsers.

For each group of 32 NT/2000/XP workstations or 16 Windows 95/98/Me
computers beyond this, the local master browser allocates another
backup browser.

There is currently no upper limit on the number of backup browsers
that can be allocated by the local master browser.

Browsing elections

Browsing
is a critical aspect of any Windows workgroup. However, not
everything runs perfectly on any network. For example,
let’s say that a computer running Windows on the
desk of a small company’s CEO is the local master
browser—that is, until he switches it off while plugging in his
massage chair. At this point the Windows NT Workstation in the spare
parts department might agree to take over the job. However, that
computer is currently running a large, poorly written program that
has brought its processor to its knees. The moral: browsing has to be
very tolerant of servers coming and going. Because nearly every
Windows system can serve as a browser, there has to be a way of
deciding at any time who will take on the job. This decision-making
process is called an election.

An election algorithm is built into nearly all Windows operating
systems such that they can each agree who is going to be a local
master browser and who will be local backup browsers. An election can
be forced at any time. For example, let’s assume
that the CEO has finished his massage and reboots his server. As the
server comes online, it will announce its presence, and an election
will take place to see if the PC in the spare parts department should
still be the master browser.

When an election is performed, each computer broadcasts information
about itself via datagrams. This information includes the following:

The version of the election protocol used

The operating system on the computer

The amount of time the client has been on the network

The hostname of the client

These values determine which operating system has seniority and will
fulfill the role of the local master browser. (Chapter 7 describes the election process in more
detail.) The architecture developed to achieve this is not elegant
and has built-in security problems. While a browsing domain can be
integrated with domain security, the election algorithm does not take
into consideration which computers become browsers. Thus it is
possible for any computer running a browser service to register
itself as participating in the browsing election and (after winning)
being able to change the browse list. Nevertheless, browsing is a key
feature of Windows networking, and backward-compatibility
requirements will ensure that it is in use for years to come.

Windows 95/98/Me authentication

Three types of passwords arise when
Windows
95/98/Me is operating in a Windows workgroup:

A Windows password

A Windows Networking password

A password for each shared resource that has been assigned password
protection

The Windows password functions in a manner
that might be a source of confusion for Unix system administrators.
It is not there to prevent unauthorized users from using the
computer. (If you don’t believe that, try clicking
the Cancel button on the password dialog box and see what happens!)
Instead, the Windows password is used to gain access to a file that
contains the Windows Networking and network resource passwords. There
is one such file per registered user of the system, and they can be
found in the C:\Windows directory with a name
composed of the user’s account name, followed by a
.pwl extension. For example, if the
user’s account name is
“sarah,” the file will be
C:\Windows\sarah.pwl. This file is encrypted
using the Windows password as the encryption key.

Tip

As a security measure, you might want to check for junk
.pwl files on Windows 95/98/Me clients, which
might have been created by mistakes users made while attempting to
log on. A .pwl file is easily cracked and can
contain valid passwords for Samba accounts and network shares.

The first time the network is accessed, Windows attempts to use the
Windows password as the Windows Networking password. If this is
successful, the user will not be prompted for two separate passwords,
and subsequent logins to the Windows system will automatically result
in logging on to the Windows network as well, making things much
simpler for the user.

Shared network resources in the workgroup can also have passwords
assigned to them to limit their accessibility. The first time a user
attempts to access the resource, she is asked for its password, and a
checkbox in the password dialog box gives the user the option to add
the password to her password list. This is the default; if it is
accepted, Windows will store the password in the
user’s .pwl file, and all
further authentication to the resource will be handled automatically
by Windows.

Samba’s approach to workgroup authentication is a
little different, which is a result of blending the Windows workgroup
model with that of the Unix host upon which Samba runs. This will be
discussed further in Chapter 9.

Windows NT Domains

The
peer-to-peer networking model of
workgroups functions fairly well as long as
the number of computers on the network is small and there is a
close-knit community of users. However, in larger networks the
simplicity of workgroups becomes a limiting factor. Workgroups offer
only the most basic level of security, and because each resource can
have its own password, it is inconvenient (to say the least) for
users to remember the password for each resource in a large network.
Even if that were not a problem, many people find it frustrating to
have to interrupt their creative workflow to enter a shared password
into a dialog box every time another network resource is accessed.

To support the needs of larger networks, such as those found in
departmental computing environments, Microsoft introduced domains
with Windows NT 3.51. A Windows NT domain is
essentially a workgroup of SMB computers that has one addition: a
server acting as a domain
controller (see Figure 1-12).

Figure 1-12. A simple Windows domain

Domain controllers

A domain controller in a Windows NT domain functions much like a
Network
Information Service (NIS) server in a Unix network, maintaining a
domain-wide database of user and group information, as well as
performing related services. The responsibilities of a domain
controller are mainly centered around security, including
authentication,
the process of granting or denying a user access to the resources of
the domain. This is typically done through the use of a username and
password. The service that maintains the database on the domain
controllers is called the Security Account Manager (SAM).

The Windows NT security model revolves
around security
identifiers (SIDs) and access
control lists
(ACLs). Security identifiers are used to represent objects in the
domain, which include (but are not limited to) users, groups,
computers, and processes. SIDs are commonly written in ASCII form as
hyphen-separated fields, like this:

S-1-5-21-1638239387-7675610646-9254035128-545

The part of the SID starting with the
“S” and leading up to the rightmost
hyphen identifies a domain. The number after the rightmost hyphen is
called a relative identifier (RID) and is a unique
number within the domain that identifies the user, group, computer,
or other object. The RID is the analog of a user ID (UID) or
group ID
(GID) on a Unix system or within an NIS domain.

ACLs supply the same function as
“rwx”
file permissions that are common in Unix
systems. However, ACLs are more versatile. Unix file permissions only
set permissions for the owner and group to which the file belongs,
and “other,” meaning everyone else.
Windows NT/2000/XP ACLs allow permissions to be set individually for
any number of arbitrary users and/or groups. ACLs are made up of one
or more access control
entries (ACEs), each of which contains an SID
and the access rights associated with it.

ACL support has been added as a standard feature for some Unix
variants and is available as an add-on for others. Samba supports
mappings between Windows and Unix ACLs, and this will be covered in
Chapter 8.

Primary and backup domain controllers

You’ve already read about master and backup
browsers. Domain controllers are similar in that a domain has a
primary domain
controller (PDC) and can have
one or more backup domain
controllers (BDCs) as well. If the PDC fails or
becomes inaccessible, its duties are automatically taken over by one
of the BDCs. BDCs frequently synchronize their SAM data with the PDC
so if the need arises, any one of them can immediately begin
performing domain-controller services without impacting the clients.
However, note that BDCs have read-only copies of the SAM database;
they can update their data only by synchronizing with a PDC. A server
in a Windows domain can use the SAM of any PDC or BDC to authenticate
a user who attempts to access its resources and log on to the domain.

All recent versions of Windows can log on to a domain as clients to
access the resources of the domain servers. The systems that are
considered members of the domain are a more exclusive class, composed
of the PDC and BDCs, as well as domain member servers, which are
systems that have joined a domain as members, and are known to the
domain controllers by having a computer account in the SAM database.

Authentication

When
a user logs on to a Windows domain by typing in a username and
password, a secure challenge and response protocol is invoked between
the client computer and a domain controller to verify that the
username and password are valid. Then the domain controller sends a
SID back to the client, which uses it to create a
Security Access Token (SAT) that is valid
only for that system, to be used for further authentication. This
access token has information about the user coded into it, including
the username, the group, and the rights the user has within the
domain. At this point, the user is logged on to the domain.

Subsequently, when the client attempts to access a shared resource
within the domain, the client system enters into a secure challenge
and response exchange with the server of the resource. The server
then enters into another secure challenge and response conversation
with a domain controller to check that the client is valid. (What
actually happens is that the server uses information it gets from the
client to pretend to be the client and authenticate itself with the
domain controller. If the domain controller validates the
credentials, it sends an SID back to the server, which uses the SID
to create its own SAT for the client to enable access to its local
resources on the client’s behalf.) At this point,
the client is authenticated for resources on the server and is
allowed to access them. The server then uses the SID in the access
token to determine what permissions the client has to use and modify
the requested resource by comparing them to entries in the ACL of the
resource.

Although this method of authentication might seem overly complicated,
it allows clients to authenticate without having plain-text passwords
travel through the network, and it is much more difficult to crack
than the relatively weak workgroup security we described earlier.

Name service with WINS and DNS

The Windows
Internet Name Service (WINS) is Microsoft’s
implementation of a NetBIOS name server (NBNS). As such, WINS
inherits much of NetBIOS’s characteristics. First,
WINS is flat; you can have only simple machine names such as
inca, mixtec, or
navaho, and workgroups such as PERU, MEXICO, or
USA. In addition, WINS is dynamic: when a client first comes online,
it is required to report its hostname, its address, and its workgroup
to the local WINS server. This WINS server will retain the
information so long as the client periodically refreshes its WINS
registration, which indicates that it’s still
connected to the network. Note that WINS servers are not workgroup-
or domain-specific; they can contain information for multiple domains
and/or workgroups, which might exist on more than one subnet.

Multiple WINS
servers can be set to synchronize with each other. This allows
entries for computers that come online and go offline in the network
to propagate from one WINS server to another. While in theory this
seems efficient, it can quickly become cumbersome if several WINS
servers are covering a network. Because WINS services can cross
multiple subnets (you’ll either hardcode the address
of a WINS server in each of your clients or obtain it via DHCP), it
is often more efficient to have each Windows client, regardless of
the number of Windows domains, point themselves to the same WINS
server. That way, only one authoritative WINS server will have the
correct information, instead of several WINS servers continually
struggling to synchronize themselves with the most recent changes.

The currently active WINS server is known as the primary
WINS server. You can also install a secondary WINS
server, which will take over if the primary WINS server fails or
becomes inaccessible. Both the primary and any other WINS servers
will synchronize their address databases on a periodic basis.

In the Windows family of operating systems, only a server edition of
Windows NT/2000 can act as a WINS server. Samba 2.2 can function as a
primary WINS server, but cannot synchronize
its database with other WINS servers. It therefore cannot act as a
secondary WINS server or as a primary WINS server for a Windows
secondary WINS server.

WINS handles name service by default, although Microsoft added DNS
starting with Windows NT 4 Server. It is compatible with DNS that is
standard on virtually every Unix system, and a Unix server (such as
the Samba host) can also be used for DNS.

Trust relationships

One additional aspect of Windows NT domains not yet supported in
Samba 2.2 is that it is possible to set up a trust relationship between domains, allowing clients
within one domain to access the resources within another without the
user having to go through additional authentication. The protocol
that is followed is called pass-through authentication,
in which the
user’s credentials are passed from the client system
in the first domain to the server in the second domain, which
consults a domain controller in the first (trusted) domain to check
that the user is valid before granting access to the resource.

Note that in many aspects, the behaviors of a Windows workgroup and a
Windows NT domain overlap. For example, the master and backup
browsers in a domain are always the PDC and BDC, respectively.
Let’s update our Windows domain diagram to include
both a local master and local backup browser. The result is shown in
Figure 1-13.

Figure 1-13. A Windows domain with a local master and local backup browser

The similarity between workgroups and NT domains is not accidental
because the concept of Windows domains did not evolve until Windows
NT 3.5 was introduced, and Windows domains were forced to remain
backward-compatible with the workgroups present in Windows for
Workgroups.

Samba can function as a primary domain controller for Windows
95/98/Me and Windows NT/2000/XP clients with the limitation that it
can act as a PDC only, and not as a BDC.

Samba can also function as a domain member
server, meaning that it has a computer account
in the PDC’s account database and is therefore
recognized as being part of the domain. A domain member server does
not authenticate users logging on to the domain, but still handles
security functions (such as file permissions) for domain users
accessing its resources.

Active Directory Domains

Starting with Windows 2000, Microsoft has introduced
Active
Directory, the next step beyond Windows NT domains. We
won’t go into much detail concerning Active
Directory because it is a huge topic. Samba 2.2 doesn’t
support Active Directory at all, and support in Samba 3.0 is limited
to acting as a client. For now, be aware that with Active Directory,
the authentication model is centered around
Lightweight Directory
Access Protocol (LDAP), and name service is provided by DNS instead
of WINS. Domains in Active Directory can be organized in a
hierarchical tree structure, in which each domain controller operates
as a peer, with no distinction between primary and backup controllers
as in Windows NT domains.

Windows 2000/XP systems can be set up as simple workgroup or Windows
NT domain clients (which will function with Samba). The server
editions of Windows 2000 can be set up to run Active Directory and
support Windows NT domains for backward compatibility
(mixed mode). In this case, Samba 2.2 works
with Windows 2000 servers in the same way it works with Windows NT
4.0 servers. When set up to operate in native mode,
Windows 2000 servers support only
Active Directory. Even so, Samba 2.2 can operate as a server
in a domain hosted by a native-mode Windows 2000 server, using the
Windows 2000 server’s
PDC emulation mode. However, it is not
possible for Samba 2.2 or 3.0 to operate as a domain controller in a
Windows 2000 Active Directory domain.

If you want to know more about Active Directory, we encourage you to
obtain a copy of the O’Reilly book,
Windows 2000 Active Directory.

Can a Windows Workgroup Span Multiple Subnets?

Yes, but most people who have
done it have had their share of headaches. Spanning multiple subnets
was not part of the initial design of Windows NT 3.5 or Windows for
Workgroups. As a result, a Windows domain that spans two or more
subnets is, in reality, the
“gluing” together of two or more
workgroups that share an identical name. The good news is that you
can still use a PDC to control authentication across each subnet. The
bad news is that things are not as simple with browsing.

As mentioned previously, each subnet must have its own local master
browser. When a Windows domain spans multiple subnets, a system
administrator will have to assign one of the computers as the
domain master
browser. The domain master browser will keep a
browse list for the entire Windows domain. This browse list is
created by periodically synchronizing the browse lists of each local
master browser with the browse list of the domain master browser.
After the synchronization, the local master browser and the domain
master browser should contain identical entries. See Figure 1-14 for an illustration.

Figure 1-14. A workgroup that spans more than one subnet

Sound good? Well, it’s not quite
nirvana for the following reasons:

If it exists, a PDC always plays the role of the domain master
browser. By Microsoft design, the two always share the NetBIOS
resource type <1B> and (unfortunately)
cannot be separated.

Windows 95/98/Me computers cannot become oreven contact a domain master browser. This means
that it is necessary to have at least one Windows NT/2000/XP system
(or Samba server) on each subnet of a multisubnet workgroup.

Each subnet’s local master browser continues to
maintain the browse list for its subnet, for which it becomes
authoritative. So if a computer wants to see a list of servers within
its own subnet, the local master browser of that subnet will be
queried. If a computer wants to see a list of servers outside the
subnet, it can still go only as far as the local master browser. This
works because at appointed intervals, the authoritative browse list
of a subnet’s local master browser is synchronized
with the domain master browser, which is synchronized with the local
master browser of the other subnets in the domain. This is called
browse list propagation.

Samba can act as a domain master browser in a Windows NT domain, or
it can act as a local master browser for a subnet, synchronizing its
browse list with the domain master browser.

[5] This
was originally called Network Neighborhood in Windows 95/98/NT,
but Microsoft has changed the name to My Network Places in the more
recent Windows Me/2000/XP. We will continue to call it Network
Neighborhood, and if you’re using a new version of
Windows, be aware that My Network Places can act a little differently
in some ways.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, interactive tutorials, and more.