Este conteúdo não está disponível no idioma selecionado.
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.
- Make sure that the sssd-common package is installed.
~]$
rpm -q sssd-common - Open the
sssd.conffile.~]#
vim /etc/sssd/sssd.conf - Add the
sudoservice to the list of services that SSSD manages.[sssd] services = nss,pam,
sudo.... - 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 thesudoservice and supply the default configuration.[sudo]
- The
sudoinformation 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 alwaysldap. - 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.crtsudo_provider = ldap ldap_uri = ldap://ipa.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=comldap_sasl_mech = GSSAPIldap_sasl_authid = host/hostname.example.comldap_sasl_realm = EXAMPLE.COMkrb5_server = ipa.example.comNote
Thesudo_providertype for an Identity Management provider is stillldap. - Set the intervals to use to refresh the
sudorule 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 cachessudorules which apply to the local system. This can mean that thesudoHostvalue 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
sudorules.Schema elements are set in theldap_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.conffile. - Configure
sudoto look for rules configuration in SSSD by editing thensswitch.conffile and adding thessslocation:~]#
vim /etc/nsswitch.confsudoers: filessss - Restart SSSD.
~]#
service sssd restart
