1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
@node Resolving frequent problems, Acknowledgments, One-Time Passwords, Top
@chapter Resolving frequent problems
@menu
* Problems compiling Kerberos::
* Common error messages::
@end menu
@node Problems compiling Kerberos, Common error messages, Resolving frequent problems, Resolving frequent problems
@section Problems compiling Kerberos
Many compilers require a switch to become ANSI compliant. Since kth-krb
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
Some systems have lost @file{/usr/include/ndbm.h} which is necessary to
build kth-krb 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.1 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.
@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 Common error messages, , Problems compiling Kerberos, 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}).
@item @samp{Generic kerberos error}
This is a generic catch-all error message.
@end table
|
