On August 11, 2015 at 8:47 PM, Michael Torrie wrote:
> Here's an article on implementing pam_mysql and nss_mysql: I'll look at that, Thanks. Does anyone know of an article on setting up pam and nss for pgsql? All my databases are currently in pgsql and I'd rather not go through the effort to dupe them. Thanks! --- Dan On Mon, Aug 10, 2015 at 8:47 PM, Michael Torrie <[email protected]> wrote: > On 08/10/2015 06:42 AM, Frostyfrog wrote: > > As Ed already mentioned, PAM (Pluggable Authentication Modules) are what > > you want to look for. After you install them and set them up, make sure > to > > keep a command line session (ssh, tty2, etc.) open while you test from > > another terminal. You can potentially lock yourself out of the system on > > accident. > > PAM is only half the story, authentication. The other half of the story > is the name service switch, or NSS, which provides the authorization > part of things. In other words, NSS is the mechanism by which > usernames, uids, gids, home directories, etc, are looked up. In an > LDAP-authenticated system usually it requires both pam_ldap and nss_ldap. > > Here's an article on implementing pam_mysql and nss_mysql: > > http://www.idimmu.net/2010/08/27/keeping-linux-users-in-a-mysql-database-with-libpam-mysql-on-ubuntu/ > > If you check out /etc/nsswitch.conf, you'll see that passwd (which > really means uids, gids, home directory, etc), shadow, and group all > have entries that dictate how they are looked up. "files" is usually > the first mechanism defined for each name service. > > Having PAM and NSS separate is kind of nice. For example, I could > configure machines to allow me to log in as some sort of local admin > user (NSS looking in /etc/passwd) via a kerberos ticket[1] (PAM). Then > I could hand out easily revokable kerberos credentials to my programmers > to get them access to the local admin account, but if kerberos were ever > down, I could still log in with the password that I keep. > > Just one scenario where local NSS info combined with remote PAM > authentication is useful. > > > > [1] In case anyone is curious, an easy way to do this is by making the > kerberos principals be something like "username/admin@DOMAIN", and then > telling the local admin account to allow logins from */admin@DOMAIN. > That way the local account needn't be modified when other principals are > created or deleted. > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
