Ross Patterson wrote:
> The PAM-LDAP module made it possible to integrate Linux systems into this 
> environment, because in a rare instance of clear vision Microsoft allowed 
> LDAP access to their Windows domain controllers.  Becuase of PAM's model of 
> return values, we were able to set up configurations that, for example, 
> allowed root to log on from the physical console without a password, but only 
> when the domain controller was unavailable.  Some folks will scream that 
> that's a *very* insecure situation, but that's a matter for the local 
> administration to decide.  In our case, those systems were located inside 
> physically secure facilities, and the system managers believed that access to 
> the consoles was protected well enough to make it appropriate.

pam-ldap isn't the only way to do it. Just because your system support
pam-ldap, doesn't mean there aren't any other frameworks which are not PAM
which will do the same. We're using qmail-ldap, sqwebmail, courier-imap,
Cisco ACS, PHP scripts all authenticating from an LDAP directory,
without PAM. These packages are already LDAP-aware, so it's easy.

This isn't what's being discussed here if you didn't notice. What's
being discussed are merits and failures of different frameworks,
including PAM which will some day be included in NetBSD. The PAM
implementation which NetBSD may have in the future will not necessarily
mean you'll be able to use pam-ldap natively. Which, as I understand is
being written to support Linux as the first target. I believe it will
work with FreeBSD because FreeBSD borrows the Linux PAM.

If however an authentication framework allowed for such simplicity that
writing an authentication module would be trivial - you could have
written one in a day or so, and wouldn't even be required to be written
in C. Which is exactly what an exec chain would allow for. Take a look
at pam-ldap source. It's a monster compared to the size of checkpassword
interface tools.