Takeaway: If you have a Windows domain controller in your organization, Samba allows you to authenticate Linux users via the domain. All it takes is a little bit of tweaking.
Getting Samba to completely accept authentication information from an existing domain is quite a challenge. It requires changes to a few configuration files and awareness of more than a few subsystems within the Linux environment. Although simpler approaches are available in Samba, they have their own challenges, such as requiring the setup of user accounts on the Linux box and the creation of persistent connections to the authenticating domain server.
User accounts
In previous versions of Samba it was possible to allow authentication from an NT domain, but the major caveat was that the user account had to exist on the Samba machine—even if the account was logged in through the domain controller. To fix this limitation, a daemon was developed called winbind. This daemon is a pluggable authentication module (PAM) that interrogates a Windows-based domain controller for authentication information for a user and, if properly authenticated, creates the appropriate mapping between Linux user IDs and Windows IDs. In short, it provides the bridge necessary so a local Linux account is not necessary for a Windows Domain user. Winbind is now a direct part of the main Samba distribution, including the RedHat9 distributed version, 2.2.7.
Despite being a part of Samba, winbind actually allows all kinds of connections besides just Samba connections without a local Linux account. For instance, Telnet and SSH connections will work without local accounts via winbind once installed; however, this is beyond the scope of my discussion today.
Because of early UNIX-only single sign-on efforts, Linux developers created a Name Service Switch (NSS) subsystem. This subsystem provided a unified way of looking up host names as well as enumerating user accounts, groups, and other utilitarian functions. Winbind hooks into NSS to allow a UNIX application to enumerate the users of a connected Windows NT/Windows 2000 domain. Although it’s beyond the scope of this article to discuss how one might do this, or why one might do this, the necessary changes to the configuration files are outlined for completeness.
PAM, not spam
The pluggable authentication module (PAM) architecture was designed to allow for a standard way for applications to authenticate users while maintaining extensibility for new authentication mechanisms. With PAM, every application need not concern itself with where the user is actually authenticated, only that the user was authenticated by the system. PAM is a default part of RedHat9 and the configuration files it uses can be found in the /etc/pam.d directory. By integrating with PAM, Winbind provides a transparent way of mapping non-local users to the system.
Configuring Samba to authenticate against a domain
The first step in getting Samba to authenticate to a Windows domain is to add winbind to NSS by changing two lines in the /etc/nsswitch.conf file. The two lines are the password and group lines. They should be changed by adding winbind after the existing entries. Once changed, they should look like the following:
passwd: files winbind
group: files winbind
The next step is to make the appropriate changes to the Samba configuration file, /etc/samba/smb.conf. The first change is to change the workgroup entry in the global section to match the name of your domain. Next, change the security entry to be domain. Finally, change the password server to * or, alternatively, you can specify your domain controllers by name leaving a space after each one. After being modified, the lines should look something like the following:
workgroup = MYDOMAIN
security = DOMAIN
password server = *
With those changes in place, it’s time to add a few configuration lines for winbind. These entries all go in the global section and should look like these:
winbind separator = +
winbinduid = 10000-20000
winbindgid = 10000-20000
winbindenum users = yes
winbindenum groups = yes
The settings for Winbind can be set to anything you like; however, the settings here should be good enough to get you going. The separator is a + sign instead of the familiar backslash character used by Windows, in part due to the rules for using a backslash in a UNIX shell. The uid and gid ranges are just to keep the numbers assigned to the mappings by Winbind out of the way of local users. Finally, enum users and enum groups allow the enumeration of users and groups from the domain, respectively.
All of the changes to the configuration file have been made, so save the file.
The next step is to create a machine account in the Windows domain for the Samba machine. Winbind will use this machine account to do its work. The account is created by using the smbpasswd utility with options. The command needs the -j option followed by the domain name that the Samba server is being connected to. It also requires the -r option followed by the server name that the Samba server is being connected to. Finally, it requires the -U option to specify the user account that has permissions to create computer accounts in the domain. Once assembled, the command should look something like this:
smbpasswd -j MYDOMAIN –r MYPDC –U Administrator
You’ll be prompted for your password for the administrator so that Samba can create the user account for the user. Once this step has been completed, it’s time to restart Samba. The quickest way to do this is to do type ps–ea | grepsmbd and then kill the process listed. This is the first column of the returned results. To kill the process, type the “kill” command, followed by a space and the process ID. Restart Samba by typing smbd.
Verifying that Samba is set up
The next step is to verify that the winbind daemon is able to communicate with the server. Verifying that winbind is working is done by using the wbinfo command. The first step is to type wbinfo–p. This pings the winbind daemon to ensure that it’s running. If the test fails, check to see if the process is running but not responding by typing ps-ea | grepwinbindd. If you get no results, the process just hasn’t been started. If you do get a response, then winbindd is really confused since it’s not responding to basic pings. This will require a look into the error logs, as described later in this article.
If there are no errors, the next step is to type wbinfo–t. This tests the computer account that you just created to make sure it’s working correctly.
Next, it’s important to check the ability to retrieve users. This is done by first executing the wbinfo command with a -A option followed by the domain, username, and password that wbinfo can use to satisfy further requests. The format of the command is:
wbinfo -A DOMAIN+USER%PASSWORD
The command will likely return without generating any errors, even if you have mistyped the password. The final step is to type wbinfo-u, which should return a list of users from the domain.
Troubleshooting the setup
There are plenty of potential issues with the setup, ranging from basic networking problems to password mismatches and beyond. Here are a few basic steps toward determining the source of your problem.
First, if you get an error from wbinfo indicating an error looking up domain users, you’re more than likely having some sort of a problem connecting to the domain controller. This might be a network problem, or something as simple as a typo in the domain name in the workgroup name setting in the /etc/samba/smb.conf file. Checking for items that you may have overlooked or miskeyed is a good place to start.
On the other hand, if you get an error number from wbinfo that matches 0xc000006d, you’ve probably miskeyed the password when entering the wbinfo -A command. Either that or you didn’t enter the wbinfo -A command at all. Try the command again. Also, make sure that you tried the wbinfo -t command and received a message back that the secret is good. You might get a password error if your computer account is broken.
Finally, if these don’t answer your question, you can restart winbindd with a debugging level to spit out all kinds of detail to the log file. The log file is located in /var/log/samba and is named log.winbindd. If you’ve not turned debugging on, however, the file is likely to contain very little that’s useful. To turn debugging on, issue the command ps-ea | grepwinbindd and kill off the listed process as you did for smbd above. Then type winbindd-d 100. This turns the debug level all the way up for winbindd. Try the wbinfo command that failed and then go through the log file looking for what may have gone wrong. Be prepared to wade through a great deal of the log, as it fills up quite quickly at this debugging level.
Also, you may also find it useful to look at the log files for a machine. These files are named with the netbios machine name and an extension of .log. For instance, my notebook named boguer-nb created a file boguer-nb.log. This file is with the rest of the Samba logs in the /var/log/samba directory
