CHAPTER 9

Integrating Samba
Making It Work with Windows

You may already have a Samba server up and running in your network. Many people do, because it's such an easy and convenient solution to offer file sharing to Windows clients. Few people, however, have a Samba server that is integrated with other operating systems used in their environment. Achieving such integration is the focus of this chapter. In this chapter you'll first read a short section on how to quickly and easily set up a simple Samba server that offers file sharing and nothing more. In that section you will use the smbpasswd command to add individual user accounts. Sure, that works, but it's not a very sophisticated solution if you have many users to manage, because you need to create every user account twice.

Following the short introduction, there are three sections that explain how to truly integrate Samba in your network. The first section explains how to integrate Samba with LDAP, which is useful because it provides one centralized location from which you can manage user accounts. Next, you'll read how to set up your Samba server as a Windows NT 4–style Primary Domain Controller (PDC). This solution explains how you can replace a current Windows NT 4 server with Samba without your users even noticing the change. The last section explains how to integrate Samba in Active Directory. It teaches you how to set up Samba as a member server in Active Directory. Currently, making it more than a member server still isn't possible, because Samba version 4, which is supposed to make that possible, is not in a stable state yet.

Setting Up Samba the Easy Way

In this section you'll learn the easy way to set up Samba. It explains how you can define a share and create a Samba user that has access to this share. At the end of this section, you'll learn how to test whether this share is working properly.

Setting up Samba the easy way involves the following general steps, each of which is explained in detail in the sections that follow:

1. Create a local directory to share.
2. Set permissions on this directory.
3. Configure smb.conf to define the share.
4. Create a Samba user account.
5. Test access to the share.

Creating a Local Directory to Share

So what exactly is a share? Basically, it is a directory on the local Linux file system that is accessible over the network. To create such a share, the first step is to create a local directory. This is as easy as applying the mkdir command. So, assuming you want to share a local directory with the name /share, simply use mkdir /share to create the local directory.

Applying Permissions to the Local Directory

When working with Samba, you need to make sure that the appropriate permissions are applied to the share. These permissions are granted to a local user account. You can grant permissions the easy way, by just entering the command chmod 777 /share, but I don't recommend doing that. It is much better to create a dedicated group in Linux and make members of that group all users to whom you want to give access to the share. Assuming that the name of this group is sambagroup, you use chgrp sambagroup /share to make that group the share owner. Once that is done, apply the permissions, granting full permissions to the user owner and group owner and no permissions to others: chmod 770 /share. This creates a situation that is much more secure, because it ensures that other users cannot access the share.

Defining the Share

Now that you have set up everything that is necessary on the local file system, you need to define the share in Samba. Before you can start setting it up, you must install it first. There are several packages that relate to the Samba file server. You can get a list of them by using the aptitude search samba command. Listing 9-1 shows the result of this command when applied to my test server.

To make sure that all packages are installed, use the following command:

apt-get install samba dpsyco-samba ebox-samba egroupware-sambaadmin gsambad
 smbclient samba-common samba-dbg samba-doc samba-doc-pdf system-config-samba

---

Note The preceding command is not appropriate for my server, because the base packages samba and samba-common are already installed. However, it will install, in all situations, everything that is needed to operate a Samba server. I have also replaced the samba-client package with smbclient, because otherwise the installer would tell me that two Samba client packages are available and ask which one I want to install.

---

Now that all Samba packages have been installed, you can edit the general Samba configuration file /etc/samba/smb.conf to define the share. In smb.conf, there are two types of sections. The first type is the section [global], which contains global settings for your server. The second type consists of the different sections in which the individual shares are defined. You can recognize them by the name of the share, written between square brackets. For instance, to define a share for your directory /share, the section header would be [share]. The definition of this share can be really simple, as shown in Listing 9-2.

Of course, there are lots of other options that you can add to the share to make it fancier, but basically, if you define the share in this fashion it will work. So save your settings, and the share will be accessible. It takes a maximum of one minute before the share will automatically appear.

You've now set up basic access to the share. Before continuing, it's a good idea to check if it really works. You can do that by using the smbclient -L localhost command, which shows a list of all available shares on the local machine. It prompts for a user password as well, but because no user credentials are needed to display a list of shares, you can just press Enter to proceed. Listing 9-3 shows the output of this command.

At this point, your share is up and running and available, so it's time to proceed to the next step and create a Samba user account.

Creating a Samba User Account

So why does a user need a Samba user account if they already have a Linux user account? To access a share, the user, who typically works on a Windows machine, needs to enter his credentials. When doing this from a Windows machine, the password that he enters is encrypted in the Windows way. The problem is that the Linux authentication mechanism doesn't know how to handle this encryption. For that reason, the user needs a Samba user account that has a password that is encrypted the Windows way.

The Samba user account must match an existing Linux user account. That means that you first have to create the Linux account and then create the Samba account. Yes, that means creating the same user twice. If you don't like that solution, you need one of the advanced solutions, such as Samba integration with LDAP, described later in this chapter.

To create a Samba account, you need to use the smbpasswd command. For instance, to create a user with the name linda, use smbpasswd -a linda. The command will ask you to enter the Samba password twice, after which the Samba user account is created.

Testing Access to the Share

Now that you have created the Samba user account, it's time for a small test. Sure, you can do the test from Windows and make a connection to the share by entering the share name in the //servername/sharename format, but by doing that, you are introducing other factors that may fail as well. For instance, the Windows test may fail because of a misconfigured firewall. At this point, we just want to know whether the Samba server is functioning the right way. Test it by using the mount command:

mount -t smbfs -o username=linda //localhost/share /mnt

If this command succeeds in mounting the Samba share on the /mnt directory, you have established that the Samba server is working.

As an alternative way to test access to your share, you may use the smbclient command. This command offers an interface that is pretty similar to the FTP client command-line interface; you can use put and get to transfer files from and to the Samba shared directory from the smbclient shell interface. To perform the same test on //localhost/share, use smbclient --user=linda //localhost/share. If successful, this command opens a shell interface to the directory. Try for example the ls command to get a list of all files in the share. Listing 9-4 shows an example of a short smbclient session. In this example, user linda authenticates, uses ls to show a list of existing files, uses get to download the file to her current directory, and finally uses quit to close the smbclient interface.

With your Samba server up and running, now it's time to integrate it with LDAP.

Integrating Samba with LDAP

There are three tasks to accomplish if you want to integrate Samba with LDAP. First, you need to prepare Samba to talk to LDAP. Next, you have to prepare LDAP as well. Finally, you can tell Samba to use LDAP.

Preparing Samba to Talk to LDAP

The major difference between the Samba configuration just discussed and integration with LDAP is in one line in the [global] section of smb.conf. The following line defines that, by default, passwords are stored in the Trivial Database (TDB) that Samba uses by default:

passdb backend = tdbsam

This method works fine if you are using only one Samba server or if you are using Samba as a domain controller in an environment in which no backup domain controllers are available. If you are using Samba in a larger-scale environment, you can write user account information to an LDAP database. To do that, you need to change the passdb backend parameter to refer to an LDAP server. The following example would do that:

passdb backend = ldapsam

You have now prepared Samba to talk to LDAP. In the next section you'll learn how to configure LDAP to talk to Samba as well.

Preparing LDAP to Work with Samba

To store Samba user information in the LDAP Directory, you have to prepare the LDAP Directory first. LDAP needs to know about the new Samba object classes that you are going to store in it, and you can teach OpenLDAP that by including the samba.schema file. After installing the Samba packages as explained in the preceding section, you will find this file in the directory /usr/share/ebox-samba/samba.schema. Follow these steps to add this file to the LDAP environment:

1. Use cp /usr/share/ebox-samba/samba.schema /etc/ldap/schema to copy the schema file to the directory in which LDAP expects it to be.
2. Open /etc/ldap/slapd.conf with an editor and make sure the following schema files are included:
   
   # Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/samba.schema
   
   
3. Restart the LDAP service, using /etc/init.d/slapd restart.

At this point, you have extended the LDAP schema. By doing that, three different classes have been added:

• sambaDomain: Used to store information that is used between Samba domain controllers. You only need this class when setting up an environment with several domain controllers (see the section "Using Samba as a Primary Domain Controller" later in the chapter).
• sambaSamAccount: Used to extend the user properties in LDAP to include Samba properties as well.
• sambaGroupMapping: Used to add properties that are necessary to make a normal Linux group a Samba group as well.

By default, the Samba user has two password hashes that are stored in LDAP. If you do nothing, both of them are readable as plain text passwords. Therefore, when using LDAP as the password back end for Samba, you should make sure that only the Samba service has access to these passwords, by adding an ACL to LDAP. You can accomplish this by including the following code in /etc/ldap/slapd.conf:

access to attr=sambaNTPassword,SambaLMPassword
   by cn=admin,dc=sandervanvugt,dc=nl write
   by * none

Also, to increase performance, you should add some indexes to LDAP. This allows LDAP to find required information much faster. Make sure that the following indexes are added in /etc/ldap/slapd.conf:

index    uid,cn,displayName,memberUid   eq
index    uidNumber,gidNumber            eq
index    sambaSID                       eq,sub

Finally, restart the LDAP service, using /etc/init.d/slapd restart.

Telling Samba to Use LDAP

Now that the LDAP service is all prepared, you have to apply some modifications to /etc/samba/smb.conf to tell it that it has to use LDAP. You need to explain where it can find the LDAP server, and you need to secure communications.

Connecting Samba to LDAP

First and foremost, you need to use the passd backend global parameter to tell Samba where to go for password information. This option takes a URI as an argument, telling Samba where it can find LDAP. For example, if the LDAP server is available at IP address 192.168.1.200, the parameter looks as follows:

passdb backend = ldapsam:ldap://192.168.1.200/

This option tells Samba to go to the specified IP address to get password information, but what happens if this LDAP server goes down? There are two approaches to provide more redundancy:

• Configure LDAP as a resource in a Heartbeat cluster (see Chapter 7 for more details on Heartbeat). In such a configuration, you still have one LDAP server only, but Heartbeat will manage where it runs and will make sure that it is highly available. If the server that currently hosts LDAP goes down, Heartbeat will start LDAP somewhere else. The only implementation requirement is that you have to put the LDAP Directory and its configuration files on a shared storage device, so that another server, when it takes over the LDAP service, can still access the database and configuration. This is the solution that I prefer.
• Implement LDAP replication, using the slurpd process. When doing this, changes that are applied to the master LDAP server are replicated to the replica LDAP servers automatically. This could work also, but there is a disadvantage: the replica LDAP server is read-only and therefore of limited use. If you choose this solution, you can refer to both LDAP servers using the passdb backend definition in smb.conf: passdb backend = ldapsam:"ldap://192.168.1.200 ldap://192.168.1.210"

Configuring Secure Connections

Basically, your Samba server is now capable of connecting to LDAP, but there is a problem still: connections from Samba to LDAP are all in plain text. So if the LDAP Directory is not on the same server as the Samba daemon, you should apply security. The preferred method to do that is by including the ldap ssl parameter in smb.conf:

ldap ssl = start_tls

Next, you need to tell Samba the identity of the administrator who has write permissions in LDAP. To do this, use the ldap admin dn parameter in smb.conf. You already created an ACL in LDAP to give the appropriate rights to manage user passwords to a user with the name admin, so it makes sense to tell Samba as well that this admin user is the administrator for all LDAP-related stuff:

ldap admin dn = cn=admin,dc=sandervanvugt,dc=nl

At this point you must make sure that Samba knows what password to use for this LDAP administrator. To create a password, first restart Samba to enforce all changes so far, and then use smbpasswd -W to write the password. As this is the Samba password that is needed to connect to the LDAP server, the password is not written to LDAP, but rather to the /etc/samba/secrets.tdb file. Make sure this file is not readable by normal users; the password is stored in a readable way in this file. In Listing 9-5 you can see what happens when writing this password.

Specifying Where to Put the Objects in LDAP

At this point, Samba knows all it has to know to get to LDAP for administration tasks. It's time to proceed to the next part, in which you specify where in the LDAP Directory you want to create Samba-related objects. Four parameters are required and the last is optional:

• ldap suffix: The base container in LDAP that you are working from.
• ldap user suffix: The base container for user accounts. Like all following parameters, the name of this container is written as a name that is relative to the container specified with ldap suffix.
• ldap machine suffix: The base container for machine accounts.
• ldap group suffix: The base container for group accounts.
• ldap idmap suffix: Required if you want to use Winbind to get user information from a Windows environment. Winbind creates SIDs, which in an LDAP-integrated environment are stored in the container specified here.

At this point, you should have in the [global] section of smb.conf the information shown in Listing 9-6.

At this point you can restart your Samba server. It is now integrated with LDAP.

Using Samba As a Primary Domain Controller

In a Windows environment, a domain is used to manage users for a group of computers. The only option to do this in a centralized way in NT 4 is to use domains. Since Windows 2000, Active Directory has been introduced as a system that sits above domains. Samba cannot be configured as an Active Directory environment yet, so the best thing you can do if you want to work with a domain-like environment is to configure Samba as an NT 4–style domain controller. This section gives some tips on how to do that. Be aware that setting up a well-tuned, scalable domain environment requires extensive knowledge of the working of Microsoft networks. This goes far beyond the scope of this book, so in this section you'll learn just about the basic requirements needed to set up a Samba domain. Consider this section an introduction to the subject matter only; for more information consult the man pages or the documentation at http://www.samba.org.

Changing the Samba Configuration File

The first step in setting up a domain environment is to change the Samba configuration file properly. Listing 9-7 shows the settings required in the /etc/samba/smb.conf [global] section.

Table 9-1 summarizes the relevant parameters from the [global] section of Listing 9-7. Make sure to include the parameters from the [netlogon] and [profiles] sections as they appear in Listing 9-7, because you need them to make your Samba server function as a PDC.

Table 9-1. Parameters Specific for Domain Configuration

Parameter	Description
netbios name	This parameter is the name that your server will have in the Microsoft network.
security	This parameter specifies how security should be handled. If you want to configure your server as a domain controller, set it to security = user.
passdb backend	Use this parameter to specify in what kind of database you want to store user and group information. The most common values for this parameter are smbpasswd, tdbsam, and ldapsam. The easiest way to configure your server is to use the tdbsam option, which creates a local database on your Samba server. The most flexible way to configure it is to use the ldapsam option, although this does require the configuration of an LDAP server and makes things more complicated. If you want to set up your Samba environment with PDCs as well as BDCs, make sure to use the ldapsam option.
logon script	For Windows users, you can create a Windows logon script in Samba. This parameter refers to the logon script, which is a batch file that is executed automatically when the user logs in. In this example, the Samba server checks if there is a script for your user that has the name of the user account, followed by .bat. This script should be placed in the directory specified with the path parameter in the [netlogon] share.
domain master	This parameter tells the nmbd naming process that this server must be responsible for maintaining browse lists in the complete network. These browse lists allow others in the network to view a complete list of all members of the Windows network. A domain controller should always be the domain master for your network.
local master	This parameter defines which server is used as the local master browser. A domain master browser communicates with local master browsers, which are servers that are responsible for maintaining browse lists on local network segments. Apart from being the domain master, your Samba servers should be local master browsers as well.
os level	Even if you specify that your server should be local master and domain master, this doesn't really guarantee that it also will be the master browser. In a Windows network, the master browser is selected by election. To increase the chances that your server will be the master browser, make sure to you use a value higher than 32 for the os level parameter. The highest value is the most likely to win the browser elections.
preferred master	Normally, browser elections happen only occasionally. Use this parameter to force a new browser election immediately when the Samba server comes up.
domain logins	Set this parameter to yes to make this server a domain controller.
login path	This parameter specifies where the user's profile directory is found. To make this work, make sure that the [profiles] share is properly set up. In this para meter, the variable %N is used to refer to the local server name, and %U is used to refer to the home directory of the current user.
logon drive	This parameter provides for the user a drive letter that can be used as the logon drive.
logon home	Use this parameter to specify where the home directory is located.

As you can see, you need to use many parameters to make sure that the Samba server is elected to be the master browser for your network. To configure a master browser, you need the nmbd service, which handles Windows naming to be started as well. This service is started automatically when you start Samba.

Creating Workstation Accounts

Now that you have your domain environment, you should add workstations to it. For every workstation that is going to be a member of a domain, you need a workstation account on the Samba server. Setting up a workstation account is similar to setting up a user account. First you need to add the account to the local user database on your server, and then you need to add the workstation account as a workstation to the Samba user database. Notice that the name of the workstation should end with a $ sign, to indicate that it is a workstation. To create a workstation with the name ws10, for example, first use useradd ws10$ to create it in /etc/passwd. Next, add the workstation to the smbpasswd file by using the smbpasswd -a -m ws10 command. Notice that in the smbpasswd command, there is no need to use the $ to specify that it is a workstation; this is handled automatically by the -m option.

Integrating Samba in Active Directory

In its current version, you can't make a Samba server an Active Directory domain controller. Although the people in the Samba project team are working very hard to make this possible, they haven't been successful yet. You can, however, make Samba a member server in an Active Directory (AD) domain. That means you still need Windows 200x servers to fulfill the role of domain controllers.

The advantage of making Samba a member server in an AD domain is that users can log on to Active Directory and get access to all resources that are offered by the Samba server. There are two methods to connect Samba to Active Directory. The first method is to make Samba a member of the Active Directory domain, using simple passwords; the second method is to make Samba a member server in AD, using Kerberos authentication.

Making Samba a Member of the Active Directory Domain

To integrate Samba with Active Directory, the first step is to make it a member of the domain. This is a relatively easy procedure that you have to accomplish partly on a Windows server and partly on the Samba server:

1. Create user accounts for your users in Active Directory. Samba offers the resources, but in this setup, authentication is handled by Active Directory. So make sure that all users exist in Active Directory.
2. Create the Samba user as a Linux user and apply permissions for this user. So, you need one general Samba user on Linux, and you need to grant this user access permissions to the shared resources. You can grant these by using chmod 770 on the directory you want to share.
3. Modify the smb.conf configuration file. The following options are required in the [global] section to connect Samba to Active Directory:
   
   [global]
   workgroup = NAME_OF_AD_DOMAIN
   password server = IP_ADDRESS_OF_A_200X_SERVER
   security = ADS
   
   
4. Add the Samba server to Active Directory. To do this, you need a computer account in Active Directory. Use the net command on the Samba server to create this user account in Active Directory: net ads join -U Administrator%password will do the job for you (replace password with the actual password of the Active Directory administrator). The Samba account now appears in Active Directory.

Using Kerberos to Make Samba a Member of Active Directory

In recent Windows versions, Microsoft has been focusing more on Kerberos authentication. Therefore, it is a good idea to use Kerberos on Samba as well. For more information about Kerberos, read Chapter 13. The advantage of using Kerberos is that it is never necessary to send passwords over the wire; instead, authentication tickets are used, which is a much more secure method. Follow this procedure to set up Kerberos authentication:

1. Tell Samba that it should use Kerberos, by modifying the smb.conf configuration file as follows:
   
   [global]
    workgroup = YOUR_AD_DOMAIN
    realm = YOUR_AD_DOMAIN.MSFT
    ads server = YOUR_AD_SERVER
    security = ads
   
   
2. Get the initial Kerberos tickets. Use the kinit command, followed by the name of the Kerberos realm in the Active Directory environment: kinit administrator@YOUR_AD_DOMAIN.MSFT.
3. Add the Samba server to Active Directory. Use net ads join -U Administrator%password. This adds your server to Active Directory, and because your server now knows how to use Kerberos, Kerberos will be used for secure communications.

Authenticating Linux Users on Windows with Winbind

Up to now, I have assumed that your Linux users are defined in the Linux environment. This is not the most practical solution if you run a mainly Windows environment with some Linux users. In such an environment, it would be useful to maintain user accounts in Windows and redirect Linux users to Windows for authentication. Winbind helps you to do exactly that. The following procedure shows you how to set up a Winbind environment:

1. Install the winbind package by using apt-get install winbind.
2. Create in Active Directory the user accounts you want to be able to authenticate on Linux.
3. On Linux, modify the /etc/nsswitch.conf configuration file. In this file, you have to tell Linux that it should use Winbind before trying to authenticate locally on Linux. The following two lines will do that for you:
   
   passwd:    winbind compat
group:     winbind compat
   
   
4. Modify the PAM configuration. You should make sure that before getting to normal Linux-based authentication, the user tries to authenticate on Windows. To make this happen, make sure that the line auth sufficient pam_winbind.so is inserted as the first line in the files common-auth, common-account, common-password, and common-session in /etc/pam.d.
5. Modify the smb.conf configuration file. Because Winbind is related to Samba, it gets its configuration from smb.conf. The code in Listing 9-8 makes sure that a complete environment is created for users that come in through Winbind.

   Listing 9-8. Winbind Parameters in /etc/samba/smb.conf

   [global]
    winbind separator = +
    winbind cache time = 15
    template shell = /bin/bash
    idmap uid = 10000-20000
    idmap gid = 10000-20000
    template homedir = /home/%U
    winbind uid = 10000-20000
    winbind gid = 10000-20000
    workgroup = YOUR_AD_DOMAIN
6. Restart Winbind by running /etc/init.d/winbind restart.
7. Winbind should do its work now. To test if it works well, you can log in at the Linux prompt with a Windows user account. To do this, at the login prompt, use the full username, including the name of the Windows Domain. That means that you would log in with a username such as DOMWIN+linda (which is what user linda would use to log in to the domain DOMWIN). To separate the domain name and username, you must use a + sign between the two.

Summary

In this chapter you learned how to integrate Samba with Windows. After a short introduction on generic Samba basics, you read how to integrate Samba with LDAP. Basically, this offers a very nice solution in which Samba uses a hierarchical replicated database as its user configuration back end. Next, you read how Samba can offer PDC functionality to replace a Windows NT 4–style domain controller. In the last part of this chapter, you read more about the integration between Samba and Active Directory. You read how to make Samba a member server in Active Directory, and how to set up Winbind, which allows you to manage Linux users from Active Directory. In the next chapter you'll learn how to set up Ubuntu Server as a mail server.