[Freeipa-users] Sudo Commands and groups confusion

[Sina Owolabi]

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 at 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 . <yamakasi.014 at gmail.com> 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
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



-- 
best regards,

Sina Owolabi
+2348034022578
+2348176469061
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130612/9d3597b3/attachment.htm>