Locking a user's account locally when kerberos is enabled

Solution 1:

I agree with Michael Hampton's comments - you can and should use Kerberos to do this. But if you do want to do it by changing things on the local machine, here's a solution that should work.

In your sshd_config, add the line

DenyGroups blocked

Create a group named "blocked". When locking a user's local password, also add them to the group "blocked".

WARNING! This is a horribly ugly kludge that shouldn't exist in a sane world. It may, however, be useful in the one we live in.

Solution 2:

This problem is mostly a consequence of the fact that pam_unix.so checks for account lockouts in the auth stack instead of account, which is a little counter-intuitive for PAM newbies. Accounting decisions should be made in account, not auth, but shadow based account locks are performed based on the password field. This makes it a necessary compromise.

Before continuing from there and deciding how to implement your fix, let's review the management groups defined by PAM:

• auth -- Authentication concerns. Limit your tweaks to decisions based on credentials the user is submitting to authenticate, particularly since programs may choose to bypass this module entirely if they implement their own authentication scheme. (the example everyone forgets: sshd skips auth if SSH key authentication is enabled and succeeds)
• account -- The one that most people new to PAM overlook. If authentication succeeded but the user should be denied access anyway, that decision should be made here. (sshd will not skip this module if SSH key authentication succeeds, unlike auth)
• passwd -- Changing passwords related to services you defined in auth.
• session -- Miscellaneous tasks that generally have little to do with whether or not authentication succeeds. Logging, mounting stuff, etc.

Based on your problem description:

1. We need an auth stack that prioritizes local credentials over krb5 credentials, but one of the two must succeed. Sounds like you've got that covered.
2. We need an account stack that denies access if no local user is defined. As stated earlier, pam_unix.so fails us in this regard.
3. passwd defaults are probably fine for changing local passwords.
4. We have no immediate reason to touch session.

Based on your proposed self-answer, it looks like you have an idea of where to take it from here.