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.

My workaround was to add the following at the start of
/etc/pam.d/common-account:

    # skip over pam_unix for non-local users (who will be failed by
    # pam_unix.so)
    account [success=ignore default=1] pam_succeed_if.so uid >= 1000
    account [success=2 default=ignore] pam_succeed_if.so uid <= 59999

Given that pam_unix.so was the only module in the primary section, these
lines would cause processing to skip past both it and the subsequent
'fall-through' pam_deny.so entry, and on to the pam_permit.so entry.
Processing would then continue on to the 'additional' block where
pam_krb5.so would be able to make the accounting decision.

Obviously, if there were any more modules in the primary blovk, the
numbers in those two lines would have to be changed accordingly, which
makes the hack a bit annoying to maintain.

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.

Sam Morris <sam@robots.org.uk> writes:

[...]

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.