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