The NetBIOS networking environment began as a joint project of Microsoft and IBM. It originally made use of a non-routable protocol (NetBEUI) that was intended only for small computer networks. NetBIOS itself was subsequently re-implemented over TCP/IP. NetBIOS over TCP/IP still bears the limitations of its original design (i.e., WINS). It's union with TCP/IP would never be described as harmonious. Still, Microsoft has promoted this overworked protocol as the “Common Internet File System,” and it is rare that NetBIOS can be entirely ignored in the networked enterprise, however unfortunate that may be.
Samba is a free implementation of NetBIOS over TCP/IP for UNIX. While there are problems with the design (it forks too many processes), Samba has seen enterprise-class usage and has withstood the associated challenges. The goal of the Samba project is to reproduce the entire network functionality of Windows NT within UNIX (which includes the ability to function as a domain controller).
Samba is an optional component that can be selected during system installation. If it is installed, the Linux system will be a fully operational NetBIOS file server when the system boots for the first time.
If you use Samba, the author would like you to send him a pizza. The Samba website at http://www.samba.org has information on how this might be accomplished. It can be a challenge; he lives in Australia. (And no, the author of this text has not yet sent his pizza, but will if he should have the misfortune of working in Windows in the future.)
Microsoft doesn't like Samba. They have good reason not to like it; recent performance improvements in Samba have made it faster than the default configuration of Windows NT for file and print services on most hardware.
Microsoft dislikes Samba so much that they made password changes to Windows NT Service Pack 3 that prevent it from sharing unencrypted passwords with a Samba server. Samba's default settings are for unencrypted passwords, but these settings can be modified to circumvent this dastardly mischeviousness.
The new encrypted passwords are not compatible with the DES format used
in /etc/passwd or /etc/shadow, so Samba must
have its own distinct password file when encrypted passwords are enabled.
If connecting with either Windows NT Service Pack 3 or higher, or Windows 98 or higher, encrypted passwords must be implemented before these clients will function.
This is done by removing the comments from the following two lines
(they are lines 65 and 66 in /etc/smb.conf):
encrypt passwords = yes smb passwd file = /etc/smbpasswd
The Samba server must then be restarted by running the following command as root:
/etc/rc.d/init.d/smb restart
When this is done, no users will be allowed to login to the Samba
server. Each user must be individually added to the new
/etc/smbpasswd file by root. The method for doing so follows:
# smbpasswd -a luser New SMB password: Retype new SMB password:
The username luser must exist in the /etc/passwd
database when the command is executed. When it is executed, the
/etc/smbpasswd will be created with contents similar to the
following:
# Samba SMB password file luser:500:5EDBBAA6F82E9DD9AAD3B435B51404EE:F908E55FD20399082E5ADEB9792D27D1: :/home/luser:/bin/bash
Once the root user has created the entries in /etc/smbpasswd,
individual users can change their Samba password by running the
smbpasswd command with no arguments.
This procedure must be executed for each user on the system. On a new system, it should be part of the routine to establish a new user account.
However, on an older system where many accounts already exist, it might not be practical to migrate each individual user in this way. In such a case, there is a (rather awkward) method to migrate such users en masse.
To migrate an existing non-encrypted password file into
/etc/smbpasswd, do not set the encryption option in
/etc/smb.conf. First execute the following command as root:
cat /etc/passwd | /usr/bin/mksmbpasswd.sh > /etc/smbpasswd chmod 600 /etc/smbpasswd
This operation will create an entry for each user in
/etc/smbpasswd. They will have the following form:
luser:500:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: :/home/luser:/bin/bash
These entries have no password, and the users cannot change them.
The following options must then be added to /etc/smb.conf:
update encrypted = yes smb passwd file = /etc/smbpasswd
The Samba server must then be restarted by running the following command as root:
/etc/rc.d/init.d/smb restart
At this point, users can login to Samba using older, unencrypted
clients (such as Windows 95), and the /etc/smbpasswd file
will be populated with the encrypted passwords as the users connect.
When the migration is complete, the option:
update encrypted = yes
Contained in /etc/smb.conf can be replaced with:
encrypt passwords = yes
Samba will then switch to the encrypted versions only, and the newer clients can login.
A migration such as the one discussed above will require planning, timing, and forethought, especially for a large enterprise. It should be initiated several months before these newer clients enter a Samba network.
Windows 95 and 98 differ substantially from Windows NT in their ability to make use of network resources. Windows NT will allow the user to change their login identity for a particular server; Windows 95 and 98 will allow only a single login identity for all network resources.
Because of this, it is sometimes convenient to translate an incoming
username to a different UNIX user. To do so, uncomment line 79 in
/etc/smb.conf:
username map = /etc/smbusers
Then, populate /etc/smbusers with the translations:
# Unix_name = SMB_name1 SMB_name2 ... #root = administrator admin #nobody = guest pcguest smbguest luser = FunnyWindowsUser user2 = WindowsUser2 Otheruser diewindowsdie
The root and nobody users are not commented out
of the /etc/smbusers file included in the standard Samba RPM
distribution. It is advisable to remove them.
In a Windows NT network, a centralized computer is responsible for maintaining a list of NetBIOS servers and their browsable shares. This computer is called the “Master Browser.”
If the Windows NT network has a “Domain Controller,” then the Domain Controller is the master browser for the network.
If there is no Domain Controller, then Windows NT Server computers will hold an “election.” The results of the election will determine which Windows NT system will be the Master Browser. If no Windows NT Server systems are available, Windows NT Workstation computers will converse and allocate one of their number as the master browser.
If it is improperly configured, Samba can repeatedly force these elections upon the network in an attempt to become the Master Browser, causing great contention with the true preferred Master Browser.
To halt this behavior, append the following to
/etc/smb.conf:
domain master = no local master = no preferred master = no os level = 0
The /etc/smb.conf file contains a number of important
parameters and example configurations.
An option that deserves consideration is the workgroup name:
workgroup = MYGROUP
This name should be changed to the desired Domain name or Workgroup name for the network.
It is possible that a client will not be able to see a Samba server
because it lies on the far side of a router. If this becomes a problem,
an LMHOSTS file could be created on the client to direct
queries for a host to a particular IP. The location of this file depends
upon the Windows variant being used; it lies in \windows directory
on Windows 95. Look for the file LMHOSTS.SAM (which is a sample
LMHOSTS file with demonstrations of many of the common
configurations); LMHOSTS should be placed in the same
directory as the sample file.
To allow the client to see the Samba server, the LMHOSTS
entry would have the following form:
1.2.3.4 remotehost #PRE
If LMHOSTS files become inconvenient because of a
large number of clients,
the use of a WINS server (either on Samba or NT) should be investigated,
especially in conjunction with DHCP. Samba has a number of options for
WINS services; start with smb.conf for details.
It is also possible that a client cannot connect to the Samba server because the wrong protocols have been loaded. Samba requires TCP/IP support on the client, which is not loaded by default on some versions of Windows (Windows 95 specifically). To enable Windows 95 or 98 to use Samba resources, they must have “Client for Microsoft Networks” and “TCP/IP” loaded in the Network section of the Control Panel. Consult a Windows networking text for more details.
By default, as soon as the Samba server is activated, users can mount their home directories as drive letters on their Windows systems by using a share of the form:
\\remotehost\luser
Where remotehost is the remote Red Hat Samba server, and
luser is any user on that host.
Should this behavior not be desired, remove the following section
from /etc/smb.conf:
[homes] comment = Home Directories browseable = no writable = yes
To create a public browsable area, add an entry of the following form:
# A publicly accessible directory, but read only, except for people in # the "staff" group ;[public] ; comment = Public Stuff ; path = /home/samba ; public = yes ; writable = yes ; printable = no ; write list = @staff
In order to create a set of users able to write to such a directory,
an entry for staff must be created and populated with the
selected users in /etc/group. Note also that the directory
permissions must also be set to writable for the staff group,
as UNIX permissions will still apply.
The following example demonstrates the “valid users” directive:
# The following two entries demonstrate how to share a directory so that two # users can place files there that will be owned by the specific users. In this # setup, the directory should be writable by both users and should have the # sticky bit set on it to prevent abuse. Obviously this could be extended to # as many users as required. ;[myshare] ; comment = Mary's and Fred's stuff ; path = /usr/somewhere/shared ; valid users = mary fred ; public = no ; writable = yes ; printable = no ; create mask = 0765
Demonstrated below is the procedure for mapping these server resources on Windows clients. First, in Windows 98, “right click” on the My Computer Icon. From this menu, select Map Network Drive.
|
Select an empty virtual drive and enter the share to be mapped.
 |
Provide the server password to complete the connection.
 |
The procedure in Windows NT is slightly different.
 |
Windows NT allows the user to “Connect As” (a feature sorely lacking in the Windows 95/98 releases).
 |
Provide the server password to complete the connection.
 |
By default, all system printers are shared through Samba. This behavior
is controlled by the following lines in /etc/smb.conf:
# if you want to automatically load your printer list rather # than setting them up individually then you'll need this printcap name = /etc/printcap load printers = yes
Remove this section if this is not the desired behavior.
If it is removed, the following example from /etc/smb.conf
can be used to share an individual printer:
# A private printer, usable only by fred. Spool data will be placed in fred's # home directory. Note that fred must have write access to the spool directory, # wherever it is. ;[fredsprn] ; comment = Fred's Printer ; valid users = fred ; path = /homes/fred ; printer = freds_printer ; public = no ; writable = no ; printable = yes
It is also possible to specify the print command that should be used:
[laser] comment = Laser Printer path = /var/spool/samba printer driver = "Generic Laser" print command = lpr -P lp1 %s public = no writable = no printable = yes
Linux can participate as a client in Windows NT networks. It can access both file and printer shares.
If a remote server is running TCP/IP and has available shares, they can
be accessed via the smbmount command (please note that the
standard mount command is not used for this purpose).
The following command, when run by root, mounts a share called
data
on the remote host nthost on the local /mnt
directory:
smbmount //nthost/data -c 'mount /mnt'
This command will first prompt for a password, then mount the share
off /mnt.
This command assumes that there is a “root” user defined on
the remote system, and that nthost is visible on the local
network.
A different remote user name for accessing the remote host can be specified
with the -U option:
smbmount //nthost/data -U luser -c 'mount /mnt'
Should the remote host not be easily visible on the local network,
the -I option can
be used to specify a host name or IP address:
smbmount //nthost/data -I nthost.com -c 'mount /mnt'
The file permissions model on NT servers is usually much different from UNIX. If the NT server is using a FAT file system, there is no permissions on files. If the server is using NTFS, its security model is actually more flexible than UNIX, but it is not compatible. Options can be specified that control the user, group, file mode and directory mode that Linux will assign the mounted file system:
smbmount //nthost/data -U luser -I nthost.com \ -c 'mount /mnt -u 500 -g 500 -f 644 -d 755'
Adding a Windows printer as a Linux system printer is relatively straightforward. As the root user under X-Windows, run the following command:
printtool
The Print System Manager will appear, as shown in Figure 8-1:
 |
Select the “add” button, and the dialog in Figure 8-2 will be presented:
 |
Select “Lan Manager Printer” and click “OK”:
 |
Click “OK” on the warning dialog to continue:
 |
Add the relevant information to the dialogs and click “OK”:
 |
Any user should now be able to send output to the Windows printer with a command such as:
lpr -Plp0 /etc/passwd
If the NT printer has been installed as the default printer lp,
the -P option above is unnecessary.
It is also possible to use a simple shell script to print to remote
Windows printers. Record the following shell script in the file
winprint:
#!/bin/sh SERVER="NTHOST" SERVICE="PRINTER" USER="luser" PASSWORD="secret" ( echo "print -" cat $* ) | /usr/bin/smbclient "\\\\$SERVER\\$SERVICE" $PASSWORD -U $SERVER -N
An example of using the winprint script could be:
winprint /etc/passwd /etc/group /etc/hosts
There is one extremely important point to make about these SMB printers.
The username and passwords that are entered in the Print System Manager
dialogs are saved and then sourced directly into a shell script.
Because of this, a password of `"";rm -rf /' could be potentially
disastrous. To be safe, limit the sharenames, usernames and passwords
to alphanumeric characters ([A-Za-z0-9]).