The sssd-ipa package can be installed with the following command:
$ sudo yum install sssd-ipa
sssd-ipa provides the IPA back end that the SSSD can utilize to fetch identity data from and authenticate against an IPA server.
The sssd package should be installed.
The sssd package can be installed with the following command:
$ sudo yum install sssd
The SSSD service should be enabled.
The sssd service can be enabled with the following command:
$ sudo systemctl enable sssd.service
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).
Ensuring that multifactor solutions certificates are checked via Online Certificate Status Protocol (OCSP) ensures the security of the system.
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
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.
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
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.
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 = TrueAdd 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_authAlso 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
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 must have acceptable trust anchor present.
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 to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the
ldap_tls_cacertoption in
/etc/sssd/sssd.confto point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacert /path/to/tls/ca.cert
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 to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the
ldap_tls_cacertdiroption in
/etc/sssd/sssd.confto point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacertdir /path/to/tls/cacert
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 to demand a valid certificate from the server to protect the integrity of LDAP remote access sessions by setting the
ldap_tls_reqcertoption in
/etc/sssd/sssd.confto demand.
Without a valid certificate presented to the LDAP client backend, the identity of a server can be forged compromising LDAP remote access sessions.
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
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.
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
If cached authentication information is out-of-date, the validity of the authentication information may be questionable.
SSSD should be configured to expire offline credentials after 1 day. Check if SSSD allows cached authentications with the following command:
$ sudo grep cache_credentials /etc/sssd/sssd.conf cache_credentials = trueIf "cache_credentials" is set to "false" or is missing no further checks are required.
[pam] offline_credentials_expiration = 1
If cached authentication information is out-of-date, the validity of the authentication information may be questionable.
SSSD processes should be configured to run as user sssd, not root.
To minimize privileges of SSSD processes, they are configured to run as non-root user.
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
If cached authentication information is out-of-date, the validity of the authentication information may be questionable.