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: The LDAP entry looks like this: 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. Make sure that the sssd-common package is installed. Open the sssd.conf file. Add the sudo service to the list of services that SSSD manages. 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. 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: For an Identity Management (IdM or IPA) provider, there are additional parameters required to perform Kerberos authentication when connecting to the server. Note The sudo_provider type for an Identity Management provider is still ldap . 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: 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. 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. Save and close the sssd.conf file. Configure sudo to look for rules configuration in SSSD by editing the nsswitch.conf file and adding the sss location: Restart SSSD.

Commands:
Defaults env_keep+=SSH_AUTH_SOCK %wheel ALL=(ALL) ALL
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
~]USD rpm -q sssd-common
~]# vim /etc/sssd/sssd.conf
[sssd] services = nss,pam, sudo .
[sudo]
[domain/LDAP] id_provider = ldap sudo_provider = ldap ldap_uri = ldap://example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
[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
[domain/LDAP] ldap_sudo_full_refresh_interval=86400 ldap_sudo_smart_refresh_interval=3600
~]# vim /etc/nsswitch.conf sudoers: files sss
~]# service sssd restart