[Freeipa-users] Debian: libpam-sss pam-configs update?

[Sumit Bose]

On Wed, Jan 04, 2017 at 10:39:37AM +0100, Jochen Hein wrote:
> 
> Hi,
> 
> I'm still working on my Debian systems to get local login to work with
> OTP.
> 
> In /etc/pam.d/common-auth we have:
> auth    [success=2 default=ignore]      pam_unix.so nullok_secure
> auth    [success=1 default=ignore]      pam_sss.so use_first_pass
> 
> On CentOS we have something more complicated in /etc/pam.d/system-auth:
> 
> auth        [default=1 success=ok] pam_localuser.so
> auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
> auth        sufficient    pam_sss.so forward_pass
> 
> I think we need something more elaborated for debian to replicate the
> (good!) experience from CentOS when asking for "First/Second Factor".
> The four lines from above work well, but how can we get that into
> pam-auth-update? Any ideas how this could be packaged?

The 

    auth        [default=1 success=ok] pam_localuser.so

line was added in CentOS/RHEL to make sure that the PAM conversation is
run by pam_sss for users managed by SSSD and not by pam_unix because
pam_unix can only ask for a password. It would have been possible to
call pam_sss first but it was considered safer to have pam_unix first to
make sure root login will always handled by pam_unix.

It has to be noted that pam_sss currently is a bit special when a
modules called earlier, e.g. pam_unix, put a password on the PAM stack.
Only if use_first_pass is used pam_sss will use the password on the
stack but also will never prompt on its own. If use_first_pass is not
used pam_sss will always prompt on its own and never check if there is
already a password in the stack. This behaviour was there since the very
first versions of pam_sss because we didn't wanted to copy the
try_first_pass behaviour of other PAM modules because this try-and-error
scheme might easily wrong password counters and lock accounts. So we
assumed that pam_sss is either the first module or will get the password
from other modules. This is why there is the 'default=die' option in the
pam_unix line for CentOS. But it turns out that there are valid use
cases where pam_sss should handle the prompting for SSSD users but
should accept a password on the PAM stack as well.

We plan to fix this with https://fedorahosted.org/sssd/ticket/2984 so
that pam_sss will check for a password on the PAM stack even if
use_first_pass is not set. But if there is one pam_sss will only use
this and will not prompt for other credentials is password
authentication fails. So the pam_localuser line will still be needed to
make sure users handled by SSSD will be prompted by pam_sss exclusively.

HTH

bye,
Sumit

> 
> Jochen
> 
> -- 
> The only problem with troubleshooting is that the trouble shoots back.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project