In Part 1 of this series, we looked at core improvements for Identity Management (IdM) in Red Hat Enterprise Linux (RHEL) 7.3, as well as manageability and other improvements. In the second half, we're going to look at interoperabilty, and Active Directory integration. 

Certificate Management

Enriched certificate management is an ongoing theme for several releases.

In the current release we focused on the following use case: assume you issue certificates for different purposes like devices, systems, services, VPNs, switches and so on, using IdM CA. If you have a single CA, all the certificates come from the same trust chain, so administrators have to explicitly limit the scope of the certificates to the environment they are used in to prevent cross pollination and misuse of the certificates issued for one purpose with a different service.

Getting all these access control rules right becomes a really complex task. It would have been much easier if one could just have a dedicated CA for each of the environments. But standing up a separate CA infrastructure is usually an even bigger task. Not anymore! With the SubCA feature one can create a dedicated CA with a couple of commands in seconds.

The second enhancement is the ability to authenticate using smart cards via SSSD and IdM, but this time with added support for Active Directory users coming from a trusted forest. In version 7.2, we introduced the ability to authenticate IdM users using certificates on smart cards when they log into the Linux systems configured with SSSD. This time we added the ability for Active Directory users in trusted forests to use their certificates when they are published to Active Directory or into ID override entries in IdM.

Making certificate related enhancements to bring more and more related functionality is a multi release plan. You will see more additions in this area when the next release arrives.

Interoperability

For some time, you have asked about making the IdM management API available. We were still not confident that it is ready, although we included an API browser into the IdM UI as an experimental feature. Finally, we made a set of changes that enables us to make the API publicly available. We take the commitment to support the IdM management API very seriously and want to make sure there are no issues that would force us to make incompatible changes.

This is why, in the Red Hat Enterprise Linux 7.3 release, we offer a technical preview of the IdM API. We plan to declare full support in one of the future releases. Your feedback and comments will be extremely valuable. To get more information about the IdM management API please read the knowledge base article we published last November on using the technology preview.

Many customers still have legacy UNIX systems and we often get questions about how to integrate these systems into the IdM ecosystem. While IdM can provide authentication via standard LDAP & Kerberos protocols and perform identity lookups via LDAP protocol, the access control capabilities implemented in IdM are not available to those UNIX systems.

To close this gap and provide a single central place for access control management across modern Linux and legacy UNIX systems, a new community project has been launched - pam_hbac.   This project offers a pam module that leverages IdM host-based-access-control rules. It is currently built for Solaris, FreeBSD  and Linux. This module is not included in Red Hat Enterprise Linux as it needs to be installed on other platforms and is not supported by Red Hat but rather by a community of open source developers. If you are interested in this project, please collaborate via GitHub. If you are interested in an AIX version, please contact your IBM representative and open an RFE with IBM.

As I have written some time ago, Red Hat has been working on the identity provider solution to allow federation and SSO for web applications using SAML and OpenID Connect protocols. Earlier this year, Red Hat released a fully supported solution called Red Hat SSO powered by the Keycloak community project. IdM in Red Hat Enterprise Linux 7.3 has been validated as a back end for RH SSO, in parallel to Active Directory and generic LDAP. However, we recommend waiting a bit until the next version of Red Hat SSO is released in several weeks. That version will include a tighter integration between IdP server and IdM/SSSD bringing a better user experience in complex setups.

Active Directory Integration

Clients in AD domains

Some customers that consider deploying IdM with Active Directory trusts face a challenge related to the names of the hosts. If LInux systems are deployed inside the same DNS domain as Active Directory domain controllers, moving to trusts would mean changing hostnames to a different domain when Kerberos SSO is expected to work between all the systems in the environment. In some cases renaming is possible, in some it is really hard. To discuss this issue in details and suggest some workarounds I put together a separate blog post.

Here I want to mention that while we took a look at what else can be done for this use case, we could not find anything that is in our power to improve in the current situation. Hosts can remain unchanged, but that would make it impossible to SSH into those hosts leveraging Kerberos based SSO. If this is acceptable then no name changes would be needed. At that point it becomes a deployment choice and would depend on the constraints and priorities of the specific customer environment.

External trust

The original implementation of IdM to AD trusts implies a full trust between IdM and the whole Active Directory forest. In some cases this is not desirable. Sometimes the users that should be exposed to IdM resources are isolated in a separate domain and it makes sense to have a direct trust with that specific domain rather than with the whole forest. IdM in Red Hat Enterprise Linux 7.3 now has the capability to establish trust with a selected Active Directory domain, rather than with the whole forest.

UPN Support

Users in Active Directory can have an arbitrary name assigned to them called User Principal Name (UPN). By default UPN is constructed from the domain name and user login name automatically, but in some cases it can explicitly be reconfigured. In this case, no assumptions can be made about the UPN name - it is just a string that can pretty much contain any value. SSSD was capable of working with arbitrarily UPN names in the direct integration scenario but was lacking the same flexibility in trust cases. This limitation has been addressed and SSSD can now handle arbitrary UPN names when connected to IdM in trust setup with AD.

Keytab Renewal

When a system is joined directly to Active Directory as a domain member, it has to adhere to key rotation policies. SSSD is now capable of automatically renewing its kerberos keys, following policies defined in Active Directory.

Password Change

In a trust setup, legacy UNIX and Linux systems are connected to a special LDAP compatibility view that exposes merged information between data coming from Active Directory and data stored in IdM. In the current release Active Directory and IdM users authenticating via legacy systems connected to the compatibility tree can change their user password when it expires. Password change via compatibility tree was not possible in the past.

As you can see in the last release, as in every release before, we have delivered a lot of new identity management capabilities. We would be glad to hear your input on the new and old features as well as your improvement requests. Comments are always welcome! Try it, use it, provide feedback. We are here to listen, build and make your day-to-day life easier.