Ten New Identity Management (IdM) Features in Red Hat Enterprise Linux 7.1

Given the recent general availability of Red Hat Enterprise Linux 7.1 – this post is dedicated to reviewing what’s new in the world of IdM.

Table of Contents

  1. One-Time Password Authentication
  2. Migrating Existing Environments to AD Trust
  3. Backup and Restore
  4. Identity Management CA Certificate Renewal
  5. Increased Access Control Granularity
  6. A New Fresh and Responsive Web UI
  7. Apply Automember Rules to Existing Users or Hosts
  8. DNS Interface Enhancements
  9. Keytab Retrieval Management
  10. Resolve Group Membership of Active Directory Users Prior to Log In

 

1. 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). While this technique began in the proprietary space, open standards have emerged (e.g. HOTP: RFC 4226, TOTP: RFC 6238) over time. Identity Management in Red Hat Enterprise Linux 7.1 contains the first commercially supported implementation of the standard OTP mechanism over the Kerberos protocol.

In working to include OTP in Red Hat Enterprise Linux we encountered a unique challenge, namely: how might we provide a mechanism to permit gradual migrations from proprietary technologies to their related open standards? Our solution: as nearly every proprietary technology supports the RADIUS authentication protocol, we provide a way to proxy OTP requests to proprietary RADIUS servers; ensuring the option for a gradual migration path.

For technical details on OTP – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

2. Migrating Existing Environments to AD Trust

When Identity Management Server is configured via 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, etc.). This approach has several downsides as compared to an infrastructure based on Cross-Realm 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 configuration, given that synchronized Active Directory users already had POSIX attributes assigned and, for example, used on-system ACLs for file ownership.

With Red Hat Enterprise Linux 7.1 the new ID Views mechanism allows configuring POSIX attributes and SSH keys for AD users. With this feature administrators can 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 taking advantage of Active Directory Trust for user authentication. Either user or group POSIX attributes can be defined in an ID View. The following is a detailed list of use cases covered with the ID Views feature:

  • Store POSIX attributes and SSH keys for Active Directory users: Define POSIX attributes or SSH keys for AD users and let them be applied when the AD user authenticates to clients running SSSD with ID Views support or via a 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 the migrated user/group
    4. Delete the original user/group entry
  • Migrating from NIS to IdM/AD solution: A NIS based infrastructure that is being migrated to an IdM/AD based solution often still requires for the original POSIX data to remain unchanged on some NIS domains. In some cases company policies may prevent setting the original POSIX data in the AD directly. In situations like these, ID Views may be leveraged to configure the POSIX data in the Identity Management Server directly.
  • Different POSIX/SSH data for different environments: ID Views can also be used to set different POSIX data or user SSH public keys for different environments, for example development, testing or production, based on the respective host groups.

For technical details on migrating existing environments to Trust – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

3. Backup and Restore

Identity Management in Red Hat Enterprise Linux 7.1 contains backup (ipa-backup) and restore (ipa-restore) utilities. While a 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.

For technical details on backup and restore – visit the FreeIPA design page, Fedora 19 Test Day page, or review the ipa-backup and ipa-restore man pages. Click here to return to the Table of Contents.

 

4. Identity Management CA Certificate Renewal

Before Red Hat Enterprise Linux 7.1, Identity Management CA certificate renewal or change was only possible via an overly complicated manual procedure. The good news is that the latest version of Identity Management introduces tools for automating this critical infrastructure operation. The new feature set 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, or 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. . With Identity Management in Red Hat Enterprise Linux 7.1 it is now possible to manually replace the CA certificate if it was rotated in the 3rd party CA.
  • IdM CA Install: The CA-less installation can be turned into a deployment with either self-signed IdM CA or chained to an existing external CA.

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

For technical details on CA certificate renewal visit the FreeIPA design page or review the ipa-certupdate, ipa-cacert-manage man pages. Click here to return to the Table of Contents.

 

5. Increased Access Control Granularity

With the release of Red Hat Enterprise Linux 7.1, the internal access control and permission system was overhauled to offer more granular access control. With 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.

For technical details on the increased access control granularity – visit the main feature design page, the Read Permissions design page, and the Anonymous and All Permissions design page. Click here to return to the Table of Contents.

 

6. A New Fresh and Responsive Web UI

Also of note, the 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 become usable on devices with various screen sizes (e.g. tablets and mobile phones).

For technical details on the new Web UI – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

7. Apply Automember Rules to Existing Users or Hosts

Identity Management supports a UI and command line 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.

For technical details on applying automember rules – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

8. DNS Interface Enhancements

In Red Hat Enterprise Linux 7.1 the IdM 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: Support for defining the wildcard DNS record (*) in the DNS zone is included. The wildcard, once defined, can then be used as a default value for unknown DNS queries for a given zone.
  • DNS Forward zones: A new DNS zone type was added to better separate forward and master zones and to thus make the Identity Management DNS interface compliant with the forward zone semantics in BIND. For technical details on forward zones – visit the FreeIPA design page.

Click here to return to the Table of Contents.

 

9. 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 sub-optimal 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 as included with Red Hat Enterprise Linux 7.1 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.

For technical details on keytab retrieval management – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

10. Resolve Group Membership of Active Directory Users Prior to Log In

Last, but not least, 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.

For technical details on resolving group memberships for users from trusted domains – visit the FreeIPA design page. Click here to return to the Table of Contents.

 

As can been seen – Red Hat Enterprise Linux has incorporated numerous updates to Identity Management. If you have questions on any of the new features or functionality – don’t hesitate to reach out using the comments section below – I look forward to hearing from you!

  1. Is there a compatibility matrix to list support of Redhat client with IdM 7.1. Is Redhat 4,5,6 client supported?

    1. Yes there is. But the later client you use the more functionality you can get. Older clients RHEL 4 & early 5 can use pam_ldap/pam_krb5 + nss_ldap against IdM. Later versions can use SSSD (starting 5.6) but might need to be configured differently depending on whether you need AD trust or not. It gets pretty complex quite quickly so it is better to understand your use case and requirements first and then see what client configuration would be best.

      1. Hi Dmitri,

        I have RHEL 5, 6 and Solaris 10 & 11 systems, which need to be configured as IdM clients. What kind of configuration would you recommend for RHEL 5 and Solaris clients?

      2. Hello,

        RHEL 5 & 6 have ipa-client-install that can be used to configure clients. On RHEL 7 you can use ipa-client-install or realmd that acts as a wrapper around ipa-client-install but can connect your clients to either IdM or AD.
        If you plan to use trusts the configuration is a bit different.
        I suggest you follow the document https://drive.google.com/drive/u/1/folders/0B3tfpNCVjJdCfi1nS0pLN3JScXhNS25jRzNXOVRoazhnX1l3emNBTU9VRWxyV0hRallhQTg
        and this https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/Windows_Integration_Guide/index.html#trust-legacy
        For Solaris here is the pointer: http://www.freeipa.org/page/ConfiguringUnixClients
        If you want to use Solaris with trusts you would need to point your LDAP clients to cn=compat tree. More details can be found on the FreeIPA wiki.
        You can also search archives of the freeipa-users list if you have specific questions.
        Here is the official Red Hat support statement on the matter of non Linux clients: https://access.redhat.com/articles/261973

        HTH

        Thanks,
        Dmitri

      3. Thanks for quickly responding to it. Yes, we are using Cross-realm trust between IdM and AD and are planning to configure both Solaris and Linux servers as clients.

        Thanks & Regards,
        MG

      4. Just thought of providing an update on this…

        I was able to configure RHEL 5 and 6 systems as IdM clients and the authentication from both IdM and AD works as expected.

        As for Solaris 10 systems, the authentication works from IdM, but not from AD. Somehow, I can’t even fetch user details for AD users from that client. Is this expected?

        If not, would you be able to suggest something?

        Thanks & Regards,
        MG

      5. Are you using cn=compat as DN suffix?
        Please take a look at the following materials:
        https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/Windows_Integration_Guide/index.html#trust-legacy
        The slides http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf also give some hints. You can look at the generic LDAP configuration given by ipa-advice tool and adapt it to work with Solaris clients.
        freeipa-users list https://www.redhat.com/mailman/listinfo/freeipa-users has multiple conversations on the matter and you can find other users that connected Solaris clients with AD trust.
        It would be really helpful is someone would contribute a howto (http://www.freeipa.org/page/HowTos) because we know it works but we do not have a configuration handy to give out like in your case.

        Thanks
        Dmitri

  2. Aah…That’s one thing I was missing. I added the cn=compat suffix and I can query the user/group entries from AD. However, the authentication still doesn’t work…still researching… I would love to contribute to the “HowTos” once I am able to configure it in my environment.

    1. Your authentication needs to point to the same suffix and do an LDAP bind, not Kerberos. Kerberos client on Solaris does not understand trusts (unlike SSSD) so it will not talk to the proper KDC.
      Once you make the authentication work the password change would not work (which means you need to change the password from a Windows client or client with SSSD and not on a Solaris box). It is a known limitation but we have plans to address it on the roadmap.

      1. I am sorry, I posted the update as a new comment.

        Thanks for responding.

        Here’s an update for you.

        At this point, I am able to fetch AD user details from Solaris 10 client. I can also login to the Solaris 10 client with an IPA user. However, the login/authentication with AD user doesn’t work.

        I tried with ldap bind also, but it didn’t work… I may not have done that right, but I opened a case with Oracle and the engineer said that this is happening because AD user’s username is appearing as “username@AD Domain”, which Solaris 10 PAM modules are unable to understand. So, he suggested to look for a way to map the user name such that it appears without “@AD Domain” in the getent or ldaplist commands. I am reading the IPA documents to see if that’s possible within IPA.

        Regards,
        Mohit

  3. Hi Dmitri,

    Thanks for responding.

    Here’s an update for you.

    At this point, I am able to fetch AD user details from Solaris 10 client. I can also login to the Solaris 10 client with an IPA user. However, the login/authentication with AD user doesn’t work.

    I tried with ldap bind also, but it didn’t work… I may not have done that right, but I opened a case with Oracle and the engineer said that this is happening because AD user’s username is appearing as “username@AD Domain”, which Solaris 10 PAM modules are unable to understand. So, he suggested to look for a way to map the user name such that it appears without “@AD Domain” in the getent or ldaplist commands. I am reading the IPA documents to see if that’s possible within IPA.

    Regards,
    Mohit

  4. Hi Dmitri,

    I looked at the thread given by you and have verified that I am doing the same thing, except that I have to use “authenticationMethod=simple” instead of “authenticationMethod=tls:simple” in order for the ldap client to be able to connect to the server. However, the authentication for the AD user is still failing.

    1. At this point the best path forward is to collect the logs from server and client and share them with the freeipa-users list. People there will help you to troubleshoot the problem and find the issue.

      Thanks
      Dmitri

      1. Okay – I dug in deeper and found that there was a typo in the one of the configuration files and AD authentication worked fine after fixing it. 🙂 I have also tested the procedure on another Solaris 10 system and it worked as expected.

        So, I can provide the step-by-step procedure from beginning till end, if it is needed to be added to the “How To” section as mentioned by you earlier.

      2. Please do. You can do it if you create a fedora user account. Wiki should automatically recognize it AFAIR.

      3. Hi Dmitri,

        I was able to test IdM successfully and I also showcased that to the stakeholders; I have received a positive feedback from everywhere. However, since we are planning to integrate it to AD and the AD team is planning to implement SAML, I need to find if IdM/IPA Supports SAML. I tried searching but I didn’t find any concrete information about it. Would you be able to help in this case?

      4. Hello,

        RHEL 7.2 ships a project called Ipsilon. This is something that you can use to showcase an IdP. It is a tech preview in 7.2 and might not become fully supported because there is a much more powerful IdP called Keycloak that we are looking to integrating. As we stand now there is no supported solution but we are actively working to close this gap within several months.

        Thanks
        Dmitri

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s