Posted by: Anonymous
on October 15, 2008 06:34 PM
I do use this, both with LDAP and with TACACS+ (the pam_tacplus module). It is very, very nice for centralizing authentication.
To answer the second poster's question of where you'd wnat to use this, here's how I do it. I have a bunch of GNU/Linux boxes out at various sites at work. As we know, each has its own /etc/passwd and /etc/shadow, and thus, changing a password or disabling an account becomes tedious. With PAM on these end-stations pointing to one or more centralized LDAP or TACACS+ authentication server(s), that tedium goes away. At work, I do it against a TACACS+ server, and at home, I use LDAP.
Here's another one. Let's suppose you want to move from MS Windows Active (Craptive?) Directory to a Samba-LDAP backend. No problem, that's built into Samba, so you have your PDC/BDC setup done there. But wait, you now also want to convert at least some of your end stations from, say, Windows XP to GNU/Linux. Naturally, you want to maintain single-sign-on for GNU/Linux end stations like you have the MS Windows end stations. Maybe you even want to do LTSP against that LDAP server. PAM is what makes that happen.
Here's a third. Say you have your Apache server, and you'd like for it to authenticate against /etc/passwd and /etc/shadow. One way to do this is to allow the Apache process to read /etc/shadow. Well, that's a bad idea from a security perspective. Much better to have Apache go through PAM. Furthermore, this is how you can get Apache to authenticate against LDAP.
So, this has a lot of uses, and it's highly recommended for enterprise environments. Some (like Pat Volkerding of Slackware fame) don't like it, and he's made clear why. Others say, a *correctly configured* PAM is just as secure as doing things the traditional way and gives you way more flexibility. I've come to agree with the latter.
BTW, yes, the first thing I thought of was the cooking oil, too. :-)