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