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:
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.