Este contenido no está disponible en el idioma seleccionado.

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)
Copy to Clipboard Toggle word wrap

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.

    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.
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    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.
  4. Restart SSSD:
    # systemctl restart sssd.service
    Copy to Clipboard Toggle word wrap
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat