Section 29.1. Objective 1: Configuring a Samba Server
29.1. Objective 1: Configuring a Samba ServerSamba is the name given to the software that implements the Server Message Block (SMB) protocol on Unix systems. SMB is the name commonly used to refer to the numerous services and protocols that are involved in implementing file and print sharing between computers running Microsoft Windows. Because file and print sharing in the Windows world includes many additional features (Kerberos authentication, WINS server integration, NetBIOS name lookups, domain and workgroup membership, and browser elections, just to name a few), Samba is a relatively complex piece of software. However, configuring it is not difficult, as long as you understand some basics of how the software works and what exactly needs to be done. Because of all the functionality that is involved and because the Samba team is always trying to play catch-up with the moving target of Microsoft Windows releases, Samba is in active development. Samba 2.0 was released in January 1999 and was a major milestone in the world of Windows-to-Unix file and print integration. Samba 2.0 brought basic emulation of the Windows Primary Domain Controller (PDC), which gave administrators the ability to replace many of their existing Windows NT-based primary domain controllers with Linux systems running Samba. Samba 3.0 was released in September, 2003 and includes such new features as Kerberos 5 and LDAP integration, full Unicode support, trust relationships with other Windows-based PDCs, and support for Windows NT access control lists. For the purposes of this chapter, we will not be going into the Samba configuration required for many of these advanced network configurations. We will focus on:
Samba most likely came as a default package with your Linux distribution. Many distributions ship it in three packages named samba-common, samba-server, and samba-client. If you're planning on using Samba only as a server, allowing Windows PCs to access directories on your Linux server, you don't need the samba-client package. For the purposes of this chapter, we will assume all Samba components are installed. If your vendor does not offer Samba as a package or you'd rather go the source route and compile it yourself, you can download the latest version of the Samba source from a mirror listed at http://www.samba.org. The Samba packages include many files, the most important of which are described in Table 29-1.
29.1.1. Basic Configuration FileThe Samba configuration file, /etc/samba/smb.conf, is similar to most other Linux configuration files in that it is a plain ASCII file that can be edited with any text editor. The other features it shares with most other Linux configuration files is its relatively free-form syntax and the huge number of options that are available. Fortunately, the manual page for this file is very well done, explaining all available options and giving many good examples. The manual page can be accessed by typing man smb.conf from the command line. The smb.conf file is broken down into two sections: the global section and the shares section (in Windows terminology, every directory shared to other systems is called a share). The global section defines settings that apply to the Samba server itself or are valid across all shares. This section is defined by the [global] directive, and all settings are in the format variable = value. Let's look at a global section from a default installation of Samba: [global] workgroup = WORKGROUP server string = My File Server printcap name = /etc/printcap printing = lprng load printers = yes security = user encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd domain logons = yes logon script = login.bat This is, of course, not a complete list of options available in the global section, but it is enough to get you started. The workgroup variable defines the Windows workgroup that this Samba server will belong to. Think of workgroups as an informal association of Windows PCs. There are no authentication or membership details. Membership in a workgroup simply means that your computer will show up in a Windows browse list with other workgroup members. The server string variable can be any text that describes your server. The next three lines all deal with how Samba interacts with the underlying printing subsystem. If printing is already correctly configured on your Linux server, Samba can interact with it without much configuration. The only important variable is printing, which tells Samba what kind of printing subsystem your version of Linux uses. Popular choices are lprng and CUPS. The security variable is one of the most important variables in the smb.conf file, and the one that generates the most confusion in people new to Samba. The options for this variable are share, user, and domain. Share-level security means that Windows users connecting to shared resources on the Linux server do not necessarily have to be valid Linux users. This situation is common when you want to set up a "guest" share or some other kind of no-privilege or anonymous access. User-level security is the most common (and is the default in Samba 2.2 and later) and requires that Windows users connecting to the Samba server successfully authenticate themselves against the server. This can be done in a number of ways, but the point is that the Windows user identifies who he is, and Samba decides what access level to apply to him. Finally, domain-level security assumes that the Samba server is a member of an existing Windows domain (much different from the aforementioned Windows workgroup). If domain-level security is in place, every attempted connection to the Samba server by a Windows PC prompts the Samba server to pass the authentication of the Windows user to the primary domain controller for that domain. In this way, Samba is still requiring authentication to access the shared resources but is acting as a gateway for that authentication process. If your Samba server is acting as a file server for a relatively small set of users, security = user is probably the correct choice for you. 29.1.2. Windows PasswordsThe encrypt passwords variable brings to light an important configuration issue with Samba and one that often confuses people new to Samba. With the advent of Windows 95OSR2 in 1996, Microsoft defaulted to encrypting the passwords that were exchanged between Windows systems when they authenticated to access shared resources. Before this date, these passwords were sent in plain text over the network, which posed serious security risks. In order to understand how this affected Samba, we must first understand how the standard Linux login process works. Each Linux user has an entry in the /etc/passwd file that defines important details about her user account, such as UID, GID, home directory, and shell. The user's entry in /etc/shadow contains the user's encrypted password. This password is encrypted with a one-way hash for security reasons. When a user logs into a Linux system, the password she provides is encrypted with the standard encryption libraries, and the resulting encrypted string is compared with the encrypted string in /etc/shadow. If they match, the user is authenticated and allowed into the system. There is no easy way to derive a user's password from the encrypted string in /etc/shadow; the encryption algorithm is one-way only. Windows (starting with Windows95OSR2) uses a similar scheme to store encrypted passwords. When one Windows machine authenticates against another in order to access shared resources, it's the encrypted password that is sent over the network. In order for Samba to communicate with Windows machines in this way, it has to be able to authenticate Windows users using the given encrypted password. Now, you may be thinking that this should be easy, because we know that Linux users already have an encrypted password in /etc/shadow on the Linux server. So Samba should just be able to compare the proffered Windows encrypted password with the string in /etc/shadow and authenticate a Windows user, right? Unfortunately, that is not the case. Windows and Linux use different password encryption algorithms, so although the password might be the same for a Linux user and a Windows user, the encrypted string will not be. This means that if your Samba server is using user-level access to share resources with Windows systems running Windows 95OSR2 or later, you must maintain a list of Windows users and their encrypted Windows passwords on your Linux server, in addition to the list of users you already have in /etc/shadow. Because this has been a default of Microsoft Windows for so long, encrypt passwords = yes is the default in the smb.conf file. The smb passwd file variable defines where this list of Windows users and their passwords resides, and it defaults to /etc/samba/smbpasswd. An example line for user joe from /etc/shadow is: joe:$1$xDTY3.yX$l9R4lCBFr0fDr0SQds1NA0:13159:0:99999:7::: An example line for the sane user from /etc/samba/smbpasswd is: joe:504:2D09ECB6715E94F6D9243782117C7417:3ADBA9C02F6A67701B419BFFF31A21F2: [U ]:LCT-43C571F8: While normal Linux user accounts are maintained through commands such as useradd and passwd, the /etc/samba/smbpasswd entries are maintained by the program smbpasswd. Some common options to smbpasswd are:
29.1.3. Acting as a PDCIf you want your Samba server to act as a primary domain controller for Windows PCs, set domain logons = yes. The primary advantages of having your Windows PCs be a part of a domain managed by your Samba server are more client-level security options, more logging options, the ability to maintain client PCs through login scripts, and the ability to implement domain policies on client machines. On Windows machines running Windows95OSR2, Windows 98, or Windows ME, joining a domain is as simple as configuring the domain name on the Windows client and authenticating against the Samba server with a valid username and password. On clients running Windows NT, 2000, XP, or 2003, there is another step involved. You must first create a machine account for each workstation that will be a member of the domain. This is accomplished by running smbpasswd with the -m and -a options. Machine accounts look like normal accounts in the /etc/passwd file, but the username must be the same as the computer name of the Windows client. The smbpasswd program will automatically add a $ character to the end of the username, identifying it as a special machine account. No actual password is required for these accounts; they just must be present in the password database in order for these Windows machines to connect to your domain. If your Samba server is operating as a domain controller, you must configure a netlogon share. This can be any physical directory on your Linux server. A netlogon section in smb.conf looks something like this: [netlogon] comment = Network Logon Service path = /home/netlogon guest ok = yes writable = no This section creates a sharename called netlogon that offers the physical directory /home/netlogon as a Samba share. Guests are allowed to connect, and the share is read-only. The netlogon share is a default share on Windows domain controllers, and Windows PCs that belong to a domain will expect to find it. Two important files that belong in the netlogon directory are the login script and the group policy file. 29.1.4. Login SettingsLogin scripts are simply Windows batch files that run every time a user logs into a Windows PC that is a member of a domain. The most common use for a login script is to restore drive mapping to network resources. Here is a sample login script, called login.cmd, that maps the user's home directory to H: and the share public to P:: net use h: /home net use p: \\server\public You do not have to include a sharename when specifying /home because the server can figure out what the users' home directories are via their usernames. Windows ships with a program called the Group Policy Editor that can be used to specify registry settings that are applied to each workstation every time a user logs into the domain. Use the Group Policy Editor to create a policy file, name it config.pol, and save it to the netlogon share to ensure that it is executed on every client when a user authenticates against the domain. 29.1.5. SharesOnce you have a global section defined and some user accounts created with smbpasswd, you're ready to define some resources to share. We've already seen the basic setup for a share with the netlogon share. Other shares are configured the same way. All share sections in smb.conf start with [sharename] followed by any options you want to enable for the share. The only required option is path, which indicates what directory on your Linux server you're actually assigning to this share. Here is a share section example from the default smb.conf file: [public] comment = Public Stuff path = /home/samba public = yes read only = yes write list = @staff Most of these options are relatively self-explanatory, and the smb.conf manual page goes into great detail on every available option. The comment directive defines a line of text that will appear next to each folder in the network browse view on a Windows PC. The path directive defines the directory that is being shared. The public directive is a synonym for guest ok, meaning that guest users can connect to this share. The read only directive means that this share is not writable by default by users on remote systems, and write list defines a Linux group that does have write access to this share (in this case, any user in the staff group). 29.1.6. StartupLike most other Linux server applications, any change to the configuration file requires a restart of Samba before the change will take effect. Samba is restarted the standard way: # /etc/init.d/smb restart This will restart the two Samba processes, smbd and nmbd. smbd is the main daemon that shares directories from the Linux system, while nmbd is the NetBIOS name server. This server provides name service for NetBIOS clients over TCP/IP. The NetBIOS name service is similar to the DNS service, which translates hostnames to IP addresses. nmbd translates Windows machine names to IP addresses. This ability is usually handled by Windows machines that run WINS (Windows Internet Name Service). If you want your Samba server to act as a WINS server, you must enable the global option wins support = yes. Then you must configure each Windows client to register with the WINS service. Once this is done, you will be able to browse for available Windows PCs using NetBIOS over TCP/IP and do IP address-to-Windows machine name mapping. Use the Linux command nmblookup to query a WINS server and return the IP address of a given Windows machine name. Here is an example: # nmblookup client1 querying client1 on 192.168.1.255 192.168.1.10 client1<00> This tells us that client1 has the IP address 192.168.1.10. The subnet with a broadcast address of 192.168.1.255 was searched in order to return this information. There is a special share section that is unique among shares: the [printers] share. If this section is included in smb.conf, Windows clients can spool print jobs to any printer defined on your Linux server. Here is a sample [printers] share: [printers] comment = All Printers path = /var/spool/samba browseable = no guest ok = no writable = no printable = yes This section looks very similar to the other share sections we've seen, with the exception of the printable directive. This defines this share as a special printer share, and the directory /var/spool/samba becomes the local Linux directory to which Windows print jobs are spooled. You can assign the same level of security to the printers share as you would any other share. As long as your underlying Linux printing subsystem is set up correctly, this is all you need to do to enable Windows clients to print to your Linux printers. 29.1.7. TroubleshootingNow that we've seen how to perform a basic Samba setup, allowing Windows machines to connect to shared Linux resources, we must address the next stage of any server setup: troubleshooting. The Samba suite includes a number of useful tools that allow you to identify possible problems with your Samba configuration. The testparm program parses your smb.conf file and notifies you of any syntax errors or other potential mistakes. It's a good idea to get into the habit of running testparm after you make any change to smb.conf, but before you restart Samba. The smbstatus program with a -V option gives you an overview of a currently running smbd process, including the version of Samba that is running, the username and machine name of all currently connected clients, and a list of all resources that are currently in use. Samba also has extensive logging capability. By default, Samba logs everything to the directory /var/log/samba. The smbd.log and nmbd.log files contain events specific to those services. By default, every connecting client machine gets its own log in /var/log/samba, named after the Windows machine name. These logs are useful for identifying when certain machines attempted connections and if any errors occurred during the communication process. Samba's log level can be increased in the global section of smb.conf to high enough levels that every action performed by any Samba service is logged. This is very useful for debugging any connection issues that may arise. We have so far talked mostly about using the Samba suite to enable a Linux computer to act as a server for Windows PCs. However, Samba also gives us the ability to have a Linux computer act as a client on a Windows network, accessing shared Windows resources. In order to access these resources, they must be mounted into the Linux filesystem, just like any other shared network resource. The command to accomplish this is smbmount. For example, if I wish to mount the shared directory public that is shared from the Windows server named server1 on my Linux machine, I would type this command as root: # smbmount //server1/public /mnt/public -o username=adamh,password=mypassword This command assumes that the directory /mnt/public exists on the local Linux system and that the user adamh with password mypassword is a valid user account on the Windows machine server1. If the authentication is successful, I will be able to change to the directory /mnt/public and see the files that reside in the public directory on server1. The manpage for smbmount contains other command-line options that are useful in this context, such as Kerberos settings for connecting to an Active Directory share and specifying the UID and GID that will "own" the mount point. Samba is a very powerful tool, and a useful one, especially in today's heterogeneous networks. This basic overview should give you enough information to get started using it. |
EAN: 2147483647
Pages: 257