diff options
Diffstat (limited to 'crypto/kerberosIV/doc/problems.texi')
| -rw-r--r-- | crypto/kerberosIV/doc/problems.texi | 342 |
1 files changed, 0 insertions, 342 deletions
diff --git a/crypto/kerberosIV/doc/problems.texi b/crypto/kerberosIV/doc/problems.texi deleted file mode 100644 index d7a525f..0000000 --- a/crypto/kerberosIV/doc/problems.texi +++ /dev/null @@ -1,342 +0,0 @@ -@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). |
