diff options
Diffstat (limited to 'crypto/kerberosIV/doc/problems.texi')
| -rw-r--r-- | crypto/kerberosIV/doc/problems.texi | 342 |
1 files changed, 342 insertions, 0 deletions
diff --git a/crypto/kerberosIV/doc/problems.texi b/crypto/kerberosIV/doc/problems.texi new file mode 100644 index 0000000..d7a525f --- /dev/null +++ b/crypto/kerberosIV/doc/problems.texi @@ -0,0 +1,342 @@ +@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 + +@cindex GCC +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. + +@cindex Linux +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 SunOS 5 (aka Solaris 2) problems + +@cindex SunOS 5 + +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. + +@subheading HP-UX problems + +@cindex HP-UX +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 IRIX problems + +@cindex IRIX + +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 +@samp{--with-mips-abi} configure option. The valid arguments are +@samp{o32}, @samp{n32}, and @samp{64}, N32 is the default. Libraries for +the three different ABI:s are normally installed installed in different +directories (@samp{lib}, @samp{lib32}, and @samp{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. + +@cindex GCC +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 @file{afskauthlib.so} library has to use the same ABI as +@file{xdm}, and @file{login}. The easiest way to check what ABI to use +is to run @samp{file} on @file{/usr/bin/X11/xdm}. + +@cindex AFS +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 +@url{ftp://ftp.pdc.kth.se/home/joda/irix-afs64.tar.gz}. + +@subheading AIX problems + +@cindex GCC +@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). |
