1@node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, Top 2@comment node-name, next, previous, up 3@chapter Kerberos 4 issues 4 5If compiled with version 4 support, the KDC can serve requests from a 6Kerberos 4 client. There are a few things you must do for this to work. 7 8@menu 9* Principal conversion issues:: 10* Converting a version 4 database:: 11@end menu 12 13@node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues 14@section Principal conversion issues 15 16First, Kerberos 4 and Kerberos 5 principals are different. A version 4 17principal consists of a name, an instance, and a realm. A version 5 18principal has one or more components, and a realm (the terms ``name'' 19and ``instance'' are still used, for the first and second component, 20respectively). Also, in some cases the name of a version 4 principal 21differs from the first component of the corresponding version 5 22principal. One notable example is the ``host'' type principals, where 23the version 4 name is @samp{rcmd} (for ``remote command''), and the 24version 5 name is @samp{host}. For the class of principals that has a 25hostname as instance, there is an other major difference, Kerberos 4 26uses only the first component of the hostname, whereas Kerberos 5 uses 27the fully qualified hostname. 28 29Because of this it can be hard or impossible to correctly convert a 30version 4 principal to a version 5 principal @footnote{the other way is 31not always trivial either, but usually easier}. The biggest problem is 32to know if the conversion resulted in a valid principal. To give an 33example, suppose you want to convert the principal @samp{rcmd.foo}. 34 35The @samp{rcmd} name suggests that the instance is a hostname (even if 36there are exceptions to this rule). To correctly convert the instance 37@samp{foo} to a hostname, you have to know which host it is referring 38to. You can to this by either guessing (from the realm) which domain 39name to append, or you have to have a list of possible hostnames. In the 40simplest cases you can cover most principals with the first rule. If you 41have several domains sharing a single realm this will not usually 42work. If the exceptions are few you can probably come by with a lookup 43table for the exceptions. 44 45In a complex scenario you will need some kind of host lookup mechanism. 46Using DNS for this is tempting, but DNS is error prone, slow and unsafe 47@footnote{at least until secure DNS is commonly available}. 48 49Fortunately, the KDC has a trump on hand: it can easily tell if a 50principal exists in the database. The KDC will use 51@code{krb5_425_conv_principal_ext} to convert principals when handling 52to version 4 requests. 53 54@node Converting a version 4 database, , Principal conversion issues, Kerberos 4 issues 55@section Converting a version 4 database 56 57If you want to convert an existing version 4 database, the principal 58conversion issue arises too. 59 60If you decide to convert your database once and for all, you will only 61have to do this conversion once. It is also possible to run a version 5 62KDC as a slave to a version 4 KDC. In this case this conversion will 63happen every time the database is propagated. When doing this 64conversion, there are a few things to look out for. If you have stale 65entries in the database, these entries will not be converted. This might 66be because these principals are not used anymore, or it might be just 67because the principal couldn't be converted. 68 69You might also see problems with a many-to-one mapping of 70principals. For instance, if you are using DNS lookups and you have two 71principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME 72for `bar', the resulting principals will be the same. Since the 73conversion function can't tell which is correct, these conflicts will 74have to be resolved manually. 75 76@subsection Conversion example 77 78Given the following set of hosts and services: 79 80@example 81foo.se rcmd 82mail.foo.se rcmd, pop 83ftp.bar.se rcmd, ftp 84@end example 85 86you have a database that consists of the following principals: 87 88@samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and 89@samp{ftp.ftp}. 90 91lets say you also got these extra principals: @samp{rcmd.gone}, 92@samp{rcmd.old-mail}, where @samp{gone.foo.se} was a machine that has 93now passed away, and @samp{old-mail.foo.se} was an old mail machine that 94is now a CNAME for @samp{mail.foo.se}. 95 96When you convert this database you want the following conversions to be 97done: 98@example 99rcmd.foo host/foo.se 100rcmd.mail host/mail.foo.se 101pop.mail pop/mail.foo.se 102rcmd.ftp host/ftp.bar.se 103ftp.ftp ftp/ftp.bar.se 104rcmd.gone @i{removed} 105rcmd.old-mail @i{removed} 106@end example 107 108A @file{krb5.conf} that does this looks like: 109 110@example 111[realms] 112 FOO.SE = @{ 113 v4_name_convert = @{ 114 host = @{ 115 ftp = ftp 116 pop = pop 117 rcmd = host 118 @} 119 @} 120 v4_instance_convert = @{ 121 foo = foo.se 122 ftp = ftp.bar.se 123 @} 124 default_domain = foo.se 125 @} 126@end example 127 128The @samp{v4_name_convert} section says which names should be considered 129having an instance consisting of a hostname, and it also says how the 130names should be converted (for instance @samp{rcmd} should be converted 131to @samp{host}). The @samp{v4_instance_convert} section says how a 132hostname should be qualified (this is just a hosts-file in 133disguise). Host-instances that aren't covered by 134@samp{v4_instance_convert} are qualified by appending the contents of 135the @samp{default_domain}. 136 137Actually, this example doesn't work. Or rather, it works to well. Since 138it has no way of knowing which hostnames are valid and which are not, it 139will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This 140isn't a big problem, but if you have run your kerberos realm for a few 141years, chances are big that you have quite a few `junk' principals. 142 143If you don't want this you can remove the @samp{default_domain} 144statement, but then you will have to add entries for @emph{all} your hosts 145in the @samp{v4_instance_convert} section. 146 147Instead of doing this you can use DNS to convert instances. This is not 148a solution without problems, but it is probably easier than adding lots 149of static host entries. 150 151To enable DNS lookup you should turn on @samp{v4_instance_resolve} in 152the @samp{[libdefaults]} section. 153 154@subsection Converting a database 155 156The database conversion is done with @samp{hprop}. Assuming that you 157have the @samp{kadmin/hprop} key in the keytab @file{hprop.keytab}, you 158can run this command to propagate the database to the machine called 159@samp{slave-server} (which should be running a @samp{hpropd}). 160 161@example 162hprop -4 -E -k hprop.keytab slave-server 163@end example 164 165@section Version 4 Kadmin 166 167@samp{kadmind} can act as a version 4 kadmind, and you can do most 168operations, but with some restrictions (since the version 4 kadmin 169protocol is, lets say, very ad hoc.) One example is that it only passes 170des keys when creating principals and changing passwords (modern kpasswd 171clients do send the password, so it's possible to to password quality 172checks). Because of this you can only create principals with des keys, 173and you can't set any flags or do any other fancy stuff. 174 175To get this to work, you have to add another entry to inetd (since 176version 4 uses port 751, not 749). 177 178@emph{And then there are a many more things you can do; more on this in 179a later version of this manual. Until then, UTSL.} 180