13.2.8. Configuring Services: sudo

About sudo, LDAP, and SSSD

sudo rules are defined in the sudoers file, which must be distributed separately to every machine to maintain consistency.
One way for administrators to manage that for large environments is to store the sudo configuration in a central LDAP directory, and just configure each local system to point to that LDAP directory. That means that updates only need to be made in a single location, and any new rules are automatically recognized by local systems.
For sudo-LDAP configuration, each sudo rule is stored as an LDAP entry, with each component of the sudo rule defined in an LDAP attribute.
The sudoers rule looks like this: 
Defaults    env_keep+=SSH_AUTH_SOCK
...
%wheel        ALL=(ALL)       ALL
The LDAP entry looks like this: 
# sudo defaults
dn: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOptions go here
sudoOption: env_keep+=SSH_AUTH_SOCK

# sudo rule
dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoUser: %wheel
sudoHost: ALL
sudoCommand: ALL

Note

SSSD only caches sudo rules which apply to the local system, depending on the value of the sudoHost attribute. This can mean that the sudoHost value is set to ALL, uses a regular expression that matches the host name, matches the systems netgroup, or matches the systems host name, fully qualified domain name, or IP address.
The sudo service can be configured to point to an LDAP server and to pull its rule configuration from those LDAP entries. Rather than pointing the sudo configuration to the LDAP directory, it can be configured to point to SSSD. SSSD, then, stores all of the information that sudo needs, and every time a user attempts a sudo-related operation, the latest sudo configuration can be pulled from the LDAP directory (through SSSD). SSSD, however, also caches all of the sudo riles, so that users can perform tasks, using that centralized LDAP configuration, even if the LDAP server goes offline.

Procedure 13.5. Configuring sudo with SSSD

All of the SSSD sudo configuration options are listed in the sssd-ldap(5) man page.
  1. Make sure that the sssd-common package is installed. 
    ~]$ rpm -q sssd-common
  2. Open the sssd.conf file. 
    ~]# vim /etc/sssd/sssd.conf
  3. Add the sudo service to the list of services that SSSD manages. 
    [sssd]
services = nss,pam,sudo
....
  4. Create a new [sudo] service configuration section. This section can be left blank; there is only one configurable option, for evaluating the sudo not before/after period.
    This section is required, however, for SSSD to recognize the sudo service and supply the default configuration. 
    [sudo]
  5. The sudo information is read from a configured LDAP domain in the SSSD configuration, so an LDAP domain must be available. For an LDAP provider, these parameters are required:
    • The directory type, sudo_provider; this is always ldap.
    • The search base, ldap_sudo_search_base.
    • The URI for the LDAP server, ldap_uri.
    For example: 
    [domain/LDAP]
id_provider = ldap

sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
    For an Identity Management (IdM or IPA) provider, there are additional parameters required to perform Kerberos authentication when connecting to the server. 
    [domain/IDM]
id_provider = ipa
ipa_domain = example.com
ipa_server = ipa.example.com
ldap_tls_cacert = /etc/ipa/ca.crt

sudo_provider = ldap
ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/hostname.example.com
ldap_sasl_realm = EXAMPLE.COM
krb5_server = ipa.example.com

    Note

    The sudo_provider type for an Identity Management provider is still ldap.
  6. Set the intervals to use to refresh the sudo rule cache.
    The cache for a specific system user is always checked and updated whenever that user performs a task. However, SSSD caches all rules which relate to the local system. That complete cache is updated in two ways:
    • Incrementally, meaning only changes to rules since the last full update (ldap_sudo_smart_refresh_interval, the time in seconds); the default is 15 minutes,
    • Fully, which dumps the entire caches and pulls in all of the current rules on the LDAP server(ldap_sudo_full_refresh_interval, the time in seconds); the default is six hours.
    These two refresh intervals are set separately. For example: 
    [domain/LDAP]
...
ldap_sudo_full_refresh_interval=86400
ldap_sudo_smart_refresh_interval=3600

    Note

    SSSD only caches sudo rules which apply to the local system. This can mean that the sudoHost value is set to ALL, uses a regular expression that matches the host name, matches the systems netgroup, or matches the systems host name, fully qualified domain name, or IP address.
  7. Optionally, set any values to change the schema used for sudo rules.
    Schema elements are set in the ldap_sudorule_* attributes. By default, all of the schema elements use the schema defined in sudoers.ldap; these defaults will be used in almost all deployments.
  8. Save and close the sssd.conf file.
  9. Configure sudo to look for rules configuration in SSSD by editing the nsswitch.conf file and adding the sss location: 
    ~]# vim /etc/nsswitch.conf

sudoers: files sss
  10. Restart SSSD. 
    ~]# service sssd restart