Thank you so very much for the replies. What I did actually worked, but not on two of the servers I was testing with. (adding command groups to a sudorule). It worked so well that I did it twice again :-) What I'm curious about is the two servers that still ask for sudo password. One of them brings out long output when I try (debug is set to 1). Unfortunately they are business critical and can't be rebooted if I want to live to see tomorrow :-) What do you think?:
[oowolabi@waphost ~]$ sudo service httpd status sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: Looking for cn=defaults: cn=defaults sudo: no default options found in ou=SUDOers,dc=qrios,dc=com sudo: ldap search '(|(sudoUser=oowolabi)(sudoUser=%oowolabi)(sudoUser=%#721800009)(sudoUser=%admins)(sudoUser=%employees)(sudoUser=%qrios)(sudoUser=%#721800000)(sudoUser=%#721800006)(sudoUser=%#721800008)(sudoUser=ALL))' sudo: searching from base 'ou=SUDOers,dc=qrios,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: ldap search '(sudoUser=+*)' sudo: searching from base 'ou=SUDOers,dc=qrios,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: sorting remaining 0 entries sudo: searching LDAP for sudoers entries sudo: done with LDAP searches sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(0)=0x40 [sudo] password for oowolabi: oowolabi is not allowed to run sudo on waphost. This incident will be reported. On Wed, Jun 12, 2013 at 8:48 AM, Matt . <[email protected]> wrote: > Hi, > > A lot of people seem to have problem with Sudo and FreeIPA. > > How to enable sudo is described here: > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > The problem we are facing, also discussed on IRC is that there is looked > in the local sudoers file of the client if the loggedin user may sudo. Of > course the username is not known there. > > The workaround for now seems to be adding the username to the local > sudoers file and comment the following lines on the local client: > > # cat /etc/pam.d/password-auth > #%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 [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > > # cat /etc/pam.d/system-auth > #%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 [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > This is not what we want with a centralized auth and policy system so I hope > we can fix this bug soon. > > > Ideas are welcome! > > > Cheers, > > Matt > > > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users > -- best regards, Sina Owolabi +2348034022578 +2348176469061
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
