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