Table of Contents for
Linux in a Windows World

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Linux in a Windows World by Roderick W Smith Published by O'Reilly Media, Inc., 2005
  1. Cover
  2. Linux in a Windows World
  3. Dedication
  4. Preface
  5. Contents of This Book
  6. Conventions Used in This Book
  7. Using Code Examples
  8. Comments and Questions
  9. Safari Enabled
  10. Acknowledgments
  11. I. Linux’s Place in a Windows Network
  12. 1. Linux’s Features
  13. Linux as a Server
  14. Linux on the Desktop
  15. Comparing Linux and Windows Features
  16. Summary
  17. 2. Linux Deployment Strategies
  18. Linux Desktop Migration
  19. Linux and Thin Clients
  20. Summary
  21. II. Sharing Files and Printers
  22. 3. Basic Samba Configuration
  23. The Samba Configuration File Format
  24. Identifying the Server
  25. Setting Master Browser Options
  26. Setting Password Options
  27. Summary
  28. 4. File and Printer Shares
  29. Printing with CUPS
  30. Creating a Printer Share
  31. Delivering Printer Drivers to Windows Clients
  32. Example Shares
  33. Summary
  34. 5. Managing a NetBIOS Network with Samba
  35. Enabling NBNS Functions
  36. Assuming Master Browser Duties
  37. Summary
  38. 6. Linux as an SMB/CIFS Client
  39. Accessing File Shares
  40. Printing to Printer Shares
  41. Configuring GUI Workgroup Browsers
  42. Summary
  43. III. Centralized Authentication Tools
  44. 7. Using NT Domains for Linux Authentication
  45. Samba Winbind Configuration
  46. PAM and NSS Winbind Options
  47. Winbind in Action
  48. Summary
  49. 8. Using LDAP
  50. Configuring an OpenLDAP Server
  51. Creating a User Directory
  52. Configuring Linux to Use LDAP for Login Authentication
  53. Configuring Windows to Use LDAPfor Login Authentication
  54. Summary
  55. 9. Kerberos Configuration and Use
  56. Linux Kerberos Server Configuration
  57. Kerberos Application Server Configuration
  58. Linux Kerberos Client Configuration
  59. Windows Kerberos Tools
  60. Summary
  61. IV. Remote Login Tools
  62. 10. Remote Text-Mode Administration and Use
  63. SSH Server Configuration
  64. Telnet Server Configuration
  65. Windows Remote-Login Tools
  66. Summary
  67. 11. Running GUI Programs Remotely
  68. Using Remote X Access
  69. Encrypting X by SSH Tunneling
  70. VNC Configuration and Use
  71. Running Windows Programs from Linux
  72. Summary
  73. 12. Linux Thin Client Configurations
  74. Hardware Requirements
  75. Linux as a Server for Thin Clients
  76. Linux as a Thin Client
  77. Summary
  78. V. Additional Server Programs
  79. 13. Configuring Mail Servers
  80. Configuring Sendmail
  81. Configuring Postfix
  82. Configuring POP and IMAP Servers
  83. Scanning for Spam, Worms, and Viruses
  84. Supplementing a Microsoft Exchange Server
  85. Using Fetchmail
  86. Summary
  87. 14. Network Backups
  88. Backing Up the Linux System
  89. Backing Up with Samba
  90. Backing Up with AMANDA
  91. Summary
  92. 15. Managing a Network with Linux
  93. Delivering Names with DNS
  94. Keeping Clocks Synchronized with NTP
  95. Summary
  96. VI. Appendixes
  97. A. Configuring PAM
  98. The PAM Configuration File Format
  99. PAM Modules
  100. Sample PAM Configurations
  101. Summary
  102. B. Linux on the Desktop
  103. Configuring Applications and Environments
  104. Running Windows Programs in Linux
  105. File and Filesystem Compatibility
  106. Font Handling
  107. Summary
  108. Index
  109. Colophon

PAM and NSS Winbind Options

Getting the Winbind daemon up and running is only part of the configuration required on the domain member server. Once Winbind is functioning, you must configure PAM and NSS to use Winbind to authenticate users and return additional account information to programs that need it. These tasks are handled by special modules and configuration of these two subsystems. You may also want to configure Linux to create home directories automatically when they don’t exist.

NSS and PAM Winbind Modules

PAM and NSS both rely on modules to interface with Winbind. These module files, pam_winbind.so and libnss_winbind.so , are usually installed as part of a Samba package, such as samba-common. The pam_winbind.so file usually appears in /lib/security or /usr/lib/security. The libnss_winbind.so file usually resides in /lib and is linked to another file, libnss_winbind.so.2 (either file may be a symbolic link to the other).

If you’ve installed Samba from source code, you may need to install these libraries independently. The source code appears in the source/nsswitch subdirectory of the Samba source code package, and the compiled libraries should appear there after you build the main Samba package. (These files appear only if you select the --with-pam configure option.) Copy the files to appropriate directories, and create an appropriate link for the libnss_winbind.so file. You can then type ldconfig to force Linux to reexamine the library directories and register the new libraries.

Configuring NSS

NSS provides nonauthentication information on accounts to tools that require it. Before PAM allows you to log in using Winbind, you must configure NSS to use Winbind. This can be done by editing the /etc/nsswitch.conf file. Locate the passwd and group lines in this file. (The shadow line usually separates them, but you won’t edit this line.) Add winbind to the passwd and group lines:

passwd:  files winbind
shadow:  files
group:   files winbind

Tip

Some distributions place other options on these lines in addition to files. Some use compat instead of files. If yours is so configured, simply add winbind to the end of the list, or to an earlier position if you prefer. (NSS consults each source in turn for account information.)

Configuring PAM

PAM enables you to customize authentication options on a service-by-service basis. For instance, you can tell Linux to use only the local account database for console logins, to use only the NT domain controller for FTP logins, and to use either method for remote SSH logins. PAM accomplishes this goal by using one or more configuration files: either a file called /etc/pam.conf or files in the /etc/pam.d directory named after the particular systems they control. Modifying these files to use additional PAM modules, such as those that support NT domain authentication, is described in Appendix A.

Warning

When reconfiguring PAM, you can easily render your system unable to support logins. Thus, I recommend experimenting with one login server at a time, leaving yourself some way to log in should you create an inoperable system. For instance, experiment with the login service and leave the gdm or xdm service alone.

As an example of adding NT domain authentication, consider Example 7-1. This listing shows the contents of the /etc/pam.d/login file on a Debian system, which defines how PAM handles authentication for text-mode console logins and logins via such servers as Telnet.

Example 7-1. Sample PAM configuration file

auth       requisite  pam_securetty.so
auth       requisite  pam_nologin.so
auth       required   pam_env.so
auth       required   pam_unix.so nullok

account    requisite  pam_time.so
account    required   pam_unix.so

session    required   pam_unix.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv

password   required   pam_unix.so nullok min=6 max=255 md5

Tip

PAM configurations vary both from one service to another and from one distribution to another. If your PAM configuration file doesn’t look exactly like Example 7-1, don’t panic. The most important part of PAM Winbind configuration is adding lines, as described shortly.

To add NT domain authentication to this system, you should add a couple of lines to this file. These lines tell PAM to use the pam_winbind.so library for authentication and account validity checks. The result of adding these lines appears in Example 7-2, with the added or changed material shown in bold.

Example 7-2. Sample PAM configuration file with Winbind support

auth       requisite  pam_securetty.so
auth       requisite  pam_nologin.so
auth       required   pam_env.so
auth       sufficient pam_winbind.so
auth       required   pam_unix.so nullok try_first_pass

account    requisite  pam_time.so
account    sufficient pam_winbind.so
account    required   pam_unix.so

session    required   pam_unix.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv
session    required   pam_mkhomedir.so skel=/etc/skel umask=0027

password   required   pam_unix.so nullok min=6 max=255 md5

This configuration adds an auth line just before the existing auth line that references pam_unix.so and adds the try_first_pass parameter to that existing line. These changes add Winbind to the authentication system and cause pam_unix.so to use the password entered for Winbind if Winbind authentication fails. A second set of changes is in the account stack, which adds a Winbind call to it. Finally, this configuration adds a call to pam_mkhomedir.so, which creates a new home directory for the user if one doesn’t already exist. You need to make these changes for every service that should use the NT domain controller.

Tip

Some distributions, including Red Hat, Fedora, and Gentoo, now use the pam_stack.so module rather than pam_unix.so or pam_unix2.so. If you see calls to this module, you can either add your calls to pam_winbind.so to the file as described here or modify the /etc/pam/system-auth file instead of the file for the individual servers. The pam_stack.so module pushes part of the PAM configuration into the system-auth file, as described in Appendix A.

You should also change the /etc/pam.d/passwd file, which controls the passwd command’s actions. As described in Appendix A, this change requires adding references to pam_winbind.so to the auth, account, and password stacks.

Tip

You normally don’t need to change the /etc/pam.d/samba configuration. The Samba server provides its own tools for authenticating against the domain controller, and in fact, if you configure Winbind properly, Samba is automatically configured to use the domain controller directly. Thus, although it has one, there’s no need to edit Samba’s PAM configuration file.