SWAT then becomes available at the http://localhost:901 URL. Accessing it means using the root account (and its usual password). Note that SWAT rewrites the smb.conf in its own idiom, so it makes sense to make a backup copy beforehand if you're only interested in testing this tool.
SWAT is very user-friendly; its interface includes an assistant that allows defining the server's role in three questions. All global options can still be configured, as well as those for all the existing shares, and of course new shares can be added. Each option comes with a link to the relevant documentation.
DOCUMENTATION Going further
The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as main domain controller, but it can also be a simple server on the domain and delegate authentication to the main controller (which could be a Windows server).
The documentation available in the samba-doc package is very well written. In particular, the Samba 3 By Example document (available as /usr/share/doc/samba-doc/htmldocs/Samba3-ByExample/index.html) deals with a concrete use case that evolves alongside the growing company.
TOOL Authenticating with a Windows Server
Winbind gives system administrators the option of using a Windows NT server as an authentication server. Winbind also integrates cleanly with PAM and NSS. This allows setting up Linux machines where all users of an NT domain automatically get an account.
More information can be found in the /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/winbind.html file.
11.5.1.1. Configuring with debconf
The package sets up a minimal configuration based on the answers to a few Debconf questions asked during the initial installation; this configuration step can be replayed later with dpkg-reconfigure samba-common samba.
The first piece of required information is the name of the workgroup where the Samba server will belong (the answer is FALCOTNET in our case). Another question asks whether passwords should be encrypted. The answer is that they should, because it's a requirement for the most recent Windows clients; besides, this increases security. The counterpart is that this required managing Samba passwords separately from the Unix passwords.
The package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.
The next question is about whether servers should be started by inetd or as stand-alone daemons. Using inetd is only interesting when Samba is rarely used; the Falcot administrators therefore picked stand-alone daemons.
Finally, the package proposes creating a /var/lib/samba/passdb.tdb file for storing encrypted passwords; this option was accepted, since this system is much more efficient than the standard /etc/samba/smbpasswd text file.
11.5.1.2. Configuring Manually
11.5.1.2.1. Changes to smb.conf
The requirements at Falcot require other options to be modified in the /etc/samba/smb.conf configuration file. The following excerpts summarize the changes that were effected in the [global] section.
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = FALCOTNET
# server string is the equivalent of the NT Description field
server string = %h server (Samba %v)
# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
wins support = yes
[...]
####### Authentication #######
# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
security = user
# You may wish to use password encryption. See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
encrypt passwords = true
# If you are using encrypted passwords, Samba will need to know what
# password database type you are using.
passdb backend = tdbsam guest
[...]
########## Printing ##########
# If you want to automatically load your printer list rather
# than setting them up individually then you'll need this
load printers = yes
# lpr(ng) printing. You may wish to override the location of the
# printcap file
; printing = bsd
; printcap name = /etc/printcap
# CUPS printing. See also the cupsaddsmb(8) manpage in the
# cups-client package.
printing = cups
printcap name = cups
[...]
######## File sharing ########
# Name mangling options
; preserve case = yes
; short preserve case = yes
unix charset=ISO8859-1
Indicates that Samba should act as a Netbios name server (WINS) for the local network.
This is the default value for this parameter; however, since it is central to the Samba configuration, filling it explicitly is recommended. Each user must authenticate before accessing any share.
Tells Samba to automatically share all local printers that exist in the CUPS configuration. Restricting access to these printers is still possible, by adding appropriate sections.
Specifies the printing system in use; in our case, CUPS.
Specifies the character set and encoding used for file names under Linux. The default value is UTF8 (Unicode).
11.5.1.2.2. Adding Users
Each Samba user needs an account on the server; the Unix accounts must be created first, then the user needs to be registered in Samba's database. The Unix step is done quite normally (using adduser for instance).
Adding an existing user to the Samba database is a matter of running the smbpasswd -a user command; this command asks for the password interactively.
A user can be deleted with the smbpasswd -x user command. A Samba account can also be temporarily disabled (with smbpasswd -d user) and re-enabled later (with smbpasswd -e user).