Kerberos/Troubleshooting

From Authentication Tools for Joomla! (JAuthTools)

Jump to: navigation, search

This page documents some solutions for common Kerberos issues. It isn't comprehensive but should give you a guide what to look for when resolving the issues.

Contents

Known Errors and Resolutions

kinit(v5): KRB5 error code 68 while getting initial credentials

Wrong Kerberos domain, check that the Linux box is configured to use the right domain.


kinit(v5): Permission denied while getting initial credentials

Check the permission on your keytab file to ensure that the process can get access to it appropriately.


Client not found in Kerberos database

  • kinit(v5): Client not found in Kerberos database while getting initial credentials
  • krb5_get_init_creds_password() failed: Client not found in Kerberos database

Make sure that you're typing in the right name and the server has the right name (double check the account tab of the user, especially the realm)


kinit(v5): Preauthentication failed while getting initial credentials

Wrong password - use the right password. This may also occur with keys and a buggy version of ktpass.exe, some versions of ktpass.exe had issues generating keys (Windows 2003 SP1) so upgrading to the latest release should fix this (see Microsoft KB 919557)


kinit(v5): Key table entry not found while getting initial credentials

Regenerate keytab file and make sure that your file is correct.


krb5_get_init_creds_password() failed: Clock skew too great

  • failed to verify krb5 credentials: Clock skew too great

Time between HTTP server and Kerberos server is too big; alternatively may also indicate a client issue. Check that you have NTP setup properly, using the KDC as the primary NTP server.


failed to verify krb5 credentials: Server not found in Kerberos database

Check the default_realms to ensure there is a proper mapping, also check that the host/FQDN@REALM entry exists.


gss_acquire_cred() failed: Miscellaneous failure (No principal in keytab matches desired name)

Check default_realms to ensure there is a domain mapping. Check the keytab file (klist -k /etc/krb5.keytab or similar) to ensure that the appropriate domain is present. Also ensure that your hostname is the FQDN of the machine.


gss_accept_sec_context() failed: A token was invalid (Token header is malformed or corrupt)

Check that the site is in the local domain for IE's security settings; likely an NTLM token is being sent, see IE not correctly identifying sites in the intranet to help resolve this issue.


gss_accept_sec_context() failed: Miscellaneous failure (Key version number for principal in key table is incorrect)

Wrong key version is being used. Check the key on the server (kinit -k PRINCIPAL) and also restart any client to clear their local cache or restart the server to clear its cache. kerbtray.exe can also delete old tickets. Also note that some versions of ktpass.exe had issues generating keys (Windows 2003 SP1) so upgrading to the latest release should fix this (see http://support.microsoft.com/kb/919557 Microsoft KB 919557])


Issues with mapuser

AD may or may not have had time to properly replicate the user to all DC's. Ensure that the DC you're querying is the same as the one you created the user to avoid this as much as possible.


IE prompts for a password on each access

From Windows Authentication and ASP.Net: Internet Explorer security settings must be configured to enable Integrated Windows authentication. By default, Integrated Windows authentication is not enabled in Internet Explorer 6. To enable the browser to respond to a negotiate challenge and perform Kerberos authentication, select the Enable Integrated Windows Authentication check box in the Security section of the Advanced tab of the Internet Options menu, and then restart the browser.'

Alternatively this may be an issue with the site not being in the intranet zone. IE won't send authentication details automatically to sites that aren't located within the intranet zone. See IE not correctly identifying sites in the intranet for more information.


Unknown responses

krb5_get_init_creds_password() failed: KDC reply did not match expectations

See http://mailman.mit.edu/pipermail/kerberos/2007-November/012585.html

Specified realm `OTHER.REALM.NAME' not allowed by configuration

Another realm is trying to authenticate against the server than is permissable by the servers configuration. This could point to a mismatch between the servers configured realm and the actual realm of the user or the fact that there are multiple realms available and only one configured.

KDC has no support for encryption type

Would indicate that the KDC doesn't like the encryption protocols being used. If you're not using the MIT implementation (e.g. Hiemdal) see if switching to MIT works.

Personal tools