\documentclass[a4]{article} \usepackage{boxedminipage} \usepackage{hyperref} \begin{document} \section{Samba} by Alain Knaff \bigskip Samba (named after Microsoft's {\bf S}erver {\bf M}essage {\bf B}lock protocol) is an Open Source/Free Software suite that provides seamless file and print services to Windows clients. It can act as a primary domain controller (authentication server) to all major variants of Windows. The course will show how to: \begin{itemize} \item install the necessary software \item configure samba for some basic file service tasks \item configure samba for to operate as a PDC \end{itemize} \subsection{What is Samba} As the front page at samba.org says, "Samba is an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients." Samba is freely available, unlike other SMB/CIFS implementations, and allows for interoperability between Linux/Unix servers and Windows-based clients. Samba is a software package that gives network administrators flexibility and freedom in terms of setup, configuration, and choice of systems and equipment. Because of all that it offers, Samba has grown in popularity, and continues to do so, every year since its release in 1992. \subsection{Installation \& Configuration} The installation of Samba on Debian GNU/Linux is normally quite easy! The packages are pre-built, and you just have to run {\tt apt-get} for the installation of the needed packages. Thus, the first step is: \begin{verbatim} apt-get install samba smbclient \end{verbatim} This has to be done as root! During the installation, a few questions will be asked to build an initial database. \bigskip\noindent \begin{tabular}{|c|c|} \hline Question&Answer\\ \hline \hline Workgroup/Domain Name?&[country]\\ Use password encryption?&Yes\\ Modify smb.conf to use WINS settings from DHCP?&No\\ How do you want to run Samba?&daemons\\ Create samba password database?&Yes\\ \hline \end{tabular} \bigskip \newpage After the installation, you should be able to do a first test (samba is automatically started from the system). This example assumes that your machine is called {\tt berne}: \begin{verbatim} smbclient -L berne \end{verbatim} This will ask for a password, simply type return, and you will see a list of all shares that are defined, as well as some other servers\footnote{This list of nodes is only shown on a samba server which is a master browser for a workgroup, and only contains nodes of that workgroup. A master browser is not the same thing as a wins server. The master browser, responsible for supplying a list of all servers for the network neighborhood, is dynamically elected. The WINS server, responsible for translating names into IP addresses, is configured statically. For more information about master browsers, see {\tt http://ubiqx.org/cifs/Browsing.html}} \subsubsection{Structure of the configuration file} The configuration file is made up of various {\em sections}. These are named {\tt [section name]}. Most sections represent file or print shares. Parameters which apply to samba as a whole are set in a {\tt global} section. There are are number of reserved shares or sections, such as for example \begin{itemize} \item {\tt printers} defines parameters for printers which are not explicitly listed \item {\tt netlogon} is used for holding the Windows startup scripts when operating as a PDC \item \ldots \end{itemize} \subsection{Samba as a simple file server} \subsubsection{Global parameters} The following global parameters are relevant to simple file server operation: \bigskip\noindent \begin{tabular}{|r|p{10cm}|} \hline Name&Description\\ \hline \hline {\tt workgroup}&Windows workgroup or Domain\\ {\tt NetBIOS name}&NetBIOS name by which a Samba server is known. By default it is the same as the first part of the Unix host name.\\ {\tt wins support}&{\tt yes} if this server should be a wins server, {\tt no} otherwise.\\ {\tt wins server}&the IP address of the Wins server (only set this if {\tt wins support} is {\tt no}).\\ {\tt map to guest}&set this to {\tt Bad User} to allow all users (even not logged in) to browse.\\ \hline \end{tabular} \bigskip Set {\tt wins support} to {\tt no} if you intend to put your server into an existing Windows network, which already has a Wins server. \subsubsection{Per share parameters (all shares)} The following parameters are useful on all shares: \bigskip\noindent \begin{tabular}{|r|l|} \hline Name&Description\\ \hline \hline \tt comment&Informative text to be displayed near share in Windows Browser\\ \tt browseable&If set to {\tt yes} (default), share shows up in network neighborhood, else is hidden\\ \tt public&All users may access this share\\ \tt read only&Users may only read from share\\ \tt available&If set to {\tt no}, share is switched off\\ \hline \end{tabular} \bigskip \subsection{Parameters for file shares} The following parameters are useful on file shares: \bigskip\noindent \begin{tabular}{|r|p{10cm}|} \hline Name&Description\\ \hline \hline \tt path&Path of Unix directory which is exported in this share\\ \hline \end{tabular} \bigskip \subsubsection{Parameters for printer shares} The following parameters are useful on printer shares: \bigskip\noindent \begin{tabular}{|r|p{10cm}|} \hline Name&Description\\ \hline \hline {\tt printing}&Identifies the printing system. One of {\tt cups}, {\tt plp} or {\tt lprng} \ldots\\ \tt printable&must be set to {\tt yes}\\ \tt printer&Unix (Cups, \ldots) printer corresponding to this share\\ \tt path&Path of temporary directory where print jobs are to be spooled to (by default {\tt /tmp})\\ \tt cups options&If your printing system is cups, this specifies the options passed on to cups. Usually, {\tt "raw,media=a4"}. These mean that ``raw'' mode should be used (no postscript processing, because in the Windows world, the ``printer driver'' lives on the client), and that the paper size is {\tt A4}.\\ \hline \end{tabular} \bigskip \subsubsection{Parameters for the global printers share} \label{globalprint} If you don't want to define each printer individually, you can set up a global {\tt printers} share which exports all printers known locally to Windows. For this, set {\tt load printers = yes} in the {\tt global} section, and define a {\tt printers} section. \subsubsection{User management} So far, we have not yet defined any users in Samba. The file server is already usable, but only for anonymous access (guest account). If you want to set up named access, the following parameters need to be defined: \bigskip\noindent \begin{tabular}{|r|p{9cm}|} \hline Name&Description\\ \hline {\tt guest account}&Name of Unix user who will serve anonymous (guest) requests (usually {\tt nobody})\\ {\tt username map}&(Optional) Name of a file which maps long Windows user names to short Unix login names\\ \hline \end{tabular} \bigskip The username map has the following format (left is the Unix login, right the long Windows name): \begin{verbatim} root = admin administrator tridge = "Andrew Tridgell" \end{verbatim} Once these changes are done, you add samba users using the following command: \begin{verbatim} smbpasswd -a user \end{verbatim} These users have to be existing Unix users; the {\tt smbpasswd} command only enables them for samba. \subsubsection{Testing} The following tools are available for testing: \begin{itemize} \item {\tt testparm}: this parses the {\tt /etc/samba/smb.conf}, mentions any errors that it finds, and waits for a keystroke. After the keystroke, it prints out the whole configuration, as understood by samba \item {\tt smbclient}: smbclient is a samba client that allows you to access your file server, just as a Windows workstation would. Of course, it can also be used to access a real Windows server. \begin{obeylines} \tt smbclient -L {\em server} -U {\em user} smbclient //{\em server}/{\em share} -U {\em user} \end{obeylines} The first command logs in as {\em user} and lists all shares on {\em server}. The second command logs in as {\em user} connects to {\em share} on {\em server}. Once connected, the you get an ftp-like command line interface to get and put files on the server. \item log files are put into {\tt /var/log/samba/machine.log}, where {\em machine} is the NetBIOS name of the client having connected. Set {\tt log level} to at least 3 in the global section of {\tt smb.conf} to see a log of all files that are opened. \item {\tt nmblookup}: nmblookup resolves Windows computer names (NetBIOS names) into IP addresses. \begin{obeylines} \tt nmblookup {\em NetBIOSname} \tt nmblookup -U {\em winsServer} -R {\em NetBIOSname} \end{obeylines} The first finds {\em NetBIOSname} using broadcast. The second finds {\em NetBIOSname} by specifically the {\em winsServer}. \end{itemize} \subsubsection{Example} This example shows the configuration file of a simple file server: \begin{verbatim} [global] workgroup = samba printing = cups cups options = "raw,media=a4" load printers = yes encrypt passwords = yes log level = 3 [public] comment = A Test Share browseable = yes public = yes read only = yes path = /samba/public [authenticated] comment = An authenticated share browseable = yes read only = no path = /samba/auth [printers] comment = Printers share printable = yes \end{verbatim} Exercises: \begin{itemize} \item Create the share directories on Unix ({\tt /samba/auth}, {\tt /samba/public}). \item Log in using {\tt smbclient}, using various users, and put files into the shares, where possible \end{itemize} \subsection{Primary domain controller} A primary domain controller acts as an authentication server for all Windows workstations in its domain. Users authenticate to the PDC when they log in to their workstation. Once authenticated, they have access to all resources in the domain, be it on their local workstation, on the PDC, or on other Windows servers participating in the domain. To set up a primary domain controller, you need to \begin{itemize} \item add some attributes to the global sections \item define a {\tt netlogon} share \item define a {\tt homes} share, which will contain Windows' users home directory \item set up a place where roaming profiles are stored \end{itemize} \subsubsection{Global settings} \bigskip\noindent \begin{tabular}{|r|p{12.3cm}|} \hline Name&Description\\ \hline \hline {\tt workgroup}&name of the domain\\ {\tt domain logons}&{\tt yes}\\ {\tt wins support}&{\tt yes} in most cases, unless you've defined several domains\\ &which share a same LAN\\ {\small\tt add machine script}&Script to handle the joining of workstations to the domain: \hbox{\small\tt add machine script=/usr/sbin/useradd -d / -g 100 -s /bin/false \%u}\\ {\tt logon drive}&Drive letter for home directory (default: {\tt Z:})\\ {\tt logon home}&profile location for Windows 95/98\footnote{This path is an UNC which will be interpreted by the workstation.}\\ {\tt logon path}&profile location for Windows NT/2000/XP\footnote{This path is an UNC which will be interpreted by the workstation.}\\ \hline \end{tabular} \bigskip Notes: \begin{itemize} \item Unlike with earlier Samba versions, the drive letter ({\tt logon drive}), profile directory ({\tt logon path}), and others should {\bf not} be enclosed in quotes \item On Debian, by default the {\tt homes} share is declared as non-writable. This must be changed to {\tt writable}, or else profiles won't work! \item The purpose of the {\tt add machine script} is to create the Unix accounts that back the machine accounts which are created when a workstation joins the domain. Care must be taken that those accounts cannot be abused for interactive logins; that's why we set the login shell to {\tt /bin/false}. \item {\tt logon home} and {\tt logon path} are interpreted by the Windows workstation (after substitution of samba variables), and should refer to an existing share. Example: {\tt $\backslash\backslash$\%L$\backslash$\%U$\backslash$profile}. After substitutions of samba variables by the server, this will be {\tt $\backslash\backslash server\backslash user\backslash$profile}, which is then interpreted by the workstation to mean the {\tt profile} directory in the user's home share. \end{itemize} \newpage \subsubsection{Homes share} The homes share represents the user's home directories. Each user will ``see'' a share named after himself, containing his own home directory. \begin{verbatim} [homes] comment = Home Directories browseable = no # By default, the home directories are exported read-only. Change next # parameter to 'yes' if you want to be able to write to them. writable = yes # File creation mask is set to 0700 for security reasons. If you want to # create files with group=rw permissions, set next parameter to 0775. create mask = 0700 # Directory creation mask is set to 0700 for security reasons. If you # want to create dirs. with group=rw permissions, set next parameter # to 0775. directory mask = 0700 \end{verbatim} \subsubsection{Roaming Profiles} On login the user's is copied from the location identified by {\tt logon path} to the local workstation. On logout, it is copied back to the server. On first login, when the user does not yet have a profile on the server, his profile gets initialized from the ``Default User'''s profile. N.B. On Debian, the example config file defines the homes share as non-writable. You need to set this to {\tt writable = yes} in order to allow profiles to be stored here. \subsubsection{Netlogon share} The main purpose of the netlogon share is as a location for the startup script (identified by the {\tt logon script} parameter), which is executed on the client workstation on login. \begin{verbatim} logon script = STARTUP.BAT ... [netlogon] path=/home/samba/netlogon \end{verbatim} \subsubsection{Adding a workstation to the domain} When joining a workstation to the domain, you need to supply a user name and a password on the server, who has the appropriate privileges. One such user is {\tt root}; however in Debian, {\tt root} is marked as {\tt invalid user} in {\tt smb.conf}. In order to enable him, you need to comment out the following line, if present: \begin{verbatim} invalid users = root \end{verbatim} After having made sure that the above line is gone, {\tt root} can now add new workstations to the domain. In many circumstances, however, it may not be desirable to hand out the root password of the server to the people doing the maintenance on the clients. In such cases, you may set up another user in such a way that he is entitled to add machines to the domain. After having created this user (using {\tt useradd} and then {\tt smbpasswd -a}), you declare him to be {\tt admin user} on the reserved {\tt IPC\$} share. \begin{verbatim} [IPC$] admin users = winjoin bigmouse path = /ipc \end{verbatim} % $ The IPC share is a reserved file share which is used for administrative communications among Windows machines. Windows workstations log in to this share for numerous tasks, including joining the domain. The {\tt admin users} parameter defines a space-separated list of users who will enjoy root privileges when connecting to this share. Caution: In addition to its special meaning, the {\tt IPC\$} share may contain files just like any other shares, and the admin users have full privileges on those files. Therefore it is important to point it to a directory which contains nothing of value (create an empty directory {\tt /ipc} just for this purpose). After having set up the {\tt IPC\$} share in this way, the user named {\tt winjoin}, and {\tt bigmouse} are now entitled to add machines to the domain. \subsubsection{Setting up a ``Domain administrator''} \label{domadm} ``Domain administrators'' are users, defined on the PDC, which have administrative privileges on the workstations. They do not, however, have any particular privileges on the server itself. In order to define domain administrators, you need to: \begin{itemize} \item Create or chose a Unix Group which will hold the domain administrators: \begin{verbatim} groupadd domadm \end{verbatim} \item Define this group as domain administrators: \begin{verbatim} net groupmap modify ntgroup="Domain Admins" unixgroup=domadm \end{verbatim} \item add users to this group (by editing {\tt /etc/group}. These users now enjoy administrative privileges on the workstations. \end{itemize} Notes: \begin{itemize} \item The {\tt net groupmap} database may get corrupted, especially when samba's SID changes due to re-installation. In such case execute the following command: {\tt net groupmap cleanup}, and try again. \item Use {\tt net groupmap add \ldots} if the Windows group does not yet exist, and {\tt net groupmap modify \ldots} if it does exist, or else the command will happily create two groups with different SIDs! \end{itemize} \subsubsection{Example} \begin{verbatim} [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = switzerland domain logons = yes encrypt passwords = yes add machine script = /usr/sbin/useradd -d / -G '' -g 100 -s /bin/false %u printing = cups cups options = "raw,media=a4" load printers = yes username map = /etc/samba/user.map ... # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes ... [homes] comment = Home Directories browseable = no # By default, the home directories are exported read-only. Change next # parameter to 'yes' if you want to be able to write to them. writable = yes \end{verbatim} \subsection{Password synchronization} Due to the peculiar way how Windows workstations authenticate to servers and PDCs, the Windows password record format (as stored in {\tt /etc/samba/smbpasswd}) is fundamentally incompatible with Unix' password records (as stored in {\tt /etc/shadow}). By default, these passwords are independent of each other: if the end user changes his Unix password, his Windows password is unaffected, and vice-versa. However, this is rather confusing to the end users, and this is where password synchronization steps in. With password synchronization, the {\tt smbpasswd} utility also changes the Unix password, and vice versa. \newpage \subsubsection{Unix password follows Samba} In order to make the Unix password follow the samba password, two steps are needed: \begin{description} \item[configure samba] : Add (or uncomment) the following lines to {\tt /etc/samba/smb.conf}: \begin{verbatim} unix password change = yes pam password change = yes \end{verbatim} \item[configure pam] : Add the following line to {\tt /etc/pam.d/samba}:\\ {\tt @include common-password} \end{description} You may test password change: \bigskip \begin{obeylines} \tt smbpasswd -r {\em server} -U {\em user} \end{obeylines} \bigskip This command performs the samba password change the same way as a Windows workstation would. Change the samba password of user, and then check (by logging in via {\tt ssh}, for instance), that the Unix password has been changed as well. \subsubsection{Samba password follows Unix} In principle, a similar method should allow to do the synchronization in the other direction, by appending the following line to {\tt /etc/pam.d/common-password}: \begin{verbatim} password sufficient pam_smbpass.so nullok try_first_pass use_authtok \end{verbatim} However, unlike other distributions, such as SuSE, Debian does not ship the {\tt pam\_smbpass} module with its samba. To solve this, you may either: \begin{itemize} \item compile samba from source, and enable the feature: \begin{verbatim} ./configure --with-pam --with-pam_smbpass \end{verbatim} \item simply symlink {\tt /usr/bin/passwd} to {\tt /usr/bin/smbpasswd} \end{itemize} \subsection{Access control} In addition to the normal Unix file permissions, samba allows very fine-grained access control to shares. This section describes how to control access by user, by workstation IP, and how to control the mapping of samba users to Unix users. \subsubsection{Access control by user} The following settings define which users may access a share: \bigskip\noindent \begin{tabular}{|r|l|} \hline Name&Description\\ \hline \hline \tt valid users&Users who may connect to this share\\ \tt invalid users&Users who may {\bf not} connect to this share\\ \hline \end{tabular} \bigskip Both lists may contain individual users or groups. If a user ends up in both lists at once, {\tt invalid users} takes precedence. \bigskip The following settings define which users may access a share: \bigskip\noindent \begin{tabular}{|r|l|} \hline Name&Description\\ \hline \hline \tt write list&Users who may write to this share\\ \tt read list&Users who may {\bf not} write to this share\\ \hline \end{tabular} \bigskip Both lists may contain individual users or groups. If a user ends up in both lists at once, {\tt write list} takes precedence, i.e. users that are in both lists at once may write. \bigskip The {\tt admin users} setting defines a list of users who are granted administrator access to the share (i.e. they perform all operations on the share as root). \subsubsection{Access control by IP} The following settings define which IP addresses may access a share: \bigskip\noindent \begin{tabular}{|r|l|} \hline Name&Description\\ \hline \hline \tt hosts deny&IP addresses who may not connect\\ \tt hosts allow&IP addresses who may connect.\\ \hline \end{tabular} \bigskip Both lists may contain individual machines or subnets (IP/netmask). If a machine happens to be in both lists at once, {\tt allow} takes precedence. \newpage \subsubsection{Unix rights granted to share users} The following settings define which Unix rights the Samba users get: \bigskip\noindent \begin{tabular}{|r|p{8.5cm}|} \hline Name&Description\\ \hline \hline \tt force user&If this is set, all valid users connecting to the share act as this Unix user\\ \tt force group&If this is set, all valid users connecting to the share act as belonging to this Unix group\\ \tt create mask&``maximal'' set of permissions set on newly created files. If client who creates a file asks to grant more permissions than specified in mask, the additional permission bits are silently ignored. For instance, if the mask does not include the {\em world writable} bit, samba will not create any world writable files, even if client asks it to.\\ \tt directory mask&same {\tt create mask}, but for new directories, rather than files\\ \tt force create mode&``minimal'' set of permissions set on newly created files. If client who creates a file asks to grant less permissions than specified in mask, the missing permission bits are set anyways. For instance, if the mode includes the {\em group readable} bit, samba will make files group readable, even if client didn't ask for group readable files.\\ \tt directory mask&same as {\tt force create mode}, but for new directories, rather than files\\ \tt force security mode&same as mode, but applies to permission bit changes ({\tt chmod}), rather than new object creation. There is a {\tt force security mode}, a {\tt security mask}, a {\tt force directory security mode} and a {\tt directory security mask} (minimal/maximal bit masks, applicable to directories or plain files)\\ \tt dos filemode& The default behavior in Samba is to provide UNIX-like behavior where only the owner of a file/directory is able to change the permissions on it. However, this behavior is often confusing to DOS/Windows users. Enabling this parameter allows a user who has write access to the file (by whatever means) to modify the per- missions on it.\\ \hline \end{tabular} \bigskip \newpage \subsection{Storing printer drivers on the server} When ``installing'' a network printer on a Windows workstation, the GUI usually asks for printer driver configuration, because on Windows, the printer driver is executed on the client, not the server. However, in order to streamline the process of client installation, it is possible to store Windows drivers on the server. These drivers will still be executed on the client, but the setup of the client will now be less cumbersome. There are two methods of storing Windows printer drivers on the server: \begin{itemize} \item {\tt cupsaddsmb}. This is used to associate postscript drivers with a printer. The ``real'' printer driver (which converts postscript into PCL, for instance) continues to run on the print server. \item Using Windows' {\em add printer wizard}. This allows to associate real Windows drivers with a printer; this is useful if Unix drivers are not available, or do not offer access to all the features of the printer. \end{itemize} On the server, the drivers are stored in the {\tt [print\$]} share. On Debian, this share is set up by default as non-writable and not accessible to guest user. Both settings need to be changed: \begin{itemize} \item Uncomment {\tt write list = root @ntadmin}, so that both {\tt root} and members of the {\tt ntadmin} group may actually upload drivers to this share. \item Set {\tt guest ok = yes}, so that local administrators of the client workstations may read the drivers for installation. If you do all installations as the domain administrator, this is not needed. \end{itemize} In general, for adding drivers to the server, the user doing the operation must meet the following conditions: \begin{itemize} \item he must be a {\tt printer admin} (globally, or on the printer's share you want to add) \item he must have write rights to the {\tt [print\$]} share. That includes the {\tt write list} instruction mentioned above, but he also needs to have the necessary Unix rights to the directory backing {\tt [print\$]}. \end{itemize} \subsubsection{Cupsaddsmb} Cupsaddsmb theoretically supports 3 sets of drivers: \begin{itemize} \item Cups' own drivers. Unfortunately, these don't work because there is a version mismatch between the {\tt cupsaddsmb} program currently available and the drivers. \item Adobe's drivers. These do work. \item Microsoft's drivers. \end{itemize} Before running {\tt cupsaddsmb}, the drivers need to be available in the directory {\tt /var/lib/cups/drivers}. {\tt Cupsaddsmb} will then copy them to the print share, generate a custom {\tt .ppd} file, and associate the driver with the target printer. In order to get the Adobe driver files, first download the Postscript driver from Adobe, and install it manually on one workstation. After installation, you may then find all driver files in the following directory: {\tt \%WINDOWS\%$\backslash$SYSTEM32$\backslash$SPOOL$\backslash$DRIVERS$\backslash$W32X86$\backslash$3}. Copy them from there to {\tt /var/lib/cups/drivers} on the server. Now, when adding a printer, just call {\tt cupsaddsmb {\em Printer}}. You may also call {\tt cupsaddsmb -a} to add all printers. Once a printer is set up with the Adobe drivers, it may installed on as many Windows workstations as you want. Cupsaddsmb connects to samba as the current Unix user; a different user may be specified using the {\tt -U} option. \newpage \subsubsection{Add printer wizard} In situations where you want to use a real Windows driver, either because a Postscript driver is unavailable, or does not offer access to all the printer's features, you may want to use the real driver for your printer on your Windows workstations. You can achieve this by using the {\em add printer wizard}. Before you can use the {\em add printer wizard}, you first need to configure an {\tt addprinter command} in your {\tt smb.conf}. This script takes as parameters the printer name, the share name, the port name, the driver name, the location, and a Windows 9x driver location. Its responsibility is only to add the relevant share, and echo the port name to stdout. The actual installation of the driver is performed by Samba itself, so only the 3 first parameters are actually relevant. Here is an example of such a script: \begin{boxedminipage}{0.9\linewidth} \begin{verbatim} #!/bin/sh echo Add printer >>/tmp/err echo "$@" >>/tmp/err # If printer already there, don't add it again if fgrep -q "[$2]" /etc/samba/dynprinter.conf ; then : else (echo "[$2]" echo " printer=$1" echo " comment = port $3" echo " browseable = yes" echo " printable = yes" echo " public = yes" echo " path = /tmp" echo " cups options = \"raw\" " ) >>/etc/samba/dynprinter.conf fi echo $3 \end{verbatim} \end{boxedminipage} \bigskip This scripts appends the new printer share to {\tt /etc/samba/dynprinter.conf}. This file needs to be included by adding the following line to {\tt smb.conf}: \begin{verbatim} include = /etc/samba/dynprinter.conf \end{verbatim} Note that this script adds the parameter {\tt cups options = "raw"} to the share definition. This is needed in order to disable any server-side conversion that may exist for that printer, because now the driver runs on the client. Before you can go ahead, you must be aware that Windows only lets you add printers that do not exist yet (i.e. that Windows does not see). This means that you either need to (temporarily) set {\tt load printers} to {\tt no} (see section~\ref{globalprint}) or add a share for your printer that is {\bf not} browseable. Once the server is suitably prepared, you may invoke the {\em add printer wizard} as follows from one of your Windows workstations: \begin{itemize} \item first locate the server's directory in the Windows Explorer (that's the directory which shows all the shares of the server) \item go into {\tt Printers and Faxes} \item click the right mouse button, and chose {\tt Add printer} \item Go through the menu, and pick the right driver. \end{itemize} When done, you may re-enable {\tt load printers} on the server, or remove the non-browseable printer share. \subsubsection{Using the drivers} Now that one of the above methods has been performed ({\tt cupsaddsmb} or {\em add printer wizard}), you may use the drivers stored on the server for installation on all further Windows workstations. In order to do so, the user logged in to the Windows workstation must have read rights on the {\tt [print\$]} share. This can be achieved in one of the 3 following ways: \begin{enumerate} \item Log in as a domain user which also has administrator privileges on the local machine (i.e. a domain administrator). Set up of a domain admistrator user is described in section \ref{domadm}. \item Make sure the {\tt [print\$]} share is readable by the guest ({\tt guest ok = yes}) \item Manually map a non-public share from the server, and supply credentials (usename and password) that also have access to {\tt [print\$]}. \end{enumerate} Obviously, the first option (domain administrator) is the most convenient. \subsection{Miscellaneous Gimmicks} \subsubsection{Samba variables} Often it is interesting to make values of samba configuration parameters dependent on the environment, such as properties of the client or user connecting to the service. This can be done using {\em samba variables}. Samba variables start with a percent sign (\%) followed by a letter. \bigskip\noindent \begin{tabular}{|r|p{10cm}|} \hline Variable&Description\\ \hline \hline \tt\%U&User name who connected to the share. This is the user name ``requested'', by the client, i.e. before it is changed by {\tt username map}, {\tt force user} or {\tt admin users}.\\ \tt\%u&User name assigned by samba (after taking into account any remapping performed by {\tt username map}, {\tt force user} and {\tt admin user})\\ \tt\%G&Primary Unix group of \%U\\ \tt\%g&Forced group (if set), or primary Unix group of \%u if there is no {\tt forced group} not\\ \tt\%H&Unix home directory of \%u\\ \tt\%m&Net BIOS name of client workstation\\ \tt\%I&IP address of client workstation\\ \tt\%a&Windows variant of client (one of {\tt WfWg}, {\tt Win95}, {\tt WinNT}, {\tt Win2k}, {\tt WinXP}. This variable is particularly useful to use different profile directories for different Windows versions (there may be some issues when {\tt WinNT} and {\tt Win2k} use the same profile, so we better keep them separate).\\ \tt\%L&Net BIOS name of server\\ \hline \end{tabular} \bigskip \subsubsection{User monitoring} \begin{description} \item[\tt smbstatus] : The {\tt smbstatus} command displays the currently logged in users, as well as the shares, locks and files that they have currently open. \item[\tt root preexec] : The {\tt root preexec} and {\tt root postexec} share parameters specify a program that is executed whenever the share is mapped and/or unmapped. It can be used to propagate samba login/logout activity to Unix's {\tt last} facility: \begin{verbatim} root preexec = /usr/X11R6/bin/sessreg -l %m -h %M -a %u root postexec = /usr/X11R6/bin/sessreg -l %m -h %M -d %u \end{verbatim} \end{description} \subsubsection{Time synchronization} The following line, in the global section, enables the samba server to act as a timeserver for its workstations: \begin{verbatim} time server = yes \end{verbatim} To make use of this feature, the client workstation needs to execute the following command (for instance, from its startup script): \begin{verbatim} net time \\berne /set /y \end{verbatim} \subsubsection{Hiding files} \begin{description} \item[hide] The following hides the files with the named extensions (slash-separated list). They can still be accessed by their name, but will not show up in directories (their Dos {\tt H} bit is set) \begin{verbatim} hide files = *.exe/*.scr/ \end{verbatim} \item[veto] The following makes the files with the named extensions (slash-separated list) completely inaccessible to samba. These files cannot be accessed, even if the user knows their name \begin{verbatim} veto files = *.exe/*.scr/ \end{verbatim} \end{description} \subsubsection{Included configuration files} It is possible for {\tt smb.conf} to refer to other configuration files. This may be useful for better organizing the samba configuration, and also for making some configuration aspects dependent on samba variables. \begin{description} \item[complete override] If the named file exists, the current configuration file is overridden (i.e. all settings read from the current file, except location of new file, are forgotten), and new file is read instead. If the named file does not exist, the settings from the current file are retained \begin{verbatim} configuration file = /etc/samba/lib/smb.conf.%m \end{verbatim} \item[include / merge] The new file is read, and its setting merged with those read from the current file: \begin{verbatim} include = /etc/samba/lib/smb.conf.%m \end{verbatim} \end{description} \end{document}