Select a language
With the release of Red Hat Enterprise Linux 8 beta, we wanted to take a look at some of the changes that are coming in identity management in Red Hat Enterprise Linux 8. We’ve been preparing for the update of the Linux authentication toolbox for some time. This is part of our continuous focus on providing IT organizations with features that are designed to give them control over their environments and raise confidence in their deployments.
The release notes for Red Hat Enterprise Linux 7.4 contain a chapter that covers deprecated functionality, including identity management related packages that were deprecated in 7.4. This post expands this section and provides more context about the deprecation of the mentioned Identity Management related components.
If you’re using these today, don’t worry. As described in the release notes, deprecation means that these components are still supported for the life span of a major release i.e. Red Hat Enterprise Linux 7. However, they are not recommended for new deployments because in future versions they might be removed and replaced with a different component or approach.
Authconfig is the tool to configure Pluggable Authentication Module (PAM) and Name Server Switch (NSS) stacks on a given system. It allows different types of configurations including local authentication methods that control logging into a system using locally stored credentials, and remote authentication methods leveraging different servers: Active Directory (AD), Identity Management in Red Hat Enterprise Linux (IdM) or just LDAP and Kerberos.
Over the years the authconfig utility evolved into a complex component which is hard to maintain. It became apparent that the number of different authentication methods, and ways to conduct them, is too great for a single tool to cover all the possible combinations.
To address this challenge a new approach was implemented and piloted in Fedora. It is called authselect. The idea of the project is to allow choosing a specific set of pre-canned PAM and NSS configurations out of the prepared profiles rather than trying to modify the PAM and NSS configuration files in place like authconfig did. Authconfig comes with three profiles: NIS, SSSD and Winbind.
If you do not see a pre-canned configuration that fits your needs you can create a new one and add it to the list of the profiles that the tool can manage. This would be the way for the third party clients that install authentication agents on the system to integrate. So if you have your own customer PAM module create a profile for it, drop it into a specific directory and use authselect tool to apply it to the system. For more information see man pages for authselect-profiles.
Under the hood PAM and NSS configuration files are the place where the configuration is stored. If you need to adjust these configuration files manually, you can. The tool allows you to apply a clean configuration in a scriptable way.
The Pam_pkcs11 module has been traditionally used for the smart card based authentication into a system. Over the years the project developed multiple different plugins and mapping modules that allow linking an account to the certificates on the smart card.
Our conversations with customers indicated that, while available, it was not widely used. The challenges with pam_pkcs11 PAM module is that it does not integrate well with central authentication systems like Active Directory or IdM. It is more useful for handling of the smart card authentication using local, defined on the system, accounts. However smart card authentication is mostly used in the enterprises where centrally managed authentication solution is a compliance requirement.
Starting with Red Hat Enterprise Linux 7.4 SSSD has included capabilities to provide smart card authentication into Linux systems connected to IdM or Active directory (AD) via IdM to AD trust.
For more details see our article "Picking your Deployment Architecture".
With this functionality available in SSSD, and with the efforts to add smart card authentication for local accounts to SSSD, pam_pkcs11 becomes a redundant component. SSSD has grown a sufficient set of capabilities to address the main use cases of the pam_pkcs11 module, and has not been included in Red Hat Enterprise Linux 8 beta.
This PAM module provides Kerberos-based authentication. From the very beginning of its existence the SSSD project was targeting replacing pam_krb5 on the system. SSSD has offered Kerberos authentication for years, but also much more.
With the release of Red Hat Enterprise Linux 7.4 SSSD has the features that we believe users need from the standard pam_krb5 module, and we felt ready to add it to the set of deprecated PAM modules. As with pam_pkcs11, this module is not included in Red Hat Enterprise Linux 8 beta.
This deprecation announcement generated the most questions. First of all, there were speculations that everything related to OpenLDAP is deprecated and will be removed. This is not the case. The deprecation covers the server package only. The client package will stay and is a part of many components and solutions.
The server is deprecated for several reasons. First of all, the LDAP server is the core of the identity system. It requires enterprise level support. Red Hat found itself torn between multiple competing solutions: Red Hat Directory Server, IdM, and OpenLDAP Server.
IdM being a part of Red Hat Enterprise Linux and thus covered by the standard subscription without extra cost, is aimed at providing authentication and account management within an enterprise.
Red Hat Directory Server is a separate product with a separate subscription. Its main use case to act as a back-end for business applications storing users account information, credentials, preferences and other custom information that applications need to keep. Both Red Hat Directory Server and IdM have well trained dedicated support teams that can provide enterprise level support.
With OpenLDAP the situation was different, and confusing. The OpenLDAP server is a package that has been provided in Red Hat Enterprise Linux with a much bigger reliance on the community based development and maintenance.
The knowledge and expertise, and thus ability to support OpenLDAP server to the same level of confidence as our other offerings was limited. To avoid confusion, Red Hat decided to deprecate OpenLDAP server to discourage new deployments and steer customers to the enterprise ready solutions Red Hat offers full support for, or to allow customers to seek services from the third parties that support OpenLDAP server professionally.
The OpenLDAP server package will not be included into the next major version of Red Hat Enterprise Linux. With that in mind, for production deployment, Red Hat recommends using Red Hat Directory Server or the included IdM technologies in Red Hat Enterprise Linux. But we also know customers want control over their environment and we provide the freedom to acquire enterprise level support from companies that professionally support OpenLDAP server.
Planning for Red Hat Enterprise Linux 8
As you can see, we’ve been laying the groundwork for Red Hat Enterprise Linux 8 for quite some time. If you have not yet, please be sure to start testing the Red Hat Enterprise Linux 8 beta and provide feedback. We are excited about the IdM (and other) technologies available with Red Hat Enterprise Linux 8 beta, and look forward to hearing your experiences.