On Fri, 17 Oct 2014, Vaclav Adamec wrote:
Thanks for your time. Man pages were the first, but it's not working just
base on that. Find out that libsss_sudo is desperately needed and it's not
required by ipa-client rpm. So now I only need to check sudo policy in IPA,
as there is obviously some issue, but connection is working.
This was work in progress in RHEL6.x, we didn't setup sudo from
ipa-client-instal, we weren't forcing it rpm-wise. Now, with SSSD 1.10
and above SSSD packages libsss_sudo in the main SSSD package,
sssd-common, so there is no need to add more dependencies.
yum install ipa-client libsss_sudo
ipa-client-install ...
modify:
/etc/sssd/sssd.conf (ldap setup based on man)
/etc/nsswitch.conf (sss provider for sudoers based on man)
and result:
[vaclav.adamec@ipa-client~]$ groups
vaclav.adamec admins
[vaclav.adamec@ipa-client ~]$ sudo -l
vaclav.adamec is not allowed to run sudo on ipa-client. This incident will
be reported.
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [vaclav.adamec] from [<ALL>]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [vaclav.adamec@test]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [vaclav.adamec@test]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [vaclav.adamec] from [test]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*))(&(dataExpireTimestamp<=1413529436)))]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
to get sudo rules from cache
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=vaclav.adamec)(sudoUser=#1085800001)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*)))]
(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 1 rules for [vaclav.adamec@test]
but ldap search:
ldapsearch -x -h localhost -p 389 -b ou=sudoers,dc=test
# sudoers, test
dn: ou=sudoers,dc=test
objectClass: extensibleObject
ou: sudoers
# Admins_can_do_anything, sudoers, test <http://cz.avg.com>
dn: cn=Admins_can_run_whomai_as_root,ou=sudoers,dc=test
sudoUser: %admins
sudoHost: +all
objectClass: sudoRole
objectClass: top
sudoRunAsUser: root
sudoCommand: /usr/bin/whoami
cn: Admins_can_run_whomai_as_root
# search result
search: 2
result: 0 Success
Both the SSSD logs and your ldapsearch say that they found the rule.
However, you didn't show logs for applying the rule.
Sudo integration is a bit complex. Since sudo 1.8.8, there is a code in
sudo which implements sudoers support through SSSD and there is a code
in SSSD which complements the sudo's part by supplying actual data to
the sudo part. Sudo code dynamically loads SSSD module and actual
debugging info about parsing rules is available from the sudo.
To enable the debugging, make a /etc/sudo.conf file with a line:
Debug sudo /var/log/sudo_debug all@info
If you would run a sudo command that wouldn't match any of the rules,
you'd see following output in /var/log/sudo_debug:
Oct 17 11:16:36 sudo[3794] username=admin
Oct 17 11:16:36 sudo[3794] domainname=NULL
Oct 17 11:16:36 sudo[3794] Received 1 rule(s)
Oct 17 11:16:36 sudo[3794] netgroup c21.ipacloud.test has no leading '+'
Oct 17 11:16:36 sudo[3794] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH!
Oct 17 11:16:36 sudo[3794] netgroup admins has no leading '+'
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=6
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1
Oct 17 11:16:36 sudo[3794] searching SSSD/LDAP for sudoers entries
Oct 17 11:16:36 sudo[3794] sssd/ldap sudoRunAsUser 'root' ... MATCH!
Oct 17 11:16:36 sudo[3794] sssd/ldap sudoCommand '/usr/bin/whoami' ... not
Oct 17 11:16:36 sudo[3794] Done with LDAP searches
The last 'not' is an indicator the command is refused thanks to the
rule.
For correct match you'd get something like this:
Oct 17 11:19:36 sudo[3835] username=admin
Oct 17 11:19:36 sudo[3835] domainname=NULL
Oct 17 11:19:36 sudo[3835] Received 1 rule(s)
Oct 17 11:19:36 sudo[3835] netgroup c21.ipacloud.test has no leading '+'
Oct 17 11:19:36 sudo[3835] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH!
Oct 17 11:19:36 sudo[3835] netgroup admins has no leading '+'
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=6
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1
Oct 17 11:19:36 sudo[3835] searching SSSD/LDAP for sudoers entries
Oct 17 11:19:36 sudo[3835] sssd/ldap sudoRunAsUser 'root' ... MATCH!
Oct 17 11:19:36 sudo[3835] sssd/ldap sudoCommand '/usr/bin/whoami' ... MATCH!
Oct 17 11:19:36 sudo[3835] Command allowed
Oct 17 11:19:36 sudo[3835] No result.
Oct 17 11:19:36 sudo[3835] Done with LDAP searches
# ipa sudorule-show admins_can_run_as_root
Rule name: admins_can_run_as_root
Description: Admins can run as root
Enabled: TRUE
User Groups: admins
Hosts: cc21.ipacloud.test
Sudo Allow Commands: /usr/bin/whoami
RunAs External User: root
# su - admin
$ sudo whoami
root
$ sudo -l
[sudo] password for admin:
Matching Defaults entries for admin on cc21:
!visiblepw,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User admin may run the following commands on cc21:
(root) /usr/bin/whoami
$ logout
On Fri, Oct 17, 2014 at 8:39 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:
On Fri, 17 Oct 2014, Vaclav Adamec wrote:
Mixture of bot method is result of testing, just registration via
ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not
setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6,
but
right now:
Installing 4.x (client or server) is not supported on CentOS 6.x. You
can use whatever IPA version is available there (3.0).It will not
automatically configure sudo for you, there you have to follow what
sssd-sudo(5) tells you to do.
My primary point was that we have this documentation available on every
machine where SSSD is in use, no need to search over internet.
P.S. Please reply to the list, not personally.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
