One of the features of IPA is its facility to centrally manage sudoers rules. This rules can be based on user, group memberships etc. and be constrained to one or more servers.
One of the benefits you get is: You are able to define stricter sudoers rules without annoying the users. At the end your systems are more secure and more convenient for the users.
Unfortunately, sudoers via LDAP does not just work out of the box, some configuration on the clients needs to be done. Those can be equal on all hosts and distributed via configuration management such as puppet or RHN Satellite.
IPA has a user called “sudo”. We first need to set a password for it:
[root@ipa1 ~]# ldappasswd -x -S -W -h ipa1.example.com -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com New password: Re-enter new password: Enter LDAP Password: [root@ipa1 ~]#
We need to set this password later on as the bind password in the LDAP configuration.
Next we need to edit the /etc/nsswitch.conf file:
[root@ipaclient1 ~]# echo sudoers: files ldap >> /etc/nsswitch.conf
Lets configure the sudoers-ldap file
root@ipaclient1 ~]# cat << EOF > /etc/sudo-ldap.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com bindpw redhat ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes uri ldap://ipa1.example.com ldap://ipa2.example.com sudoers_base ou=SUDOers,dc=example,dc=com EOF root@ipaclient1 ~]#
The bindpw (in this example “redhat” is that one you previously set with ldappasswd, change it accordingly. The paramter “uri” should contain two IPA servers (as FQDN, no IP Address or shortname) for redundancy. The “binddn” and “sudoers_base” of course should match your environment.
Remember netgroups? Old school stuff from the time when NIS was used. I thought I’ll never get in touch with NIS anymore. Unfortunately sudo uses netgroups, so we need to set a proper NIS domainname.
cat << EOF >> /etc/rc.d/rc.local nisdomainname example.com EOF
The following files are needed to be configured on each host using IPA for sudoers rules:
Expect part two of this in the next few days.
Have fun 🙂
7 thoughts on “Centrally manage sudoers rules with IPA Part I – Preparation”
I am concerned about the platform and version of IPA you are using. The instructions that worked for me for FreeIPA 3.1.5-1 (http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) are different from the instructions for IPA <= 2.2. And the 3.1.5 manual in section 14.4 states that the instructions are for 2.2.
I’ve set up the stuff with RHEL 6.4, it is AFAIK based on FreeIPA 3.0. Maybe I should give a try on a Fedora based environment as well to have future RHEL version of IPA covered as well.
I am new to FreeIPA (I installed it for the first time about one week ago), but it seems to me that sudo rules work without touching rc.local (the file does not even exist on machines where sudo rules from FreeIPA work).
I probably should have a look to the upstream version of FreeIPA as well 😉 There are quite some new features. It is also supposed to be integrated with SSSD.
I found out, that it is necessary to use ndisdomainname if you want to use host groups in sudo rules (which you want). If you want to write sudo rules for specific hosts or all hosts, then you would not need it.
As I said, I am very new to this whole FreeIPA thing.
that’s what I had to do with RHEL5 and RHEL6 machines I maintain here. You can remove the “nisdomainname” entry on RHEL6 machines from /etc/rc.local and add “NISDOMAIN” to /etc/sysconfig/network.
This is also only required, if you assign sudo-rules to some host-groups. If you have rules which apply to every host, you can ommit the nisdomain* stuff.
I’m currently also investigating the SSSD integration into sudo, so that there is no constant connection needed to the LDAP server to have sudo rules valid.
The proper way to set the NIS domain name is adding “NISDOMAIN=example.com” to /etc/sysconfig/network.
The NISDOMAIN needs to be set if you’re using host groups in the sudo rules, as far as I can see it works fine without setting it unless you use host groups. (found that the other way round)