Rules Related To 'sssd'

Component overview

Relevant packages:

Relevant groups:

Changelog:

No changes recorded.

Relevant rules:

Rule details

Install sssd-ipa Package

package_sssd-ipa_installed

Description

The sssd-ipa package can be installed with the following command:

$ sudo dnf install sssd-ipa

Rationale

sssd-ipa provides the IPA back end that the SSSD can utilize to fetch identity data from and authenticate against an IPA server.

Install the SSSD Package

package_sssd_installed

Description

The sssd package should be installed. The sssd package can be installed with the following command:

$ sudo dnf install sssd

Rationale

Enable the SSSD Service

service_sssd_enabled

Description

The SSSD service should be enabled. The sssd service can be enabled with the following command:

$ sudo systemctl enable sssd.service

Rationale

Certificate status checking in SSSD

sssd_certificate_verification

Description

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards. Configuring certificate_verification to ocsp_dgst=$var_sssd_certificate_verification_digest_function ensures that certificates for multifactor solutions are checked via Online Certificate Status Protocol (OCSP).

Rationale

Ensuring that multifactor solutions certificates are checked via Online Certificate Status Protocol (OCSP) ensures the security of the system.

Enable Certmap in SSSD

sssd_enable_certmap

Description

SSSD should be configured to verify the certificate of the user or group. To set this up ensure that section like certmap/testing.test/rule_name is setup in /etc/sssd/sssd.conf. For example

[certmap/testing.test/rule_name]
matchrule =<SAN>.*EDIPI@mil
maprule = (userCertificate;binary={cert!bin})
domains = testing.test

Rationale

Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.

Configure PAM in SSSD Services

sssd_enable_pam_services

Description

SSSD should be configured to run SSSD pam services. To configure SSSD to known SSH hosts, add pam to services under the [sssd] section in /etc/sssd/sssd.conf. For example:

[sssd]
services = sudo, autofs, pam

Rationale

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Enable Smartcards in SSSD

sssd_enable_smartcards

Description

SSSD should be configured to authenticate access to the system using smart cards. To enable smart cards in SSSD, set pam_cert_auth to True under the [pam] section in /etc/sssd/sssd.conf. For example:

[pam]
pam_cert_auth = True
Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:
/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth
Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:
/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

Rationale

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multi-Factor Authentication (MFA) solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.

SSSD Has a Correct Trust Anchor

sssd_has_trust_anchor

Description

SSSD must have acceptable trust anchor present.

Rationale

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.

Configure SSSD LDAP Backend Client CA Certificate

sssd_ldap_configure_tls_ca

Description

Configure SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the

ldap_tls_cacert
option in
/etc/sssd/sssd.conf
to point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacert /path/to/tls/ca.cert

Rationale

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the key used to generate the hash.

Configure SSSD LDAP Backend Client CA Certificate Location

sssd_ldap_configure_tls_ca_dir

Description

Configure SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the

ldap_tls_cacertdir
option in
/etc/sssd/sssd.conf
to point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacertdir /path/to/tls/cacert

Rationale

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the key used to generate the hash.

Configure SSSD LDAP Backend Client to Demand a Valid Certificate from the Server

sssd_ldap_configure_tls_reqcert

Description

Configure SSSD to demand a valid certificate from the server to protect the integrity of LDAP remote access sessions by setting the

ldap_tls_reqcert
option in
/etc/sssd/sssd.conf
to demand.

Rationale

Without a valid certificate presented to the LDAP client backend, the identity of a server can be forged compromising LDAP remote access sessions.

Configure SSSD LDAP Backend to Use TLS For All Transactions

sssd_ldap_start_tls

Description

The LDAP client should be configured to implement TLS for the integrity of all remote LDAP authentication sessions. If the id_provider is set to ldap or ipa in /etc/sssd/sssd.conf or any of the /etc/sssd/sssd.conf.d configuration files, ldap_id_use_start_tls must be set to true.

To check if LDAP is configured to use TLS when id_provider is set to ldap or ipa, use the following command:

$ sudo grep -i ldap_id_use_start_tls /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf

Rationale

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. The ssl directive specifies whether to use TLS or not. If not specified it will default to no. It should be set to start_tls rather than doing LDAP over SSL.

Configure SSSD's Memory Cache to Expire

sssd_memcache_timeout

Description

SSSD's memory cache should be configured to set to expire records after $var_sssd_memcache_timeout seconds. To configure SSSD to expire memory cache, set memcache_timeout to $var_sssd_memcache_timeout under the [nss] section in /etc/sssd/sssd.conf. For example:

[nss]
memcache_timeout = $var_sssd_memcache_timeout

Rationale

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.

Configure SSSD to Expire Offline Credentials

sssd_offline_cred_expiration

Description

SSSD should be configured to expire offline credentials after 1 day. To configure SSSD to expire offline credentials, set offline_credentials_expiration to 1 under the [pam] section in /etc/sssd/sssd.conf. For example:

[pam]
offline_credentials_expiration = 1

Rationale

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.

Configure SSSD to run as user sssd

sssd_run_as_sssd_user

Description

SSSD processes should be configured to run as user sssd, not root.

Rationale

To minimize privileges of SSSD processes, they are configured to run as non-root user.

Configure SSSD to Expire SSH Known Hosts

sssd_ssh_known_hosts_timeout

Description

SSSD should be configured to expire keys from known SSH hosts after $var_sssd_ssh_known_hosts_timeout seconds. To configure SSSD to known SSH hosts, set ssh_known_hosts_timeout to $var_sssd_ssh_known_hosts_timeout under the [ssh] section in /etc/sssd/sssd.conf. For example:

[ssh]
ssh_known_hosts_timeout = $var_sssd_ssh_known_hosts_timeout

Rationale

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.