On Wed, Jan 04, 2017 at 10:39:37AM +0100, Jochen Hein wrote:
> I'm still working on my Debian systems to get local login to work with
> 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
> 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?
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.
> The only problem with troubleshooting is that the trouble shoots back.
> Manage your subscription for the Freeipa-users mailing list:
> Go to http://freeipa.org for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project