Resolving frequent problems
***************************

Problems compiling Kerberos
===========================

Many compilers require a switch to become ANSI compliant. Since krb4 is written in ANSI C it is necessary to specify the name of the compiler to be used and the required switch to make it ANSI compliant. This is most easily done when running configure using the env command. For instance to build under HP-UX using the native compiler do:

     datan$ env CC="cc -Ae" ./configure

In general gcc works. The following combinations have also been verified to successfully compile the distribution:

HP-UX
     cc -Ae

Digital UNIX
     cc -std1

AIX
     xlc

Solaris 2.x
     cc (unbundled one)

IRIX
     cc

Linux problems
--------------

The libc functions gethostby*() under RedHat4.2 can sometimes cause core dumps. If you experience these problems make sure that the file /etc/nsswitch.conf contains a hosts entry no more complex than the line

hosts: files dns

Some systems have lost /usr/include/ndbm.h which is necessary to build krb4 correctly. There is a ndbm.h.Linux right next to the source distribution.

There has been reports of non-working libdb on some Linux distributions.  If that happens, use the --without-berkeley-db when configuring.

SunOS 5 (aka Solaris 2) problems
--------------------------------

When building shared libraries and using some combinations of GNU gcc/ld you better set the environment variable RUN_PATH to /usr/athena/lib (your target libdir). If you don't, then you will have to set LD_LIBRARY_PATH during runtime and the PAM module will not work.

HP-UX problems
--------------

The shared library /usr/lib/libndbm.sl doesn't exist on all systems.  To make problems even worse, there is never an archive version for static linking either. Therefore, when building ``truly portable'' binaries first install GNU gdbm or Berkeley DB, and make sure that you are linking against that library.

Cray problems
-------------

rlogind won't work on Crays until forkpty() has been ported, in the mean time use telnetd.

IRIX problems
-------------

IRIX has three different ABI:s (Application Binary Interface), there's an old 32 bit interface (known as O32, or just 32), a new 32 bit interface (N32), and a 64 bit interface (64). O32 and N32 are both 32 bits, but they have different calling conventions, and alignment constraints, and similar. The N32 format is the default format from IRIX 6.4.

You select ABI at compile time, and you can do this with the --with-mips-abi configure option. The valid arguments are o32, n32, and 64, N32 is the default. Libraries for the three different ABI:s are normally installed installed in different directories (lib, lib32, and lib64). If you want more than one set of libraries you have to reconfigure and recompile for each ABI, but you should probably install only N32 binaries.

GCC had had some known problems with the different ABI:s. Old GCC could only handle O32, newer GCC can handle N32, and 64, but not O32, but in some versions of GCC the structure alignment was broken in N32.

This confusion with different ABI:s can cause some trouble. For instance, the afskauthlib.so library has to use the same ABI as xdm, and login. The easiest way to check what ABI to use is to run file on /usr/bin/X11/xdm.

Another problem that you might encounter if you run AFS is that Transarc apparently doesn't support the 64-bit ABI, and because of this you can't get tokens with a 64 bit application. If you really need to do this, there is a kernel module that provides this functionality at ftp://ftp.pdc.kth.se/home/joda/irix-afs64.tar.gz.

AIX problems
------------

gcc version 2.7.2.* has a bug which makes it miscompile appl/telnet/telnetd/sys_term.c (and possibily appl/bsd/forkpty.c), if used with too much optimization.

Some versions of the xlc preprocessor doesn't recognise the (undocumented) -qnolm option. If this option is passed to the preprocessor (like via the configuration file /etc/ibmcxx.cfg, configure will fail.

The solution is to remove this option from the configuration file, either globally, or for just the preprocessor:

     $ cp /etc/ibmcxx.cfg /tmp
     $ed /tmp/ibmcxx.cfg
     8328
     /nolm
             options   = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000,-qnolm
     s/,-qnolm//p
             options   = -D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_IBMR2,-D_POWER,-bpT:0x10000000,-bpD:0x20000000
     w
     8321
     q
     $ env CC=xlc CPP="xlc -E -F/tmp/ibmcxx.cfg" configure

There is a bug in AFS 3.4 version 5.38 for AIX 4.3 that causes the kernel to panic in some cases. There is a hack for this in login, but other programs could be affected also. This seems to be fixed in version 5.55.

C2 problems
-----------

The programs that checks passwords works with passwd, OTP, and Kerberos paswords. This is problem if you use C2 security (or use some other password database), that normally keeps passwords in some obscure place. If you want to use Kerberos with C2 security you will have to think about what kind of changes are necessary. See also the discussion about Digital's SIA and C2 security, see Digital SIA.

Problems with firewalls
=======================

A firewall is a network device that filters out certain types of packets going from one side of the firewall to the other. A firewall is supposed to solve the same kinds of problems as Kerberos (basically hindering unauthorised network use). The difference is that Kerberos tries to authenticate users, while firewall splits the network in a `secure' inside, and an `insecure' outside.

Firewall people usually think that UDP is insecure, partly because many `insecure' protocols use UDP. Since Kerberos by default uses UDP to send and recieve packets, Kerberos and firewalls doesn't work very well together.

The symptoms of trying to use Kerberos behind a firewall is that you can't get any tickets (kinit exits with the infamous Can't send request error message).

There are a few ways to solve these problems:

  * Convince your firewall administrator to open UDP port 750 or 88 for incoming packets. This usually turns out to be difficult.

  * Convince your firewall administrator to open TCP port 750 or 88 for outgoing connections. This can be a lot easier, and might already be enabled.

  * Use TCP connections over some non-standard port. This requires that you have to convince the administrator of the kerberos server to allow connections on this port.

  * Use HTTP to get tickets. Since web-stuff has become almost infinitely popular, many firewalls either has the HTTP port open, or has a HTTP proxy.

The last two methods might be considered to be offensive (since you are not sending the `right' type of data in each port). You probably do best in discussuing this with firewall administrator.

For information on how to use other protocols when communication with KDC, see Install the configuration files.

It is often the case that the firewall hides addresses on the `inside', so it looks like all packets are coming from the firewall. Since address of the client host is encoded in the ticket, this can cause trouble. If you get errors like Incorrect network address, when trying to use the ticket, the problem is usually becuase the server you are trying to talk to sees a different address than the KDC did. If you experience this kind of trouble, the easiest way to solve them is probably to try some other mechanism to fetch tickets. You might also be able to convince the administrator of the server that the two different addresses should be added to the /etc/krb.equiv file.

Common error messages
=====================

These are some of the more obscure error messages you might encounter:

Time is out of bounds

     The time on your machine differs from the time on either the kerberos server or the machine you are trying to login to. If it isn't obvious that this is the case, remember that all times are compared in UTC.

     On unix systems you usually can find out what the local time is by doing telnet machine daytime. This time (again, usually is the keyword) is with correction for time-zone and daylight savings.

     If you have problem keeping your clocks synchronized, consider using a time keeping system such as NTP (see also the discussion in Install the client programs).

Ticket issue date too far in the future

     The time on the kerberos server is more than five minutes ahead of the time on the server.

Can't decode authenticator

     This means that there is a mismatch between the service key in the kerberos server and the service key file on the specific machine. Either:

       * the server couldn't find a service key matching the request

       * the service key (or version number) does not match the key the packet was encrypted with

Incorrect network address

     The address in the ticket does not match the address you sent the request from. This happens on systems with more than one network address, either physically or logically. You can list addresses which should be considered equal in /etc/krb.equiv on your servers.

     A note to programmers: a server should not pass * as the instance to krb_rd_req. It should try to figure out on which interface the request was received, for instance by using k_getsockinst.

     If you change addresses on your computer you invalidate any tickets you might have. The easiest way to fix this is to get new tickets with the new address.

Message integrity error

     The packet is broken in some way:

       * the lengths does not match the size of the packet, or

       * the checksum does not match the contents of the packet

Can't send request
     There is some problem contacting the kerberos server. Either the server is down, or it is using the wrong port (compare the entries for kerberos-iv in /etc/services). The client might also have failed to guess what kerberos server to talk to (check /etc/krb.conf and /etc/krb.realms).

     One reason you can't contact the kerberos server might be because you're behind a firewall that doesn't allow kerberos packets to pass. For possible solutions to this see the firewall section above.

kerberos: socket: Unable to open socket...

     The kerberos server has to open four sockets for each interface.  If you have a machine with lots of virtual interfaces, you run the risk of running out of file descriptors.  If that happens you will get this error message.

ftp: User foo access denied

     This usually happens because the user's shell is not listed in /etc/shells.  Note that ftpd checks this file even on systems where the system version does not and there is no /etc/shells.

Generic kerberos error
     This is a generic catch-all error message.

Is Kerberos year 2000 safe?
===========================

Yes.

A somewhat longer answer is that we can't think of anything that can break. The protocol itself doesn't use time stamps in textual form, the two-digit year problems in the original MIT code has been fixed (this was a problem mostly with log files). The FTP client had a bug in the command `newer' (which fetches a file if it's newer than what you already got).

Another thing to look out for, but that isn't a Y2K problem per se, is the expiration date of old principals. The MIT code set the default expiration date for some new principals to 1999-12-31, so you might want to check your database for things like this.

Now, the Y2038 problem is something completely different (but the authors should have retired by then, presumably growing rowanberrys in some nice and warm place).