|
Credentials cache I/O operation failed XXX Cause: Kerberos had a problem writing to the system's credentials cache (/tmp/krb5cc_uid).
Solution: Make sure that the credentials cache has not been removed, and that there is space left on the device by using the df command.
Decrypt integrity check failed Cause: You might have an invalid ticket.
Solution: Make sure that your credentials are valid. Destroy your tickets with kdestroy and create new tickets with kinit.
Make sure that the target host has a keytab file with the correct version of the service key. Use kadmin to view the key version number of the service principal (for example, host/FQDN_hostname) in the Kerberos database.
Also, use klist -k on the target host to make sure that it has the same key version number.
df: cannot statvfs filesystem: Invalid argument Cause: The df command cannot access the Kerberized NFS file system, which is currently mounted, to generate its report, because you no longer have the appropriate root credentials. Destroying your credentials for a
mounted Kerberized file system does not automatically unmount the file system.
Solution: You must create new root credentials to access the Kerberized file system. If you no longer require access to the Kerberized file system, unmount the file system.
failed to obtain credentials cache Cause: During kadmin initialization, a failure occurred when kadmin tried to obtain credentials for the admin principal.
Solution: Make sure that you used the correct principal and password when you executed kadmin.
Field is too long for this implementation Cause: The message size that was being sent by a Kerberized application was too long. The maximum message size that can be handled by Kerberos is 65535 bytes. In addition, there are limits on individual fields within a protocol message that is sent by Kerberos.
Solution: Make sure that your Kerberized applications are sending valid message sizes.
GSS-API (or Kerberos) error Cause: This message is a generic GSS-API or Kerberos error message and can be caused by several different problems.
Solution: Check the /etc/krb5/kdc.log file to find the more specific GSS-API error message that was logged when this error occurred.
Hostname cannot be canonicalized Cause: Kerberos cannot make the host name fully qualified.
Solution: Make sure that the host name is defined in DNS and that the host-name-to-address and address-to-host-name mappings are consistent.
Illegal cross-realm ticket Cause: The ticket sent did not have the correct cross-realms. The realms might not have the correct trust relationships set up.
Solution: Make sure that the realms you are using have the correct trust relationships.
Improper format of Kerberos configuration file Cause: The Kerberos configuration file (krb5.conf) has invalid entries.
Solution: Make sure that all the relations in the krb5.conf file are followed by the "=" sign and a value. Also, verify that the brackets are present in pairs for each subsection.
Inappropriate type of checksum in message Cause: The message contained an invalid checksum type.
Solution: Check which valid checksum types are specified in the krb5.conf and kdc.conf files.
Incorrect net address Cause: There was a mismatch in the network address. The network address in the ticket that was being forwarded was different from the network address where the ticket was processed. This message might occur when tickets are being forwarded.
Solution: Make sure that the network addresses are correct. Destroy your tickets with kdestroy, and create new tickets with kinit.
Invalid flag for file lock mode Cause: An internal Kerberos error occurred.
Solution: Please report a bug.
Invalid message type specified for encoding Cause: Kerberos could not recognize the message type that was sent by the Kerberized application.
Solution: If you are using a Kerberized application that was developed by your site or a vendor, make sure that it is using Kerberos correctly.
Invalid number of character classes Cause: The password that you entered for the principal does not contain enough password classes, as enforced by the principal's policy.
Solution: Make sure that you enter a password with the minimum number of password classes that the policy requires.
KADM err: Memory allocation failure Cause: There is not enough memory to run kadmin.
Solution: Free up memory and try running kadmin again.
KDC can't fulfill requested option Cause: The KDC did not allow the requested option. A possible problem might be that postdating or forwardable options were being requested, and the KDC did not allow it. Another problem might be that you requested the renewal of a TGT, but you didn't have
a renewable TGT.
Solution: Determine if you are requesting an option that either the KDC does not allow or if you are requesting a type of ticket that is not available.
KDC policy rejects request Cause: The KDC policy did not allow the request. For example, the request to the KDC did not have an IP address in its request, or forwarding was requested, but the KDC did not allow it.
Solution: Make sure that you are using kinit with the correct options. If necessary, modify the policy that is associated with the principal or change the principal's attributes to allow the request. You can modify the policy or principal by using kadmin.
KDC reply did not match expectations Cause: The KDC reply did not contain the expected principal name, or other values in the response were incorrect.
Solution: Make sure that the KDC you are communicating with complies with RFC1510, or that the request you are sending is a Kerberos V5 request, or that the KDC is available.
Key table entry not found Cause: There is no entry for the service principal in the network application server's keytab file.
Solution: Add the appropriate service principal to the server's keytab file so that it can provide the Kerberized service.
Key version number for principal in key table is incorrect Cause: A principal's key version is different in the keytab file and in the Kerberos database. Either a service's key has been changed, or you might be using an old service ticket.
Solution: If a service's key has been changed (for example, by using kadmin), you need to extract the new key and store it in the host's keytab file where the service is running.
Alternately, you might be using an old service ticket that has an older key. You might want to run the kdestroy command and then the kinit command again.
|