Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 5. Authentication and Interoperability

Server performance has improved in many areas

Some operations in Identity Management run much faster now. For example, this enhancement enables better scalability in large deployments exceeding 50,000 users and hosts. Most notably, the improvements include:
  • Faster adding of users and hosts
  • Faster Kerberos authentication for all commands
  • Faster execution of the ipa user-find and ipa host-find commands
For information on how to reduce the time required for provisioning of a large number of entries, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#performance-tuning
Note that to make the find operations faster, the ipa *-find commands no longer show membership by default. To display the membership, add the --all option to ipa *-find or, alternatively, use the ipa *-show commands. (BZ#1298288, BZ#1271321, BZ#1268449, BZ#1346321)

Enhanced IdM topology management

Information about the Identity Management (IdM) topology is now maintained at a central location in the shared tree. As a result, you can now manage the topology from any IdM server using the command line or the web UI.
Additionally, some topology management operations have been simplified, notably:
  • Topology commands have been integrated into the IdM command-line interface, so that you can perform all replica operations using the native IdM command-line tools.
  • You can manage replication agreements in the web UI or from the command line using a new and simplified workflow.
  • The web UI includes a graph of the IdM topology, which helps visualize the current state of replica relationships.
  • IdM includes safety measures that prevent you from accidentally deleting the last certificate authority (CA) master from the topology or isolating a server from the other servers.
  • Support for server roles as a simpler way of determining which server in the topology hosts which services as well as installing these services onto a server.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#managing-topology
Note that the new functionality requires raising the domain level to 1. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#domain-level (BZ#1298848, BZ#1199516)

Simplified replica installation

Installing a replica no longer requires you to log in to the initial server, use the Directory Manager (DM) credentials, and copy the replica information file from the initial server to the replica. For example, this allows for easier provisioning using an external infrastructure management system, while retaining a reasonable level of security.
In addition, the ipa-replica-install utility can now also promote an existing client to a replica.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-replica
Note that the new functionality requires raising the domain level to 1. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#domain-level (BZ#837369)

IdM now supports smart card authentication for AD users

This update extends smart card support in Identity Management (IdM). Users from a trusted Active Directory (AD) can now authenticate using a smart card both remotely using ssh as well as locally. The following methods are supported for local authentication:
  • Text console
  • Graphical console, such as the Gnome Display Manager (GDM)
  • Local authentication services, like su or sudo
Note that IdM only supports the above-mentioned local authentication services and ssh for smart card authentication. Other services, such as FTP, are not supported.
The smart card certificate for AD users can be stored directly in AD, or in an IdM override object for the AD user.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#smart-cards (BZ#1298966, BZ#1290378)

IdM now supports TGS authorization decisions

In an Identity Management (IdM) environment, users can optionally log in using multi-factor authentication. The Kerberos ticket from the ticket granting server (TGS) now contains an indicator if two-factor authentication using a standard password in combination with a one-time password (OTP) was used. This enables the administrator to set server-side policies for resources, and the users are allowed to access based upon the type of their logins. For example, the administrator can now allow the user to log in to the desktop either using one- or two-factor authentication, but require two-factor authentication for virtual private networks (VPN) logins.
By default, all services accept all tickets. To activate this granularity, you have to manage the policies in the IdM web user interface or use the ipa service-* and ipa host-* commands. (BZ#1224057, BZ#1340304, BZ#1292153)

sssd now provides optional two-factor authentication

The System Security Services Daemon (SSSD) now allows users with two-factor authentication enabled to authenticate to services either by using a standard password and a one-time password (OTP), or using only a standard password. Optional two-factor authentication enables administrators to configure local logins using a single factor, while other services, like access to VPN gateways, can request both factors. As a result, during the login, the user can enter either both factors, or optionally only the password. The Kerberos ticket then uses authentication indicators to list the used factors. (BZ#1325809)

New SSSD control and status utility

The sssctl utility provides a simple and unified way to obtain information about the System Security Services Daemon's (SSSD) status. For example, you can query status information about active server, auto-discovered servers, domains, and cached objects. Additionally, the sssctl utility enables you to manage SSSD data files to troubleshoot SSSD in a safe way while the service is running.
The options supported by sssctl include client-data-backup and cache-remove to back up and remove the SSSD cache. Previously, when it was necessary to start SSSD without any cached data, the administrator had to remove the cache files manually.
For more information about the features the utility provides, run sssctl --help.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#sssctl (BZ#879333)

SSSD configuration file validation

Previously, the System Security Services Daemon (SSSD) did not provide a tool to manually check the /etc/sssd/sssd.conf file. As a consequence, the administrator had to find the problem in the configuration file if the service failed to start. This update provides the config-check option of the sssctl command to locate problems in the configuration file. Additionally, SSSD automatically checks the validity of the configuration file after the service starts, and shows level 0 debug messages for incorrect settings. (BZ#988207, BZ#1072458)

The pki cert-find command now supports revocation strings

The pki cert-find command has been enhanced and now supports revocation reasons in string format. As a result, you can pass strings, such as Key_compromise, to the --revocationReason option, instead of the corresponding numeric values. For the list of supported revocation strings, see 
# pki cert-find --help
(BZ#1224365)

IdM now supports setting individual Directory Server options during server or replica installation

The Identity Management (IdM) ipa-server-install and ipa-replica-install commands have been enhanced. The new --dirsrv-config-file parameter enables the administrator to change default Directory Server settings used during and after the IdM installation. For example, to disable secure LDAP binds in the mentioned situation:
Create a text file with the setting in LDIF format: 
dn: cn=config
changetype: modify
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: off
Start the IdM server installation by passing the --dirsrv-config-file parameter and file to the installation script: 
# ipa-server-install --dirsrv-config-file filename.ldif
(BZ#825391)

IdM now enables the admin group and ipaservers host group

Identity Management (IdM) now introduces two new groups:
  • User group admins - Members have full administrative permissions in IdM.
  • Host group ipaservers - Hosts in this group can be promoted to a replica by users without full administrative permissions. All IdM servers are members of this group. (BZ#1211595)

IdM now supports OTP generation in the Web UI

Identity Management (IdM) now supports one-time password (OTP) generation when adding a host in the Web UI. Select the Generate OTP check box in the Add host dialog. After adding the host, a window displays the generated OTP. You can use this password to join the host to the domain. This procedure simplifies the process and provides a strong OTP. To override the OTP, navigate to the host's details page, click, Action and select Reset One-Time-Password. (BZ#1146860)

New sss_cache option to mark sudo rules as expired

This update enhances the sss_cache command from the System Security Services Daemon (SSSD). The options -r and -R have been added to mark one or all sudo rules as expired. This enables the administrator to force a refresh of new rules on the next sudo lookup. Please note that the sudo rules are refreshed using a different algorithm than the user and group entities. For more information about the mechanism, see the sssd-sudo(5) man page. (BZ#1031074)

New packages: custodia, python-jwcrypto

This update adds the custodia packages and their dependency python-jwcrypto to Red Hat Enterprise Linux 7.
Custodia is an HTTP-based pipeline to request and distribute secrets. It handles the authentication, authorization, request handling, and storage stages of secrets management. Custodia is currently only supported as an internal subsystem of Red Hat Identity Management.
The package python-jwcrypto is an implementation of the JavaScript object signing and encryption (JOSE) web standards in Python. It is installed as a dependency of Custodia. (BZ#1206288)

New package: python-gssapi

This update adds the python-gssapi package to Red Hat Enterprise Linux 7. It provides a generic security services API (GSSAPI) that is compatible with Python 2 and 3. Identity Management (IdM) uses the package as a replacement for python-krbV and python-pykerberos, which only support Python 2 (BZ#1292139)

New package: python-netifaces

This update adds the python-netifaces package to Red Hat Enterprise Linux 7. This Python module makes it possible to read information about the system network interfaces from the operating system. It has been added as a dependency for Red Hat Identity Management (IdM). (BZ#1303046)

New package: mod_auth_openidc

This update adds the mod_auth_openidc package to Red Hat Enterprise Linux 7. It enables the Apache HTTP server to act as an OpenID Connect Relying Party for single sign-on (SSO) or as an OAuth 2.0 Resource Server. Web applications can use the module to interact with a variety of OpenID Connect server implementations including the Keycloak open source project and Red Hat Single Sign-On (SSO) products. (BZ#1292561)

IdM now supports DNS locations

This update adds support for DNS location management to the Identity Management (IdM) integrated DNS server to improve cross-site implementations. Previously, clients using DNS records to locate IdM servers could not distinguish local servers from servers located in remote geographical locations. This update enables clients using DNS discovery to find the nearest servers, and to use the network in an optimized way. As a result, administrators can manage DNS locations and assign servers to them in the IdM web user interface and from the command line.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#dns-locations (BZ#747612)

IdM now supports establishing an external trust to an AD domain

Red Hat Enterprise Linux Identity Management (IdM) now supports establishing an external trust to an Active Directory (AD) domain in a forest. An external trust is non-transitive and can be established to any domain in an AD forest. This allows to limit a trusted relationship to a specific domain rather than trusting the whole AD forest. (BZ#1314786)

IdM now supports logging in with alternative UPNs

In an Active Directory (AD) forest, it is possible to associate a different user principal name (UPN) suffix with the user name instead of the default domain name. Identity Management (IdM) now allows users from a trusted AD forest to log on with an alternative UPN.
Additionally, the System Security Services Daemon (SSSD) now detects whether the IdM server supports alternative UPNs. If they are supported, SSSD activates this feature automatically on the client.
When you add or remove UPN suffixes in a trusted AD forest, run ipa trust-fetch-domains on an IdM master to refresh the information for the trusted forest in the IdM database.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#UPN-in-a-trust (BZ#1287194, BZ#1211631)

IdM now supports sub-CAs

Previously, Identity Management (IdM) only supported one certificate authority (CA) that was used to sign all certificates issued within the IdM domain. Now, you can use lightweight sub-CAs for better control over the purpose for which a certificate can be used. For example, a Virtual Private Network (VPN) server can be configured to only accept certificates issued by a sub-CA created for that purpose, rejecting certificates issued by other sub-CAs, such as a smart card CA.
To support this functionality, you can now specify an IdM lightweight sub-CA when requesting a certificate with certmonger.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#lightweight-sub-cas (BZ#1200731, BZ#1345755)

SSSD now supports automatic Kerberos host keytab renewal

Previously, the System Security Services Daemon (SSSD) did not support the automatic renewal of Kerberos host keytab files in an Active Directory (AD). In environments that, for security reasons, do not allow using passwords that never expire, the files had to be manually renewed. With this update, SSSD is able to automatically renew Kerberos host keytab files.
SSSD checks once per day if the machine account password is older than the configured number of days in the ad_maximum_machine_account_password_age parameter of the /etc/sssd/sssd.conf file.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#sssd-auto-keytab-renewal (BZ#1310877)

IdM supports user principal aliases

Previously, Identity Management (IdM) supported only the authentication using the user name. However, in some environments it is a requirement to authenticate with an email address or alias name. IdM has been enhanced and now supports principal aliases. The System Security Services Daemon (SSSD) has also been updated to support this functionality.
To add the aliases ualias and user@example.com to the account user, run the following command: 
# ipa user-add-principal user ualias user\\@example.com
Use the -C option to the kinit command when with an alias, and the -E option when using an enterprise principal name: 
# kinit -C ualias
# kinit -E user@example.com
(BZ#1328552, BZ#1309745)

SSSD cache update performance improvement

Previously, the System Security Services Daemon (SSSD) always updated all cached entries after the cache validity timeout passed. This consumed unnecessarily resources on the client and the server, for entries that have not been changed. SSSD has been enhanced and now checks if the cached entry requires an update. The time stamp values are increased for unchanged entries and stored in the new SSSD database /var/lib/sss/db/timestamps_$domain.ldb. This enhancement improves the performance for entries that rarely change on the server side, such as groups. (BZ#1290380)

SSSD now supports sudo rules stored in the IdM schema

Previously, the System Security Services Daemon (SSSD) used the ou=sudoers container, generated by the compatibility plug-in, to fetch sudo rules. SSSD has been enhanced to support sudo rules in the cn=sudo container that are stored in the Identity Management (IdM) directory schema.
To enable this feature, unset the ldap_sudo_search_base parameter in the /etc/sssd/sssd.conf file. (BZ#789477)

SSSD now automatically adjusts the ID ranges for AD clients in environments with high RID numbers

The automatic ID mapping mechanism included in the System Security Services Daemon (SSSD) service is now able to merge ID range domains. The SSSD default size of ID ranges is 200,000. In large Active Directory (AD) installations, the administrator had to manually adjust the ID range assigned by SSSD if the Active Directory relative ID (RID) increased 200,000 to correspond with the RID.
With this enhancement, for AD clients having ID mapping enabled, SSSD automatically adjusts the ID ranges in the described situation. As a result, the administrator does not have to adjust the ID range manually, and the default ID mapping mechanism works in large AD installations. (BZ#1059972)

New sssctl option remove-cache

This update adds the remove-cache option to the sssctl utility. The option removes the local System Security Services Daemon's (SSSD) database contents, and restarts the sssd service. This enables the administrator to start from a clean state with SSSD and avoid the need to manually remove cache files. (BZ#1007969)

Password changes on legacy IdM clients

Previously, Red Hat Enterprise Linux contained a version of slapi-nis that does not enable user to change their passwords on legacy Identity Management (IdM) clients. As a consequence, users logged in to clients via the slapi-nis compatibility tree could only update their password using the IdM web UI or directly in Active Directory (AD). A patch has been applied to and as a result, users are now able to change their password on legacy IdM clients. (BZ#1084018)

The ldapsearch command can now return all operational attributes

LDAP searches can now return all operational attributes as described in IETF RFC 3673. Using the + character in a search will yield all operational attributes to which the bound Distinguished Name (DN) has access. The returned results may be limited depending on applicable Access Control Instructions (ACIs).
An example search might look similar to the following: 
ldapsearch -LLLx -h localhost -p 10002 -b ou=people,dc=example,dc=com -s base '+'
dn: ou=People,dc=example,dc=com
See https://tools.ietf.org/html/rfc3673 for additional information about this feature. (BZ#1290111)

Increased accuracy of log time stamps

This update increases the accuracy of time stamps in Directory Server logs from one second precision to nanosecond precision by default. This enhancement allows for a more detailed analysis of events in Directory Server, and enables external log systems to correctly rebuild and interweave logs from Directory Server.
Previously, log entries contained time stamps as shown in the following example: 
[21/Mar/2016:12:00:59 +1000] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3
With this update, the same log entry contains a more accurate time stamp: 
[21/Mar/2016:12:00:59.061886080 +1000] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3
To revert to the old time stamp format, set the nsslapd-logging-hr-timestamps-enabled attribute to false in cn=config. (BZ#1273549)

Changing a user password now always updates the shadowLastChange attribute

Previously, some ways of changing a user's password could update the passwordExpirationTime attribute but not the shadowLastChange attribute. Some systems which can interface with Directory Server, such as Active Directory, expect both attributes to be updated, and therefore this behavior could lead to synchronization errors. With this update, any change to a user password updates both attributes, and synchronization problems no longer occur. (BZ#1018944)

ns-slapd now logs failed operations in the audit log

Previously, ns-slapd only logged successful changes to the directory. This update adds support for also logging failed changes, their contents, and the reason for the failure. This allows for easier debugging of applications failing to alter directory content as well as detecting possible attacks. (BZ#1209094)

New utility for displaying status of Directory Server instances

Directory Server now provides the status-dirsrv command line utility, which outputs the status of one or all instances. Use the following command to obtain a list of all existing instances: 
status-dirsrv
To display the status of a specific instance, append the instance name to the command. See the status-dirsrv(8) man page for additional details and a list of return codes. (BZ#1209128)

IdM now supports up to 60 replicas

Previously, Identity Management (IdM) supported up to 20 replicas per IdM domain. This update increases the support limit to 60 replicas per IdM domain.
For detailed replica topology recommendations, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replica-considerations.html#replica-topology-recommendations (BZ#1274524)

SSSD now reads optional *.conf files from /etc/sssd/conf.d/

The System Security Services Daemon (SSSD) has been enhanced to read *.conf files from the /etc/sssd/conf.d/ directory. This enables you to use a general /etc/sssd/sssd.conf file on all clients and to add additional settings in further configuration files to suit individual clients. SSSD first reads the common /etc/sssd/sssd.conf file, and then in alphabetical order the other files in /etc/sssd/conf.d/. The daemon uses the last read configuration parameter if the same one appears multiple times in different files. (BZ#790113)

New option to enable use of quotes in schema

This update introduces the LDAP_SCHEMA_ALLOW_QUOTED environment variable which adds support for older style schema using quotes in the schema directory. To enable this functionality, set the following variable in the /etc/sysconfig/dirsrv-INSTANCE configuration file: 
LDAP_SCHEMA_ALLOW_QUOTED=on
(BZ#1368484)

OpenLDAP now supports SHA2 password hashes

The OpenLDAP server in Red Hat Enterprise Linux 7.3 now provides a module for SHA2 support. To load the pw-sha2 module, add the following line to your /etc/openldap/slapd.conf file: moduleload pw-sha2
As a result, you can store passwords in OpenLDAP using the following hashes:
  • SSHA-512
  • SSHA-384
  • SSHA-256
  • SHA-512
  • SHA-384
  • SHA-256 (BZ#1292568)

The pki cert-request-find command now displays the serial number for completed revocation requests

With this update, the pki subcommand cert-request-find now displays the certificate ID of revoked certificates for completed revocation requests. (BZ#1224642)

The IdM password policy now enables never-expiring passwords

Previously, all user passwords in Identity Management (IdM) were required to have an expiration date defined. With this update, the administrator can configure user passwords to be valid indefinitely by setting the password policy Max lifetime value to 0.
Note that new password policy settings apply to new passwords only. For the change to take effect, existing users must update their passwords. (BZ#826790)

ipa-getkeytab can now automatically detect the IdM server

When running the ipa-getkeytab utility on an Identity Management (IdM) server, you are no longer required to specify the server name using the -s option. The ipa-getkeytab utility detects the IdM server automatically in this situation. (BZ#768316)

Enhanced sub-commands in the ipa-replica-manage utility

The ipa-replica-manage utility has been enhanced and now additionally supports the o=ipaca back end in the following sub-commands:
  • list-ruv
  • clean-ruv
  • abort-clean-ruv
Additionally, the clean-dangling-ruv sub-command has been added to the ipa-replica-manage utility. This enables the administrator to automatically remove dangling replica update vectors (RUV). (BZ#1212713)

samba rebased to version 4.4.4

The samba packages have been upgraded to upstream version 4.4.4, which provides a number of bug fixes and enhancements over the previous version:
  • The WINS nsswitch module now uses the libwbclient library for WINS queries. Note that the winbind daemon must be running to resolve WINS names that use the module.
  • The default value of the winbind expand groups option has been changed from 1 to 0.
  • The -u and -g options of the smbget command have been replaced with the -U option to match other Samba command's parameter. The -U option accepts a username[%password] value. Additionally, the username and password parameters in the smbgetrc configuration file have been replaced with the user parameter.
  • The -P parameter of the smbget command has been removed.
  • Printing using the CUPS back end with Kerberos credentials now requires to install the samba-krb5-printing package and to configure CUPS appropriately.
  • It is now possible to configure Samba as a print server by using the CUPS back end with Kerberos credentials. To do so, install the samba-krb5-printing package and configure CUPS appropriately.
  • Samba and CTDB header files are no longer installed automatically when you install samba.
Samba automatically updates its tdb database files when the smbd, nmbd, or winbind daemon starts. Back up the databases files before starting Samba. Note that Red Hat does not support downgrading tdb database files.
Note that using the Linux kernel CIFS module with SMB protocol 3.1.1 is currently experimental and the functionality is unavailable in kernels provided by Red Hat.
For further information about notable changes, read the upstream release notes before updating:

New net ads join option to prevent AD DNS update

The net ads join command now provides the --no-dns-updates option that prevents updating the DNS server with the machine name when joining a client to the Active Directory (AD). This option enables the administrator to bypass the DNS registration if the DNS server does not allow client updates and thus the DNS update would fail with an error message. (BZ#1263322)

New realm join option to set NetBIOS name

The realm join command now provides the --computer-name option to set an individual NetBIOS name. This enables the administrator to join a machine to a domain using a different name than the host name. (BZ#1293390)

DRMTool renamed to KRATool

The Data Recovery Manager (DRM) component of Certificate System (CS) is now called Key Recovery Authority (KRA). For consistency with this change, this update renames the DRMTool utility to KRATool. Note that to ease the transition, compatibility symbolic links are provided. The links help ensure that, for example, scripts referencing DRMTool continue working. (BZ#1305622)

Explicit dependency on OpenJDK 1.8.0

The current PKI code has only been verified to work with OpenJDK 1.8.0. Previously, PKI depended on a generic java link provided by alternatives and assumed that the link would point to OpenJDK 1.8.0. Since the alternatives settings could change for various reasons, it could cause some problems to PKI.
To ensure that PKI always works properly, PKI has been changed to depend more specifically on jre_1.8.0_openjdk link which will always point to the latest update of OpenJDK 1.8.0 regardless of other Java installation. (BZ#1347466)

The ipa *-find commands no longer display member entries

The new default setting in Identity Management (IdM) ipa *-find commands no longer displays member entries, such as for host groups. Resolving a large number of member entries is resource intensive and the output of the commands can get long and unreadable. As a result, the default was changed. To display members entries, use the --all option to the ipa *-find command. For example: 
# ipa hostgroup-find --all
(BZ#1354626)

Certificate System now supports setting a start ID for CRL

The Red Hat Certificate System now supports setting a start ID for certificate revocation lists (CRL) using the pki_ca_starting_crl_number option in the /etc/pki/default.cfg file. This enables administrators to migrate certificate authorities (CA) which already have CRLs issued to the Certificate System. (BZ#1358439)

New pki-server subcommand to add the issuer DN to a certificate

An enhancement in the Certificate Server now stores the issuer DN in new certificate records and the REST API certificate search enables support for filtering certificates by the issuer DN. To add the issuer DN to existing certificate records, run: 
# pki-server db-upgrade
(BZ#1305992)

Certificate System now removes old CRLs

Previously, if the file based certificate revocation list (CRL) publishing feature was enabled in the Certificate System, the service regularly created new CRL files without removing old ones. As a consequence, the system running Certificate System could eventually run out of space. To address the problem, two new configuration options were added to the /etc/pki/pki-tomcat/ca/CS.cfg file:
  • maxAge - Sets the number of days after which files expire and be purged. Default is 0 (never).
  • maxFullCRLs - Sets the maximum number of CRLs to keep. When new files are published, the oldest file is purged. Default is 0 (no limit).
As a result, you can now configure how the Certificate System handles old CRL files. (BZ#1327683)

Specifying certificate nick names in pkispawn configuration for cloning

During clone installation, the clone imports the system certificates from the PKCS #12 file specified in the pki_clone_pkcs12_path parameter in the pkispawn configuration file. Previously, it was not necessary to specify the nick names of the certificates in the PKCS #12 file.
Due to new IPA requirements, the certificate import mechanism had to be changed. With this update, to ensure that the certificates are imported with the proper trust attributes, the nick names of the CA signing certificate and the audit signing certificate in the PKCS #12 file have to be specified in the following parameters:
  • pki_ca_signing_nickname
  • pki_audit_signing_nickname (BZ#1321491)

Deploying the Certificate System using an existing CA certificate and key

Previously, the Certificate System generated the key for the certificate authority (CA) certificate internally. With this update, the key generation is optional and the Certificate System now supports reusing an existing CA certificate and key which can be provided by using a PKCS#12 file or a hardware security module (HSM). This mechanism enables the administrator to migrate from an existing CA to the Certificate System. (BZ#1289323)

Separate cipher lists for instances acting as a client

Prior to this feature, the cipher list specified in the server.xml file was used when a Certificate System instance was acting as a server as well as a client. In some cases, certain ciphers could be not desired or did not work. This update gives administrators tighter control as it allows the administrator to specify an allowed list of SSL ciphers when the server is acting as a client for communication between two Certificate System subsystems. This cipher list is separate from the one stored on the server. (BZ#1302136)

Support for PKCS #7 certificate chains with the BEGIN/END PKCS7 label

To comply with RFC 7468, PKI tools now accept and generate PKCS #7 certificate chains with the BEGIN/END PKCS7 label instead of the BEGIN/END CERTIFICATE CHAIN label. (BZ#1353005)

krb5 rebased to version 1.14.1

The krb5 packages have been updated to upstream version 1.14.1, which provides a number of enhancements, new features, and bug fixes. Notably, it implements authentication indicators support to increase security. For further details, see http://web.mit.edu/kerberos/krb5-latest/doc/admin/auth_indicator.html (BZ#1292153)

The Kerberos client now supports configuration snippets

The /etc/krb5.conf file now loads configuration snippets from the /etc/krb5.conf.d/ directory. This enables compliance with existing distribution configuration standards and crypto policies management. As a result, users can now split configuration files and store the snippets in the /etc/krb5.conf.d/ directory. (BZ#1146945)

IdM rebased to version 4.4.0

The ipa* packages have been upgraded to upstream version 4.4.0, which provide a number of bug fixes and enhancements over the previous version:
  • Improved Identity Management (IdM) server performance, such as faster provisioning, Kerberos authentication, and user and group operations with many members.
  • DNS locations to enable clients in a branch office to contact only local servers with the possibility to fall back to remote servers.
  • Central replication topology management.
  • The number of supported replication partners has been increased from 20 to 60 replicas.
  • Authentication indicator support for one-time passwords (OTP) and RADIUS. Authentication indicators can be enabled for hosts and services individually.
  • Sub-CA support enables the administrator to create individual certificate authorities to issue certificates for specific services.
  • Enhanced smart card support for Active Directory (AD) users enables the administrator to store smart card certificates in AD or IdM overrides.
  • IdM server API versioning.
  • Support for establishing external trusts with AD.
  • Alternative AD user principal names (UPN) suffixes. (BZ#1292141)

SSSD now enables fetching autofs maps from an AD server

You can now use the autofs_provider=ad setting in the [domain] section of the /etc/sssd/sssd.conf file. With this setting, the System Security Services Daemon (SSSD) fetches autofs maps from an Active Directory (AD) server.
Previously, when it was required to store autofs maps in AD, the AD server administrator had to use the autofs_provider=ldap setting and manually configure the LDAP provider, including the bind method, search base, and other parameters. With this update, it is only required to set autofs_provider=ad in sssd.conf.
Note that SSSD expects the autofs maps stored in AD to follow the format defined in RFC2307: https://tools.ietf.org/html/rfc2307 (BZ#874985)

The dyndns_server option enables specifying the DNS server to receive dynamic DNS updates

The System Security Services Daemon (SSSD) now supports the dyndns_server option in the /etc/sssd/sssd.conf file. The option specifies the DNS server that is automatically updated with DNS records when the dyndns_update option is enabled.
The option is useful, for example, in environments where the DNS server is different from the identity server. In such cases, you can use dyndnds_server to enable SSSD to update the DNS records on the specified DNS server. (BZ#1140022)

SSSD now supports using full_name_format=%1$s to set the output name of AD trusted users to a shortname

Previously, in trust setups, certain System Security Services Daemon (SSSD) features required using the default value for the full_name_format option in the /etc/sssd/sssd.conf file. Using full_name_format=%1$s to set the output format of trusted Active Directory (AD) users to a shortname broke other functionality.
This update decouples the internal representation of a user name from the output format. You can now use full_name_format=%1$s without breaking other SSSD functionality.
Note that the input name must still be qualified, except for when the default_domain_suffix option is used in sssd.conf. (BZ#1287209)

Documentation now describes configuration and limitations of IdM clients using an AD DNS host name

The Identity Management (IdM) documentation has been enhanced and now describes the configuration of IdM clients located in the DNS name space of a trusted Active Directory (AD) domain. Note that this is not a recommended configuration and has some limitations. For example, only password authentication is available to access these clients instead of single sign-on. Red Hat recommends to always deploy IdM clients in a DNS zone different from the ones owned by AD and access IdM clients through their IdM host names.
For detailed information, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ipa-in-ad-dns.html. (BZ#1320838)

Certificate System now supports setting SSL ciphers for individual installation

Previously, if an existing Certificate Server had customized cipher set that did not overlap with the default ciphers used during the installation, a new instance could not be installed to work with existing instances. With this update, Certificate System enables you to customize the SSL cipher using a two-step installation, which avoids this problem. To set the ciphers during a Certificate System instance installation:
1. Prepare a deployment configuration file that includes the pki_skip_configuration=True option.
2. Pass the deployment configuration file to the pkispawn command to start the initial part of the installation.
3. Set the ciphers in the sslRangeCiphers option in the /var/lib/pki/<instance>/conf/server.xml file.
4. Replace the pki_skip_configuration=True option with pki_skip_installation=True in the deployment configuration file.
5. Run the same pkispawn command to complete the installation. (BZ#1303175)

New attribute for configuring replica release timeout

In a multi-master replication environment where multiple masters receive updates at the same time, it was previously possible for a single master to obtain exclusive access to a replica and hold it for a very long time due to problems such as a slow network connection. During this time, other masters were blocked from accessing the same replica, which considerably slowed down the replication process.
This update adds a new configuration attribute, nsds5ReplicaReleaseTimeout, which can be used to specify a timeout in seconds. After the specified timeout period passes, the master releases the replica, allowing other masters to access it and send their updates. (BZ#1349571)