[Pkg-sssd-devel] Bug#1001644: Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so

[Sam Morris]

On Wed, Dec 15, 2021 at 11:19:23AM +0200, Timo Aaltonen wrote:
> On 13.12.2021 19.39, Sam Morris wrote:
> > Package: libpam-sss
> > Version: 2.6.1-1
> > Severity: normal
> >
> > 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?
>
> 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 at 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?

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9