Configuring the Samba Server
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.
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.
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:
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
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.
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.
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.*
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.
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).
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).
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.
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).
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.
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.
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.
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 =
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.
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 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)
- 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)
- Allows you to include the contents of another configuration file.
- 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.
- Allows you to turn off a share without deleting it or commenting it out within smb.conf (available = no)
- Allows you to control whether this share is seen in the list of available shares or not
- 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.