Intended for: Kerberos users who are having trouble authenticating to Kerberos and logging in to Kerberized machines.
Scenario/Use case:
This article is intended to help you troubleshoot your Kerberos authentication problem and provides instructions on how to fix it.
Instructions:
Note: If you don't find the solution to your problem here, send mail to kerberos-users@fnal.gov requesting help in diagnosing the failure. Please include: principal name, date, time and IP address from which authentication failed, in addition to the error message and other error-related information.
- In many cases, when authentication fails, one of three things is likely to be wrong:
- (1) your password
- (2) the date/time on your system (see section Synchronize your Machine with Time Server for UNIX, Time Synchronization for Windows, or Time Synchronization for Mac OS X)
- (3) the local host name in the /etc/hosts file (see section The /etc/hosts File)
- "Incorrect net address" usually refers to NAT (see section Network Address Translation) or a multiple-IP address host. For UNIX, edit the [libdefaults] in /etc/krb5.conf: add proxy_gateway=<your fixed IP address>. For Macintosh, edit the [libdefaults] in the Kerberos Preferences file: add noaddresses=true.
- YP problem: The error "do_ypcall: clnt_call: RPC: Timed out" typically indicates a local problem on your system or site network. Your machine is likely using YP (NIS) for host name-to-address resolution and you have a transient problem with your YP server(s).
- When using the Kerberized versions of telnet, rlogin, or rsh (see Network Programs Available on Kerberized Machines) to connect to another machine in the strengthened realm, some users have had to use the -l <login_name> option even when the login names on both systems match. (Don't ask why.) You definitely need to use this option if the login names don't match.
- "KDC policy rejects request" or "KDC can't fulfill requested option" usually means either you're requesting a forwardable ticket for a /root or /admin instance of your principal (not allowed), or you're trying to forward a ticket that's not forwardable, or renew one that's not renewable.
- "Key version number for principal in key table is incorrect" means either the keytab has changed since the service ticket was obtained (to solve, run kinit -R or kinit), or the service key (for host principal) in the KDC was changed after the keytab file was created (to solve, recreate keytab file on host, see section Installing Service Host Keys).
- "Cannot contact any KDC for requested realm." Caused by firewall blocking KDC request or reply, or DNS failure.
- "Server not found in Kerberos database" Possible causes include: local hosts file or NIS map giving wrong name for host (check /etc/hosts file and make sure the full official host name appears first, not a nickname; see section The /etc/hosts File), or a bad or missing [domain_realm] mapping in /etc/krb5.conf.
- Syslog message: Principal <principalname>@FNAL.GOV ... for local user <user> failed krb5_kuserok.krb5_kuserokis a function in the kerberos library. It is accessed by krshd, and fails for these reasons:
- requested user has no account on target system
- krb5_unparse_name fails
- can't open ~user/.k5login
- ~user/.k5login not owned by user or root
- principal doesn't match any line in .k5login (try od -c ~user/.k5login to look for any "invisible" characters in this file).
- If Kerberos functions are very slow on a client host, check its Kerberos logs for long intervals between "NEEDED_PREAUTH" and "ISSUE" and see if there are few or no repeats of the same request to different KDCs. If so, the client host's first-configured DNS server may be slow or dead.
To resolve this, check the DNS server list (/etc/resolv.conf on UNIX-like systems, Network Control Panel on Windows) and test each one, moving dead servers down in the list or removing them.
SSH Problems
- Make sure the instance of the ssh product you're using matches the OS version of your target UNIX machine.
- When you use the Kerberos-aware ssh or scp client to connect to a node that's running a non-Kerberos-aware sshd, the client ignores a .shost file on the remote node. It tries Kerberos, that of course fails, then it prompts for a password. Supplying the password works. (This is an unavoidable side-effect.)
- Logins from Kerberized ssh clients to unstrengthened ssh servers can fail. You can work around this by explicitly using the -l <login_name> option even if the login names on both systems match. (Again, don't ask why.)
- If you get prompted for a password when you login from a machine with Kerberized ssh, and you already have valid tickets, check to make sure the following line is in the [domain_realm]section of your /etc/krb5.conffile:
.fnal.gov = FNAL.GOV
Kerberized ssh token-passing won't work without it, nor will FTP.