Discussion:
Sudo Commands and groups confusion
(too old to reply)
Sina Owolabi
2013-06-11 23:56:13 UTC
Permalink
Hi
Please help me understand what I am doing wrong:

Im using two RHEL6.4 ipa servers in a multi-master configuration
Instead of creating multiple sudocmdgroups and sudo rules, I tried to
subset what I could see in the /etc/sudoers files and have nested command
groups and rules, to be applied to certain users and hostgroups as needed.
I have a hostgroup called allservers, which applies to all servers.

The allservers hostgroup is a member of sudo rule admin-commands, which I
created for specific users to be able to run admin commands on all servers.
I have added as members, multiple sudogroups, each of which have a number
of commands inside of them. Despite this, I find that sudo does not allow
me to run any command as the users added to the admin-command rule. Please
help me see where my logic is broken, and what to do to fix. Thanks a lot
in advance.
My sudo-ldap.conf is correctly configured, and so is nsswitch.conf.

Output is below:

sudo service httpd status
[sudo] password for tuser:
tuser is not allowed to run sudo on waphost. This incident will be
reported.

ipa sudorule-find admin-commands
-------------------
1 Sudo Rule matched
-------------------
Rule name: admin-commands
Enabled: TRUE
Users: tuser
Host Groups: allservers
Sudo Allow Command Groups: locate, networking, rooting, services,
software, storage
Sudo Option: !authenticate
----------------------------
Number of entries returned 1
----------------------------
--
best regards,

Sina Owolabi
+2348034022578
+2348176469061
Steven Jones
2013-06-12 00:26:52 UTC
Permalink
Hi,

Sounds to complex, dont nest, KISS, Keep It Simple and Stupid.

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272

________________________________
From: freeipa-users-***@redhat.com [freeipa-users-***@redhat.com] on behalf of Sina Owolabi [***@gmail.com]
Sent: Wednesday, 12 June 2013 11:56 a.m.
To: freeipa-***@redhat.com
Subject: [Freeipa-users] Sudo Commands and groups confusion

Hi
Please help me understand what I am doing wrong:

Im using two RHEL6.4 ipa servers in a multi-master configuration
Instead of creating multiple sudocmdgroups and sudo rules, I tried to subset what I could see in the /etc/sudoers files and have nested command groups and rules, to be applied to certain users and hostgroups as needed.
I have a hostgroup called allservers, which applies to all servers.

The allservers hostgroup is a member of sudo rule admin-commands, which I created for specific users to be able to run admin commands on all servers. I have added as members, multiple sudogroups, each of which have a number of commands inside of them. Despite this, I find that sudo does not allow me to run any command as the users added to the admin-command rule. Please help me see where my logic is broken, and what to do to fix. Thanks a lot in advance.
My sudo-ldap.conf is correctly configured, and so is nsswitch.conf.

Output is below:

sudo service httpd status
[sudo] password for tuser:
tuser is not allowed to run sudo on waphost. This incident will be reported.

ipa sudorule-find admin-commands
-------------------
1 Sudo Rule matched
-------------------
Rule name: admin-commands
Enabled: TRUE
Users: tuser
Host Groups: allservers
Sudo Allow Command Groups: locate, networking, rooting, services, software, storage
Sudo Option: !authenticate
----------------------------
Number of entries returned 1
----------------------------



--
best regards,

Sina Owolabi
+2348034022578
+2348176469061
Rob Crittenden
2013-06-12 01:33:29 UTC
Permalink
Post by Sina Owolabi
Hi
Im using two RHEL6.4 ipa servers in a multi-master configuration
Instead of creating multiple sudocmdgroups and sudo rules, I tried to
subset what I could see in the /etc/sudoers files and have nested
command groups and rules, to be applied to certain users and hostgroups
as needed.
I have a hostgroup called allservers, which applies to all servers.
The allservers hostgroup is a member of sudo rule admin-commands, which
I created for specific users to be able to run admin commands on all
servers. I have added as members, multiple sudogroups, each of which
have a number of commands inside of them. Despite this, I find that sudo
does not allow me to run any command as the users added to the
admin-command rule. Please help me see where my logic is broken, and
what to do to fix. Thanks a lot in advance.
My sudo-ldap.conf is correctly configured, and so is nsswitch.conf.
sudo service httpd status
tuser is not allowed to run sudo on waphost. This incident will be
reported.
ipa sudorule-find admin-commands
-------------------
1 Sudo Rule matched
-------------------
Rule name: admin-commands
Enabled: TRUE
Users: tuser
Host Groups: allservers
Sudo Allow Command Groups: locate, networking, rooting, services,
software, storage
Sudo Option: !authenticate
----------------------------
Number of entries returned 1
----------------------------
Did you set your NIS domain name on the client machine? sudo uses
netgroups which needs the NIS domain. By default IPA creates a managed
netgroup for each hostgroup so one should be available with the right
information.

rob
Matt .
2013-06-12 07:48:54 UTC
Permalink
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
Sina Owolabi
2013-06-12 08:26:22 UTC
Permalink
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?:

[***@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.
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
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
# 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
https://www.redhat.com/mailman/listinfo/freeipa-users
--
best regards,

Sina Owolabi
+2348034022578
+2348176469061
Alexander Bokovoy
2013-06-12 09:10:31 UTC
Permalink
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?

If you are using SSSD's sudo integration against IPA server, then here
is what you need to get it working on Fedora 18/19 and RHEL 6.4:

1. install libsss_sudo package

2. Add/change following line to /etc/nsswitch.conf

sudoers: files sss

3. Make sure your /etc/sssd/sssd.conf looks like this example:
http://abbra.fedorapeople.org/.paste/sssd.conf.example

4. Restart sssd

These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.

Please note that
sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
Matt .
2013-06-12 09:22:35 UTC
Permalink
Hi,

The package as you described is installed, the configlines are set as you
show it.

This is what I see in auth.log, my sssd_sudo does not show a thing:

Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication failure;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ; TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su
Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No such
file or directory

I really cannot figure out what to check more.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
Jakub Hrozek
2013-06-12 12:37:22 UTC
Permalink
Post by Matt .
Hi,
The package as you described is installed, the configlines are set as you
show it.
Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication failure;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ; TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su
Pavel, I know you were debugging this problem on IRC, was there any
conclusion?
Post by Matt .
Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No such
file or directory
I really cannot figure out what to check more.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
Pavel Březina
2013-06-12 12:51:57 UTC
Permalink
Post by Jakub Hrozek
Post by Matt .
Hi,
The package as you described is installed, the configlines are set as you
show it.
Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication failure;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ; TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su
Pavel, I know you were debugging this problem on IRC, was there any
conclusion?
No. I'm waiting for our lab to come back online so I can try to
reproduce it.
Post by Jakub Hrozek
Post by Matt .
Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No such
file or directory
I really cannot figure out what to check more.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
Pavel Březina
2013-06-13 11:49:10 UTC
Permalink
Post by Pavel Březina
Post by Jakub Hrozek
Post by Matt .
Hi,
The package as you described is installed, the configlines are set as you
show it.
Jun 12 11:19:16 server sudo: pam_unix(sudo:auth): authentication failure;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): User info message: Your
password will expire in 89 day(s).
Jun 12 11:19:16 server sudo: pam_sss(sudo:auth): authentication success;
logname=USERNAME uid=866600006 euid=0 tty=/dev/pts/0 ruser=USERNAME rhost=
user=USERNAME
Jun 12 11:19:16 server sudo: USERNAME : user NOT in sudoers ; TTY=pts/0 ;
PWD=/ ; USER=root ; COMMAND=/bin/su
Pavel, I know you were debugging this problem on IRC, was there any
conclusion?
No. I'm waiting for our lab to come back online so I can try to
reproduce it.
I followed the deployment guide and everything works fine. If you still
have problem, please start over and follow:
[1] for sudo-ldap-ipa
[2] for sudo-sssd-ipa

Check list:
- NIS domain has to be set to IPA domain

- hostname must be set to fqdn

- sudo-ldap configuration file on RHEL systems is located at
# sudo -V | grep ldap.conf
ldap.conf path: /etc/sudo-ldap.conf

- nsswitch must contain sudoers: ldap or sudoers: sss
# cat /etc/nsswitch.conf | grep sudoers
sudoers: files ldap


[1]
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#example-configuring-sudo

[2] http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Post by Pavel Březina
Post by Jakub Hrozek
Post by Matt .
Jun 12 11:19:16 server sudo: unable to execute /usr/sbin/sendmail: No such
file or directory
I really cannot figure out what to check more.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
Sina Owolabi
2013-06-12 17:29:57 UTC
Permalink
Thank you for the reply Alex, though I'm a little confused that I am
answering the correct email.
I have taken a look at the example sssd.conf you advised, and I'm a little
curious if the configuration supports having multiple IPA servers? I have a
multi-master setup with two servers. I tried to add both servers to the
ldap uri and to the krb5 section byt the service refused to start.
Also I have to note that this not being able to sudo only seems to affect
physical servers, and not the virtual machines I have applied it against.
Also unfortunately, this didnt work either.. I guess I will try a reboot
first if I can.

sudo debug:

[***@waphost IPA-configs]# su - 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.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
______________________________**_________________
Freeipa-users mailing list
https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
--
best regards,

Sina Owolabi
+2348034022578
+2348176469061
Sina Owolabi
2013-06-12 18:21:30 UTC
Permalink
I rebooted one of the servers and it worked!
Thanks a lot
Post by Sina Owolabi
Thank you for the reply Alex, though I'm a little confused that I am
answering the correct email.
I have taken a look at the example sssd.conf you advised, and I'm a little
curious if the configuration supports having multiple IPA servers? I have a
multi-master setup with two servers. I tried to add both servers to the
ldap uri and to the krb5 section byt the service refused to start.
Also I have to note that this not being able to sudo only seems to affect
physical servers, and not the virtual machines I have applied it against.
Also unfortunately, this didnt work either.. I guess I will try a reboot
first if I can.
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
oowolabi is not allowed to run sudo on waphost. This incident will be
reported.
Post by Alexander Bokovoy
Post by Matt .
Hi,
A lot of people seem to have problem with Sudo and FreeIPA.
http://www.freeipa.org/images/**7/77/Freeipa30_SSSD_SUDO_**
Integration.pdf<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.
Not sure what exactly is your problem? Could you please rephrase and
show it with logs again?
If you are using SSSD's sudo integration against IPA server, then here
1. install libsss_sudo package
2. Add/change following line to /etc/nsswitch.conf
sudoers: files sss
http://abbra.fedorapeople.org/**.paste/sssd.conf.example<http://abbra.fedorapeople.org/.paste/sssd.conf.example>
4. Restart sssd
These are the only actions I needed to get sudo working for IPA users on
Fedora 19 and RHEL 6.4.
Please note that sudoers: files sss
gives you chance to have local users configured in local sudoers. If you
don't want them to be able to use sudo, just change the line in
/etc/nsswitch.conf to
sudoers: sss
--
/ Alexander Bokovoy
______________________________**_________________
Freeipa-users mailing list
https://www.redhat.com/**mailman/listinfo/freeipa-users<https://www.redhat.com/mailman/listinfo/freeipa-users>
--
best regards,
Sina Owolabi
+2348034022578
+2348176469061
--
best regards,

Sina Owolabi
+2348034022578
+2348176469061
Alexander Bokovoy
2013-06-12 22:26:54 UTC
Permalink
Post by Sina Owolabi
Thank you for the reply Alex, though I'm a little confused that I am
answering the correct email.
I have taken a look at the example sssd.conf you advised, and I'm a little
curious if the configuration supports having multiple IPA servers? I have a
multi-master setup with two servers. I tried to add both servers to the
ldap uri and to the krb5 section byt the service refused to start.
See man sssd-ldap(5). ldap_uri accepts comma-separated list of servers.
Same for krb5_server, see sssd-krb5(5).
--
/ Alexander Bokovoy
Jakub Hrozek
2013-06-13 08:31:47 UTC
Permalink
Post by Alexander Bokovoy
Post by Sina Owolabi
Thank you for the reply Alex, though I'm a little confused that I am
answering the correct email.
I have taken a look at the example sssd.conf you advised, and I'm a little
curious if the configuration supports having multiple IPA servers? I have a
multi-master setup with two servers. I tried to add both servers to the
ldap uri and to the krb5 section byt the service refused to start.
See man sssd-ldap(5). ldap_uri accepts comma-separated list of servers.
Same for krb5_server, see sssd-krb5(5).
Also if you're using service DNS records, you can either leave the URIs
blank and default to service resolution or explicitly use service
resolution along with a hardcoded name:

ldap_uri = _srv_, ldap://ldap.example.com

See the "service discovery" section in the man pages.
Notify Me
2013-06-13 12:22:55 UTC
Permalink
Thanks a lot. I followed Alex's advice and it's all good now.
Very much appreciated!
Post by Sina Owolabi
Post by Alexander Bokovoy
Post by Sina Owolabi
Thank you for the reply Alex, though I'm a little confused that I am
answering the correct email.
I have taken a look at the example sssd.conf you advised, and I'm a
little
Post by Alexander Bokovoy
Post by Sina Owolabi
curious if the configuration supports having multiple IPA servers? I
have a
Post by Alexander Bokovoy
Post by Sina Owolabi
multi-master setup with two servers. I tried to add both servers to the
ldap uri and to the krb5 section byt the service refused to start.
See man sssd-ldap(5). ldap_uri accepts comma-separated list of servers.
Same for krb5_server, see sssd-krb5(5).
Also if you're using service DNS records, you can either leave the URIs
blank and default to service resolution or explicitly use service
ldap_uri = _srv_, ldap://ldap.example.com
See the "service discovery" section in the man pages.
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
James Hogarth
2013-06-14 11:12:14 UTC
Permalink
Post by Jakub Hrozek
Also if you're using service DNS records, you can either leave the URIs
blank and default to service resolution or explicitly use service
ldap_uri = _srv_, ldap://ldap.example.com
Hi Jakub,

Thanks for this. I've been doing the ldap backed sudo for a while for my
systems and missed that sssd backed sudo arrived in EL6.4...

A quick bit of testing looks like the bare minimum that needs to be added
to sssd.conf is to the main section under [domain]:

sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI


with an [sudo] section and sudo added to the provided services of course...

This really cleans up something that was quite messy before and simplifies
a lot - thanks!

Time to go and convert all my systems over I think...

James
Jakub Hrozek
2013-06-14 11:24:30 UTC
Permalink
Post by James Hogarth
Post by Jakub Hrozek
Also if you're using service DNS records, you can either leave the URIs
blank and default to service resolution or explicitly use service
ldap_uri = _srv_, ldap://ldap.example.com
Hi Jakub,
Thanks for this. I've been doing the ldap backed sudo for a while for my
systems and missed that sssd backed sudo arrived in EL6.4...
A quick bit of testing looks like the bare minimum that needs to be added
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
with an [sudo] section and sudo added to the provided services of course...
This really cleans up something that was quite messy before and simplifies
a lot - thanks!
Time to go and convert all my systems over I think...
James
Hi James,

I believe that at one point we included a configuration very similar to
the snippet above in man sssd-sudo. It should be there in 6.4, not 100%
sure now.
James Hogarth
2013-06-14 11:38:53 UTC
Permalink
Post by Jakub Hrozek
I believe that at one point we included a configuration very similar to
the snippet above in man sssd-sudo. It should be there in 6.4, not 100%
sure now.
Just checked the man page and indeed that minimal snippet is there ...

I really need to spend more time going through new man pages etc at each
point release!

My quick testing has it working a treat though and it's a lot more
lightweight with the caching going on than it was before

I've just let a couple of my colleagues know who were struggling a bit with
the ldap-sudo and binding stuff ... this is just so much simpler.
Matt .
2013-06-14 11:56:07 UTC
Permalink
James,

Is this in RHEL based systems only ? On Ubuntu there seems to be still
issues.

A full printout of the config file(s) would be nice to see as most people
write other things down they have working, but the working ones don't write
their full config down.

Thanks.

Cheers,

Matt
Post by Jakub Hrozek
I believe that at one point we included a configuration very similar to
Post by Jakub Hrozek
the snippet above in man sssd-sudo. It should be there in 6.4, not 100%
sure now.
Just checked the man page and indeed that minimal snippet is there ...
I really need to spend more time going through new man pages etc at each
point release!
My quick testing has it working a treat though and it's a lot more
lightweight with the caching going on than it was before
I've just let a couple of my colleagues know who were struggling a bit
with the ldap-sudo and binding stuff ... this is just so much simpler.
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users
James Hogarth
2013-06-14 12:36:16 UTC
Permalink
Post by Matt .
Is this in RHEL based systems only ? On Ubuntu there seems to be still
issues.
A full printout of the config file(s) would be nice to see as most people
write other things down they have working, but the working ones don't write
their full config down.
All my systems are CentOS 6.4 so YMMV on Ubuntu - I've not tested any
packages for debian based systems...

The full (sanitized for domains) config:

[***@backup hogarthj]# cat /etc/sssd/sssd.conf
[domain/example.com]

cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = EXAMPLE.COM
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, ipa01.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI



[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2

domains = example.com
[nss]

[pam]

[sudo]

[autofs]

[ssh]

The only other edit on the system to make this work was adding this line to
/etc/nsswitch.conf:

sudoers: files sss


This system was successfully working with the ldap-sudo.conf method before
but of course that had no load balancing and no caching.
Jakub Hrozek
2013-06-14 12:46:39 UTC
Permalink
Post by James Hogarth
Post by Matt .
Is this in RHEL based systems only ? On Ubuntu there seems to be still
issues.
A full printout of the config file(s) would be nice to see as most people
write other things down they have working, but the working ones don't write
their full config down.
All my systems are CentOS 6.4 so YMMV on Ubuntu - I've not tested any
packages for debian based systems...
[snip]
Post by James Hogarth
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
btw in 1.10 we have amended the sudo IPA provider to include this
configuration as default, so you should no longer need to amend the
config file with 1.10

Natxo Asenjo
2013-06-12 14:19:52 UTC
Permalink
Post by Sina Owolabi
Hi
Im using two RHEL6.4 ipa servers in a multi-master configuration
Instead of creating multiple sudocmdgroups and sudo rules, I tried to subset
what I could see in the /etc/sudoers files and have nested command groups
and rules, to be applied to certain users and hostgroups as needed.
I have a hostgroup called allservers, which applies to all servers.
The allservers hostgroup is a member of sudo rule admin-commands, which I
created for specific users to be able to run admin commands on all servers.
I have added as members, multiple sudogroups, each of which have a number of
commands inside of them. Despite this, I find that sudo does not allow me to
run any command as the users added to the admin-command rule. Please help me
see where my logic is broken, and what to do to fix. Thanks a lot in
advance.
we have deployed sudo accross all our ipa nodes with cfengine. The
configuration you need is this:

/etc/sudo-ldap.conf (permissions 640)

TLS_CACERT /etc/ipa/ca.crt
TLS_REQCERT demand
SASL_MECH GSSAPI
BASE dc=domain,dc=tld
URI ldaps://kdc1.domain.tld ldaps://kdc2.domain.tld
ROOTUSE_SASL on
SUDOERS_BASE ou=sudoers,dc=,dc=domain,dc=tld
SUDOERS_DEBUG 0

if you need debugging, change SUDOERS_DEBUG to 1

in /etc/nsswitch.conf, you need to have this:

sudoers: files ldap

sudo needs a nisdomain defined, so in all the nodes you can edit the
/etc/sysconfig/network file and add something like this:

NISDOMAIN=domain.tld

after which a reboot is needed. When you log in the node, in the shell
you enter

$ nisdomainname

and you need to see your ipa domain name in there.

If you have a configuration management system modify these files for
you, do not forget to restore the selinux context in /etc if selinux is
enabled.

After that, create a sudo rule. This is our admins sudo rule:

$ ipa sudorule-show admins
Rule name: admins
Description: admins may run any command on anyhost
Enabled: TRUE
Host category: all
Command category: all
User Groups: admins
Sudo Option: !authenticate

It works. I have not yet created other sudo rules limited to a set of
hosts/commands, but it should be straight forward.
--
natxo
Continue reading on narkive:
Loading...