Chapter 16 SEAM Error Messages and Troubleshooting

This chapter provides resolutions for error messages that you might receive when you use SEAM, as well as some troubleshooting tips for various problems. This is a list of the error message and troubleshooting information in this chapter.

• SEAM Administration Tool Error Messages

• Common SEAM Error Messages (A-M)

• Common SEAM Error Messages (N-Z)

• Problems Mounting a Kerberized NFS File System

• Problems Authenticating as root

SEAM Error Messages

This section provides information about SEAM error messages, including why each error occurs and a way to fix it.

SEAM Administration Tool Error Messages

Unable to view the list of principals or policies; use the Name field.

Cause:

The admin principal that you logged in with does not have the list privilege (l) in the Kerberos ACL file (kadm5.acl), so you cannot view the principal list or policy list.

Solution:

You must enter the principal and policy names in the Name field to work on them, or you need to log on with a principal that has the appropriate privileges.

JNI: Java array creation failed

JNI: Java class lookup failed

JNI: Java field lookup failed

JNI: Java method lookup failed

JNI: Java object lookup failed

JNI: Java object field lookup failed

JNI: Java string access failed

JNI: Java string creation failed

Cause:

A serious problem exists with the Java Native Interface that is used by the SEAM Administration Tool (gkadmin).

Solution:

Exit gkadmin and restart it. If the problem persists, please report a bug.

Common SEAM Error Messages (A-M)

This section provides an alphabetical list (A-M) of common error messages for the SEAM commands, SEAM daemons, PAM framework, GSS interface, the NFS service, and the Kerberos library.

major_error minor_error gssapi error importing name

Cause:

An error occurred while a service name was being imported.

Solution:

Make sure that the service principal is in the host's keytab file.

Bad krb5 admin server hostname while initializing kadmin interface

Cause:

An invalid host name is configured for admin_server in the krb5.conf file.

Solution:

Make sure that the correct host name for the master KDC is specified on the admin_server line in the krb5.conf file.

Cannot contact any KDC for requested realm

Cause:

No KDC responded in the requested realm.

Solution:

Make sure that at least one KDC (either the master or slave) is reachable or that the krb5kdc daemon is running on the KDCs. Check the /etc/krb5/krb5.conf file for the list of configured KDCs (kdc = kdc_name).

Cannot determine realm for host

Cause:

Kerberos cannot determine the realm name for the host.

Solution:

Make sure that there is a default realm name, or that the domain name mappings are set up in the Kerberos configuration file (krb5.conf).

Cannot find KDC for requested realm

Cause:

No KDC was found in the requested realm.

Solution:

Make sure that the Kerberos configuration file (krb5.conf) specifies a KDC in the realm section.

cannot initialize realm realm_name

Cause:

The KDC might not have a stash file.

Solution:

Make sure that the KDC has a stash file. If not, create a stash file by using the kdb5_util command, and try running the krb5kdccommand again. The easiest way to start krb5kdc is to run the /etc/init.d/kdc script.

Cannot resolve KDC for requested realm

Cause:

Kerberos cannot determine any KDC for the realm.

Solution:

Make sure that the Kerberos configuration file (krb5.conf) specifies a KDC in the realm section.

Cannot reuse password

Cause:

The password that you entered has been used before by this principal.

Solution:

Choose a password that has not been chosen before, at least not within the number of passwords that are kept in the KDC database for each principal (this policy is enforced by the principal's policy).

Can't get forwarded credentials

Cause:

Credential forwarding could not be established.

Solution:

Make sure that the principal has forwardable credentials.

Can't open/find Kerberos configuration file

Cause:

The Kerberos configuration file (krb5.conf) was unavailable.

Solution:

Make sure that the krb5.conf file is available in the correct location and has the correct permissions. This file should be writable by root and readable by everyone else.

Client/server realm mismatch in initial ticket request

Cause:

A realm mismatch between the client and server occurred in the initial ticket request.

Solution:

Make sure that the server you are communicating with is in the same realm as the client, or that the realm configurations are correct.

Client or server has a null key

Cause:

The principal has a null key.

Solution:

Modify the principal to have a non-null key by using the cpw command of kadmin.

Communication failure with server while initializing kadmin interface

Cause:

The host that was entered for the admin server, also called the master KDC, did not have the kadmind daemon running.

Solution:

Make sure that you specified the correct host name for the master KDC. If you specified the correct host name, make sure that kadmind is running on the master KDC that you specified.

Credentials cache file permissions incorrect

Cause:

You do not have the appropriate read or write permissions on the credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that you have read and write permissions on the credentials cache.

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:

1. Make sure that your credentials are valid. Destroy your tickets with kdestroy and create new tickets with kinit.

2. 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.

login: load_modules: can not open module /usr/lib/security/pam_krb5.so.1

Cause:

Either the Kerberos PAM module is missing or it is not a valid executable binary.

Solution:

Make sure that the Kerberos PAM module is in the /usr/lib/security directory and that it is a valid executable binary. Also, make sure that the /etc/pam.conf file contains the correct path to pam_krb5.so.1.

Looping detected inside krb5_get_in_tkt

Cause:

Kerberos made several attempts to get the initial tickets but failed.

Solution:

Make sure that at least one KDC is responding to authentication requests.

Master key does not match database

Cause:

The loaded database dump was not created from a database that contains the master key, which is located in /var/krb5/.k5.REALM.

Solution:

Make sure that the master key in the loaded database dump matches the master key that is located in /var/krb5/.k5.REALM.

Matching credential not found

Cause:

The matching credential for your request was not found. Your request requires credentials that are unavailable in the credentials cache.

Solution:

Destroy your tickets with kdestroy and create new tickets with kinit.

Message out of order

Cause:

Messages that were sent using sequential-order privacy arrived out of order. Some messages might have been lost in transit.

Solution:

You should reinitialize the Kerberos session.

Message stream modified

Cause:

There was a mismatch between the computed checksum and the message checksum. The message might have been modified while in transit, which can indicate a security leak.

Solution:

Make sure that the messages are being sent across the network correctly. Since this message can also indicate the possible tampering of messages while they are being sent, destroy your tickets using kdestroy and reinitialize the Kerberos services that you are using.

Common SEAM Error Messages (N-Z)

This section provides an alphabetical list (N-Z) of common error messages for the SEAM commands, SEAM daemons, PAM framework, GSS interface, the NFS service, and the Kerberos library.

No credentials cache file found

Cause:

Kerberos could not find the credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that the credential file exists and is readable. If it isn't, try performing the kinit again.

Operation requires “privilege” privilege

Cause:

The admin principal that was being used does not have the appropriate privilege configured in the kadm5.acl file.

Solution:

Use a principal that has the appropriate privileges. Or, configure the principal that was being used to have the appropriate privileges by modifying the kadm5.acl file. Usually, a principal with “/admin” as part of its name has the appropriate privileges.

PAM-KRB5: Kerberos V5 authentication failed: password incorrect

Cause:

Your UNIX password and Kerberos passwords are different. Most non-Kerberized commands, such as login, are set up through PAM to automatically authenticate with Kerberos by using the same password that you specified for your UNIX password. If your passwords are different, the Kerberos authentication fails.

Solution:

You must enter your Kerberos password when prompted.

Password is in the password dictionary

Cause:

The password that you entered is in a password dictionary that is being used. Your password is not a good choice for a password.

Solution:

Choose a password that has a mix of password classes.

Permission denied in replay cache code

Cause:

The system's replay cache could not be opened. The server might have been first run under a user ID different than your current user ID.

Solution:

Make sure that the replay cache has the appropriate permissions. The replay cache is stored on the host where the Kerberized server application is running (/usr/tmp/rc_service_name). Instead of changing the permissions on the current replay cache, you can also remove the replay cache before you run the Kerberized server under a different user ID.

Protocol version mismatch

Cause:

Most likely, a Kerberos V4 request was sent to the KDC. SEAM supports only the Kerberos V5 protocol.

Solution:

Make sure that your applications are using the Kerberos V5 protocol.

Request is a replay

Cause:

The request has already been sent to this server and processed. The tickets might have been stolen, and someone else is trying to reuse the tickets.

Solution:

Wait for a few minutes and reissue the request.

Requested principal and ticket don't match

Cause:

The service principal that you are connecting to and the service ticket that you have do not match.

Solution:

Make sure that DNS is functioning properly. If you are using another vendor's software, make sure that the software is using principal names correctly.

Requested protocol version not supported

Cause:

Most likely, a Kerberos V4 request was sent to the KDC. SEAM supports only the Kerberos V5 protocol.

Solution:

Make sure that your applications are using the Kerberos V5 protocol.

Required parameters in krb5.conf missing while initializing kadmin interface

Cause:

There is a missing parameter (such as the admin_server parameter) in the krb5.conf file.

Solution:

Determine which parameter is missing and add it to the krb5.conf file.

Server rejected authentication (during sendauth exchange)

Cause:

The server that you are trying to communicate with rejected the authentication. Most often this error occurs during Kerberos database propagation. Some common causes might be problems with the kpropd.acl file, DNS, or the keytab file.

Solution:

If you get this error when you are running applications other than kprop, investigate whether the server's keytab file is correct.

Set gss service nfs@<host> failed. Check nfs service credential.

Cause:

This message is generated by syslog after a share command has failed with an “invalid argument” message. The most likely cause of this message is that either there is no keytab file or that there is no NFS service principle in the keytab file.

Solution:

To isolate the problem, run klist -k to see if the keytab file exists and if there is an NFS service principal for the host in the keytab file.

The ticket isn't for us

Ticket/authenticator don't match

Cause:

There was a mismatch between the ticket and authenticator. The principal name in the request might not have matched the service principal's name, because the ticket was being sent with an FQDN name of the principal while the service expected non-FQDN, or vice versa.

Solution:

If you get this error when you are running applications other than kprop, investigate whether the server's keytab file is correct.

Ticket expired

Cause:

Your ticket times have expired.

Solution:

Destroy your tickets with kdestroy and create new tickets with kinit.

Ticket is ineligible for postdating

Cause:

The principal does not allow its tickets to be postdated.

Solution:

Modify the principal with kadmin to allow postdating.

Ticket not yet valid

Cause:

The postdated ticket is not valid yet.

Solution:

Create new tickets with the correct date, or wait until the current tickets are valid.

Truncated input file detected

Cause:

The database dump file that was being used in the operation is not a complete dump file.

Solution:

Create the dump file again, or use a different database dump file.

Wrong principal in request

Cause:

There was an invalid principal name in the ticket. This error might indicate a DNS or FQDN problem.

Solution:

Make sure that the principal of the service matches the principal in the ticket.

SEAM Troubleshooting

This section provides troubleshooting information for the SEAM software.

Problems Mounting a Kerberized NFS File System

• If mounting a Kerberized NFS file system fails, make sure that the /var/tmp/rc_nfs file exists on the NFS server. If the file system is not owned by root, remove it and try the mount again.

• If you have a problem accessing a Kerberized NFS file system, make sure that there is an entry for gssd in the inetd.conf file on your system and the NFS server.

• If you see either the invalid argument or bad directory error message when you are trying to access a Kerberized NFS file system, the problem might be that you are not using a fully-qualified DNS name when you are trying to mount the NFS file system. The host that is being mounted is not the same as the host name part of the service principal in the server's keytab file.

  This problem might also occur if your server has multiple Ethernet interfaces, and you have set up DNS to use a “name per interface” scheme instead of a “multiple address records per host” scheme. For SEAM, you should set up multiple address records per host as follows [Ken Hornstein, “Kerberos FAQ,” [http://www.nrl.navy.mil/CCS/people./kenh/kerberos-faq.html], accessed 11 December 1998.] :

  my.host.name.   A       1.2.3.4
                  A       1.2.4.4
                  A       1.2.5.4
  
  my-en0.host.name.       A       1.2.3.4
  my-en1.host.name.       A       1.2.4.4
  my-en2.host.name.       A       1.2.5.4
  
  4.3.2.1         PTR     my.host.name.
  4.4.2.1         PTR     my.host.name.
  4.5.2.1         PTR     my.host.name.

In this example, the setup allows one reference to the different interfaces and allows a single service principal instead of three service principals in the server's keytab file.

Problems Authenticating as root

If authentication fails when you try to become superuser on your system and you have already added the root principal to your host's keytab file, there are two potential problems to check. First, make sure that the root principal in the keytab file has a fully-qualified name as its instance. If it does, check the /etc/resolv.conf file to make sure that the system is correctly set up as a DNS client.