FreeIPA 3.3.5 and sudo

The last time I had any real reason to play with sudo and IPA was before sssd got sudo support. I found the previous sudo-ldap debugging quite good, even if sudo itself was rather slow due to lack of caching.

A lot of users seem to have problems getting it setup since older IPA clients will not do this automatically so I thought I’d give it a go. I’m doing this on an up-to-date Fedora 20 system using the following IPA and SSSD:

freeipa-client-3.3.5-1.fc20.x86_64
sssd-1.11.7-4.fc20.x86_64

I started with the sssd-sudo(8) man page which laid out quite clearly the changes I needed to make to /etc/nsswitch.conf and sssd.conf. I restarted sssd and found my user couldn’t sudo at all, which makes sense since I hadn’t added any rules yet.

Ok, so I add a single rule to run any command on any host for a new group I added, sudoers of which my test user is a member. Oh, and be sure that the user is a member of the group before logging in so the groups evaluate properly.

I created the group and sudo rule with:

[admin@ipaserver]$ ipa group-add sudoers
[admin@ipaserver]$ ipa group-add-member sudoers --users=tuser1
[admin@ipaserver]$ ipa sudorule-add --hostcat=all --cmdcat=all sudoers
[admin@ipaserver]$ ipa sudorule-add-user --group=sudoers sudoers

I should also note I still have the HBAC allow_all rule enabled. If you’ve disabled this then you’ll need to grant sudo rights to the users you want to be able to execute it.

Before starting real testing, I created /etc/sudo.conf with these contents:

Debug sudo /var/log/sudo.log all@debug

This gives me a quite verbose log of what is going on. It probably makes more sense to a sudo developer but I can more or less follow along with the number of rules being evaluated, etc.

To double-check that the rule exists we can look in it in LDAP as the IPA admin user:

[admin@ipaserver]$ kinit admin
[admin@ipaserver]$ ldapsearch -LLL -Y GSSAPI -b ou=SUDOers,dc=example,dc=com
SASL/GSSAPI authentication started
SASL username: admin@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn: ou=sudoers,dc=example,dc=com
objectClass: extensibleObject
ou: sudoers

dn: cn=sudoers,ou=sudoers,dc=example,dc=com
objectClass: sudoRole
objectClass: top
sudoUser: %sudoers
sudoHost: ALL
sudoCommand: ALL
cn: sudoers

Ok, so now I just need to ssh into this box and try sudo -l

[admin@ipaserver]$ ssh tuser1@ipaserver
[tuser1@ipaserver]$ sudo -l
[sudo] password for tuser1: 
User tuser1 may run the following commands on ipaserver:
    (root) ALL

I also want to avoid authentication so I can update the rule to not require it:

[admin@ipaserver]$ ipa sudorule-add-option sudoers --sudooption='!authenticate'

Remember that the rules are cached so changes may not be available immediately, but it worked for me:

[tuser1@ipaserver]$ sudo -l
User tuser1 may run the following commands on ipaserver:
    (root) ALL

A somewhat old, but good, document to read is http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. In particular it has good information how the caching works.

Leave a Reply