In the default configuration, /etc/pam.d/common-auth contains:

  auth	[success=2 default=ignore]	pam_unix.so nullok
  auth	[success=1 default=ignore]	pam_sss.so use_first_pass
  auth    requisite                       pam_deny.so

This means that pam_unix has the first & only change to prompt the user
for authentication, and the user gets a single 'Password:' prompt.

In the Red Hat world, /etc/pam.d/password-auth contains:

  auth        required                                     pam_env.so
  auth        required                                     pam_faildelay.so delay=2000000
  auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
  auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
  auth        sufficient                                   pam_unix.so nullok
  auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
  auth        sufficient                                   pam_sss.so forward_pass
  auth        required                                     pam_deny.so

A local user will hit pam_unix. A non-local user will skip over it and
be prompted by pam_sss.so.

An easy fix is to increase the Priority in /usr/share/pam-configs/sss to
some value > 256. That way, pam-auth-update puts pam_sss before
pam_unix.

I tested this, and 'su - localuser' still works.

Unfortunately I don't know of a way for a user to override this value
other than by editing that file, which is owned by libpam-sss.

Is there a good reason that pam_unix has to be first in the module
stack? If not, could we make this change?

- -- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 'unstable'), (500, 'stable-security'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-sss depends on:
ii  libc6             2.32-5
ii  libgssapi-krb5-2  1.18.3-7
ii  libpam-pwquality  1.4.4-1
ii  libpam-runtime    1.4.0-9+deb11u1
ii  libpam0g          1.4.0-11

Versions of packages libpam-sss recommends:
ii  sssd  2.6.1-1

libpam-sss suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYbeFXRIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIpR9gEAldojCYmY4mvOcns5k9wcfXpTN324+MUx
wiiKCeGy5PgBAKsWW6nGrvuFyQggaQADHH5O1p+bdr5q35Bp4suL0w0A
=ldXe
-----END PGP SIGNATURE-----

On 13.12.2021 19.39, Sam Morris wrote:
 > Package: libpam-sss
 > Version: 2.6.1-1
 > Severity: normal
 >
You're asking in the wrong place.. Anyway, pam_sss is not above pam_unix
in Fedora either, so why should it have a higher priority here?

My goal is to get 2-factor authentication working on Debian systems as
easily as it does on Fedora/RHEL systems. This requires pam_sss to
prompt the user for their password, not pam_unix.

Here's a solution that uses pam_localuser to prevent pam_unix from being
invoked for pam_sss's users:

    # here are the per-package modules (the "Primary" block)
    auth	[default=1 ignore=ignore success=ok]         pam_localuser.so
    auth	[success=2 default=ignore]	pam_unix.so nullok
    auth	[success=1 default=ignore]	pam_sss.so
    # here's the fallback if no module succeeds
    auth	requisite			pam_deny.so

But, this another package to change for us (libpam-modules which ships
/usr/share/pam-configs/unix). We can ask, of course....

For this to work, I had to remove the 'use_first_pass' option from
pam_sss. Otherwise FreeIPA users can't log in any more:

    (2022-02-01 10:22:06): [be[ipa.example.com]] [krb5_auth_send] (0x0020): Illegal empty authtok for user [user@ipa.example.com]

Unfortunately pam_sss doesn't have a 'try_first_pass' option. As a
result, if there is _another_ module that runs before pam_sss, AND
prompts the user for a password, storing itin the PAM environment,
pam_sss will not use it, and the user will be prompted for their
'password' or 'first factor' (depending on whether the user requires
MFA) a second time.

Even if 'try_first_pass' did exist in pam_sss, the user would still get
a 'password' prompt instead of a 'first factor' prompt, which is an
annoying behaviour difference between how things work in the Debian
universe rather than the Red Hat universe. The only fix for that is for
every other PAM module to avoid prompting for a password if the user is
'not for them', so that pam_sss still gets to be the first/only module
that prompts for a password, even though it is later on in the stack.

Because of requiring extra work in the libpam-modules package, and the
edge case above, it seems simpler to re-arrange the stack so that
pam_sss goes first.

So, we can either bump the priority of pam_sss, or remove the
use_first_pass option iff the PAM maintainers agree to add pam_localuser
to their pam-auth-update config file. What do you think?

I like Sam's suggestions. Has a maintainer considered it?