Hello! While trying to configure and understand pam autentication and name service switch in the context of ldap I had a hard time to find clear and complete documentation, configuration examples and aplication hints.
As it seems, pam autentication is yet standard on Debian systems, however the debian policy does not cover it (yet), neither nsswitch configuration so I want to propose some issues. Disclaimer: Please understand that I am somewhat novice to these themes, so please be so polite to ignore my nuisances. * General questions It seems to me, that pam and nsswitch resolve some issues in parallel, so there would have to be made a choice how to deal consistently without loosing flexibility. I am thinking about session managment, where some pam modules provide information about, e.g. home directory and login shell, while nsswitch serves the same purpos. With retrieval of autentication information we have the same situation, you can go either way: nss or pam. Pam seems not to reimplement standard autentication completely. While the shadow-suite sets some standards (login.defs) over standard login handling, pam seems not to implement the whole set of it's features - correct me if I'm wrong: root path vs user path (ENV_[SU]PATH) is not equally handled. There are other examples, like password changing, etc. which are not/not yet implemented in pam, or where the pamified program versions are not installed. * Proposal A policy chapter or document should be created, where authentication and name service is thoroughly covered, so that package maintainers can orient themselves of how to (re)configure their pieces of software, and from where they can derive the TODO's to make them compliant. PAM authentication and NSS auth-information retrieval should be the default configuration, while allowing to substitute it for the shadow and the standard passwd suite as options. The default PAM/NSS configuration should emulate the shadow suite. Each pam/nss/sasl module should install a defined default configuration, giving reasonable "best" security to the system. The configuration script should allow (see later) to modify some parameters of the authentication configuration in a standardized way. Sources of nss/pam information (slapd, db2, smb) should also come with reasonable "best" security preconfigured (slapd installs by default without access restrictions to smb-passwords). A set of standard programs should be written, which ONLY rely on PAM/NSS, so that the full power of their modularity can be exploited. Candidates are: login, passwd, chfn, chsh, sudo, su, etc. (if not yet done!) Especially information storing (passwd, chfn, chsh) shall be included, so that credentials can be updated in parallel. If not the case yet, "getent" or a similar utility should be used as the standard way (and mentioned as such) to retrieve name service information. I stumbled over dh_make, which goes through a long and fixed ordered list of individual queries to obtain my Full Name, while this could be done more easy and compliant to my systems nss search order configuration via "getent passwd $LOGIN". * PAM documentation and configuration handling ** Drawbacks The original PAM Documentation is very good and creates some kind of standard in the reference part of the modules. However this standard is not taken up by the newer pam modules and ocasionally you have to go to the c-sources to know which pam functions they implement. On the other side, it is not clear which applications use pam, and which pam functions are used by them. So the pam.d directories shows entries in some configuration files, which never will be called by aplications. This of course tends to obscure the meaning of the configuration file. The original "other" configuration is "wide open" explicitly against the recomendation of the "Pam Systems Administrators Manual". ** Proposal A pam module must install a cross reference documentation for itself, similar to the original module documentation, to comply with the policy. Each application which uses the pam library *must* provide documentation which states *which* pam routines are used. If pam is not used in all aplicable cases, the exceptions also have to be documented. Each autentication/nss affine application which does *not* use pam/nss *should* state this fact, at least in the README.Debian file. Each application using the pam library *must* install a configuration file in the pam.d directory, which generates a default compliant configuration for this aplication. Don't know what to do with different applications with the same service name (configuration file), maybe a authoritative list of service names should be maintained, at least for Debian. A convenient place for the application to place it's pam-usage information is the pam.d configuration file, if posible in a parsable way, so that configuration scripts can rely on the information. It would be nice to have a tool which scans a pam module for the pam routines it provides (elf can do that, does it?) and writes them to stdout. It would of course also be nice to have each pamified aplication have a command line option, showing the pam routines it uses. Given the former two or three tools/functionalities, it would be able to write a configuration tool for each pam module, which checks its applicapility for each installed service (pam-application) and installs a configuration line in the corresponding service configuration file. This utility should: - install standard modules options without questions - install optional pam-module configurations after confirmation from the installer or - install a "best security" configuration if non-interactive or - install a commented out configuration line and notify the administrtator. - allow the administrator determine level (order) and action of the module, as well as eventually establish the provided module options. The level can be given as a number, similar to the selection of the ispell dictionary sequence. - be usable to reconfigure the service files. Another issue with pam modules is logging. The log format should be unified, so that the administrator can identify wether it is the pam library itself or a module, and which pam module issues the message (if we are using a pam stack). In especial with stacked autentication modules it is of use to know *which* module of the stack has finally given the authorization. This can reveal security setup faults. Actually the modules only log failed autentication, but not granted autentication. This can be changed in *some* modules using the "debug" option. On one hand a "verbose" option would be better for this issue, so one does not have to clutter up syslog with debug messages when tracing authentication, on the other hand each pam module should be required to be able to generate this message to be compliant to Debian. * Name Service Switch As I have even less experience and less documentation digested with this, this section stays almost empty. However the obvious thing is to define the way, nsswitch.conf is maintained. If somebody installs, lets say, libnss-ldap, a proper modification to this file has to be made, and the adminstrator has to be able to select the databases affected and the order of search. On the other hand, all Debian utilities which use the system databases have to be revised, so that they access uniformly to them via libnss. See my example about dh_make. This issue should really be addressed in the main policy manual, so that package maintainers and builders are aware. I'm saying this as a Newbie-Unix-administrator, as we are the most out there who are installing a Debian computer. Nobody told me about nss, and the "books" are full of "grep $USER /etc/passwd" ;-) Help us to learn "good practice" from the start. * OpenLDAP When installing slapd and openldap and maybe other ldap before, etc. I found myself with the fact (after strace-ing ldapsearch), that openldap looks for /etc/openldap/ldap.conf, which is identical to the file in /etc/ldap/ldap.conf, with the diference that /etc/ldap/* get's configured to my needs by slapd and the other stays clean. The point is, that the tools do not find their configuration because they use other directory then debconf. While this may seem a mere concern of the package maintainer, it shows also the need for a, surprise!, ldap-policy. Other example is, that the nss and pam modules for ldap utilizan /etc/ for their configuration files, while this could maybe logically fit into /etc/ldap too. The security concern is mentioned already: while a lot of schemes are supplied for slapd, only *one* access restriction politics is given - for userPassword. **Proposal - All ldap related programs shall use /etc/ldap/ for their configuration files, *and* reuse existing files. For this reason, a configuration file nameing scheme should be pointed out. - Debian should adopt the Domain-Component notation as standard, easying the standard setup of a server and of the clients, by using known information items - in this case the domain name of the machine. - Each scheme installed should be acompanied by a corresponding security setup, and maybe the installation script should take care of it. Schemes for which a security setup is not (yet) available shall not be installed in /etc/ldap/schemes, but in /usr/share/doc/<package>/examples * Sasl I know even less about sasl... Tell me how it fits in * Maildir Off Topic The Policy states, that /var/mail is the standard mail spool. Probably this issue should be revised, giving ~/Maildir/ at least an optional status. Nowadays probably a wealth of Debian Machines, more than other distribution are using Maildir aware MTA's and MUA's. There should be a note in README.Debian of each MTA and MUA if it is Maildir and/or /var/mail capable, and maybe a system configuration choice should be made available via debconf or the like, respected by packages capable of both posibilities. Packages which are not compatible with the actual system mail directory setup should refuse to install or configure. An example is Kmail, which is not Maildir aware. However there is a script available (basically from the qmail software, wrapped by me) which converts the Maildir contents to a /var/mail/<user> mailbox, and which can be plugged into the retreival mecanism of Kmail. Something like this could be done either way when packaging a MUA or MTA. * My personal motivation While installing more and more Debian Systems, mostly in small and heterogeneous Linux/Microsoft networks, I face the fact, that Debian configuration is much more work (albeit less trouble :) then MS installation. In my context - Nicaraguan small business and tecnical universities, where on the one hand there ARE a lot of computers, but on the other hand it is dificult to get qualified IT personal, this reduces the chances of placing Linux "in the market" almost to zero - everybody fears, that when the "chele" (my person) goes away, there will be no one left to manage the beast. Free Software is surely a great potential, especially in "development" countries, where it can help with the apropiation of the employed tecnology itself, in contrast to propietary systems, which tend to increase dependence, curiously by the side efect of (I know this is not the right term) piracy: As propietary software is practically gratis, it is very widespread, for the corresponding industry this means a costless training and propaganda system. Once forced to use the software profesionally, the user yet is locked in into the propietary system. Of course there is the other argument, that low profile and obsolete Hardware can nowadays only be exploited by Open Source products, I can even give you some own examples: http://sam.uni.edu.ni is a 50Mhz/32MByte 486 Olivetti PC and running since half a year, and there is a masquerading firewall with a similar machine under heavy duty on the León UNAN University net, aliviating the lack of IP Numbers for about thirty Window machines, running over a year practically without administrative intervention, not to speak of the computer oldtimer museum I am hording at home. However I consider this a foul and lazy point of view. Industry, government and people by themselves are buying the newest tecnology computers on a daily basis, and where Information Technology is to be playing a role, it will be on the most actual hardware. While personally beeing a computer recycle fanatic I try NOT to convince anybody here, that this is the better solution, because people deserve to be on top tecnology and knowledge to overcome the economic and social problems with which they are struggling. Now, coming back to the original theme, I am working on creating a project which uses Debian and some of the wonderful tools existing on it to form a set of installation and configuration tools, which allow people to build and maintain computer network "cells" out of the box with minimal effort and time, and a given set of functionality and applications. These "cells" should be private networks which can be "pluggable" into the Internet or any other "comunity network" via one of the machines, such forming parts of bigger networks. The target are computer classrooms, Internet Cafés, small and middle business networks, comunity groups etc. While exploring this task I found myself faced with the problems discribed above. Please contact me, if you are interested in the project, or if you are doing something similar. Best Regards, Georg Lehner, alias Jorge-León