doc/kerberos4.texi

   1 @c $Id$
   2
   3 @node Kerberos 4 issues, Windows compatibility, Things in search for a better place, Top
   4 @comment  node-name,  next,  previous,  up
   5 @chapter Kerberos 4 issues
   6
   7 The KDC has built-in version 4 support. It is not enabled by default,
   8 see setup how to set it up.
   9
  10 The KDC will also have kaserver emulation and be able to handle
  11 AFS-clients that use @code{klog}.
  12
  13 For more about AFS, see the section @xref{AFS}.
  14
  15 @menu
  16 * Principal conversion issues::
  17 * Converting a version 4 database::
  18 * kaserver::
  19 @end menu
  20
  21 @node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
  22 @section Principal conversion issues
  23
  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.
  36
  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}.
  42
  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.
  52
  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}.
  56
  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.
  61
  62 @node Converting a version 4 database, kaserver , Principal conversion issues, Kerberos 4 issues
  63 @section Converting a version 4 database
  64
  65 If you want to convert an existing version 4 database, the principal
  66 conversion issue arises too.
  67
  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.
  76
  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.
  83
  84 @subsection Conversion example
  85
  86 Given the following set of hosts and services:
  87
  88 @example
  89 foo.se          rcmd
  90 mail.foo.se     rcmd, pop
  91 ftp.bar.se      rcmd, ftp
  92 @end example
  93
  94 you have a database that consists of the following principals:
  95
  96 @samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and
  97 @samp{ftp.ftp}.
  98
  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}.
 103
 104 When you convert this database you want the following conversions to be
 105 done:
 106 @example
 107 rcmd.foo         host/foo.se
 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}
 114 @end example
 115
 116 A @file{krb5.conf} that does this looks like:
 117
 118 @example
 119 [realms]
 120         FOO.SE = @{
 121                 v4_name_convert = @{
 122                         host = @{
 123                                 ftp = ftp
 124                                 pop = pop
 125                                 rcmd = host
 126                         @}
 127                 @}
 128                 v4_instance_convert = @{
 129                         foo = foo.se
 130                         ftp = ftp.bar.se
 131                 @}
 132                 default_domain = foo.se
 133         @}
 134 @end example
 135
 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}.
 144
 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.
 150
 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.
 154
 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.
 158
 159 To enable DNS lookup you should turn on @samp{v4_instance_resolve} in
 160 the @samp{[libdefaults]} section.
 161
 162 @subsection Converting a database
 163
 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}).
 167
 168 @example
 169 hprop --source=krb4-db --master-key=/.m slave-server
 170 @end example
 171
 172 This command can also be to use for converting the v4 database on the
 173 server:
 174
 175 @example
 176 hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
 177 @end example
 178
 179 @node kaserver, , Converting a version 4 database, Kerberos 4 issues
 180 @section kaserver
 181
 182 @subsection kaserver emulation
 183
 184 The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4
 185 server with pre-authentication using Rx as the on-wire protocol. The kdc
 186 contains a minimalistic Rx implementation.
 187
 188 There are three parts of the kaserver; KAA (Authentication), KAT (Ticket
 189 Granting), and KAM (Maintenance). The KAA interface and KAT interface
 190 both passes over DES encrypted data-blobs (just like the
 191 Kerberos-protocol) and thus do not need any other protection.  The KAM
 192 interface uses @code{rxkad} (Kerberos authentication layer for Rx) for
 193 security and data protection, and is used for example for changing
 194 passwords.  This part is not implemented in the kdc.
 195
 196 Another difference between the ka-protocol and the Kerberos 4 protocol
 197 is that the pass-phrase is salted with the cellname in the @code{string to
 198 key} function in the ka-protocol, while in the Kerberos 4 protocol there
 199 is no salting of the password at all. To make sure AFS-compatible keys
 200 are added to each principals when they are created or their password are
 201 changed, @samp{afs3-salt} should be added to
 202 @samp{[kadmin]default_keys}.
 203
 204 For more about AFS, see the section @xref{AFS}.
 205
 206 @subsection Transarc AFS Windows client
 207
 208 The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus
 209 does not need a kaserver. The Windows client assumes that the Kerberos
 210 server is on the same machine as the AFS-database server. If you do not
 211 like to do that you can add a small program that runs on the database
 212 servers that forward all kerberos requests to the real kerberos
 213 server. A program that does this is @code{krb-forward}
 214 (@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}).