Hello everybody, I am looking for a way to have different authentication policy for a freeia-client logout and screenlock on linux workstations. When a user logs in I want to use my password+otp (this is working)! When a user locks it screen I want to be able unlock it with only the password. When a user logs out and back in then it needs to use the password+otp again. I am aware of the security implications for this. How can I configure this policy?

On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote: > Hello everybody, > > > I am looking for a way to have different authentication policy for a > freeia-client logout and screenlock on linux workstations. > > When a user logs in I want to use my password+otp (this is working)! > > When a user locks it screen I want to be able unlock it with only the > password. > > When a user logs out and back in then it needs to use the password+otp > again. > > I am aware of the security implications for this. > > How can I configure this policy? I don't think there is a way to deploy such policy through SSSD at all. Jakub, do you have an idea how to make that possible?

On 18/03/2019 20:44, Jakub Hrozek wrote: > On Mon, Mar 18, 2019 at 06:14:16PM +0200, Alexander Bokovoy wrote: >> On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote: >>> Hello everybody, >>> >>> I am looking for a way to have different authentication policy for a >>> freeia-client logout and screenlock on linux workstations. >>> >>> When a user logs in I want to use my password+otp (this is working)! >>> >>> When a user locks it screen I want to be able unlock it with only the >>> password. >>> >>> When a user logs out and back in then it needs to use the password+otp >>> again. >>> >>> I am aware of the security implications for this. >>> >>> How can I configure this policy? >> I don't think there is a way to deploy such policy through SSSD at all. >> >> Jakub, do you have an idea how to make that possible? > > Currently I can't think of anything clean either. Is the lock screen > and the > login manager the same PAM service? If they are different, maybe some > hack like letting pam_unix to always read the password and then just > pass it on to pam_sss would work.. > > But I know Sumit is working on improving the 2FA prompting lately, so > maybe this will be improved in the upcoming release. I seem to have mate-screensaver, lightdm and xrdp-sesman. Will that be enough to hook a custom pam rule together for mate-screensaver? If not is it possible to disable OTP for all the destkop systems in sssd.conf? and have it still working for all other systems with --user-auth-type=otp as only enabled option in freeipa? Also for laptop systems in offline disable_preauth forward_pass

On Mar 29, 2019, at 8:28 AM, Jelle de Jong via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt; wrote: Hello everybody, I tried the bellow configuration, but I can still only authorize with pass+otp. I assume pam_unix.so only works for local users? I only have sssd freeipa users. Is there a way to tell pam_sss.so to only use the password if --user-auth-type=otp is set? /etc/pam.d/common-auth auth [success=2 default=ignore] pam_succeed_if.so service in mate-screensaver:lightdm:xrdp-sesman auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth requisite pam_deny.so auth required pam_permit.so auth optional pam_ecryptfs.so unwrap auth optional pam_cap.so Mar 29 13:19:01 workstation01 mate-screensaver-dialog: pam_succeed_if(mate-screensaver:auth): requirement "service in mate-screensaver:lightdm:xrdp-sesman" was met by user "jdejong" Mar 29 13:19:49 workstation01 mate-screensaver-dialog: pam_unix(mate-screensaver:auth): authentication failure; logname= uid=350600026 euid=350600026 tty=:10.0 ruser= rhost= user=jdejong Mar 29 13:19:50 workstation01 mate-screensaver-dialog: pam_sss(mate-screensaver:auth): authentication success; logname= uid=350600026 euid=350600026 tty=:10.0 ruser= rhost= user=jdejong Kind regards, Jelle de Jong On 26/03/2019 18:04, Charles Hedrick via FreeIPA-users wrote: > Basically if you put pam_unix before pam_sss, you’ll get a single prompt, and things like RDP will work with OTP. > Here’s the default in password-auth and system-auth for Centos 7 > auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet > auth [default=1 ignore=ignore success=ok] pam_localuser.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 1000 quiet_success > auth sufficient pam_sss.so forward_pass > This causes local users and users with UID < 1000 to use Unix, otherwise go directly to sss. > You can add another line to test for specific services, and force pam_unix, i.e. a single prompt, e.g. > auth [success=2 default=ignore] pam_succeed_if.so service in lightdm:xrdp-sesman. > auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet > auth [default=1 ignore=ignore success=ok] pam_localuser.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 1000 quiet_success > auth sufficient pam_sss.so forward_pass > The one that gets messy is x2go, because it uses ssh, and can’t be detected by a service test. >> On Mar 19, 2019, at 2:16 PM, Jelle de Jong via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt; wrote: >> >> Hello everybody, >> >> Thank you all for replying. >> >> On 18/03/2019 20:44, Jakub Hrozek wrote: >>> On Mon, Mar 18, 2019 at 06:14:16PM +0200, Alexander Bokovoy wrote: >>>> On ma, 18 maalis 2019, Jelle de Jong via FreeIPA-users wrote: >>>>> Hello everybody, >>>>> >>>>> >>>>> I am looking for a way to have different authentication policy for a >>>>> freeia-client logout and screenlock on linux workstations. >>>>> >>>>> When a user logs in I want to use my password+otp (this is working)! >>>>> >>>>> When a user locks it screen I want to be able unlock it with only the >>>>> password. >>>>> >>>>> When a user logs out and back in then it needs to use the password+otp >>>>> again. >>>>> >>>>> I am aware of the security implications for this. >>>>> >>>>> How can I configure this policy? >>>> I don't think there is a way to deploy such policy through SSSD at all. >>>> >>>> Jakub, do you have an idea how to make that possible? >>> Currently I can't think of anything clean either. Is the lock screen and the >>> login manager the same PAM service? If they are different, maybe some >>> hack like letting pam_unix to always read the password and then just >>> pass it on to pam_sss would work.. >>> But I know Sumit is working on improving the 2FA prompting lately, so >>> maybe this will be improved in the upcoming release. >> >> I seem to have mate-screensaver, lightdm and xrdp-sesman. >> >> Will that be enough to hook a custom pam rule together for mate-screensaver? >> >> If not is it possible to disable OTP for all the destkop systems in sssd.conf? and have it still working for all other systems with --user-auth-type=otp as only enabled option in freeipa? >> >> Also for laptop systems in offline >> >> disable_preauth >> forward_pass >> >> Mar 19 18:54:50 workstation01 mate-screensaver-dialog: pam_unix(mate-screensaver:auth): authentication failure; logname= uid=350600021 euid=350600021 tty=:10.0 ruser= rhost= user=jdejong >> >> Mar 19 18:54:51 workstation01 mate-screensaver-dialog: pam_sss(mate-screensaver:auth): authentication success; logname= uid=350600021 euid=350600021 tty=:10.0 ruser= rhost= user=jdejong >> >> Mar 19 18:56:48 workstation01 xrdp-sesman[788]: pam_unix(xrdp-sesman:auth): authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=jdejong >> >> Mar 19 18:56:48 workstation01 xrdp-sesman[788]: pam_sss(xrdp-sesman:auth): authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=jdejong >> >> Mar 19 19:01:01 workstation01 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=jdejong >> >> Mar 19 19:01:01 workstation01 lightdm: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=jdejong >> >> cat /etc/pam.d/mate-screensaver >> @include common-auth >> auth optional pam_gnome_keyring.so >> >> cat /etc/pam.d/common-auth >> # >> # /etc/pam.d/common-auth - authentication settings common to all services >> # >> # This file is included from other service-specific PAM config files, >> # and should contain a list of the authentication modules that define >> # the central authentication scheme for use on the system >> # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the >> # traditional Unix authentication mechanisms. >> # >> # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. >> # To take advantage of this, it is recommended that you configure any >> # local modules either before or after the default block, and use >> # pam-auth-update to manage selection of other modules. See >> # pam-auth-update(8) for details. >> >> # here are the per-package modules (the "Primary" block) >> auth [success=2 default=ignore] pam_unix.so nullok_secure >> auth [success=1 default=ignore] pam_sss.so use_first_pass >> # here's the fallback if no module succeeds >> auth requisite pam_deny.so >> # prime the stack with a positive return value if there isn't one already; >> # this avoids us returning an error just because nothing sets a success code >> # since the modules above will each just jump around >> auth required pam_permit.so >> # and here are more per-package modules (the "Additional" block) >> auth optional pam_ecryptfs.so unwrap >> auth optional pam_cap.so >> # end of pam-auth-update config >> >> sssd 1.16.1-1ubuntu1.1 >> >> root@workstation01:~# ls -hal /etc/pam.d/ >> total 136K >> drwxr-xr-x 2 root root 4,0K Mar 15 11:35 . >> drwxr-xr-x 161 root root 12K Mar 19 18:22 .. >> -rw-r--r-- 1 root root 384 Jan 25 2018 chfn >> -rw-r--r-- 1 root root 92 Jan 25 2018 chpasswd >> -rw-r--r-- 1 root root 581 Jan 25 2018 chsh >> -rw-r--r-- 1 root root 1,3K Mar 11 16:11 common-account >> -rw-r--r-- 1 root root 1,4K Mar 11 16:11 common-auth >> -rw-r--r-- 1 root root 1,6K Mar 11 16:11 common-password >> -rw-r--r-- 1 root root 1,6K Mar 11 16:11 common-session >> -rw-r--r-- 1 root root 1,5K Mar 11 16:11 common-session-noninteractive >> -rw-r--r-- 1 root root 606 Nov 16 2017 cron >> -rw-r--r-- 1 root root 69 Mar 27 2018 cups >> -rw-r--r-- 1 root root 884 Mar 22 2018 lightdm >> -rw-r--r-- 1 root root 551 Mar 22 2018 lightdm-autologin >> -rw-r--r-- 1 root root 727 Mar 22 2018 lightdm-greeter >> -rw-r--r-- 1 root root 4,9K Jan 25 2018 login >> -rw-r--r-- 1 root root 57 Dec 11 2014 mate-screensaver >> -rw-r--r-- 1 root root 92 Jan 25 2018 newusers >> -rw-r--r-- 1 root root 520 Apr 4 2018 other >> -rw-r--r-- 1 root root 92 Jan 25 2018 passwd >> -rw-r--r-- 1 root root 270 Jul 13 2018 polkit-1 >> -rw-r--r-- 1 root root 168 Feb 26 2018 ppp >> -rw-r--r-- 1 root root 143 Feb 14 2018 runuser >> -rw-r--r-- 1 root root 138 Feb 14 2018 runuser-l >> -rw-r--r-- 1 root root 84 Nov 8 19:09 samba >> -rw-r--r-- 1 root root 2,1K Mar 4 13:17 sshd >> -rw-r--r-- 1 root root 214 Jan 16 16:58 sssd-shadowutils >> -rw-r--r-- 1 root root 2,3K Jan 25 2018 su >> -rw-r--r-- 1 root root 239 Jan 18 2018 sudo >> -rw-r--r-- 1 root root 317 Apr 20 2018 systemd-user >> -rw-r--r-- 1 root root 104 Feb 16 2018 xrdp-sesman >> >> Thank you in advance! >> >> Kind regards, >> >> Jelle de Jong >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...