- Red Hat Enterprise Linux (RHEL) 7.2
- Red Hat Enterprise Linux (RHEL) 7.2 Beta
- Identity Management / IPA
What are the new main features introduced in Identity Management in RHEL 7.2? How to test them and provide feedback for the Engineering team? This solution is targeted but not limited to RHEL-7.2 and RHEL-7.2 Beta customers.
The core components of IdM Server were rebased in RHEL-7.2 (based on FreeIPA 4.2, SSSD 1.13 upstream project versions) and thus again offer a lot of new functionality that can be leveraged to cover more customer use cases. This article lists the new major features in Identity Management available in Red Hat Enterprise Linux 7.2, provides basic information about them and contains links to respective design pages, including instructions for testing. Features are divided by main components of the Identity Management solution.
Identity Management / IPA
One-Way Trust, Trust Agents
Initially IdM and 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 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 login to Windows systems from a trusted Active Directory forest and access control of IdM users and groups to access Active Directory resources was not possible. Effectively, the IdM implementation of a Two-way trust to Active Directory was a one-way from usage perspective. However, due to formal lack of One-way trusts in IdM solution was not accepted in some organizations where strict AD related policies do not allow such type of trust relationship. In RHEL-7.2 IdM was enhanced to allow proper One-Way Trust relationship and is thus easier to deploy in environments with strict AD trust policies, easier to prove compliance to company or external auditors.
As part of the feature implementation, Trust agent concept was introduced. It is no longer required to install and configure AD Trust package on all systems serving AD Trust information. IdM servers can be now 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.
DNSSEC (Tech Preview)
IdM server offers DNS server, controlled with common CLI and UI. In order to provide security for the DNS responses and prevent known DNS attacks, 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 cave-eat is that one of the replicas needs to be chosen as DNSSEC key master which generates signing keys for each zone and provides key rotation. The keys and OpenDNSSEC database should be backed up in case the DNSSEC key master replica is lost (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 biggest certificate related enhancements since it's inception in RHEL. Previously, IdM server was able to issue certificates using only one profile meaning that all the certificates in IdM looked the same. Certificates are issued for different purposes and require different extensions (Examples: VPNs, mobile devices, Puppet, User signing, User authentication, etc.). IdM Server was enhanced to 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.
Secondly, in the past IdM was able to issue and store only certificates for hosts and services but not for users, thus missing the user PKI use cases. IdM was enhanced to 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 (especially useful when adding a Smart Card certificate to user entry to allow Smart Card authentication - see respective IdM Client feature).
Official Documentation: Certificate Profiles, Certificate Authority ACL Rules, Issuing User Certificates with the IdM CA, Managing User Certificates
Reference: FreeIPA design page - Certificate Profiles, FreeIPA design page - User Certificates
User Life Cycle Management
In many cases users are added into identity system like IdM by an external provisioning system, which uses LDAP and can't be enhanced to add all the parts of the user entry 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 he can be deactivated. IdM Server was enhanced to allow 2 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)
Kerberos Proxy (Kdcproxy)
Kerberos authentication across firewalls requires opening special ports, which is not possible in many cases. Traditionally those ports are closed preventing an authentication using Kerberos for clients that happen to be outside the firewall (laptops, DMZ). IdM Server was enhanced to contain a new component called kdcproxy. The component allows 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
IdM Server was enhanced to provide new Vault (DRM) subsystem of it's Certificate System component. Vault allows storing user or service secrets, encrypted by symmetric or asymmetric keys following the best security practices.
API and API Browser (Experimental)
IdM Server provides JSON (XML) RPC API, since the first versions as it is naturally consumed by CLI or the Web UI. However, the API is hard to use by other consumers as there was no documentation for it. The IdM Server in RHEL-7.2 provides interactive guide to explore capabilities of the provided API (see IPA Server tab in the Web UI).
Please note that 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 Server Interoperability - Federation
Ipsilon - Federated Identity Provider (Tech Preview)
In some environment Kerberos SSO can’t be used due to different limitations. The alternative and de facto standard is to use SAML based SSO for access to the web applications, where identity is provided by IdM server through Ipsilon and consumed by the external (web) application. Ipsilon component of RHEL acts as a SAML IdP providing SSO between different applications.
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 mapping using local file which is not scalable. pam_krb5 requires Kerberos extension in a certificate which is usually not there. In order to make Smart Card authentication more easier to use, SSSD project was enhanced to allow it, given it is already the gateway and provider of different authentication methods against multiple identity sources and has access to the right information.
Currently, SSSD matches users by full certificate lookup. When used with 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.
Note: this feature was tested with IdM Client authenticating against 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, Knowledge Base article shall be created when the engineering team has test results.
OTP Multi-step Prompting
Traditionally a Linux system prompts user for username and password where 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 was able to enter password (first factor) and code from his token (second factor) in this single prompt. However, the single prompts provided poor user experience as 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 user for password and 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.
Note: Improving usability of the multi factor authentication for laptop users is a part of a longer term plan
This is the first enhancements of a series of enhancements on the roadmap to make user experience smooth and reduce number of authentications required to fully connect to the enterprise resources
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 with IdM server ID Views functionality. However, this was not an option for direct integration scenarios.
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 such behavior may become a performance problem. In order to mitigate such scenarios, SSSD now allows a configurable offline authentication if the online authentication was performed within predefined number of second in the past.
Reference: SSSD design page
Certmonger SCEP Support
IdM Client prefers certmonger component for requests and renewal of certificates issued by IdM Server. However, not all deployments prefer IdM to manage certificates. In many cases the CA is a Microsoft CA
SCEP (Simple Certificate Enrollment Protocol) is a preferred method of acquiring such certificates. Certmonger was thus enhanced to talk this protocol to the Certificate Authorities that support SCEP.
Note: SCEP protocol is manual and does not have strong authentication methods. Certmonger still uses Kerberos to authenticate when it interacts with IdM.
- Red Hat Enterprise Linux
- Learn more
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.