[Freeipa-users] Re: OTP behaviour on Debian

2021-12-14 Thread Sam Morris via FreeIPA-users
On Tue, 2021-12-14 at 10:23 +0100, Sumit Bose wrote: > Am Mon, Dec 13, 2021 at 06:14:13PM - schrieb Sam Morris via FreeIPA-users: > > > > > I've filed https://bugs.debian.org/1001644 to discuss whether pam_sss can > > be moved before pam_unix in the Debian packaging. > > Btw, in RHEL and

[Freeipa-users] Re: OTP behaviour on Debian

2021-12-14 Thread Sumit Bose via FreeIPA-users
Am Mon, Dec 13, 2021 at 06:14:13PM - schrieb Sam Morris via FreeIPA-users: > You're absolutely right. On Debian in /etc/pam.d/common-auth we have: > > # here are the per-package modules (the "Primary" block) > auth[success=2 default=ignore] pam_unix.so nullok > auth[success=1

[Freeipa-users] Re: OTP behaviour on Debian

2021-12-13 Thread Sam Morris via FreeIPA-users
You're absolutely right. On Debian in /etc/pam.d/common-auth we have: # here are the per-package modules (the "Primary" block) auth[success=2 default=ignore] pam_unix.so nullok auth[success=1 default=ignore] pam_sss.so use_first_pass # here's the fallback if no module succeeds

[Freeipa-users] Re: OTP behaviour on Debian

2021-12-13 Thread Sumit Bose via FreeIPA-users
Am Mon, Dec 13, 2021 at 01:34:12PM - schrieb Sam Morris via FreeIPA-users: > I enabled OTP for my user. On RHEL and Fedora systems, I get the > expected interactive 'first factor' followed by 'second factor' > prompts which work fine. > > On a Debian system, PAM still only gives me the single