[Freeipa-users] Valid documentation for sudo setup for version 4.0.3

Fri Oct 17 08:21:05 UTC 2014

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 at ipa-client~]$ groups
>vaclav.adamec admins
>
>[vaclav.adamec at 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 at test]
>(Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400):
>Returning info for user [vaclav.adamec at 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 at 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 at 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 <abokovoy at 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