Part II. Identity and Authentication Stores
Chapter 3. Using and Caching Credentials with SSSD
3.2. SSSD and Syst em Services
3.2.3. Configuring Services: aut ofs
3.2 .3.1 . Abo ut Aut o m o unt , LDAP, and SSSD
Automount maps are commonly flat files, which define a relationship between a map, a mount directory, and a fileserver. (Automount is described in the Storage Administration Guide.)
For example, let's say that there is a fileserver called nfs. exampl e. co m which hosts the directory pub, and automount is configured to mount directories in the /shares/ directory. So, the mount location is /shares/pub. All of the mounts are listed in the auto . master file, which identifies the different mount directories and the files which configure them. The auto . shares file then identifies each file server and mount directory which goes into the /shares/ directory. The relationships could be viewed like this:
Every mount point, then, is defined in two different files (at a minimum): the auto . master and auto .whatever file, and those files have to be available to each local automount process.
One way for administrators to manage that for large environments is to store the automount
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 maps are automatically recognized by local systems.
For automount-LDAP configuration, the automount files are stored as LDAP entries, which are then translated into the requisite automount files. Each element is then translated into an LDAP attribute.
The LDAP entries look like this:
# container entry
dn: cn=automount,dc=example,dc=com objectClass: nsContainer
objectClass: top
The schema elements, then, match up to the structure like this (with the RFC 2307 schema):
auto . master mount point name attribute: automountKey filename attribute:
automountMapName
auto fs uses those schema elements to derive the automount configuration. The
/etc/sysco nfi g /auto fs file identifies the LDAP server, directory location, and schema elements used for automount entities:
Rather than pointing the automount configuration to the LDAP directory, it can be configured to point to SSSD. SSSD, then, stores all of the information that automount needs, and as a user attempts to mount a directory, that information is cached into SSSD. This offers several advantages for
configuration — such as failover, service discovery, and timeouts — as well as performance improvements by reducing the number of connections to the LDAP server. Most important, using SSSD allows all mount information to be cached, so that clients can still successfully mount directories even if the LDAP server goes offline.
3.2 .3.2 . Co nfiguring aut o fs Se rvice s in SSSD
1. Make sure that the auto fs package is installed.2. Open the sssd . co nf file.
[root@ server ~]# vim /etc/sssd/sssd.conf
3. Add the auto fs service to the list of services that SSSD manages.
[sssd]
services = nss,pam,auto fs ....
4. Create a new [auto fs] service configuration section. This section can be left blank; there is only one configurable option, for timeouts for negative cache hits.
This section is required, however, for SSSD to recognize the auto fs service and supply the default configuration.
[autofs]
5. The automount information is read from a configured LDAP domain in the SSSD
configuration, so an LDAP domain must be available. If no additional settings are made, then the configuration defaults to the RFC 2307 schema and the LDAP search base
(l d ap_search_base) for the automount information. This can be customized:
The directory type, auto fs_pro vi d er; this defaults to the i d _pro vi d er value; a value of none explicitly disables autofs for the domain.
The search base, l d ap_auto fs_search_base.
The object class to use to recognize map entries, l d ap_auto fs_map_o bject_cl ass
The attribute to use to recognize map names, l d ap_auto fs_map_name The object class to use to recognize mount point entries,
l d ap_auto fs_entry_o bject_cl ass
The attribute to use to recognize mount point names, l d ap_auto fs_entry_key The attribute to use for additional configuration information for the mount point, l d ap_auto fs_entry_val ue
7. Configure auto fs to look for the automount map information in SSSD by editing the nsswi tch. co nf file and changing the location from l d ap to sss:
[root@ server ~]# vim /etc/nsswitch.conf automount: files sss
8. Restart SSSD.
[root@ server ~]# systemctl restart sssd.service
3.2.4 . Configuring Services: sudo
3.2 .4 .1 . Abo ut sudo , LDAP, and SSSD
sud o rules are defined in the sud o ers 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 sud o 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 sud o-LDAP configuration, each sud o rule is stored as an LDAP entry, with each component of the sud o rule defined in an LDAP attribute.
The sud o ers rule looks like this:
Defaults env_keep+=SSH_AUTH_SOCK ...
%wheel ALL=(ALL) ALL
The LDAP entry looks like this:
SSSD only caches sud o 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 hostname, matches the systems netgroup, or matches the systems hostname, fully-qualified domain name, or IP address.
The sud o service can be configured to point to an LDAP server and to pull its rule configuration from those LDAP entries. Rather than pointing the sud o configuration to the LDAP directory, it can be configured to point to SSSD. SSSD, then, stores all of the information that sud o needs, and every time a user attempts a sud o-related operation, the latest sud o configuration can be pulled from the LDAP directory (through SSSD). SSSD, however, also caches all of the sud o riles, so that users can perform tasks, using that centralized LDAP configuration, even if the LDAP server goes offline.
3.2 .4 .2 . Co nfiguring sudo wit h SSSD
All of the SSSD sud o configuration options are listed in the sssd -l d ap(5) man page.
To configure the sud o service:
1. Open the sssd . co nf file.
[root@ server ~]# vim /etc/sssd/sssd.conf
2. Add the sud o service to the list of services that SSSD manages.
[sssd]
services = nss,pam,sud o ....
3. Create a new [sud o ] 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 sud o service and supply the default configuration.
[sudo]
4. The sud o 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, sud o _pro vi d er; this is always l d ap. The search base, l d ap_sud o _search_base.
The URI for the LDAP server, l d ap_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
Setting IdM as the ID provider automatically enables the sudo provider, so it is not necessary to specify sud o _pro vi d er = i pa in the configuration file.
[domain/IDM]
id_provider = ipa
ipa_domain = example.com ipa_server = ipa.example.com
5. Set the intervals to use to refresh the sud o 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
(l d ap_sud o _smart_refresh_i nterval, 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(l d ap_sud o _ful l _refresh_i nterval, 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 sud o 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 hostname, matches the systems netgroup, or matches the systems hostname, fully-qualified domain name, or IP address.
6. Optionally, set any values to change the schema used for sud o rules.
Schema elements are set in the l d ap_sud o rul e_* attributes. By default, all of the schema elements use the schema defined in sudoers.ldap; these defaults will be used in almost all deployments.
7. Save and close the sssd . co nf file.
8. Configure sud o to look for rules configuration in SSSD by editing the nsswi tch. co nf file and adding the sss location:
[root@ server ~]# vim /etc/nsswitch.conf sudoers: files sss
9. Restart SSSD.
[root@ server ~]# systemctl restart sssd.service