From Authentication Tools for Joomla! (JAuthTools)
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.
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.
krb5_get_init_creds_password() failed: KDC reply did not match expectations
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.