-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 26 Sep 2002, Dan Melomedman wrote:

>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.

In other words, you're recommending that people who wish to use LDAP
write/use five different LDAP client implementations, and then they
still won't be able to do what Ross mentions, as none of ssh, rsh,
telnet, etc. support LDAP at all?

I guess most people on the list can see why this is a non-starter.


>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.

So, in other words, you hold the fact that we might be dumb enough to
implement something which calls itself PAM but is not compliant with
everyone else's PAM implementations as a good reason for us not to
implement 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.

What you miss is that almost all of that code is dealing with complex
and highly configurable use of LDAP -- it isn't the PAM part which makes
it complex (compare pam_ldap with other pam modules if you aren't sure).

I seriously doubt that an LDAP module for your imaginary
generalized-exec-chaining-module-api would be any shorter than pam_ldap,
and I'm quite sure that it wouldn't work in many of the contexts in
which PAM is used (such as in apache modules or for database access).

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)

iD8DBQE9kz5dlGcH240chEIRAn8bAJ96B7UhZb/5h77jqm77r6EUNwrkOgCgydNx
WKiYHP2e8nXkbS3qiu5RtIw=
=Z4YC
-----END PGP SIGNATURE-----