Sélectionner une langue
Hello again! I have not had time to blog in awhile. What happened? I picked up some additional responsibilities and these consumed a lot of my time. But now... I am back and will be blogging once again.
Time goes on and there are (many) new topics that are worth sharing with you. The first subject that I want to cover is the new Identity Management (IdM) features in Red Hat Enterprise Linux 7.2. While the release happened nearly three months ago - it's still worth me providing an overview of new features and functionality. Another subject that people often ask about nowadays is the conversion from 3rd party vendor solutions to the IdM offering from Red Hat. We see a lot of interest in this area and I want to share some hints for when it is a good idea to use what we offer and when it might not be. Finally, there are also some emerging technologies
that I want to draw your attention to; in addition to drawing your attention to them - we need your help and input in order to serve you best - to this end - please do share your thoughts and comments.
So without further ado let me start again...
The core components of the IdM Server were rebased in RHEL 7.2 (based on FreeIPA 4.2, SSSD 1.13 upstream project versions). The updated components offer a lot of new functionality that can be leveraged to cover more customer use cases. This article lists the new features in Identity Management available in Red Hat Enterprise Linux 7.2, provides basic information about each and contains links to the respective design pages, including instructions for testing. The features are divided by main components of the Identity Management solution.
Identity Management / IPA
One-Way Trust, Trust Agents
Initially, IdM and Active Directory (AD) trust was implemented as a Two-way Trust. Due to technical limitations, an outgoing trust leg was required to obtain information about users and groups from the domains of a trusted Active Directory forest. At the same time, IdM did not provide corresponding services for Active Directory servers to perform identity resolution for IdM users and groups. As result, IdM users were not able to log into Windows systems from a trusted Active Directory forest and access control of IdM users and groups to access Active Directory resources was not possible.
Essentially, the IdM implementation of a Two-way Trust to Active Directory was actually a one-way from the user’s perspective. Because the IdM solution lacked a formal, documented One-way Trust, some organizations with strict AD-related trust policies requested an explicit supported one-way trust feature. In RHEL 7.2, IdM was enhanced to allow proper One-Way Trust relationships. It is now easier to deploy IdM in environments with strict AD trust policies, and thus easier to prove policy compliance to company or external auditors.
As part of the implementation of this feature, a Trust agent concept was introduced. It is no longer required to install and configure an AD Trust package on all systems serving AD Trust information. IdM servers can now be enabled as Trust agents with default packages installed. The only requirement is that there should be at least one IdM server with AD Trust package installed.
DNSSEC (Technical Preview)
The IdM server offers DNS server, controlled with a common CLI and UI. In order to provide security for the DNS responses and prevent known DNS attacks, the IdM Server now provides DNSSEC, which is a known solution to solving problems related to DNS spoofing. DNS server with DNSSEC enabled can serve signed DNS responses which can be validated by a client and provide:
- Data integrity
- Authenticated denial of existence
The only known caveat is that one of the replicas needs to be chosen as a DNSSEC key master to generate signing keys for each zone and provide key rotation. It is important to back up the keys and OpenDNSSEC database in case the DNSSEC key master replica is lost. This should be done using standard IdM backup and restore scripts.
Reference: FreeIPA design page - testing instructions
Certificate Improvements - Certificate Profiles, User Certificates
IdM in RHEL 7.2 introduces the most important certificate-related enhancements since its inclusion in RHEL. Previously, the IdM server was able to issue certificates using only one profile. This meant that all the certificates in IdM looked the same. However, certificates are issued for different purposes and require different extensions (Examples: VPNs, mobile devices, Puppet, User signing, User authentication, etc.). Now the IdM Server can manage the profiles in a replicated tree, shared between all IdM replicas. Once the profile is created and loaded into IdM, it can be used for requested certificates in common interfaces - CLI, UI, ipa-getcert - provided by Certmonger.
Also, in the past IdM was only able to issue and store certificates for hosts and services, but not for users, and so was unable to handle user PKI use cases.
IdM can now issue certificates for users using different profiles via standard interfaces. New commands were added to IdM CLI to add externally-issued certificates to user entry. This is especially useful when adding a Smart Card certificate to user entry to allow Smart Card authentication - (see respective IdM Client feature).
User Lifecycle Management
In many cases, users are added into an identity system like IdM by an external provisioning system which uses LDAP. Consequently, it can't be enhanced to add all the parts of the user entry that IdM expects. Also, if user leaves the company, the user needs to be removed from IdM otherwise it would be visible in all searches even though the user has been deactivated.
The IdM Server now allows for two new containers for user entries to address these use cases:
- Staging users: allows adding (incomplete) user entries via LDAP/CLI/Web UI and moving them to the main tree by privileged administrator
- Deleted users: contains removed active users, ensures that new users do not have colliding settings (especially login, UID, GID)
Reference: FreeIPA design page
Kerberos Proxy (Kdcproxy)
Kerberos authentication across firewalls requires opening special ports, which is not possible in many cases. Traditionally, those ports are closed which prevents a Kerberos authentication for clients that happen to be outside the firewall (examples include laptops, DMZ). The IdM Server now has a new component called kdcproxy. The component allows for proxying Kerberos traffic over the HTTPs, which is open in most cases and can be leveraged by the clients configured to use the proxy URL.
Vault - Secret store
The IdM Server now offers a new Vault (DRM) subsystem as part of its Certificate System component. Vault allows for storing user or service secrets, encrypted by symmetric or asymmetric keys following the best security practices.
API and API Browser (Experimental)
Since its first release, the IdM Server provided JSON (XML) RPC API, as it is naturally consumed by CLI or the Web UI. However, the API was hard to use by other consumers and documentation was quite limited for this use case. The IdM Server in RHEL-7.2 now provides an interactive guide to explore the capabilities of the provided API (see IPA Server tab in the Web UI).
Please Note: The API itself is still experimental and may be a subject to change in future RHEL versions. Feedback or suggestions for API improvements are welcome.
IdM Client - SSSD
Authentication using certificates on Smart Cards required mapping of the user identity in the certificate to the user on the operating system. Pam_pkcs11 was able to do the mapping using a local file which is not scalable. Pam_krb5 requires a Kerberos extension in a certificate which is usually not provided.
Given that the SSSD component of Identity Management is already the gateway and provider of different authentication methods against multiple identity sources and has access to the right information, it has been enhanced to make Smart Card authentication easier to use.
Currently, SSSD matches users by full certificate lookup. When used with the IdM Server, the prerequisite is to either issue the Smart Card certificates by the IdM Server itself or add/register the certificates to IdM user via the new options mentioned in IdM Server User Certificates feature.
Please Note: this feature was tested with the IdM Client authenticating against the IdM Server. With the right configuration, SSSD might be able to authenticate users with certificates registered in AD. This use case requires extra interoperability testing. A Knowledge Base article will be created when the engineering team has test results.
OTP Multi-step Prompting
Traditionally, a Linux system prompts the user for username and password where the password is a single prompt. In recent releases, when a system is connected to IdM and a user is enabled for two-factor authentication using OTP tokens, the user should be able to enter his password (first factor) and then the code from his token (second factor) in this single prompt. However, the single prompt for both factors provided a poor user experience. For many users, it was unclear what the prompt is actually asking for. Additionally, since credential caching only works with the first factor, it is important that both factors are entered separately.
SSSD and the PAM stack were enhanced to prompt the user for his password and his OTP code separately, so that if the system is not connected to the identity server it will use only the first factor to authenticate using cached credentials. When the identity server is reachable, the OS will prompt for both factors separately.
Please Note: Improving the usability of the multi-factor authentication for laptop users is part of the longer term identity management strategy.
This is the first enhancement of a series of enhancements on the roadmap designed to make the user experience smoother and reduce number of authentications required to fully connect to the enterprise resources.
Reference: SSSD design page
Local UID/GID override
In some environments, the POSIX attributes (such as UIDs, GIDs or shell) for some accounts are different on different systems. When trying to consolidate the account management in a central server, it is easier to override the POSIX attributes locally than centrally. In previous versions, this was only possible using IdM server ID Views functionality. However, this was not an option for direct integration scenarios.
The IdM Client (SSSD) was enhanced to allow overrides of POSIX attributes for any user and group. Please see sss_override man page for more information.
Authentication against cache
By design, on every authentication SSSD goes over the wire to perform an online authentication against the authentication server (IdM Server, Kerberos, LDAP or Active Directory). If there are multiple authentications for a user in a short period of time, this may lead to performance problem. In order reduce the chance of performance problems,, SSSD now allows for configurable offline authentication if the online authentication was performed within a predefined number of seconds in the past.
Reference: SSSD design page
Certmonger SCEP Support
The IdM Client prefers Certmonger component for requests and renewal of certificates issued by the IdM Server. However, not all deployments prefer IdM to manage its certificates. In many cases, the certificate authority is a Microsoft CA.
SCEP (Simple Certificate Enrollment Protocol) is a preferred method of acquiring such certificates. Certmonger was thus enhanced to support this protocol for the Certificate Authorities that support SCEP.
Please Note: The SCEP protocol is manual and does not have strong authentication methods. Certmonger still uses Kerberos to authenticate when it interacts with IdM.