Testing New Features of Identity Management In RHEL-7.0

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 7.0 Beta
  • Red Hat Enterprise Linux (RHEL) 7.0
  • Identity Management / IPA
  • SSSD

Issue

What are the new main features introduced in RHEL 7.0? How to test them and provide feedback for the Engineering team? This solution is targeted but not limited to RHEL-7.0 Beta customers.

Resolution

Introduction

Feedback from a real-life IdM customer deployment is a very important input in finalizing Identity Management release for new RHEL 7.0. It gives the Engineering team ability to fix issues even before they hit customer environment, provide better default configuration or do final changes based on the customer feedback.

This article lists the new major features in Identity Management available in RHEL 7.0, provides basic information about them and contains links to guides for testing. Features are divided per main components of the Identity Management solution.

Identity Management / IPA

Using POSIX attributes Defined In Active Directory

Starting with Identity Management of version 3.3, it is possible to define identity ranges for a trusted Active Directory domain that rely on POSIX attributes provided by AD DC instead of generating them out of corresponding security identifiers (feature design). This functionality requires Services for Unix (SFU) (also named Identity Management for UNIX) enabled on Active Directory side and is provided mostly to aid with migration to SID-based mapping.

In order to support externally defined POSIX attributes, identity ranges have been extended to support new range types:

  • AD trust with SID-based mapping: 'ipa-ad-trust' (default)
  • SFU support: 'ipa-ad-trust-posix'

ipa-ad-trust-posix range type is activated when range discovery finds out SFU is in use by Active Directory domain. To override automatic detection, --range-type=ipa-ad-trust can be specified to ipa trust-add command.

Official documentation: Configuring an Active Directory Domain with POSIX Attributes
Testing instructions: Fedora 19 Test Day page

Support of subdomains in AD or Identity Management

Identity Management Servers prior to version 3.2.0 did not have an interface to publish list of domains managed by it. Thus, Active Directory could not route authentication requests to non-default domains to the IdM Server. Similarly, IdM Server did not manage a list of Active Directory sub-domains and thus could not route authentication requests to the right Active Directory.

In RHEL-7, both parts are addressed:

  • IdM Server sub-domains are now managed in a new realmdomains entry, by using CLI commands (realmdomains-show or realmdomains-mod) or Web UI page.
  • Active Directory sub-domains are now retrieved in the time of a trust creation. The list can be refreshed with trust-fetch-domains command. Particular AD sub-domains can be managed by trustdomain-* commands, see ipa help trust the entire list.

Official documentation: Discovering, Enabling, and Disabling Trust Domains, Viewing and Managing DNS Realms
Testing instructions: Fedora 19 Test Day page

Serving AD Integration for Legacy Clients

Identity Management 3.3 also provides a new way to enable legacy clients (e.g. RHEL 5 machines) to support trusted domain users. A compatibility tree, provided by slapi-nis, can now be configured to look up trusted domain users and handle authentication for them. This functionality relies on SSSD 1.11 and release 0.47.7 of slapi-nis. One can enable legacy clients support by running ipa-adtrust-install and answering positively to the corresponding question (upstream design).

For easier configuration of the legacy clients, Identity Management server introduced a new framework to generate recipes of configuration based on how Identity Management server is configured (upstream design). These recipes can be taken to the target client systems and used there to configure them for a specific task.

We expect to expand use of 'ipa-advise' tool to cover at least configuration of legacy systems in subsequent releases. Identity Management in RHEL 7.0 contains following advices:

  • configuring a generic Fedora release with authconfig, nss-pam-ldapd or nss-ldap
  • configuring a FreeBSD release with nss-pam-ldapd
  • configuring RHEL-based systems with SSSD 1.5-1.8

Official documentation: Active Directory Trust for Legacy Linux Clients
Testing instructions based on Fedora 19 Test Day pages:

  1. Establish trust with an AD server
  2. Configure a generic legacy client for accessing trusted resources
  3. Use nss-pam-ldapd to give access to trusted domain users
  4. Use legacy SSSD to give access to trusted domain users

Add Selected Kerberos Flags for Host or Service Principals

In RHEL 7.0, service or host principals can have assigned OK_AS_DELEGATE or REQUIRES_PRE_AUTH flags. Both flags can be assigned with service-mod/host-mod --ok-as-delegate=1 or --requires-pre-auth=1 respectively.

Official documentation: Kerberos Flags for Services and Hosts
Testing instructions: Fedora 19 Test Day page

CA-less Identity Management Server

Identity Management Servers prior to version 3.2.0 could be installed with --selfsign option. This configured the server with a NSS database based Certificate Authority with a selfsigned CA certificate and limited certificate operation support.

This option was always intended for development or testing purposes only and was not intended for use in production. In RHEL 7.0, this option is dropped and functionality is deprecated. Identity Management Servers installed with the --selfsign option will be converted to (CA-less. See upstream documentation for more information and instructions for manual certificate management.

Identity Management Servers version 3.2.0 and later supports the following 2 flavors of certificate management:

  • Identity Management with PKI server (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option)
  • CA-less configuration with no PKI Server installed with certificates signed and provided by an external CA (upstream design)

Official documentation: Installing with Different CA Configurations
Testing instructions: Fedora 19 Test Day page

Search Certificates from CLI or Web UI

Identity Management Server prior to version 3.2.0 could not search in certificates signed and published by IdM PKI Server, it only offered an API to display a certificate for selected service or host. In RHEL 7.0, a new CLI command cert-find and a Web UI page is introduced to provide that capability.

Official Documentation: Showing Certificates
Testing instructions: Fedora 19 Test Day page

Dropped CSV Support

Identity Management CLI supported CSV in some arguments so that multiple values could be added with just one convenient option:

ipa permission-add some-perm --permissions=read,write --attrs=sn,cn
ipa dnsrecord-add example.com --a-rec=10.0.0.1,10.0.0.2

CSV parsing however introduces great difficulty when trying to include a value with an embedded space in it. Escaping these values is not intuitive and made it very difficult to add such values. The level of effort in working around the CSV problems has come to the point where the benefits of it are outweighed by the problems which lead to decision to drop CSV support in CLI altogether [10].

There are several ways to workaround lack of CSV:

  • Provide an argument multiple times on the command-line:

      ipa permission-add some-perm --permissions=read --permissions=write --attrs=sn --attrs=cn
      ipa dnsrecord-add example.com --a-rec=10.0.0.1 --a-rec=10.0.0.2
    
  • Let BASH do the expansion for you:

    ipa permission-add some-perm --permissions={read,write} --attrs={sn,cn}
    ipa dnsrecord-add example.com --a-rec={10.0.0.1,10.0.0.2} 
    

Experimental Backup and Restore Scripts

RHEL 7.0 Beta Identity Management release contains experimental Backup (ipa-backup) and restore (ipa-restore) scripts for customer testing. They are planed to be removed in a GA version of the IdM Server with following justification:

  • Backup and Restore scripts are not mature and stable enough to be run in production
  • IdM Engineering Team does not believe that backup and restore using these scripts is the best way to do backup and restore of an IdM server.

There is a separate KB article explaining all the options for different backup and restore scenarios. IdM Engineering Team is eager to learn customer's opinion and reasoning on this matter. If there is a common agreement that these scripts is the best approach to go forward instead of the proposed approaches, they may be included in a future version of Red Hat Enterprise Linux.

Dedicated KB Article: 626303
Testing instructions: Fedora 19 Test Day page, ipa-backup and ipa-restore man pages

Resolving user names from AD

An external group member is currently a Security Identifier (SID) as defined by the trusted domain. When adding external group members, it is possible to specify them in either SID, or DOM\name, or name@domain format. IdM will attempt to resolve passed name to SID with the use of Global Catalog of the trusted domain.

External group member Web UI page automatically resolves SIDs to names, making the page more user friendly.

SID can be also resolved by trust-resolve CLI command.

SSSD

This section only lists SSSD features that are testable with a standalone client instance. Some 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.

Dynamic DNS updates

Clients enrolled to an Active Directory domain and using the ad id_provider may be allowed to update their DNS records stored in AD dynamically. At the same time, Active Directory servers support DNS aging and scavenging, which means that stale DNS records might be removed from AD after a period of inactivity.

The AD provider supports both scenarios described above by default. The AD provider will attempt to update the DNS record every time the AD provider goes online (typically after startup) and periodically every 24 hours to keep the records from being scavenged. The DNS updates are enabled by default.

Official documentation: Enabling Dynamic DNS Updates, Enabling Dynamic DNS Updates (Active Directory Only)
Testing instructions: Fedora 19 test day page, sssd-ad man page

Dynamic NetBIOS name discovery

When referring to a user from an Active Directory domain, typically the domain is part of the identifier.

In contrast to UNIX users that are normally just referred to with the username:

id root

The AD users can be referred to either by fully qualifiying the name with the AD domain:

id Administrator@ad.example.com

Or just using the NetBIOS name of the AD domain:

id AD\\Administrator

In most deployments, the NetBIOS name is just the first part of the full domain name, but not always. The NetBIOS name can be customized on the AD side by the administrator.

The AD provider of SSSD is able to recognize both formats and autodetect the right NetBIOS name as well.

Official documentation: Supported Username Formats, Setting Username Formats
Testing instructions: Fedora 19 test day page

DNS site discovery

Large Active Directory environments often span across multiple locations in multiple geographies. In Active Directory, these physical locations are represented as sites.

Each client belongs to a site based on the network subnet it resides in. For best performance, it is important that the clients are able to find the closest site and use the other domain controllers only as a fallback. The support for discovering the closes site was is enabled by default.

Official documentation: Linux Clients and Active Directory DNS Sites
Testing instructions: Fedora 19 test day page, sssd-ad man page

Support for trusted domains in the same forest

Starting with RHEL7, the SSSD is able to dynamically find the trusted domains in the same forest and provide both authentication and identity information for users coming from the trusted domains. The SSSD retrieves identity information from the Global Catalog, so it's important that the users and all needed attributes are replicated to the Global Catalog. This includes even POSIX attributes such as home directory, login shell and most importantly UIDs and GIDs if not using ID mapping.

In case the Global Catalog is not configured or available, or in case the POSIX attributes are not replicated to the Global Catalog, the SSSD is able to fall back to LDAP searches, but for users from the primary domain only.

With RHEL-7, a properly configured AD provider would be able to resolve users from the primary domain:

id Administrator@ad.example.com

As well as a trusted domain:

id Administrator@trusted.ad.example.com

Similarly, group lookups would report members from both primary and any of trusted domains.

Please note that as of RHEL7 Beta, there is a bug that prevents all groups from being reported correctly in case the user being requested is from a different domain that the Global Catalog the client is connected to.

A simplified LDAP access control mechanism

Starting with RHEL-7, there is a simplified way to express the access control using an LDAP filter with the AD backend. The administrator can now only specify access_provider=ad and then use the access filter with an option aptly called ad_access_filter. The following example illustrates restricting access to users whose name begins with 'jo' and have a valid home directory attribute:

access_provider = ad
ad_access_filter = (&(sAMAccountName=jo*)(unixHomeDirectory=*))

In addition to checking whether the user matches the filter, the AD access filter also checks the account validity. Expired accounts are not permitted even if they matched the filter.

Previously, the administrator had to configure the LDAP access filter and specify all the options manually. The example used above would the look much more involved:

access_provider = ldap
ldap_access_order = filter, expire
ldap_account_expire_policy = ad
ldap_access_filter = (&(sAMAccountName=jo*)(unixHomeDirectory=*))
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = CLIENT_SHORTNAME$@EXAMPLE.COM
ldap_schema = ad

Still, for most deployments, the simple access provider is the best choice for the ease of configuration, especially when it comes to nested group membership.

Official documentation: Using a Filter with Access Controls

Support for Enterprise logins

Some users in AD might use a different UPN suffix than the default one. This feature is often called "Enterprise principals" or "Enterprise logins". Starting with RHEL-7, the SSSD is able to canonicalize the principals and allow users with a custom UPN suffix to log in without any customization. This feature is available by default.

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.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.