|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library|
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.
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
# kinit -k
# kvno nfs/denver.example.com nfs/denver.example.com@EXAMPLE.COM: kvno = 3
Note that the KVNO listed here is 3 instead of 2.
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.
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.
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 22.214.171.124 A 126.96.36.199 A 188.8.131.52 my-en0.host.name. A 184.108.40.206 my-en1.host.name. A 220.127.116.11 my-en2.host.name. A 18.104.22.168 22.214.171.124 PTR my.host.name. 126.96.36.199 PTR my.host.name. 188.8.131.52 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.
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.
To be able to monitor the credential mappings, first uncomment this line from the /etc/gss/gsscred.conf file.
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.