Chapter 5. Authentication and Interoperability
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.
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.
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/etc/ssh/sshd_config options, refer to the sshd_config man page.
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
autofsdaemon 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/autofsfile 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.
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.
debug_level option must always be specified independently in each section of the configuration file, instead of acquiring its default from the [sssd] section.
~]# python /usr/lib/python2.6/site-packages/sssd_update_debug_levels.pydebug_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.
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.
