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: 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: 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: 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: 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: b. Extract the public key: c. Create a PKCS#12 file without the CA certificate: Replace ca1/replica with the nickname of your certificate. 3. Import the created certificate into the Directory Server's NSSDB database: 4. Remove the temporary certificate files: 5. Create a file, /tmp/enable_ssl.ldif , with the following contents: 6. Modify the LDAP configuration to enable SSL: Replace dm_password with your Directory Manager password. 7. Create a file, /tmp/add_rsa.ldif , with the following contents: Replace ca1/replica with the nickname of your certificate. 8. Add the entry to the LDAP: Replace dm_password with your Directory Manager password. 9. Remove the temporary files: 10. Restart directory server: 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: As a workaround, after this message appears, reset the third-party certificate flags to their state and restart httpd . For example, if the ca1 certificate previously had the C,, trust flags: 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: 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: To work around this problem, modify the /etc/sssd/sssd.conf file and set your domain to use the existing attribute mappings: 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: 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 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 step. 2. Remove the SSSD cache using the sss_cache utility before upgrading. A fix for this known issue will be available with the 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: Obtain a corrected schema file from the upstream git.fedorahosted.org repository: Copy the corrected schema file into the Directory Server's instance configuration folder. Restart Directory Server: (BZ#1413805)

Commands:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
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.
[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
pk12util -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt -o temp.p12 -n 'ca1/replica'
openssl pkcs12 -in temp.p12 -nocerts -nodes -out temp.key
openssl pkcs12 -in temp.p12 -nokeys -clcerts -out temp.pem
openssl pkcs12 -export -in temp.pem -inkey temp.key -out repl.p12 -name 'ca1/replica'
pk12util -d /etc/dirsrv/slapd-EXAMPLE-COM -K '' -i repl.p12
rm -f temp.p12 temp.key temp.pem repl.p12
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
ldapmodify -H "ldap://localhost" -D "cn=directory manager" -f /tmp/enable_ssl.ldif -w dm_password
dn: cn=RSA,cn=encryption,cn=config changetype: add objectclass: top objectclass: nsEncryptionModule cn: RSA nsSSLPersonalitySSL: ca1/replica nsSSLToken: internal (software) nsSSLActivation: on
ldapadd -H "ldap://localhost" -D "cn=directory manager" -f /tmp/add_rsa.ldif -w dm_password
rm -f /tmp/enable_ssl.ldif /tmp/add_rsa.ldif
systemctl restart dirsrv@EXAMPLE-COM.service
CA failed to start after 300 seconds
certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, systemctl restart httpd.service
[domain.example.com] computer-name = host_name
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.
[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
Installation failed: [Errno 2] No such file or directory
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
cp /usr/share/doc/bind-dyndb-ldap-10.0/schema.ldif /etc/dirsrv/slapd-[EXAMPLE-COM]/schema/[SCHEMA_FILE_NAME].ldif
systemctl restart dirsrv.target