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 -- 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