Control: tags 783473 wontfix Sam Morris <[email protected]> writes:
> A while ago I was configuring NSS and PAM on a system to store user > information outside of /etc/passwd and /etc/shadow, and I ran into a > problem with /etc/pam.d/common-account. > The problem was that pam_krb5.so was not registered as a 'primary' > accounting module, which meant that pam_unix.so would deny logins > because it could not find accounting information about the user in > /etc/shadow. [...] > I suggest changing /usr/share/pam-configs/krb5 such that pam_krb5.so > becomes a 'primary' accounting module; pam_krb5.so and pam_unix.so would > then both be given a chance to approve accounting checks. The problem here is that different Kerberos-using sites want to do different things, which are mutually exclusive. If there were some way for people to easily pick which profile they want, I could provide an alternate profile, but in the absence of that, making pam_krb5.so primary would be a significant security risk for the people using the other approach. There are two basic ways to configure Kerberos authentication. One of them is to not use pam_unix.so at all and control login access via either disabling the default aname to lname mapping or limiting which users are visible to the system in NSS. This works great with Kerberos as a primary accounting module. The other way is to allow the system to see all valid domain accounts, but control which accounts can log in based on which accounts are created locally on that machine. This is a much simpler and more straightforward configuration, but it requires that pam_krb5.so *not* be a primary accounting module so that login control is still based on the existence of accounts on the local system. Both ways work and have different merits. If I change the module to be a primary accounting module, when it historically has not been, people who use the latter configuration suddenly have a serious security vulnerability if they weren't paying attention to the change, since now all local Kerberos accounts can suddenly log on to their systems, ignoring which users were actually created locally. In retrospect, it may have been better to only support the former model and require people using that latter model to specially configure it. But, well, that isn't what happened, and now making that change retroactively is very risky. What I'm hoping is that we'll eventually have some standard mechanism to support this in the PAM configuration system, so that people who want to use the method that you're using can select the alternate profile for how the PAM module is configured. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
