On Thu, Nov 2, 2017 at 9:14 PM, Mario Rossi <mro...@hostopia.com> wrote:
> There are a couple of things to check, older versions of sssd package sudo > in a separate rpm and not all versions of sudo integrate with sssd, upgrade > to the latest sudo package that your distro supports, just in case. > > If sssd.conf has the proper refereces to sudo e.g. > > services = nss, pam, sudo, ssh > ..... > [sudo] > # debug_level=9 > .... > [domain/XYZ] > > sudo_provider = ldap > ldap_sudo_search_base = ou=sudoers,dc=example,dc=net > ldap_sudo_full_refresh_interval = 86400 > ldap_sudo_smart_refresh_interval = 3600 > > Additional troubleshooting steps: > Flush sssd cache just in case with sss_cache -E , as root on the server, > su to the user, do id -G myuser, id myuser, after which try logging in with > ssh as the user and use sudo. List all sudo rules, as root, with: sudo -U > myuser -l > > I almost forgot, /etc/nsswitch.conf must have a sudoers line to point to > sssd: > $ egrep sudo /etc/nsswitch.conf > sudoers: files sss > > > Thanks for your reply. sudo is now working as well, with this config $ cat /etc/pam.d/sudo #%PAM-1.0 *auth sufficient pam_sss.so* account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so If you still see issues , I would recommend turning debugging on for sssd, > sudo, looking through openldap logs for queries done by sssd. In addition, > the next link might also help. > > https://jhrozek.livejournal.com/2065.html > > I will bookmark this link. > Let us know how it goes. I assumed your openldap is loading the sudo > schema and you have configured at least one rule in openldap for sudo. In > my environment I modified the sudo password prompt ( see option passprompt) > , that way I can distinguish between a non-ldap sudo and sssd-enabled sudo > :) > > Yes I modified the passprompt too :-) > Let us know how it goes ... > > Appreciate your help! > > On 11/02/2017 03:13 PM, Asif Iqbal wrote: > > > > On Fri, Oct 27, 2017 at 10:53 AM, Mario Rossi <mro...@hostopia.com> wrote: > >> What OS are you using ? I am using Centos 6 with RSA ( fixed password + >> PIN ) + sssd/ldap auth , so yes, that does give you BOTH prompts, one for >> RSA and one for LDAP. If you need to ONLY use RSA w account lookup from >> sssd/ldap, then you have to comment out the auth line related to >> system-auth-ac in /etc/pam.d/sshd. You also have to be careful what umask >> are you using, make sure file perms is set to 0644 . Also if you run >> authconfig to manage /etc/pam.d, your files may be overwritten, so you may >> need to import custom setting into your deployment system i.e. >> puppet/ansible. >> >> Have you set *ChallengeResponseAuthentication* to yes in >> /etc/ssh/sshd_config ? >> >> Example of a system that uses RSA for sshd , so you get *only one* >> password prompt: >> >> $ cat /etc/pam.d/sshd >> #%PAM-1.0 >> auth required pam_securid.so reserve >> *#auth include system-auth-ac* >> account required pam_nologin.so >> account include system-auth-ac >> password include system-auth-ac >> session optional pam_keyinit.so force revoke >> session include system-auth-ac >> session required pam_loginuid.so >> >> $ cat */etc/pam.d/system-auth-ac * >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid >= 500 quiet >> auth sufficient pam_sss.so use_first_pass >> auth required pam_deny.so >> >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_sss.so >> account required pam_permit.so >> >> password requisite pam_cracklib.so try_first_pass retry=3 type= >> password sufficient pam_unix.so sha512 shadow nullok try_first_pass >> use_authtok >> password sufficient pam_sss.so use_authtok >> password required pam_deny.so >> >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_mkhomedir.so >> session [success=1 default=ignore] pam_succeed_if.so service in crond >> quiet use_uid >> session required pam_unix.so >> session optional pam_sss.so >> > > I got it working with your config. > > I can ssh with OTP and it does check my LDAP attributes as well. > > I have auth_provider = ldap now as well so I can sudo auth based on LDAP. > > Howerver sudo is failing and here is my pam.d/sudo looks like > > [root@localhost vagrant]# cat /etc/pam.d/sudo > #%PAM-1.0 > auth include system-auth-ac > account include system-auth-ac > password include system-auth-ac > session optional pam_keyinit.so revoke > session required pam_limits.so > > $ sudo -s > [sudo] password for iqbala: > sudo: account validation failure, is your account locked? > > It is not locked in LDAP and I checked. > > Any suggestion what is going wrong there? I am using your system-auth-ac > > > > > > > >> >> On 10/27/2017 10:27 AM, Asif Iqbal wrote: >> >> This setup also failed miserably where pam.d/sshd first two lines like >> below >> >> auth required pam_securid.so >> auth include system-auth-ac_new >> >> And using your pam.d/system-auth-ac_new >> >> So it does give you the right prompt 'Enter SMS Token:' when just put PIN >> at first login prompt. But after putting SMS token on the next prompt >> it goes back to Password: prompt again. Even worse is now it does not >> even work with giving both PIN and TokenCode at the first prompt either. >> >> Any other suggestion? Does anyone work with SSS and OTP at all? >> >> Seems like I should just not use sss since OTP is a *must* requirement. >> >> >> >> >> >> On Thu, Oct 26, 2017 at 8:54 PM, Mario Rossi <mro...@hostopia.com> wrote: >> >>> >>> My 2c, having two 'Password:' prompts ( RSA + sssd ) will confuse your >>> users, the easiest would be to configure sd_pam.conf to use a different >>> prompt for RSA. >>> >>> $ egrep ^AUTH /etc/sd_pam.conf >>> AUTH_CHALLENGE_USERNAME_STR=Enter USERNAME : >>> AUTH_CHALLENGE_RESERVE_REQUEST_STR=Please enter System Password for >>> root : >>> AUTH_CHALLENGE_PASSCODE_STR=Enter SecureKey : >>> AUTH_CHALLENGE_PASSWORD_STR=Enter your SecureKey : >>> >>> Now back to your question, I believe you need to define a new >>> system-auth file to be used, in my case >>> system-auth-ac_new with custom pam config. This is a working rsa + sssd >>> (openldap ) setup, I am not sure about proxy as I haven't used it before. >>> >>> >>> $ cat /etc/pam.d/sshd >>> #%PAM-1.0 >>> auth required pam_securid.so reserve >>> auth include system-auth-ac_new >>> account required pam_nologin.so >>> account include system-auth-ac_new >>> password include system-auth-ac_new >>> session optional pam_keyinit.so force revoke >>> session include system-auth-ac_new >>> session required pam_loginuid.so >>> >>> $ cat /etc/pam.d/system-auth-ac_new >>> #%PAM-1.0 >>> # This file is auto-generated. >>> # User changes will be destroyed the next time authconfig is run. >>> auth sufficient pam_sss.so >>> auth required pam_env.so >>> auth sufficient pam_unix.so nullok try_first_pass >>> auth requisite pam_succeed_if.so uid >= 500 quiet >>> auth required pam_deny.so >>> >>> account [default=bad success=ok user_unknown=ignore] pam_sss.so >>> #account required pam_access.so >>> account required pam_unix.so broken_shadow >>> account sufficient pam_localuser.so >>> account sufficient pam_succeed_if.so uid < 500 quiet >>> account required pam_permit.so >>> >>> password sufficient pam_sss.so use_authtok >>> password requisite pam_cracklib.so try_first_pass retry=3 type= >>> password sufficient pam_unix.so sha512 shadow nullok >>> try_first_pass use_authtok >>> password required pam_deny.so >>> >>> session optional pam_sss.so >>> session optional pam_keyinit.so revoke >>> session required pam_limits.so >>> session optional pam_mkhomedir.so >>> session [success=1 default=ignore] pam_succeed_if.so service in >>> crond quiet use_uid >>> session required pam_unix.so >>> >>> On 10/26/2017 07:34 PM, Asif Iqbal wrote: >>> >>> With pam_securid.so >>> >>> I can on /etc/pam.d/sshd >>> >>> auth sufficient pam_securid.so >>> >>> and at ssh login, I just put PIN at Password: prompt and then I get >>> Enter SMS Token: prompt and I can then put the >>> tokencode and I can ssh into the server fine. >>> >>> If I do the same with pam_sss.so it keeps asking for Password: and never >>> changes the prompt to Enter SMS Token: and ssh fails badly. >>> At this second Password: prompt I tried with just tokencode (at 18:45:34 >>> in log below) or PIN and tokencode (at 18:47:55). Neither let >>> me in and failed eventually. >>> >>> I think it is because pam_sss -> proxy -> securid -> pam_securd is >>> failing to handle PAM conversation? >>> >>> Is there a way to fix that to so pam_sss to behave the right way and let >>> authenticate in two steps with PIN and then TokenCode on next step? >>> >>> Also without this PAM conversation, when the PIN expires it will not let >>> you update it. With simple pam.d/sshd and auth sufficient pam_securid.so >>> that works very well as well. >>> >>> I have sssd.conf setup like this >>> auth_server = proxy >>> proxy_target_pam = securid >>> >>> And in pam.d/securid file >>> auth sufficient pam_securid.so >>> >>> Here are some log http://dpaste.com/2HD27XH.txt where >>> I tried with PIN at first Password: prompt and then TokenCode at >>> second Password: prompt at 18:45:34 and failed to login >>> And >>> I tried with PIN at first Password: prompt and then PIN and TokenCode >>> at second Password: prompt at 18:47:55 and failed to login >>> >>> I tried with SElinux off and on and same result >>> >>> If I put PIN and TokenCode at the first Password: prompt, login works >>> fine . I did not put any log for that here. >>> >>> Any suggestion how to fix pam_sss for OTP? >>> >>> Thanks! >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Asif Iqbal >>> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> >>> >>> >>> _______________________________________________ >>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >>> >>> >>> >> >> >> -- >> Asif Iqbal >> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> >> >> > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
