Samba

NEAL ASPINALL

Recently, corporations have been waking up to a revolution in their back
pockets. Linux has been quietly invading many corporate networks and setting up residence there.
Often, it will have been in operation for some time before most people even realize it’s there. And
then they’ll discover it, performing some mission, some critical application, and doing the job
better than the alternatives. Linux has been put to work providing services to corporations
worldwide, acting as firewalls, routers, file servers, and print servers, and performing its duties
reliably and inexpensively, with a minimum investment in hardware. The key to this success has been
stealth. It does the job and does it well, without drawing attention to itself.

There is an old adage that goes something like: “Do a job well and nobody will know you are
there. Do a job poorly and everybody will know your name”.

For Linux to infiltrate workplace environments and provide services to users running Windows, it
has to provide Windows-like services — transparently integrated with the Windows network. It must
also have the ability to make use of the services available in the Windows networking environment.
The Samba software suite provides all of this, performing its functions well enough and
inconspicuously enough that it rarely gets noticed, even as it readily aids the integration of
Windows and UNIX networking.

The Samba Suite

The Samba software suite is a collection of Netbios programs that implements the Server Message
Block (SMB) protocol (the native networking protocol of Microsoft Windows) on top of TCP/IP. SMB is
evolving into the next generation’s protocol, referred to as the Common Internet File System (CIFS).
It is based on the earlier Lan-Manager and NetBios protocols. RFCs are the standards documents of
the Internet Engineering Task Force (IETF), and RFC 1001 & 1002 (sometimes called the Network
Control Block, (NCB) protocol) describes NetBios over TCP/IP. New standards which will include the present SMB are under development now for the CIFS protocol. Samba implements both the
SMB and NCB layers in the Windows network model, as well as providing both client and server
applications.

Samba is the glue that makes transparent integration between Linux (and UNIX — Samba runs on
many flavors of UNIX) systems and Windows networking stick. With Samba servers running on Linux
systems, Windows boxes have access to Linux file systems and print services. Samba client
applications provide the Linux systems with access to services available in the Windows systems.
None of this requires changes on the Windows side of the networking equation, and Linux systems can
be integrated with the Windows systems without the Windows users being aware that they aren’t
accessing non-Windows systems.

Name Services & Identification

In its simplest form, Windows network naming is based on a broadcast model. This works something
like a shouting match — a system wishing to participate in Windows networking broadcasts its name
to every other system on that subnet. If no other systems object, the name is registered to that box
and it proceeds to use the name. Conversely, to locate a system by name, the name request is
broadcast on the network and the system holding that name responds. Samba is able to participate and
provide this level of name service for both registering its names on the network and looking up
other names. NetBios name service is provided by the nmbd component of Samba. This allows a
Linux box to register its name and be recognized by Windows systems.

On the Linux side of the fence, Samba includes an nmblookup utility which performs
functions similar to what nslookup does for Domain Naming Service, (DNS). With this
utility, one can query the Windows network for a name and get the address(es) associated with that
name.

Each Windows system generally has multiple names associated with it. Part of the name is also
the service that it is identifying. The server or workstation itself has a name identifying the
system. The user who is logged onto a system may also have one or more names registered on the
network.

Most of these names are “individual names” and must be unique on the network. They will identify
the location (address) of a specific machine, service, or user within the Windows network.

Some of the names can be “group names”. These names can appear on multiple systems and in
different locations within the Windows network. Group names are used for functions similar to some
multicasting services.

The Windows messenger pop-up service is one that uses group names. A message to the pop-up
service will pop up on all of the systems with the registered group name (generally the user login
name). Samba supports sending messages to the messenger pop-up service, can support receiving
messages from the pop-up service, and can invoke a configured external program such as LinPopup for
handling incoming pop-up messages.

Browsing & Master Browsers

The broadcast mode name service works for small networks on a single subnet, but generates a lot
of broadcast traffic and does not scale well to larger networks. Broadcast mode name service also
does not work between different subnets and is difficult to use efficiently for browsing. This is
where master browsers and name servers come in.

Browsing allows a user at one workstation to view or browse the names on the network. To have
all of these names, the workstation must have received and stored all of the name broadcasts itself
or it would have to broadcast a request for all of the workstations to “report to it” with their
names. The former is highly unlikely and the latter is extremely wasteful of network resources.

To support the browsing of the network, a master browser is used. The master browser is a
selected system which caches the browsing information broadcast by the other systems. When a system
wishes to “browse the network neighborhood” it only needs to query the master browser for the
information that it requires. It doesn’t need to cache the information itself, nor does it need to
burden the network with even more broadcast request and response traffic.

The master browser is chosen through an election process. If a master browser is rebooted or
becomes unavailable, an election is held between the available workstations for the station most
able to take over this task. The new master browser then updates its cache of information from other
workstations and begins responding to browser requests. A station can “force” a browser election if
it thinks that it has better information or capabilities than the current master browser.

Because Linux systems are rebooted far less often than Windows systems and the reliability of the
master browser depends on its availability, Linux systems make far better master browsers than
Windows systems do. With a Linux system as a master browser, there is far less need for browser
elections and cache refreshing.

Samba can be used as the master browser for Windows networking. It can be configured to force
browser elections as well as to participate in them. Through the use of the OS level, Samba can be
configured to be the preferred master browser, overriding even the other Windows NT systems on the
network. It is, however, also possible to misconfigure a network in such a way that it results in
constant browser elections and subsequent arguing between systems which want to be the master
browser. Forcing elections should be done with caution.

Subnetworks & WINS

Using a master browser still depends on the “B” mode, or broadcast mode, of the Windows name
system. This restricts its ability to work across routers and between subnets. To work across
networks where broadcast mode doesn’t function, the name service needs a designated name server.
This is where the Windows Internet Name Service (WINS) comes into play. WINS is roughly equivalent
in functionality to a dynamic DNS. The idea is that, rather than broadcasting your naming requests
to everyone, you communicate with a single entity — the name server.Because this doesn’t depend on
broadcast packets, the WINS service works just as well between subnets and routed networks as it
does within a single subnet.

In spite of the similarity between the browsing service and WINS, the two services perform
different functions on a Windows network. If a WINS service exists on the Windows network, the
master browser will use the WINS server for name to address resolution. The master browsers will
continue to respond to browsing requests on their respective subnets.

Samba can be set up to use a pre-existing WINS server. It will then send its name requests to
the server and process information back from the server. In this way, Samba can be integrated into
an existing Windows naming system just like any Windows workstation, without additional servers or
configuration tables. Not only can Samba act as a client, it can also act as the WINS server itself.
The advantages which make Linux systems superior choices as master browsers hold equally true for
WINS servers. Simply put, Linux systems are rebooted less often, making them better choices for
critical network components. The only difference that the users would notice, if they noticed
anything at all, would be improved network response and reliability.

Samba can also be used to provide a WINS proxy service on the network for clients which are not
WINS capable (older Windows systems, for instance). It will respond to requests from these clients
after querying the WINS server on their behalf.

In some respects, Samba as a WINS server is more versatile than a native Windows WINS server
because it can perform and provide name resolution for Windows clients based on DNS, NIS, or NIS+.
This can be particularly helpful in environments that use name resolution other than DNS or WINS. By
default, Windows can only use only DNS for resolving external Internet names and addresses.

File Sharing & File Servers

Samba can also provide versatile file services to a Windows networking environment. Most of the
same models of file sharing which are offered on Windows systems are available from Samba. Public
shares, available for anyone to access, can be set up with read or read/write permissions. Shares
can be set up which are available only to certain individuals, or lists of individuals.

Since Linux supports the idea of “home directories”, Samba also includes them in its services.
Users logging into personalized shares get their own private directories on the Linux systems. Samba
supports a form of name expansion in share names which can customize the mapping from access to file
system based on the client access name and system name. This allows different workstations to access
different areas depending on the names of the workstation and user connecting to the share.

File shares on Windows systems have two basic access levels. Share level access uses a password
on the share itself to grant or deny access. User level access involves a finer grained access
control based on the user login and permissions. Samba supports similar access control methods for
connecting to shared out file systems. The end user will notice no difference between this and any
other Windows file server.

Since file servers are a central shared component of many networks and workstation clusters, the
reliability of file servers often equates to the reliability of the networks themselves. Users won’t
see Samba supporting a Linux system at the other end of their network drives — they only see a
reliable resource that they can depend on day to day. And, as long as it’s working, most don’t
care.

Some recent independent comparisons of Linux with Samba versus Windows NT on identical hardware
show the Linux systems outperforming Windows on such crucial tasks as file sharing. Though Windows
NT held its own under a light load, as the number of clients increased, Linux outperformed Windows
by as much as 250% for 12 or more client systems (Vaughan- Nichols/Carr, “The Best Windows File
Server: Linux!”) The recently released Samba version 2.0 is known to have even better performance
than the versions which were used in these studies.

Samba supports the ability to store roaming user profiles on the Samba shares. With this, a user
can log into different workstations and have the workstation settings and preferences follow him.
Since these can be stored in the user’s personal “home directory” on the Samba system, there is less
likelihood of users tampering with profiles, or of profiles accidentally getting crossed.

Linux Tools for Windows Networking

NOT QUITE SEVEN LAYERS: A simplified model of the protocol stack employed by an SMB system.

The smbclient utility is an ftp-like application for Linux systems used to get and put
files to and from Windows shares. It can display a directory of a connected share and can build an
archive file from the contents of that share. When copying text files to and from Linux systems, it
can do Linux to Windows end-of-line conversion just like the text mode in ftp. Smbclient
can also print to a shared Windows printer, and is at the heart of the smbprint
script.

Smbclient is not the most user friendly utility in the Samba suite, and is often buried
in other scripts or called from other applications such as smbtar and
smbprint.

* SMBFS

Linux systems also support a kernel level facility, SMB File System (smbfs), for
accessing Windows shares. This file system module treats Windows shares as if they were similar to
NFS remote file systems. In many cases, this is not a bad comparison. A Windows file system share
can be mounted and accessed similarly to an NFS remote file system. However, there are some
significant differences.

NFS supports the idea of different users accessing files over a common “mount”, and maintains
user permissions and access across the remote file systems. Windows SMB shares have no such concept.
A connection to an SMB share carries with it a user ID and password which must be specified at the
time the connection is made. That user ID is used for all file accesses over that connection for the
duration of the connection. Normal ACLs on the remote system will control access permissions as
defined for the connecting user ID. For public shares, this is usually sufficient.

That smbfs connections are required to provide the user ID and password at the time the
connection is established has some consequences. The normal Linux mount command has no
provision for supplying user IDs or passwords. Samba provides an smbmount utility to
establish the SMB connections and set up the smbfs remote filesystem mounts. In addition,
Samba’s smbmount creates a daemon that provides automatic session reconnect in the event
that the session is disconnected from the other end due to temporary network problems. Earlier
versions of smbmount and smbfs did not provide this reconnection and were prone to
lost connections. NFS, which is not a “connected service” is not subject to these problems.

FOOLING WINDOWS CLIENTS: Samba accepts SMB requests and returns SMB responses, making Windows machines think they are on an all-Windows network.

A new facility in Samba 2.0 is a library wrapper called smbwrapper. By “reloading” this
library before running a dynamically linked program, Windows shares can be accessed through the
normal open / read / close library functions. Windows systems become browsable from a path
which begins with /smb. These connections are made on a process by process basis, instead
of a file system by file system basis, as in the case of smbfs. This allows for finer
grained user information, as well as more dynamic browsing of the Windows network. The
smbwrapper library is being incorporated into some utilities, such as Midnight Commander,
and will become a built-in feature. Other advantages of smbwrapper are that it runs on a
larger number of UNIX platforms, while smbfs is currently only a Linux facility. Also,
smbwrapper is more closely modeled after the Windows networking model and less like the NFS
networking model.

The disadvantage with smbwrapper is that connections, or sessions, currently cannot be
shared between different processes. If two applications have the same file open, this requires two
sessions with the file server. Smb-wrapper can be slower than smbfs because it is
required to be build and tear down sessions more often.

Both smbfs and smbwrapper provide useful methods for Linux systems to access
Windows file system shares in a manner consistent with the filesystem model of UNIX. Because of the
inherent nature of the SMB protocol and model, each has its own strengths and weaknesses.

Printing

Next to file access, the most pressing issue with users is printing (login services don’t count
– users think of that as just getting in the way). Printers are often a shared resource on a
network. Far more users have private disk space than have private printers. That makes printer
sharing near and very dear to their hearts. Printer sharing can also be one of the most difficult
items to get to work right.

Samba provides the Windows networking systems access to the UNIX printers. It also provides the
access utilities, smbclient and smbprint, for UNIX systems to access Windows
printers.

The UNIX print queues can be shared by Samba as printer resources under the server name. Users
can browse this and connect to it just as they can any to other Windows shares.

Some Windows systems want to be able to download the print drivers from the server which is
providing the printer share. Samba now provides a facility to store the Windows print drivers and
grant them on request to any connecting systems. Once again, Samba provides a transparent level of
integration, so the users do not have additional work to perform. This does take some initial setup,
requiring the administrator to have previously copied the Windows print drivers into place on the
Samba server. In large networks with many users, however, this extra effort pays off.

When combined with PostScript printing packages like Ghostscript, it is possible for the UNIX
systems to provide enhanced printer services to the Windows systems which they might not otherwise
have. The addition of Ghostscript on a Linux box provides PostScript emulation to printers which
either do not have it or for which the addition of PostScript is prohibitively expensive. In some
cases, PostScript provides print systems that might otherwise refuse to cooperate in a heterogeneous
network environment a common ground on which to communicate.

For the UNIX users who want to print to Windows printers, Samba provides an smbprint
script which is a front-end to smbclient. This can be called directly by users or can
be called as a print filter from within the UNIX print spool system. Once set up, the UNIX users
access the printer as they normally would, through lp or lpr. Red Hat has
simplified the setup greatly with their configuration tools. While PostScript continues to be a
“lingua franca” between printers in a heterogeneous network, RedHat, Linux, and Samba can all
support the various native printer languages over the SMB connections, including graphics and
color.

Samba Security

Two major cornerstones of security are authentication and authorization — determining who you are
and what you can do. UNIX systems support several different authentication mechanisms such as simple
login/password, one-time keys, and kerberos. Some UNIX systems support Access Control Lists (ACLs)
for authorization control, but most rely on simple file system permissions.

Windows likewise has login authentication, which may be a local login or a login to a Windows
domain. Windows NT systems support access control lists, while other Windows systems are limited to
access controls on share level or user level. Access control lists on Windows NT are only available
on file systems which support it, like NTFS. They are not available on FAT or VFAT file systems.

Samba creates several different flavors of integration between the Windows authentication
systems and the UNIX authentication system. Samba can use an existing Windows Domain Controller for
SMB authentication, or it can provide user authentication based on local server authentication
files. Recent versions of Samba can act as a Windows Primary Domain Controller (PDC), and provide
authentication services to the entire Windows network.

Because the encryption models between the UNIX password files and the Windows password are
different and both involve one-way hashing functions, it is not possible to simply convert from one
authentication system to another. Samba provides a mechanism for maintaining the two authentication
systems in sync with each other. It becomes possible to update both authentication systems together.
This eliminates a major administrative headache in heterogeneous networks.

Due to the variety of authentication mechanisms on UNIX systems, this is not a feature which
simply works “out of the box”. It generally takes some effort initially to set up. Once set up and
working, the effort pays off by eliminating requests from users for the administrator to fix their
passwords, and eliminates the confusion of maintaining different sets of passwords in the different
environments.

When using authentication based on the Windows Domain Controller database, Linux users can query
and update information in the Windows Domain system through the rpcclient program. Similar
to the smb-client utility, this utility performs remote procedure functions allowing the
user to update his password or query his user database information in a Windows networking
domain.

At one point, it was possible to use the UNIX password file for authenticating Windows users.
Unfortunately, this depended on the Windows clients using an older LanManager protocol for
authentication which passed the user’s passwords “on the wire”. To say that this was not a good idea
was an understatement. Some enterprising individuals created a web page out on the Internet, that
could trick Windows clients into providing the user’s password to a special rogue server they had
set up. Faced with this degree of embarrassing insecurity, even Microsoft had to do something to
improve the security of their protocols. That meant the end of the older protocol and clear text
passwords.

The latest service packs for Windows NT have now disabled clear text passwords by default. Some
people have published instructions for re-enabling clear text passwords to allow Samba (and other
SMB servers) to work with existing password files. This is still a very bad idea; Samba works
perfectly well with encrypted passwords and there is absolutely no need to compromise the security
of your network to get user authentication to work from Windows systems to Samba. It does require a
little more work on the UNIX systems to set up and maintain the smbpassword file, but the
effort is worth it — security is maintained and the Windows users still have transparent access
with authentication to the UNIX systems.

PAM and NT Authentication

Pluggable Authentication Modules (PAM) is a method for modularizing the various authentication
systems on UNIX. This is currently supported by Red Hat Linux, Solaris, and others. By using PAM,
it’s possible to switch from a simple password system to shadow passwords to NIS to S/Key to
Kerberos, without having to recompile all of the programs and applications that require access to
the authentication and identification data. The pam_nt PAM module allows all of these
applications to authenticate against an NT domain controller or a Samba based PDC. This gives the
network administrator even more flexibility in laying out and coordinating his authentication
scheme. If all of the UNIX systems support PAM, and a PDC already exists (on Windows or UNIX), then
both UNIX logins and Windows logins can be performed against a common authentication database.

* Authorization

The UNIX file system security extends to shared file systems. Non-public shares have user
identifications associated with the access permissions, which are further restricted by the UNIX
file system. Open, public shares have a common “guest” account associated with them which can be
used to restrict read and read/write access to areas under the public directories.

Currently full Access Control Lists (ACLs) are not supported by Samba, but are under
development. While some flavors of UNIX do support ACLs and some work is being done on ACLs for the
ext2fs file system under Linux, this support is not universal. How ACL support under Samba on the
various flavors of UNIX is going to work has yet to be determined.

The lack of ACLs may be a limitation from the standpoint of administrators who desire extensive
control over what users are permitted to do. But Access Control Lists don’t even exist on Windows
systems other than Windows NT, and for common users of the garden variety of Windows systems (3.1,
WfWg, 95, 98, etc.) the presence of ACLs versus UNIX permissions is simply a non-issue. From an
administrator’s point of view, he is either permitted to perform some operation or he isn’t. Still,
this is an issue of ongoing development.

Future Directions

Work remains to be done to permit WINS service replication between Samba based WINS servers and
Windows based WINS servers. When that is complete, a network can have a mix of WINS servers on
various platforms interoperating seamlessly.

And while Samba can be a Windows PDC, it still cannot function as a Backup Domain Controller
(BDC), running with a Windows based PDC. This would allow a Samba-based PDC to interoperate with a
Windows based BDC, which would in turn allow seamless integration of the Domain controllers across
platforms.

Most of the future development effort will improve Samba’s transparency from the view of the
system administrator thereby reducing his burden even further.

As long as Linux can provide improved reliability, superior performance, enhanced services, and
reduced administrative workload to corporate networks, it will continue to infiltrate the corporate
environment to the benefit of all. Linux could not have made the inroads which it already has based
solely on being technically superior. Users and administrators must have some benefit from the
presence of Linux in these environments. Samba provides the glue to transparently integrate Linux
into the Windows networking environment and thus gives Linux the edge in providing advantages to
users and administrators alike.

In heterogeneous networks of mixed UNIX systems and Windows systems, Samba allows users and
administrators to enjoy the best both worlds.

Mike Warfield works at Internet Security Systems and is a member of the Samba Development Team.
He is a founding member of the Atlanta Linux Enthusiasts, and can be reached at
mhw@wittsend.com.