> The problem here is that the poster explicitly stated this needed to work with > PPP CHAP authentication. That means that it WON'T work with pam_pwdb, > pam_unix, pam_kerberos, pam_ntdom, pam_userdb, or any other PAM module that > backends onto a user database where passwords are stored in encrypted form. I > would be surprised if pam_ldap worked at all, and pam_radius_auth will only > work if talking to a Radius server that supports CHAP -- which rules out most > of the Radius servers that run under Unix. And that pretty much takes me to The point here isn't so much the encrypted password (tho Livingston's Radius does support CHAP/cleartext passwords) - the point (where I digress from the reply thread) is that PAM is useful purely as an authentication routing mechanism *however* it still tends to be a little too OS bound to be a network-only-auth application (limited only by the current modules which were written for OS-user environments) and where the PAM API doesn't seem to have room for the extra session handling. Don't get me wrong - I think PAM is better than sliced bread .. > the end of the list of PAM authentication modules that I can think of. Unless > you have PHP, MySQL, Apache, Squid, and pppd all configured for PAM and using > a module /other/ than the above, one which uses a cleartext password database, > then you don't gain any interoperability at all by introducing PAM into the > above equation. > > Steve Langasek > postmodern programmer -- RingBurn.com "Where there's smoke, there's fire"
