3 @node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, Top
4 @comment node-name, next, previous, up
5 @chapter Kerberos 4 issues
7 The KDC has built-in version 4 support. It is not enabled by default,
8 see setup how to set it up.
10 The KDC will also have kaserver emulation and be able to handle
11 AFS-clients that use @code{klog}.
13 For more about AFS, see the section @xref{AFS}.
16 * Principal conversion issues::
17 * Converting a version 4 database::
21 @node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
22 @section Principal conversion issues
24 First, Kerberos 4 and Kerberos 5 principals are different. A version 4
25 principal consists of a name, an instance, and a realm. A version 5
26 principal has one or more components, and a realm (the terms ``name''
27 and ``instance'' are still used, for the first and second component,
28 respectively). Also, in some cases the name of a version 4 principal
29 differs from the first component of the corresponding version 5
30 principal. One notable example is the ``host'' type principals, where
31 the version 4 name is @samp{rcmd} (for ``remote command''), and the
32 version 5 name is @samp{host}. For the class of principals that has a
33 hostname as instance, there is an other major difference, Kerberos 4
34 uses only the first component of the hostname, whereas Kerberos 5 uses
35 the fully qualified hostname.
37 Because of this it can be hard or impossible to correctly convert a
38 version 4 principal to a version 5 principal @footnote{the other way is
39 not always trivial either, but usually easier}. The biggest problem is
40 to know if the conversion resulted in a valid principal. To give an
41 example, suppose you want to convert the principal @samp{rcmd.foo}.
43 The @samp{rcmd} name suggests that the instance is a hostname (even if
44 there are exceptions to this rule). To correctly convert the instance
45 @samp{foo} to a hostname, you have to know which host it is referring
46 to. You can to this by either guessing (from the realm) which domain
47 name to append, or you have to have a list of possible hostnames. In the
48 simplest cases you can cover most principals with the first rule. If you
49 have several domains sharing a single realm this will not usually
50 work. If the exceptions are few you can probably come by with a lookup
51 table for the exceptions.
53 In a complex scenario you will need some kind of host lookup mechanism.
54 Using DNS for this is tempting, but DNS is error prone, slow and unsafe
55 @footnote{at least until secure DNS is commonly available}.
57 Fortunately, the KDC has a trump on hand: it can easily tell if a
58 principal exists in the database. The KDC will use
59 @code{krb5_425_conv_principal_ext} to convert principals when handling
60 to version 4 requests.
62 @node Converting a version 4 database, kaserver , Principal conversion issues, Kerberos 4 issues
63 @section Converting a version 4 database
65 If you want to convert an existing version 4 database, the principal
66 conversion issue arises too.
68 If you decide to convert your database once and for all, you will only
69 have to do this conversion once. It is also possible to run a version 5
70 KDC as a slave to a version 4 KDC. In this case this conversion will
71 happen every time the database is propagated. When doing this
72 conversion, there are a few things to look out for. If you have stale
73 entries in the database, these entries will not be converted. This might
74 be because these principals are not used anymore, or it might be just
75 because the principal couldn't be converted.
77 You might also see problems with a many-to-one mapping of
78 principals. For instance, if you are using DNS lookups and you have two
79 principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME
80 for `bar', the resulting principals will be the same. Since the
81 conversion function can't tell which is correct, these conflicts will
82 have to be resolved manually.
84 @subsection Conversion example
86 Given the following set of hosts and services:
94 you have a database that consists of the following principals:
96 @samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and
99 lets say you also got these extra principals: @samp{rcmd.gone},
100 @samp{rcmd.old-mail}, where @samp{gone.foo.se} was a machine that has
101 now passed away, and @samp{old-mail.foo.se} was an old mail machine that
102 is now a CNAME for @samp{mail.foo.se}.
104 When you convert this database you want the following conversions to be
108 rcmd.mail host/mail.foo.se
109 pop.mail pop/mail.foo.se
110 rcmd.ftp host/ftp.bar.se
111 ftp.ftp ftp/ftp.bar.se
112 rcmd.gone @i{removed}
113 rcmd.old-mail @i{removed}
116 A @file{krb5.conf} that does this looks like:
128 v4_instance_convert = @{
132 default_domain = foo.se
136 The @samp{v4_name_convert} section says which names should be considered
137 having an instance consisting of a hostname, and it also says how the
138 names should be converted (for instance @samp{rcmd} should be converted
139 to @samp{host}). The @samp{v4_instance_convert} section says how a
140 hostname should be qualified (this is just a hosts-file in
141 disguise). Host-instances that aren't covered by
142 @samp{v4_instance_convert} are qualified by appending the contents of
143 the @samp{default_domain}.
145 Actually, this example doesn't work. Or rather, it works to well. Since
146 it has no way of knowing which hostnames are valid and which are not, it
147 will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This
148 isn't a big problem, but if you have run your kerberos realm for a few
149 years, chances are big that you have quite a few `junk' principals.
151 If you don't want this you can remove the @samp{default_domain}
152 statement, but then you will have to add entries for @emph{all} your hosts
153 in the @samp{v4_instance_convert} section.
155 Instead of doing this you can use DNS to convert instances. This is not
156 a solution without problems, but it is probably easier than adding lots
157 of static host entries.
159 To enable DNS lookup you should turn on @samp{v4_instance_resolve} in
160 the @samp{[libdefaults]} section.
162 @subsection Converting a database
164 The database conversion is done with @samp{hprop}. You can run this
165 command to propagate the database to the machine called
166 @samp{slave-server} (which should be running a @samp{hpropd}).
169 hprop --source=krb4-db --master-key=/.m slave-server
172 This command can also be to use for converting the v4 database on the
176 hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
179 @section Version 4 Kadmin
181 @samp{kadmind} can act as a version 4 kadmind, and you can do most
182 operations, but with some restrictions (since the version 4 kadmin
183 protocol is, lets say, very ad hoc.) One example is that it only passes
184 des keys when creating principals and changing passwords (modern kpasswd
185 clients do send the password, so it's possible to to password quality
186 checks). Because of this you can only create principals with des keys,
187 and you can't set any flags or do any other fancy stuff.
189 To get this to work, you have to add another entry to inetd (since
190 version 4 uses port 751, not 749).
192 @emph{And then there are a many more things you can do; more on this in
193 a later version of this manual. Until then, UTSL.}
195 @node kaserver, , Converting a version 4 database, Kerberos 4 issues
198 @subsection kaserver emulation
200 The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4
201 server with pre-authentication using Rx as the on-wire protocol. The kdc
202 contains a minimalistic Rx implementation.
204 There are three parts of the kaserver; KAA (Authentication), KAT (Ticket
205 Granting), and KAM (Maintenance). The KAA interface and KAT interface
206 both passes over DES encrypted data-blobs (just like the
207 Kerberos-protocol) and thus do not need any other protection. The KAM
208 interface uses @code{rxkad} (Kerberos authentication layer for Rx) for
209 security and data protection, and is used for example for changing
210 passwords. This part is not implemented in the kdc.
212 Another difference between the ka-protocol and the Kerberos 4 protocol
213 is that the pass-phrase is salted with the cellname in the @code{string to
214 key} function in the ka-protocol, while in the Kerberos 4 protocol there
215 is no salting of the password at all. To make sure AFS-compatible keys
216 are added to each principals when they are created or their password are
217 changed, @samp{afs3-salt} should be added to
218 @samp{[kadmin]default_keys}.
220 For more about AFS, see the section @xref{AFS}.
222 @subsection Transarc AFS Windows client
224 The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus
225 does not need a kaserver. The Windows client assumes that the Kerberos
226 server is on the same machine as the AFS-database server. If you do not
227 like to do that you can add a small program that runs on the database
228 servers that forward all kerberos requests to the real kerberos
229 server. A program that does this is @code{krb-forward}
230 (@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}).