@node Resolving frequent problems, Acknowledgments, One-Time Passwords, Top
@chapter Resolving frequent problems

@menu
* Problems compiling Kerberos::  
* Problems with firewalls::     
* Common error messages::       
* Is Kerberos year 2000 safe?::  
@end menu

@node Problems compiling Kerberos, Problems with firewalls, Resolving frequent problems, Resolving frequent problems
@section 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 @kbd{env} command. For
instance to build under HP-UX using the native compiler do:

@cartouche
@example
datan$ env CC="cc -Ae" ./configure
@end example
@end cartouche

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

@table @asis

@item @samp{HP-UX}
@kbd{cc -Ae}
@item @samp{Digital UNIX}
@kbd{cc -std1}
@item @samp{AIX}
@kbd{xlc}
@item @samp{Solaris 2.x}
@kbd{cc} (unbundled one)
@item @samp{IRIX}
@kbd{cc}

@end table

@subheading Linux problems

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

@cartouche
hosts: files dns
@end cartouche

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

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

@subheading HP-UX problems

The shared library @file{/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.

@subheading Cray problems

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

@subheading AIX problems

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

Some versions of the @kbd{xlc} preprocessor doesn't recognise the
(undocumented) @samp{-qnolm} option. If this option is passed to the
preprocessor (like via the configuration file @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:

@example
$ 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
@end example

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 @kbd{login},
but other programs could be affected also. This seems to be fixed in
version 5.55.

@subheading C2 problems

@cindex C2
The programs that checks passwords works with @file{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 @ref{Digital SIA}.

@node Problems with firewalls, Common error messages, Problems compiling Kerberos, Resolving frequent problems
@section Problems with firewalls

@cindex firewall
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 (@code{kinit} exits with the infamous @samp{Can't
send request} error message).

There are a few ways to solve these problems:

@itemize @bullet
@item 
Convince your firewall administrator to open UDP port 750 or 88 for
incoming packets. This usually turns out to be difficult.
@item 
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.
@item 
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.
@item 
@cindex HTTP
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.
@end itemize

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 @ref{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 @samp{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 @file{/etc/krb.equiv} file.

@node Common error messages, Is Kerberos year 2000 safe?, Problems with firewalls, Resolving frequent problems
@section Common error messages

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

@table @asis

@item @samp{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
@code{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
@ref{Install the client programs}).

@item @samp{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.

@item @samp{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:
@itemize @bullet
@item
the server couldn't find a service key matching the request
@item
the service key (or version number) does not match the key the packet
was encrypted with
@end itemize

@item @samp{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 @file{/etc/krb.equiv} on your servers. 

A note to programmers: a server should not pass @samp{*} as the instance
to @samp{krb_rd_req}. It should try to figure out on which interface the
request was received, for instance by using @samp{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.

@item @samp{Message integrity error}

The packet is broken in some way:
@itemize @bullet
@item
the lengths does not match the size of the packet, or
@item
the checksum does not match the contents of the packet
@end itemize

@item @samp{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
@samp{kerberos-iv} in @file{/etc/services}). The client might also have
failed to guess what kerberos server to talk to (check
@file{/etc/krb.conf} and @file{/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.

@item @samp{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.

@item @samp{ftp: User foo access denied}

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

@item @samp{Generic kerberos error}
This is a generic catch-all error message.

@end table

@node Is Kerberos year 2000 safe?,  , Common error messages, Resolving frequent problems
@section Is Kerberos year 2000 safe?

@cindex Year 2000

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