openSolaris 2008 - Kerberos Troubleshooting - System Administration Guide: Security Services

Kerberos Troubleshooting

This section provides troubleshooting information for the Kerberos software.

Problems With the Format of the `krb5.conf` File

If the krb5.conf file is not formatted properly, the telnet command will fail. However, the dtlogin and login commands will still succeed, even if the krb5.conf file is specified as required for the commands. If this problem occurs, the following error message is displayed:

Error initializing krb5: Improper format of Kerberos configuration

In addition, an incorrectly formatted krb5.conf file, prevents the applications that use the GSSAPI from using the krb5 mechanisms.

If there is a problem with the format of the krb5.conf file, you are vulnerable to security breaches. You should 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,” [https://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 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 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.