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 7The KDC has built-in version 4 support. It is not enabled by default, 8see setup how to set it up. 9 10The KDC will also have kaserver emulation and be able to handle 11AFS-clients that use @code{klog}. 12 13For 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 24First, Kerberos 4 and Kerberos 5 principals are different. A version 4 25principal consists of a name, an instance, and a realm. A version 5 26principal has one or more components, and a realm (the terms ``name'' 27and ``instance'' are still used, for the first and second component, 28respectively). Also, in some cases the name of a version 4 principal 29differs from the first component of the corresponding version 5 30principal. One notable example is the ``host'' type principals, where 31the version 4 name is @samp{rcmd} (for ``remote command''), and the 32version 5 name is @samp{host}. For the class of principals that has a 33hostname as instance, there is an other major difference, Kerberos 4 34uses only the first component of the hostname, whereas Kerberos 5 uses 35the fully qualified hostname. 36 37Because of this it can be hard or impossible to correctly convert a 38version 4 principal to a version 5 principal @footnote{the other way is 39not always trivial either, but usually easier}. The biggest problem is 40to know if the conversion resulted in a valid principal. To give an 41example, suppose you want to convert the principal @samp{rcmd.foo}. 42 43The @samp{rcmd} name suggests that the instance is a hostname (even if 44there 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 46to. You can to this by either guessing (from the realm) which domain 47name to append, or you have to have a list of possible hostnames. In the 48simplest cases you can cover most principals with the first rule. If you 49have several domains sharing a single realm this will not usually 50work. If the exceptions are few you can probably come by with a lookup 51table for the exceptions. 52 53In a complex scenario you will need some kind of host lookup mechanism. 54Using DNS for this is tempting, but DNS is error prone, slow and unsafe 55@footnote{at least until secure DNS is commonly available}. 56 57Fortunately, the KDC has a trump on hand: it can easily tell if a 58principal exists in the database. The KDC will use 59@code{krb5_425_conv_principal_ext} to convert principals when handling 60to 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 65If you want to convert an existing version 4 database, the principal 66conversion issue arises too. 67 68If you decide to convert your database once and for all, you will only 69have to do this conversion once. It is also possible to run a version 5 70KDC as a slave to a version 4 KDC. In this case this conversion will 71happen every time the database is propagated. When doing this 72conversion, there are a few things to look out for. If you have stale 73entries in the database, these entries will not be converted. This might 74be because these principals are not used anymore, or it might be just 75because the principal couldn't be converted. 76 77You might also see problems with a many-to-one mapping of 78principals. For instance, if you are using DNS lookups and you have two 79principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME 80for `bar', the resulting principals will be the same. Since the 81conversion function can't tell which is correct, these conflicts will 82have to be resolved manually. 83 84@subsection Conversion example 85 86Given the following set of hosts and services: 87 88@example 89foo.se rcmd 90mail.foo.se rcmd, pop 91ftp.bar.se rcmd, ftp 92@end example 93 94you 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 99lets 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 101now passed away, and @samp{old-mail.foo.se} was an old mail machine that 102is now a CNAME for @samp{mail.foo.se}. 103 104When you convert this database you want the following conversions to be 105done: 106@example 107rcmd.foo host/foo.se 108rcmd.mail host/mail.foo.se 109pop.mail pop/mail.foo.se 110rcmd.ftp host/ftp.bar.se 111ftp.ftp ftp/ftp.bar.se 112rcmd.gone @i{removed} 113rcmd.old-mail @i{removed} 114@end example 115 116A @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 136The @samp{v4_name_convert} section says which names should be considered 137having an instance consisting of a hostname, and it also says how the 138names should be converted (for instance @samp{rcmd} should be converted 139to @samp{host}). The @samp{v4_instance_convert} section says how a 140hostname should be qualified (this is just a hosts-file in 141disguise). Host-instances that aren't covered by 142@samp{v4_instance_convert} are qualified by appending the contents of 143the @samp{default_domain}. 144 145Actually, this example doesn't work. Or rather, it works to well. Since 146it has no way of knowing which hostnames are valid and which are not, it 147will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This 148isn't a big problem, but if you have run your kerberos realm for a few 149years, chances are big that you have quite a few `junk' principals. 150 151If you don't want this you can remove the @samp{default_domain} 152statement, but then you will have to add entries for @emph{all} your hosts 153in the @samp{v4_instance_convert} section. 154 155Instead of doing this you can use DNS to convert instances. This is not 156a solution without problems, but it is probably easier than adding lots 157of static host entries. 158 159To enable DNS lookup you should turn on @samp{v4_instance_resolve} in 160the @samp{[libdefaults]} section. 161 162@subsection Converting a database 163 164The database conversion is done with @samp{hprop}. You can run this 165command to propagate the database to the machine called 166@samp{slave-server} (which should be running a @samp{hpropd}). 167 168@example 169hprop --source=krb4-db --master-key=/.m slave-server 170@end example 171 172This command can also be to use for converting the v4 database on the 173server: 174 175@example 176hprop -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 184The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4 185server with pre-authentication using Rx as the on-wire protocol. The kdc 186contains a minimalistic Rx implementation. 187 188There are three parts of the kaserver; KAA (Authentication), KAT (Ticket 189Granting), and KAM (Maintenance). The KAA interface and KAT interface 190both passes over DES encrypted data-blobs (just like the 191Kerberos-protocol) and thus do not need any other protection. The KAM 192interface uses @code{rxkad} (Kerberos authentication layer for Rx) for 193security and data protection, and is used for example for changing 194passwords. This part is not implemented in the kdc. 195 196Another difference between the ka-protocol and the Kerberos 4 protocol 197is that the pass-phrase is salted with the cellname in the @code{string to 198key} function in the ka-protocol, while in the Kerberos 4 protocol there 199is no salting of the password at all. To make sure AFS-compatible keys 200are added to each principals when they are created or their password are 201changed, @samp{afs3-salt} should be added to 202@samp{[kadmin]default_keys}. 203 204For more about AFS, see the section @xref{AFS}. 205 206@subsection Transarc AFS Windows client 207 208The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus 209does not need a kaserver. The Windows client assumes that the Kerberos 210server is on the same machine as the AFS-database server. If you do not 211like to do that you can add a small program that runs on the database 212servers that forward all kerberos requests to the real kerberos 213server. A program that does this is @code{krb-forward} 214(@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}). 215