Chapter 3. Authentication and Interoperability


Identity Management sets up a one-way trust by default

The ipa trust-add command now configures a one-way trust by default. One-way trusts enable users and groups in Active Directory (AD) to access resources in Identity Management (IdM) but not the other way around. Previously, the default trust configured by running ipa trust-add was a two-way trust.
IdM still allows the administrator to set up a two-way trust by adding the --two-way=true option to ipa trust-add.

openldap rebase to version 2.4.40

The openldap packages have been upgraded to upstream version 2.4.40, which provides a number of bug fixes and one enhancement over the previous version. Notably, the ORDERING matching rules have been added to the ppolicy attribute type descriptions. Among the fixed bugs are: The server no longer terminates unexpectedly when processing SRV records, and missing objectClass information has been added, which enables the user to modify the front-end configuration by standard means.

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 could cause excessive application latency, which could make the login process overly time-consuming.

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. 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.

SSSD can now deny SSH access to locked accounts

Previously, when SSSD used OpenLDAP as its authentication database, users could authenticate into the system successfully with an SSH key even after the user account was locked. The ldap_access_order parameter now accepts the ppolicy value, which can deny SSH access to the user in the described situation. For more information about using ppolicy, see the ldap_access_order description in the sssd-ldap(5) manual page.

The sudo utility now capable of verifying command checksum

The configuration of the sudo utility can now store the checksum of a command or script that is being permitted. When the command or script is run again, the checksum is compared to the stored checksum to verify that nothing has changed. If the command or binary is modified, the sudo utility refuses to run the command or logs a warning. This functionality makes it possible to correctly devolve responsibility and problem-solving activities if an incident occurs.

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 does not currently 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.

Support for multiple certificate profiles and user certificates

Identity Management now supports multiple profiles for issuing server and other certificates instead of only supporting a single server certificate profile. The profiles are stored in the Directory Server and shared between IdM replicas.
In addition, the administrator can now issue certificates to individual users. Previously, it was only possible to issue certificates to hosts and services.

Password Vault

A new feature to allow secure central storage of private user information, such as passwords and keys has been added to Identity Management. Password Vault is built on top of the Public Key Infrastructure (PKI) Key Recovery Authority (KRA) subsystem.

Kerberos HTTPS proxy in Identity Management

A Key Distribution Center (KDC) proxy function, interoperable with the Microsoft Kerberos KDC Proxy Protocol (MS-KKDCP) implementation, is now available in Identity Management and allows clients to access the KDC and kpasswd services by using HTTPS. System administrators can now expose the proxy at their network edge by a simple HTTPS reverse proxy without the need to set up and manage a dedicated application.

Background refresh of cached entries

SSSD now allows cached entries to be updated out-of-band in the background. Prior to this update, when the validity of cached entries expired, SSSD fetched them from the remote server and stored them in the database anew, which could be time consuming. With this update, entries are returned instantly because the back end keeps them updated at all times. Note that this causes a higher load on the server because SSSD downloads the entries periodically instead of only upon request.

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, for example GlusterFS and slapi-nis.

Negotiate authentication streamlined with mod_auth_gssapi

Identity Management now uses the mod_auth_gssapi module, which uses GSSAPI calls instead of direct Kerberos calls used by the previously used mod_auth_kerb module.

User life-cycle management capabilities

The user life-cycle management gives the administrator a greater degree of control over activating and deactivating user accounts. The administrator can now provision new user accounts by adding them to a stage area without fully activating them, activate inactive user accounts to make them fully operational, or deactivate user accounts without completely deleting them from the database.
User life-cycle management capabilities bring significant benefits to large IdM deployments. Note that users can be added to the stage area also directly from a standard LDAP client, using direct LDAP operations. Previously, IdM only supported managing users using IdM command-line tools or the IdM web UI.

SCEP support in certmonger

The certmonger service has been updated to support the Simple Certificate Enrollment Protocol (SCEP). It is now possible to issue a new certificate and renew or replace existing certificates over SCEP.

Apache modules for IdM now fully supported

The following Apache modules for Identity Management (IdM), added as Technology Preview in Red Hat Enterprise Linux 7.1, are now fully supported: mod_authnz_pam, mod_lookup_identity, and mod_intercept_form_submit. The Apache modules can be used by external applications to achieve tighter interaction with IdM beyond simple authentication.

NSS raises minimum accepted key strength values

The Network Security Services (NSS) library in Red Hat Enterprise Linux 7.2 no longer accepts Diffie-Hellman (DH) key exchange parameters smaller than 768 bits, nor RSA and DSA certificates with key sizes less than 1023 bits. Raising the minimum accepted key strength values prevents attacks exploiting known security vulnerabilities such as Logjam (CVE-2015-4000) and FREAK (CVE-2015-0204).
Note that attempts to connect to a server by using keys weaker than the new minimum values now fail, even though such connections worked in previous versions of Red Hat Enterprise Linux.

NSS enables TLS version 1.1 and 1.2 by default

Applications using protocol versions that NSS enables by default now additionally support the TLS version 1.1 and TLS version 1.2 protocols.

ECDSA certificates are now supported

Applications that use the default NSS cipher list now support connections to servers that use Elliptic Curve Digital Signature Algorithm (ECDSA) certificates.

OpenLDAP automatically chooses the NSS default cipher suites

OpenLDAP clients now automatically choose the Network Security Services (NSS) default cipher suites for communication with the server. It is no longer necessary to maintain the default cipher suites manually in the OpenLDAP source code.

Configuring an IdM server to be a trust agent now supported

Identity Management (IdM) distinguishes two types of IdM master servers: trust controllers and trust agents. Trust controllers run all the services required for establishing and maintaining a trust; trust agents only run services required to provide resolution of users and groups from trusted Active Directory forests to IdM clients enrolled with these IdM servers.
By default, running the ipa-adtrust-install command sets up the IdM server as a trust controller. To configure another IdM server to be a trust agent, pass the --add-agents option to ipa-adtrust-install.

Automated migration from WinSync to trusts now supported

The new ipa-winsync-migrate utility enables seamless migration from synchronization-based integration using WinSync to integration based on Active Directory (AD) trust. The utility automatically migrates all users synchronized using WinSync from a specified AD forest. Previously, migration from synchronization to trust could only be performed manually using ID views.
For more information about ipa-winsync-migrate, see the ipa-winsync-migrate(1) man page.

Multi-step prompting for one-time and long-term passwords

When using a one-time password (a token) together with a long-term password to log in, the user is prompted for both passwords separately. This results in better user experience when using one-time passwords as well as a safer long-term password extraction, which allows long-term password caching to be used for offline authentication.

LPK schema for OpenLDAP now available in the LDIF format

LDIF is the new default format for the OpenLDAP import schema, and the openssh-ldap package now provides the LDAP Public Key (LPK) schema in the LDIF format as well. Therefore, administrators can directly import the LDIF schema when setting up public-key authentication based on LDAP.

Cyrus can authenticate to AD and IdM servers again

An upstream release of the cyrus-sasl packages introduced a non-backward compatible change that prevented Cyrus from authenticating against older SASL implementations. Consequently, Red Hat Enterprise Linux 7 was not able to authenticate to Active Directory (AD) and Red Hat Enterprise Linux 6 Identity Management (IdM) servers. The upstream change has been reverted and Cyrus can now authenticate to AD and IdM servers as expected.

SSSD supports overriding automatically discovered AD site

The Active Directory (AD) DNS site to which the client connects is discovered automatically by default. However, the default automatic search might not discover the most suitable AD site in certain setups. In such situations, you can now define the DNS site manually using the ad_site parameter in the [domain/NAME] section of the /etc/sssd/sssd.conf file.

Support for SAML ECP has been added

The lasso packages have been rebased to version 2.5.0 and the mod_auth_mellon packages have been rebased to version 0.11.0 in order to add support for Security Assertion Markup Language (SAML) Enhanced Client or Proxy (ECP). SAML ECP is an alternative SAML profile that allows non-browser-based Single Sign On (SSO).

The winbindd service no longer lists group memberships in its default configuration

The winbindd service in Samba version 4.2.0 and later no longer lists group memberships for display purposes. In some situations, such as in environments with trusted domains, it was not always possible to provide this information reliably. To prevent the risk of providing inaccurate information, the default winbindd configuration has been changed to winbind expand groups = 0, which disables the previous behavior. Note that some commands, such as the getent group command, previously relied on this functionality and might not behave as before.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.