Before you read this

To fully comprehend this Daily Drill Down, it would behoove you to read Scott Lowe’s previous Samba articles: ”Share files and control your domains in a heterogeneous network with Samba 2.2.2” and ”Call SWAT or Webmin to administer your Samba 2.2.2.”

Many administrators would be interested in rolling out a Samba installation into an already existing Windows NT or Windows 2000 domain, but that would require the Samba administrator to create user accounts for each and every incoming Windows user. It would seem that there must be a better way, and there is—winbind.

The winbind utility is a part of the Samba 2.2.2 distribution; it doesn’t come with previous distributions. By building winbind support into a Samba installation and configuring the various components, you’ll be able to connect to a Samba share using a Windows domain account without having to create a separate UNIX account, telnet to the same server, and log in using the same Windows user.

No PAM? No need

If you’re running a system that doesn’t support PAM, authentication will be next to impossible.

Using winbind for easy user administration
If you’re planning to install a Samba server as a supplement to an existing Windows domain, it’s quite likely that you prefer to continue to manage your users centrally using Windows’ built-in utilities.

Winbind provides a mechanism for unified logons between Windows NT/2000 and UNIX; it creates a single point of administration by supplementing Samba’s capability to become a member of a Windows domain and allow the UNIX box to see Windows users and native UNIX users. Best of all, this entire process is completely transparent to the users. This capability can also be extended beyond Samba to other system functions, such as incoming telnet, ssh, and ftp.

Here, I’ll demonstrate how to get Samba up and running, install winbind, and get authentication working between a Samba server on Red Hat Linux 7.1 and a Windows 2000 Server acting as the domain controller.


You shouldn’t perform certain actions in a production environment, and that’s especially true here. If you make mistakes while modifying system logon files, you run the risk of not being able to access your system at all. For that reason, it’s imperative that you test this in a lab first.

Before you begin, whether or not you have a working Samba system, you need to recompile the package to add support for winbind. I’m going to assume that you’ve downloaded Samba 2.2.2, are logged on as a root user, and have extracted it to /usr/local/samba-2.2.2 by using the following while in /usr/local:
gunzip –dc samba-2.2.2.tar.gz
tar xvf –“

To compile Samba with winbind support, you need to specify a –with-winbind option to the configure command. You’ll also build in support for smbwrapper, which I’ll discuss further in a future article.

First, change to the newly created directory with cd /usr/local/samba-2.2.2/source. The next step is to prepare the source for compilation by running this command.

Finally, build the application binary with these two commands:
make install

Now, you need to copy the libraries that were created during the installation to the locations that will make them useful for a real Samba installation. Table A shows the commands to copy the correct libraries and a description of what each command is doing.

Table A
Command Description  
cp /usr/local/samba-2.2.2/source/nsswitch/ /lib Copies the NSS winbind module to the /lib directory
ln –s /lib/ /lib/ This step was recommended by the Samba 2.2.2 documentation to allow nsswitch to find the winbind libraries.
cp /usr/local/samba-2.2.2/source/nsswitch/ /lib/security Copies the PAM authentication module to the /lib/security directory

Now, make the new module available to winbind by typing the following:
/sbin/ldconfig –v

Creating the smb.conf file
You first need a basic /usr/local/samba/lib/smb.conf file, which is the file that Samba uses for all of its configuration parameters. Use your favorite text editor (mine is Pico) to create this; some GUI utilities, such as SWAT and Webmin, can allow you to do this via a browser, but you’ll have more control over your smb.conf file by creating it by hand. I put the following lines (see Table B) into my smb.conf file. While you’re working, remember that the lines marked with an asterisk (*) at the beginning need to be modified to fit your environment. The asterisk (*) should not be placed into the smb.conf file. Table B shows the global entries, along with their explanations.

Table B
[global] Explanation
(*)netbios name = pear The NetBIOS name of the Samba server
(*)workgroup = slowe The name of the domain that the Samba server is to join
encrypt passwords = yes This is required for machines with Windows 95 OSR2 and above and Windows NT 4.0 machines with SP4 or later.
security = domain Specifies that accounts will be looked up via the domain controller
password server = *        — This is an asterisk An asterisk (*) indicates that the password server is the domain controller.
winbind separator = + Specifies the separator that winbind will place between the domain and the username
winbind uid = 10000-20000 Specifies what UNIX user IDs winbind should use
winbind gid = 10000-20000 Specifies what UNIX group IDs winbind should use
winbind enum users = yes Not allowing user enumeration can cause programs such as finger to have problems since they rely on having access to the full user list.
winbind enum groups = yes Same as winbind enum users, except for groups
template shell = /bin/bash Specifies what shell Windows users will get when they telnet to a Samba box that is running winbind.

If you haven’t created a NETLOGON share, you should. This allows Windows 9x users to access your Samba server (see Table C).

Table C
path = /usr/local/samba/netlogon You’ll need to create this directory manually. It’s used by Windows 9x machines to connect to Samba.
read only = yes  

After creating the smb.conf file, or modifying the one you’re using, you need to join your Samba server to an existing Windows domain. In my example, I’m adding my Linux Samba server to a Windows 2000 domain named slowe with a domain controller named scott-2ks; you should make the appropriate changes to these names for your system. Once this line is typed, you’ll be prompted for the administrator password for the Windows 2000 domain. If you type the correct password and everything is properly set up, you’ll get a response indicating that the addition to the domain was successful.

Once that’s complete, it’s time to test your handiwork and start winbind. To do so, type /usr/local/samba/sbin/winbindd at the command line.

To test whether or not winbind is working properly, you can try to get a list of users from the Windows domain. To do this, type /usr/local/samba/bin/wbinfo –u at the command line. When I typed this, I got the following results, which show that winbind is working as anticipated:

Notice that the plus sign (+) appears between the domain and user name, as specified in the smb.conf file.

For winbind to run properly when Samba is also running, Samba must be started before winbind. So you’ll now kill the winbind process. To do this, you’ll first discover the PID of winbind with the following command:
ps -ef | grep winbind

In my case, this command returns 1108, so I can kill that process with this command:
kill -9 1108

Now, restart Samba with the following two commands:
/usr/local/samba/sbin/smbd –D
/usr/local/samba/sbn/nmbd -D

Finally, start winbind with this command:

At this point, you have a winbind system that is able to talk to the Windows 2000 domain controller and get user information and more. But it’s not fully integrated into the operating system yet; that is, you can’t connect to a Samba share and use a Windows login.

Make them play well together
To set up the integration, you need to modify some of the system startup files. Make sure that you back these up before modifying them. An emergency boot disk might be a good idea as well.

Boot disks

Unsure about making boot disks? Check out Jack Wallen, Jr.’s ”Creating Linux boot disks from both Linux and DOS.”

Keep in mind that my test installation is on a Red Hat 7.1 system. Your system may differ slightly, and you should make the appropriate modifications. First, I modified the /etc/pam.d/samba file so that it had the following contents. (I only added the two lines that call—the first and third lines; the other two lines were already there.)
auth required /lib/security/
auth required /lib/security/ nullok shadow
account required /lib/security/
account required /lib/security/

Next, modify the /etc/nsswitch.conf file. For this modification, find the uncommented lines that start with passwd, shadow, and group and add winbind as the second option on the list, right after files. For example:
passwd:     files winbind nisplus
shadow:     files winbind nisplus
group:      files winbind nisplus

Now, modify the contents of the /etc/pam.d/login file and add the three lines that are highlighted here.

Now, restart xinetd, like so:
/etc/init.d/xinetd restart

What have you accomplished? A lot, actually. If you have telnet enabled on your Red Hat server, you can now log in to a shell account using nothing more than a Windows user account from your domain with the format DOMAIN+username (for example, slowe+administrator, to log in as the domain administrator on my system).

Testing a share
Let’s test a share in Samba to see if we can connect to it using an account in the Windows domain that doesn’t exist in the UNIX user database. For my testing purposes, I’ve created a user named windowsuser in my domain, which is named slowe.

I’m assuming that this is a new Samba installation and that no users have been created in the smbpasswd file yet. If this is an existing installation and you already have users created, you may need to do some cleanup work to remove the Windows-only users from your smbpasswd file before you have a true central point of administration.

First, we need to create a share that can be used. We’ll share out the Samba directory in a read-only state for this example. We’ll add the following lines to the smb.conf file:
path = /usr/local/samba
read only = no

We’ll wait for a minute or so to let Samba refresh its configuration and then try to connect to it. Then, we’ll connect to \\server\samba from the Windows machine using domain/username, where domain is your actual domain name and username is your actual username, type the password, and see what happens. If all goes well, we should get the contents of the Samba directory in a window.

Moving back to the command line on the Samba server, we can type /usr/local/samba/bin/smbstatus to see who is connected to the Samba machine. As you can see from this output from my system, I am indeed logged in to the Samba server as a Windows domain user.

Behind the scenes
What is happening behind the scenes? When you connect to the Samba server using a Windows domain account, the UNIX system needs to have some way of mapping files back to a user ID and group ID. When we set up the initial smb.conf file in the /usr/local/samba/lib directory, we specified winbind uid and winbind gid parameters of 10000-20000 for this purpose. Upon a successful connection, the next available UID and GID are assigned to the incoming Windows user, and these results are stored in a small database located in /usr/local/samba/var. Now, when you create files on the UNIX system while logged in as a Windows user, that user will have domain+username ownership. For example, I created a small temporary file called Testing in /usr/local/samba via a Windows share and while logged in as slowe/windowsuser. When I do an ls -al, the line for that file reads this way.

To see the uid and gid, I issue ls -ln and get these results. These two IDs match what we put in the smb.conf file earlier.

While these steps are fairly complicated and involve modifying a number of system files, the end result is a Linux and Samba installation that is tightly integrated into your Windows domain. With the installation presented above, all PAM-enabled applications on your Linux system can use the Windows user database for authentication.

More on Samba

If you have a Samba topic that TechProGuild has yet to cover, send it to Jack Wallen, Jr., and he’ll be sure to get on it right away.