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

Appendix A. Configuring PAM

Modern Linux distributions rely on the Pluggable Authentication Modules system for authentication. Part III of this book describes three network authentication tools, all of which can be used in conjunction with PAM to provide authentication for arbitrary servers and other programs that require authentication. In order to avoid duplicating content, therefore, this appendix describes PAM in detail; Part III provides a much briefer description of how PAM interacts with the relevant servers.

In order to get the most out of PAM, it helps to begin with some background—what PAM is, what it can do, why it’s used, and so on. You must also understand the PAM configuration file format; PAM configuration involves editing one or more of these files. From there, knowing something about individual PAM modules, including both the standard ones and those described elsewhere in this book, will help you create an appropriate configuration. Finally, some examples of working PAM configurations will help you understand PAM and provide models you can adapt for your own use.

PAM Principles

In Linux’s early days, every server or other tool that had to authenticate users did so by reading /etc/password, the traditional Unix account file. This approach was easy to implement, but it had several problems. One of these was that the file, and hence the encrypted password, had to be readable by all users, making it vulnerable to cracking. Another problem is that changes to authentication methods, such as new password-encryption systems, required changes to all the programs that could authenticate users. This problem would result in a nightmarish tangle of upgrades should an administrator ever want to change the authentication system.

PAM is designed to solve these problems. PAM solves the problem of world readability of /etc/passwd by implementing a system known as shadow passwords, in which passwords are moved out of /etc/passwd and into a file that can be read only by root—typically /etc/shadow on Linux systems. (Shadow passwords can be implemented without PAM, but today PAM is the tool that does it on all major Linux distributions.) PAM helps minimize the pain of changing authentication systems by working as a layer between the tools that authenticate users and the account database. Instead of accessing /etc/passwd directly, programs consult PAM, which accesses /etc/passwd. Thus, if the format of data in /etc/passwd changes, individual servers don’t need to be rewritten or even recompiled; only PAM must change. Indeed, PAM can be changed to support authentication systems that don’t even consult /etc/passwd. It’s this feature of PAM that Winbind, LDAP authentication, and some Kerberos tools use. Rather than consult /etc/passwd, PAM consults the appropriate network authentication tool.

Tip

In addition to PAM, Linux relies on another software component, the Name Service Switch, for account information. Rather than authentication information, though, NSS provides more mundane information, such as a mapping of UIDs to usernames and the account’s default shell. Like PAM, NSS is designed in a modular way and sits between applications that ask for this information and the actual account databases. Although you may think in terms of authentication, which is what PAM provides, this ancillary information is just as important, so you must configure NSS to link to your authentication system. The chapters on Winbind and LDAP describe configuring NSS to work with these tools, but Kerberos provides no NSS interface, which is a limitation of Kerberos if you want a network authentication system to handle all your account information.

In practice, PAM is a modular tool: it consults libraries to handle various parts of the authentication procedure. You tell PAM which libraries to consult with the help of the PAM configuration files, which are described in the next section. Thus, the overall authentication system, and its equivalent in pre-PAM days, are depicted in Figure A-1. PAM’s modular nature is manifested in this figure by the fact that PAM is shown accessing three independent authentication tools—the /etc/passwd file, an NT domain controller, and an LDAP server. A default configuration is likely to be simpler than this, but if you want to use a network authentication tool, chances are you’ll leave the old-style /etc/passwd authentication intact as a backup and to provide information for accounts you might not want to define using a centralized system, such as the root account.

PAM distances servers and other programs that require authentication from authentication implementations, increasing flexibility—and complexity

Figure A-1. PAM distances servers and other programs that require authentication from authentication implementations, increasing flexibility—and complexity

In practice, PAM configuration is even more complex than Figure A-1 suggests, for three reasons:

  • PAM provides management features beyond those related to account authentication. In particular, it supports authentication (verifying that users are who they claim to be), account management (checking for expired accounts, the right to use a particular server, and so on), session management (login and logout housekeeping), and password changes. Each management system must be configured individually; for instance, the modules called in service of authentication may be different than those required for session management.

  • A single act, such as logging in, may require multiple PAM modules. For instance, many PAM login configurations call a module called pam_deny.so, which explicitly denies access to the system if no earlier module has explicitly granted access. You can even tack on modules that aren’t directly related to authentication, such as modules that display login notices.

  • Each program that requires PAM’s services may be configured individually. For instance, you might want to use one set of options for authenticating users for console logins and another for authenticating users to use the su command to change their effective UID numbers.