Chapter 3. Authentication and Interoperability

SSSD smart card support

SSSD now supports smart cards for local authentication. With this feature, the user can use a smart card to log on to the system using a text-based or graphical console, as well as local services such as the sudo service. The user places the smart card into the reader and provides the user name and the smart card PIN at the login prompt. If the certificate on the smart card is verified, the user is successfully authenticated.
Note that SSSD currently does not enable the user to acquire a Kerberos ticket using a smart card. To obtain a Kerberos ticket, the user is still required to authenticate using the kinit utility.
To enable smart card support in Red Hat Enterprise Linux 6, you must allow SSSD to prompt for password, one-time password (OTP), or the smart card PIN by modifying the auth lines of the /etc/pam.d/password-auth and /etc/pam.d/system-auth PAM configuration files. For detailed information, see the Identity Management Guide: http://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#idm-smart-cards (BZ#1270027)

Cache authentication in SSSD

Authentication against cache without a reconnection attempt is now available in SSSD even in online mode. Authenticating directly against the network server repeatedly can cause excessive application latency, which can make the login process overly time-consuming. (BZ#1237142)

The ou=sudoers,$DC part of the IdM server compatibility plug-in tree can now be disabled for better performance

The Identity Management (IdM) client is now able to look up sudo rules in the cn=sudorules,cn=sudo,$DC part of the IdM server's LDAP tree instead of the ou=sudoers,$DC compatibility tree generated by the slapi-nis Directory Server plug-in.
In environments where the compatibility tree is not required for other operations, such as for legacy client support, users can now disable the ou=sudoers,$DC part of the tree. This allows better performance because generating the compatibility tree using slapi-nis is resource-intensive, especially in environments with a large number of authentication operations. (BZ#1244957)

SSSD enables UID and GID mapping on individual clients

It is now possible to map users to a different UID and GID on specific Red Hat Enterprise Linux clients through client-side configuration by using SSSD provided by the sss_override utility. This client-side override possibility can resolve problems caused by UID and GID duplication or ease transition from a legacy system that previously used different ID mapping.
Note that the overrides are stored in the SSSD cache; removing the cache therefore also removes the overrides. See the sss_override(8) man page for more details about this feature. (BZ#1269422)

Caching for initgroups operations

The SSSD fast memory cache now supports the initgroups operations, which enhances the speed of initgroups processing and improves the performance of some applications, such as GlusterFS and slapi-nis. (BZ#1269421)

New packages: adcli

This update adds the adcli packages to Red Hat Enterprise Linux 6. The adcli utility allows users to manage host, user, and group objects in Active Directory (AD) from a Red Hat Enterprise Linux 6 client. The main use of the utility is joining a host to an AD domain and to renew the credentials of the host.
The adcli utility is site-aware and does not require additional configuration to join an AD domain. On clients that run the SSSD service, adcli can renew the host credentials on a regular basis. (BZ#1279725)

SSSD is now able to automatically renew the host credentials of Linux clients joined to AD

Certain Windows utilities can remove hosts from Active Directory (AD) after their password has not been updated for a long time. This is because these utilities consider such clients inactive.
With this feature, the host password of Linux clients joined to AD is regularly updated, which indicates the client is still actively used. As a result, Red Hat Enterprise Linux clients joined to AD are not removed in the described situation. (BZ#1290761)

SSSD can now automatically adjust ID ranges for AD clients in environments with large RIDs

The automatic ID mapping mechanism included in the SSSD service is now able to merge ID range domains. Previously, if the relative ID (RID) of the Active Directory (AD) domain was larger than 200,000, which is the default size of the ID range assigned by SSSD, the administrator was required to manually adjust the ID range assigned by SSSD to correspond with the RID.
With this enhancement, for AD clients with ID mapping enabled, SSSD automatically adjusts the ID ranges in the described situation. As a result, the administrator is no longer required to adjust the ID range manually, and the default SSSD ID mapping mechanism works even in large AD environments. (BZ#1268902)

SSSD now supports GPOs from different domain controllers

The System Security Services Daemon (SSSD) service has been updated to support group policy objects (GPOs) from different domain controllers. (BZ#1221365)

Support for SSLv2 has been disabled

SSLv2 is insecure and should not be used in current deployments, and thus has been disabled without a way to override. All modern browsers and frameworks cannot negotiate SSLv2 connections in default configuration and many cannot be configured to perform SSLv2 negotiation. A recent OpenSSL vulnerability (CVE-2015-3197) shows that keeping this code is a liability. In addition, upstream has already removed support for SSLv2 (MZBZ#1228555). (BZ#1304812)

OpenLDAP now supports TLSv1.2

The TLS layer of OpenLDAP has been enhanced to support the cipher string value TLSv1.2 along with new ciphers from the TLSv1.2 suite. Additionally, the new cipher strings AESGCM, SHA256, and SHA384 have been added. With this update, the cipher string DEFAULT selects a subset of the Network Security Services (NSS) defaults in order to be up to date with current security development. Note that the cipher string DEFAULT currently excludes AESGCM ciphers, in order not to break the Security Strength Factor (SSF) functionality. (BZ#1300701)

nss now supports ECDSA certificates

By default, the NSS library did not enable TLS cipher suites that use Elliptic Curve Cryptography (ECC). Applications that did not change the NSS default configuration were unable to connect to servers that mandated support for ECC key exchange, such as ECDHE. In particular, connecting to servers that use certificates with ECDSA keys failed.
This update changes the default configuration to enable TLS cipher suites that allow using ECC by default. As a result, applications using NSS defaults for communication over TLS can now connect to servers that use certificates with ECDSA keys. (BZ#1059682)

New SSSD default values for group names

The System Security Services Daemon (SSSD) now uses new default group names that are compatible with Windows and third-party solutions. This affects installations that have the id_provider configuration option set to ad in the /etc/sssd/sssd.conf file.
If the environment requires a different value for the group name attribute than the new default value of sAMAccountName, a manual configuration change is required. For example, this might be required in situations when providing groups with the same name as users. To revert to the old behaviour, set cn as the attribute value:
1. Set ldap_group_name = cn in the /etc/sssd/sssd.conf file.
2. Run the following commands to clear the SSSD cache:
# service sssd stop
# find /var/lib/sss/ ! -type d | xargs rm -f
# service sssd start
(BZ#1342458)