Good catch! I had completely forgotten about nss. It may just be because I had a bit of a bad experience when trying to setup Linux logins through an LDAP server with sssd on centos 6. >_> On Aug 10, 2015 9:47 PM, "Michael Torrie" <torr...@gmail.com> 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. */
