Kerberos Troubleshooting

This section provides troubleshooting information for the Kerberos software.

How to Identify Problems With Key Version Numbers

Sometimes, the key version number (KVNO) used by the KDC and the service principal keys stored in /etc/krb5/krb5.keytab for services hosted on the system do not match. The KVNO can get out of synchronization when a new set of keys are created on the KDC without updating the keytable file with the new keys. This problem can be diagnosed by using the following procedure.

1. List the keytab entries.

   Note that the KVNO for each principal is included in the list.

   # klist -k 
   Keytab name: FILE:/etc/krb5/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      2 host/denver.example.com@EXAMPLE.COM
      2 host/denver.example.com@EXAMPLE.COM
      2 host/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM
      2 nfs/denver.example.com@EXAMPLE.COM

2. Acquire an initial credential by using the host key.

   # kinit -k

3. Determine the KVNO that is used by the KDC.

   # kvno nfs/denver.example.com
   nfs/denver.example.com@EXAMPLE.COM: kvno = 3

   Note that the KVNO listed here is 3 instead of 2.

Problems With the Format of the krb5.conf File

If the krb5.conf file is not formatted properly, then the following error message might be displayed in a terminal window or recorded in the log file:

Improper format of Kerberos configuration file while initializing krb5 library

If there is a problem with the format of the krb5.conf file, then the associated services could be vulnerable to attack. You must fix the problem before you allow Kerberos features to be used.

Problems Propagating the Kerberos Database

If propagating the Kerberos database fails, try /usr/bin/rlogin -x between the slave KDC and master KDC, and from the master KDC to the slave KDC server.

If the KDCs have been set up to restrict access, rlogin is disabled and cannot be used to troubleshoot this problem. To enable rlogin on a KDC, you must enable the eklogin service.

# svcadm enable svc:/network/login:eklogin

After you finish troubleshooting the problem, you need to disable the eklogin service.

If rlogin does not work, problems are likely because of the keytab files on the KDCs. If rlogin does work, the problem is not in the keytab file or the name service, because rlogin and the propagation software use the same host/host-name principal. In this case, make sure that the kpropd.acl file is correct.

Problems Mounting a Kerberized NFS File System

• If mounting a Kerberized NFS file system fails, make sure that the /var/rcache/root 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 the gssd service is enabled 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 the Kerberos service, you should set up multiple address records per host as followsKen Hornstein, “Kerberos FAQ,” [http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns], accessed 10 March 2010.:

  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 a single service principal instead of three service principals in the server's keytab file.

Problems Authenticating as the root User

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

Observing Mapping From GSS Credentials to UNIX Credentials

To be able to monitor the credential mappings, first uncomment this line from the /etc/gss/gsscred.conf file.

SYSLOG_UID_MAPPING=yes

Next instruct the gssd service to get information from the /etc/gss/gsscred.conf file.

# pkill -HUP gssd

Now you should be able to monitor the credential mappings as gssd requests them. The mappings are recorded by syslogd, if the syslog.conf file is configured for the auth system facility with the debug severity level.