<div dir="ltr"><div>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 :-) <br>
</div>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 :-)<br>
<div class="gmail_extra">What do you think?:<br><br>[oowolabi@waphost ~]$ sudo service httpd status<br>sudo: ldap_set_option: debug -> 0<br>sudo: ldap_set_option: tls_checkpeer -> 1<br>sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt<br>
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt<br>sudo: ldap_set_option: ldap_version -> 3<br>sudo: ldap_set_option: timelimit -> 15<br>sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)<br>sudo: ldap_start_tls_s() ok<br>
sudo: ldap_sasl_bind_s() ok<br>sudo: Looking for cn=defaults: cn=defaults<br>sudo: no default options found in ou=SUDOers,dc=qrios,dc=com<br>sudo: ldap search '(|(sudoUser=oowolabi)(sudoUser=%oowolabi)(sudoUser=%#721800009)(sudoUser=%admins)(sudoUser=%employees)(sudoUser=%qrios)(sudoUser=%#721800000)(sudoUser=%#721800006)(sudoUser=%#721800008)(sudoUser=ALL))'<br>
sudo: searching from base 'ou=SUDOers,dc=qrios,dc=com'<br>sudo: adding search result<br>sudo: result now has 0 entries<br>sudo: ldap search '(sudoUser=+*)'<br>sudo: searching from base 'ou=SUDOers,dc=qrios,dc=com'<br>
sudo: adding search result<br>sudo: result now has 0 entries<br>sudo: sorting remaining 0 entries<br>sudo: searching LDAP for sudoers entries<br>sudo: done with LDAP searches<br>sudo: user_matches=1<br>sudo: host_matches=0<br>
sudo: sudo_ldap_lookup(0)=0x40<br>[sudo] password for oowolabi: <br>oowolabi is not allowed to run sudo on waphost. This incident will be reported.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 12, 2013 at 8:48 AM, Matt . <span dir="ltr"><<a href="mailto:yamakasi.014@gmail.com" target="_blank">yamakasi.014@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>A lot of people seem to have problem with Sudo and FreeIPA.<br>
<br></div>How to enable sudo is described here:<br><br><a href="http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf" target="_blank">http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf</a><br>
<br></div>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.<br><br></div>The workaround for now seems to be adding the username to the local sudoers file and comment the following lines on the local client:<br>
<br><pre># 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
<br><br></pre><pre>This is not what we want with a centralized auth and policy system so I hope we can fix this bug soon.<br><br><br></pre><pre>Ideas are welcome!<br><br><br></pre><pre>Cheers,<br><br>Matt<br></pre><br></div>
<br>_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>best regards,<br><br>Sina Owolabi<br>
+2348034022578<br>+2348176469061
</div></div>