Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 5. Authentication and Interoperability

Support for central management of SSH keys

Previously, it was not possible to centrally manage host and user SSH public keys. Red Hat Enterprise Linux 6.3 includes SSH public key management for Identity Management servers as a Technology Preview. OpenSSH on Identity Management clients is automatically configured to use public keys which are stored on the Identity Management server. SSH host and user identities can now be managed centrally in Identity Management.

SELinux user mapping

Red Hat Enterprise Linux 6.3 introduces the ability to control the SELinux context of a user on a remote system. SELinux user map rules can be defined and, optionally, associated with HBAC rules. These maps define the context a user receives depending on the host they are logging into and the group membership. When a user logs into a remote host which is configured to use SSSD with the Identity Management backend, the user's SELinux context is automatically set according to mapping rules defined for that user. For more information, refer to http://freeipa.org/page/SELinux_user_mapping. This feature is considered a Technology Preview.

Multiple required methods of authentication for sshd

SSH can now be set up to require multiple ways of authentication (whereas previously SSH allowed multiple ways of authentication of which only one was required for a successful login); for example, logging in to an SSH-enabled machine requires both a passphrase and a public key to be entered. The RequiredAuthentications1 and RequiredAuthentications2 options can be configured in the /etc/ssh/sshd_config file to specify authentications that are required for a successful log in. For example: 

~]# echo "RequiredAuthentications2 publickey,password" >> /etc/ssh/sshd_config
For more information on the aforementioned /etc/ssh/sshd_config options, refer to the sshd_config man page.
SSSD support for automount map caching

In Red Hat Enterprise Linux 6.3, SSSD includes a new Technology Preview feature: support for caching automount maps. This feature provides several advantages to environments that operate with autofs:

  • Cached automount maps make it easy for a client machine to perform mount operations even when the LDAP server is unreachable, but the NFS server remains reachable.
  • When the autofs daemon is configured to look up automount maps via SSSD, only a single file has to be configured: /etc/sssd/sssd.conf. Previously, the /etc/sysconfig/autofs file had to be configured to fetch autofs data.
  • Caching the automount maps results in faster performance on the client and lower traffic on the LDAP server.
Change in SSSD debug_level behavior

SSSD has changed the behavior of the debug_level option in the /etc/sssd/sssd.conf file. Previously, it was possible to set the debug_level option in the [sssd] configuration section and the result would be that this became the default setting for other configuration sections, unless they explicitly overrode it.

Several changes to internal debug logging features necessitated that the debug_level option must always be specified independently in each section of the configuration file, instead of acquiring its default from the [sssd] section.
As a result, after updating to the latest version of SSSD, users may need to update their configurations in order to continue receiving debug logging at the same level. Users that configure SSSD on a per-machine basis can use a simple Python utility that updates their existing configuration in a compatible way. This can be accomplished by running the following command as root: 
~]# python /usr/lib/python2.6/site-packages/sssd_update_debug_levels.py
This utility makes the following changes to the configuration file: it checks to see if the debug_level option was specified in the [sssd] section. If so, it adds that same level value to each other section in the sssd.conf file for which debug_level is unspecified. If the debug_level option already exists explicitly in another section, it is left unchanged.
Users who rely on central configuration management tools need to make these same changes manually in the appropriate tool.
New ldap_chpass_update_last_change option

A new option, ldap_chpass_update_last_change, has been added to SSSD configuration. If this option is enabled, SSSD attempts to change the shadowLastChange LDAP attribute to the current time. Note that this is only related to a case when the LDAP password policy is used (usually taken care of by LDAP server), that is, the LDAP extended operation is used to change the password. Also note that the attribute has to be writable by the user who is changing the password.