Dan Mahoney <d...@prime.gushi.org> writes: > Our userbase is pretty small and systems are overall managed with > puppet, so that's not a problem for us. We'd need to either disallow > GSSAPI entirely, or accept that we need to manipulate a dir of k5login > files outside the users' homedirs.
If you're already willing to manage .k5login files, the search_k5login option to my PAM module may also work and the whole reason why I started contributing to that module instead of using Red Hat's (to solve an old issue that Stanford had). alt_auth_map is the more precise solution, but it only allows a single mapping, whereas with search_k5login you can do whatever you want as long as you populate .k5login accordingly. > I'll take a directory of k5login files. As an organization we don't > like pubkey auth because there's no easy central control over users. > (i.e. pubkey completely sidesteps kerberos. If you have something like > ldap deployed, that can help, but we don't like the idea of every system > call like ls -al phoning an LDAP server.) Yes, at Stanford we disabled public key and required GSS-API for most things. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos