Red Hat Training

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

Chapter 51. Authentication and Interoperability

Problem with importing a user certificate from CA over SSL

The pki user-cert-add command provides an option to import a user certificate directly from CA. Due to incorrect client library initialization, when the command is executed over an SSL port, the command fails with the following error message: 
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
To work around this problem, download the certificate from CA into a file using the pki cert-show command. Then, upload the certificate from the file using the pki user-cert-add command. With the workaround, the user certificate is added correctly. (BZ#1246635)

The IdM web UI displays all certificates on one page in the Certificates table

The Certificates table, available under the Authentication tab in the Identity Management (IdM) web UI, ignores the page size limit of 20 entries. When more than 20 certificates are available, the table displays all the certificates on one page, instead of only displaying 20 certificates per page. (BZ#1358836)

Security warning when using ipa-kra-install, ipa-ca-install, or ipa-replica-install

When using the ipa-kra-install, ipa-ca-install, and ipa-replica-install utilities to install an additional key recovery authority (KRA) component, certificate authority, or replica, the following warning appears: 
SecurityWarning: Certificate has no `subjectAltName`,
falling back to check for a `commonName` for now.
This feature is being removed by major browsers and deprecated by RFC 2818.
The error occurs due to RFC 2818, which deprecates the practice of carrying the subject host name in the subject distinguished name (DN) common name (CN) field. However, the three utilities succeed. Therefore, you can ignore the warning message. (BZ#1358457)

pam_pkcs11 only supports one token

The PKCS#11 modules in the opensc and coolkey packages provide support for various types of smart cards. However the pam_pkcs11 module only supports one of them at a time. As a consequence, you cannot use PKCS#15 and CAC tokens using the same configuration. To work around the problem, install one of the following:
  • the opensc package for PKCS#15 and PIV support
  • the coolkey package for CAC, Coolkey, and PIV support (BZ#1367919)

Using ipa-ca-install on an IdM replica fails when the Directory Server is not configured with LDAPS

Installing a certificate authority (CA) using the ipa-ca-install utility on an Identity Management (IdM) replica fails when the Directory Server on the replica is not configured with LDAPS (using the TLS protocol over port 636). The attempt fails with this error: 
[2/30]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpsDHYbO' returned non-zero exit status 1
...
Installing a replica in this situation is not possible. As a workaround, choose one of these options:
  • Install the CA on the master server instead.
  • Enable LDAPS on the replica manually before running ipa-ca-install.
To manually enable LDAPS on the replica:
1. Export the server certificate from the /etc/httpd/alias file: 
$ pk12util -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt -o temp.p12 -n 'ca1/replica'
Replace ca1/replica with the nickname of your certificate.
2. Remove the trust chain from certificate, because it was already imported:
a. Extract the private key: 
$ openssl pkcs12 -in temp.p12 -nocerts -nodes -out temp.key
b. Extract the public key: 
$ openssl pkcs12 -in temp.p12 -nokeys -clcerts -out temp.pem
c. Create a PKCS#12 file without the CA certificate: 
$ openssl pkcs12 -export -in temp.pem -inkey temp.key -out repl.p12 -name 'ca1/replica'
Replace ca1/replica with the nickname of your certificate.
3. Import the created certificate into the Directory Server's NSSDB database: 
$ pk12util -d /etc/dirsrv/slapd-EXAMPLE-COM -K '' -i repl.p12
4. Remove the temporary certificate files: 
$ rm -f temp.p12 temp.key temp.pem repl.p12
5. Create a file, /tmp/enable_ssl.ldif, with the following contents: 
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: off
-
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
-
replace: nsSSL3Ciphers
nsSSL3Ciphers: default

dn: cn=config
changetype: modify
replace: nsslapd-security
nsslapd-security: on
6. Modify the LDAP configuration to enable SSL: 
$ ldapmodify -H "ldap://localhost" -D "cn=directory manager" -f /tmp/enable_ssl.ldif -w dm_password
Replace dm_password with your Directory Manager password.
7. Create a file, /tmp/add_rsa.ldif, with the following contents: 
dn: cn=RSA,cn=encryption,cn=config
changetype: add
objectclass: top
objectclass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: ca1/replica
nsSSLToken: internal (software)
nsSSLActivation: on
Replace ca1/replica with the nickname of your certificate.
8. Add the entry to the LDAP: 
$ ldapadd -H "ldap://localhost" -D "cn=directory manager" -f /tmp/add_rsa.ldif -w dm_password
Replace dm_password with your Directory Manager password.
9. Remove the temporary files: 
$ rm -f /tmp/enable_ssl.ldif /tmp/add_rsa.ldif
10. Restart directory server: 
# systemctl restart dirsrv@EXAMPLE-COM.service
After following these steps, LDAPS is enabled, and you can successfuly run ipa-ca-install on the replica. (BZ#1365858)

Third-party certificate trust flags are reset after installing an external CA into IdM

The ipa-ca-install --external-ca command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA.
When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the mod_nss module fail, and the httpd service fails to start. The CA installation fails with the following message in this situation: 
CA failed to start after 300 seconds
As a workaround, after this message appears, reset the third-party certificate flags to their previous state and restart httpd. For example, if the ca1 certificate previously had the C,, trust flags: 
# certutil -d /etc/httpd/alias -n 'ca1' -M -t C,,
# systemctl restart httpd.service
This restores the system to the correct state. (BZ#1318616)

realmd fails to remove the computer account from AD

Red Hat Enterprise Linux uses Samba as default back end for Active Directory (AD) domain memberships. In this case, if you manually set a computer name using the --computer-name option with the realm join command, the account cannot be removed from AD when you leave the domain. To work around this problem, do not use the --computer-name option and instead add the computer name to the /etc/realmd.conf file. For example: 
[domain.example.com]
computer-name = host_name
With the workaround, the host is successfully joined to the domain and the account is automatically removed if you leave the domain using the realm leave --remove command. (BZ#1370457)

SSSD fails to manage autofs mappings from a LDAP tree

Previously, the System Security Services Daemon (SSSD) implemented incorrect default values for autofs mappings when using the RFC2307 LDAP schema. A patch has been applied, which fixed the defaults to match the schema. However, users connecting to LDAP servers that contain mappings with the schema SSSD previously used, are not able to load the autofs attributes. Affected users see the following error reported in the /var/log/messages log file: 
Your configuration uses the autofs provider with schema set to rfc2307 and default attribute mappings. The default map has changed in this release, please make sure the configuration matches the server attributes.
To work around this problem, modify the /etc/sssd/sssd.conf file and set your domain to use the existing attribute mappings: 
[domain/EXAMPLE]
...
ldap_autofs_map_object_class   = automountMap
ldap_autofs_map_name           = ou
ldap_autofs_entry_object_class = automount
ldap_autofs_entry_key          = cn
ldap_autofs_entry_value        = automountInformation
As a result, SSSD is able to load autofs mappings from the attributes. (BZ#1372814)

The dependency list for pkispawn does not include openssl

When the openssl package is not installed, using the pkispawn utility fails with this error: 
Installation failed: [Errno 2] No such file or directory
This problem occurs because the openssl package is not included as a runtime dependency of the pki-server package contained within the pki-core package. As a work around, install openssl before running pkispawn. (BZ#1376488)

Enumerating a large number of users results in high CPU load and slows down other operations

When enumerate=true is set in the etc/sssd/sssd.conf file and a large number of users (for example, 30,000 users) are present in the LDAP server, certain performance problems occur:
  • the sssd_be process consumes almost 99% of CPU resources
  • certain operations, such as logging in as a local user or logging out, take unexpectedly long to complete
  • running the ldbsearch operation on the sysdb and timestamp caches fails with an error reporting that the indexed and full searches both failed
Note that this is not a new known issue, as these problems occurred in previous releases of SSSD as well. (BZ#888739, BZ#1379774)

GDM fails to authenticate using a smart card

When using smart card authentication, the System Security Services Daemon's (SSSD) PAM responder does not verify if the login name is a Kerberos user principal name (UPN). As a consequence, the gdm-password pluggable authentication module (PAM) shows the password prompt instead of the smart card PIN prompt when using a user principal name (UPN) as login name. As a result, smart card authenticating to the GNOME display manager (GDM) fails. (BZ#1389796)

The ipa passwd command fails when using uppercase or mixed case user names

Identity Management (IdM) 4.4.0 introduced unified handling of user principals in all commands. However, some commands were not fully converted. As a consequence, the ipa passwd command fails when you use uppercase or mixed case letters in user names. To work around this issue, use only lower case letters in user names when using the ipa passwd command. (BZ#1375133)

The IdM web UI does not correctly recognize the status of a revoked certificate

The Identity Management (IdM) web UI is currently unable to determine whether a certificate has been revoked. As a consequence:
  • The Revoked sign is not displayed when viewing the certificate from the user, service, or host details page.
  • The Revoke action is still available from the details page. Attempting to revoke an already revoked certificate results in an error dialog.
  • The Remove Hold button is always disabled even if the certificate has been revoked because of Certificate Hold (revocation reason 6). (BZ#1371479)

SSSD only applies values in sudoUser attributes from AD in lower case

Previously, when the System Security Services Daemon (SSSD) fetched sudo rules from Active Directory (AD), the sudoUser attribute must have match the exact case of the samAccountName attribute of the user the rule was assigned to. Due to a regression in Red Hat Enterprise Linux 7.3, the sudoUser attribute now only matches lower case values. To work around this problem, rename sudoUser attribute values to lower case. With the workaround, sudo rules are applied correctly. (BZ#1380436)

Updating the ipa-client and ipa-admintools packages can fail

During the upgrade from Red Hat Enterprise Linux 7.2 to Red Hat Enterprise Linux 7.3, updating of the ipa-client and ipa-admintools packages can fail in some cases. To work around this problem, uninstall ipa-client and ipa-admintools prior to upgrading to Red Hat Enterprise Linux 7.3, and then install the new versions of these packages. (BZ#1390565)

Upgrading SSSD sometimes causes the sssd process to be terminated

When the sssd process performs an action for an unexpectedly long time, an internal watchdog process terminates it. However, the sssd process does not start again. This problem usually occurs during an attempt to upgrade SSSD on a slow system if the SSSD database contains a large number of entries.
To work around this problem:
1. Make sure the central authentication server is available. This ensures that users will be able to authenticate after removing the SSSD cache in the next step.
2. Remove the SSSD cache using the sss_cache utility before upgrading.
A fix for this known issue will be available with the next update. (BZ#1392441)

Directory Server fails due to bind-dyndb-ldap schema errors

The version of the bind-dyndb-ldap LDAP schema included in Identity Management contains syntax errors and is missing a description of one attribute. If the user uses this version of the schema, the Directory Server component fails to start. Consequently, error messages are logged in the journal, informing the user about the incorrect syntax.
To work around this problem:
  1. Obtain a corrected schema file from the upstream git.fedorahosted.org repository: 
    # wget https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/doc/schema.ldif?id=17711141882aca3847a5daba2292bcbcc471ec63 -O /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif
  2. Copy the corrected schema file into the Directory Server's instance configuration folder. 
    # cp /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif /etc/dirsrv/slapd-[EXAMPLE-COM]/schema/[SCHEMA_FILE_NAME].ldif
  3. Restart Directory Server: 
    # systemctl restart dirsrv.target
(BZ#1413805)