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.
9.5.1 Installing winbindInstalling and configuring winbind is fairly complicated and involves the following steps:
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 nsswitchWhen 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
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.confTo 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.
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.
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.
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 PAMMost 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
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 OptionsTable 9-9 summarizes some commonly used options that you can use to configure winbind. Table 9-9. winbind options
9.5.5.1 winbind separatorOn 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 uidAs 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 gidThis 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 timeThe 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 homedirWhen 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 shellThis 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. |