Resolution

Introduction

Feedback from a real-life Identity Management (IdM) customer deployment is very important input in finalizing the Identity Management release for Red Hat Enterprise Linux 7.1. It gives the Engineering team the ability to fix issues before they hit a customer environment, to refine the default configuration, and to incorporate changes based on customer feedback.

This article lists the new major features in Identity Management available in Red Hat Enterprise Linux 7.1, provides basic information about them and contains links to respective design pages, including instructions for testing, and official documentation. Features are divided by main components of the Identity Management solution.

Identity Management / IPA

One-Time Password Authentication

One of the best ways to increase authentication security is to require two factor authentication (2FA). A very popular option is to use one-time passwords (OTP). This technique began in the proprietary space, but over time some open standards emerged (HOTP: RFC 4226, TOTP: RFC 6238). Identity Management in Red Hat Enterprise Linux 7.1 contains the first implementation of the standard OTP mechanism.

One unique challenge of this project is to provide a mechanism to permit gradual migrations from proprietary technologies to their related open standards. Since nearly every proprietary technology supports the RADIUS authentication protocol, we provide a way to proxy OTP requests to their proprietary RADIUS servers. This provides a path for gradual migration.

Official Documentation: One-Time Passwords
Testing instructions: FreeIPA design page

Migrating Existing Environments to AD Trust

When Identity Management Server is configured with a Winsync synchronization with Active Directory, all users are copied to the Identity Management server with generated POSIX attributes (login name, UID number, GID number, shell...). The architecture has several downsides when compared to the infrastructure based on Cross-Forest Trusts, and it is commonly discouraged from being used. However, before Red Hat Enterprise Linux 7.1 it was very difficult to migrate to a trust-based setup, given that synchronized Active Directory users already had POSIX attributes assigned and used on the system ACLs, for file ownership for example.

The new ID Views mechanism allows configuring POSIX attributes for AD users and thus allows the Administrator to both separate POSIX attributes from the user identity in Active Directory and also potentially remove the Winsync-ed identity from the Identity Management Directory Server and leverage Active Directory Trust for user authentication. The user (or group) POSIX attributes can be defined either in an ID View. See the detailed list of covered use cases:

• Store POSIX attributes and SSH keys for Active Directory users: Define POSIX attributes or SSH users for AD users and let them be applied when the AD user authenticates to clients running SSSD with ID Views support or via legacy compat LDAP tree. This capability is useful both for migration from Winsync or in a situation when the Linux Administrator would like to manually define POSIX attributes for Active Directory users, but Active Directory policy does not allow it.
• Migration from the Sync to the Trust solution: Utilize the ID Views interface to configure needed POSIX attributes for existing users synchronized with Winsync and move them back to AD. The mechanism follows the simple procedure:

1. Select a user/group entry to be migrated
2. Create an ID View override specifying previously used UID or other tools
3. Backup migrated user/group
4. Delete user/group original entry

• Migrating from NIS to IdM/AD solution: NIS based infrastructure that is being migrated to IdM/AD based solution still often requires the original POSIX data remain unchanged on some NIS domains or may the company policies may prevent setting the original POSIX data in the AD directly. *ID Views * may be leveraged in this case to configure the POSIX data in the Identity Management Server directly.

• Different POSIX/SSH data for different environments: ID Views can be used to set different POSIX data or user SSH public keys for different production environments, for example development, testing or production, based on the respective host groups.

Official Documentation: ID Views and Migrating Existing Environments to Trust
Testing instructions: FreeIPA design page

Backup and Restore

Red Hat Enterprise Linux 7.1 Identity Management release contains the first supported backup (ipa-backup) and restore (ipa-restore) utilities. While robust Identity Management Replica infrastructure is the key mechanism for infrastructure recovery (dedicated KB article with reasoning), the new backup and restore utilities are targeted on catastrophic hardware or data failures that cannot be recovered from leveraging the replicas.

Official Documentation: Backing Up and Restoring Identity Management
Testing instructions: FreeIPA design page, Fedora 19 Test Day page, ipa-backup and ipa-restore man pages

Identity Management CA Certificate Renewal

Before Red Hat Enterprise Linux 7.1, Identity Management CA Certificate renewal or change was only possible by a very complicated manual procedure. This version of Identity Management introduces tools for automating this infrastructure critical operation. The feature covers the following use cases:

• Automated CA certificate renewal: When the CA certificate is nearing its expiration time, it will be automatically renewed. The renewed certificate uses the same key pair and subject name as the old certificate. Note that this option is only available for self-signed CA certificates in CA-ful installs.
• Manual CA certificate renewal: Allow the Identity Management Administrator to manually renew the CA certificate or change its chaining (self-signed to signed by external CA, signed by external CA to self-signed, signed by external CA to signed by other external CA). The renewed certificate will use the same key pair and subject name as the old certificate. This works for any CA certificate in CA-ful installs.
• Manual install of CA certificate: In CA-less installations, CA certificate renewal is completely in charge of a 3rd party CA. Means of installing CA certificates are now provided.

Note that CA certificate on clients still needs to be updated manually by running the ipa-certupdate utility.

Official Documentation: Certificate Renewals
Testing instructions: FreeIPA design page, ipa-certupdate, ipa-cacert-manage man pages.

Increased Access Control Granularity

The internal access control and permission system was overhauled so that more granular access control can be offered. With the new Read Permissions, the Administrator may select different read access to different parts of the Identity Management LDAP tree. Instead of one global read ACI, entries in Identity Management (users, groups, policy objects, SUDO, ...) have their own Read Permission that can be tweaked to control visibility of the entries or their attributes. The new --bindtype option of the Permission API can now also apply permissions not only to selected users or services in the Identity Management server, but also to any authenticated entity or simply to anonymous.

Official Documentation: Permissions
Detailed information: main feature design page, Read Permissions design page, Anonymous and All Permissions design page

New Fresh and Responsive Web UI

Identity Management Server Web interface was reworked and is now based on the open-source PatternFly framework providing common UX principles and patterns usable in enterprise open source web applications. By utilizing the new framework, the Web UI now leverages the Bootstrap 3 front end framework offering much better responsiveness, compared to the old version of the Web UI. It allows the Web UI to abandon absolute position layout and became usable on devices with various screen sizes.

The new Web UI can be tested by simply exercising all the new features. Customers are encouraged to try controlling the Web UI with different devices, including but not limited to tables or mobile phones.

List of new features: FreeIPA design page

Apply Automember Rules to Existing Users or Hosts

Identity Management supports UI for configuring automember rules for automated assignment of new users or hosts in respective groups, according to their characteristics (e.g. userClass or departmentNumber). However, the rules were applied only to new entries. The new CLI and Web UI in Red Hat Enterprise Linux 7.1 allows rebuilding the auto-membership for all or selected existing users or hosts and thus allows easy application of newly configured policies.

Testing instructions: FreeIPA design page

DNS Interface Enhancements

Identity Management DNS interface was improved with several minor enhancements, namely:

• Internationalized domain (IDN) support: DNS zone and record names now support non-ASCII characters. The DNS record names can be entered with standard Unicode encoding which is then transparently encoded to Punycode required for the IDN support. Note that the canonical host or service DNS names are still limited to ASCII until Kerberos protocol accepts IDN.
• Wildcard DNS names: Define wildcard DNS record (*) in the DNS zone which is then used as a default value for unknown DNS queries for a zone.
• DNS Forward zones: new DNS zone type was added to better separate forward and master zones and thus make the Identity Management DNS interface compliant with the forward zone semantics in BIND, See FreeIPA design page for details.

Keytab Retrieval Management

Before Identity Management in Red Hat Enterprise Linux 7.1, when a Kerberos principal's key was created, it was not possible to retrieve it from the KDC. The only option was to generate a new key. However, the approach was suboptimal when multiple machines (e.g. in a cluster) needed to share the same key for high availability or load balancing purposes. In these cases, distributing the key had to be performed completely through out of band/custom channels.

This version of Identity Management adds a mechanism to retrieve an existing key from the KDC (subject to access control) and resolves the secure distribution channel problem. Leaving to the cluster members the problem of retrieving the key when a new one is created or an old one rotated.

Testing instructions: FreeIPA design page Note: the build included in beta does not contain option --hosts in service-allow-retrieve-keytab command for allowing to download a keytab of a service . For testing purposes, the approach can be simulated with users (--users) or user groups(--groups) instead of hosts.

Resolve Group Membership of Active Directory User Prior to Log In

Before Red Hat Enterprise Linux 7.1, the full list of group memberships for users from trusted domains was only available for authenticated users on client machines. Authentication was needed because the group memberships were extracted from the PAC which is a part of the Kerberos ticket of the user. For un-authenticated users only the primary POSIX group was available.

In Red Hat Enterprise Linux 7.1, the Identity Management servers can resolve the group memberships for users from trusted domains even for un-authenticated users by reading them from the Active Directory Domain Controllers of the trusted domains directly. In Red Hat Enterprise Linux 7.1, this data is available on all updated client systems as well.

Testing instructions: FreeIPA design page

SSSD

This section only lists SSSD features that are testable with a standalone client instance. Other features (such as resolving user names from AD in IdM UI) that rely on SSSD features, but are only testable with IdM, are listed in the section above.

Control Access to Linux Machines with Active Directory GPO

A common use case for managing computer-based access control in an Active Directory environment is through the use of GPO policy settings related to Windows Logon Rights. The Administrator, who maintains a heterogeneous AD and Red Hat Enterprise Linux network without Identity Management Server available to leverage HBAC rules had a challenging task in controlling access to the Linux machines centrally, without updating SSSD configuration on every client machine.

In Red Hat Enterprise Linux 7.1, Administrator is able to define log-in policies in a central place -- on the Active Directory Domain Controller in the Group Policy. The same policies will then be honored by its Red Hat Enterprise Linux clients and Windows clients alike.

Official documentation: Group Policy Object Access Control
Testing instructions: SSSD design page

Integrate SSSD with CIFS Client

Although mapping of POSIX UIDs and SIDs is not needed when mounting a Samba CIFS share, it might become necessary when working with files on the share, e.g. when modifying ACLs. Up to version 5.8 the cifs-utils package used Winbind for this exclusively. However, with version 5.9 of cifs-utils a plugin interface was introduced to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. In Red Hat Enterprise Linux 7.1, SSSD provides a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin, an SSSD client can access a CIFS share with the same functionality as a client running Winbind.

Official documentation: Accessing a CIFS share with SSSD
Testing instructions: SSSD design page

Active Directory Users Can Use UPN to Log In

Kerberos authentication is independent of the operating system of the host and the Kerberos principals are intentionally decoupled from the user identity and respective POSIX information. Basic mappings are integrated in the MIT Kerberos library - by default, the realm part of the Kerberos principal is stripped off and what remains is considered a POSIX user name. However, the mapping does not suit environments with multiple realms or a Cross-Realm Trust with the Active Directory. Manual auth_to_local rules need to be defined on all supported client systems in this case.

SSSD in Red Hat Enteprise Linux 7.1 introduces a local auth plugin for Kerberos KDC to allow SSSD to look up the POSIX information for an authenticated account and return it to the system. No auth_to_local rules need to be configured for configured realms in SSSD.

Testing instructions: SSSD design page

Restricting the Domains a PAM Service Can Authenticate Against

Some environments require that different PAM applications can use a different set of SSSD domains. The legacy PAM modules, such as pam_ldap were able to use a different configuration file altogether as a parameter for the PAM module. An example use-case is an environment that allows external users to authenticate to an FTP server. This server is running as a separate non-privileged user and should only be able to authenticate to a selected SSSD domain, separate from the internal company accounts.

With SSSD in Red Hat Enterprise Linux 7.1, the Administrator is able to leverage this new feature to allow the FTP user to only authenticate against one of the domains in the FTP PAM config file.

Official documentation: Restricting Domains for PAM services
Testing instructions: SSSD design page

Running SSSD As a Non-Root User

Normally, all SSSD processes run as the root user. However, if one of the processes was compromised, it might lead to compromising the whole system, especially if additional measures like SELinux were not enabled. In Red Hat Enterprise Linux 7.1, except several well documented parts, all SSSD processes are able to run under unprivileged user when user option is configured in sssd.conf.

Testing instructions: SSSD design page