Configuring the Samba Server

Introduction

One of the quickest and easiest ways to save quite a bit of money on your network is to utilize a Suse Linux Enterprise Server (or any other GNU/Linux Server) as a Domain Controller for Windows Clients.

Microsoft not only charges a premium for their Server Software, they also charge you a "License" for every client that accesses a Windows server over a network. These licenses are called "Client Access Licenses" or CALs and are different than the License that you need to run Windows. As of this writing a CAL for Windows 2003 Server from Microsoft costs between $40 - $50 per device depending upon how many CALs you purchase. For instance, if you go with a Windows Server and you have 100 clients connecting to your server, not only do you have to spend the thousand(s) of dollars for their server software, you would also have to spend an additional $4,000 - $5,000 just on Client Access Licenses.

To successfully deploy a Samba server within your Network there are a few things you will want to keep in mind: First, remember that Samba is not a replacement for Active Directory. If you think you want or need all of the features of Active Directory to manage your network, you may want to either stick with a Windows Server or look into more advanced solutions such as Novell's Open Enterprise Server. With that said, I believe (as well as many other admins) that a properly configured Samba Server can be easier to maintain than a Windows Server with Active Directory.

The second thing to keep in mind as you deploy a Samba Server is the fact that a Samba Server's primary role is to allow Windows machines to access the resources on a Unix/Linux server. Those resources (users, groups, shares) must be already be present on the Unix Server in order for samba to work properly. This will become more clear as you read this, but just keep in mind that the Samba Server is like a "window" for Microsoft Windows Clients to access your Unix/Linux Servers (pun intended). This Chapter is written for Suse Linux Enterprise Server, but (hopefully) it is written in such a way that it can be used with any GNU/Linux Distribution with relative ease.

Configuring Samba

With most GNU/Linux Distributions, Samba is normally configured through a single file, smb.conf, which is usually located at /etc/samba/smb.conf. This file is separated into a "global" section and a section for every share that your Samba Server will provide. With Suse Linux Enterprise Server, the Samba server is configured through a graphical Yast module. This module provides an easy way to configure and adjust the Samba Server without having to edit the /etc/samba/smb.conf file by hand.

Since I am trying to provide documentation that is useful for other GNU/Linux distributions (as well as Suse Linux Enterprise Server) I am going to "build" upon a sample smb.conf file that will change as you go through this document. The basic smb.conf file I am going to start with is below, note that this is only the bare minimum and you need to add upon this example as you go through this document for Samba to work properly:

	[global]
		workgroup = WORKGROUP
		netbios name = myserver
		printing = cups
		printcap name = cups
		printcap cache time = 750
		cups options = raw
		map to guest = Bad User
	[homes]
		comment = Home Directories
		valid users = %S, %D%w%S
		browseable = No
		read only = No
		inherit acls = Yes
		
	[printers]
		comment = All Printers
		path = /var/tmp
		printable = Yes
		create mask = 0600
		browseable = No
		
	[print$]
		comment = Printer Drivers
		path = /var/lib/samba/drivers
		write list = @ntadmins root
		force group = ntadmins
		create mask = 0664
		directory mask = 0775
				

Again if you are using Suse Linux Enterprise Server, you do not need the above example as Yast will configure Samba for you. If you are using the above example, you should adjust the workgroup and netbios name accordingly for your server.

Samba Server Roles

Samba can be configured in a variety of ways depending upon your network configuration and what role you want Samba to play within your network (i.e. Standalone Server, Primary Domain Controller, Secondary Domain Controller, etc) . With SLES, when you first launch the Yast Samba Server module it will first scan your networks for available Domains/Workgroups, then it will ask which type of network server you want to setup.

Samba Installation Wizard Workgroup Selection

Samba Installation Wizard Server Type

Samba Installation Wizard: Configuring Workgroup name and Server Type

On the first screen, if you are creating a new Domain or Workgroup go ahead and change the name to whatever you want it to be. If you are creating a Backup Domain Controller, ensure you select the correct Domain and when you hit next it will give you a prompt to join the domain (it will create a computer account in the Domain).

If you are not using Suse Linux Enterprise Server, you can add the following to your /etc/samba/smb.conf file to get the same configuration:

Standalone Server

	domain logons = No
	domain master = No
	security = user
	

Primary Domain Controller

	domain logons = Yes
	domain master = Yes
	local master = Yes
	os level = 65
	preferred master = Yes
	security = user	
	

Secondary Domain Controller

	domain logons = Yes
	domain master = No
	security = user	
	

Samba Backends

Since Samba's job is basically to allow Windows Clients to access Unix/Linux Resources (among other things) and Windows Resources (user accounts, group accounts, etc.) are different than Unix's, Samba needs to have a "Database" that it can use to maintain and "map" these differences together. This "Database" is referred to as a Backend. Samba can use several different types of Backends, the ones I will cover here are a simple text file, a tdbsam database (specifically created for Samba) and an LDAP Database. There are other databases that can be used as Samba Backends, such as MySQL and Novell's eDirectory, but I will not cover them here.

smbpasswd - This backend is a simple text file that basically only stores user accounts and passwords. You should only use this backend on standalone servers that only require a very basic setup.

tdbsam - This backend is a database created for Samba. It holds all of the account information necessary for Samba to act as a Domain Controller. This backend is usually used for sites with a Single Samba Domain Controller, thus should be limited to smaller networks (less than 250 computers).

ldapsam - This backend allows you to store all of the account information into an LDAP database. This gives you the ability to replicate this information to other servers, as well as allow you to create Backup Domain Controllers for your network. Another side benefit of this backend is the fact that both the Unix/Linux Account information and the Windows Account information are stored in the same location.

With Suse Linux Enterprise Server you set the Samba Backend using the Samba Server Yast Module. The setting is under the Advanced Settings drop-down menu located under the Identity Tab.

Samba Identity Tab

Samba User Information Sources

Accessing the User Information Sources page through the Identity Tab

At the User Information Sources Page you can remove the current backend and add the one you want to use. There are a few things to note here: Once you set your backend, do not remove or change the backend or you will lose all of the Windows Account Information that you have created. For instance, if you decide down the road that you want to utilize the ldapsam backend instead of the tdbsam backend, the data you already have (the user accounts, group mappings, etc.) will not be automatically transferred over - you will have to recreate them. Also, you can no longer use 2 backends at the same time, Samba will error out if you do.

If you decide to use the ldapsam backend you will need to configure it to talk to the server correctly. The Samba Server Yast Module now has a separate tab that allows you to fine tune this backend. When using this tab you will soon notice that every time you open the tab, you cannot leave the tab unless you (re)enter the LDAP Password. This password is needed to ensure that Samba can write to the LDAP store. This was changed primarily because with previous versions of SLES many people forgot to enter this password, thus samba would not work correctly with the administrator wondering why (until they checked the logs). Also note that if you want the Unix and Windows password to be the same for your users, you will want to change "Synchronize Passwords" to "yes" under the advanced LDAP settings.

The LDAP Setting tab

Yast's Expert LDAP Settings Page

The Samba Server Yast Module LDAP Settings Pages

When using the LDAP Settings tab you will soon notice that every time you open the tab you cannot leave the tab unless you (re)enter the LDAP Password. This password is needed to ensure that Samba can write to the LDAP store. This was changed primarily because with previous versions of SLES many people forgot to enter this password, thus samba would not work correctly with the Admin wondering why (until they checked the logs). Also note that if you want the Unix and Windows password to be the same for your users, you will want to change "Syncronize Passwords" to "yes" under the advanced LDAP settings.

Whenever you change the Samba Backend and you finish with Samba Server module it will ask you to create the Administrator password. This is the password for the "root" user, which is used for Administrative functions, such as adding computers to the Domain, changing User Passwords, etc. Later on I will show you how you can specify additional groups to have these privileges.

Manually Setting the Backend

If you are not using Suse Linux Enterprise Server or if you simply want to manually set the Backend, add these to your smb.conf file:

smbpasswd: passdb backend = smbpasswd

tdbsam: passdb backend = tdbsam
Be sure to run "smbpasswd -a root" to ensure you (re)create the Admin Account

ldapsam: - note that using this on a GNU/Linux Distro other than SLES requires quite a bit of work to setup LDAP properly, as well as prepped to be used with Samba. Your Mileage May Vary.

	passdb backend = ldapsam:ldap://localhost
	ldap admin dn = cn=Administrator,dc=private,dc=lan
	ldap group suffix = ou=group
	ldap idmap suffix = ou=Idmap
	ldap machine suffix = ou=Machines
	ldap suffix = dc=private,dc=lan
	ldap user suffix = ou=people
	idmap backend = ldap:ldap://localhost
	ldap passwd sync = Yes
	

WINS Server Support

When configuring Microsoft Windows networks, there are multiple ways that the clients receive it's name resolution. Most newer Windows clients use DNS for their name resolution lookups. Older Windows Clients use what is called WINS. This is a database that Microsoft Windows Servers maintain consisting of the names/addresses of all the connected Windows Clients.

Samba can be configured to be a WINS Server, as well as be configured to utilize an existing WINS Server. However, be warned that if you inadvertantly take over the WINS Server role on a network with an existing WINS Server you will most likely run into problems.

To enable WINS Server support on your Samba server, include the following within the Global Section of your smb.conf file:

	wins support = yes

If you wish to utilize another WINS Server for name resolution, enter the following within the Global Section of your smb.conf file:

	wins support = no
	wins server = 10.0.0.251 (IP Address of the WINS Server)

Note - If you are having troubles with newer Windows versions "talking" to older Windows versions, ensure that you enter the WINS Server address in the network configuration of the newer clients. Also note that if you change IP Addresses on your network, you must flush the WINS databases on your Samba server, they are usually located at /var/lib/samba/wins.*

User Accounts

Now that you have a Samba Backend configured you can start populating it with data for your network. As you start adding entries, keep in mind that Samba simply allows Windows Clients access to your Unix/Linux resources. So, do not try to "add" a Windows Group without having a Unix Group already present (or automatically created at the same time).

SLES LDAP User Credentials

With Suse Linux Enterprise Desktop, allowing Users to access your Linux Server is accomplished in a couple of different ways depending upon the Samba Backend you are using. If you decided to go with an LDAP backend the Yast Users module provides a nice graphical way to adjust your user's samba properties. This is done with the "Manage Samba Account Parameters" Plugin.

Launching the Samba Plugin for LDAP Users

Adjusting the Samba Attributes for an LDAP User

Launching the Samba Plugin for LDAP Users and Adjusting User Parameters

As you can see in the above screen shots, you can modify various Samba User parameters directly within the Yast User module. This makes it very easy to maintain the Samba Credentials for your users since it is more or less automatic (simply enable the Samba User Plugin by default).

Manually Adding User Credentials

If you are not using the LDAP Backend on Suse Linux Enterprise Server, or if you are using a different GNU/Linux Distribution, you must manually create the user credentials for Samba. To do this you must enter the following command for every user account on your server (or do this after you create the Unix User account).

	smbpasswd -a username

This will add the relevant information for that user into your backend, whether it be the smbpasswd file (usually located at /etc/samba/smbpasswd) or the tdbsam database (usually located at /etc/samba/*.tdb). Again be warned that if you change your Samba Backend you will have to recreate all of your User Credentials.

Creating the User Accounts in this way can be somewhat of a put-off for some Administrators, some may say: "Why do you have to add the same user twice ?" To get around this annoyance, you can set a script that will automatically add the Unix User Account to your Server when you create the Samba Credentials. A basic script to add to your smb.conf file would look something like these (note that these probably won't work with an LDAP Backend):

	add user script = /usr/sbin/useradd -m %u

You can also set a delete user script similar to:

	delete user script = /usr/sbin/userdel -r %u

For those that are not familiar with Samba, these scripts can be very useful since you can actually manage most of Samba's User and Machine data remotely using Microsoft's User Manager for Domains. This can make Samba a very easy upgrade for people still using Windows NT4 Servers. Also, if you do not want to use Microsoft User Manager, there are other alternatives such as webmin or the included Samba Swat utility (there are also a whole slew of others if you are using the ldapsam backend).

Group Accounts

When setting up a server for file sharing, proper management of groups is a must. Groups can help in sorting out file permission problems when sharing files, help you in locking down your workstations, and even help you to automate certain settings during the user's login.

Similar to User Accounts, the Unix Group Account must already be present on the server, then you must "map" the Unix Group to a Windows Group (usually by running a command on the server). This "mapping" will create all the necessary entries into the Samba Backend that Windows Networking requires (including the Security Identifier). Also of note is the fact that Windows Group Names are different than Unix Group Names, with Unix Groups you should avoid long names (usually you stay at or below 8 characters) and you should not use spaces, Windows Groups do not have these limitations.

SLES LDAP Group Mapping

To show you how to create this group mapping I am going to show you how to create a "Domain Admin" account on your Samba Server so that anyone added to this group will have Administrator privileges when they log onto the Domain at your Windows Machines.

First, you will want to have a Unix Group already present that you will map the Domain Admin Windows Group to. I usually use ntadmins or domadmin on the servers I setup. Some Distributions already create a "ntadmin" group that could be used for this mapping (although if you are using the LDAP Backend you will not want to use this pre-configured Unix group). Since this document is mostly about Suse Linux Enterprise Server I will first show you how to create this mapping using the Yast Group Management Module (using the LDAP Backend).

Launching the Yast Samba Group Plugin

Creating the Group Mapping Using the Yast Samba Group Plugin

Lauching the Yast Samba Group Plugin to create the group mapping

First, open the Yast Group Management Module and either add the ntadmins group, or edit it if it is already created. Then you will go to the "Plugins" tab and add the "Manage Samba attribute of LDAP groups" plugin (if it is not already enabled). Now you will want to "Launch" that plugin to be able to name the Windows Group "Domain Admins". When you are done, click finished and the mapping is done.

Normally this is all you would have to do to map a Unix Group to a Windows Group, however we are creating a Default Windows Group that requires it to have a specific Relative Identifier (RID) to work properly, for the Domain Admins Group that Relative Identifier needs to be 512. So to adjust this for LDAP groups you need to launch the "Yast LDAP Browser" module and login to the local LDAP Server.

Using the Yast LDAP Browser to adjust entries

Adjusting the ntadmins' Group SID using the LDAP Browser

Using the Yast LDAP Browser to Adjust the ntadmins' SambaSID

Once you have the local LDAP tree open, browse to group organizational unit and highlight the group that you created to be "Domain Admins". Now click on the Entry Data tab and go ahead and edit the sambasid to have "512" as the last group of digits (don't forget to save before you exit). After this is done, anyone in the ntadmins group will be considered a "Domain Admin" for your Windows Workstations.

Along with the "Domain Admins" group, you should also create a few other Windows Default Groups: The "Domain Users" Group with a RID of 513, and "Domain Guests" Group with a RID of 514.

Manually Creating the Group Mapping

If you are not using the LDAP Backend with your Suse Linux Enterprise Server, or if you are using another GNU/Linux Distribution, you must manually create the "Group Mapping" in your Samba Backend for Groups to work properly. To show you this I will re-create the same Domain Admins group only this time using the command line utilities. Again you must already have a group created to map to. I will be using a group called "ntadmin" (since SLES already has this group created by default for this purpose).

net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin rid=512 type=d

To check if the mapping worked correctly, issue the "net groupmap list" command. One thing to note when you manually create these mappings; the Relative Identifiers must not overlap (even with user's RIDs).

Again, if your server is going to be a Domain Controller, you should also create groups for: The "Domain Users" Group with a RID of 513, and The "Domain Guests" Group with a RID of 514.

Granting Rights to Domain Admins

Normally, if you stop now, anyone in the "Domain Admins" group has the Administrator privileges on the Windows Workstation when logging in, but does not have any "privileges" to remotely modify the Samba Server (including adding machines to the Domain). This could be a good thing, or it could be a bad thing, it really depends upon the users you will add to the "Domain Admins" group.

If you want these users to be able to also modify the Samba Server you must first set the following in the global section of your smb.conf file (actually, later versions of Samba has this enabled by default):

	enable privileges = yes

Then you must run the following command with the privileges you want to allow:

net rpc rights grant 'DomainName\Domain Admins' SeXXXX -S servername -U root

Where SeXXXX is the rights you want to grant. If you want to specify multiple rights, simply separate the rights with a space. The rights you can specify are:


SeMachineAccountPrivilege - add machines to the Domain
SePrintOperatorPrivilege - manage printers
SeAddUsersPrivilege - add users and groups to the Domain
SeRemoteShutdownPrivilege - remotely shutdown computers
SeDiskOperatorPrivilege - manage disk shares
SeTakeOwnershipPrivilege - take ownership of files

Remotely Managing Groups

Similarly to managing Users with Microsoft's tools (among others), you can also manage groups with Microsoft's User Manager for Domains (and Microsoft's MMC). In order for you to utilize this functionality you must first set a few scripts within your smb.conf file. Generic scripts (which may or may not work with your distribution) are found below - note that these probably will not work if you are using a LDAP Backend:

	add group script = /usr/sbin/groupadd %g 
	delete group script = /usr/sbin/groupdel %g 
	add user to group script = /usr/sbin/usermod -G %g %u

There is also a possibility of adding a "delete user from group script", but it is highly recommended that you manually do that at the Samba Server to avoid inadvertently deleting the user from all their groups (or deleting the user entirely).

Computer Accounts

The way Windows Networking works, to participate in a Domain, every Windows Workstation must have an account created at the Domain Controller. Normally this account is created when the Computer is joined to the Domain, although it can be created before it is joined (some admins consider this a risk).

With Samba, this is accomplished with a script specified in the smb.conf file, which is ran whenever a computer attempts to join the Domain. With Suse Linux Enterprise Server, this script is already specified for you. Other GNU/Linux Distributions may or may not have this script specified, so here is an example:

	/usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$

Once this is set, you would add Computers to the Domain in the exact same way as you would when connecting them to a Windows Server. To join a domain, under Windows XP/2000 right-click on the "My Computer" icon and hit properties. Go to the "Computer Name" tab and hit change. Where it says "Member of" select Domain and enter the domain name that you used, such as "TUX-NET" and hit OK. The workstation will contact your server, and it will ask for a username and password to create a computer account on the server. Simply type in "root" and the root password (or a user that belongs to a group that has the SeMachineAccountPrivilege set) and hit OK, Windows will now become a member of the domain and will ask to restart the computer.

Opening the System Properties to Join the Domain

Specifying the Domain to Join

Opening the System Properties to Join the Domain

Joining Windows NT to the domain is slightly different, instead of right-clicking on "My Computer", right click on the "Network Neighborhood" and select properties, click the change button and enter the domain name. Also, you must check the "create machine account" and enter an appropriate username and password (root account or a user that belongs to a group that has the SeMachineAccountPrivilege set). Once Completed, when you restart the client you will be able to log into the Samba Domain.

Samba Shares

Once you have the Samba Server Role, the Samba Backend and the framework to start adding data into the Samba backend in place, you can then focus on creating Samba Shares that will allow your users to store and share files/folders on your Samba Server.

As you create these Samba shares, the number one objective you want to keep in mind is how to implement a good security policy without forcing the users to be computer experts. Unfortunately, most administrators, as well as Server Operating Systems (including Microsoft Windows Servers) take the least secure way of handling this task, which is to simply allow everyone access to everything by default. However, with most Unix and nearly all GNU/Linux Operating Systems, the security aspect of the filesystem is quite secure by default. This forces the administrator to look for a more secure approach of implementing file sharing on the server, rather than taking the "readable/writable by everyone" approach.

Although most GNU/Linux Distributions now have support for POSIX ACLs (Access Control Lists), the technique that I am going to show you simply takes advantage of the user's group membership information. This allows you to specify that only Group A or Group B can access and/or write to a share. For instance, I will show you how to implement a Samba share named "Office" where only the members of the "office" group will be able to read and write to it.

Creating Samba Shares

If you remember from the first part of this Chapter, Samba is configured through a single configuration file, smb.conf. This file is separated into two parts, the [global] section and a section for every share available on your server. Here is a sample share directive:

[share1]
        comment = Testing Share
        read only = No
        inherit acls = Yes
        path = /srv/exports/share1

Ordinarily you simply edit the smb.conf file and add any share you want on your server, however with Suse Linux Enterprise Server you can utilize the Yast Samba Server module to add any shares you need for your server.

Samba Share Tab of the Samba Server Yast module

Samba Share Tab of the Samba Server Yast module

Now that you have the basic premises down, I am going to step through creating a share for all of the office workers on your network. For this to work properly, you must already have the group created within your system and have that group mapped to a Samba Group (covered in an earlier section).

First, create the directory you are going to use for the share. You also must prep this directory by giving the correct group ownership and permissions. For instance, I usually do the following:

 	mkdir /srv/exports/office
	chgrp office /srv/exports/office
	chmod 2770 /srv/exports/office

This will ensure that the "office" group can write to the directory, while at the same time ensuring that any file or directory added within this directory will be owned by the office group, this is done in case someone accesses this directory from the server or through NFS. (See Appendix I for more information regarding File Permissions.)

Once the directory is "prepped" you can create the share directive within the smb.conf file. The directive I usually use is listed below. Note how I make use of different samba parameters to ensure that only members of the "office" group can access the share.

[office]
        comment = Office Share
        path = /srv/exports/office/
        writeable = yes
        browseable = yes
        guest ok = no
        printable = no
        force group = office
        valid users = @office
        create mode = 0660
        directory mode = 0770
        inherit acls = Yes
        veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

To create this share on a SLES server, click on the "Add" button within the "Shares" tab of the Yast Samba Server module. This will launch the "New Share" screen where you can enter basic information about the share. Then you can click on the "Edit" button to adjust the advanced parameters of the share.

Creating a New Share with SLES

Editing a Samba Share

Creating a New Share and Editing with within SLES

Standard Shares to Implement

When you deploy a Samba Server as a Domain Controller, there are certain shares that you will probably need to implement in order for the server to operate correctly. Some of these shares are listed below, others are covered in other sections.

Homes Share

The Homes Share is a special share that will automatically create a share based on the Username of the person who logs into the client. This ensures that the user's files are readily available without forcing the administrator to create a new share for every user. This share is accessed through \\servername\username

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes
        
	

Netlogon Share

In order to support advanced functions of a Primary Domain Controller, you must create a "Netlogon" share. This share is automatically connected to from a client upon login. You can utilize this share to implement Logon Scripts, System Policies and Network Default Profiles. These implementations are discussed later. Just ensure that everyone logging into your Domain can read the contents of this share.

[netlogon]
        comment = Network Logon Service
        path = /var/lib/samba/netlogon
        write list = root
	

Users Share

Since every user has their own directory, sometimes it may be worthwhile to implement a share that is accessible by the Network Administrators to allow them to have access to all of the User's home directories. Please be aware that you probably need to address any security concerns with the Network's Owner before you implement this share to ensure that you don't inadvertently overstep the organization's computer or network policies.

[users]
        comment = All users
        path = /home
        read only = No
        valid users = @ntadmins
        create mode = 0660
        directory mode = 0770
        inherit acls = Yes
        veto files = /aquota.user/lost+found/
	

Sharing Printers Through Samba

One of the most problematic functions within a Windows Network is printing. From dealing with the installation of different drivers, dealing with the vulnerability of the Windows Print Queue, or simply trying to figure out how to completely remove print jobs on the server, managing a Printer Server can quickly become a full time job on a larger network. Most of these problems can be minimized by deploying Samba Servers for your Windows network printing needs.

Samba Server Confguration for Printer Support

A few years ago it was somewhat difficult to configure Samba to allow Windows Clients to print to it (simply for the fact that different Unixes handled printing in their own way). Fortunately, over time most Unixes standardized on utilizing the CUPS print server for their printing needs. This allowed the Samba developers to focus on communicating with the CUPS server for printing support. The results have made configuring printing on your Samba Servers extremely easy.

The first step to configure your server to share it's printers is to enable CUPS support within your smb.conf file. To do this simply add the following to the "Global Section".

        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw

Then you must add a "printers" share and a "print$" share for the printer drivers within your samba configuration file. Something similar to the following should suffice.

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No
[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = @ntadmins root
        force group = ntadmins
        create mask = 0664
        directory mask = 0775

Now, once samba "re-reads" it's configuration it should automatically add printer shares for every printer configured within your CUPS printer server. It can't get much easier than that.

Adding Windows Printer Drivers to the Server

When sharing printers to Microsoft Windows clients, you have the ability to "install" the printer's drivers onto the server to alleviate the need to install the drivers locally on every computer. This has the advantage of allowing your users to easily add printers to their computer, as well as having a single driver installation on your network to allow for easy driver updates.

There are multiple ways to add the printer's driver to the server, the method I use utilizes the "Printer Properties Page" on the Windows Client and adds the drivers to the server using the "Add Printer Wizard". This method is listed below.

  1. First you must "prep" the Drivers Directory on the Server to ensure that the Printers$ Share has appropriate permissions within the Samba config file as well as correct Unix Permissions set. Also ensure that your Domain Administrator group (or equivalent) has the SePrintOperatorPrivilege set. Finally, simply follow these steps to add the printer drivers to your Samba server:
  2. Browse to the Server through "Network Neighborhood" and Open the "Printers and Faxes Folder".
  3. Right Click on Printer Icon and select Properties - If it asks if you want to install a driver hit NO
  4. Go to Advanced and Select a Driver from the Dropdown menu or hit New Driver. Follow the Add Printer Wizard and it should install the Driver to the Server.
  5. Go to the "Sharing" tab and add any "Additional Drivers" that you may need for that printer.
  6. Finally, rename the Printer to something meaningful for your enviornment.

Adding Network Printers to a Windows Client

There really are two ways to add a network printer to a Microsoft Windows Client. Each one has it's own drawbacks and it will basically boil down to whether or not your Users jump from machine to machine on your network, or if your workstations are used by more than one user.

The most popular way is to simply add a "Network Printer" during the "Add Printer Wizard" and browse to the printer and hit install. This gives you the advantage of having the client computer use the Printer Drivers that are located on the server. However, when this procedure is used, the printer is only installed within the User's Profile, not on the machine, so when that user logs out and another user logs in, the printer that was installed previously is not present for the new user. This can have a detrimental effect if you have a large number of users using the same machine (such as a school setting), or if your users jump from machine to machine on the network.

The second way, which may be more advantageous in certain circumstances, is that you add a "Local Printer" during the "Add Printer Wizard". When the wizard asks for a printer port, hit "New" and type in the name of the Printer Share on the server as the name of the printer port (an example printer port name would be "\\Server\Printername"). When adding a printer in this way, the printer is actually installed "on the machine" instead of "within the User's Profile", which means that any user that logs into the computer will be able to print to the printer. The downside of this method is that it requires you to install the Printer Driver locally on the computer, which means that if you need to update the driver, you must update it on every computer instead of just on the server.

Additional Domain Controller Functions

When dealing with Windows Networking, a good understanding of what Domains are and what options you have when deploying servers in a Domain environment is necessary to ensure that you optimally configure your server(s) for your environment. This section provides basic information on Windows Domain networking that will help you fully configure Samba to be optimized for your network.

User Profiles

Microsoft Windows stores all of the User's Data into what are called "Profiles". With Windows XP (and 2000) these Profiles are located within the "Documents and Settings" folder of the system drive (other Windows versions place these in a different folder). These Profiles not only contain all of the Registry Settings for the User, but also contain their Documents, Favorites, Emails, etc. Over time these profiles can become quite large.

When you implement a Windows Network you are able to place these Profiles onto a network drive if you wish. This gives the advantage of having all user's profiles located at single network location reducing the overhead of backing them up. It also gives you the advantage of having each user's settings "follow" them to whichever computer they happen to login to on the network. When you implement profiles in this way on the network, they are referred to as either "Server Side Profiles" or "Roaming Profiles".

To implement "Roaming Profiles" with Samba, you simply need to create the Profiles share and set a few directives within the Samba configuration file. To create the Profiles Share, simply create a directory on the server to hold the profiles, such as "/srv/samba/profiles" (make sure all users who log into the Domain will be able to write to this directory). Then add a Samba share similar to the following into your smb.conf file.

[profiles]
        comment = Network Profiles Service
        path = /srv/samba/profiles
        read only = No
        store dos attributes = Yes
        create mask = 0600
        directory mask = 0700
        hide files = /desktop.ini/outlook*.lnk/*Briefcase*
        browseable = no

Then you add the following to the Global Section of the smb.conf file. Note that you can even separate out the profiles by different Windows versions if you wish by adding a "%a" at the end of the "logon path" directive ( logon path = \\%L\profiles\%U\%a ).

    logon path = \\%L\profiles\%U
    logon home = \\%L\%U\.9xprofile
    logon drive = P:

Now, if you wish to simply use Local Profiles (Profiles stored on the local machine), you simply set the "logon path" and "logon home" directives to nothing (null). Note that when using Local Profiles the "logon drive" directive will not automatically mount the User's Home folder to a drive letter (so you will probably want to do this with a logon script).

    logon path = 
    logon home = 

System Policies

To control what your user's can and cannot do on your Windows Client Computers, Microsoft implemented what is called "System Polices" (later re-implemented as Group Policy Objects for their Active Directory). These Policies give you the ability to get a handle on your Windows Clients.

This section will cover how to utilize System Policies to attack different problems you may have with utilizing Microsoft Windows Clients. This is not meant to be a full tutorial on using the System Policy Editor, but is here to give you a good understanding of how to utilize good Policies to reduce your "Total Cost of Ownership" in respect of managing Windows Clients. For a full tutorial of using Microsoft's System Policy Editor, visit this page.

In order to fully manage your Windows Clients without resorting to implementing highly complex, unmanageable Policies, I am going to illustrate how you can easily implement an easy to understand, easy to implement "Fool-Proof" System Policy.

The first step in implementing a "Fool-Proof" System Policy is to understand what you want the System Policy to do. Normally, I usually attack Windows Clients from two separate issues. The first issue is to simply use the Policy to change the default behavior of the Windows clients. This allows you to redirect various folders and to adjust the software to make it easier for the user to utilize their computer.

The second issue to tackle using System Policies is to use them to prevent your users from accessing things that they should not access, such as registry editing tools, etc. This issue is where some stumbling blocks may occur. If you do not configure your policies correctly they can easily overlap each other and before you know it all of your users may become affected. To avoid this I will show you how to implement sensible policies based on different Windows Groups.

Changing Default Windows Behavior

Utilizing System Policies to change the default Microsoft Windows behavior can do wonders for your User's output and morale. For instance, using "Folder Redirection" you can reduce the amount of time a User spends waiting for the computer to login as well as reduce the amount of time it takes the user to find the files that they work on. You can also reduce the User's Frustration by changing the erratic behavior of how Microsoft Windows handles different situations.

Folder Redirection: Implementing Folder Redirection can greatly reduce your network bandwidth during logins. It can also move important files from the volatile User's Profile into something more permanent such as their home directory. To utilize folder redirection, ensure the directories you are redirecting to already exist (create them within the "/etc/skel/" folder prior to adding the users to your server), ensure that the user's home folder is mapped to a drive letter (in this case "P:\"), then set the following policies, notice that I give an example of what I usually set it to.

From my custom.adm file (apply to Default User)

  • Custom Application Data Folder - P:\.winsettings\appdata
  • Custom Desktop Folder* - P:\WinDesktop
  • Custom My Music Folder - P:\Music
  • Custom My Pictures Folder - P:\Pictures
  • Custom My Documents Folder - P:\Documents
  • Custom Start Menu* - P:\.winsettings\startmenu
  • Custom Programs Folder* - P:\.winsettings\programs
  • Custom Templates - P:\.winsettings\templates
  • Do NOT Sync Redirected Folders - Ensure this is checked
  • Disable Offline Files - Ensure this is checked

For the folders above with an * ensure that you also set the "Windows NT Shell\Custom folders\Custom ..." Policies (from the default adm files) to the exact same settings. You may notice that there are other redirection options available, however, these may present problems and I don't recommend setting them.

Policies regarding Profiles - Along with utilizing Folder Redirection, there are other policies you can utilize to ensure that your User's Profiles remain somewhat small and manageable. The most important ones are listed below.

  • Default User Properties - Windows NT User Profiles - Exclude directories in roaming profiles - - Good defaults are: "Temporary Internet Files;Temp;Local Settings"
  • Default Computer Properties - Windows NT User Profiles - Delete Cached Copies of Roaming Profiles

There are other Policies that pertain to Profiles, including changing the default options in regards to Roaming Profiles, Limiting the Profile Size, etc. These may be useful in certain deployments.

Changing Other Default Options - Within my "custom.adm" policy template I include quite a few policies to change some of the Windows default options. These policies may be beneficial for your deployment and you should look at them to be implemented within the "Default Computer" or "Default User" Policy group (as these are applied to everyone who logs into your network).

Creating Lock-Down Policies

The other important function of Policies is to restrict your Users from doing something they should not be doing (such as editing the registry). This seems like it would be straightforward, but many administrators find stumbling blocks when these restrictive policies inadvertently get applied to some users.

To avoid these issues, the easiest way to implement these restrictive policies is to create various Windows Groups that have no other purpose on your network except to apply restrictive policies. For instance, you can create a "Normal Policy" group that has moderate restrictions applied, then create another Windows Group called "Restrictive Policy" that has further restrictions on it's users. The trick here is to add the User to only one of these Groups. This virtually eliminates the problems where a User is a member of multiple Groups that have different Policies applied.

Finishing Up the Policies

Once you create your Policy File, save it as "NTConfig.POL" and copy it to the "NETLOGON" share of all of your Domain Controllers. Whenever a User logs into a Windows Client it will check for this file and apply the policies to that User (and computer). Just remember that Microsoft Windows Vista clients will not apply any System Policies, so you will probably have to rely on local policies and/or login scripts if you utilize Windows Vista Clients.

Logon Scripts

Another way of controlling clients is through the use of Logon Scripts. Whenever a user logs into a workstation connected to the Samba Domain, you can force the computer to run a script. This allows you to do various tasks such as syncing the time or mapping network drives to drive letters.

To force a script to execute when the user logs into the machine, simply add the following directive within the Global Section of the smb.conf file:

logon script = login.bat

Where "login.bat" is a DOS based text file which includes something similar to:

	net time \\Servername /set /yes
	net use L: \\Servername\Company /persistent:no
	net use O: \\Servername\Office /persistent:no

Most of the deployments I configure, I usually make use of the Kixtart scripting language to give some sort of reconfigurability to the Logon script without having to resort to create one for every user. For instance, I always create shares that are only accessed by members of certain groups, so I simply create an IF statement stating that if the user is in this group map a drive letter to this share. For instance, an example script I use is:

BREAK OFF
$ = SETTITLE("Domain Login")
BIG
COLOR G/N
?@DOMAIN
?
SMALL
COLOR W/N
?@TIME " - " @WKSTA " - " @USERID
?"Do not close this Window, it will automatically close"
?
        USE P: "\\Servername\" + @USERID
IF InGroup( "Domainname\Domain Admins", "Servername\Domain Admins" )
        SetTime "\\Servername"
ENDIF
IF InGroup( "Domainname\Company", "Servername\Company" )
        USE L: "\\Servername\Company"
ENDIF
IF InGroup( "Domainname\Office", "Servername\Office" )
        USE O: "\\Servername\Office"
ENDIF
IF InGroup( "Domainname\NetAdmins", "Servername\NetAdmins" )
        USE Z: "\\Servername\AdminUtils"
ENDIF

Then, I simply set "logon script = kix32 login.kix" within the smb.conf file and ensure that the kix32.exe file is located within the netlogon share. Also, to reduce network bandwidth I always copy the kix32.exe file into the PATH of the Windows Workstations as the Windows command interpreter will utilize the local copy of kix32.exe to interpret the script (as opposed to the one within the netlogon share).

Samba Parameters

Samba Separates it's configuration file into a "Global Section" and a section for each "Share". This is not a complete reference and does not include the parameters that have been covered within the Samba Chapter, but it does include the ones that may pertain to most networks. Also remember that you can utilize what are called "variable substitutions", some of these include:

  • %U - session username
  • %m - the NetBIOS name of the client machine
  • %L - the NetBIOS name of the server
  • %a - the architecture of the remote machine
  • %I - the IP address of the client machine

Useful Global Samba Parameters

bind interfaces only
Allows you to limit which interfaces will serve SMB requests (yes or no)
deadtime
The number of minutes of inactivity before a connection is considered dead, and it is disconnected. This can be useful to reduce the amount of connections to your server. Most clients will auto-reconnect if needed so this is safe to implement. (deadtime = 15)
default service
Allows you to specifies the name of a share which will be connected to if the share that was actually requested cannot be found. This is useful if you wish to utilize a "help" share to feed information to users. (default service = help)
include
Allows you to include the contents of another configuration file.
interfaces
Allows you to specify which interfaces will server SMB requests, this can be specified as IP Addresses or Interface Names. (interfaces = eth0 192.168.1.0/24 10.0.0.0/8)
ldap passwd sync
Set's whether or not Samba should sync the LDAP password with the User's Windows Password. Useful if you wish your users to have separate passwords (for Windows and other Server Resources) or not.
log level
Allows you to control how much information Samba will log. This is normally a number, such as 3 where the higher the number the more information that will be logged, however you can now specify different numbers to different functions. (log level = 3 passdb:5 auth:10)
null passwords
Allows you to control whether or not users with null passwords are granted access to the server (yes or no, the default is no)
server string
Allows you to set what appears in browse lists next to the machine name. By default this is set to Samba and it's version (server string = Suse Linux Enterprise)

Useful Samba Share Parameters

admin users
Allows you to create a list of users who will be granted administrative privileges on the share.
available
Allows you to turn off a share without deleting it or commenting it out within smb.conf (available = no)
browseable
Allows you to control whether this share is seen in the list of available shares or not
comment
Allows you to specify a comment that is shown within Network Neighborhood when browsing the server's shares.
create mask
Allows you to specify the default Unix Permissions for files that are created through the Samba share. (create mask = 664)
delete readonly
Allows you to specify whether or not a user is able to delete a read-only file or directory (delete readonly = yes)
directory mask
Allows you to specify the default Unix Permissions for directories that are created through the Samba Share. (directory mask = 775)
follow symlinks
Allows you to specify whether or not Samba will follow symbolic Links on the Unix filesystem when accessed through the Share.
force create mode
Allows you to force the default Unix Permissions for files that are created through the Samba share. (force create mode = 664)
force directory mode
Allows you to force the default Unix Permissions for directories that are created through the Samba Share. (force directory mode = 775)
force group
Allows you to specify a group name that will be assigned as the default primary group for all users connecting to the share.
force user
Allows you to specify a user name that will be assigned for all users connecting to the share.
guest ok
Allows you to specify whether a username/password is required to access the share.
guest only
Allows you to specify that only guest connections are permitted to the share.
hide files
Allows you to specify a list of files and directories that will be marked as hidden by default. (hide files = /desktop.ini/*utloo*.lnk/.*/*riefcas*/)
invalid users
Allows you to specify users and groups that are not allowed to access the share.
level2 oplocks
Allows you to disable level 2 oplocks on a share (not recommended).
max connections
Allows you to limit the number of simultaneous connections to a share.
nt acl support
Allows you to control whether or not the "security" tab of the Windows Explorer file/directory properties dialog are available to the user.
profile acls
Allows you to set correct permissions on a "profile" share (profile acls = yes)
valid users
Allows you to specify which users or groups are allowed to access a share.
veto oplock files
Provides an easy way to fix locking problems with certain applications. An example: veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
write list
Allows you to specify which users and groups can write to a share.

Google Ad

© 2017 Mike Petersen - All Rights Reserved