B.4. Logging In and Authentication Problems

B.4.1. Kerberos GSS Failures When Running ipa Commands

Immediately after installing a server, Kerberos errors occur when attempting to run an ipa command. For example:
ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)

What this means:

DNS is not properly configured.

To fix the problem:

Verify your DNS configuration.

B.4.2. SSH Connection Fails when Using GSS-API

Users are unable to log in to IdM machines using SSH.

What this means:

When SSH attempts to connect to an IdM resource using GSS-API as the security method, GSS-API first verifies the DNS records. SSH failures are often caused by incorrect reverse DNS entries. The incorrect records prevent SSH from locating the IdM resource.

To fix the problem:

Verify your DNS configuration as described in Section 2.1.5, “Host Name and DNS Configuration”.
As a temporary workaround, you can also disable reverse DNS lookups in the SSH configuration. To do this, set the GSSAPITrustDNS to no in the /etc/ssh/ssh_config file. Instead of using reverse DNS records, SSH will pass the given user name directly to GSS-API.

B.4.3. OTP Token Out of Sync

Authentication using OTP fails because the token is desynchronized.

To fix the problem:

Resynchronize the token. Any user can resynchronize their tokens regardless of the token type and whether or not the user has permission to modify the token settings.
  1. In the IdM web UI: Click Sync OTP Token on the login page.
    Sync OTP Token

    Figure B.1. Sync OTP Token

    From the command line: Run the ipa otptoken-sync command.
  2. Provide the information required to resynchronize the token. For example, IdM will ask you to provide your standard password and two subsequent token codes generated by the token.

    Note

    Resynchronization works even if the standard password is expired. After the token is resynchronized using an expired password, log in to IdM to let the system prompt you to change the password.

B.4.4. Smart Card Authentication Fails with Timeout Error Messages

The sssd_pam.log and sssd_EXAMPLE.COM.log files contain timeout error messages, such as these:
Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000):
Setting up signal handler up for pid [12370]
(Wed Jun 14 18:24:03 2017) [sssd[pam]] [child_handler_setup] (0x2000): Signal
handler set up for pid [12370]
(Wed Jun 14 18:24:08 2017) [sssd[pam]] [pam_initgr_cache_remove] (0x2000):
[idmeng] removed from PAM initgroup cache
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [p11_child_timeout] (0x0020): Timeout
reached for p11_child.
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_forwarder_cert_cb] (0x0040):
get_cert request failed.
(Wed Jun 14 18:24:13 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called
with result [4]: System error.

What this means:

When using forwarded smart card readers or the Online Certificate Status Protocol (OCSP), you might need to adjust certain default values for users to be able to authenticate with smart cards.

To fix the problem:

On the server and on the client from which you want users to authenticate, make these changes in the /etc/sssd/sssd.conf file:
  1. In the [pam] section, increase the p11_child_timeout value to 60 seconds.
  2. In the [domain/EXAMPLE.COM] section, increase the krb5_auth_timeout value to 60 seconds.
  3. If you are using OCSP in the certificate, make sure the OCSP server is reachable. If the OCSP server is not directly reachable, configure a proxy OCSP server by adding the following options to /etc/sssd/sssd.conf:
    certificate_verification = ocsp_default_responder=http://ocsp.proxy.url,
    ocsp_default_responder_signing_cert=nickname
    Replace nickname with the nickname of the OCSP signing certificate in the /etc/pki/nssdb/ directory.
    For details on these options, see the sssd.conf(5) man page.