9.5 Authentication with winbind

   

In Chapter 3, we showed you how to add Windows clients to a network in which user accounts were maintained on the Samba server. We added a user account to the Windows client using the same username and password as an account on the Unix system. This method works well in many computing environments. However, if a Samba server is added to a Windows network that already has a Windows NT/2000 primary domain controller, the PDC has a preexisting database of user accounts and group information that is used for authentication. It can be a big chore to transfer that database manually to the Unix server, and later maintain and synchronize the Unix and Windows databases.

In Chapter 4, we showed you how to add a Samba server as a domain member server to a network having a Windows NT/2000 primary domain controller. We set security = domain in the Samba configuration file to have the Samba server hand off authentication to the Windows PDC. Using that method, passwords are kept only on the PDC, but it is still necessary to set up user accounts on the Unix side to make sure each client has a valid Unix UID and group ID (GID). This is necessary for maintaining the file ownerships and permissions of the Unix security model. Whenever Samba performs an operation on the Unix filesystem on behalf of the Windows client, the user must have a valid UID and GID on the local Unix system.

A facility that has recently been added to Samba, winbind, allows the Windows PDC to handle not only authentication, but the user and group information as well. Winbind works by extending the Unix user and group databases beyond the standard /etc/passwd and /etc/group files such that users and groups on the Windows PDC also exist as valid users and groups on the Unix system. The extension applies to the entire Unix system and allows users who are members of a Windows domain to perform any action on the Unix system that a local user would, including logging in to the Unix system by telnet or even on the local system, using their domain usernames and passwords.

When winbind is in use, administration of user accounts can be done on the Windows PDC, without having to repeat the tasks on the Unix side. This includes password expiration and allowing users to change their passwords, which would otherwise not be practical. Aside from simplifying domain administration and being a great time saver, winbind lets Samba be used in computing environments where it otherwise might not be allowed.

Because this is a chapter on security, we want to point out that some issues might relate to allowing a Windows system to authenticate users accessing a Unix system! Whatever you might think of the relative merits of Unix and Windows security models (and even more importantly, their implementations ), one thing is certain: adding winbind support to your Samba server greatly complicates the authentication system overall ”and quite possibly allows more opportunities for crackers.

We present winbind in this chapter not as a means of improving security, but rather as a further example of Samba's ability to integrate itself into a modern Windows environment.

9.5.1 Installing winbind

Installing and configuring winbind is fairly complicated and involves the following steps:

  1. Reconfigure, recompile, and reinstall Samba ”to add support for winbind.

  2. Configure the Unix name server switch.

  3. Modify the Samba configuration file.

  4. Start and test the winbindd daemon.

  5. Configure the system to start and stop the winbindd daemon automatically.

  6. Optionally, configure PAM for use with winbind.

At the time this book was written, winbind was supported only on Linux, so all of the following directions are specific to it. Other Unix flavors might be supported at a later time. In addition, we assume you have a Windows NT/2000 primary domain controller running on your network.

First, you will need to configure and compile Samba using the --with-winbind configure option. Directions for doing this are included in Chapter 2 in Section 2.3. As usual, run make install to reinstall the Samba binaries.

9.5.2 Configuring nsswitch

When Samba is compiled after being configured with the --with-winbind option, the compilation process produces a library called libnss_winbind.so in the source/nsswitch directory. This library needs to be copied to the /lib directory:

 #  cp nsswitch/libnss_winbind.so /lib  

Also, a symbolic link must be created for winbind to be fully functional:

 #  ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2  

The name of this symbolic link is correct for Samba 2.2.3 and Red Hat 7.1. The name might change ”with a higher version number in the extension ”in future releases. See the winbindd manual page for details.

Next , we need to modify /etc/nsswitch.conf to make the lines for passwd and group look like this:

 passwd:     files winbind group:      files winbind 

Then activate these changes by issuing the following command:

 #  /sbin/ldconfig  

What we've just done is reconfigure the Linux name service switch, which allows name service and other tasks to be configured to use the traditional method (files in the /etc directory) or an extension coded in a library, such as the libnss_winbind.so library we've just installed. We've specified in our configuration that Samba will search for user and group information first in the /etc/passwd and /etc/group files , and if they are not found there, in the winbind service.

9.5.3 Modifying smb.conf

To use winbind, we must have our Samba server added to the Windows NT domain as a domain member server (as we described in Chapter 4) and also add some parameters to the Samba configuration file to configure winbind. In addition to the options required to configure Samba as a domain member server, we need:

 [global]     winbind uid = 10000-20000     winbind gid = 10000-20000 

The winbind uid and winbind gid options tell winbind how to map between Windows relative identifiers (RIDs) and Unix UIDs and GIDs. Windows uses RIDs to identify users and groups within the domain, and to function, the Unix system must have a UID and GID associated with every user and group RID that is received from the Windows primary domain controller. The winbind uid and winbind gid parameters simply provide winbind with a range of UIDs and GIDs, respectively, that are allocated by the system administrator for Windows NT domain users and groups. You can use whatever range you want for each; just make sure the lowest number in the range does not conflict with any entries in your /etc/passwd or /etc/group files at any time, either now or in the future. It is important to be conservative about this. Once winbind adds an RID to UID/GID mapping to its database, it is very difficult to modify the mapping.

The file /usr/local/samba/locks/winbindd_idmap.tdb contains winbind's RID mapping file by default. We suggest you regard this file as extremely sensitive and make sure to guard it carefully against any kind of harm or loss. If you lose it, you will have to re-create it manually, which can be a very labor- intensive task.

Be careful when adding local users after domain users have started accessing the Samba server. The domain users will have entries created for them by winbind in /etc/passwd, with UIDs in the range you specify. If you are using a method of creating new accounts that automatically assigns UIDs, it might choose UIDs by adding 1 to the highest UID assigned thus far, which will be the most recent UID added by winbind. (This is the case on Red Hat Linux, with the useradd script, for example.) The UID for the new local user will be within the range allocated for winbind, which will have undesired effects. Make sure to add new local users using a method that assigns them UIDs in the proper range. For example, you can use the -u option of useradd to specify the UID to assign to the new user.

Restart the Samba daemons to put your changes to the configuration file into effect. If you have not already done so while adding your Samba server as a domain member server, you must issue the command:

 #  smbpasswd -j   domain   -r   pdc   -U Administrator  

as we described in Chapter 4. At this point, you can start the winbindd daemon:

 #  winbindd  

You might want to run a ps ax command to see that the winbindd daemon is running. Now, to make sure everything we've done up to this point works, we can use Samba's wbinfo command:

 $  wbinfo -u  METRAN\Administrator METRAN\bebe METRAN\Guest METRAN\jay METRAN\linda $  wbinfo -g  METRAN\Domain Admins METRAN\Domain Guests METRAN\Domain Users 

The -u option queries the domain controller for a list of domain users, and the -g option asks for the list of groups. The output shows that the Samba host system can query the Windows PDC through winbind.

Another thing to check is the list of users and groups, using the getent command:

 #  getent passwd  root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin:  ... deleted ...  jay:x:500:500:Jay Ts:/home/jay:/bin/bash rik:x:501:501::/home/rik:/bin/bash METRAN\Administrator:x:10000:10000::/home/METRAN/administrator:/bin/bash METRAN\bebe:x:10001:10000:Bebe Larta:/home/METRAN/bebe:/bin/bash METRAN\Guest:x:10002:10000::/home/METRAN/guest:/bin/bash METRAN\jay:x:10003:10000:Jay Ts:/home/METRAN/jay:/bin/bash METRAN\linda:x:10004:10000:Linda Lewis:/home/METRAN/linda:/bin/bash # getent group root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon  ... deleted ...  jay:x:500: rik:x:501: METRAN\Domain Admins:x:10001:METRAN\Administrator METRAN\Domain Guests:x:10002:METRAN\Guest METRAN\Domain Users:x:10000:METRAN\Administrator,METRAN\jay,METRAN\linda,METRAN\bebe 

This shows that the Linux system is finding the domain users and groups through winbind, in addition to those in the /etc/passwd and /etc/group files. If this part doesn't work as shown earlier, with the domain users and groups listed after the local ones, check to make sure you made the symbolic link to libnss_winbind.so in /lib correctly.

Now you can try connecting to a Samba share from a Windows system using a domain account. You can either log on to the domain from a Windows NT/2000/XP workstation or use smbclient with the -U option to specify a username.

If you get errors while attempting to log on to the domain, it is probably because you had previously configured the client system with a computer account on another domain controller. Commonly, you get a dialog box that says, "The domain NAME is not available." On a Windows 2000 system, the fix is to log in to the system as an administrative user and open the Control Panel, double-click the System icon, click the Network Identification tab, then click the Properties button. In the dialog that comes up, click the "Workgroup:" radio button and fill in the name of the workgroup (you can use the same name as the domain). Click the OK buttons in the dialogs, and reboot if requested .

This removes the computer account from the primary domain controller. Now log in again as the administrative user and repeat the previous directions, but change from the workgroup back to the domain. This creates a new computer account that "fits" the workstation to the new primary domain controller. If your network has backup domain controllers, it will take up to 15 minutes for the new computer account to propagate to the BDCs.

If you are using Windows NT/XP, the method is slightly different. For the exact procedure, see the section in Chapter 4 that is specific to your Windows version.

After logging in as a domain user, try creating a file or two in a Samba share. (You might need to change the permissions on the shared directory ”say, to 777 ”to allow this access. This is very permissive, but after you finish reading this section, you will understand how to change ownership and permissions on the directory to restrict access to selected domain users.) After you've created files by one or more domain users, take a look at the directory's contents from a Linux shell. You will see something like this:

 $  ls -l /u  -rwxrw-rw-    1 METRAN\b METRAN\D        0 Apr 13 00:00 bebes-file.doc -rwxrw-rw-    1 METRAN\l METRAN\D        0 Apr 12 23:58 lindas-file.doc drwxrwxr-x    6 jay      jay          4096 Jan 15 05:12 snd  $ ls -ln /u  total 4 -rwxrw-rw-    1 10001    10000           0 Apr 13 00:00 bebes-file.doc -rwxrw-rw-    1 10004    10000           0 Apr 12 23:58 lindas-file.doc drwxrwxr-x    6 500      500          4096 Jan 15 05:12 snd 

We can even use the domain usernames and groups from the Linux shell:

 #  chown 'METRAN\linda:METRAN\Domain Users' /u  #  ls -ldu /u  drwxrwxrwx    3 METRAN\l METRAN\D     4096 Apr 13 00:44 /u #  ls -ldn /u  drwxrwxrwx    3 10004    10000        4096 Apr 13 00:00 /u 

Notice how the owner and group are listed as being those of the domain user and group. Unfortunately, the GNU ls command won't show the full names of the domain users and groups, but we can use the -ln listing to show the UIDs and GIDs and then translate with the wbinfo command:

 $  wbinfo -s `wbinfo -U 10004`  METRAN\LINDA 1 $  wbinfo -s `wbinfo -G 10000`  METRAN\Domain Users 2 

(It's a bit messy, but it works, and it shows that the winbind system is working!) At this point, you might want to modify your /etc/rc.d/init.d/smb script to start and stop the winbindd daemon automatically along with the smbd and nmbd daemons. Starting with the script we presented in Chapter 2, we first add this code to the start( ) function:

 echo -n $"Starting WINBIND services: " /usr/local/samba/bin/winbindd ERROR2=$? if [ $ERROR2 -ne 0 ] then     ERROR=1 fi echo 

The previous code should be located after the code that starts nmbd and before the return statement.

We start winbindd after nmbd because winbindd needs nmbd to be running to work properly.

In the stop( ) function, we add the following:

 echo -n $"Shutting down WINBIND services: " /bin/kill -TERM -a winbindd ERROR2=$? if [ $ERROR2 -ne 0 ] then     ERROR=1 fi echo 

Again, this code should be located after the code that stops nmbd and before the return statement.

9.5.4 Configuring PAM

Most popular Linux distributions use Pluggable Authentication Modules (PAM), a suite of shared libraries that provide a centralized source of authentication for applications running on the Unix system. PAM can be configured differently for each application (or service) that uses it, without needing to recompile the application. As a hypothetical example, if an organization's security policy mandated the use of passwords exactly 10 characters in length, a PAM module could be written to check the length of passwords submitted by users and reject any attempts to use a longer or shorter password. PAM would then be reconfigured to include the new module for services such as ftp , console login, and GUI login that call upon PAM to authenticate users.

If you are not already familiar with PAM, we suggest you read the documentation provided with the Linux PAM package before continuing. On most Linux systems, it is located in the /usr/share/doc directory hierarchy. Another resource is the Linux-PAM System Administrator's Guide , which you can find on the Internet at http://www.kernel.org/pub/linux/libs/pam.

The rest of this section is about using the PAM module provided in the Samba distribution to enable Windows domain users to authenticate on the Linux system hosting Samba. Depending on which services you choose to configure, this allows Windows domain users to log in on a local console (or through telnet ), log in to a GUI desktop on the Linux system, authenticate with an FTP server running on the Linux system, or use other services normally limited to users who have an account on the Linux system. The PAM module authenticates Windows domain users by querying winbind, which passes the authentication off to a Windows NT domain controller.

As an example, we will show how to allow Windows domain users to log in to a text console on the Linux system and get a command shell and home directory. The method used in our example can be applied (with variations) to other services.

All users who can log in to the Linux system need a shell and a home directory. Unix and Linux keep this user information in the password file ( /etc/passwd ), but information about Windows users isn't located there. Instead, in the Samba configuration file, we add the following to notify winbind what the shell and home directory for Windows domain users will be:

 [global]     template shell = /bin/bash     template homedir = /home/%D/%U 

The first line sets the template shell parameter, which tells winbind what shell to use for domain users that are logging in to the Unix host. The template homedir parameter specifies the location of users' home directories. The %D variable is replaced by the name of the domain in which the user's account resides, and %U is replaced by the user's username in that domain.

Before the domain users can successfully log in, their home directories must be created manually. To add a single account for linda in the METRAN domain, we would use these commands:

 #  mkdir /home/METRAN  #  chmod 755 /home/METRAN  #  mkdir /home/METRAN/linda  #  chown 'METRAN\linda:METRAN\Domain Users' /home/METRAN/linda  #  chmod 700 /home/METRAN/linda  

One side effect of creating the home directories is that if the Samba server is configured with a [ homes ] share, the domain users can see and access their home directories through Samba's file sharing.

Next, we need to compile and install the PAM module in the Samba distribution. From the source directory in the Samba distribution, issue the following commands:

 #  make nsswitch/pam_winbind.so  #  cp nsswitch/pam_winbind.so /lib/security  

and check that it was copied over correctly:

 #  ls /lib/security/pam_winbind.so  /lib/security/pam_winbind.so 

On Red Hat Linux, the PAM configuration files reside in /etc/pam.d . Before making any modifications, we strongly advise making a backup of this directory:

 # cp -pR /etc/pam.d /etc/pam.d.backup 

The reason for this is that we will be modifying the Linux system's means of authenticating logins, and if our configuration goes awry, all users (including root ) will be locked out of the system. In case the worst happens, we would reboot into single-user mode (by typing linux single at the LILO: prompt) or boot a rescue disk, and then we would issue these two commands:

 #  mv /etc/pam.d /etc/pam.d.bad  #  mv /etc/pam.d.backup /etc/pam.d  

Be very careful to make sure you can recover from any errors you make because when PAM encounters any configuration information it doesn't understand, its action is not to allow access. This means you must be sure to enter everything correctly! You might want to leave yourself logged in as root on a spare virtual terminal while you are modifying your PAM configuration to ensure yourself a means of easy recovery.

In the /etc/pam.d directory, you will encounter a file for each service that uses PAM. We are interested only in the file corresponding to the login service, which is called login . It contains the following lines:

 auth       required     /lib/security/pam_securetty.so auth       required     /lib/security/pam_stack.so service=system-auth auth       required     /lib/security/pam_nologin.so account    required     /lib/security/pam_stack.so service=system-auth password   required     /lib/security/pam_stack.so service=system-auth session    required     /lib/security/pam_stack.so service=system-auth session    optional     /lib/security/pam_console.so 

The lines starting with auth are related to the function of authentication ”that is, printing a password prompt, accepting the password, verifying that it is correct, and matching the user to a valid user and group ID. The line starting with account is for account management, which allows access to be controlled by other factors, such as what times during the day a user is allowed access. We are not concerned with the lines starting with password or session because winbind does not add to either of those functions.

The third column lists the PAM module, possibly with arguments, that is called in for the task. The pam_stack.so module has been added by Red Hat to act somewhat like a macro or a subroutine. It calls the file in the pam.d directory named by the service argument. In this case, the file /etc/pam.d/system-auth contains a common set of lines that are used as a default for many services. Because we want to customize the login service for winbind, we first replace the pam_stack.so lines for auth and account with the auth and account lines from /etc/pam.d/system-auth . This yields:

 auth       required     /lib/security/pam_securetty.so  auth       required     /lib/security/pam_env.so   auth       sufficient   /lib/security/pam_unix.so likeauth nullok   auth       required     /lib/security/pam_deny.so  auth       required     /lib/security/pam_nologin.so  account    required     /lib/security/pam_unix.so  password   required     /lib/security/pam_stack.so service=system-auth session    required     /lib/security/pam_stack.so service=system-auth session    optional     /lib/security/pam_console.so 

To add winbind support, we need to add a line in both the auth and account sections to call the pam_winbind.so module:

 auth       required     /lib/security/pam_securetty.so auth       required     /lib/security/pam_env.so  auth       sufficient   /lib/security/pam_winbind.so  auth       sufficient   /lib/security/pam_unix.so  use_first_pass  likeauth nullok auth       required     /lib/security/pam_deny.so auth       required     /lib/security/pam_nologin.so  account    sufficient   /lib/security/pam_winbind.so  account    required     /lib/security/pam_unix.so password   required     /lib/security/pam_stack.so service=system-auth session    required     /lib/security/pam_stack.so service=system-auth session    optional     /lib/security/pam_console.so 

The keywords required and sufficient in the second column are significant. The keyword required specifies that the result returned by the module (either to pass or fail the authentication) must be taken into account, whereas the keyword sufficient specifies that if the module successfully authenticates the user, no further lines need to be processed . By specifying sufficient for the pam_winbind.so module, we let winbind attempt to authenticate users, and if it succeeds, the PAM system returns to the application. If the pam_winbind.so module doesn't find the user or the password does not match, the PAM system continues with the next line, which performs authentication according to the usual Linux user authentication. This way, both domain users and local users can log in.

Notice that we also added the use_first_pass argument to the pam_unix.so module in the auth section. By default, both the pam_winbind.so and pam_unix.so modules print a password prompt and accept a password. In cases where users are logging in to the Linux system using their local accounts, this would require them to enter their password twice. The user_first_pass argument tells the pam_unix.so module to reuse the password that was given to the pam_winbind.so module, which results in users having to enter the password only once.

After modifying the login configuration file, switch to a spare virtual console and make sure you can still log in using a regular Linux account. If not, check your modifications carefully and try again until you get it right. Then log in using a domain user account from the Windows PDC database to check that the winbind authentication works. You will need to specify the username in DOMAIN \ user format, like this:

 login: METRAN\linda Password: 

More information on configuring winbind can be found in the Samba source distribution file docs/htmldocs/winbind.html , and in the winbindd manual page. If you would like to learn more about configuring PAM, we recommend the web page http://www.kernel.org/pub/linux/libs/pam/ as a starting place. Some of the documentation for Linux PAM, including Red Hat's extensions, can also be found on Red Hat Linux in /usr/share/doc/pam- version .

9.5.5 winbind Configuration Options

Table 9-9 summarizes some commonly used options that you can use to configure winbind.

Table 9-9. winbind options

Option

Parameters

Function

Default

Scope

winbind separator

string (single character)

Character to use as a separator in domain usernames and group names

Backslash ( \ )

Global

winbind uid

string (numeric range)

Range of UIDs for RID-to-UID mapping

None

Global

winbind gid

string (numeric range)

Range of GIDs for RID-to-GID mapping

None

Global

winbind cache time

numeric

Number of seconds the winbindd daemon caches user and group data

15

Global

template homedir

string (directory name)

Directory to be used as the home directory of the logged-in domain user

/home/%D/%U

Global

template shell

string (command name)

The program to use as the logged-in domain user's shell

/bin/false

Global

9.5.5.1 winbind separator

On Windows systems, the backslash ( \ ) is commonly used as a separator in file names, UNCs, and the names of domain users and groups. For example, an account in the METRAN domain with a username of linda would be written as METRAN\linda . On Unix systems, the backslash is commonly used as a metacharacter for quoting, so the account would have to be specified as METRAN\\linda or ' METRAN\linda '. The winbind separator parameter allows another character to be used instead of the backslash character, making it much easier to type in domain user and group names. For example, with:

 [global]     winbind separator = + 

the aforementioned account could be written simply as METRAN+linda on the Unix host, making it unnecessary to use additional backslashes or single quotes. Winbind then uses the same format for reporting domain user and group names.

9.5.5.2 winbind uid

As part of winbindd 's task of letting Windows NT domain users function as local users on the Unix host, winbindd supplies a Unix UID that is linked to the Windows RID of the domain user. The winbind uid parameter allows the Unix system administrator to allocate a range of UIDs for this purpose. It is very important that this range not overlap any UIDs used for other purposes on the Unix system, so we recommend you begin your range at a very high number, one much larger than the number of local users and NIS users that will ever exist. For example, winbind uid might be defined as:

 [global]     winbind uid = 10000-15000 

on a system that would never have more than 9,999 local and NIS users, or for that matter, any other entries in /etc/passwd that would use up another UID. Because the example allocates 5,000 UIDs to winbindd , the assumption is that there will never be more than 5,000 domain users accessing the Samba host.

If your method for adding new local users to the system assigns UIDs automatically, make sure it does not assign them within the range of UIDs allocated to winbind. This might happen if the algorithm used adds 1 to the highest UID assigned thus far.

There is no default for winbind uid , so you must specify it in your Samba configuration file for winbind to work.

9.5.5.3 winbind gid

This option works like winbind uid , except that it is for allocating a range of GIDs for use with winbindd . You might not need to allocate as many GIDs as UIDs because you probably have relatively few domain groups that need corresponding GIDs. (In many cases, users are all members of the Domain Users group, requiring only one GID.) However, it is best to play it safe, so make sure to allocate many more GIDs than you think you will need.

As with winbind uid , if you are using a method of adding new local users to your Unix host that automatically assigns GIDs, either make sure the method used doesn't conflict with winbind or set the GIDs manually.

There is no default for winbind gid , so you must specify it in your Samba configuration file for winbind to work.

9.5.5.4 winbind cache time

The winbindd daemon maintains a cache of user and group data that has been retrieved from the Windows PDC to reduce network queries and increase performance. The winbind cache time parameter allows the amount of time (in seconds) winbindd can use the cached data before querying the PDC to check for an update. By default, this interval is set to 15 seconds. This means that when any part of a user or group account on the PDC is modified, it can take up to 15 seconds for winbindd to update its own database.

9.5.5.5 template homedir

When the local Unix system is configured to allow domain users to log in, the user must be provided with a home directory for many programs, including command shells , to function properly. The template homedir option is used to set the name of the home directory. In the name of the directory, %D is replaced by the name of the Windows NT domain the user is in, and %U is replaced by his username. By default, template homedir is set to /home/%D/%U , which works fine for a network in which there might be more than one Windows NT domain, and it is possible for different people in different domains to have the same username. If you are sure you will never have more than one Windows NT domain on your network, or you have more than one domain but know for sure that unique users have identical usernames in each multiple domain, you might prefer to set template homedir like this:

 [global]     template homedir = /home/%U 
9.5.5.6 template shell

This option specifies the program to use as the shell for domain users who are logged in to the Unix host. By default, it is set to /bin/false , which effectively denies domain users to log in. If you wish to allow logins for domain users, set template shell to a valid command shell (or other program) that you want to act as the textual interface the domain users will receive when logged in. A common setting on Linux would be:

 [global]     template shell = /bin/bash 

which would give users the Bash shell for their interactive login sessions.

   


Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2003
Pages: 475

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net